Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Simulación Con Software Arena (4a. Ed.) PDF
Simulación Con Software Arena (4a. Ed.) PDF
Cuarta edición
W. David Kelton
University of Cincinnati
Randall P. Sadowski
Rockwell Automation
David T. Sturrock
Rockwell Automation
Revisor técnico:
Jorge E. Betancourt
Instituto Tecnológico y de Estudios Superiores de Monterrey,
Campus Ciudad de México
ISBN-13: 978-970-10-6515-0
ISBN-10: 970-10-6515-8
1234567890 09765432108
Aidan, Charity, Emma, Jenny, Michael, Noah, Sammy, Sean, Shelley y Tierney
1.1 Modelación......................................................................................................... 1
1.1.1 ¿Qué se está modelando?................................................................ 2
1.1.2 ¿Y si sólo se juega con el sistema? . ................................................ 3
1.1.3 A veces no se puede (o no se debe) jugar con el sistema.................. 3
1.1.4 Modelos físicos............................................................................... 4
1.1.5 Modelos lógicos (o matemáticos)................................................... 4
1.1.6 ¿Qué es lo que se hace con un modelo lógico?................................ 5
1.2 Simulación por computadora.............................................................................. 5
1.2.1 Popularidad y ventajas................................................................... 5
1.2.2 Las malas noticias.......................................................................... 6
1.2.3 Diferentes tipos de simulaciones..................................................... 7
1.3 Cómo se hace la simulación................................................................................. 8
1.3.1 A mano.......................................................................................... 8
1.3.2 Programación en lenguajes con un propósito general..................... 10
1.3.3 Lenguajes de simulación................................................................. 10
1.3.4 Simuladores de alto nivel................................................................ 10
1.3.5 En dónde encaja Arena.................................................................. 10
1.4 Cuándo se usan las simulaciones......................................................................... 12
1.4.1 Los primeros años.......................................................................... 12
1.4.2 Los años de formación................................................................... 12
1.4.3 El pasado reciente.......................................................................... 13
1.4.4 El presente...................................................................................... 13
1.4.5 El futuro......................................................................................... 14
2.1 Un ejemplo.......................................................................................................... 15
2.1.1 El sistema....................................................................................... 15
2.1.2 Metas del estudio........................................................................... 17
2.2 Opciones de análisis............................................................................................. 18
2.2.1 Conjetura educada......................................................................... 18
2.2.2 Teoría de colas................................................................................ 19
2.2.3 Simulación mecánica...................................................................... 20
2.3 Piezas de un modelo de simulación...................................................................... 20
2.3.1 Entidades....................................................................................... 20
2.3.2 Atributos........................................................................................ 21
viii Contenido
3.1 Inicio................................................................................................................... 53
3.2 Exploración de la ventana de Arena.................................................................... 55
3.2.1 Abrir un modelo............................................................................. 55
3.2.2 Interacción básica y partes de la ventana de Arena........................ 56
3.2.3 Tomar vista panorámica, acercamiento, ver y alinear en la vista
del diagrama de flujo...................................................................... 58
3.2.4 Módulos......................................................................................... 60
3.2.5 Documentación interna del modelo............................................... 61
3.3 Navegar por un modelo existente: modelo 3-1..................................................... 62
3.3.1 El módulo Create en diagrama de flujo.......................................... 62
3.3.2 El módulo de Entity Data (Datos de la Entidad)............................ 64
3.3.3 El módulo diagrama de flujo de proceso......................................... 64
3.3.4 El módulo Data del recurso............................................................ 66
3.3.5 El módulo Queue Data . ................................................................ 67
3.3.6 Animar recursos y colas................................................................. 68
3.3.7 El módulo Dispose de diagrama de flujo........................................ 68
3.3.8 Conexión de los módulos del diagrama de flujo............................. 68
3.3.9 Gráficos dinámicos . ...................................................................... 69
3.3.10 Arreglando las cosas....................................................................... 71
3.3.11 Preparando las condiciones para la ejecución................................. 72
Contenido ix
3.3.12 Ejecución........................................................................................ 73
3.3.13 Ver los reportes............................................................................... 74
3.4 Construya el modelo 3-1 usted mismo................................................................. 79
3.4.1 Nueva ventana del modelo y panel básico del proceso . ................. 80
3.4.2 Colocar y conectar los módulos del diagrama de flujo.................... 81
3.4.3 El módulo Create de diagrama de flujo.......................................... 81
3.4.4 Despliegues.................................................................................... 82
3.4.5 El módulo Entity Date................................................................... 83
3.4.6 El módulo de diagrama de flujo Process ........................................ 83
3.4.7 Los módulos Resource y Queue data . ........................................... 84
3.4.8 Animation Resource (Animación).................................................. 84
3.4.9 El módulo Dispose del diagrama de flujo....................................... 85
3.4.10 Gráficos dinámicos......................................................................... 85
3.4.11 Fachada (apariencia)...................................................................... 88
3.4.12 Los cuadros de diálogo Run > Setup (Correr > configurar)......... 89
3.4.13 Establecer Named Views ............................................................... 89
3.5 Estudio de caso: procesamiento serial especializado frente a procesamiento
paralelo generalizado........................................................................................... 89
3.5.1 Modelo 3-2: Procesamiento serial. Trabajo especializado separado.. 90
3.5.2 Modelo 3-3: Procesamiento paralelo. Trabajo integrado
generalizado................................................................................... 93
3.5.3 Modelos 3-4 y 3-5: El efecto de la variabilidad de tiempo de tarea 95
3.6 Más de menús, barras de herramientas, dibujo e impresión................................. 97
3.6.1 Menús............................................................................................ 98
3.6.2 Barras de herramientas................................................................... 102
3.6.3 Dibujar........................................................................................... 105
3.6.4 Imprimir......................................................................................... 107
3.7 ¡Ayuda!................................................................................................................ 107
3.8 Más de ejecutar modelos..................................................................................... 108
3.9 Resumen y pronóstico.......................................................................................... 110
3.10 Ejercicios............................................................................................................. 110
5.6 Modelo 5-3: el centro de llamadas mejorado con más medidas del
desempeño de la salida........................................................................................ 238
5.7 Modelo 5-4: simulación de inventario (s, S)......................................................... 245
5.7.1 Descripción del sistema.................................................................. 245
5.7.2 Modelo de simulación.................................................................... 247
5.8 Resumen y pronóstico.......................................................................................... 258
5.9 Ejercicios............................................................................................................. 258
8.3.1 Modelo 8-2: el modelo 8-1 modificado para los transportadores.... 333
8.3.2 Modelo 8-3: refinación de la animación para los transportadores.. 341
8.4 Transportadores continuos.................................................................................. 347
8.4.1 Modelo 8-4: el pequeño sistema de fabricación con
transportadores continuos no acumuladores.................................. 350
8.4.2 Modelo 8-5: el pequeño sistema de fabricación con
transportadores acumuladores....................................................... 355
8.5 Resumen y pronóstico.......................................................................................... 356
8.6 Ejercicios............................................................................................................. 356
E sta cuarta edición de Simulación con software Arena tiene el mismo objetivo que las tres
ediciones anteriores: proporcionar una introducción a la simulación mediante el uso
del software Arena. La intención principal de esta obra es que se utilice como un texto sobre
simulación. Es recomendado para un primer curso de licenciatura relativo a simulación, sin em-
bargo, el material de los últimos capítulos se puede incorporar en cursos de posgrado. Este libro
también se puede usar para aprender simulación de manera independiente (principalmente por
usuarios de Arena). El objetivo principal es presentar los conceptos y métodos de la simulación
usando el software Arena como un vehículo para ayudar al lector a llevar a cabo modelado,
análisis y proyectos de simulación. Aun cuando se cubre la mayor parte de las capacidades de
Arena, este libro es una referencia exhaustiva acerca del software. En Simulación con software
Arena se incluye un CD con Arena 10.0 y todos los ejemplos del texto.
Los autores han adoptado un estilo de redacción informal y tutelar, centrado en ejemplos
elaborados con todo cuidado, a fin de ayudar al lector a comprender las ideas y temas presen-
tados. Desde el punto de vista ideal, los estudiantes estructurarían modelos de simulación a
medida que leen los capítulos. Al comienzo, se incita al lector a desarrollar modelos sencillos,
bien animados, de alto nivel; posteriormente se pasa hacia el modelado y los análisis avanzados.
El análisis estadístico no se trata como un tema separado, sino que se integra en muchos de los
capítulos de modelado, para reflejar la naturaleza conjunta de estas actividades en estudios de
simulación. En esta obra se presentan los aspectos estadísticos y la planeación de proyectos
en capítulos finales de manera de cubrir aspectos más avanzados que no abarcan los capítulos
sobre modelado. Este enfoque mejora mucho el proceso de aprendizaje al colocar al lector en
una situación más realista y menos aburrida.
No es necesario que el estudiante tenga un conocimiento previo de simulación ni experiencia
en programación de computadora; basta que exista una familiaridad básica con la computa-
ción en general (archivos, carpetas, operaciones básicas de edición, etc.), pero nada avanzado.
Se necesita una comprensión fundamental de la probabilidad y la estadística, y los apéndices C
y D contienen repasos de estos temas.
A continuación le ofrecemos un breve panorama de los temas y la organización de esta
obra. El capítulo 1 presenta una introducción general, una historia corta de la simulación y los
conceptos de modelado. En el capítulo 2 se maneja el proceso de simulación mediante el uso
de una simulación sencilla ejecutada a mano y se discute brevemente el uso de hojas de cálculo
para simular modelos muy sencillos. En el capítulo 3 se introduce al lector en el software Arena;
se examina un modelo de simulación a través del problema representado a mano en el capítulo
2, reestructurándolo; asimismo, se estudia la interfaz de usuario de Arena y se suministra un
panorama general de las capacidades de este software; proporcionamos también un pequeño
estudio de caso, que ilustra cómo el conocimiento de los bloques básicos de construcción de
Arena permiten manejar aspectos interesantes y realistas.
En los capítulos 4 y 5 se hacen avanzar las habilidades de modelado del lector al considerar
un ejemplo “núcleo” por capítulo, en versiones cada vez más complejas, para ilustrar diversas
características del modelado y la animación; en el capítulo 4 también se cubre el aspecto es-
tadístico de selección de distribuciones de probabilidad de entrada mediante el Arena Input
Analyzer (Analizador de entrada de Arena).
xx Prefacio
En el capítulo 6 se usa el modelo del capítulo 5 para ilustrar las capacidades básicas de aná-
lisis estadístico de la salida de Arena, incluyendo el análisis de un solo sistema, la comparación
de escenarios múltiples (configuraciones de un modelo) y la búsqueda de un escenario óptimo;
con este material se usan los Arena Output and Process Analyzers (Analizadores de salida y
procesos de Arena), así como el OptQuest para Arena.
En el capítulo 7 se introduce otro modelo “núcleo” en versiones cada vez más complejas,
que se usan para ilustrar el análisis estadístico de simulaciones de larga duración (de estado
estacionario). Las maneras alternativas en las que las entidades simuladas se pueden mover en
diversas direcciones es el tema del capítulo 8, que incluye las capacidades de manejo de materia-
les, sobre los modelos del capítulo 7. En el capítulo 9 se profundiza en las extensas estructuras
de modelado de Arena, usando una sucesión de pequeños modelos enfocados para presentar
una amplia variedad de capacidades para fines especiales.
En el capítulo 10 se describen varios temas en el área de personalización de Arena y se
integran con otras aplicaciones como hojas de cálculo y bases de datos; esto incluye el uso de
VBA (Visual Basic for Applications, Visual Basic para aplicaciones) con Arena. En el Capítulo
11 se muestra la manera en que Arena puede manejar modelos continuos y discretos continuos
combinados, como el flujo de fluidos. En el capítulo 12 se cubren conceptos estadísticos más
avanzados subyacentes y aplicados al análisis de la simulación, incluidos generadores de núme-
ros aleatorios, generación de variables y procesos, técnicas de reducción de la variancia, mues-
treo secuencial y diseño de experimentos de simulación. El capítulo 13 suministra un amplio
panorama general del proceso de simulación y discute de manera más específica los aspectos de
administración y diseminación de un proyecto de simulación.
En el apéndice A se describe una especificación completa de modelado de un proyecto para
el periódico The Washington Post. En el apéndice B se da un panorama general y un enlace
para los enunciados de problemas para la competencia de modelado de Arena patrocinada
anualmente por el Institute of Industrial Engineers (IIE) y Rockwell Automation. El apéndice
C repasa los principios básicos de la probabilidad y la estadística formulados en el marco de re-
ferencia de su papel en el modelado y el análisis de la simulación. Las distribuciones de probabi-
lidad con soporte en Arena se detallan en el apéndice D. Las instrucciones de instalación para el
software académico Arena están incluidas en el apéndice E. Toda las referencias bibliográficas
están concentradas en la sección de bibliografía, al final del libro. El índice ayuda a los lectores
a localizar los temas y a ver cómo se relacionan entre sí; también incluye los autores citados.
Como ya se mencionó, la presentación de este libro es en el “estilo tutelar” estructurado
en torno a una sucesión de ejemplos elaborados de manera cuidadosa, en los que se ilustran
conceptos y aplicaciones, en lugar del estilo convencional de presentar primero conceptos y
después citar ejemplos como una idea posterior. De modo que es probable que tenga sentido
leer (o enseñar) el material en el orden en el que se presenta. En un curso de un semestre o un
trimestre sobre simulación se podría cubrir todo el material de los capítulos 1 al 8, incluido el
material sobre estadística. Si el tiempo lo permite, se podrían incluir temas acerca de modelado
y computación de los capítulos 9 al 11, o algunos de los aspectos de estadística más avanzados
del capítulo 12 o el material relativo a administración de proyectos del capítulo 13, según los
gustos del profesor. En un segundo curso sobre simulación se podría abordar la mayor parte del
material de los capítulos 1 al 8 y después cubrir las ideas más avanzadas de modelado de los ca-
pítulos 9 al 11, seguido de los temas de los capítulos 12 y 13. Si se procede en forma autodidac-
ta, sugerimos estudiar los capítulos 1 a 6, para entender los conceptos básicos y familiarizarse
al menos con los capítulos 7 y 8, y considerar el resto del libro como una fuente de temas más
Prefacio xxi
avanzados y como material de consulta. Sin importar lo que se cubra y si se usa el libro en un
curso o en forma independiente, será útil ejecutar Arena en una computadora al mismo tiempo
que se esté leyendo este libro.
El CD contiene la versión académica de Arena (ver el apéndice E en relación con las ins-
trucciones para su instalación), la cual tiene todas las capacidades de modelado y análisis de la
versión comercial completa. Todos los ejemplos del libro y los ejercicios que están al final de los
capítulos se ejecutarán con Arena. El CD también contiene archivos para todos los modelos
de ejemplo que están en el libro. Este software se puede instalar en cualquier computadora y
está concebido para su uso conjunto con este libro. No está autorizado su uso en ambientes
comerciales.
Si el lector está familiarizado con la tercera edición, aquí podrá ver los cambios principa-
les:
< Todos los ejemplos se actualizaron para conformarse a la versión actual de Arena (10.0).
El software es en gran parte coherente con lo que se discutió en la tercera edición, pero
hay varias características y capacidades nuevas que ilustramos, incluyendo documenta-
ción del modelo, gráficas mejoradas, lectura y escritura de archivos, impresión y símbo-
los de animación.
< La sección 2.7 del capítulo 2 es nueva y en ella se da una introducción breve del uso de
hojas de cálculo con el fin de simular con un ejemplo el modelo estático y el dinámico.
< La sección 3.5 del capítulo 3 es nueva e incluye un estudio de caso del procesamiento en
paralelo, en comparación con uno en serie, ilustrando que sólo este conjunto básico de
herramientas de Arena permite manejar aspectos interesantes y prácticos.
< En el capítulo 5 reemplazamos el modelo de reparación de automóviles de la tercera edi-
ción con una versión mejorada del modelo del centro de atención, semejante al de las dos
primeras ediciones. Sin embargo, lo estructuramos en tres etapas para poder impartir
grandes cantidades de conceptos más manejables.
< El capítulo 6 tiene la misma misión que el de la tercera edición (análisis estadísticos para
la terminación de sistemas), pero en él se usa el modelo mejorado de centro de atención
del capítulo 5.
< En los nuevos capítulos 7, 8, 9, 12 y 13 se cubre el mismo material que en la tercera edi-
ción, excepto por las actualizaciones.
< El capítulo 10 tiene una sección nueva, la 10.6, sobre integración en tiempo real, com-
partimiento de datos de simulación con otros dispositivos durante una ejecución.
< El capítulo 11 tiene una sección nueva, la 11.2.4, sobre el panel de proceso de flujo para
el modelado de cambio continuo.
< El apéndice B, acerca de los problemas del concurso, se ha reducido a una sola página y
la lista (creciente) de descripción de problemas se movió al sitio Web.
< Se actualizaron todos los materiales de apoyo del sitio Web (diapositivas y soluciones).
Como en cualquier trabajo como éste, existe una gran cantidad de personas e instituciones
que participaron en este libro en una gran cantidad de maneras. La primera y principal, Lynn
Barrett de Rockwell Automation, hizo que todo esto sucediera al leer una y otra vez (y después
componer) nuestros borradores semicultos, orquestando la composición y producción, recor-
dándonos de qué mes (y año) fue, así como tolerando nuestra lentitud y minuciosidad y nues-
tros peculiares hábitos personales de separación de sílabas mediante guiones; su esposo Doug
merece también nuestros agradecimientos por aguantar que ella nos aguantara a nosotros.
xxii Prefacio
¿Qué es la simulación?
La simulación se refiere a un gran conjunto de métodos y aplicaciones que buscan imitar el com-
portamiento de sistemas reales, generalmente en una computadora con un software apropiado.
De hecho, la “simulación” puede ser un término extremadamente general dado que se utiliza
en muchos campos, industrias y aplicaciones. En estos días, la simulación es más popular y
poderosa que nunca, ya que las computadoras y el software son mejores de los que nunca han
existido.
Este libro ofrece un tratamiento exhaustivo de la simulación en general y del software de
simulación Arena en particular. Cubre la idea general de la simulación y su lógica en los ca-
pítulos 1 y 2 (incluyendo hojas de cálculo para simular), y de Arena en los capítulos 3 a 9; sin
embargo, no es la intención de esta obra ser una referencia completa en todo lo que atañe a
Arena (eso es para lo que son los sistemas de ayuda en el software). En el capítulo 10 se muestra
cómo integrar Arena con archivos externos y otras aplicaciones, y se da un panorama general
de algunas de las capacidades avanzadas de Arena. En el capítulo 11 se presentan una modela-
ción continua y una combinada discreta/continua con Arena. Los capítulos 12 y 13 incluyen los
temas relacionados con la planeación e interpretación de los resultados de los experimentos de
simulación, así como la gestión de un proyecto de simulación. El apéndice A es un relato deta-
llado de un proyecto de simulación llevado a cabo por el periódico The Washington Post. En el
apéndice B se proporciona un vínculo con enunciados de problemas muy complejos sacados de
concursos recientes entre estudiantes sobre la modelación de Arena, realizados por el Instituto
de Ingenieros Industriales y Rockwell Automation (antes Systems Modeling). El apéndice C
ofrece una rápida revisión de los conceptos de probabilidad y estadística necesarios para la
simulación. El apéndice D describe las distribuciones de probabilidad de Arena y el apéndice E
proporciona las instrucciones de instalación del software. Después de leer este libro se deberá
tener la capacidad para modelar sistemas con Arena y realizar estudios de simulación efectivos
y exitosos.
Este capítulo trata de la noción general de la simulación. En la sección 1.1 se describen
algunas ideas generales acerca de cómo se pueden estudiar modelos de sistemas y se dan los
ejemplos donde ha sido útil la simulación. La sección 1.2 contiene información más específica
acerca de la simulación y su popularidad, menciona algunas cosas buenas (y una cosa mala)
de la simulación e intenta clasificar los diferentes tipos de simulaciones que la gente hace. En
la sección 1.3 se habla un poco de las opciones de software y, finalmente, en la sección 1.4 se
exponen los cambios que se han hecho en el transcurso del tiempo en cuanto a cómo y cuándo
se ha usado la simulación. Tras la lectura de este capítulo usted debe contar con una apreciación
de dónde encaja la simulación, las cosas que puede hacer y cómo Arena ayuda a hacerlas.
1.1 Modelación
La simulación, al igual que la mayoría de los métodos de análisis, implica sistemas y sus mo-
delos. Así que en esta sección se darán algunos ejemplos de modelos y se describirán opciones
para estudiarlos con el fin de aprender acerca del sistema correspondiente.
Capítulo 1
a desarrollar el modelo de simulación) proporciona una gran perspectiva sobre los cambios que
tienen que hacerse. Parte de esto se debe al hecho de que rara vez hay un individuo responsable
de entender cómo funciona todo un sistema. Hay expertos en diseño de máquinas, manejo de
materiales, procesos, etc., pero no en la operación cotidiana del sistema. Así que a medida que
lea, estará consciente de que la simulación es mucho más que sólo construir un modelo y reali-
zar un experimento estadístico. Hay más que conocer en cada paso de un proyecto de simula-
ción; además, las decisiones que se toman a lo largo del camino pueden afectar en gran medida
la importancia de sus hallazgos.
herido y su libertad para intentar ideas diversas con el modelo podría descubrir alternativas atrac-
tivas que de otra manera no podría probar con el sistema real.
Sin embargo, se deben construir modelos con cuidado y con el suficiente detalle, de tal ma-
nera que lo que se aprenda del modelo nunca1 sea diferente de lo que se hubiera aprendido del
sistema al jugar directamente con él. Esto se denomina validez del modelo y se hablará más de
ello en el capítulo 13.
1
Bueno, casi nunca.
¿Qué es la simulación?
2
Siempre se puede desarrollar un modelo simple (quizá simplista) de un sistema complicado, pero hay muchas
probabilidades de que no sea válido. Si se va más allá y se analiza, puede ser que dicho modelo obtenga respuestas agra-
dables, limpias y sencillas a las preguntas erróneas. A veces a esto se le llama error de tipo III: trabajar en el problema
equivocado (los estadísticos han reivindicado ya los errores de tipo I y II).
Capítulo 1
azar una vez, o ver el centro de distribución un día: con probabilidad se verá algo diferente la
próxima vez, aun si usted no cambia nada por sí mismo. En muchas simulaciones, conforme el
marco del tiempo se hace más largo (como meses en lugar de un día), la mayoría de los resulta-
dos promediados durante la ejecución tenderán a estabilizarse y hacerse menos variables, pero
puede ser difícil determinar cuán largo es “suficientemente largo” para que esto pase. Además,
el modelo o estudio podría dictar que la simulación se detenga en un punto en particular (por
ejemplo, un banco abre de 9 a 17 horas), así que es inapropiado ejecutarla durante más tiempo
para estabilizar el resultado.
Por lo tanto, se debe pensar con cuidado acerca del diseño y el análisis de los experimentos
de simulación para tomar en cuenta esta incertidumbre en los resultados, en especial si el marco
de tiempo apropiado para su modelo es relativamente corto. Se retomará esta idea varias veces
en el libro y se ilustrará el diseño estadístico y las herramientas de análisis apropiados, algunos
de los cuales están desarrollados en Arena, pero de otros tendrá que ocuparse usted mismo.
Aun cuando los resultados de la simulación pueden ser inciertos, se puede tratar, cuantificar
y reducir esta incertidumbre. Podría deshacerse por completo de dicha incertidumbre al hacer
muchas suposiciones demasiado simplificadas acerca del sistema, lo cual lo llevará a un modelo
agradable, sencillo, que producirá resultados agradables y no aleatorios. Sin embargo, por des-
gracia, es probable que este modelo demasiado simplificado no sea una representación válida
del sistema y el error debido a tal invalidez del modelo es imposible de medir o de reducir for-
malmente. Pero preferimos una respuesta aproximada al problema correcto que una respuesta
exacta al problema erróneo (¿recuerda el error de tipo III?).
entradas aleatorias —como un banco con clientes que llegan de forma aleatoria y que
requieren tiempos de servicio variados—. Un modelo puede tener tanto entradas deter-
minístas como aleatorias en diferentes componentes; qué elementos se modelan como
deterministas y cuáles como aleatorios son temas de realismo en el modelo en cuestión.
Arena maneja con facilidad entradas deterministas y estocásticas para modelos y pro-
porciona muchas distribuciones y procesos de probabilidad diferentes que se pueden
utilizar para representar entradas aleatorias. Puesto que por lo menos algunos elementos
de incertidumbre están presentes en la realidad, la mayoría de las ilustraciones incluyen
entradas aleatorias en alguna parte del modelo. Sin embargo, como se observó anterior-
mente, los modelos estocásticos producen resultados inciertos, lo cual se debe considerar
con cuidado al diseñar e interpretar las ejecuciones del proyecto.
1.3.1 A mano
Al principio, las personas en realidad hacían las simulaciones a mano (se mostrará sólo una en
la sección 2.4).
Por ejemplo, alrededor de 1733, Georges Louis Leclerc (quien después fue invitado a entrar en
la nobleza, debido sin duda a su destreza en la simulación, como Conte de Buffon) describió un
experimento para estimar el valor de π. Si se lanza una aguja de longitud l en una mesa pintada
$POTJHBMBBHVKBZQJOUFMBT
(FUUIFOFFEMFBOEQBJOU
MJOFBTFOMBNFTB
UIFMJOFTPOUIFUBCMF
%FDJEBDVÃOUBTWFDFTO O
EFTFBMBO[BSMBBHVKB
1POHBFMDPOUBEPSFO
4FUBDPVOUFSUP
)BHBFTUPTQBTPTOWFDFT
-BODFMBBHVKBiBMFBUPSJBNFOUFu
-BODFMBBHVKB
TPCSFMBNFTB
POUPUIFUBCMF
4JÊTUBDSV[BVOBEFMBTMÎOFBT
*GJUDSPTTFTPOFPGUIFMJOFT
BÒBEBBMDPOUBEPS 4JOP
BEEUPUIFDPVOUFS *GJU
DSV[BMBMÎOFB
OPNVFWBFM
EPFTOhUDSPTTBMJOF
MFBWF
DPOUBEPS
UIFDPVOUFSBMPOF
$BMDVMFMBQSPQPSDJÓOEFMBTWF
$BMDZVO Q QPG
DFTRVFMBBHVKBDSVDFVOBMÎOFB
UJNFTUIFOFFEMFDSPTTFEBMJOF
QGJOBMWBMVFPGUIFDPVOUFS
QWBMPSGJOBMEFMDPOUBEPS
OO
%BEPRVF Q
1SPWJEFEUIBUQ
M
Ĭ ĬQPS M
FTUJNBUF
FTUJNBS
QE
QE
con líneas paralelas espaciadas una distancia d entre ellas (d debe ser ≥ que l ), la aguja cruzará
una línea con probabilidad p = 2l /(π d ). La figura 1-1 muestra un experimento de simulación para
estimar el valor de π. (No intente esto en casa, al menos no con una aguja grande.)
Aunque este experimento puede parecer sencillo (y posiblemente tonto), tiene algunos as-
pectos comunes a la mayoría de las simulaciones:
< El propósito es estimar algo (en este caso, π) cuyo valor sería difícil de calcular con exac-
titud (tal vez en 1733 esto era cierto).
< El estimado que se obtiene al final no será con exactitud el correcto; esto es, tiene algún
error asociado con él, y podría ser bueno tener una idea de cuán grande es probable que
sea el error.
< Parece intuitivo que cuantos más lanzamientos se hagan (esto es, entre más grande sea
n), más probabilidades habrán de que el error sea más pequeño y, por lo tanto, es más
probable que el estimado sea mejor.
< De hecho, podría hacer un experimento secuencial y sólo seguir lanzando hasta que el
posible error sea tan pequeño que pueda vivir con él, en lugar de decidir de antemano el
número n de lanzamientos.
< Podría ser capaz de reducir el error sin aumentar el número de lanzamientos si invierte
un poco de trabajo por anticipado. Suelde una segunda aguja a la primera de tal mane-
ra que se crucen en ángulos rectos por sus puntos medios; dicho artefacto se llama cruz
de Buffon. Deje las líneas de la mesa. En cada lanzamiento registre de forma separada
si cada aguja cruza una línea (puede ser que ambas lo hagan, que ninguna lo haga o
que sólo una, pero no la otra, la cruce) y obtenga dos estimados diferentes de π. Es
intuitivo (y cierto) que si una aguja cruza una línea se correlaciona negativamente con
el hecho de que la otra lo haga o no lo haga, así que los dos estimados de π estarán co-
rrelacionados negativamente con el otro. El promedio de los dos estimados también es
un estimado imparcial de π, pero tendrá menos varianza que un estimado con una sola
aguja con el mismo número de lanzamientos puesto que es probable que si un estimado
es alto, el otro sea bajo. (Ésta es una analogía física de lo que se llama técnica de reduc-
ción de varianza, en específico variaciones antitéticas, y se analiza en la sección 12.4.2.
Parece una clase de trampa o estafa, pero realmente es un juego justo.)
Se volverá a este tipo de temas conforme se hable de simulaciones más interesantes y útiles.
(Para más información acerca del problema de la aguja de Buffon, así como de otras curiosida-
des históricas igualmente interesantes, consulte Morgan, 1984.)
En las décadas de 1920 y 1930, los estadísticos comenzaron a usar máquinas y tablas de
números aleatorios en experimentos numéricos para ayudarse a desarrollar y entender la teoría
estadística. Por ejemplo, Walter A. Shewhart (el pionero del control de calidad) hizo experi-
mentos numéricos al sacar chips numerados de un recipiente para estudiar las primeras gráficas
de control. W.S. Gossett, un empleado de Guinness Brewery, hizo experimentos similares de
muestreo numérico para obtener una perspectiva en cuanto a lo que sucedía con la estadística
matemática. (Para proteger su empleo en Guinness, publicó su investigación bajo el seudónimo
“Student” y también desarrolló la distribución t que se usa mucho en inferencia estadística.)
Durante muchos años ingenieros, físicos y matemáticos han usado varios tipos de ideas de si-
mulación a mano en una gran variedad de problemas.
10 Capítulo 1
plejos de decisión o datos de acceso desde una aplicación externa, se pueden escribir partes de
su modelo en un lenguaje de procesamiento como Visual Basic o C/C++. Todo esto, a pesar de
cuán alto o bajo quiera usted ir en la jerarquía, tiene lugar en la misma interfaz gráfica consis-
tente del usuario
De hecho, los módulos de Arena están compuestos por componentes SIMAN; usted puede
crear sus propios módulos y reunirlos en sus propias plantillas para varias clases de sistemas. Por
ejemplo, Rockwell Automation (antes Systems Modeling) ha construido plantillas para modela-
ción general (la plantilla de Arena, que es el núcleo principal de este libro), empaque de alta veloci-
dad, centros de contacto y otras industrias. Otras personas han desarrollado plantillas para su em-
presa en industrias tan diversas como la minera, la fabricación de automóviles, la comida rápida y
la administración de recursos forestales. De esta forma, no tiene por qué elegir entre la flexibilidad
de la modelación y la facilidad de uso. Aunque este libro de texto se enfoca en la modelación con
la plantilla de Arena, usted puede probar a crear sus propios módulos en el capítulo 10.
Más aún, Arena incluye animación dinámica en el mismo ambiente de trabajo. También
proporciona apoyo integrado y gráficas para algunos de los temas de diseño y análisis estadís-
ticos que son parte y componente de un buen estudio de simulación.
500 000 dólares por día. Al equipo se le dijo: “encuentra el problema y resuélvelo”. En unas tres
semanas se desarrolló y usó una simulación para identificar el problema, que resultó no haber
estado en la lista inicial de sospechosos. Al final la línea se modificó y produjo de acuerdo con
las especificaciones; por desgracia, para ese momento la competencia estaba produciendo vehí-
culos similares y la producción adicional ya no fue necesaria. Irónicamente, se había usado un
modelo de simulación durante el diseño de la línea de ensamble para determinar su viabilidad.
Desafortunadamente, muchos de los procesos eran nuevos y el área de ingeniería había depen-
dido de los vendedores de equipo para que les proporcionaran estimados de fallas y razón de
procesamiento de trabajos (Throughput). Como sucede con frecuencia, los vendedores fueron
demasiado optimistas en sus estimados. Si el equipo de diseño original hubiera usado la simula-
ción para llevar a cabo un buen análisis de sensibilidad en estas cifras cuestionables, el problema
se habría descubierto y resuelto bien antes de la implementación.
Durante este tiempo la simulación encontró un hogar en la academia como una parte nor-
mal del currículo de la ingeniería industrial y la investigación de operaciones. Su uso creciente
en la industria obligó a las universidades a difundirla ampliamente. Al mismo tiempo, la simu-
lación comenzó a llegar a los programas cuantitativos de negocios, ampliando el número y tipo
de estudiantes e investigadores expuestos a su potencial.
1.4.4 El presente
La simulación en realidad comenzó a madurar durante la década de 1990. Muchas empresas
pequeñas la adoptaron y se comenzó a ver su uso en las primeras etapas de los proyectos, en
donde podía tener el mayor impacto. Una mejor animación, la mayor facilidad de uso, las com-
putadoras más veloces, la fácil integración con otros paquetes y el surgimiento de simuladores
ayudaron a que la simulación se convirtiera en una herramienta normal en muchas empresas.
Aunque la mayoría de los administradores admitirán de buena gana que la simulación puede
agregar valor a sus empresas, hasta ahora es cuando se ha convertido en una herramienta nor-
mal que reside en las computadoras de todos. La forma en que se usa la simulación también
está cambiando: se emplea más temprano en la fase de diseño y a menudo se actualiza conforme
se hacen los cambios en los sistemas operativos. Esto proporciona un modelo de simulación
vivo que se puede usar en muchos análisis de sistemas con muy poca antelación. La simulación
también ha invadido la industria de servicios en donde se aplica en muchas áreas que no son
tradicionales.
Los obstáculos principales que impiden que la simulación se convierta en una herramienta
bien utilizada y aceptada de manera universal son el tiempo de desarrollo del modelo y las habi-
14 Capítulo 1
lidades de modelado que se requieren para desarrollar una simulación exitosa. ¡Ésas son quizá
las razones por las que usted está leyendo este libro!
1.4.5 El futuro
La razón de cambio en la simulación se ha acelerado en años recientes, y hay razones para
creer que continuará con su rápido crecimiento y cruzará los puentes para ser aceptada como la
corriente dominante. El software de simulación ha sacado ventaja de los nuevos sistemas ope-
rativos para proporcionar una mayor facilidad de uso, en particular para la persona que lo usa
por primera vez. Esta tendencia debe continuar si la simulación se tiene que convertir en una
herramienta de vanguardia que resida en cada computadora de análisis de sistemas. Los nuevos
sistemas operativos también permitieron una mayor integración de la simulación con otros
paquetes (como hojas de cálculo, bases de datos y procesadores de texto). Ahora es posible
prever la integración completa de la simulación con otros paquetes de software que recopilan,
almacenan y analizan datos del sistema de interfaz junto con software que ayuda a controlar el
sistema del compilador.
La Internet y los intranets tienen un gran impacto en la manera en que las organizaciones
llevan a cabo sus negocios. El intercambio de información en tiempo real no sólo es posible,
sino que se ha hecho obligatorio. Las herramientas de simulación se están desarrollando para
apoyar la distribución de la construcción del modelo, el proceso de distribución y el análisis
remoto de los resultados. Pronto estará disponible un conjunto de herramientas en toda una
empresa que proporcione a la totalidad de los empleados de la organización la capacidad de
obtener respuestas a preguntas críticas y de rutina.
Con la finalidad de facilitar el uso de la simulación a un mayor número de personas, se
verán productos más verticales dirigidos a mercados muy específicos. Esto permitirá que los
analistas construyan simulaciones fácilmente, al usar construcciones de modelado diseñadas
para su industria o empresa con terminología que se relaciona directamente con su medio
ambiente. Éstas pueden ser herramientas muy especializadas diseñadas para medio ambien-
tes muy específicos, pero que deberían tener la capacidad de modelar cualquier actividad del
sistema que sea única para cada proyecto de simulación. Algunos de esos productos están hoy
en día en el mercado en áreas de aplicación, tales como comunicaciones, semiconductores,
centros de contacto y reingeniería de procesos de negocio.
Los proyectos de simulación en la actualidad se concentran en el diseño o rediseño de sis-
temas complejos. A menudo deben tratar con temas complejos de control de sistemas, lo cual
puede conducir al desarrollo de una nueva lógica de control de sistemas que se pruebe usando
la simulación desarrollada. El siguiente paso lógico es el uso de esa misma simulación para con-
trolar el sistema real (Wysk, Smith, Sturrock, Ramaswamy, Smith y Joshi; 1994). Este enfoque
requiere que el modelo de simulación permanezca actual, pero también permite una prueba
fácil de nuevos controles del sistema conforme el sistema o los productos cambian en el tiempo.
A medida que se progrese a este siguiente paso lógico, las simulaciones no serán ya desechables
ni se usarán una sola vez, sino que se convertirán en parte esencial de la operación del sistema
en curso.
Con los rápidos avances en las computadoras y el software es muy difícil predecir las si-
mulaciones de un futuro lejano, pero aun ahora se observa el desarrollo y la implementación
de características tales como el análisis estadístico automático, el software que recomienda
cambios en el sistema, las simulaciones totalmente integradas en el software operativo del
sistema e incluso la realidad virtual.
CAPÍTULO 2
En este capítulo se introducen algunas ideas, métodos y temas subyacentes a la simulación an-
tes de entrar en el software Arena propiamente dicho que se ve en el capítulo 3 y los posteriores.
Estos conceptos son los mismos en cualquier tipo de software de simulación y la familiaridad
con ellos es esencial para entender cómo simula Arena un modelo ya construido.
Esto se hace principalmente a través de un ejemplo sencillo que se describe en la sección
2.1. En la sección 2.2 se exploran algunas opciones para tratar con el modelo de ejemplo. En la
sección 2.3 se describen las varias partes de un modelo de simulación y en la sección 2.4 se lleva
a cabo la simulación (a mano), al describir la organización y acción fundamentales. Después de
eso se contrastan dos diferentes enfoques de modelación de simulaciones en la sección 2.5 y el
tema de la aleatoriedad tanto en las entradas como en los resultados se introduce en la sección
2.6. En la sección 2.7 se considera el uso de hojas de cálculo para la simulación con un modelo
estático y con uno dinámico sencillo. Por último, en la sección 2.8 se resume y analiza todo lo que
se incluye en un proyecto de simulación, aunque esto se retoma más a fondo en el capítulo 13.
Al final de este capítulo se entenderá la lógica, la estructura, los componentes y la adminis-
tración fundamentales de un proyecto de modelación de simulación. Todo esto subyace a Arena
y a los modelos más ricos que se desarrollarán con él después de leer los capítulos siguientes.
2.1 Un ejemplo
En esta sección se describe el ejemplo del sistema y lo que se desearía saber acerca de su com-
portamiento y ejecución.
2.1.1 El sistema
Puesto que muchos modelos de simulación incluyen líneas de espera o colas como elementos
fundamentales, se comenzará con un caso muy sencillo de tal modelo que representa una parte
de una instalación de manufactura. Las partes “en blanco” llegan a un centro de perforación,
se procesan en una sola perforadora y después salen (véase la figura 2-1). Si una parte llega y
encuentra la perforadora desocupada, su proceso en la perforadora comienza de inmediato;
de lo contrario, espera en una cola de primeras entradas-primeras salidas (FIFO). Ésta es la
estructura lógica del modelo.
$FOUSPEFQFSGPSBDJÓO
1FSGPSBEPSB
-MFHBEB 4BMJEB
EFQBSUFT EFQBSUFT
FOCMBODP UFSNJOBEBT
$PMB
1BSUFFO
QSPDFTP
También se deben especificar los aspectos numéricos, incluyendo cómo comienza y se de-
tiene la simulación. Primero se eligen las unidades “base” subyacentes con las que se medirá
el tiempo; aquí se usarán minutos para todas las mediciones. Es obvio que no importa qué
unidades de tiempo sean, así que se escoge la más apropiada, familiar y conveniente para su
aplicación.1 Se pueden expresar las cantidades de tiempo de entrada si es habitual o conveniente
en diferentes unidades, como minutos para tiempos de servicio medios y horas para tiempos de
funcionamiento de máquina medios. Sin embargo, para aritmética y cálculos todos los tiempos
se deben convertir a las unidades de tiempo base si es que aún no están así. Arena permite ex-
presar los tiempos de entradas en unidades diferentes, aunque también se deben manifestar las
unidades de tiempo base a las que se convertirán todos los tiempos durante la ejecución de la
simulación y en las que se reportarán todos los resultados con base en el tiempo.
El sistema comienza a los 0 minutos con ninguna parte presente y la perforadora desocupa-
da. Esta suposición de que está vacía —y desocupada— sería realista si el sistema comienza de
nuevo cada mañana, pero podría no ser tan buena para el modelo con una situación inicial que
simule una operación en proceso.
Las duraciones de los tiempos que harán el movimiento de la simulación están en la tabla 2-
1. El número de la parte (secuencial) está en la primera columna, la segunda columna contiene
el tiempo de llegada de cada parte, la tercera columna da el tiempo entre la llegada de una parte
y la de la parte siguiente (llamado tiempo entre llegadas), y el tiempo de servicio (necesario para
procesar en la perforadora, sin contar ningún gasto en tiempo esperando en la cola) está en la
última columna. Todos los tiempos se expresan en minutos. Quizá usted se está preguntando de
dónde provienen todos esos números, pero no se preocupe por eso en este momento y sólo su-
ponga que se observaron en el centro de perforación o que se inventaron de forma descarada.
Tabla 2-1. Tiempos de llegadas, entre llegadas y de servicio de las partes (en minutos).
1
No sólo se debe ser sensato al elegir las unidades de tiempo base (por ejemplo, para una simulación de 20 años,
no elija segundos como sus unidades base, y para una simulación de dos minutos, no mida el tiempo en días), sino que
también se deben escoger unidades que eviten valores de tiempo tanto extremadamente grandes como extremadamente
pequeños en el mismo modelo, ya que aun con la aritmética de doble precisión de Arena la computadora podría tener
problema con el error de redondeo.
Conceptos principales de simulación 17
∑ WQ i
i=1
N
(Nótese que puesto que la parte 1 llega en el tiempo 0 para encontrar la perforadora
desocupada, de seguro WQ1 = 0 y N ≥ 1, de tal manera que no hay que preocuparse
por dividirlo entre cero.) Por lo general a esto se le llama estadística de tiempo discreto
(o parámetro discreto) puesto que se refiere a las cifras, en el caso de los tiempos de es-
pera WQ1, WQ2, . . ., para lo que hay una primera, segunda… observaciones naturales;
en Arena éstas se llaman estadísticas cuenta (Tally) puesto que sus valores “coinciden”
cuando se les observa (al usar una característica del lenguaje de simulación SIMAN
esencial llamada Cuenta). Desde un punto de vista del desempeño, lo poco es bueno.
< El tiempo de espera máximo en una cola de partes que entran a servicio en la perforadora
durante la simulación. Ésta es la medida del peor de los casos, la cual podría ser de inte-
rés al brindar garantías de servicio a los clientes. Lo poco es bueno.
< El promedio del tiempo que las partes esperan en la cola (sin contar cualquier parte en ser-
vicio en la perforadora). Por “promedio del tiempo” se entiende el promedio ponderado
de las longitudes posibles de la cola (0, 1, 2…) ponderadas por la proporción de tiempo
durante la ejecución que la cola tenía en esa longitud. Sea Q(t) el número de partes en la
cola en un instante de tiempo t, esta longitud de cola en el promedio de tiempo es el área
total debajo de la curva Q(t), dividida entre la longitud de la ejecución, 20. En términos
de cálculo integral, esto es
20
∫Q (t)dt
0
20
Dichas estadísticas de tiempo continuo son comunes en la simulación, que indica cuán
larga es una cola (en promedio), lo cual debiera ser de interés para destinar espacio en
el suelo.
18 Capítulo 2
< El número máximo de partes que estuvieron esperando en la cola. Esto podría ser una me-
jor indicación de cuánto espacio se requiere en el suelo que el promedio del tiempo si lo
que se desea es estar razonablemente seguro de tener espacio todo el tiempo. Ésta es otra
medida del peor de los casos, y el más pequeño es el mejor.
< El tiempo total promedio y máximo en el sistema de las partes que terminan de procesarse
en la perforadora y se van. También llamado tiempo del ciclo, éste es el tiempo que trans-
curre entre la llegada de la parte y su partida, así que es la suma del tiempo de espera de
las partes en la cola y su tiempo de servicio en la perforadora. Éste es un tipo de tiempo
de respuesta tras llegada, así que menos es mejor.
< El uso de la perforadora se define como la proporción de tiempo en que está ocupada
durante la simulación. Piense en ello como en otra estadística de tiempo continuo, pero
de la función “ocupada”.
∫B (t)dt
0
20
Los usos del recurso son de interés obvio en muchas simulaciones, pero es difícil decir si
“desea” que sean altos (cerca de 1) o bajos (cerca de 0). Alto es bueno dado que indica
poca capacidad de exceso, pero también puede ser malo porque puede significar una
gran congestión en la forma de largas colas y un lento desempeño en el procesamiento
de trabajos (Throughput).
Por lo general hay muchas medidas de desempeño de la producción y quizá sea una buena
idea observar muchas cosas en una simulación puesto que siempre se pueden ignorar cosas que
se tienen pero nunca se pueden observar cosas que no se tienen; además, a veces podría encon-
trarse una sorpresa. El único inconveniente es que recopilar cifras superfluas puede retardar la
ejecución de la simulación.
menos en promedio, lo cual significa que el sistema tiene una oportunidad de operar de una
manera estable en un plazo largo y no “estallar”. Si estos promedios fueran exactamente lo
que sucedía con cada parte (sin ningún tipo de variación) entonces nunca habría una cola y
todos los tiempos de espera en ella serían de cero; un pensamiento feliz, sin duda. Sin impor-
tar lo feliz que pueda ser este pensamiento, es seguro que sea erróneo puesto que los datos
muestran con claridad que sí hay variación entre las llegadas y los tiempos de servicio, lo cual
podría crear a veces una cola, por ejemplo, si sucedieran algunos pequeños tiempos entre
llegadas durante un periodo cuando también sucedieran algunos tiempos de servicio largos.
Hay que suponer, por otra parte, que los promedios en los datos de entrada en la tabla 2-1
revelarán el tiempo promedio entre llegadas más pequeño que el tiempo de servicio promedio.
Si esta situación persistiera, en promedio las partes podrían estar llegando más rápido que en
lo que pudieran prestarles el servicio, lo cual implica una grave congestión (por lo menos des-
pués de un tiempo, quizá más largo que la ejecución de 20 minutos que se planeó). De hecho, el
sistema estallará en la ejecución larga; un mal pensamiento.
La verdad, como siempre se da en la probabilidad, estará entre ambos extremos. Queda
claro que conjeturar tiene sus límites.
sólo donde μA es el valor esperado de la distribución del tiempo entre llegadas y μS es el valor
esperado de la distribución del tiempo del servicio (suponiendo que μA > μS para que la cola no
estalle). Así que una idea inmediata es usar los datos para estimar μA y μS, y luego plasmar estos
estimados en la fórmula; para estos datos se obtiene 3.462/(4.08 − 3.46) = 19.31 minutos.
Tal enfoque a veces puede dar una aproximación razonable del orden de magnitud, que po-
dría facilitar las comparaciones; pero también hay problemas (véase el ejercicio 2-6):
< Los estimados de μA y μS no son exactos, así que también habrá error en el resultado.
< Los supuestos del tiempo exponencial entre llegadas y las distribuciones del tiempo del
servicio son esenciales para derivar la fórmula anterior, y es probable que no se satisfa-
gan estos supuestos. Esto invita a preguntarse acerca de la validez de la fórmula. Aun-
20 Capítulo 2
que hay versiones más sofisticadas para modelos de colas más generales, siempre habrá
supuestos de qué preocuparse.
< La fórmula es para un desempeño de larga ejecución y no sólo para el periodo de 20
minutos que se desea. Esto es típico en la mayor parte (pero no en toda) de la teoría de
colas.
< La fórmula no proporciona información de la variabilidad natural en el sistema. Esto no
sólo es una dificultad en el análisis, sino que también podría ser de un interés inherente
por sí mismo, como en la variabilidad de la producción. (A veces es posible, sin embargo,
encontrar otras fórmulas para medir la variabilidad.)
Muchas personas sienten que la teoría de colas puede demostrar su valor como una aproxi-
mación de primer corte para tener una idea de dónde están las cosas y proporcionar una guía
con respecto a qué tipos de simulaciones podrían ser apropiadas en el siguiente paso del pro-
yecto. Se está de acuerdo, pero se le exhorta a mantener en mente los problemas listados con
anterioridad y, en consecuencia, suavizar sus interpretaciones.
2.3.1 Entidades
La mayoría de las simulaciones incluyen “jugadores” llamados entidades que se mueven alrede-
dor, cambian de estatus, afectan y son afectados por otras entidades y el estado del sistema, y
afectan las medidas de desempeño de los resultados. Las entidades son objetos dinámicos en la
simulación, por lo general son creados, se mueven alrededor durante un tiempo y después son
desechados conforme se van. Sin embargo, es posible tener entidades que nunca se van sino que
se mantienen circulando en el sistema. No obstante, todas las entidades deben ser creadas, ya
sea por usted o de forma automática por el software.
Las entidades del ejemplo son las partes a procesar. Se crean cuando llegan, se mueven a
través de la cola (si es necesario), se les da servicio con la perforadora y se les desecha conforme
se van. Aun cuando sólo hay un tipo de entidad en el ejemplo, puede haber muchas “copias” o
realizaciones independientes en existencia al mismo tiempo, así como muchas partes indepen-
dientes de este tipo en el sistema real en un tiempo dado.
La mayoría de las entidades representan cosas “reales” en una simulación. Usted puede
tener muchos tipos diferentes de entidades y muchas realizaciones de cada tipo de entidad
existente en el modelo en un tiempo dado. Por ejemplo, podría tener varios tipos diferentes de
partes, que quizá requieran diferentes procesamientos y asignaciones de ruta y que tengan di-
Conceptos principales de simulación 21
ferente prioridad; más aún, podría haber diversas realizaciones de cada tipo de parte flotando
en el modelo en un momento dado.
Sin embargo, existen situaciones en donde pueden aparecer entidades “falsas” (o “lógicas”)
no correspondientes a nada tangible para hacerse cargo de ciertas operaciones de modelado.
Por ejemplo, una manera de modelar fallas mecánicas es mediante la creación de un “demo-
nio de falla” (véase la figura 2-2) que esté escondido durante el tiempo de funcionamiento de
la máquina y salga corriendo y patee la máquina cuando se supone que se interrumpe su fun-
ción, se pose triunfante sobre ella hasta que se le repare y después corra a refugiarse de nuevo
y comience otro periodo al acecho que represente el siguiente tiempo de funcionamiento de
la máquina. Un ejemplo similar es un “ángel de pausa” que llega con periodicidad y toma un
servidor fuera de servicio. (Para ambos ejemplos Arena tiene construcciones de modelado ya
incluidas que no requieren la creación de entidades falsas.)
Comprender qué son las entidades es la primera cosa que usted necesita hacer en la mode-
lación de un sistema.
2.3.2 Atributos
Para individualizar las entidades, hay que añadirles atributos. Un atributo es una característica
común de todas las entidades, pero con un valor específico que puede diferir entre las entida-
des. Por ejemplo, nuestras entidades de partes tienen atributos llamados Fecha límite,
Prioridad y Color para indicar estas características en cada unidad individual. A usted le
concierne descubrir qué atributos requieren sus entidades, nombrarlas, asignarles valores, cam-
biarlas conforme convenga y usarlas cuando sea el momento (todo es parte del modelado).
Lo más importante que hay que recordar acerca de los atributos es que sus valores están
unidos a entidades específicas. Por lo general, el mismo atributo tendrá diferentes valores para
diferentes entidades, así como diferentes partes tienen diferentes fechas límite, prioridades y
códigos de color. Un atributo puede estar añadido a una entidad como una etiqueta, la cual
puede diferir para caracterizar a las entidades de manera individual. Una analogía a la progra-
mación por computadora tradicional es que los atributos son variables locales a cada entidad
individual. Arena mantiene la pista de algunos atributos de forma automática, pero se puede
necesitar definir, asignar valores, cambiar y usar atributos suyos.
2.3.4 Recursos
Con frecuencia las entidades compiten entre ellas por el servicio de los recursos que represen-
tan cosas, como personal, equipo o espacio en el área de almacenaje de tamaño limitado. Una
entidad se aprovecha de (unidades de) un recurso cuando está disponible y lo(s) libera cuando
termina. Es mejor pensar en el recurso como una donación a la entidad más que pensar que a
la entidad se le asigna el recurso, puesto que una entidad (como una parte) podría necesitar un
servicio simultáneo de múltiples recursos (como una máquina y una persona).
Un recurso puede representar un grupo de varios servidores individuales, cada uno de los
cuales se denomina una unidad de ese recurso. Esto es muy útil para el modelo; por ejemplo,
varios agentes “paralelos” idénticos en una ventanilla de boletos en una aerolínea. El número
de unidades disponibles de un recurso puede cambiarse durante la ejecución de la simulación
para representar agentes yendo a un descanso o abriendo estaciones si las cosas se complican.
Si un recurso tiene unidades múltiples o un número variable de unidades, se debe generalizar la
definición de la sección 2.1.2 del uso de un recurso para que sea el tiempo promedio del número
de unidades del recurso que está siendo ocupado, dividido entre el número promedio de unida-
des del recurso que están disponibles. En el ejemplo sólo hay una perforadora, así que el recurso
tiene una sola unidad disponible todo el tiempo.
2.3.5 Colas
Cuando una entidad no puede seguir adelante, quizá porque necesita aprovechar una unidad
de un recurso que está inmovilizada por otra entidad, se requiere un lugar para esperar, que es
la cola. En Arena, las colas tienen nombres y pueden tener también capacidades de represen-
tación; por ejemplo, el espacio de suelo limitado para un amortiguador. Usted deberá decidir
cómo manejar una entidad que llega a una cola que ya está llena.
Conceptos principales de simulación 23
2.3.7 Eventos
Ahora vayamos al funcionamiento de las cosas cuando se ejecuta el modelo. Básicamente todo
está centrado alrededor de los eventos. Un evento es algo que sucede en un instante de tiempo
(simulado) que puede cambiar atributos, variables o acumuladores estadísticos. En el ejemplo
existen tres tipos de eventos:
< Llegada: Una nueva parte entra en el sistema.
< Salida: Una parte termina su servicio en la perforadora y deja el sistema.
< Fin: La simulación se detiene a los 20 minutos de tiempo. (Podría parecer más artificial
designar esto como un evento, pero con certeza cambia las cosas, y ésta es una manera
de detener una simulación.)
Además de los eventos anteriores, debe haber un inicio para establecer las cosas. Después se
explicará la lógica de cada evento con más detalle.
Otras cosas suceden en el modelo ejemplar, pero no necesitan ser eventos separados.
Así, las partes dejan la cola y comienzan su servicio en la perforadora, lo cual cambia el
sistema y sólo sucede debido a que existe una salida de alguna otra entidad, lo cual cons-
tituye un evento.
Para ejecutarse, una simulación debe mantener el rastro de los eventos que se supone su-
cedan en el futuro (simulado). En Arena, esta información se almacena en un calendario de
eventos. No se entrará en detalles de la estructura de datos del calendario de eventos, pero aquí
está la idea: cuando la lógica de la simulación lo exige, un registro de información para un
evento futuro se coloca en el calendario de eventos. Dicho registro contiene la identificación
de la entidad involucrada y el tiempo y tipo del evento. Arena coloca cada evento programado
24 Capítulo 2
en el calendario de tal manera que el siguiente (más próximo) evento está siempre al inicio del
calendario (el nuevo registro de eventos se clasifica en el calendario en orden ascendente de los
tiempos de evento). Cuando llega el momento de ejecutar el siguiente evento, el registro de la
parte superior se saca del calendario y la información de este registro se usa para ejecutar la
lógica apropiada, parte de la cual podría ser colocar uno o más registros de eventos nuevos en
el calendario. Es posible que en un tiempo determinado no tenga sentido tener algún evento
programado (en el modelo, si la perforadora está desocupada, no se desea programar un evento
de salida), en cuyo caso no hay un registro para ese evento específico en el calendario, así que
no puede suceder después. Aunque este modelo no lo requiere, también es posible tener pro-
gramados varios eventos del mismo tipo en el calendario, para diferentes tiempos y diferentes
entidades.
En un modelo de evento discreto las variables que describen el sistema no cambian entre
los eventos sucesivos. La mayor parte del trabajo en la simulación dirigida por eventos incluye
obtener el derecho lógico de lo que sucede con cada tipo de evento. Como se verá más adelante,
la modelación con Arena en general le evita definir esta lógica de eventos detallada de forma
explícita, aunque lo puede hacer si lo que desea es representar algo muy peculiar para su mode-
lo, el cual Arena no puede manejar de manera directa.
(así como se hará a los 20 minutos) o si debe detenerse cuando algo específico suceda (por
ejemplo, tan pronto como se produzcan 100 partes). Es importante pensar en esto y hacer
suposiciones consistentes con lo que se esté modelando; las decisiones pueden tener un gran
efecto en sus resultados como cosas tan obvias como valores de parámetros de entrada
(como medias de tiempo entre llegadas, varianzas de tiempo de servicio y el número de má-
quinas).
Se debería hacer algo específico (y consciente) para detener la simulación con Arena, ya
que en muchas situaciones tomar todas las omisiones causará que su simulación se ejecute por
siempre (o hasta que uno se canse de esperar y la destruya, lo que pase primero).
Después de cada evento (excepto el evento final) se retira el registro de la parte de arriba del
calendario del evento, indicando qué evento sucederá después y en qué momento. El reloj de
simulación se avanza a ese momento y se lleva a cabo la lógica apropiada.
No. t evento Q(t) B(t) (En cola) En servicio P N ∑WQ WQ* ∑TS TS* ∫Q Q* ∫B [Entidad No.,Tiempo,Tipo]
- 0.00 Inicio 0 0 () - 0 0 0.00 0.00 0.00 0.00 0.00 0 0.00 [1, 0.00, Lleg]
[-, 20.00, Final]
1 0.00 Lleg 0 1 () 0.00 0 1 0.00 0.00 0.00 0.00 0.00 0 0.00 [2, 1.73, Lleg]
[1, 2.90, Sal]
[-, 20.00, Final]
2 1.73 Lleg 1 1 (1.73) 0.00 0 1 0.00 0.00 0.00 0.00 0.00 1 1.73 [1, 2.90, Sal]
[3, 3.08, Lleg]
[-, 20.00, Final]
1 2.90 Sal 0 1 () 1.73 1 2 1.17 1.17 2.90 2.90 1.17 1 2.90 [3, 3.08, Lleg]
[2, 4.66, Sal]
[-, 20.00, Final]
3 3.08 Lleg 1 1 (3.08) 1.73 1 2 1.17 1.17 2.90 2.90 1.17 1 3.08 [4, 3.79, Lleg]
[2, 4.66, Sal]
[-, 20.00, Final]
4 3.79 Lleg 2 1 (3.79, 3.08) 1.73 1 2 1.17 1.17 2.90 2.90 1.88 2 3.79 [5, 4.41, Lleg]
[2, 4.66, Sal]
[-, 20.00, Final]
5 4.41 Lleg 3 1 (4.41, 3.79, 3.08) 1.73 1 2 1.17 1.17 2.90 2.90 3.12 3 4.41 [2, 4.66, Sal]
[6, 18.69, Lleg]
[-, 20.00, Final]
2 4.66 Sal 2 1 (4.41, 3.79) 3.08 2 3 2.75 1.58 5.83 2.93 3.87 3 4.66 [3, 8.05, Sal]
[6, 18.69, Lleg]
[-, 20.00, Final]
3 8.05 Sal 1 1 (4.41) 3.79 3 4 7.01 4.26 10.80 4.97 10.65 3 8.05 [4, 12.57, Sal]
[6, 18.69, Lleg]
[-, 20.00, Final]
4 12.57 Sal 0 1 () 4.41 4 5 15.17 8.16 19.58 8.78 15.17 3 12.57 [5, 17.03, Sal]
[6, 18.69, Lleg]
[-, 20.00, Final]
5 17.03 Sal 0 0 () - 5 5 15.17 8.16 32.20 12.62 15.17 3 17.03 [6, 18.69, Lleg]
[-, 20.00, Final]
6 18.69 Lleg 0 1 () 18.69 5 6 15.17 8.16 32.20 12.62 15.17 3 17.03 [7, 19.39, Lleg]
[-, 20.00, Final]
[6, 23.05, Sal]
7 19.39 Lleg 1 1 (19.39) 18.69 5 6 15.17 8.16 32.20 12.62 15.17 3 17.73 [-, 20.00, Final]
[6, 23.05, Lleg]
[8, 34.91, Sal]
- 20.00 Final 1 1 (19.39) 18.69 5 6 15.17 8.16 32.20 12.62 15.78 3 18.34 [6, 23.05, Sal]
[8, 34.91, Lleg]
Conceptos principales de simulación 27
28 Capítulo 2
número de espera 3
0
0 5 10 15 20
número ocupado
Perforadora:
2
1
0
0 5 10 15 20
Tiempo (minutos)
< Entidad 2, t = 1.73, Lleg: La llegada de la siguiente parte (tercera) se programa al crear
una entidad de la parte tres, colocando su tiempo de llegada en el tiempo actual (1.73)
más su tiempo entre llegadas (1.35, de la tabla 2-1), y colocándolo en el calendario de
eventos, que guarda la llegada de esta parte en el tiempo 1.73 + 1.35 = 3.08. Mientras
tanto, la parte que llega ahora (parte 2) encuentra la perforadora todavía ocupada
(con la parte 1), así que debe hacer cola. La perforadora aún está ocupada, así que
B(t) se mantiene en 1, pero la longitud de la cola Q(t) se incrementa de 0 a 1. Ahora
hay una cola y el tiempo de llegada (que ahora es 1.73) de la parte en la cola (la parte 2
que actualmente llega) se almacena como un atributo de aquella parte en la cola (entre
paréntesis); la parte 1, que llegó en el tiempo 0.00, aún está en servicio. Este evento no
da como resultado ninguna nueva producción ni nuevas observaciones de tiempo en
la cola, así que P, N, ∑WQ, WQ*, ∑TS y TS siguen sin cambios. ∫Q se aumenta por
0 ×(1.73 − 0.00) = 0 y ∫B se aumenta por 1 × (1.73 − 0.00) = 1.73. Dado que el nuevo
valor de Q(t) es 1, que es mayor que el previo Q* = 0, se coloca Q* = 1 como la nueva
longitud de cola máxima observada hasta este punto. No actualizamos el tiempo de
la siguiente partida puesto que queda (correctamente) programada como el tiempo de
partida de la parte 1, que llegó antes y ahora está parcialmente procesada. El siguiente
evento será la salida de la parte 1 en el tiempo 2.90.
< Entidad 1, t = 2.90, Sal: Dado que este evento es de salida, no se necesita programar
la siguiente llegada —ya está en camino, con el (correcto) evento de llegada [3, 3.08,
Lleg] en el calendario de eventos. La parte 1 ahora está siendo procesada por la per-
foradora y partirá. Puesto que hay una cola, la perforadora se mantendrá ocupada,
así que B(t) se mantiene en 1, pero Q(t) disminuye (de 1 a 0) y la cola se queda va-
cía (cuando la parte 2, que llegó en el tiempo 1.73, la deja para entrar en servicio). El
tiempo de espera de la parte 2 en la cola de duración 2.90 – 1.73 = 1.17 ahora está
completo y se suma a ∑WQ y N se incrementa; éste es un nuevo tiempo de espera
máximo en la cola, así que WQ* se redefine en 1.17. Una parte terminada (parte 1)
se produjo, así que P se incrementa y el tiempo total en el sistema para la parte 1 se
calcula como 2.90 − 0.00 = 2.90, que se suma en ∑TS; éste es un nuevo tiempo total
máximo en el sistema, así que TS* se actualiza a 2.90. Nosotros aumentamos ∫Q por
1 × (2.90 − 1.73) = 1.17, y ∫B se aumenta por la misma cantidad. No se realizó ningún
nuevo máximo para Q(t), así que Q* está sin cambio en 1. En la tabla 2-1, el siguiente
tiempo de servicio es 1.76, por lo tanto, la siguiente salida (de la parte 2, que ahora está
entrando a servicio) será en el tiempo 2.90 + 1.76 = 4.66. El siguiente evento es la llega-
da de la parte 3 en el tiempo 3.08.
< Entidad 3, t = 3.08, Lleg: La llegada de la siguiente parte (cuarta) se programó al crear
una entidad de parte 4, ajustando su tiempo de llegada en 3.08 + 0.71 = 3.79 (0.71
es el siguiente tiempo entre llegadas en la tabla 2-1) y colocándolo en el calendario
de eventos. Mientras tanto, la parte que llega ahora (parte 3) aún encuentra ocupa-
da la perforadora (con la parte 2), así que la parte 3 hace cola. La perforadora aún
está ocupada, así que B(t) se mantiene en 1, pero la longitud de la cola Q(t) se incre-
menta de 0 a 1. El tiempo de llegada (3.08) de la parte en la cola (la parte 3 que ac-
tualmente llega) se almacena como un atributo de esa parte; la parte 2, que llegó en
el tiempo 1.73, sigue en servicio. Con este evento, no se experimenta ninguna nueva
producción u observación del tiempo en la cola, así que P, N, ∑WQ, WQ*, ∑TS y TS*
30 Capítulo 2
< t = 20.00, Final: La única tarea aquí es actualizar las áreas ∫Q y ∫B al final de la simula-
ción, que en este estado aumentan 1 × (20.00 − 19.39) = 0.61 para ambas.
La última fila de la tabla 2-2 muestra la terminación, incluyendo los valores finales de los
acumuladores estadísticos.
2.4.4 Resumen
La única limpieza requerida es calcular los valores finales de las medidas de desempeño de los
resultados:
< El tiempo de espera promedio en la cola es ∑WQ/N = 15.17/6 = 2.53 minutos por parte.
< El tiempo total promedio en el sistema es ∑TS/P = 32.20/5 = 6.44 minutos por parte.
< La duración del tiempo promedio en la cola es ∫Q/t = 15.78/20 = 0.79 partes (aquí t es
el valor final, 20.00, del reloj de la simulación).
< El uso de la perforadora es ∫B/t = 18.34/20 = 0.92.
La tabla 2-3 resume todas las medidas de resultados finales junto con sus unidades de me-
dición.
Durante 20 minutos produjimos cinco partes terminadas; el tiempo de espera en la cola,
los tiempos totales en el sistema y la duración en la cola no parecen ser tan malos; y la perfo-
radora estuvo ocupada 92% del tiempo. Estos valores son considerablemente diferentes de lo
que se hubiera supuesto u obtenido a través de un modelo de colas demasiado simplificado
(véase el ejercicio 2-6).
nual) y tiene algunas ventajas, es fácil imaginar que se vuelve muy complicada para modelos
grandes con muchos tipos diferentes de eventos, entidades y recursos.
Una forma más natural de pensar acerca de muchas simulaciones es tomar el punto de vista
de una entidad “típica” conforme atraviesa por el modelo, más que la orientación omnisciente
del controlador maestro siguiendo el rastro de todos los eventos, entidades, atributos, variables
y acumuladores estadísticos, como hicimos en la simulación manual orientada a eventos. Esta
vista alternativa se centra en los procesos que realizan las entidades, así que se llama orienta-
ción del proceso. Como verá, esto es análogo a otra herramienta de modelado común, llamada
diagrama de flujo. En este panorama se podría modelar el ejemplo simulado a mano en pasos
como éste (póngase en la posición de una entidad típica de partes):
< Créese usted mismo (una nueva entidad llega).
< Escriba qué hora es ahora en uno de sus atributos para saber su tiempo de llegada des-
pués para los cálculos del tiempo de espera en la cola y del tiempo total en el sistema.
< Póngase al final de la cola.
< Espere en la cola hasta que la perforadora esté libre (la duración de esta espera podría
ser de 0 si tiene suficiente suerte para encontrar la perforadora libre).
< Tome la perforadora (y sálgase de la cola).
< Calcule y cuente su tiempo de espera en la cola.
< Manténgase, o retrásese, por una cantidad de tiempo igual a sus requerimientos de ser-
vicio.
< Deje la perforadora (para que otras entidades pueden tomarla).
< Incremente el acumulador de contador de producción en la pared y cuente su tiempo
total en el sistema.
< Dispóngase y sálgase.
Ésta es la clase de “programa” que se escribe con un lenguaje de simulación orientada a los
procesos como SIMAN y también es la visión de cosas normalmente tomadas por Arena (que
traduce su descripción tipo diagrama de flujo en un modelo SIMAN para correrlo, aunque
usted no necesite ir dentro a menos que quiera; véase la sección 7.1.6). Es una forma mucho
más natural de pensar acerca de la modelación, donde (muy importante) los modelos grandes
pueden construirse sin la complejidad extrema que requerirían en un programa orientado a
eventos. Pero esto requiere más apoyo tras bamabalinas para tareas como tiempo de avance,
manutención del rastro de estadísticas de tiempo continuo (que no se mostraron en la lógica
orientada a los procesos) y generación de reportes de salida. El software de simulación como
Arena proporciona este apoyo, así como una rica y poderosa variedad de construcciones de
modelación que permite desarrollar modelos complejos de forma relativamente rápida y con-
fiable.
La mayoría de las simulaciones de eventos discretos son ejecutadas en la orientación de
eventos, incluso aunque nunca se pueda ver si se hace la modelación en la orientación de proce-
sos. La naturaleza jerárquica de Arena permite entrar en la orientación de eventos si se necesita,
con la finalidad de recuperar el control para modelar algo peculiar; en ese caso se debe pensar (y
codificar) con la lógica orientada a eventos como se hizo en la simulación manual.
Por su facilidad y poder, la lógica orientada a procesos se ha vuelto muy popular y es el
acercamiento que nosotros tomaremos desde ahora. Sin embargo, es bueno tener algún co-
nocimiento de lo que pasa bajo el capó, así que primero lo hicimos sufrir a través del evento
laborioso de simulación.
34 Capítulo 2
lar con un mínimo de 1 minuto, una media de 3 minutos y un máximo de 6 minutos (el capítulo
3 indica cómo funciona todo esto en Arena). Hay que ver el apéndice D para una descripción
de las distribuciones de probabilidad de Arena.
Así, en lugar de sólo la corrida simple de 20 minutos, podremos hacer varias (haremos cin-
co) corridas de 20 minutos independientes y estadísticamente idénticas, e investigaremos cómo
cambian los resultados en una corrida y otra, indicando cómo podrían cambiar las cosas en la
realidad de una mañana a otra. Cada corrida comienza y termina de acuerdo con las mismas
reglas y usa los mismos conjuntos de parámetros (esta es la parte “estadísticamente idéntica”),
pero usa números separados aleatorios de entrada (esta es la parte “independiente”) para gene-
rar los tiempos entre llegadas y de servicio reales usados para dirigir la simulación. Otra cosa
que se debe hacer es no aplazar ninguna parte en la cola o en el proceso del final de una corrida
al inicio de la siguiente ya que ellos podrían introducir un enlace, o correlación, entre una co-
rrida y la siguiente; cualquier parte sin tanta suerte sólo déjela ir. Las corridas independientes
y estadísticamente idénticas se llaman repeticiones de la simulación, y Arena lo ayuda a encar-
garse de ellas; sólo introduzca el número de repeticiones que desea en el cuadro de diálogo de
la pantalla. Usted puede pensar en esto como tener cinco repeticiones de la tabla 2-1 para los
valores de entrada, cada uno generando una repetición de la simulación registrada en la tabla
2-2, resultando en cinco repeticiones de la tabla 2-3 para todos los resultados.
Deseamos que nos admire (o nos compadezca) por hacer todo esto a mano, pero realmente
sólo le pedimos a Arena que lo haga por nosotros; los resultados están en la tabla 2-4. La co-
lumna para la repetición 1 es la misma que está en la tabla 2-3, pero puede haber variaciones
sustanciales entre repeticiones, así como varían las cosas en una fábrica a través de los días.
Tabla 2-4. Medidas de desempeño de salida finales de cinco repeticiones de la simulación manual
*Tomar medias y desviaciones estándar de las medidas “máximas” podría tener una validez discutible, ¿cuál es la “máxima
media” supuesta, bueno, la media? En estos casos podría ser mejor tomar el máximo de la máxima de repeticiones individuales si
realmente quiere conocer los extremos.
36 Capítulo 2
Las columnas de la tabla 2-4 dan la media y la desviación estándar de la muestra (véase el
apéndice C) entre los resultados de las repeticiones individuales para la medida de desempeño
de salida en cada fila. La media de la muestra proporciona una indicación más estable de lo que
hay que esperar de cada medida de desempeño que lo que sucede en una repetición individual,
y la desviación estándar de la muestra mide la variación entre repeticiones.
Puesto que los resultados de las repeticiones individuales son independientes e idéntica-
mente distribuidos, se puede formar un intervalo de confianza para la medida de desempeño
μ esperada y verdadera (piense en μ como la media de la muestra entre un número infinito de
repeticiones), como
s
X ïtn Ź1, 1Ź Ĝ / 2
n
s
donde X ï estnla media de la muestra, s es la desviación estándar de la muestra, n es el número
Ź 1, 1Ź Ĝ / 2
de repeticiones 1.64
s nn = 5) y tn −1, 1 − α/2 es el 1 = α/2 punto crítico superior de la distribución t
(aquí
ïï
3X.80 tn Ź21,.1776 5n 1 grados de libertad. Por ejemplo, si se usa la medida de producción total,
de Student con n − Ź Ĝ / 2
2
Bueno, casi siempre.
Conceptos principales de simulación 37
1SPEVDDJÓOUPUBM
0 5 10
1SPNFEJPEFUJFNQPEFFTQFSBFOMBDPMB
0 5 10
1SPNFEJPEFUJFNQPUPUBMFOFMTJTUFNB
0 5 10
5JFNQPQSPNFEJPEFOÙNFSPEFQBSUFTFOMBDPMB
0 5 10
6TPEFMBQFSGPSBEPSB
Figura 2-4. Comparación entre el sistema original (círculos) y el de llegada de doble tiempo
(triángulos). (En la primera repetición el símbolo está lleno y en las restantes están vacíos.)
38 Capítulo 2
La figura 2-4 indica qué ocurrió con las cinco medidas de desempeño “no extremas”; la fila
de arriba (círculos) de cada gráfica indica la configuración original (y se toma directo de la ta-
bla 2-4) y la fila más baja (triángulos) es para la nueva configuración. Se indican los resultados
de las cinco repeticiones de cada modelo para cada medida de desempeño y el resultado de la
primera repetición en cada caso está llena (las repeticiones 2 a 5 están vacías).
No está claro que la producción total en realidad aumente mucho con las llegadas de doble
tiempo, debido a la capacidad limitada de procesamiento. Sin embargo, parece que el tiempo
en la cola y en el sistema, así como el uso, tienden a aumentar, aunque no en todos los casos
(debido a la variabilidad). A pesar de algún traslape, las longitudes promedio en la cola parecen
crecer algo cuando el índice de llegada se duplica. Mientras que los análisis estadísticos forma-
les pueden ser posibles aquí para ayudar a descubrir cosas (véase la sección 6.4), las gráficas
simples como éstas pueden ser más ilustrativas (aunque quizá se requieran bastantes más que
sólo cinco repeticiones de cada escenario).
Además observe que depender de una repetición (la primera; indicada por los símbolos lle-
nos) puede ser engañoso. Por ejemplo, el tiempo promedio de espera en la cola en las primeras
repeticiones de cada variante del modelo podría indicar que es mucho mayor para las llegadas
de doble tiempo, aunque examinando la dispersión entre las repeticiones se ve que la diferencia
no es tan clara o drástica. Éste es el peligro de depender de sólo una corrida sencilla para tomar
decisiones importantes.
Se escribe esta fórmula como una función de q ya que depende de la elección de Rupert de q.
En programación matemática o lenguaje de optimización, q es la variable de decisión de Rupert
para tratar de maximizar su función objetivo de ganancias diarias esperadas, E(W(q)). Puesto
que D es una variable aleatoria, también lo es W(q), y se necesita tomar su expectativa (véase
el apéndice C para un repaso de probabilidad y estadística) para obtener una función objetivo
deterministica para tratar de maximizarla. En este ejemplo, donde los valores esperados son
promedios de largo plazo durante muchos días, Rupert maximiza su ganancia diaria promedio
de largo plazo al encontrar el mejor valor constante de q que mejor se adapte y del que no tenga
que preocuparse. Él no trata de ajustar q cada día dependiendo de la demanda, lo cual es im-
posible ya que debe comprometerse a comprar un número fijo q de periódicos por la mañana,
sin saber la demanda de ese día. Con base en la forma de la distribución de probabilidad de D,
puede ser posible en algunos casos derivar una expresión exacta para E(W(q)) que se trate de
maximizar con respecto a q. Pero siempre se puede desarrollar un modelo de simulación simple
y tomar en cuenta las lecciones de la sección 2.6 acerca del análisis estadístico de la salida de si-
mulación para obtener un estimado válido y preciso del q óptimo, sin hacer suposiciones firmes
y tal vez irreales de la distribución de D sólo para hacer posible un resultado analítico.
Para simular esto es necesario generar valores numéricos en la variable aleatoria de deman-
da D = máx (⎣X⎤, 0); también llamadas variables estadísticas aleatorias en D. Por lo tanto
primero es necesario generar variables estadísticas aleatorias en X, que tiene una distribu-
ción normal con una media μ = 135.7 y una desviación estándar σ =27.1. La sección 12.2
analiza la generación de variable estadística aleatoria en general, así que confiaremos en que
la revisará más adelante si está interesado en este punto. En este caso−1
se puede generar una
variable estadística aleatoria de distribución normal como X = Φμ,σ (U) donde U es un nú-
mero aleatorio (variable estadística aleatoria continua distribuida uniformemente entre 0 y 1,
analizada en la sección 12.1), Φμ,σ es la−1
distribución acumulada de la distribución−1
normal con
media μ y desviación estándar σ, y Φμ,σ es la función inversa de Φμ,σ es decir, Φμ,σ “deshace”
lo que Φμ,σ hace. Otra forma de ver la función inversa es la necesidad de resolver U = Φμ,σ
(X) para X, donde U podría ser un número específico entre 0 y 1 del generador de números
−1
aleatorios. Como se sabe, ni Φμ,σ ni Φμ,σ de la distribución normal−1
pueden escribirse como
una fórmula de forma cerrada explícita, así la evaluación de Φμ,σ (U) será por aproximación
40 Capítulo 2
a la fila 2 para mantener la referencia a ella para las siguientes filas. Por lo tanto, esto es
mín (D, q), como se desea.
< La celda G4 es el número de periódicos desechados al final del día 1 si q = 100. La fór-
mula de Excel es = MÁX(H$2 − $E4, 0), con el uso de $ lo mismo que en la celda
F4 y por las mismas razones. Éste es máx (q − D, 0).
< La celda H4 es la ganancia, en dólares, en el día 1 si q = 100. La fórmula de Excel es =
$B$5*F4 + $B$6*G4 − $B$4*H$2, que es r mín (D, q) + s máx (q − D, 0) − cq. Se
deja a su interpretación por qué los signos $ están o no están presentes.
Después sólo se copian las celdas F4, G4 y H4 en las 29 filas siguientes, permitiendo a las letras
de las columna y a los números de las filas correr de forma apropiada y controlados por la co-
locación del símbolo $ en las fórmulas, para obtener la tabla de simulación, como a veces se le
llama, para el caso q = 100.
Al final de estas columnas, sombreadas con verde en el archivo, se agregó la ganancia pro-
medio (celda H34) y la mitad del ancho de un intervalo de confianza de 95% en la ganancia
promedio esperada (celda H35) por los 30 días, con la fórmula igual que aquellas hacia el final
de la sección 2.6.2; el valor 2.045 es el punto crítico 0.975 superior de la tabla t con 29 grados
de libertad. Observe que igual que en la sección 2.6.2 la forma de este intervalo de confianza
asume que las ganancias individuales en una columna son distribuidas normalmente, lo cual
no es tan cierto, en especial para valores pequeños de q donde hay una variabilidad pequeña
en ganancia, que también se contempla; de nuevo, vaya al final de la sección 6.3 para más
información sobre robustez estadística.
Se agregó también en la fila 36 la proporción de días en que se presentaron pérdidas, que
es un estimado de la probabilidad de incurrir en pérdidas en un día, al usar la función de Ex-
cel COUNTIF [CONTAR.SI]. Con este valor bajo de q no es probable una pérdida ya que la
demanda será al menos q en casi todos los días, pero eso puede cambiar con valores más altos
de q. En las filas 38 a 46 se presentan datos de distribución de frecuencias (de nuevo al usar
COUNTIF [CONTAR.SI]) para construir un histograma de las ganancias inmediatamente
abajo; la línea vertical en los histogramas, que es roja en el archivo, está en cero, indicando a
su izquierda la probabilidad de presentar una pérdida, así como la distribución general de los
datos de ganancias.
Para completar el estudio de simulación se toman las columnas F, G y H y se copian en
cuatro bloques más de tres columnas cada uno a la derecha, pero con los valores para q de 120,
140, 160 y 180, y agregando histogramas en la parte baja de cada valor de q. Para visualizar los
resultados medios se agregó la gráfica en el margen izquierdo, que muestra la ganancia prome-
dio como un punto, con las líneas I verticales que muestran los intervalos de confianza, para
diferentes valores de q en el eje horizontal.
Para un día dado, nótese que se escogió usar la misma variación de demanda numérica
realizada (columna E) para todos los valores de prueba de q, en lugar de generar demandas
independientes nuevas para cada valor de q, que también podrían ser válidas. Llenar más
columnas de Excel con demandas nuevas no costaría mucho, pero se realizó deliberadamente
de esta forma. El interés es realmente comparar la ganancia para diferentes valores de q; al
usar las mismas demandas numéricas realizadas en un día específico para todos los valores
de q, las diferencias que se observan en la ganancia se pueden atribuir a diferencias en q (que
es el efecto que se trata de medir) más que arriesgar diferencias en la demanda. Éste es un
ejemplo de una técnica de reducción de varianza, en particular de números aleatorios comunes,
Conceptos principales de simulación 43
que se analizan de forma más completa en la sección 12.4. Dichas estrategias en la simulación
estocástica pueden ayudar a obtener respuestas más precisas, a menudo con poco o ningún
trabajo (en este caso, con menos trabajo) y vale la pena pensar en ello.
Si abre el archivo de la hoja de cálculo por su cuenta no verá los mismos números que en
la figura 2-5 debido a la volatilidad de la función RAND () [ALEATORIO()] de Excel. Así,
conforme se vuelve a calcular (teclee F9 varias veces) se verá que todos los números cambian,
los objetos en la gráfica de medias a la izquierda saltan de arriba abajo, y los histogramas en
la parte baja ondearán de izquierda a derecha, todos reflejando esta volatilidad y la verdad
subyacente de que tal simulación estocástica es un experimento con resultados aleatorios; sin
duda, los saltos ascendentes y descendentes de las líneas I en la gráfica de medias a la izquier-
da recuerdan que los intervalos de confianza por sí solos son intervalos aleatorios y dependen
de la muestra particular que se logró obtener. Nótese que los cinco puntos y líneas I tienden
a saltar arriba o abajo juntas, reflejando la reducción de varianza de los números aleatorios
comunes que se mencionó en el párrafo anterior (véase el ejercicio 2-10).
A pesar de la aleatoriedad, parecería que Rupert colocó a q cerca de 140, a lo mejor un
poco menos, para maximizar sus ganancias diarias esperadas. Desde las líneas I de intervalo
de confianza también se ve como si se quisiera aumentar el tamaño de muestra considerable-
mente más de 30 días para sujetar mejor esta disminución (ejercicio 2-11). Esto ayudaría a
considerar más valores de q en una malla más fina (ejercicio 2-12), pero este estudio por lo
menos muestra que Rupert tal vez comprará al menos 120 periódicos cada mañana, pero no
más de 160, puesto que por otro lado él pierde demasiadas ganancias debido a las ventas no
logradas o al desechao de periódicos.
Al mirar más allá de los promedios mediante los histogramas en la parte baja, a mayor valor
de q, habrá mayor variabilidad (riesgo) en la ganancia, visto al ensancharse los histogramas.
Esto implica buenas y malas noticias. Con una q alta, Rupert tiene el inventario necesario
para obtener una ganancia mayor en días de gran demanda, pero también se observan más
ganancias negativas cuando la demanda es baja, en días con noticias aburridas y lentas cuando
se queda con mucho desecho de pérdida. Si Rupert tomara riesgos, puede ir por un valor alto
de q (algunas veces usted se come al oso, otras el oso se lo come a usted). Por el contrario, los
valores muy bajos de q suponen poco riesgo puesto que la demanda raras veces cae poco debido
a que el valor de q es bajo, pero el inconveniente es que la ganancia promedio también es baja
y Rupert no puede cobrar en los días de gran demanda ya que vende toda la mercancía. Tales
cambios de riesgo o retorno en las decisiones de negocios en general son cuantificados a través
de simulaciones en hojas de cálculo de modelos estáticos como éste.
Es muy fácil simular el problema del voceador en Arena (véanse los ejercicios 6.22 y 6.23).
< Los tiempos entre llegadas tienen una distribución de probabilidad exponencial con me-
dia 1/λ = 1.6 minutos y son independientes entre ellos (véanse los apéndices C y D). El
parámetro λ = 1/1.6 = 0.625 es la tasa de llegada (aquí por minuto).
< Los tiempos de servicio tienen una distribución uniforme continua entre a = 0.27 minu-
tos y b = 2.29 minutos, son independientes entre ellos y de los tiempos de llegada.
Ésta se llama cola M/U/1, donde U se refiere a los tiempos de servicio distribuidos uniforme-
mente.
En lugar de observar todas las salidas en la simulación manual, sólo se observarán los
tiempos de espera en cola, WQ1, WQ2, ..., WQ50 de los primeros 50 clientes para completar
su espera en la cola (no incluye sus tiempos de servicio). En la simulación manual colocamos
un reloj, variables de estado, calendario de eventos y acumuladores estadísticos para simular
esto, pero para una cola FIFO de servidor sencillo hay una recursión sencilla para los valores
de WQi (si eso es en lo que estamos interesados en la forma de la salida) en la fórmula de
Lindley (1952). Sea Si el tiempo en servicio para el cliente i y sea Ai el intervalo de tiempo
entre los clientes i − 1 e i. Entonces
y comenzamos al igualar WQi = 0 dado que llega el primer cliente a un sistema vacío y desocu-
pado.
Para simular esto necesitamos generar variables estadísticas aleatorias de las distribuciones
uniformes exponenciales y continuas. De nuevo con referencia en la sección 12.2, hay fórmulas
simples para ambos (igual que antes, U muestra un número aleatorio distribuido continuamen-
te de forma uniforme entre 0 y 1):
< Tiempos entre llegadas exponenciales con media 1/λ: Ai = −(1/λ) ln (1 − U) donde ln es
el logaritmo natural (base e).
< Tiempos de servicio distribuidos de manera unifrome y continua entre a y b: Si = a +
(b − a)U.
La figura 2-6 muestra el archivo de Excel MU1.xls en la carpeta de ejemplos del libro. Las
celdas B4, B5 y B6 son los parámetros y la columna D sólo brinda el número de cliente i = 1,
2, ..., 50 para una corrida del modelo. Los tiempos entre llegadas están en la columna E, con la
fórmula de Excel −$B$4*LN(1−RAND()), y los tiempos de servicio están en la columna F,
generados por la fórmula $B$5+($B$6−$B$5)*RAND().
La recursión de Lindley está en la columna G; comienza con el 0 en la celda G4. Una
entrada común está en la celda G9, MÁX(G8+F8-E9,0), que genera WQ6 de WQ5 (en la
celda G8), S5 (celda F8) y A6 (celda E9). De esta forma, cada espera de la cola en la columna
G tiene relación con la anterior, estableciendo una correlación entre ellas. Puesto que esto es
una correlación de entradas en una secuencia entre ellas, se llama autocorrelación. En este
caso, es una autocorrelación positiva ya que una espera larga quizá significa que la siguiente
espera también será larga y viceversa, lo cual se puede entender al observar la recursión de
Lindley o las experiencias personales de esperar en una fila. Así que, a diferencia de las filas
de ganancia del voceador en la sección 2.7.1, los tiempos de espera en la cola aquí no son
independientes de una fila a otra en la columna G, que es típico de las secuencias de salida
dentro de una corrida de una simulación dinámica.
Conceptos principales de simulación 45
Al final de las columnas E, F y G se dan los promedios. En las columnas E y F, esto confirma
que están cerca de los valores esperados de los tiempos entre llegadas y los tiempos de servicio,
respectivamente 1/λ = 1.6 y (a + b)/2 = 1.28 (véase el apéndice D). Para la columna G, ésta es
la espera promedio en la cola para los primeros 50 clientes; es decir, el resultado de salida de la
simulación.
También se puede calcular fácilmente la desviación estándar de la muestra de las esperas
en la cola de la columna G y después los intervalos de confianza, como en la simulación del
voceador, pero no lo hacemos por dos razones muy importantes:
1. Debido a la autocorrelación entre los valores de WQi en la columna G, la varianza de la
muestra podría ser desviada como en un estimador de la varianza de un WQi “típico”,
puesto que hasta cierto punto están “vinculados” unos con otros, de tal forma que no son
libres de variar tanto como deberían si fueran independientes. Con nuestra autocorrelación
positiva, el estimador de la varianza de la muestra estaría desviado a la baja; es decir, la
varianza de un WQi “típico” sería demasiado pequeña y subestimada. Sólo debido a que
se pueden calcular algunos números, o dibujar algunas gráficas para esa cuestión, no se
debería hacer si pudieran ser engañosos.
46 Capítulo 2
2. No está claro aún lo que significa aquí un WQi “típico”, ya que el comienzo de WQi =
0 hace la primera parte de la secuencia de salida menor que la siguiente, así que la distri-
bución (y por tanto la varianza) de los valores de WQi cambian a medida que i aumenta.
Por consiguiente, aún no esta claro qué es lo que se calcula con un estimado de la varian-
za de la muestra.
Se copian las columnas E, F y G en cinco bloques más de tres columnas cada uno hacia la
derecha, creando cinco repeticiones independientes de esta corrida de 50 esperas en cola. Todos
los números aleatorios y, por ende, los resultados son independientes entre estos cinco conjun-
tos de tres columnas. Éste es el mismo modelo para todo el proceso, pero repetido cinco veces
independientes.
La gráfica de la izquierda marca la secuencia de WQi en cada una de las cinco repeticiones
al usar diferentes patrones de guiones y también grafica el promedio de los cinco valores de
WQi, para un i fijo, entre las repeticiones (en la columna T) como la curva más ancha y conti-
nua. Note que la variación dentro de una ejecución y la curva ancha promedio suaviza un poco
las cosas hacia abajo. Todas las curvas comienzan en 0 a la izquierda, reflejando el comienzo
determinista de WQi = 0, y aumentan a partir de ese punto, sujetas a un gran movimiento que
refleja la variabilidad de salida. La autocorrelación positiva está en evidencia ya que las curvas,
mientras se mueven, no se desprenden abruptamente a medida que progresan hacia la derecha
y los puntos en ellas tienden a estar cerca de los puntos colindantes por poco hacia izquierda
s
X ïtn Ź1, 1Ź Ĝ / 2
y derecha.
La línea horizontal n ancha de color gris grafica el valor de la celda B10, que es la espera
supuesta de estado estacionario de la cola, E(WQ∞). Esto puede calcularse de forma exacta, a
partir de la teoría de colas (véase Gross y Harris, 1998), para colas FIFO de servidor sencillo
1.64
.80 ï2 .776
con 3tiempos exponenciales entre llegadas y tiempos de servicio Si con cualquier distribución,
5
como
2
Var Si à E Si
E WQƈ âħ
2 1 Ź ħ ESi
En nuestro caso, λ = 0.625 (el recíproco de la celda B4), E(Si ) = (a + b)/2 = 1.28 en la celda
B8 y Var(Si ) = (b − a)2/12 = .034 en la celda B9 (véase el apéndice D). Aunque la variación en
la gráfica la oscurece, un poco de imaginación indica que la curva promedio gruesa y constante
está cubriendo la línea horizontal, de color gris (véase el ejercicio 2-13).
¿Por qué no utilizar histogramas como los utilizados en la parte inferior de la hoja de cálculo
del problema del voceador? Se pueden construir de la misma forma y pueden proporcionar in-
formación útil acerca de la distribución de las esperas en la cola, más allá de sólo sus medias. El
problema potencial con esto es la autocorrelación en la secuencia de espera en la cola, así que un
histograma, como un estimado de varianza, puede estar desviado si la corrida no fuera lo sufi-
cientemente larga como para asegurar que los tiempos de espera en la cola al fin visitarán todas
las posibles regiones y en las proporciones adecuadas; la autocorrelación se enlaza a las observa-
ciones cercanas, lo cual impediría tal inspección si la corrida fuera muy corta. Sin embargo, una
corrida muy larga puede producir realmente un histograma desviado cercano, que podría ser útil;
en la práctica, puede ser difícil determinar cuán largo es suficientemente largo. La duda es pre-
sentar algo que sea preciso y útil la mayoría del tiempo, con el riesgo de que sea ocasionalmente
desviado y engañoso.
Conceptos principales de simulación 47
Simular una cola de único servidor en Arena es muy sencillo y es básicamente el ejemplo cen-
tral que se usa en el capítulo 3 para presentar Arena.
< Validar el modelo: ¿Corresponden las distribuciones de entrada con lo que se observó en
el campo? ¿Corresponden las mediciones del desempeño de salida del modelo con las
de la realidad? Mientras se realizan las pruebas estadísticas, se valora mucho una buena
dosis de sentido común.
< Diseñar los experimentos: Planee qué es lo que desea saber y cómo los experimentos de si-
mulación lo llevarán a obtener las respuestas de una forma precisa y eficaz. Muchas veces
los principios de diseño experimental estadísticos clásicos pueden ser de gran ayuda.
< Ejecutar los experimentos: Aquí es donde usted va a almorzar mientras la computadora
trabaja alegremente, o tal vez ir a casa por la noche o el fin de semana, o ir de vacaciones.
En este paso es clara la necesidad de un diseño experimental cuidadoso. Pero no se asus-
te, es probable que su computadora pase la mayor parte del tiempo sin hacer nada, así
que llevar a cabo instrucciones equivocadas no constituye el fin del mundo (recuerde que
usted cometerá errores en la computadora, en donde no cuentan, en lugar de cometerlos
en la realidad, donde sí lo hacen).
< Analizar los resultados: Llevar a cabo las formas correctas de análisis estadísticos para
ser capaz de hacer declaraciones acertadas y precisas. Está claro que esto tiene una estre-
cha relación con el diseño de los experimentos de simulación.
< Tener entendimiento: Esto es más fácil decirlo que hacerlo. ¿Qué significan los resultados
de las corazonadas? ¿Todos tienen sentido? ¿Cuáles son las consecuencias? ¿Qué otras
preguntas (y posiblemente simulaciones) indican los resultados? ¿Usted está observando
el conjunto adecuado de mediciones del desempeño?
< Documentar lo que se hace: No estará siempre cerca, así que hágale fácil la vida a su co-
lega explicándole lo que hizo para que pueda seguir con su trabajo. La documentación
también es esencial para convencer a la administración e implementar las recomendacio-
nes en las que trabajó tan duro para ser capaz de lograrlas con precisión y confianza.
Al poner atención en estos y otros temas similares, su intento de un proyecto de simulación
exitoso habrá logrado una mejora considerable.
2.9 Ejercicios
2-1 Para la simulación manual del sistema de proceso simple, defina otra estadística de
tiempo continuo como el número total de partes en el sistema, incluyendo cualquier parte
en la cola y en el servicio. Aumente la tabla 2-2 para identificarla como una nueva variable
global, añada nuevos acumuladores estadísticos para obtener su tiempo promedio y máximo,
y calcule estos valores al final.
2-2 En el ejercicio anterior, ¿usted realmente necesitó agregar variables estáticas y mantener
el rastro de los nuevos acumuladores para obtener el tiempo promedio de número de partes en el
sistema? Si no, ¿por qué no? ¿Qué hay del número máximo de partes en el sistema?
2-3 En la simulación manual del sistema de procesamiento simple, suponga que la disci-
plina de la cola cambió de tal forma que cuando la perforadora se detenga y encuentre partes
esperando en la cola, en lugar de tomar el primero, tomará el que requiera el tiempo de proceso
más corto (esto en algunas ocasiones se llama disciplina de la cola SPT). Para hacer que esto
funcione necesitará asignar un segundo atributo a las partes en el sistema cuando lleguen, re-
presentando el tiempo de servicio que tendrán en la perforadora. Vuelva a hacer la simulación
manual. ¿Es ésta una mejor regla? ¿Desde qué perspectiva?
Conceptos principales de simulación 49
2-4 Suponga que en la simulación manual del sistema de procesamiento simple se requiere
un tiempo de arranque constante de 2 minutos una vez que una parte ingresa en la perfo-
radora pero antes de que su servicio pueda comenzar. Cuando está en acción un arranque,
considere que la perforadora esté ocupada. Vuelva a hacer la simulación manual y comente
los resultados.
2-5 Suponga que la perforadora puede trabajar en dos partes simultáneamente (y ellas en-
tran, son procesadas y dejan la perforadora de manera independiente). No hay diferencia en la
velocidad de procesamiento si hay dos partes en la perforadora en lugar de una. Redefina B(t)
para ser el número de partes en servicio en la perforadora al tiempo (así 0 ≤ B(t) ≤ 2); el uso de
la perforadora se redefine como
T
∫ B(t)dt
0
2T
donde T = 20. Vuelva a correr la simulación original para medir el efecto de este cambio.
2-6 En la sección 2.2.2 usamos la fórmula de cola M/M/1 con la media de tiempo entre lle-
gadas μA y la media de tiempo de servicio μS calculados de los datos de la tabla 2-1 como 4.08
y 3.46, respectivamente. Esto produjo un valor “esperado” de 19.31 minutos para el tiempo de
espera promedio en la cola. Sin embargo, los resultados de la simulación manual de la sección
2.4.4 produjeron un valor de 2.53 minutos para esta medición.
a) Si se supone que estos dos números (muy diferentes) calculan o se aproximan a lo mis-
mo (tiempo de espera promedio en la cola), ¿por qué son aparentemente tan diferentes?
Dé por lo menos tres razones.
c) Consultamos un oráculo, que nos vendió la información de que los tiempos entre
llegadas de hecho son “trazos” de una distribución exponencial con una media de 5
minutos y los tiempos de servicio realmente son trazos de una distribución triangu-
lar con un mínimo de 1 minuto, una media de 3 minutos y un máximo de 6 minutos
(véase el apéndice D para mayor información de estas distribuciones y el apéndice C
para repasar la probabilidad). Con esta información (exacta), la media de los tiem-
pos entre llegadas es μA = 5 minutos y la media de tiempo de servicio es μS = (1 + 3
+ 6)/3 = 3.33 minutos. Cuando use estos valores, use la fórmula M/M/1 en la sección
2.2.2 para pronosticar un valor para el tiempo de espera promedio en la cola. ¿Por
qué es todavía diferente de los primeros tres valores (19.31, 2.53 y 3.60) para esta
misma cantidad comentada anteriormente en este ejercicio?
50 Capítulo 2
d ) Al usar la información del oráculo en la parte c) se consideró otra simulación manual
de un millón de minutos (igual de entretenida), pero esta vez se trazaron los tiempos
de servicio de una distribución exponencial (no triangular) con media de 3.33 minutos
y se obtuvo un resultado de 6.61 para una media de tiempo de espera en la cola. Com-
pare y contraste esto con los cuatro valores anteriores para esta cantidad comentados
anteriormente en este ejercicio.
2-7 Aquí están los números reales usados para graficar los triángulos para el modelo de lle-
gada de doble tiempo de la figura 2-4:
Repetición
Medida de desempeño 1 2 3 4 5
Producción total 6 4 6 4 5
Promedio de tiempo de espera en la cola 7.38 2.10 3.52 2.81 2.93
Promedio de tiempo total en el sistema 10.19 5.61 5.90 6.93 5.57
Tiempo promedio del número de partes en la cola 2.88 0.52 1.71 0.77 2.25
Uso de la perforadora 1.00 0.92 1.00 0.95 1.00
Para cada una de estas cinco medidas de desempeño calcule la media de la muestra, la des-
viación estándar de la muestra y la mitad del ancho de los intervalos de confianza de 95% en las
medidas de desempeño esperadas, como se hizo en la tabla 2-4. Al comparar estos intervalos de
confianza con los de la tabla 2-4, ¿podría aclarar cualquier diferencia más allá del análisis de la
sección 2.6.3 (que se basó en observar la figura 2-4)?
2-8 En la simulación manual del sistema de procesamiento sencillo, suponga que la perfora-
dora se desmonta en 3 minutos para darle mantenimiento y toma 3 minutos hacer este trabajo
y colocarla de nuevo; entonces se mantiene por el resto de los 20 minutos de duración de la
simulación. Si hay alguna parte en servicio cuando se desmonte la perforadora, su proceso se
suspende hasta que la perforadora se vuelva a armar, se reanude y necesite sólo su tiempo de
proceso restante (su procesamiento no tiene que comenzar de nuevo desde cero). Durante el
tiempo de desinstalación, el proceso de llegada de nuevas partes continúa sin considerar el tiem-
po que estuvo parada. Considere que la perforadora está ocupada cuando está desmontada y
defina el tiempo en el sistema de una parte para incluir el tiempo que se queda en la perforadora
sin que esté funcionando si fuera lo suficientemente desafortunada para estar en servicio cuan-
do la perforadora se desmonte. Usando los mismos datos de entrada de la tabla 2-1, desarrolle
esta simulación manualo y observe cualquier diferencia en las medidas de desempeño de salida
del modelo original. (Véase el ejercicio 6-18 para la pregunta de si este cambio de modelo pro-
voca cambios estadísticos significativos en las medidas de desempeño de salida.)
2-9 En el ejercicio 2-8 depure las medidas de desempeño de salida en el estado de la perfo-
radora de sólo los dos estados (ocupada contra detenida, donde en el ejercicio 2-8 se consideró
que la perforadora estaba “ocupada” durante su tiempo de desmonte) a tres estados:
Conceptos principales de simulación 51
2-10 Modifique el problema del voceador de la sección 2.7.1 para usar demandas indepen-
dientes para cada valor de prueba de q y observe la diferencia en el comportamiento de la sali-
da, en particular en la gráfica de medias a la izquierda.
2-11 Aumente el tamaño de muestra en el problema del voceador de la sección 2.7.1 de 30 a
120 días. Igual que en el problema original, use las mismas demandas realizadas en la columna
E para todos los valores de q. No olvide cambiar el resumen estadístico y las celdas del histogra-
ma de forma adecuada en la parte baja de las columnas, así como las celdas a las que se refieren
en las diferentes gráficas. ¿Cuál es el efecto en los resultados? Con base en sus resultados, ¿qué
tamaño de muestra (en días) sería necesario para obtener la mitad del ancho máximo de todos
los cinco intervalos de confianza debajo de ± $2.00? No lleve a cabo esto, sólo obtenga un esti-
mado (véase la sección 6.3).
2-12 Con base en sus resultados del ejercicio 2-11, intente un conjunto diferente de valores
de prueba de q para probar en casa de una forma más precisa una q óptima. Mantenga el tama-
ño de muestra en 120 días. Dependiendo de lo que elija probar, necesitará ajustar los ejes en la
gráfica de medias a la izquierda.
2-13 Modifique la simulación de la hoja de cálculo de cola M/U/1 de la sección 2.7.2 para
tener tiempos de servicio exponenciales con una media de 1.28 minutos, en lugar de los tiempos
de servicio uniformes originales, resultando en la cola M/U/1. Cambie adecuadamente la espera
pronosticada de estado estacionario en la cola; vea la entrada de distribución exponencial en el
apéndice D.
2-14 Modifique la simulación en hoja de cálculo de cola M/U/1 de la sección 2.7.2 para
hacer diez repeticiones en lugar de 5 y para hacer una corrida con 200 clientes en lugar de con
50. Para evitar los grupos, grafique sólo la curva de espera en la cola promedio de repetición
cruzada. Compare con el original de la sección 2.7.2.
CAPÍTULO 3
3.1 Inicio
Arena es una aplicación del sistema operativo Windows® de Microsoft®, así que su apariencia
y percepción le resultarán familiares pues todas las características y operaciones usuales se
encuentran en él. Además, Arena es totalmente compatible con otros software de Windows,
como procesadores de texto, hojas de cálculo y paquetes CAD, así que usted puede mover los
elementos con facilidad hacia delante y hacia atrás (en el capítulo 10 se detallarán tanto la co-
municación como la interacción de Arena con otro software).
A propósito, suponemos que usted trabaja sin problemas con los puntos básicos para operar
con Windows, como:
54 Capítulo 3
chivo > Panel de plantillas > Adjuntar). Los archivos de plantillas (con extensión del
nombre del archivo .tpo) están en la carpeta de Template (Plantillas) que a su vez se
ubica en la carpeta 10.0 de Arena. También puede hacer clic con el botón derecho en la
Project bar (barra de proyecto) a la izquierda (véase la figura 3-1), y después Template
Panel > Attach (Panel de plantillas > Adjuntar) en la ventana que aparezca.
Template Detach (Separar plantillas) (cuando ya no necesita los elementos de modela-
do en el panel activo); de forma equivalente File > Template Panel > Detach (Archivo
> Panel de plantillas > Separar) o un clic con el botón derecho en el panel activo (que
usted desee separar) de la barra de proyectos de la izquierda; después Template Panel
> Detach (Panel de plantillas > Separar) en la ventana que surja.
Context Help (Ayuda de contexto) para proporcionar ayuda en un menú o comando de
la barra de herramientas. Haga clic para añadir un signo de interrogación a la punta
de la flecha de su ratón y después presione el botón de la barra de herramientas o el
comando del menú para obtener ayuda; al cerrar esa ventana de ayuda el cursor del
ratón volverá a ser una flecha.
Los tooltips (consejos de las herramientas) proporcionan otra fuente de ayuda rápida y breve
(aun más rápida y más breve) en los botones de la barra de herramientas. Si su ratón permanece
inmóvil sobre un botón, por un segundo o dos, aparece un pequeño cuadro con el nombre del bo-
tón. Si desea saber más acerca de ese botón, usted podría utilizar así como se describió, o qui-
zá buscarlo (ahora que por lo menos sabe su nombre) en el sistema de ayuda de Arena; hay más
sobre este asunto en la sección 3.7. Si usted se cansa de que los tooltips lo molesten a cada instante,
los puede quitar mediante View > Toolbars > Toolbars (Ver > Barra de herramientas > Barra de
herramientas) y quitar la marca en la opción Show Tooltips (Mostrar consejos de herramientas).
Cuando acabe con su sesión en Arena y desee salir, haga clic en ∙ en la esquina superior
de la pantalla de Arena, en File + Exit (Archivo > Salir), en Alt + F4, o haga clic con el botón
derecho en la parte de arriba de la barra de la pantalla de Arena y seleccione Close (Cerrar) en
la ventana que aparezca.
1
En su primer desarrollo, Arena tenía el nombre codificado de “Bambi”. No lo estamos inventando.
56 Capítulo 3
Toolbars
(Barras de
herramientas)
Project Bar
Model Window
(Barra de proyectos)
Flowchart View
(Vista del diagrama
de flujo de
la ventana del
modelo)
Figura 3-1. Ventana de Arena para el sistema de procesamiento simple, Modelo 3-1
Debe aparecer una ventana de Arena que se asemeje a la de la figura 3-1 (podría encontrar
diferentes barras de herramientas y botones en su computadora o ver algunos elementos en
lugares diferentes). Le llamaremos modelo 3-1.
la esquina superior izquierda. O usted puede tener abierto Arena simultáneamente a una hoja de
cálculo en la que haya un número muy grande que desee poner en el cuadro de diálogo de texto.
Copie el número de la celda de la hoja de cálculo, cámbiese a Arena (ya sea vía Barra de trabajo de
Windows® o usando Alt >Tab para circular a través de las aplicaciones abiertas), posicione el
cursor de inserción en el cuadro de diálogo de Arena en donde desee el número y péguelo ahí. Si
usted está escribiendo un reporte en un procesador de textos y desea pegarlo en “automático”
de una pantalla de Arena, vaya a Arena y métase en el estado que desea fotografiar, presione la
clave Prnt Scrn (Print Screen [Imprimir pantalla]), regrese a su documento en el procesador de
textos y pegue la imagen en donde lo desee; si sólo desea la ventana activa (como un cuadro de
diálogo que quiera documentar), presione Alt + Prnt Scrn y después péguelo en el documento
del procesador de textos.
La ventana del modelo se puede dividir en dos regiones o vistas; la vista del diagrama de flujo
y la vista de la hoja de cálculo. A menudo es útil mirar tanto la vista del diagrama de flujo como
la de la hoja de cálculo de la ventana del modelo al mismo tiempo. Pero se puede elegir ver sólo
una de las dos y por lo tanto dedicar todo el estado real en la ventana del modelo a ella, despe-
jando el comando del menú View > Split Screen (Ver > Dividir pantalla) o al hacer clic en de
tal forma que no aparezca presionado; en este caso, para observar una u otra vista, sólo haga
un clic en cualquier módulo de diagrama de flujo ( ) o de hoja de cálculo ( ) en la barra de
proyectos que aparece a la izquierda de su pantalla. La vista del diagrama de flujo contiene las
gráficas del modelo, incluyendo el diagrama de flujo del proceso, animación y otros elementos
de dibujo. La vista de la hoja de cálculo puede desplegar los datos del modelo, tales como tiem-
pos y otros parámetros, y le permite meterlos o editarlos (ahora mismo aparecen mostrados
detalles acerca de algo llamado “Crear - Proceso básico”). Muchos parámetros del modelo se
pueden ver y editar ya sea en la vista del diagrama de flujo o en la de la hoja de cálculo, pero la
segunda le brinda acceso a muchos de los parámetros a la vez, colocados en grupos compactos
de parámetros similares que son convenientes para editar, en especial, modelos grandes. La lí-
nea horizontal que divide las vistas del diagrama de flujo y de la hoja de cálculo (si es que ambas
están visibles) se puede arrastrar hacia arriba y hacia abajo para cambiar la proporción de la
ventana del modelo colocada en las dos vistas.
En la parte de abajo y a la izquierda de la ventana de Arena en la figura 3-1 está la barra de
proyectos, que contiene los paneles con los objetos con los que trabajará, desplegando un panel
a la vez. Ahora mismo la barra de proyectos despliega el panel del proceso básico, que contiene
los elementos fundamentales, llamados módulos, que son útiles en una gran variedad de mode-
los de simulación.
Debajo del panel del proceso básico en la barra de proyectos se encuentra un botón horizon-
tal nombrado como “Reports” (“Reportes”), que desplegará otro panel que contiene un mapa
para orientarse hacia los resultados de una simulación después de que se ejecutó; haga clic en
este botón para hacer visible este panel y después otro clic en el botón Basic Process (proceso
básico) para hacer el panel visible de nuevo.
El panel de navegación le permite desplegar diferentes vistas de un modelo, incluso sub-
modelos diferentes de un modelo jerárquico (el modelo 3-1 no contiene submodelos, así que la
única vista en el panel de navegación es el nivel más alto, aunque si se hace clic en la + que se
encuentra a su izquierda, abrirá un árbol que tiene tres entradas para nuestro modelo, las cuales
se analizarán después en la sección 3.2.3). Si se presiona el botón pequeño ( ) que se encuentra
a la derecha del botón de navegación horizontal, obtendrá también una “pestaña” de la ventana
del modelo en la parte superior del panel de navegación, con un cuadro azul translúcido que
muestra la localización y el tamaño de zoom de la vista actual de la ventana activa. Si hace clic
58 Capítulo 3
en cualquier parte de esta pestaña cambia la vista actual a ese punto. Arrastre el cuadro azul
alrededor para alcanzar otras regiones de la ventana o calcule nuevamente el cuadro azul (colo-
que el cursor en un extremo y después arrastre con el clic) para cambiar la graduación del zoom.
El botón de alternar +/− que se ubica en el círculo de la parte superior derecha de la pestaña
determina si el cuadro azul se muestra relativo a la completa capacidad de la pantalla (la elección
“+”) o toma en cuenta qué región en la ventana tiene realmente contenido (la elección “−”).
La barra de proyectos por lo general está minimizada en el extremo izquierdo de la ventana
de Arena, pero se puede prender y “poner a flote” en cualquier parte de la pantalla o puede
minimizarse en el extremo derecho de la ventana del modelo si así lo prefiere. Por lo general
necesitará que la barra de proyectos sea visible mientras trabaja en un modelo, pero si quisiera
más espacio sólo para ver entre los elementos, puede presionar el botón ∙ del extremo superior
derecho de la barra de proyecto o despejar View > Project Bar para esconderla (vuelva a pre-
sionar View > Project Bar para desplegarla de nuevo).
Existen otros paneles que vienen con Arena, quizá dependiendo de lo que tenga permitido.
Éstos incluyen proceso avanzado (con bloques de desarrollo diferentes y “más pequeños” para
un modelado más detallado), transferencia avanzada (que contiene muchas opciones para mo-
ver entidades alrededor) y bloques y elementos (que juntos le dan un acceso total al lenguaje de
simulación SIMAN que es esencial en Arena; véase Pegden, Shannon y Sadowski, 1995). Aún
más paneles contienen desarrollos para aplicaciones especializadas, como modelado de centros
de contacto y líneas de empaque de alta velocidad. Como se mencionó antes, para hacer que
los elementos estén disponibles en un panel para usarlos en su modelo, tiene que adjuntar el
panel a su modelo a través de File > Template Panel > Attach (Archivo > Panel de plantillas >
Adjuntar), con el botón Template Attach (Adjuntar plantillas) ( ) o al hacer clic en el botón
derecho de un panel y seleccionar Template Panel > Attach en la ventana que aparezca. Los
archivos del panel tienen la extensión del nombre del archivo .tpo y por lo general están en la
carpeta Template dentro de la carpeta Arena 10.0. Si usted desea que Arena adjunte ciertos
paneles a cada nuevo modelo que inicie, presione Tools > Options > Settings (Herramientas >
Opciones > Configuración) y escriba los nombres de los archivos de entre aquellos archivos de
paneles .tpo del cuadro Auto Attach Panels (Paneles de autoadjuntar).
Hasta el extremo inferior de la ventana de Arena se encuentra la barra de estado, la cual
despliega varios tipos de información acerca del estado de la simulación, dependiendo de lo que
esté pasando en ese momento. Justo ahora la única cosa que muestra son las coordenadas (x,
y) en el espacio (véase la sección 3.2.3) de la ubicación del cursor del ratón. Mientras se ejecuta
la simulación, la barra de estado desplegará, por ejemplo, el valor del reloj de la simulación, el
número de réplicas que se están ejecutando y el número de réplicas a ejecutarse. Usted puede es-
conder la barra de estado al despejar (no marcar) View > Status Bar (Ver > Barra de estado).
3.2.3 Tomar vista panorámica, acercamiento, ver y alinear
en la vista del diagrama de flujo
La vista particular del diagrama de flujo de la ventana del modelo que se observa en la figura 3-1
es sólo una de las muchas vistas posibles del modelo y del gran espacio mundial en donde reside la
representación del diagrama de flujo del modelo. El centro del espacio mundial tiene coordenadas
(x, y) (0, 0) y se extiende por miles de unidades en las cuatro direcciones desde ahí; estas unidades
son sólo posicionales y no tienen un significado físico en particular (llámelas estadios o youdels2
si lo desea). Para maximizar el tamaño de la ventana del modelo desde la ventana de Arena, haga
2
Nuestras disculpas a Gene Woolsey.
Un recorrido guiado a través de Arena 59
clic en si está visible en la esquina superior derecha de la ventana del modelo. De igual modo,
para maximizar la ventana de Arena para que ocupe toda su pantalla, haga clic en el botón .
Para observar las diferentes partes de la vista del diagrama de flujo, usted puede tomar una
vista panorámica alrededor usando las barras de despliegue en los extremos inferior y derecha,
o las flechas del teclado (inténtelo; para navegar con su teclado, primero se activa la ventana
del modelo al hacer clic en ella). También puede acercarse (con el botón , la tecla + o View
> Zoom in [Ver > Acercarse]) o alejarse (con el botón , la tecla – o View > Zoom out [Ver >
Alejarse]) para visualizar partes del modelo desde diferentes “perspectivas”. Para seleccionar
vista panorámica/zoom de manera automática y ver todo el modelo con el mayor acercamiento
posible, haga clic en el botón (o View > Views > All (Ver > Vistas > Todas) o la tecla *). Si
usted desea retroceder a la vista anterior (quizá lo estropeó), haga clic en el botón (o View
> Previous [Ver > Anterior]). Si usted se encuentra a una perspectiva relativamente alta pero
divisa una región que le gustaría ver más de cerca, seleccione View > Views > Region (Ver >
Vistas > Región) (o presione la tecla “[”) para cambiar el cursor del ratón a una cruz de líneas
delgadas, haga clic en una de las esquinas de la región rectangular que desee ver y después en
la esquina opuesta. Arena visualizará panorámicamente y se acercará para ver toda esa región
con el mayor acercamiento posible (esto es, la menor perspectiva posible). Otra forma para
visualizar panorámicamente y acercarse es mediante la opción de la pestaña en la barra de
herramientas del navegador, descrita en la sección 3.2.2.
Si usted llega a una vista que desea (y a la que le gustaría regresar de forma instantánea), la
puede guardar como Named View (Vista con nombre) y asignarle una clave. Seleccione y acér-
quese a la vista que desea guardar, después seleccione View > Named Views (o presione la tecla
? o el botón ) y después haga clic en Add (Añadir). Debe darle a la vista un nombre descripti-
vo y, opcionalmente, también asignarle una tecla clave. Para regresar a esta vista en cualquier
momento, seleccione View > Named Views (o presione la tecla ? o el botón ), haga clic en la
vista que desee y presione el botón Show (Mostrar). También puede tener acceso a sus vistas
con nombre en el panel de navegación de la barra de proyectos al hacer clic en la tecla + que se
encuentra a la izquierda (en este caso del nivel alto) para abrir un árbol de las Named Views;
sólo haga clic en una entrada para ir a esa vista. Otra forma (probablemente la más rápida)
para ir a las vistas con nombre es presionar la tecla clave asignada a ella; deberá recordar cuáles
son las teclas activas o quizá documentarlas en el modelo con algún texto, como se describe en
la sección 3.6.3. Las teclas activas para las vistas con nombre son uno de los pocos lugares de
Arena en donde los caracteres son sensibles a mayúsculas/minúsculas (por ejemplo, “a” y “A”
son diferentes). Se puede tener acceso a las vistas con nombre en cualquier momento, incluso
mientras se esté ejecutando la simulación. Configuramos tres vistas con nombre para el modelo
3-1: todas (tecla clave a), lógicas (tecla clave l) y delineadas (tecla clave p). Inténtelas.
Los nuevos modelos de Arena comienzan en una configuración específica de vista pano-
rámica/zoom “Home” (Inicio), justo en el extremo inferior izquierdo de la posición (0,0) en el
espacio mundial, a donde usted puede regresar al presionar la tecla Home (Inicio) en su teclado
(o View > Views > Home). Para ver el área más grande posible del espacio de trabajo (desde
una perspectiva máxima), seleccione View > Views > Max (Ver > Vistas > Maximizar).
Para ir a sus marcas visuales, puede desplegar una rejilla de fondo de pequeños puntos al veri-
ficar View > Grid (Ver > Cuadrícula) (o al hacer clic en ). Si posteriormente usted quiere hacer
que los nuevos artículos colocados se adhieran a esta cuadrícula, intente con View > Snap (Ver
> Encajar) (o haga clic en ). Ambas acciones son teclas de unión; esto es, sólo debe repetir la
acción para deshacer lo que hizo. Para adherir artículos ya existentes a la cuadrícula, primero
60 Capítulo 3
selecciónelos (quizá usando Ctrl + clic para mantener ampliada su selección o arrastrando un
rectángulo a través de ellos, si es que están acomodados de esa forma) y después Arrange > Snap
Object to Grid (Ordenar > Encajar objeto en cuadrícula) para ajustar sus posiciones y alinearlas
con los puntos de la cuadrícula. Para personalizar el espaciado de los puntos de la cuadrícula,
seleccione View > Grid & Snap Settings (Ver > Configuración de cuadrícula y coincidencia); las
unidades son los valores (x, y) de las unidades de medida del espacio mundial. Usted también
puede desplegar Rulers (Reglas) en el extremo superior izquierdo, con las unidades que sean
unidades del espacio mundial de Arena, al presionar el botón o teclear View > Rulers.
Si desea alinear con precisión los objetos en la vista del diagrama de flujo, ya sea horizontal o
verticalmente, con respecto a sus extremos o centros, existen varias opciones para hacerlo. Una
es establecer guías horizontales y verticales en la vista del diagrama de flujo; asegúrese que están
desplegadas las Rulers, después haga clic en el botón Guides (guías) ( ) o seleccione View +
Guides (Ver > Guías) y arrastre hacia abajo desde la regla horizontal en la parte superior o arras-
tre a la derecha desde la regla vertical de la izquierda para colocar la línea punteada de guía azul
(puede ser que tenga varias de cada uno). Después, haga clic en el botón Glue to Guides (Pegar a
Guías) ( ) o seleccione View > Glue to Guides (Ver > Pegar a Guías) y arrastre los objetos hacia
las guías hasta que se encienda un cuadrado rojo de posición para una posición extrema o cen-
tral. Una vez que los objetos están pegados a la guía, puede arrastrar la guía y todos los objetos
pegados a ella se moverán juntos y adheridos con su alineación a la guía. Otra opción es selec-
cionar los objetos que desee alinear y después usar el menú Arrange (Ordenar); seleccione Align
(Alinear) para alinear los objetos seleccionados en sus extremos Superior, Inferior, Izquierdo o
Derecho: seleccione Distribute (Distribuir) para espaciarlos horizontal o verticalmente de ma-
nera uniforme con un espaciado específico en Settings (Configuración). Arrange > Flowchart
Alignment (Ordenar > Alineación del diagrama de flujo) alinea los módulos de los diagramas de
flujo (véase la siguiente sección 3.2.4) en la configuración actual de los objetos seleccionados.
3.2.4 Módulos
Los elementos básicos para los modelos de Arena se llaman módulos. Éstos son el diagrama de
flujo y los objetos de datos que definen el proceso que se va a simular y se eligen de los paneles
de la barra de proyectos. Los módulos vienen en dos formas básicas: diagrama de flujo y datos.
Los módulos de diagrama de flujo describen los procesos dinámicos del modelo. Puede pen-
sar en los módulos de diagrama de flujo como en nodos o lugares a través de los cuales fluyen
las entidades o en donde se originan las entidades o dejan el modelo. Para poner un ejemplo de
un módulo de diagrama de flujo de un tipo particular en su modelo, arrástrelo de la barra de
proyectos hacia la vista del diagrama de flujo de la ventana del modelo (después puede arras-
trarlo alrededor para reposicionarlo). Los módulos de diagrama de flujo por lo general están
conectados entre ellos de alguna manera. En el panel de proceso básico, los tipos de módulos
de diagrama de flujo disponibles son Create, Dispose, Process, Decide, Batch, Separate, Assign
y Record (Crear, Eliminar, Procesar, Decidir, Agrupar, Separar, Asignar y Grabar); otros pane-
les tienen muchos tipos adicionales de módulos de diagrama de flujo. Cada tipo de módulo de
diagrama de flujo del panel de proceso básico tiene una forma distintiva, similar al diagrama
de flujo clásico (véase Schriber, 1969) y sugerente de qué es lo que hace. Pero en otros paneles
(como el panel de proceso avanzado), hay muchos más tipos de módulos de diagramas de flujo
que formas razonables, así que todos están representados por rectángulos simples. Algunos
paneles (como la transferencia avanzada) usan rectángulos de colores para distinguir diferentes
tipos de módulos de diagrama de flujo y otros más (como los especializados para centros de
Un recorrido guiado a través de Arena 61
contacto y paquetería) emplean gráficas más elaboradas. Una forma de editar un módulo de
diagrama de flujo es con un doble clic en él, una vez que está colocado en la vista del diagra-
ma de flujo de la ventana del modelo, para traer el cuadro de diálogo que le pertenezca. Otra
forma de editar módulos de diagrama de flujo es seleccionar un tipo de módulo (por ejemplo,
haciendo clic en Crear o en el módulo Proceso), ya sea en la barra de proyectos o en la vista del
diagrama de flujo de la ventana del modelo, y aparecerá una línea para cada módulo de diagra-
ma de flujo de ese tipo del modelo en la vista de la hoja de cálculo de la ventana del modelo (si
es que es visible), en donde se pueden editar las entradas. Esto le ofrece una visión compacta de
todos los ejemplos de módulos de diagrama de flujo de ese tipo en su modelo, lo que resulta útil
en grandes modelos donde pudiera tener muchas de esas situaciones.
Los módulos de datos definen las características de varios elementos del proceso, como enti-
dades, recursos y colas. También pueden configurar variables y otros tipos de valores y expresio-
nes numéricos que pertenecen al modelo en su conjunto. Los íconos para los módulos de datos
en la barra de proyecto parecen pequeñas hojas de cálculo. Los módulos de datos del panel de
proceso básico son Entity, Queue, Resource, Variable, Schedule y Set (Entidad, Cola, Recurso,
Variable, Programación y Conjunto); otros paneles contienen tipos de módulos de datos adicio-
nales. Las entidades no fluyen a través de los módulos de datos y estos últimos no se arrastran a
la ventana del modelo; más bien, los módulos de datos existen “detrás de escena” en un modelo
para definir diferentes clases de valores, expresiones y condiciones. No se hace doble clic en un
módulo de datos para editarlo, sino sólo un clic en la barra de proyectos y la hoja de cálculo
para que ese tipo de módulo aparezca en la vista de la hoja de cálculo de la ventana del modelo
(que debe estar visible), la cual se puede editar o extender con un doble clic donde se indica para
agregar líneas adicionales. Mientras que lo que viene predeterminado es para editar módulos de
la vista de la hoja de cálculo, si se hace doble clic en el número de la columna izquierda (o un clic
con el botón derecho del ratón y selecciona Edit a través de Dialog) también se puede editar en
el modo de diálogo. A diferencia de los módulos de diagrama de flujo, usted no cuenta con más
de un ejemplo de un módulo de datos en un modelo; sin embargo, podría haber muchas colas
en la hoja de cálculo para un módulo de datos, representando por lo general cada una de ellas
un objeto separado de ese tipo (por ejemplo, si su modelo tiene tres colas diferentes, el módulo
de datos de Queue desplegará tres filas, una para cada cola, en la hoja de cálculo).
Los módulos de diagrama de flujo y de datos de un modelo se relacionan entre ellos por los
nombres de los objetos (como colas, recursos, tipos de entidad y variables) que tienen en común.
Arena mantiene listas internas de los nombres que usted le da a esos tipos de objetos conforme
los define, y después le presenta esos nombres en listas de sugerencias en los lugares apropiados
en ambos tipos de módulos, tanto de diagrama de flujo como de datos, lo que le ayuda a recor-
dar los nombres que puso (y lo protege de sus inevitables erratas... o por lo menos lo mantiene
consistente con su mala escritura de tal forma que su modelo pueda seguir corriendo).
Además de las descripciones del módulo, también puede entrar a Project Description (Des-
cripción de proyecto) que proporciona algo de contexto a todo el modelo. Éste es un buen lugar
para documentar qué es lo que hace el modelo, por qué fue creado, suposiciones que usted se
hizo e información similar. Esto se mete en Run > Setup > Project Parameters (Ejecutar >
Configuración > Parámetros del proyecto) (véase figura 3-15 en este capítulo).
Aunque los Data Tips son una característica útil, en particular cuando los modelos son lar-
gos, se puede preguntar si hay alguna otra manera de hacer uso de esta información. Sí la hay.
Tools > Model Documentation Report (Herramientas > Reporte de documentación del modelo)
crea un reporte personalizado resumiendo todos los datos de su modelo. Proporciona algunas
opciones acerca de qué información incluir y después genera un reporte en HTML.
recursos al hacer doble clic en su línea o al seleccionarla, y después hacer clic en Edit, para traer el
cuadro de diálogo Resources así como en la figura 3-6. Aquí usted define el Nombre del recurso
(Resource Name) y la Cantidad de unidades (Quantity of units) (por ejemplo, servidores indivi-
duales) que las entidades tomadoras tomarán y que las entidades liberadoras soltarán (aquí no
es donde usted especifica el número de unidades del Recurso que existen, eso se hace en el campo
de Capacity [Capacidad] del módulo de datos de Resource y se analizará más adelante). Hacer
un listado de más de un Recurso significa que las entidades tomadoras deben tomar la cantidad
especificada de cada recurso antes de empezar a procesarse, como una máquina y dos operadores,
y las entidades liberadoras soltarán la cantidad especificada de los recursos correspondientes.
Regresando al cuadro de diálogo de propiedades del proceso de la figura 3-5, el cuadro de la
lista de sugerencias de Delay Type ofrece tres distribuciones de probabilidad (normal, triangular
y uniforme), una Constante o una Expresión general. El campo Units determina las unidades de
tiempo para la duración de los retrasos numéricos y el campo Allocation se refiere a cómo se va
a cargar este retraso. Los avisos de la siguiente línea cambian para corresponder a su opción de
Delay Type. Note que la opción de Expresión para el Delay Type permite gran flexibilidad en la
definición de la duración del retraso, incluyendo cualquier otra distribución de probabilidad de
Arena; un clic en el botón derecho del ratón en el campo Expression permite que surja el Expres-
sion Builder (Constructor de Expresiones) (véanse las secciones 3.4.10 y 4.2.4) para ayudarlo.
Cierre el cuadro de diálogo de propiedades de proceso con el botón Cancel; de nuevo, si hizo
algún cambio que desee guardar, haga clic en OK.
La figura 3-7 ilustra la hoja de cálculo de Process, ya sea si usted selecciona cualquier lugar
del módulo Process en la vista del diagrama de flujo de la ventana del modelo o el módulo ge-
neral de Process en la barra de proyectos, con el cuadro de listas de sugerencias con la muestra
del Delay Type (en donde seleccionamos Triangular). Si usted tuviera múltiples módulos de
Process en su modelo, debería haber una fila para cada una de las hojas de cálculo del proce-
so. Así como con los módulos Create, ello le proporciona una manera alternativa para ver de
forma simultánea y editar los campos para su(s) módulo(s) Process. Si hace clic en el botón “1
Rows” (1 Filas) en el campo Resources, aparecerá una segunda hoja de cálculo (véase la figura
3-8) que le permite editar, añadir y borrar recursos equivalentes al cuadro de diálogo Resources
de la figura 3-6 (tiene que hacer clic en el botón ∙ en el extremo superior derecho de la segunda
hoja de cálculo de Resources para cerrarla antes de poder seguir adelante).
Figura 3-9. La hoja de cálculo del módulo Data del recurso para el modelo 3-1
Un recorrido guiado a través de Arena 67
barra de proyectos para ver la hoja de cálculo de Resource en la figura 3-9. La hoja de cálculo le
permite determinar las características de cada recurso en su modelo, así como si su capacidad es
fija o varía de acuerdo con un programa (esa lista de sugerencias se muestra en la figura 3-9, en
donde se seleccionó Fixed Capacity [Capacidad fija]). Usted también puede ocasio-
nar que falle el recurso de acuerdo con algún patrón; intente hacer clic en el botón “0 Rows” de-
bajo del encabezado de la columna Failures (Fallas) para abrir una segunda hoja de cálculo para
esto (el patrón de fallas se define en el módulo datos Failure (Falla) en el panel Advanced Process
(Proceso avanzado), que usted tendría qué adjuntar a la barra de proyectos para su modelo.
Figura 3-10. La hoja de cálculo del módulo Queue Data para el modelo 3-1
Figura 3-11. El cuadro de diálogo de la Resource Picture Placement para el modelo 3-1
68 Capítulo 3
mentos de línea). Para ayudarlo a encontrar estos puntos de entrada y salida, que aparecerán
bastante pequeños si se está demasiado alejado en una perspectiva muy pronunciada, Arena
enciende un cuadro verde para indicarle que puede hacer clic en ese momento y alcanzar un
punto de salida así como un cuadro rojo para un punto de entrada.
Si se tienen muchas conexiones que hacer (quizá usted colocó muchos módulos de diagra-
ma de flujo para bosquejar su modelo), después de cada una se puede hacer clic, con el botón
derecho del ratón, en un lugar en blanco de la vista del diagrama de flujo y seleccionar Repeat
Last Action (Repetir acción anterior) del menú que aparezca para mantener la conexión. Y si
usted de verdad tiene qué hacer muchas conexiones, puede hacer doble clic en el botón Connect
(Conectar) (o hacer Object > Connect dos veces en una fila) y no tiene que preocuparse por el
clic en el botón derecho del ratón; cuando esté listo y desee salir, presione el botón derecho del
ratón o la tecla escape (Esc).
Si selecciona Object > Auto-Connect (Objeto > Autoconexión), Arena conectará de manera
automática el punto de entrada en un módulo nuevo de colocación con cualquier otro módulo
de conexión externa que se seleccione cuando usted coloque el módulo nuevo.
Si selecciona Object > Smart Connect (Objeto > Conexión inteligente), entonces las nuevas
conexiones se ajustan de forma automática para seguir sólo direcciones horizontales y vertica-
les, en lugar de seguir direcciones libres en forma diagonal de acuerdo al lugar en donde estén
los módulos de conexión (a menos que haga clics intermedios mientras que traza una conexión,
en cuyo caso usted obtiene los puntos y las diagonales intermedios). Esto tiene mucho que ver
con el gusto y no tiene una relación con la operación o los resultados del modelo.
Si selecciona Object > Animate Connectors (Objeto > Conectores animados) (o, de manera
equivalente, se introduce Animate Connectors [ ]), entonces Arena mostrará los íconos de en-
tidad (en nuestro caso, las pelotas azules) bajando por las conexiones conforme sucede la trans-
ferencia cuando se ejecuta la simulación. Esto es sólo para hacerle saber durante la animación
que están ocurriendo tales transferencias; hasta donde le concierne a la simulación y a la reco-
pilación de estadísticas, éstas suceden en un tiempo simulado de cero (o, de forma equivalente,
a una velocidad infinita). En la sección 4.4, le mostraremos cómo modelar tiempos de recorrido
diferentes a cero entre las ubicaciones del modelo, incluyendo cómo son animadas.
Si por alguna razón usted quiere mover un punto de conexión (de entrada o salida) a algún
otro lado con relación a este módulo, puede realizarlo, pero primero debe hacer clic con el bo-
tón derecho del ratón en él y seleccionar Allow Move (Permitir movimiento) en la ventana que
aparezca.
Figura 3-14. Los cuadros de diálogo Plot y Plot Expression para el gráfico de
longitud de la cola para el modelo 3-1
mática conforme proceda la simulación. Un clic con el botón derecho del ratón en el cuadro
Expression nos permitió usar el Expression Builder (constructor de expresiones) de Arena para
ayudarnos a introducir el texto correcto aquí (más información acerca del Expression Builder
aparecerá en las secciones 3.4.10 y 4.2.4).
En el cuadro de diálogo Plot, vaya hacia delante y haga doble clic en Expression (o selecció-
nelo y después haga clic en Edit) para obtener el cuadro de diálogo Plot Expression ya llenado,
que se muestra del lado derecho de la figura 3-14. El Minimum (Mínimo) es el valor más pe-
queño del eje y para esta curva, y el Maximum (Máximo) es (ya lo adivinó) el valor máximo del
eje y que queremos permitir para esta curva. Aquí, sabemos que el modelo comenzará vacío y
desocupado, así que resulta claro que el Minimum debe ser 0. Sin embargo, el Maximum es más
bien una suposición a priori, que es posible que haya que ajustar después de hacer la ejecución
y de ver qué longitud de cola máxima resulta; si su suposición en el Maximum es muy grande,
usted hundirá su gráfico hacia el fondo y si subestima el Maximum, lo decapitará (sin embargo,
Arena puede escalar de manera automática, como se analizará después). Los # History Points
(# Puntos históricos) son el número máximo de esquinas en el gráfico que desea permitir para
cualquier tiempo dado; si usted ve que su gráfico se disuelve desde la izquierda conforme avan-
za la simulación, debería aumentar este valor. Debido a que se trata de un gráfico de longitud
de cola, será una constante por segmentos, así que la apariencia Stepped (Escalonada) es apro-
piada. El botón Color (Color) en el cuadro de diálogo Plot Expressions le permite cambiar el
color de la curva (nosotros elegimos el negro), lo que resultará útil si usted dibuja varias curvas
para diferentes Expressions en el mismo conjunto de ejes. Cierre el diálogo Plot Expression con
su botón Cancel para regresar al cuadro de diálogo Plot.
De regreso en el cuadro de diálogo Plot, escribimos 20 en el Time Range (Rango de tiempo)
para permitir suficiente espacio en el eje x para un gráfico con los 20 minutos completos de la
ejecución de la simulación (las unidades, que deseamos sean minutos, están en Base Time Units
[Unidades de tiempo base] para el modelo, como se analizó en la sección 3.3.11). Puesto que esto
Un recorrido guiado a través de Arena 71
es lo suficientemente amplio para toda la ejecución, seleccionamos None for Refresh (Para no ac-
tualizar) (las fracciones por debajo de Refresh [Actualizar] son la sección del gráfico que cambia
el extremo izquierdo, conforme se necesite, para hacer espacio en un futuro cercano en el extremo
derecho). Nos sentimos más seguros con un Bounding Box (Cuadro de división) alrededor de
todo el Border (Límite) y seleccionamos que Fill Area (Rellenar área) inunde el área debajo de la
curva con un color. Si dibujamos varias curvas en la misma gráfica, podríamos medirlas en un eje
y común al seleccionar Synchronize Min and Max (Sincronizar mínimo y máximo) e introducir
nuestras suposiciones sobre el Minimum y Maximum para todas las curvas; en este caso, si des-
pués seleccionamos Y-Labels (Etiquetas Y), entonces podemos seleccionar Auto Scale (Auto-Es-
calar) para que Arena cambie la escala del eje y, según se necesite para todas las curvas, y entonces
nuestras suposiciones en cuanto a los extremos sólo serían los valores iniciales (esto funciona aun
si sólo se está dibujando una única curva). También puede añadir un Title (Título) a su gráfico;
los campos en esa área deberían explicarse por sí mismos (con excepción, quizá, de Percent Height
[Altura porcentual], que es el porcentaje de la altura total del gráfico consumida por el Title). La
opción de las X-Labels (Etiquetas X) nombrarían los valores extremos del eje x, pero haremos
nuestro propio etiquetado en la sección 3.3.10; la opción X-Labels desplegaría en el eje vertical
los valores más altos y los más bajos alcanzados por la(s) curva(s) en el gráfico. Los botones Area
(Área), Border (Límite) y Fill Area (Rellenar área) debajo y a la derecha de la pestaña del gráfico
le permiten seleccionar los colores para esos elementos, elegimos el gris claro para el fondo, gris
oscuro para el llenado del área por debajo de la curva y el negro para el límite (está bien, llámenos
aburridos). Haga clic en Cancel para cerrar el cuadro de diálogo Plot.
El tamaño del gráfico se determina al arrastrar los cabos en sus límites. Haga un clic en el
gráfico e intente esto (no se preocupe, hay una tecla Undo [Deshacer]). De hecho, se debe espe-
cificar un tamaño inicial del gráfico después de llenar los diálogos, pero esto se puede cambiar
después, así como arrastrarlo alrededor para colocarlo de nuevo.
Los cuadros de diálogo Plot y Plot Expressions para el gráfico Drill Press: Number Busy
(Perforadora: número ocupado) son similares, así que no ahondaremos en ellos (pero seguire-
mos adelante y los abriremos para analizarlos). La única cosa de verdad diferente es que Ex-
pression, cuyo valor queremos graficar en el eje y, es NR (Drill Press), que sabemos que siempre
será 0 o 1, así que especificamos que el Maximum en el cuadro de diálogo Plot Expression sea 2
para hacer una gráfica atractiva y de buen gusto. Como antes, usamos el Expression Builder en
la caja Expression del cuadro de diálogo Plot Expression para descifrar que estos son el número
y sintaxis correctos.
Figura 3-15. El cuadro de diálogo Run > Setup > Project Parameters
(Correr > Configurar > Parámetros del proyecto) para el modelo 3-1
la ventana del modelo, dependiendo de la creatividad artística y talento de cada quien (como
puede ver, los nuestros son bastante limitados). Así es como hicimos el sencillo cuadro sombrea-
do detrás del título del modelo en el extremo superior izquierdo de la ventana. La barra de he-
rramientas Arrange (Ordenar) y el menú tienen botones y comandos que le permiten manipular
objetos, tales como agrupar, quitar, enviar un objeto de dibujo al fondo o al frente de un montón
de objetos, etc. Hablaremos más acerca del trabajo de arte en las secciones 3.6.2 y 3.6.3.
Figura 3-16. El cuadro de diálogo Run > Setup > Replication Parameters para el modelo 3-1
Hours Per Day (Horas por día) es de 24 (para responder a la pregunta que de seguro usted se
hace al respecto, sería conveniente definir que un día tenga, digamos, 16 horas en el caso de
una operación de manufactura de dos turnos, si es que se acostumbra a pensar en el tiempo
como días). El cuadro Base Time Units especifica las unidades de tiempo “predeterminado”
en las que se reportarán los resultados a partir del tiempo, así como la forma en que Arena
interpretará algunas entradas numéricas con base en el tiempo que no cuentan con un cua-
dro acompañante de Time Units (como Time Range en el cuadro de diálogo Plot en la figura
3-14). El cuadro Terminating Condition (Condición de término) le permite establecer reglas de
término complejas o dependientes del estado; véase la sección 12.5.2 para un ejemplo en donde
queremos que la simulación continúe corriendo hasta que los resultados alcancen la precisión
estadística que quisiéramos. Sin embargo, el modelo 3-1 simplemente terminará en un tiempo
de 20 minutos. Cierre el cuadro de diálogo Run Setup presionando Cancel.
Hablando de finalización, en cada modelo de Arena hay que especificar cómo quiere que
aquéllos terminen. Esto realmente es parte del modelado. Arena no puede saber qué es lo que
usted quiere, así que no incluya ningún tipo de término “predeterminado”. De hecho, en la
mayoría de los casos, su simulación simplemente continuará ejecutándose por siempre o hasta
que usted intervenga para detenerla, lo que ocurra primero. En la sección 3.8 le mostraremos
cómo poner pausa y después acabar con su ejecución si es necesario.
3.3.12 Ejecución
Para ejecutar el modelo, haga clic en el botón Go (Ir) ( ) en la barra de herramientas Standard
(o Run + Go o presione la tecla F5); note que los botones de este grupo son similares a los de
un reproductor de video. La primera vez que se ejecuta un modelo (y después de hacerle cam-
bios) Arena revisa su modelo en busca de errores (usted puede hacer este paso con el botón
de la barra de herramientas Run Interaction [Ejecutar interacción], con Run > Check model
[Ejecutar > Revisar modelo] o con la tecla F4); si tiene errores, recibirá una educada llamada de
atención al respecto, junto con alguna ayuda para encontrarlos y corregirlos. Entonces podrá
ver ejecutarse la animación del modelo, pero deberá mirar rápido en una ejecución tan corta a
74 Capítulo 3
menos que su computadora se retrase. Durante la ejecución animada, se ven entrar y salir las
entidades de las Partes (las pelotas azules), la Resource Picture cambiando su apariencia con-
forme el estado del Resource oscila entre desocupado y ocupado, la Queue cambia conforme las
entidades de las Partes entran y la dejan, el reloj digital de simulación avanza en la barra de es-
tado y los gráficos se dibujan. Los contadores situados al lado de los módulos del diagrama de
flujo despliegan diferentes cantidades dependiendo del tipo de módulo. Para el módulo Create,
es el número de entidades que se crearon. Para el módulo Process, el número de entidades que
actualmente están ahí en proceso (en servicio más en la cola) y para el módulo Dispose es el
número de entidades que ya dejaron el sistema. Existen otras formas de ejecutar su modelo y
analizaremos algunas de ellas en la sección 3.8.
El estado final de las cosas debería verse parecido a la figura 3-17, con excepción de que
movimos el cuadro de diálogo de Arena (al preguntar sobre ver los resultados) fuera del
camino. Los gráficos despliegan la misma información que en la figura 2-3 de la simulación a
mano. El reloj en la barra de estado está detenido en su valor final y en ese punto vemos que el
Resource está ocupado en la operación de una parte, con otra esperando en la cola (de acuerdo
con el estado final en la simulación a mano en la sección 2.4.3 y la fila inferior de la tabla 2-2).
Los valores finales de los contadores al lado de los módulos de diagrama de flujo también se
encuentran como estaban al final de la simulación a mano en la sección 2.4.3.
El cuadro de Arena que aparece al final de la ejecución pregunta si le gustaría mirar un re-
sumen de los resultados, que es lo que haremos a continuación en la sección 3.3.13. Después de
ver esos reportes (o si elige no hacerlo), la ventana de su modelo aparecerá “colgada” y no se
puede editar nada. Ello se debe a que todavía está en el run mode (modo ejecutar), que le da la
oportunidad de analizar los gráficos y el estado final de la animación. Para salir del run mode y
volver a editar, debe hacer clic en End (Fin) ( ) igual que en un reproductor de video.
figura 3-17. Éste abre una nueva ventana de reportes en la ventana de Arena (separada de su
ventana del modelo). La barra de proyectos ahora despliega el panel Reports (Reportes), que
enlista varios informes diferentes que puede ver, así como Category Overview (Resumen de
categorías), Category by Replications (Categoría por réplicas) y Resources (Recursos). Hacer
clic en cualquiera de estos reportes en la barra de proyectos abre una ventana de reporte por
separado en la ventana de Arena (use el menú de Windows de Arena para mirar qué es lo que
tiene abierto). No olvide cerrar estas ventanas de reporte cuando no esté viéndolas, ya que no
desaparecen por sí mismas si simplemente se regresa a la ventana de su modelo; si cambia su
modelo y vuelve a ejecutarlo, puede terminar con varias ventanas abiertas de reportes diferentes
y tornarse confuso saber cuál de ellas corresponde a determinada variante de su modelo. De
hecho, cuando haga cambios en su modelo para investigar los efectos de diferentes configura-
ciones o suposiciones de parámetros, probablemente deba cambiar un poco el nombre de su
archivo .doe, ya que Arena simplemente sobrescribirá resultados previos en el mismo nombre
de archivo de reporte si usted no lo hace así, por lo que perderá sus resultados previos. (El Pro-
cess Analyzer [Analizador de procesos] de Arena, que se revisa en las secciones 3.6.1 y 6.5, le
proporciona una forma mucho mejor de manejar la actividad de ejecutar múltiples variantes o
escenarios de su modelo y seguir el rastro de los resultados.)
La instalación predeterminada de Arena le trae de forma automática el reporte Category
Overview, que le da acceso a la mayoría de los resultados; los otros reportes enlistados en la
barra de proyectos repiten mucho de esto, pero proporcionan más detalles. Abajo, en el extremo
izquierdo de la ventana de reportes, hay un árbol que usted puede agrandar al hacer clic en los
signos + que hay en él (y contraerlo con los signos −), lo que le brinda un tipo de contorno
sobreenlazado a este reporte completo. El reporte en sí mismo está organizado en páginas, a
través de las cuales usted puede navegar al usar los botones , , y en la parte superior
izquierda de la ventana de reporte. Si usted desea imprimir algunas o todas las páginas del re-
porte que se muestra, haga clic en el botón en la ventana del reporte (no en el botón que se
parece a él arriba en la ventana de Arena, que se oscurecerá y por lo tanto estará desactivado si
la ventana de reportes está activa). Si se desea exportar el reporte a un archivo diferente, inclu-
yendo diversos formatos de hojas de cálculo y de procesadores de textos, haga clic en el botón
de la ventana de reporte y siga las instrucciones ahí.
Pero si lo que busca son sólo unos cuantos resultados específicos, es mejor hacer clic alrede-
dor en los signos + y – en el contorno del árbol en la ventana de reporte. Por ejemplo, para ver
qué pasó con la cola durante nuestra simulación, hicimos clic en una secuencia de signos + en
la sección Queue del reporte (específicamente, Simple Processing [Proceso sencillo] → Queue
[Cola] → Time [Tiempo] → Waiting Time [Tiempo de espera] → Drilling Center.Queue [Centro
de perforación.Cola]), llegando finalmente a la información de Waiting Time, como se muestra
en la figura 3-18. Lo que se selecciona en el árbol se muestra y delinea en el reporte a la derecha,
y de esa línea vemos que el tiempo de espera promedio en la cola fue de 2.5283 (el reporte nos
recuerda que las unidades de tiempo básicas son minutos) y el tiempo de espera máximo fue de
8.1598 minutos (ambos están acorde con los resultados de la simulación a mano en la sección
2.4.4). Un poco más abajo en la vista de la ventana de reporte, debajo de Other (Otro) (al que
podríamos saltar de forma directa al hacer clic en su entrada en el árbol), vemos que el número
promedio de espera (es decir, longitud) de la cola fue de 0.7889 partes y el máximo fue de 3,
ambos concuerdan con nuestra simulación a mano de la sección 2.4.4.
Navegue por este reporte y observe que aquí están todas las medidas de desempeño del
resultado de la tabla 2-3, así como muchas de las otras cosas que Arena recopiló de manera
76 Capítulo 3
Figura 3-18. Parte del Reporte Category Overview para el modelo 3-1
automática (después hablaremos más sobre estas cosas). Al seguir las ramas del árbol como se
indica abajo, encontrará, por ejemplo:
< Simple Processing → Entity → Time → Total Time → Part: el tiempo total promedio en
el sistema fue de 6.4397 minutos y el máximo fue de 12.6185 minutos.
< Simple Processing → Resource → Usage → Instantaneous Utilization (Uso instantáneo)
→ Drill Press: el uso de la perforadora fue de 0.9171 (es decir, estuvo ocupada 91.71%
del tiempo durante la simulación). Las diferentes medidas de uso se analizan en la sec-
ción 4.2.5.
< Simple Processing → Process → Other → Number In → Drilling Center: durante la si-
mulación, siete entidades entraron al módulo Process del centro de perforación.
< Simple Processing → Process → Other → Number Out → Drilling Center: durante la
simulación, cinco entidades dejaron el módulo Process del centro de perforación (dos
menos de los que entraron, que es cuantas partes estuvieron en el centro de perforación
al momento de terminar). El valor de 5 también representa la producción total de este
modelo, dado que las partes salen del sistema inmediatamente después de dejar el centro
de perforación.
< Simple Processing → Entity → Time → Wait Time → Part: de las cinco partes que salie-
ron del sistema, su tiempo de espera promedio en todas las colas (de las que sólo hay una
en este modelo) fue de 3.0340 minutos y el máximo fue de 8.1598 minutos. La razón por
la que el promedio difiere aquí del tiempo de espera promedio en la cola = 2.5283 es que
3.0340 aquí cuenta los tiempos de espera de sólo aquellas cinco partes que salieron del sis-
tema, mientras que el 2.5283 contaba los tiempos de espera de las 6 partes que dejaron la
cola. Los dos máximos, sin embargo, son los mismos en esta ejecución, ya que el máximo
se alcanzó antes en la simulación (los máximos no necesariamente serán siempre iguales).
Un recorrido guiado a través de Arena 77
< Simple Processing → Entity → Other → WIP →Part: El trabajo en proceso (WIP) pro-
medió 1.7060 partes y alcanzó un máximo de cuatro partes en algún(os) momento(s) del
tiempo.
Muchos de los números de los reportes (así como en nuestra simulación a mano en el capítu-
lo 2) pueden clasificarse como estadísticas de cuenta, persistentes en el tiempo o de conteo:
< Las estadísticas de cuenta son aquellas que resultan de tomar el promedio, mínimo o
máximo, de una lista de números. Por ejemplo, el tiempo total promedio y máximo en el
sistema (6.4397 y 12.6185 minutos, respectivamente) son estadísticas de cuenta, ya que
representan el promedio y el máximo de los tiempos totales en el sistema de las cinco
partes que lo dejaron durante la simulación. Las estadísticas de cuenta a veces se llaman
estadísticas de tiempo discreto puesto que su índice “de tiempo” (1, 2, 3, ...) es uno discre-
to del orden del tiempo en que se hacen las observaciones.
< Las estadísticas persistentes en el tiempo son aquellas que resultan de tomar el promedio,
mínimo o máximo (de tiempo), de un gráfico de algo durante la simulación, en donde
el eje x está en tiempo continuo. Los promedios de tiempo continuo involucran el área
acumulada debajo de la curva graficada (es decir, una integral). El promedio y máximo
del número de partes en la cola (0.7889 y 3 partes, respectivamente) son estadísticas
persistentes en el tiempo así como el uso instantáneo de la perforadora (0.9171). Las
estadísticas persistentes en el tiempo se conocen también como estadísticas de tiempo
continuo.
< Las estadísticas de conteo, como su nombre lo señala, son sumas acumuladas de algo. A
menudo, son simples cuentas exactas de cuántas veces sucede algo, como el número de
partes que dejaron el centro de perforación (cinco en nuestra simulación) o que entraron
al centro de perforación (siete). Pero podrían ser acumulaciones de números que no son
todos iguales a 1; por ejemplo, el tiempo de espera acumulado en el centro de perfora-
ción fue de 15.1700 minutos, que representan la suma (no el promedio) de los tiempos de
espera observados ahí en la cola. En el reporte Category Overview, este número se puede
encontrar mediante Simple Processing → Process → Accumulated Time (Tiempo acu-
mulado)→ Acum. Wait Time (Tiempo de espera acumulado) → Drilling Center. Otra
estadística de conteo está en Simple Processing → Resource → Usage → Total Number
Sized → Drill Press, en donde vemos que el recurso de la perforadora se usó (ya sea para
completar la parte o para comenzar) seis veces.
Si se cierra una ventana de reporte, se puede ver después siempre y cuando no se borre (o
se sobrescriba) el archivo de la base de datos Access de Microsoft® que Arena crea conforme
ejecuta la simulación. Este archivo Access se llama model_filename.mdb, en donde mo-
del_filename es como usted nombró a su archivo del modelo .doe (así que en nuestro caso,
el archivo Access se llama Model 03-01.mdb). En la barra de proyectos, seleccione Reports
y haga clic en el reporte que desee (como Category Overview) para verlo de nuevo. La manera
en que esto funciona es que Arena usa un software de un tercer proveedor llamado Crystal
Reports® de Business Objects (http://businessobjects.com) para leer el archivo de la base de
datos Access, extraer las cosas útiles de ahí y después mostrárselas en el formato de ventana
de reporte que se describió antes.
Ahora mismo usted debe estar pensando que esta estructura de reporte es bastante seria
como para sólo obtener de ella un puñado de números para este pequeño modelo, y con pro-
78 Capítulo 3
babilidad lo es. Sin embargo, en modelos grandes y complicados es bastante útil tener esta
estructura para organizar los miles de números de salida diferentes y para ayudarlo a encontrar
cosas y hacer algunas comparaciones y conclusiones rápidas.
Además de los reportes ya descritos, Arena produce un reporte muy compacto (hasta el pun-
to de ser misterioso) de muchos de los resultados de simulación, como un archivo de texto sen-
cillo ASCII llamado model_filename.out (como el Model 03-01.out para nosotros),
como se muestra en la figura 3-19. Algunas de las etiquetas son un poco diferentes; por ejemplo,
las “DISCRETE-CHANGE VARIABLES” (variables de cambio discreto) son las mismas que
Figura 3-19. Archivo del reporte resumido de SIMAN (Modelo 03-01.out) para el modelo 3-1
Un recorrido guiado a través de Arena 79
las estadísticas persistentes en el tiempo. En este archivo se encontrarán muchos de los números de
los reportes de los que hablamos antes (es posible que haya mínimas discrepancias de errores
de redondeo) y aun unos cuantos que no están en los reportes anteriores (como el número de
observaciones usado para las estadísticas de cuenta). Para algunos propósitos, podría ser más
fácil y rápido echar una rápida mirada a esto más que a la estructura del reporte que describi-
mos antes. Sin embargo aquí, el orden, acomodo y etiquetado de los elementos decididamente
es hostil al usuario; este formato es, de hecho, un sobrante de versiones anteriores de Arena y
en realidad se remonta a principios de la década de 1980 y al lenguaje de simulación esencial de
SIMAN. Sin embargo, si aparte de la nostalgia o de la manía por lo compacto, usted desea que
éste sea el reporte predeterminado que le dé Arena cuando pida uno después de que termine la
ejecución, seleccione Run > Setup > Reports y en la lista Default Report (Reporte predetermi-
nado) baje y elija SIMAN Summary Report (archivo .out).
El significado exacto de las etiquetas de reportes como Average, Minimum, Maximum, Ave-
rage Time (Promedio, Mínimo, Máximo y Tiempo promedio) deberían serle claros en este mo-
mento. Pero los reportes también se refieren aquí y allá a Half Widths (Mitad de los Intervalos)
(aunque nunca obtenemos números para ellas en este modelo y sólo está la llamada de atención de
que somos algo insuficientes). Como puede adivinar, éstos pueden ser la mitad de los intervalos de
confianza (ellos estarán en un nivel de 95%) del valor esperado de las medidas de desempeño co-
rrespondientes, suponiendo que nuestra simulación produzca datos adecuados para formarlos.
Si hiciéramos más de una réplica (que no es el caso), Arena tomaría los resultados del re-
sumen para una medida del desempeño del resultado de cada réplica, las promediaría entre el
número de réplicas, calcularía la desviación estándar de la muestra de ellas y al final calcularía
la mitad para un intervalo de confianza de 95% en el valor esperado de esta medida de desem-
peño. Esto es exactamente lo que hicimos a mano ahí en la sección 2.6.2 para varias de las medi-
das de desempeño del resultado, como lo muestra la tabla 2-4. El ejercicio 3-1 le pide hacer esto
con Arena para reproducir (con excepción quizá del redondeo) los resultados en la tabla 2-4.
Si estuviéramos interesados en el comportamiento a largo plazo (o estado constante) del siste-
ma después de quitar cualquier efecto de inicio, deberíamos elegir hacer una réplica o ejecución
(verdaderamente) larga; este tema se aborda en la sección 7.2.3. Si lo hacemos, y nuestra ejecución
es lo suficientemente larga, deberíamos ver números de las mitades de los intervalos de confianza
en los reportes, aun cuando sólo hagamos una réplica. Arena intenta calcular estas mitades de in-
tervalo al dividir en partes una sola ejecución larga, lo que significa servir como suplentes para los
resultados breves verdaderamente independientes sobre las réplicas para hacer los intervalos de
confianza. Hablaremos más al respecto en la sección 7.2.3, incluyendo un análisis de cómo se cal-
culan exactamente estas mitades de intervalo de los datos del resultado de la simulación. La razón
por la que pudiera obtener un “Insuficiente” (o, a veces, “Correlacionado”) en lugar de un valor
numérico para la mitad del intervalo es que la ejecución debe ser lo suficientemente larga para
proporcionar datos en cantidad suficiente y de una calidad adecuada para justificar la validez de
la mitad del intervalo; si su ejecución no es para ello, Arena simplemente se niega a transmitir un
valor basándose en la teoría de que una respuesta errónea es peor que no responder.
El panel adjunto aparecerá en la barra de proyectos, con íconos que representan a cada
módulo de este panel. Haga clic con el botón derecho del ratón para cambiar el tamaño del
ícono o para mostrar el texto sólo para los módulos. Hacer clic en el botón derecho del ratón
en un panel también le permite separarlo si por accidente adjuntó el que no era (también puede
eliminar el panel visible a través de o File > Template Panel > Detach). Puede eliminar un
panel aun si colocó módulos de ese panel en su modelo. Si su muestra no es lo suficientemente
alta para mostrar toda la altura del panel, utilice la barra de desplazamiento a su derecha para
llegar a ella.
Process I
Create I
Dispose I
3.4.4 Despliegues
Conforme introduzcamos nuevos módulos y conceptos, intentaremos llevarlo a través de
cada cuadro de diálogo (o, de manera equivalente, hoja de cálculo). Aun cuando el módulo
Create es bastante sencillo, la descripción anterior fue bastante larga. Para transmitir esto de
forma más compacta, usaremos visuales, llamados Displays (Despliegues), como lo muestra
la pantalla 3-1. Note que existen tres partes en esta pantalla. La parte superior derecha tiene
el cuadro de diálogo lleno (que en la pantalla 3-1 es el mismo que en la figura 3-2). En algunos
casos puede mostrar varios diálogos relacionados. La parte superior izquierda contiene el
módulo con el que se asocia el cuadro de diálogo. Después, esta parte también puede exhibir
botones a los que le dimos clic para obtener el (los) cuadro(s) de diálogo que se muestran en
la parte superior derecha. La parte inferior de la pantalla es una tabla que señala las acciones
que se requieren para completar el (los) cuadro(s) de diálogo. La columna izquierda de la
tabla define los cuadros de diálogo o avisos y la columna derecha contiene los datos o acción
introducidos (cursivas) como cuadros de verificación o botones de comandos. En general,
intentaremos proporcionar la pantalla completa cuando introduzcamos un módulo nuevo
o un nuevo cuadro de diálogo secundario de un módulo que ya hayamos cubierto. Para los
módulos que no sean nuevos, normalmente le daremos sólo la tabla al final de la pantalla,
que puede permitirle recrear con facilidad todos los modelos que desarrollamos. Puede haber
más temas o avisos en un cuadro de diálogo de los que mostramos en una pantalla, para esos
aceptaremos los predeterminados.
Un recorrido guiado a través de Arena 83
Part Arrives
to System
Éste puede ser un buen momento para guardar su modelo; elija un nombre diferente del
nuestro (que era Model 03-01.doe) o póngalo en una carpeta diferente.
Drilling
Center
Ahora, si su perforadora realmente parece un cuadro blanco cuando está desocupada y uno
verde cuando está ocupada, usted esta listo... pero probablemente no sea así. Si hace doble clic
en un cuadro entrará en el Picture Editor (Editor de imágenes), donde puede probar su mano al
dibujar su perforadora en ambos estados que le corresponda. O, si tiene un archivo de gráficas
en algún lugar que represente a su perforadora (posiblemente de una cámara digital), usted
podrá copiar y pegarla en el Picture Editor.
En lugar de eso, tomemos algunas ilustraciones atractivas de una de las carpetas de imágenes
de Arena, bajo la teoría de que si usted fuera bueno en arte o fotografía probablemente no estaría
leyendo este libro. Así que continúe y cierre el Picture Editor para volver al cuadro de diálogo
Resource Picture Placement. Para abrir una librería de imágenes de Arena, haga clic en Open en
la columna derecha y navegue a la carpeta de Arena 10.0 donde verá una lista de archivos con
extensiones de nombre de archivo .plb. Abra Machines.plb (Máquinas.plb) para ver una
galería a la derecha de las creaciones asombrosas de la colección rustbelt. Desplace un poco hacia
abajo y haga clic en , después haga clic (sin soltar) en el botón cuadrado blanco de Idle (Des-
ocupado) a la izquierda y luego en para copiar esta imagen a la izquierda donde se vuelve la
imagen Desocupada en lugar del cuadrado blanco. De forma similar, copie a la derecha para
que se vuelva la imagen Busy (Ocupado) de la izquierda. Finalmente, verifique el cuadro Seize
Area (Tomar área) en la parte inferior de tal forma que la parte que se procesa aparecerá en la
animación. Su cuadro de diálogo de Resource Picture Placement se verá como la figura 3-11 en la
sección 3.3.6 en este punto. Diremos más acerca de las imágenes de Resource en la sección 4.3.3.
Part Leaves
System
Plot Expressions (Expresiones de la gráfica) (diálogo secundario mediante el botón Add [agregar])
Expression (Expresión) NQ (Drilling Center.Queue)
Maximum (Máximo) 5
Color black (negro)
Plot (Gráfico)
Time Range (Rango de tiempo) 20
X-Labels (Etiquetas en X) libre (esto es, sin marcar)
Title – Use Title (Título – usar título) Select (Seleccionado)
Horiz. Alignment (Alineación horizontal) Center (Centrar)
Title Text (Texto de título) Dilling Center Queue: Number Waiting(Fila
del centro de perforación:número en espera)
Pantalla 3-4. Cuadro de diálogo Plot completo para el gráfico de longitud de la fila
otra vez para determinar la esquina opuesta (por supuesto, usted puede recalcular y volver a
colocar el gráfico después).
Aunque es perfectamente válido sólo teclear en NQ(Drilling Center.Queue) de for-
ma manual para la Expression en el cuadro de diálogo secundario Plot Expression, primero
debería saber que ésta es la forma correcta de escribirlo, lo que es probable que usted no sepa
muy bien. Éste es uno de los muchos lugares de Arena en donde puede introducir una expre-
sión algebraica general y, para hacerlo precisamente, con frecuencia tiene que saber exacta-
mente los nombres correctos de varios objetos de su modelo (como Drilling Center.
Queue) y las funciones internas insertadas en Arena (como NQ, que devuelve el número actual
de entidades en la cola nombrada en su argumento). Para ayudarlo con esta tarea de memoria
intensiva (ésa es su memoria, no la de su computadora), Arena proporciona algo llamado Ex-
pression Builder (Constructor de expresiones), al que puede tener acceso haciendo clic con el
botón derecho del ratón en todo cuadro que tenga que ver con cualquier tipo de Expression,
Un recorrido guiado a través de Arena 87
y después seleccionar Build Expression. La figura 3-23 muestra la ventana Expression Builder
después de que expandimos el árbol Expression Type (Tipo de expresión) de la izquierda para
lograr lo que deseamos en el gráfico de longitud de la fila. La etiqueta del cuadro en la parte
superior derecha (ahora Queue Name [Nombre de la cola]) cambiará dependiendo de lo que
seleccionemos en el árbol Expression Type (tipo de expresión); aquí se proporciona una lista
hacia abajo donde podemos especificar la fila para la que queremos saber el Current Number
in Queue (Número actual en la cola) (sólo tenemos una fila en este modelo, así que es una lista
corta). El cuadro Current Expression (Expresión actual) en la parte inferior es la respuesta del
Expression Builder, y hacer clic en OK (Aceptar) en tal punto pega este texto de nuevo en el
cuadro Expression, desde donde comenzamos cuando hicimos clic con el botón derecho del
ratón. Todavía se puede editar y modificar la expresión ahí, así como puede hacerlo en el cua-
dro Current Expression del Expression Builder, tal vez usando sus botones tipo calculadora
para operaciones aritméticas y usando el árbol de la izquierda para observar los nombres de
otras cantidades.
El gráfico para el número ocupado en la perforadora es bastante similar, con sólo dos dife-
rencias de la pantalla 3-4, las cuales están en el cuadro de diálogo secundario Plot Expression.
Primero, haga la Expression (Expresión) NR (Drill Press), una expresión que puede en-
contrar con Expression Builder siguiendo el camino Expression Type Basic Process Variables
→ Resource → Usage → Current Number Busy, y seleccione Drill Press (la única entrada)
debajo de Resource Name. Por último, haga el Maximum 2, ya que conocemos que esta curva
siempre estará a una altura de cero o uno.
Para hacer que los dos gráficos se visualicen de forma armoniosa, los hicimos del mismo
tamaño y los alineamos verticalmente.
88 Capítulo 3
que cuanto más arriba se encuentre en una organización la persona a quien se le presente la
simulación, más esfuerzo se justificará en los gráficos.
3.4.12 Los cuadros de diálogo Run > Setup (Correr > configurar)
Para establecer las condiciones de ejecución, use el comando del menú Run > Setup, donde en-
contrará páginas tabuladas que controlan varios aspectos de cómo se ejecutará su simulación.
Usted necesitará editar sólo dos de estas páginas.
La primera es el tabulador Project Parameters (Parámetros de proyecto), donde usted debe
introducir un Project Title (Título de proyecto), Analyst Name (nombre del analista) (ése es
usted) y Project Description (Descripción del proyecto). Puede que también tenga que modifi-
car la selección de qué estadísticas se recopilarán y reportarán, dependiendo de cómo tenga su
conjunto predeterminado en Tools (Herramientas) > Options (Opciones) > Project Parameters
(Parámetros de proyecto) (queremos Entities, Resources, Queues y Processes). El diálogo ya
completo se muestra en la figura 3-15 en la sección 3.3.11.
El otro tabulador que necesita editar es Replication Parameters (Parámetros de réplica).
Estas ediciones también se analizaron en la sección 3.3.11 y se mostraron en la figura 3-16.
3
Agradecemos al catedrático Jim Morris de la Universidad de Wisconsin-Madison por recomendarnos este do-
cumento.
90 Capítulo 3
Revisar
Solicitudes
el crédito
que llegan
(Alfie)
Preparar el
convenio
(Betty)
Precio del
préstamo
(Chuck)
Desembolso
de los fondos Solicitudes
(Doris) completas
cada solicitud, los pasos deben hacerse en ese orden. El tiempo para cada paso es de distribu-
ción exponencial con media de 1 hora, independientemente de los otros pasos y del proceso de
llegada. Inicialmente, el sistema está vacío y desocupado, y lo ejecutamos por 160 horas (alrede-
dor de un mes de trabajo); véase el capítulo 5 para otras formas de reglas de detención con base
en conteos de entidades y otras condiciones. Las medidas de desempeño de salida incluyen el
número promedio y el número total máximo de solicitudes en proceso y el tiempo total prome-
dio y máximo, desde la entrada hasta la salida, que pasan las solicitudes en el sistema, así como
su tiempo de espera para que el siguiente paso comience. Hay cuatro trabajadores disponibles
(Alfie, Betty, Chuck y Doris) todos igualmente calificados para cualquiera de los cuatro pasos
y la pregunta es cómo emplearlos mejor.
Modelo 3-2
Solicitud de préstamo serial especializado
Alfie revisa
Llega solicitud
el crédito
Betty prepara
el convenio
Applications in Process
(Solicitudes en proceso)
Chuck pone
precio al
préstamo
Doris
Salen la
desembolsa
solicitudes
los fondos
Time (Hours)
[Tiempo (horas)]
Figura 3-26. Modelo 3-2 completo con el primer módulo Process y su diálogo Resources
Ya que los tiempos de proceso exponencial no están entre las opciones Delay Type, en su
lugar elija Expression y después use el Expression Builder (ir a “Random Distri-
butions” [“Distribuciones aleatorias”]) para llenar el campo Expression,
como se observa en la figura 3-26. Las unidades de tiempo aquí también son horas.
< Aparte del nombre (Name), el módulo Dispose es el mismo que el modelo 3-1.
< La imagen de la entidad predeterminada (módulo de datos de la entidad, Picture.
Report) está bien aquí ya que las entidades son, completamente, reportes de las solici-
tudes de préstamo.
< Las animaciones predeterminadas de Resource casi siempre están bien, pero nosotros
hicimos que la imagen Desocupado también tuviera un relleno blanco en lugar del verde
predeterminado (haga doble clic en el ícono de animación de Resource para obtener la
ventana Resorce Picture Placement, después doble clic en los íconos de Busy [Ocupado]
e Idle [Desocupado] sucesivamente y use la herramienta Fill Color [Rellenar color]).
Recuerde seleccionar en el campo Identifier el nombre correcto de Resource para cada
uno de los cuatro casos. También, revise el cuadro Seize Area.
< Los módulos de datos de Queue y Resource se llenan automáticamente de forma correcta
si los módulos Process se configuraron primero. Las predeterminaciones para todo (por
ejemplo, Type y Capacity para cada uno de los cuatro Resources) aplican en este modelo.
92 Capítulo 3
< El gráfico (Plot) dinámico expone el número total de solicitudes en proceso, que es la
Expression de Arena EntitiesWIP(Application), y se puede encontrar en Expre-
ssion Builder bajo Basic Process Variables, después Entity y por último Num-
ber in Process. “WIP” es un acrónimo para trabajo en proceso (work in process).
Las otras entradas del diálogo Plot son parecidas a las del modelo 3-1, ajustadas, claro,
para la diferente estructura de tiempo y el valor máximo del eje y.
< En Run > Setup, en el tabulador Project Parameters, revise el cuadro de Processes en
Statistics Collection e ingrese alguna documentación en otro lugar; en el tabulador Re-
plication Parameters ingrese 160 para la Replication Length (Longitud de réplica) y
asegúrese de que tanto Time Units como Base Time Units estén en horas.
< Después de algunas ejecuciones iniciales, y al notar las longitudes máximas de la fila,
alargamos sus animaciones un poco hacia la izquierda para acomodarlas.
Ejecute este modelo y observe en el reporte Category Overview (Visión general de categoría)
para encontrar, entre otras cosas, que:
< El número promedio y total máximo de solicitudes en proceso fueron, 12.3931 y 21 res-
pectivamente (vía Loan Application → Entity → Other → WIP).
< El tiempo promedio y total máximo, desde la entrada hasta la salida, que pasaron las
solicitudes en el sistema fueron 16.0831 horas y 27.2089 horas respectivamente (Loan
Application → Entity → Time → Total Time). Note que esto cuenta sólo para aquellas
solicitudes que hayan dejado el sistema cuando se detiene la simulación, no para aque-
llas que aún estuvieran en proceso en ese momento (ya que, por supuesto, su tiempo
total en el sistema no se ha terminado).
< El tiempo promedio y total máximo que las solicitudes pasan esperando para que el
siguiente paso de proceso inicie fueron 11.9841 horas y 22.2732 horas, respectivamente
(Loan Application → Entity → Time → Wait Time). Esto incluye sólo el tiempo “des-
perdiciado” de espera en la fila, y no el tiempo “de valor agregado” pasado sometido al
proceso en los cuatro pasos, así que es una buena medida de la ineficiencia en el sistema.
Arena cuenta en esta estadística el tiempo de espera total en las cuatro filas sólo para
aquellas solicitudes que completaron los cuatro pasos y salieron del sistema; los tiempos
de espera en las filas individuales están bajo Loan Application → Queue → Time y,
como se observó para el modelo 3-1, pueden incluir más entidades que aquellas incluidas
para todo el ancho del sistema promedio y máximo.
< Durante las 160 horas, 117 solicitudes se completaron (Loan Application → Entity →
Other → Number Out), lo que nos da una medición de productividad.
< Alfie, Betty, Chuck y Doris estuvieron ocupados, 82.33, 70.34, 80.44 y 80.80% del tiem-
po, respectivamente.
< Alfie, Betty, Chuck y Doris procesaron, respectivamente, 128, 128, 122 y 117 solicitudes
(Loan Application → Process → Other → Number Out). En este modelo, todas las so-
licitudes pasaron por estas personas en este orden, así qué estos números en este orden
pueden disminuir o mantenerse igual. (¿Bajo qué condiciones serían todas iguales? ¿Es
eso posible en este modelo?)
La principal ineficiencia de este sistema es la espera en la cola que las solicitudes deben so-
portar, y hay cuatro lugares diferentes donde ello puede suceder. También, existe la posibilidad,
como en la figura 3-25, de que las solicitudes pudieran hacer fila en alguna estación mientras
otros empleados están desocupados, lo que parece una pérdida de recursos.
Un recorrido guiado a través de Arena 93
Alfie (los
4 pasos)
Betty (los
Solicitudes 4 pasos)
Solicitudes
que llegan completas
Chuck (los
4 pasos)
Doris (los
4 pasos)
Modelo 3-3
Solicitud de préstamo paralelo generalizado
Una de las
Llega la personas pro-
cesa los Sale solicitud
solicitud
cuatro pasos
Applications in Process
(Solicitudes en proceso)
Time (Hours)
[Tiempo (horas)]
Figura 3-28. Modelo 3-3 completo con el módulo Process y su diálogo Resources
94 Capítulo 3
El modelo de Arena para esto, modelo 3-3, es de hecho más simple que el modelo 3-2, apa-
rece en su forma completa en la figura 3-28 con el (único) módulo Process y muestra su diálogo
Resources. Los módulos Create y Dispose son idénticos al modelo 3-2, como lo es el Plot diná-
mico y el diálogo Run > Setup (excepto para etiquetar).
El principal cambio es que los cuatro módulos Process del modelo 3-2, cada uno de los
cuales representaban a un solo empleado, se reemplazan por un único módulo Process que re-
presenta a los cuatro empleados. Se sustituyeron los cuatro recursos unitarios en el modelo 3-2
con un recurso único de cuatro unidades, que llamamos Loan Officer (observe el módulo
de datos Resource en el modelo 3-3). Note que, en el diálogo de Resources del módulo Process
que se muestra en la figura 3-28, el campo Quantity sigue siendo 1, que representa el número de
unidades del recurso Loan Officer que son tomados y soltados por cada entidad Appli-
cation; aquí no es donde especificamos que hay cuatro unidades de este recurso en existencia,
sino más bien en la columna Capacity del módulo de datos Resource.
Y puesto que ahora cada empleado debe llevar a cabo las cuatro tareas en tándem antes de
tomar la siguiente solicitud de la cola, debemos hacer el tiempo Delay más largo en el módulo
Process. Cada uno de los cuatro pasos requiere EXPO(1) horas para completarse, así que sim-
plemente agregamos cuatro de éstas en el campo Expression en el área Delay Type del módulo
Process; como se observa en la figura 3-28, cada uno representa los cuatro pasos del proceso
(está bien hacer operaciones aritméticas dentro de un campo Expression en cualquier parte de
Arena). Ahora suponemos que, si usted está leyendo un libro como éste, probablemente le fue
bien en sus clases de álgebra de séptimo año, así que sabe que sumar cuatro cosas iguales es lo
mismo que multiplicar esa cosa por 4, por lo que se preguntará por qué no nos ahorramos algo
al teclear e introdujimos algo como 4*EXPO(1) en su lugar. Bueno, el problema con eso es que
puede hacer sólo una sola “tirada” de la distribución exponencial y multiplicar ese único resul-
tado por 4, lo que significa en nuestro caso que cada uno de los cuatro pasos toma exactamente
la misma cantidad de tiempo, no lo que queremos. Así que, desagradable como es, EXPO(1)
+ EXPO(1) + EXPO(1) + EXPO(1) es lo que necesitamos ya que esto hace cuatro tiradas
separadas, independientes de la distribución exponencial para representar cuatro tiempos sepa-
rados, independientes para los cuatro pasos.
Por último, un cambio en la animación Resource haría las cosas un poco más realistas (pero
aún no completamente correctas), aunque podría no ser necesario que sean correctas para el
modelo o sus resultados. Primero, cambie el ícono al hacer doble clic en la animación Resource
y después el ícono Idle para obtener la ventana Resource Picture Placement, y duplicar el cua-
drado blanco tres veces y alinearlos todos de forma vertical. Después seleccione y copie todo
esto, regrese (sólo cierre la ventana), abra el ícono Busy y péguelo para reemplazar lo que ya
esté allí. De regreso en la ventana del modelo, haga doble clic en los dos círculos concéntricos
que representan el Seize Area para ir al diálogo Seize Area, seleccione Points, y después Add
tres veces para obtener tres áreas de tomar más relacionadas para este recurso de unidades múl-
tiples; cierre el diálogo Seize Area y arrastre éstas hacia donde pertenecen dentro de los cuadros
(puede necesitar cerrar Snap to Grid para tener todo correcto). Entonces, en la animación verá
tantos íconos de entidad en la animación de Resource como entidades haya en servicio en cual-
quier momento. Lo que aún no hace esto completamente correcto es que los íconos para las en-
tidades en servicio siempre se empujarán hacia el Area Seize original (los círculos concéntricos
dobles) en lugar de quedarse en donde “pertenecen”, si se observan los cuadros de arriba hacia
abajo como si fueran para Alfie, Betty, Chuck y Doris (se puede realmente tener esto correcto al
Un recorrido guiado a través de Arena 95
usar Resource Sets en los recursos de unidad simple, en lugar de un recurso simple de unidades
múltiples, como se analiza en el modelo 5-2 del capítulo 5).
Esta configuración paralela de trabajo integrado parece proporcionar un mejor servicio que
la configuración de trabajo especializado de serie. El número promedio y número total máximo
de solicitudes en proceso aquí son, respectivamente, 4.6118 y 10, comparados con 12.3931 y 21
de la configuración en serie. El tiempo promedio y tiempo total máximo en el sistema de las
solicitudes aquí son 5.3842 y 13.7262 horas, respectivamente, menor que las 16.0831 y 27.2089
horas del modelo en serie. Aquí el tiempo promedio y máximo de espera gastados en la cola es
de, respectivamente, 1.3282 y 6.8231 horas, marcadamente menor que las 11.9841 y 22.2732 ho-
ras de la configuración de serie. La productividad aumentó de 117 a 135 solicitudes terminadas,
aunque tal mejora está por supuesto limitada por el índice de llegada. Todas estas mejoras se
deben al menor tiempo desocupado entre los empleados; el empleo del recurso Loan Officer,
definido como el tiempo promedio de unidades ocupadas (que se calcula en 3.48) dividido entre
4, fue 87%, comparado con el promedio de 78.48% sobre los cuatro empleados individuales en la
configuración de serie. Nosotros nunca tuvimos una situación como la de la figura 3-25 en donde
los trabajos se forman aunque los recursos estén desocupados. Por supuesto, tales comparaciones
provienen de una sola réplica de cada modelo 3-2 y 3-3, así que nos encontramos sobre una frágil
base estadística, como se analizó en la sección 2.6 (véase ejercicio 6-19).
Figura 3-29. Módulo Process completo para Alfie en el modelo 3-4 con tiempos de tarea constantes
mos qué sucede si no hay variabilidad, esto es, si cada tiempo de tarea toma exactamente una
hora (y por lo tanto, cada solicitud requerirá exactamente cuatro horas de tiempo de proceso en
total). Quizá podemos movernos hacia esto con un mejor apoyo para las tareas, tanto con base
en computadoras de oficina, o a través de perfeccionar la investigación de antecedentes previos.
Puesto que en realidad no está bajo nuestro control, mantendremos el proceso de llegada igual,
esto es, con tiempos entre llegadas que tengan una distribución exponencial con media 1.25
horas, así este modelo mantendrá alguna entrada estocástica (aleatoria).
Ahora, ¿cómo se comparan las configuraciones serie y paralela? Modificamos el modelo
3-2 para obtener el modelo 3-4, donde cada uno de los cuatro módulos Process se manipularon
para hacer que el tiempo de tarea correspondiente fuera exactamente una hora. Esto fue muy fácil
Figura 3-30. Módulo Process completo para el modelo 3-5 con tiempos de tarea constantes
Un recorrido guiado a través de Arena 97
de hacer; en cada uno de los diálogos del módulo Process sólo cambiamos Delay Type a Cons-
tant en el menú de sugerencias, fijamos Value en 1, y nos aseguramos que Units se mantuviera en
Hours. La figura 3-29 muestra esto para Alfie y los otros tres funcionan de la misma forma.
De forma similar, creamos el modelo 3-5 a partir del modelo 3-3 con sólo deshacernos del
desagradable EXPO(1)+EXPO(1)+EXPO(1)+ EXPO(1) en el módulo Process para el tipo
Expression Delay, cambiando el Delay Type a Constant e introduciendo un Value de 4 horas;
la figura 3-30 muestra el diálogo del módulo Process completo.
La tabla 3-1 resume los resultados de tiempo de servicio constante de los modelos 3-4 y
3-5 (mitad inferior) y repite aquéllos de los tiempos de servicio exponencial de los modelos 3-1
y 3-2 (mitad superior), redondeando a dos decimales. Para los modelos de servicio constante
(3-4 y 3-5) aún podría haber alguna mejora al ir de la operación de serie a la paralela, pero sólo
una muy ligera (y podría aún no ser estadísticamente significativa, por el ejercicio 6-19). Evi-
dentemente, cuando los tiempos de servicio tienen poca o ninguna variabilidad no hay mucha
diferencia entre los diseños de trabajo de serie especializado y paralelo generalizado.
Por supuesto, usted podría plantear algunas preguntas, como:
< En el modelo de trabajo integrado paralelo, ¿no esperaría que estas personas generaliza-
das fueran por lo menos un poco menos eficientes que si ellas se especializaran en hacer
sólo una cosa? Nuestro modelo 3-3 no permite esta posibilidad, pero sí los ejercicios
3-13 y 6-20.
< Cuando se trata con recursos humanos, ¿no necesitan un poco de tiempo desocupado,
quizá a través de descansos programados, para tomar un respiro y mantenerse frescos?
Los Resource Schedules (programas de recursos), que se pueden usar para modelar tales
descansos, se analizarán en los capítulos 4 y 5.
< Las mejoras de pasar de un diseño de serie a uno paralelo, ¿son estadísticamente signi-
ficativas, o pueden ser sólo falsas, es decir, el resultado de una simple fluctuación de la
muestra (después de todo, sólo realizamos una réplica simple de cada configuración)?
Esto se retomará en el capítulo 6 y en los ejercicios 6-19 y 6-20.
3.6.1 Menús
Aquí se da una vista general rápida de lo que hay en los menús de Arena. Algunas opciones
en ciertos menús se irán atenuando (significa que no las podrá seleccionar) si no aplican en su
situación en particular o en la situación en el momento. Para mayor información acerca de
entradas a los menús recuerde que puede oprimir y después usarlo para hacer clic sobre
cualquier artículo del menú (atenuado o no) con el fin de obtener documentación completa al
respecto, incluyendo hipervínculos con temas relacionados.
Menú File (Archivo). Aquí es donde usted crea nuevos archivos de modelos en Arena, abre los que
ya existen, cierra ventanas y guarda sus modelos. También es donde adjunta y separa paneles de la
barra de proyectos. También puede importar dibujos CAD de AutoCAD® (y de otros programas
CAD en formato estándar DXF) para usar como “fondos” de Arena
y, en algunos casos, activar elementos (como caminos para vehículos
guiados por cable) para permitirle usar dibujos detallados existentes
de instalaciones. Otro tipo de archivo de gráficos que puede importar
son los de dibujo de Microsoft® Visio® en formato .vsd. Si cambia los
colores que usa Arena, puede guardarlos como una paleta de colores
(puede hacer algo de esto también con Windows®); también puede
abrir paletas de colores previamente guardadas. Las funciones de im-
presión de Arena son accesibles desde este menú. El comando Send
(Enviar) le permite remitir correos desde Arena y adjuntar cualquier
modelo activo a su mensaje. Arena recuerda los documentos más re-
cientes y usted puede abrirlos rápidamente. El comando Exit (Salir)
es una de las formas de abandonar Arena.
Menú Edit (Editar). Aquí encontrará las opciones usuales como se
aplican a objetos en los modelos de Arena. Usted puede Undo (Deshacer) acciones previas o Redo
(Rehacer) sus undos. Puede Cut (Cortar) o Copy (Pegar) un objeto seleccionado (o grupo de ob-
jetos) al Clipboard (Portapapeles) para colocarlos en cualquier
otro lado del modelo actual, o importalos a otros modelos, o
en algunos casos, a otras aplicaciones. Paste (Pegar) le permite
insertar los contenidos del Clipboard (Portapapeles) en un mo-
delo, y Paste Link (Pegar hipervínculo) crea un vínculo OLE
con el documento fuente que actualmente esté en el Clipboard
(Portapales). Duplicate (Duplicar) realiza una copia de lo que
está seleccionado y la coloca cerca en el modelo actual, mien-
tras Delete (Borrar) elimina permanentemente lo que se haya
seleccionado. Puede Seleccionar todos (Select All) los objetos
en un modelo así como deseleccionarlos (Deselect All). Con
Entity Pictures (Imágenes de la entidad) puede cambiar lo que
se presenta en la lista en el módulo de datos Entity, así como la
apariencia de esas imágenes; usted puede copiar imágenes en
esta lista de las bibliotecas de imágenes de Arena (archivos .plb). El comando Calendar Schedules
(Programas calendario) le permite describir patrones complejos de tiempo con jerarquías (las
semanas están formadas por días, que están compuestos de turnos, y así sucesivamente), define
excepciones como días festivos y vacaciones y muestra el efecto de red neto de todo esto en una
vista compuesta. La función Find (encontrar) de Arena busca todos los módulos y objetos de
Un recorrido guiado a través de Arena 99
animación en el modelo activo para una serie de textos, con el control usual sobre las búsquedas
de palabras completas y sensibilidad al caso (esto puede ser de utilidad para encontrar entradas
que usted no pensaba que tenía, pero sobre las que está teniendo algún mensaje de error). Puede
desplegar Properties (Propiedades) de objetos adicionales, como su única etiqueta. Si tiene en su
modelo vínculos a otros archivos, como a una hoja de cálculo o archivo de sonido, Links (Víncu-
los) le comenta acerca de ellos y le deja modificarlos. Insert New Object (Insertar nuevo objeto) le
permite hacer colocaciones de otras aplicaciones, como gráficas y multimedia, e Insert New Con-
trol (Insertar nuevo control) permite la inserción de un control VBA®/ActiveX®. Object (Objeto)
le hace posible editar algo que haya llevado al modelo desde otra aplicación.
Menú View (Ver). Desde este menú se puede controlar cómo se presenta su modelo en la pantalla,
así como qué barras de herramientas quiere que aparezcan. Usar el zoom le permite ver el modelo
desde diferentes “perspectivas”, de tal forma que pueda ver la imagen completa o secciones más
pequeñas con mayor detalle. El Zoom Factor (Factor zoom) le deja
controlar qué tanto aumenta o disminuye cada vez. Views (Vistas)
(cuyo submenú se muestra) ofrece ciertas vistas “enlatadas” de su
modelo; y Named Views (Vistas nombradas) lo deja definir, cambiar
y usar sus propias vistas. Rulers (Reglas), Grid (Cuadrícula), Guides
(Guías), Glue to Guides (Pegar a guías) y Snap to Grid (Coincidir
con cuadrícula) son útiles si usted quiere alinear las cosas geográ-
ficamente; Grid & Snap Settings (Configuración de cuadriculado
y coincidencia) le brinda control sobre el espacio de Grid & Snap
(reticulado y coincidencia). Page Breaks (Salto de página) muestra
su modelo indicando cómo se dividirá en páginas para la impresión.
Data Tips (Consejos de datos) le brinda opciones para mostrar las
propiedades del objeto en consejos de herramientas si deja el ratón
sobre ese objeto. Connector Arrows (Flechas conectoras) le permite
poner puntas de flechas en conectores para visualizar la dirección
del flujo de la entidad. Layers (Capas) le deja controlar qué tipos
de objetos se muestran durante el modo editar o correr. Si Split Screen (Dividir pantalla) está
palomeado (activado), la ventana de su modelo mostrará tanto las vistas del diagrama de flujo
como de la hoja de calculo simultáneamente. Si Runtime Elements Bar (barra de elementos de
ejecución) está marcada, despliega una ventana para permitirle escoger qué se muestra durante la
ejecución. Toolbars (Barras de herramienta) es una forma en que pueda designar qué conjuntos
de botones se muestran en su pantalla (véase la sección 3.6.2), Project Bar (Barra de proyectos)
cambia de estado por si la barra de proyectos (que presenta el panel) es visible y la entrada Status
Bar (Barra de estado) le permite decidir si usted quiere ver la barra horizontal en la parte más baja
de la pantalla, la cual le dice qué está pasando e indica las coordenadas en el espacio del cursor
del ratón en el área de trabajo de Arena. Si Debug Bar
(Barra de depuración) está seleccionada, muestra una
ventana de herramientas para depurar durante una eje-
cución.
Menú Tools (Herramientas). Arena News Flash es una
forma de alimentación con base en Internet para ac-
tualizaciones, etc. Arena no sólo incluye la capacidad
de modelar con la que hemos pasado nuestro tiempo
100 Capítulo 3
hasta este momento, sino que también contiene una aplicación de herramientas relacionadas
que posiblemente dependan de su licencia. El Arena Symbol Factory (Fábrica de símbolos
Arena) proporciona una gran colección de objetos gráficos en muchas categorías a partir de
las cuales puede crear símbolos gráficos para la animación de elementos como entidades y re-
cursos. El Input Analyzer (Analizador de entradas) instala distribuciones de probabilidad a sus
datos observados del mundo real para especificar entradas del modelo (véase la sección 4.6.4).
El Process Analyzer (Analizador de procesos) organiza formas eficientes para hacer ejecuciones
múltiples de simulación, que pueden representar diferentes configuraciones del modelo y dar se-
guimiento a los resultados; también le ayuda a llevar a cabo análisis estadísticos apropiados de
los resultados de su simulación, como una forma confiable de seleccionar la mejor entre varias
conFiguraciones diferentes de modelos. Otra aplicación con capacidades estadísticas adiciona-
les, llamada Output Analyzer (Analizador de salidas), viene con Arena pero se debe de cargar
por separado (está en la carpeta Arena 10.0). Le mostraremos cómo usar el Process Analyzer
y el Output Analyzer en las secciones 6.5 y 6.4, respectivamente. Report Database (Reportar
base de datos) exporta un reporte de estadísticas desde una ejecución a un archivo CSV (Com-
ma-Separated Values [Valores separados por una coma]) para leerlo en una hoja de cálculo en
un análisis posterior al procesamiento. ContactCenter (Centro de contacto) (mostrado con su
submenú abierto) brinda funciones especiales para modelar centros de contacto/llamadas. Mo-
del Documentation Report (Reporte de Documentación del modelo) produce un conjunto de
información, compacto pero completo, incluyendo condiciones de ejecución, módulos usados y
cualquier submodelo. Export Model to Database (Exportar modelo a base de datos) le permite
guardar los detalles de su modelo en una base de datos Access o Excel; Import Model from Da-
tabase (Importar modelo de base de datos) le deja traer esos detalles desde dicha base de datos
para construir o actualizar rápidamente un modelo. OptQuest para Arena es una aplicación
que decide cómo cambiar las entradas del modelo que usted selecciona y después ejecuta una
secuencia de simulaciones para buscar una combinación de estas entradas que optimice (maxi-
mice o minimice) una medida de desempeño de salida que usted designe; daremos un ejemplo
de su uso en la sección 6.6. AVI Capture (Captura AVI) permite grabar muchas acciones, inclu-
yendo edición y animación, en un archivo de video (.avi) para reproducirlo. El elemento Macro
proporciona las herramientas para grabar y ejecutar macros de Visual Basic (VB) y abrir el VB
Editor (Editor VB) para escritura lógica a la medida. Estos temas VB son analizados en la sec-
ción 10.2. Por último, el elemento Options (Opciones) le deja cambiar y personalizar mucho de
cómo funciona y se ve Arena para adaptarla a sus necesidades (o gustos).
Menú Arrange (Ordenar). Aquí los objetos se refieren a la posición de los módulos del modelado
y objetos gráficos; algunos aplican sólo a objetos gráficos. Bring to Front (Traer objeto al frente)
y Send to Back (Mandar objeto al fondo) colocan a los objetos seleccionados al frente y atrás,
respectivamente, de un “montón” de objetos que pueden estar superpuestos.
Group (Agrupar) y Ungroup (Desagrupar), respectivamente, colocan jun-
tos y subsecuentemente separan objetos con lógica, sin afectar su apariencia
física; agrupar es útil si se quiere mover o copiar una imagen compleja com-
puesta de muchos objetos individuales. La entrada Flip (Mover objeto verti-
cal u horizontalmente) invierte los objetos seleccionados por una línea en la
dirección indicada y Rotate (Rotar) hace girar 90° la selección en el sentido
de las manecillas del reloj. Align (Alinear) forma los objetos seleccionados
en los márgenes superior, inferior, izquierdo o derecho. Distribute (Distri-
buir) alinea los objetos seleccionados en partes iguales tanto en dirección
Un recorrido guiado a través de Arena 101
horizontal como vertical, y Flowchart Alignment (Alineación del diagrama de flujo) ordena los
módulos seleccionados del diagrama de flujo de igual forma tanto vertical como horizontalmente.
Snap Object to Grid (Coincidir objeto con cuadrícula) obliga a la selección a alinearse a la cua-
drícula de puntos y Change Object Snap Point (Cambiar el punto de coincidencia del objeto) le
permite alterar el punto exacto en el objeto seleccionado que coincidirá.
Menú Object (Objeto). Estos elementos se refieren a la estructura lógica del modelo, sus módulos
de diagramas de flujo y las conexiones entre las piezas lógicas del modelo. Connect (Conectar)
cambia el cursor a una cruz de líneas delgadas y le permite es-
tablecer gráficamente una conexión entre los módulos para que
sigan las entidades; seleccionarlo dos veces configura una “se-
sión” Connect (Conectar) para uso repetido (haga clic con el
botón derecho del ratón o presione Esc para terminar la sesión).
Auto-Connect (Auto-conectar) es un interruptor que le deja co-
nectar automáticamente un módulo colocado recientemente
a uno que ya estaba seleccionado. Smart Connect (Conexión
inteligente) hace que las conexiones agregadas recientemente se dibujen en segmentos horizon-
tales/verticales en lugar de posibles líneas diagonales, a menos que haga clics intermedios si está
haciendo la conexión a mano. Animate Connectors (Animar conectores) hace que las entidades
se muestren conforme se mueven a lo largo de las conexiones entre los módulos de diagrama de
flujo, aun si este movimiento ocurre de forma instantánea en la simulación. Si Animate at Des-
ktop Color Depth (Animar con color de fondo de escritorio) está marcada, ejecuta la animación
con todos los colores en su computadora, lo que puede hacer lenta aquélla; si no está marcada,
la animación corre a 8 bits de profundidad de color sin lentitud. Submodel (Submodelo), cuyo
submenú se muestra, le permite definir y administrar los submodelos jerárquicos.
Menú Window (Ventana). Si tiene varios modelos abiertos a la vez, puede ordenarlos físicamen-
te en forma de Cascade (Cascada) que se traslapa, o por Tile (Mosaico), sin traslaparse. Si tiene
varios modelos minimizados (vía el botón en cada ventana), seleccione
Arrange Icons (Ordenar íconos) para organizarlos. La entrada Use Sys-
tem Background Color (Utilizar color de fondo del sistema) provoca que
este modelo emplee cualquier color de fondo seleccionado en el nivel de
sistema operativo de Windows® en lugar del de la configuración interna
de Arena; para regresar su modelo al color interno de Arena, seleccione
102 Capítulo 3
de nuevo aquél. (Este elemento de menú cambia entre “System” [Sistema] y “Custom” [Perso-
nalizado] cada vez que lo selecciona.) Por último, puede activar un modelo que ya esté abierto
al seleccionarlo en la parte inferior del menú.
Menú Help (Ayuda). Ésta es una de las diversas formas de entrar al sistema de Ayuda en línea de
Arena (véase sección 3.7 para más información de Help [Ayuda]). Si usted selecciona la ayuda
de Arena, llegará a la plataforma de Contents (Con-
tenidos), a un Index (Índice) y a una herramienta
Search (Buscar) para acceder al tema que quiera.
What’s This (¿Qué es esto?) cambia el cursor a
que puede usar luego para hacer clic en la entrada
de un menú o botón de barra de herramientas para
descubrir un poco más acerca de él. Release Notes
(Liberar notas) tiene información de los cambios re-
cientes y requerimientos del sistema. Arena SMART
Files (Archivos SMART de Arena) produce un índice
basado en temas para un par de cientos de pequeños modelos de Arena que ilustran una gran
variedad de técnicas específicas de modelado. También en este menú encontrará tópicos generales
de ayuda en cualquier panel de modelado que haya adjuntado en ese momento. Product Ma-
nuals (Manuales de producto) lo lleva a documentos detallados de los diferentes componentes del
software Arena y productos relacionados. Arena Assistance on the Web (Asistencia de Arena en
Internet) lo remite directamente a una página Web con la ayuda más reciente e información del
software (por supuesto, tiene que estar en línea para que esto funcione). Las últimas tres entradas
en este menú proporcionan información de soporte y capacitación; la protección de derechos y
los procedimientos de activación usados para versiones comerciales y otras de Arena, así como
información detallada de la versión.
< Aunque se puede elegir ocultar la barra de herramientas Standard (Estándar), es un poco
difícil hacer algo sin ella:
Inicia con los botones para crear un modelo nuevo (New), abrir (Open) uno existente y
guardar (Save) el modelo activo, como en el menú File (Archivo); también de ese menú
hay botones para adjuntar (Attach) un panel o retirar (Detach) el que está visible, y para
imprimir (Print) y hacer una vista preliminar (Print Preview). Del menú Edit (Editar) están
Cut (Cortar), Copy (Copiar) y Paste (Pegar), así como Undo (Deshacer) y Redo (Rehacer).
A continuación se encuentra el botón Toggle Split Screen (Activar pantalla dividida) para
una ventana de modelo dividido, y después la lupa para ver una región (View a Region) que
usted seleccione con ella en la vista de diagrama de flujo de la ventana del modelo con el
aumento más cercano posible. Usted puede escoger un porcentaje de Zoom (Acercamiento)
de la lista de sugerencias. El botón Layers (Capas) le permite controlar qué tipos de objetos
se muestran en la vista del diagrama de flujo de la ventana del modelo, tanto en el modo
editar como en ejecutar. Se pueden agregar los módulos de diagrama de flujo Submodel y
Connect. También puede crear y manejar los diseños de tiempo calendario y sus excepciones
con Edit Time Patterns (Editar diseños de tiempo) y Edit Exceptions (Editar excepciones).
Display Composite View (Desplegar vista de composición) le permite manejar la capacidad
y eficiencia de los datos asociados con elementos específicos del sistema (como programar
un recurso para estar disponible en dos turnos en lugar de uno). Los siguientes seis botones
son controles de ejecución, y se analizarán en la sección 3.8. La barra de desplazamiento le
permite acelerar o desacelerar la animación durante una corrida. La barra de herramientas
Standard (Estándar) termina con el botón Help (Ayuda) sensible al contexto; haga clic en
él (note el signo ? que se queda en el cursor del ratón), después haga clic en un botón de
la barra de herramientas, un comando del menú o un módulo en la Project Bar (Barra de
proyectos) para saber más de él.
< Los botones de la barra de herramientas Draw (Dibujo) no tienen opciones que correspon-
dan a algún menú, así que sólo se puede dibujar al acceder por la barra de herramientas:
Así es como usted puede dibujar líneas estáticas, líneas múltiples, arcos de límites de
elipse, curvas de Bézier, cuadros, polígonos y elipses para arreglar su modelo, así como
agregar texto para anotar en él. También hay controles para cambiar el color de las
líneas (incluyendo las formas de los bordes), llenar objetos, texto y el fondo de la vista
del diagrama de flujo de la ventana del modelo. Usted puede alterar el ancho y estilo de
las líneas (grosor, si lo hubiera o no, al igual que diseños de guiones), y poner puntas
de flechas en ellas. Line Patterns (Diseños de línea) brindan diferentes apariencias de
líneas pre dibujadas, como carreteras, caminos y correas. Fill Pattern (Diseño de relleno)
provee diseños de entramado para las formas. Show Dimensions (Mostrar dimensiones)
le permite desplegar los tamaños de las formas y líneas para dibujar con precisión. Usted
probablemente ha usado características de dibujo en otras aplicaciones, así que las
posibilidades de Arena le serán familiares. Con mucho, la mejor forma de familiarizarse
con ellas es abrir una ventana de modelo de “prueba” y experimentar; véase la sección
3.6.3 para más información de dibujo.
104 Capítulo 3
Por lo general, haga clic en uno de estos botones, entre en el cuadro de diálogo para
describir exactamente qué es lo que quiere y después coloque la animación en su modelo.
Hay muchas características diferentes aquí, e ilustraremos la mayoría de ellas conforme
avancemos en el desarrollo de modelos en capítulos posteriores (ya hemos usado Plot
y Resource). Por ahora, coloque su ratón sobre cada botón para mostrar el Tooltip
(consejo de la herramienta) con su nombre.
< La barra de herramientas Integration (Integración) contiene botones relacionados al
asistente llamado Arena Module Data Transfer (Módulo de transferencia de datos de
Arena) y VBA (el Visual Basic Editor [Editor de Visual Basic] y botón VBA Design
Mode [Modo diseño VBA]):
Desde aquí usted puede Manage Named Views (Manejar vistas nombradas), Zoom In
(Acercar) y Out (Alejar), o escoger ver todo el modelo (View All) o una vista previa
(View Previous). También puede revelar las Rulers (Reglas) y Grid (Cuadrícula), crear
Guides (Guías), mostrar las páginas divididas para impresión, y dividir (Snap) nuevos
objetos de la cuadrícula (Grid), así como pegarlos (Glue) a las guías (Guides).
< La barra de herramientas Arrange (Ordenar) corresponde estrechamente con el menú
Arrange (Ordenar):
Usted puede traer (Bring) un objeto seleccionado hacia el frente o enviarlo al fondo. Una
selección de múltiples objetos de dibujo puede agruparse de forma lógica y desagruparse
después. Los objetos de dibujo también pueden moverse alrededor de una línea vertical
u horizontal en su punto medio o rotar (Rotate) 90° en el sentido de las manecillas del
reloj. Asimismo puede alinear (Align) los objetos seleccionados en sus márgenes superior,
inferior, izquierdo o derecho, al igual que dividirlos tanto horizontal como verticalmente.
Por último, usted puede coincidir (Snap) objetos seleccionados a la cuadrícula.
< La barra de herramientas Run interaction (correr interacción) tiene los botones Check
Model, Command, Break, Watch y Break on Module (Comprobar modelo, Comando,
Pausa, Observar y Pausa en módulo) que corresponden a las entradas del menú Run
Un recorrido guiado a través de Arena 105
(Ejecución) (véase la sección 3.8 para más información). El último botón corresponde a
los Animate Connectors (Conectores de animación) del menú Object:
< La barra de herramientas Record Macro (Grabar macro) tiene botones para Start/Pause/
Resume (comenzar/pausa/continuar) así como Stop (detener) la grabación de un macro
VB. Un macro es una serie de instrucciones de Visual Basic almacenadas en una subruti-
na en un módulo Visual Basic (los macros se analizan en el capítulo 10):
3.6.3 Dibujar
La barra de herramientas Draw (Dibujar), mencionada en la sección 3.6.2, tiene una variedad
de formas, herramientas de texto y características de control que le permiten mejorar el modelo
al colocar objetos estáticos (sin participar en la simulación o animación) en su ventana, con el
fin de ayudar a documentar cosas o hacer que la animación parezca más “real” agregándole
elementos como paredes, pasillos y plantas en macetas. Esto no intenta ser un CAD completo
lleno de características o capacidad de trabajo de arte, pero generalmente es adecuado; por
supuesto, usted siempre puede importar gráficas de otros paquetes, como se mencionó en la
sección 3.4.11. Las herramientas de dibujo de Arena funcionan de forma muy similar a otros
paquetes de dibujo, así que nosotros sólo señalaremos qué hay y lo dejaremos jugar con ellas
para que se acostumbre:
< Line (Línea), : haga clic una vez en este botón y el cursor del ratón cambiará a una cruz
de líneas delgadas; después presione dondequiera que la línea comience y de nuevo donde
sea que termine. Para obligar a la línea a ser vertical u horizontal o en un ángulo de 45°,
mantenga presionada la tecla Shift (mayúsculas) mientras se mueve al final de la línea.
< Polyline (Multilínea), : ésta le permite dibujar una línea quebrada con un número ilimi-
tado de puntos. Después de seleccionar este botón, haga clic donde quiera comenzar y de
nuevo para cada punto nuevo; haga doble clic para el punto final. Mantenga presionada la
tecla Shift (mayúsculas) en un segmento para obligarlo a ser vertical, horizontal o de 45°.
< Arc (Arco), : dibuja parte del borde de una elipse. Primero haga clic en el centro de la
elipse, luego mueva el ratón y siga el límite externo, haga clic de nuevo cuando llegue al
tamaño y forma deseados (mantenga presionada la tecla Shift (mayúsculas) para obligar
a que la elipse forme un círculo). En este punto, el cursor del ratón se convierte en el final
de una línea que proviene del centro de la elipse; haga clic para definir un final del arco,
106 Capítulo 3
después para el otro final. Para editar el arco posteriormente, selecciónelo y emplee las
líneas para cambiar la parte del arco mostrada y use el asa desconectada para modificar
el tamaño o forma de la elipse.
< Bézier Curve (Curva de Bézier), : éstas se han vuelto populares debido a su habilidad
de adquirir una gran variedad de formas, ya que mantienen su suavidad y belleza in-
herente. Haga clic para un extremo, después haga clics intermedios (hasta 30) para los
puntos interiores “atrayentes”; haga doble clic para colocar el otro extremo. Mantener
presionada la tecla Shift (mayúsculas) mientras se mueve al siguiente punto hace que
las líneas (invisibles) que se conectan a ellos sean horizontales, verticales o de 45°. Para
cambiar la curvatura, seleccione la curva y jale los puntos interiores atrayentes de alre-
dedor; arrastrando los extremos, se ancla la curva a diferentes lugares. Mueva la curva
al tirarla directamente.
< Box (Cuadro), : primero haga clic para una esquina, después otra vez para la esquina
opuesta. Mantenga presionada la tecla Shift (mayúsculas) para darle forma de cuadrado.
Este objeto, como los dos siguientes, tiene un borde considerado como una “línea” para
color y estilo, así como un “relleno” para opciones de color o diseño.
< Polygon (Polígono), : haga clic para el primer punto, luego mueva a nuevas ubicacio-
nes para hacer clic en ellas; haga doble clic en el punto final, el que usted quiere que se
conecte de nuevo con el primero. Mantenga presionada la tecla Shift (mayúsculas) para
hacer que los segmentos sean horizontales, verticales o de 45°. Este objeto tiene un borde
de línea y un relleno como el de Box (cuadro).
< Ellipse (Elipse), : primero haga clic para ubicar el centro, mueva el ratón y siga la línea
exterior vinculada al tamaño y forma que usted quiera, y por último haga clic de nuevo.
Mantenga presionada la tecla Shift (mayúsculas) para forzarlo a ser un círculo. Este ob-
jeto tiene un borde de línea y un relleno como el de Box (cuadro).
< Text (Texto), : así es como usted agrega anotaciones a su modelo para nombrar cosas
o proporcionar información. Al hacer, clic el botón presenta un cuadro de diálogo don-
de usted escribe su texto; use Ctrl + Enter para ir a una línea nueva y Ctrl + Tab para
un tabulador. El botón Font (fuente) le deja cambiar la fuente, el estilo y el tamaño. Al
cerrar este cuadro de diálogo cambia el cursor del ratón a una cruz de líneas delgadas,
con el que usted puede hacer clic donde quiera para colocar la esquina superior izquier-
da de su texto. Use el subrayado para mover, cambiar el tamaño o reorientar el texto a
un ángulo diferente (mantenga presionada la tecla Shift [mayúsculas] para mantener el
ángulo horizontal, vertical o en 45°).
< Line Color (Color de línea), : si se selecciona un objeto de línea (una línea, multilínea,
arco, curva de Bézier, o el borde de una forma), al hacer clic en el botón en la parte del
pincel cambia ese objeto al color que subraya el pincel. Hacer clic en la flecha que se des-
pliega cambia el objeto de línea seleccionado al color que se haya elegido de la paleta, y
muda también el color del subrayado. Los objetos de líneas nuevos estarán en el color sub-
rayado. Arena recordará este color de línea no sólo para objetos de línea futuros en esta
ventana, sino para ventanas nuevas y sesiones posteriores, hasta que lo cambie de nuevo.
< Fill Color (Color de relleno), : éste funciona en el interior de una figura (cuadro, po-
lígono o elipse) igual que Line Color (Color de línea) lo hace en los objetos de línea.
< Text Color (Color de texto), : éste opera en los objetos de dibujo de texto como fun-
ciona Line Color (Color de línea) en los objetos de línea.
Un recorrido guiado a través de Arena 107
< Window Background Color (Color del fondo de ventana), : éste configura el color del
fondo de la vista de diagrama de flujo de la ventana del modelo al color que se seleccione
de la paleta cromática.
< Line Width (Ancho de línea), : actúa en el grosor de los objetos de línea igual que
Line Color (Color de línea) lo hace sobre su color.
< Line Style (Estilo de línea), : proporciona diseños de guiones para las líneas. La op-
ción No Line (sin línea) hace a la línea invisible pero sigue estando allí (esto puede tener
sentido para el borde de una figura).
< Arrow Style (Estilo de flechas), : brinda diversas puntas de flecha para las líneas.
< Line Pattern (Diseño de líneas), : proporciona diferentes apariencias de línea pre
dibujadas, como caminos, veredas y correas.
< Fill Pattern (Rellenar, patrón), : funciona en el diseño para el interior de una figura
como Line Color (Color de línea) manipula su color.
< Show Dimensions (Mostrar dimensiones), : exhibe el tamaño de las formas y longi-
tudes de las líneas y segmentos de línea para un dibujo preciso.
3.6.4 Imprimir
Todo o partes de la vista del diagrama de flujo de la ventana del modelo activo se puede im-
primir directamente de Arena (en color, si lo tiene). File > Print Preview (o ) le permite ver
previamente qué es lo que viene; File (Archivo) > Print (Imprimir) (o o Ctrl + P) lo deja
imprimirlo, y File (Archivo) > Print Setup (Configuración de impresión) le permite seleccionar
un controlador de impresión o configurar su impresora.
Si su modelo es grande, la impresión se extenderá a varias páginas. Y si usted tiene Named
Views (Vistas nombradas) obtendrá una impresión de la vista actual, seguida de una impresión
separada de cada vista con nombre. Si no quiere todo esto, use Print Preview para ver qué hay
en cada página, luego imprima selectivamente sólo las páginas que desee. La opción del menú
View (Ver) > Pages Breaks (Pausas de páginas) mostrará en la vista del diagrama de flujo dónde
terminarán las hojas si se imprime el modelo.
Como una alternativa para imprimir directamente de Arena, recuerde que usted puede con-
seguir la vista que quiera (quizá aun durante una pausa en la animación); para ello presione
la tecla Prnt Scrn (imp pant) (Print Screen [Imprimir pantalla]), cámbielo a su documento de
procesador de palabras y pegue la toma donde usted la quiera. Después podrá imprimir este
documento cuando guste. También podrá pegar la imagen Prnt Scrn en un programa de pintura
y quizá recortarlo o por el contrario limpiarlo (de hecho, así es exactamente como obtuvimos
todas las piezas de la ventana de Arena de este libro).
3.7 ¡Ayuda!
Arena tiene un sistema de Ayuda amplio y detallado que sirve como referencia, lo guía a través
de varias operaciones y proporciona ejemplos de modelado de facetas así como para completar
proyectos. El sistema de ayuda está cuidadosamente integrado y proporciona detallados hiper-
vínculos a otras áreas para auxiliar a obtener la información que necesite de forma rápida y
fácil. Hay formas diferentes de acceder al sistema de ayuda, que describiremos brevemente en
esta sección. Sin embargo, verá que la mejor forma de aprender acerca de la ayuda es entrar
en ella y comenzar a explorar.
En cualquier momento, usted puede ingresar a todo el sistema de ayuda desde el menú Help
(Ayuda). Los contenidos de este menú fueron descritos antes, al final de la sección 3.6.1.
108 Capítulo 3
El botón evoca ayuda sensible al contexto. Para usarlo, sólo haga clic en el botón, luego
en lo que tenga curiosidad (un botón de barra de herramientas, un comando de algún menú, un
módulo en la barra de proyecto) y obtendrá la información que necesite vía camino visual.
La mayoría de los cuadros de diálogo de Arena tienen un botón Help (de ayuda) que puede
presionar. Ésta es una buena forma de obtener información directa sobre qué parte del software
se trata, cuáles son sus opciones, cómo se definen las cosas relevantes, los conceptos relaciona-
dos (a través de hipervínculos a otras partes del sistema de ayuda) y ejemplos. También puede
usar el botón ? en la parte superior del cuadro de diálogo para ingresar a la información de
ayuda What’s This? (¿Qué es esto?) en elementos individuales en un cuadro de diálogo. Simple-
mente haga clic en ? y después en el elemento seleccionado.
En caso de que se le olvide qué hace un botón en particular, usted puede dejar sin mover el
cursor en él durante uno o dos segundos; un pequeño Tooltip (Consejo de herramienta) cuadra-
do aparecerá para recordarle lo que es.
Los archivos SMART, mediante el menú Help (Ayuda), son modelos de Arena clasificados
por tema (un par de cientos) que ilustran, mediante pequeños modelos de trabajo, una gran
variedad de habilidades de modelado Arena.
La ayuda en línea se encuentra disponible en la forma de notas técnicas y actualizaciones,
en http://support.rockwellautomation.com. Usted puede configurar su propia cuenta en ella (es
gratis) para descargar lo último en dichos temas.
En la carpeta Examples (Ejemplos), contenida a su vez en la carpeta Arena 10.0, hay varios
modelos detallados que usted puede abrir, mirar, copiar, editar (para que sea seguro, editar
una copia) y ejecutar. Si usted tiene una versión académica u otra limitada de Arena, no podrá
correr sus modelos hasta su terminación, debido al límite en el número de entidades concurren-
tes. Si abre un modelo grande (uno que sobrepase los límites de la versión académica), Arena
introducirá un modo de ejecución. Tal modo le permite hacer cambios mínimos y ejecutar el
modelo, pero no permite cambios significativos como agregar y borrar módulos. Los modelos
de ejemplo ilustran aspectos diferentes para su construcción y estudio. El tema4 “Example Mo-
dels” (Modelos de ejemplo) de Help (Ayuda) tiene una descripción de lo que hay en cada uno.
4
Para ir a un tema específico de Ayuda, seleccione Help Arena Help (Ayuda de Arena) Index (Índice), teclee el
nombre del tema en la primera región, y después abra (haga doble clic, o un clic y luego marque en Display [desplegar])
el índice de temas en la segunda región de abajo.
Un recorrido guiado a través de Arena 109
< Run > Go (Ejecutar > Ir) (o desde la barra de herramientas Standard o la tecla de fun-
ción F5) sólo hace eso (o lo reanuda después de una pausa). Si usted ha hecho cambios al
modelo desde la última revisión (véase más abajo), se llega a revisar antes de ejecutar.
< Run > Step (Ejecutar > Paso) (o o F10) ejecuta el modelo una acción a la vez así usted
podrá ver en detalle que está pasando. Esto es muy aburrido así que es útil principalmen-
te como una herramienta de depuración o demostración. Como con el botón Go, el uso
de Step hace que el modelo se revise si Arena detecta cambios desde que se llevó a cabo
la última revisión.
< Run > Fast-Forward (Ejecutar > avance rápido) (o ) invalida la animación y ejecuta la
corrida a un índice más rápido. Usted puede hacer pausa en cualquier momento durante
la corrida para ver la animación. Fast-Forward (Avance rápido) hace que el modelo se
revise si Arena detecta cambios desde que se realizó la última revisión.
< Run > Pause (Ejecutar > pausa) (o o Esc) interrumpe la corrida para que usted pueda
ver cualquier cosa. Presione , o para reanudarla.
< Run > Start Over (Ejecutar > Comenzar de nuevo) (o o Shift + F5) regresa hasta el
principio de una simulación y vuelve a ejecutar el modelo. Start Over hace que el modelo
se verifique si Arena detecta cambios desde que se hizo la última verificación.
< Mientras que Arena corre su modelo, está en lo que se llama modo correr y la mayor
parte de las herramientas de desarrollo del modelo están inutilizadas. Así que cuando se
finaliza la ejecución, necesita seleccionar Run > End (Ejecutar > Terminar) (o o Alt +
F5) para salir del modo correr y habilitar las herramientas de modelado nuevamente. Si
usted puso pausa a su ejecución antes de que finalizara, esto la acabará en ese punto.
< Utilice Run > Check Model (Ejecutar > Verificar modelo) (o o F4) para “recopilar” su
modelo sin correrlo. Si Arena detecta errores en esta etapa, se los hará saber (gentilmente,
por supuesto) en una ventana de Errors/Warnings (Errores/Advertencias); los botones en
la parte inferior de esta ventana le ayudan a encontrar el problema (por ejemplo, al selec-
cionar el módulo ofensivo en la vista del diagrama de flujo de la ventana del modelo).
< Run > Review Errors (Ejecutar > Revisar errores) recuerda la más reciente ventana
Errors/Warnings que contiene lo que sea que Arena haya encontrado que está mal du-
rante la verificación.
< Run > Run Control > Command (Ejecutar > Control de Ejecución > Comando) (o )
lo lleva a una ventana de comando de línea interactiva que le permite controlar mucho
de cómo se hace la ejecución, como interrupciones y valores alterados. Esto también
verifica el modelo, si se requiere, y comienza la corrida si es que aún no lo hizo.
< Run > Run Control > Breakpoints (Ejecutar > Control de Ejecución > Puntos de pausa)
(o ) le permite configurar los tiempos y las condiciones para interrumpir el modelo con
la finalidad de verificar o ilustrar algo.
< Run > Run Control > Watch (Ejecutar > Control de Ejecución > Observar) (o ) es-
tablece una ventana en la que se puede observar el valor de una variable o expresión
conforme progresa la ejecución. Run > Setup > Run Control (Ejecutar > Configuración
> Control de Ejecución) le deja determinar si esto es concurrente con la ejecución o sólo
cuando la ventana Watch está activada (lo último acelerará las cosas).
< Run > Run Control > Break on Module (Ejecución > Control de Ejecución > Pausa en
módulo) (o configura o despeja una ruptura en el módulo seleccionado. Una ruptura
en el módulo detiene la ejecución cuando una entidad comienza o reanuda la ejecución
de la lógica para el módulo.
110 Capítulo 3
< Run > Run Control > Highlight Active Module (Ejecución > Control de Ejecución > Se-
ñalizar módulo activo) hace que el módulo de diagrama de flujo se destaque cuando se está
ejecutando, lo que proporciona un indicador visual de la acción durante la animación.
< Si está marcada Run > Run Control > Batch Run (No animation) (Ejecución > Control
de Ejecución > Ejecutar modelo en lotes) (sin animación), el modelo se correrá sin ani-
mación alguna. Esto es aun más rápido que el Fast-Forward (Avance rápido) y por lo
general se usa cuando el proyecto está en modo de producción para elaborar estadísticas
adecuadas para un análisis preciso.
< Run > SIMAN le permite ver o escribir a un archivo el archivo del modelo (.mod) y el
archivo del experimento (.exp) para el código en el lenguaje de simulación SIMAN sub-
yacente que su modelo Arena genera. Para entender esto, por supuesto que se tiene que
saber algo acerca de SIMAN (véase Pegden, Shannon y Sadowski, 1995).
3.10 Ejercicios
3-1 Haga cinco réplicas del modelo 3-1 con sólo pedirlas en Run > Setup > Replication
Parameters. Observe los resultados y note cómo las medidas de desempeño varían entre las ré-
plicas, confirmando la tabla 2-4. Para ver los resultados para cada una de las cinco réplicas por
separado, tendrá que abrir el reporte Category by Replication; sin embargo, los semianchos del
intervalo de confianza se pueden ver en el reporte Category Overview.
3-2 Implemente la modificación a la llegada de doble tiempo al modelo 3-1, analizado en la
sección 2.6.3, al abrir el módulo Create y cambiar el Valor de 5 a 2.5 para la media de la dis-
tribución exponencial para el tiempo entre llegadas (Time Between Arrivals) (no olvide hacer
clic en OK, en lugar de en Cancel, si usted desea que suceda este cambio). Haga cinco réplicas
y compare los resultados con los que obtuvimos en la simulación a mano (véase la figura 2-4).
Para conocer los resultados de cada una de las cinco réplicas de manera individual, tendrá que
abrir el reporte Category by Replication.
3-3 Alargue la ejecución del modelo 3-1 a 12 horas para una muestra más interesante. Si
usted quiere que los gráficos sean completos, deberá abrirlos y extender el Time Range (¡fíjese
en las unidades!), así como posiblemente el valor máximo para el eje y en el gráfico Number in
Queue. También puede ser que necesite aumentar los # History Points (# de Puntos de historia)
en el Number in Queue Plot. Haga una sola réplica.
3-4 Implemente el cambio al modelo 3-1 descrito en el ejercicio 2-4 del capítulo 2. Abra el
módulo Process, cambie el Delay Time a Expression y anote la Expression adecuada (use el
Expresión Builder [Constructor de expresiones] si lo desea). Corra el modelo durante 20 minu-
Un recorrido guiado a través de Arena 111
tos y verifique los resultados contra los obtenidos de la simulación a mano. Si son diferentes,
¿cuál podría ser la explicación (suponiendo que lo hizo todo bien)? Después, intente correr esto
durante 24 horas y observe el gráfico de longitud de fila (para ambos gráficos, cambie el Time
Range a 1440 y los # History Points a 1000, y en el gráfico de longitud de fila, modifique el
máximo para el eje y a 50). Para permitir más espacio en la animación de la fila, haga clic en la
línea para la fila y arrastre su límite izquierdo hacia la izquierda. ¿Qué sucede? ¿Por qué?
3-5 Implemente la función de recopilación estadística adicional descrita en el ejercicio 2-1 y
añada un gráfico que rastree el número total de partes en el sistema (también llamado trabajo
en proceso, con su abreviación en inglés WIP) en el tiempo. Note que en cualquier punto dado
en el tiempo de simulación, WIP es el número en la fila más el número en servicio; usted tam-
bién debería usar el Expresión Builder (Constructor de expresiones) y revisar el tema Entities
WIP Variable (Variable de entidades WIP) en Ayuda.
3-6 Modifique el modelo 3-1 con todos los cambios siguientes:
< Añada una segunda máquina a la que vayan todas las partes de inmediato después de
dejar la primera máquina para un tipo de proceso por separado (por ejemplo, la primera
máquina perfora y la segunda limpia). Los tiempos de proceso en la segunda máquina
son los mismos que los de la primera. Reúna las estadísticas de antes más el tiempo en la
cola, la longitud de ésta y el uso en la segunda máquina.
< Inmediatamente después de la segunda máquina, existe una inspección de correcto/error
que toma 5 minutos constantes para llevarse a cabo y tiene un 80% de probabilidades de
tener un resultado correcto; es posible hacer cola en la inspección y la fila es primeras
entradas primeras salidas. Todas las partes dejan el sistema sin importar si pasan o no la
prueba. Cuente el número de las que no la pasan y el de las que sí y reúna las estadísticas
del tiempo en la cola, longitud de ésta y uso en el centro de inspección. (PISTA: Intente
con el módulo diagrama de flujo Decide (Decidir).)
< Incluya gráficos para rastrear la longitud de fila y el número ocupado en las tres estacio-
nes. Configúrelos como se necesite.
< Corra la simulación durante 480 minutos en lugar de 20.
3-7 En el ejercicio 3-6, suponga que las partes que fallan la inspección después de lavarse se
envían de regreso y se lavan de nuevo en lugar de retirarse; tales partes relavadas deben enton-
ces someterse a la misma inspección y tienen la misma probabilidad de fallar (aunque parezca
improbable). No existe un límite en cuántas veces una parte dada debe pasar de nuevo por la
lavadora. Corra este modelo bajo las mismas condiciones que en el ejercicio 3-6 y compare los
resultados para el tiempo en la cola, longitud de ésta y uso en el centro de inspección. Por su-
puesto, esta vez no hay necesidad de contar el número de partes que fallan y pasan, puesto que
finalmente todas pasarán (¿o no?). Puede que tenga que dejar más espacio en alguna animación
de la fila y en los ejes y de los gráficos.
3-8 En el ejercicio 3-7, suponga que la inspección puede dar uno de tres resultados: pasar
(probabilidad 0.80, como antes), fallar (probabilidad de 0.09) y lavarse de nuevo (probabilidad
0.11). Las que fallan se retiran de inmediato y las que se lavan de nuevo regresan a la lavadora.
Las probabilidades anteriores mantenidas para cada parte se someten a inspección, a pesar de
su historia pasada. Cuente el número de las que al final fallan y de las que pasan y reúna las
estadísticas para el tiempo en la fila, longitud de fila y uso en el centro de inspección. (PISTA:
112 Capítulo 3
Explore el módulo de diagrama de flujo Decide (Decidir) y considere lanzar una moneda di-
mensional más alta.)
3-9 En el modelo 3-1, suponga que en lugar de tener una sola fuente de partes, existen tres
fuentes de llegada, una para cada uno de los tipos de partes que llegan: azul (como antes), verde
y rojo. Para cada color de partes que arriban, los tiempos entre llegadas son distribuidos de for-
ma exponencial con una media de 15 minutos. Corra la simulación por 480 minutos y calcule las
mismas medidas de desempeño que para el modelo 3-1. Una vez que las partes están en el sis-
tema, retienen su color correcto (para la animación) pero no se diferencian para la recopilación
de estadísticas en tiempo en la cola, longitud de ésta o uso (esto es, se encuentran agrupadas
para propósitos de procesamiento y recopilación de estadísticas en estas medidas de desempeño
de resultados); sin embargo, recopile las estadísticas de forma separada por color de partes para
el tiempo total en el sistema. Los tiempos de procesamiento en el centro de perforación son los
mismos que en el modelo 3-1 e idénticos a pesar del color de la parte.
3-10 En los museos de ciencias, con frecuencia encontrará lo que se llama tabla de probabili-
dad (también conocida como quincunx):
Ésta es como una bandeja para hornear, lisa, inclinada con una ranura en la parte media
de la orilla superior a través de la cual caen las canicas, una a la vez, de una reserva fuera del
tablero; digamos que la reserva tiene un número k de canicas. Sólo debajo de la ranura hay una
clavija, que cada canica que entra golpea y hace que ella misma ruede a la izquierda o a la de-
recha; suponga que inclinó la tabla de forma que hay un número de posibilidades iguales de
que la canica ruede a izquierda o derecha (interprete “izquierda” y “derecha” desde su punto
de vista conforme mira la tabla desde el frente, que es el extremo opuesto al punto de vista de
las canicas conforme se lanzan hacia abajo de la tabla sobre sus estómagos). Por debajo de esta
clavija hay una línea de dos clavijas, paralelas al extremo más alto de la tabla pero compensadas
con respecto a la primera clavija de forma horizontal, de tal manera que estas dos clavijas de la
segunda línea están acomodadas de forma diagonal por debajo de la primera clavija, como en
la imagen. Suponga que el ángulo de inclinación de la tabla, el espacio de la clavija, la masa de
las canicas y el campo gravitacional del planeta anfitrión están correctos, de tal forma que cada
canica golpeará exactamente una de las dos clavijas en la segunda línea (qué clavija es la que
Un recorrido guiado a través de Arena 113
golpea, se determina si ésta rueda hacia la izquierda o hacia la derecha de la primera clavija).
La canica después rodará a la izquierda o a la derecha de cualquier clavija que golpee en la segun-
da línea (de nuevo, suponga una probabilidad de 50-50 de que ruede a izquierda o derecha). La
siguiente línea paralela de clavijas tiene tres clavijas en ella, de nuevo, compensadas de tal forma
que cada canica golpeará exactamente una de ellas y rodará a izquierda o derecha, una vez más,
con igual número de probabilidades. Esto continúa hasta la última línea; digamos que el número
de líneas es n de manera que la última línea tiene n clavijas (n = 6 en la imagen, contando la pri-
mera clavija de arriba como su propia línea). Después de rodar por una clavija en la última fila,
la canica caerá exactamente en un contenedor de n > 1 contenedores, ordenados diagonalmente
debajo de la última fila de clavijas. Cree un modelo de simulación Arena para simular un tablero
de probabilidad con n = 6 filas de clavijas y k = 1 000 canicas en la reserva. Animar las canicas
rebotando cuando caen en el tablero, y también animar el número de canicas que se acumulan en
los contenedores en la parte inferior con objetos de animación Level (Nivel) de la barra de herra-
mientas Animate (Animar). Además, contar el número de canicas que llegan a cada uno de los 7
contenedores. ¿La proporción de canicas cayendo en cada contenedor estima las probabilidades
de qué distribución? ¿Qué pasa si alguien abre una ventana en la izquierda del tablero y un viento
sopla las canicas hacia la derecha cuando ruedan, de tal forma que hay un 75% de oportunidad
(más que 50%) de que rueden a la derecha de cada clavija?
3-11 En el ejercicio 3-9, como parte de procesar partes, se incluye una inspección (no hay tiempo
para el procesamiento adicional requerido para la inspección, y durante la inspección, la entidad
de partes continúa ocupando el recurso). Cada parte pasa esta inspección con 0.93 de probabili-
dad, a pesar de su color. Si pasa, deja el sistema, como antes. Si falla, debe regresar atrás y volver
al proceso, yendo al final de la cola si es que hay una y toma cierta cantidad de tiempo volverla a
procesar, lo que es un dibujo independiente de la misma distribución del tiempo de proceso; las
partes que se someten de nuevo al proceso deben ser inspeccionadas (con la misma probabilidad
de pasar) y pueden fallar varias veces (no hay límite en el número de fallas para una parte dada)
antes de que finalmente pasen y dejen el sistema. Ajuste los gráficos si es necesario para que mues-
tren la curva completa. Compare el tiempo promedio de partes en la fila de procesamiento, la
longitud promedio en la fila, el uso de los recursos y el tiempo promedio en el sistema por color de
parte con lo que se obtuvo del ejercicio 3-9 ... ¿tiene sentido? (PISTA: Explore el módulo Decide
[Decidir], y elija “2-way by Chance” “[2 vías por oportunidad]” en “Type [Tipo]”.)
3-12 En el ejercicio 3-11, después (finalmente) de pasar la inspección, la pintura de las partes
necesita retocarse, así que se envían a una de tres cabinas de retoque de pintura, una para cada
color, con cada parte dirigida a la cabina de su color (por supuesto); cada cabina de retoque tiene
su propia cola FIFO y su propio servidor (sencillo). Los tiempos de retoque son TRIA(3, 9, 18)
minutos, sin importar el color. Agregue un gráfico que rastree, en un conjunto sencillo de ejes, la
longitud de la fila de cada una de las cabinas de retoque (con colores adecuados para cada una
de las tres curvas). Recopile las mismas estadísticas de salida que para el ejercicio 3-9, además
del tiempo en la cola, número en ésta y empleo de cada cabina de retoque. (PISTA: Explore el
módulo Decide [decidir] un poco más, esta vez al escoger que “Type” sea “N-way by Condition
[N vías por condición]” y después añadir [Add] condiciones basado en el Entity Type.)
3-13 En el modelo 3-3, los estudios de tiempos mostraron que pasar a este trabajo integrado
supuso un aumento promedio de 18% del tiempo que toma completar cada una de las cuatro
tareas para procesar una solicitud, ya que los empleados no están especializados en una sola
114 Capítulo 3
tarea, como lo estaban en el modelo 3-2. Modele esto como si se incrementara cada uno de los
tiempos de servicio en un 18% con respecto a lo que era en el modelo 3-3. Si esto sucede, ¿es aún
aconsejable la combinación de trabajo integrado paralelo generalizado, en comparación con la
organización serial especializada del modelo 3-2?
3-14 Cinco máquinas idénticas trabajan de forma independiente en una tienda pequeña. Cada
máquina está activa (esto es, trabaja) entre seis y diez horas (distribuidas uniformemente) y
después se paran. Hay dos técnicos de reparación disponibles, y un técnico requiere entre una
y tres horas (distribuidas uniformemente) para arreglar una máquina; sólo un técnico puede
estar asignado a trabajar en una máquina descompuesta aun si el otro técnico se encuentra
desocupado. Si más de dos máquinas están descompuestas en un tiempo dado, forman una cola
FIFO “de reparación” (virtual) y esperan por el primer técnico disponible. Un técnico trabaja
en una máquina descompuesta hasta que esté reparada, sin importar qué esté pasando en el
sistema. Todos los tiempos de funcionamiento y de inactividad son independientes de cualquier
otro. Empezando con todas las máquinas al comienzo del tiempo de “trabajo”, simule esto para
160 horas y observe el tiempo promedio en el número de máquinas que se encuentran inactivas
(en reparación o en la cola para reparación), así como el empleo de los técnicos de reparación
como un grupo. Anime las máquinas cuando estén tanto en reparación como en la cola para
un técnico de reparación, y grafique el número total de máquinas descompuestas (en repara-
ción y en la cola) en el transcurso del tiempo. (PISTA: Piense en las máquinas como “clientes”
y en los técnicos de reparación como “servidores” y note que siempre hay cinco máquinas flo-
tando alrededor en el modelo y nunca lo dejan.)
CAPÍTULO 4
Modelación de operaciones
y entradas básicas
En los capítulos 2 y 3 presentamos un sistema de proceso sencillo (modelo 3-1), llevamos a cabo
una simulación a mano (capítulo 2) y examinamos un modelo de Arena (capítulo 3). También
consideramos un par de otros modelos, en las secciones 2.7 y 3.5, pero todos fueron bastante
sencillos y estilizados. En este capítulo trabajaremos con un sistema más realista y desarrolla-
remos modelos completos de varias versiones de ese sistema, añadiendo complejidad y nuevos
conceptos de modelado a cada versión. También hablaremos acerca de cómo se puede especi-
ficar, de manera realista, distribuciones de probabilidad de entradas que representen el sistema
real bajo estudio.
La sección 4.1 describe este sistema más complicado: un montaje electrónicamente sellado
y un sistema de prueba. Después analizaremos cómo desarrollar un enfoque de modelado,
presentaremos nuevos conceptos de Arena, construiremos el modelo y le mostraremos cómo
ejecutarlo y ver los resultados. A estas alturas, el lector debería comenzar a ser peligroso en
cuanto a sus habilidades de modelado. En la sección 4.2 realzaremos el modelo al enrique-
cer la programación, falla y estados de los recursos y le daremos métodos alternativos para
estudiar los resultados. La sección 4.3 mostrará cómo arreglar un poco la animación. En la
sección 4.4 generalizaremos cómo las entidades se mueven alrededor, al introducir las nociones
de Estaciones (Stations), Rutas (Routes) para tiempos de viaje diferentes a cero y animación de
transferencias. La sección 4.5 tratará de cómo encontrar y corregir los errores en sus modelos.
Por último, en la sección 4.6, reanudaremos el tema de cómo especificar entradas cuantitativas,
incluyendo distribuciones de probabilidad desde donde se “generan” observaciones de variables
aleatorias para realizar su simulación. Cuando termine este capítulo, el lector debería ser capaz
de construir por su propia cuenta algunos modelos razonablemente elaborados, así como de
especificar distribuciones apropiadas y realistas como entradas para sus modelos.
Parte A
(EXPO 5)
Sellador Recuperados y
EXPO (45) enviados
TRIA (1,4,8)
Llegadas
Preparación de la Parte B
Parte A
Parte B TRIA (1,3,4) Enviados
Lotes de 4 Parte B
(EXPO 30) WEIB (2.5, 5.3)
TRIA (3,5,10)
el lote se envía al área de producción final que estamos modelando. El tiempo entre las llegadas de
los lotes sucesivos de la Parte B a nuestro modelo es exponencial con una media de 30 minutos.
A la llegada al área de preparación de la Parte B, el conjunto se separa en las cuatro unidades
individuales, que se procesan una a una desde este punto y las partes individuales proceden (de
forma instantánea) al área de preparación de la Parte B. El proceso en el área de preparación
de la Parte B tiene los mismos tres pasos que el área de preparación de la Parte A, excepto que
el tiempo del proceso para la operación combinada sigue una distribución TRIA(3, 5, 10). En-
tonces la parte se envía (de forma instantánea) al sellador.
En la operación del sellador se insertan los componentes electrónicos, la caja se ensambla y se
sella y se prueba la unidad sellada. El tiempo total del proceso para estas operaciones depende del
tipo de parte: TRIA(1, 3, 4) para la Parte A y WEIB(2.5, 5.3) para la Parte B (2.5 es el parámetro de
escala β y 5.3 es el parámetro de forma α; véase el apéndice D). Noventa y nueve por ciento de las
partes pasan la inspección y se transfieren inmediatamente al departamento de envío; si una parte
pasa es independiente de si cualquier otra parte lo hace. Las partes restantes se transfieren de forma
instantánea al área de retrabajo en donde se les desensambla, repara, limpia, se ensamblan de nuevo
y se les pone a prueba otra vez. Ochenta por ciento de las partes que se procesan en el área de retraba-
jo se recuperan y transfieren de forma inmediata al departamento de envío como partes reprocesa-
das y el resto se transfieren de forma instantánea al área de descarte. El tiempo para reprocesar una
parte sigue una distribución exponencial con una media de 45 minutos y es independiente del tipo
de parte y de la disposición última (recuperación o descarte).
Queremos recopilar estadísticas en cuanto a uso del recurso, número en cola, tiempo en
cola y tiempo del ciclo (o tiempo total en el sistema) en cada área por separado para las partes
enviadas, recuperadas o descartadas. En un principio ejecutaremos la simulación para cuatro
turnos consecutivos de 8 horas, o 1 920 minutos.
problema real, esto puede requerir la definición de una estructura de datos, la segmentación del
sistema en submodelos o el desarrollo de la lógica de control. Para este problema, sólo se requie-
re que decidamos qué módulos de Arena proporcionarán las habilidades que se requieren para
captar la operación del sistema en un nivel apropiado de detalle. Además, debemos decidir cómo
modelar los diferentes tiempos de proceso en la operación de sellado. Para simplificar esta tarea,
separemos el modelo en los componentes siguientes: llegada de la parte, áreas de preparación,
operación del sellado, retrabajo, salida de la parte y animación de la parte. También, asumiremos
que todas las entidades del sistema representan partes individuales que se procesan.
Debido a que tenemos dos clases distintas de llegadas de entidades a nuestro modelo, cada
una con su propio patrón de tiempo, usaremos dos módulos Crear (Create) por separado (uno
para cada tipo de parte) para generar las partes que llegan.
También tenemos diferentes tiempos de proceso por tipo de parte en la operación de sellado,
así que usaremos dos módulos Asignar (Assign) (para definir un atributo llamado Tiempo de
sellado [Sealer Time]) que se asignará al tiempo de proceso de sellado apropiado des-
pués de generar todas las partes en los módulos Crear (Create). Cuando se procesan las partes
en la operación de sellado, usaremos el tiempo contenido en el atributo Tiempo de sellado
(Sealer Time) para el tiempo de proceso ahí, más que generarlo en el lugar como lo hicimos
en los modelos del capítulo 3.
Cada una de las dos áreas de preparación y la operación de sellado se modelarán con su propio
módulo Proceso (Process), muy parecido al módulo Proceso (Process) utilizado en los modelos del
capítulo 3. Se lleva a cabo una inspección después de que la operación de sellado se completó, que
resulta en que las partes van a diferentes lugares con base en “arrojar una moneda” (sólo con la
tendencia justa en la moneda). Usaremos un módulo Decidir (Decide) con el resultado de aprobar
o fallar dejado a la suerte. El área de retrabajo se modelará con los módulos Proceso (Process) y
Decidir (Decide), ya que también tiene las opciones de aprobar o fallar. Las salidas de las partes se
modelarán con tres módulos separados de Grabar, Registrar (Record) y de Disposición (Dispose)
(enviadas, recuperadas y descartadas), de manera que podamos mantener las estadísticas de tiem-
po del ciclo correspondientes ordenadas por Enviadas contra Recuperadas contra Descartadas.
Todos estos módulos se pueden encontrar en el panel de procesos básicos (Basic Process).
Proceso
(Process) 3
Verdadero
Verdadero
Decidir Proceso Decidir Grabar, Dispose
(Decide) 1 (Process) 4 (Decide) 2 Registrar (Disponer) 1
(Record) 1
Grabar, Dispose
Registrar (Disponer) 3
(Record) 3
y especificamos el Tipo de entidad (Entity Type) como Parte A. El Tiempo entre llegadas
(Time Between Arrivals) es Aleatorio (Random), es decir, una distribución exponencial, con
un Valor (Value), es decir, media, de 5 y las unidades se configuran en Minutos (Minutes). Las
entradas restantes son opciones predeterminadas. Ahora podemos aceptar el módulo al hacer
clic en Aceptar (OK).
Llega
Parte A
Pantalla 4-2. Las entradas completas del cuadro de diálogo Crear (Create) de la Parte B
El módulo Crear (Create) para las llegadas de la Parte B es muy similar al de la Parte A,
como se indicó en la pantalla 4-2 (nos saltaremos las gráficas puesto que son casi las mismas
que las que se acaban de ver), excepto que llenamos un campo adicional (Entidades por llegada
[Entities per Arrival]) para reflejar que el tamaño del lote es de 4. Recuérdese que las entidades
de la Parte B llegan en lotes de cuatro. Así, esta entrada ocasionará que cada llegada consista
de cuatro entidades por separado en lugar de una sola.
Habiendo creado las partes que llegan, ahora debemos definir el atributo Tiempo del sella-
dor (Sealer Time) y asignarle el tiempo de proceso de sellado, que es diferente para cada tipo de
parte. Asignaremos estos valores en los módulos Asignar (Assign) 1 y Asignar (Assign) 2 que
colocamos anteriormente. La asignación de la Parte A se indica en la pantalla 4-3. Definimos el
nuevo atributo y le asignamos un valor de la distribución TRIA(1, 3, 4). También definimos un
atributo, Tiempo de llegada (Arrive Time), que se usa para grabar el tiempo de llegada
Asignar Sellador
y Tiempo de
llegada de la
Parte A
Pantalla 4-3. Asignación del Tiempo de sellado (Sealer Time) y del Tiempo de llegada
(Arrival Time) a la Parte A
120 Capítulo 4
Pantalla 4-4. Asignación del Tiempo de sellado (Sealer Time) y del Tiempo de llegada
(Arrival Time) a la Parte B
Preparación
del proceso
A
pre debe coincidir con lo que se haya tecleado la primera vez. Los nombres de Arena no son
sensibles a mayúsculas/minúsculas, pero la ortografía y cualquier espacio en blanco deben ser
idénticos. La elección del nombre de la lista le asegura que sea el mismo. Si escribe algún nom-
bre diferente, Arena mostrará un mensaje de error la primera vez que revise o intente ejecutar
el modelo (o, peor aun, su modelo puede ejecutarse pero estará incorrecto).
También note que cuando se coloca un módulo, de forma automática Arena proporciona
nombres y valores predeterminados. Estos nombres predeterminados son los nombres de los
objetos (módulo, recurso, etc.) con un número añadido. Tal número aumenta con cada nombre
122 Capítulo 4
adicional, si se requiere un nombre único; por ejemplo, Proceso (Process) 1, Proceso (Process) 2,
etc. Existen dos razones para esto. La primera tiene que ver con la conveniencia: puede aceptar
el nombre del recurso predeterminado o bien, cambiarlo. La segunda razón es que todos los
nombres para cualquier objeto en Arena deben ser únicos, aun cuando el tipo del objeto sea
diferente. De lo contrario, Arena podría no determinar qué objeto asociar con un nombre que
se haya usado más de una sola vez.
Para ayudar al lector, Arena nombra mucho de forma automática, lo cual, en la mayoría de
las ocasiones, ni siquiera notará. Por ejemplo, si hace clic en el módulo Datos de la cola, verá
que Arena también asignó el nombre Prep A Process.Queue a la cola en esta área de pre-
paración. En la mayoría de los casos puede asignar sus propios nombres en lugar de aceptar los
ya predeterminados.
También puede ser que observe que cuando selecciona cualquiera de las dos acciones que
incluyen Tomar (Seize) y después acepta el módulo, Arena colocará de forma automática una
cola animada (una línea horizontal con una pequeña línea vertical a la derecha) cerca del mó-
dulo asociado Proceso (Process). Esto le permitirá visualizar entidades que esperan en la cola
durante la ejecución de la simulación. Si hace clic en esta cola, se desplegará su nombre.
El segundo módulo Proceso (Process) se llena de una forma casi idéntica, con la excepción
del nombre (Prep B Process), el nombre del recurso (Prep B) y los parámetros para el
tiempo de proceso (3, 5, 10). No incluimos una pantalla para este módulo.
El siguiente paso es introducir los datos para la operación de sellado, que es el tercer módulo
Proceso (Process) que colocamos. Las entradas para el cuadro de diálogo se indican en la pan-
talla 4-6. Note que en los módulos Asignar (Assign) hacia arriba definimos el atributo Tiempo
de sellado (Sealer Time) cuando se crearon las partes que llegan. Cuando una entidad
obtiene el control de, o toma, el recurso, experimentará una demora del proceso igual al valor
contenido en su atributo Tiempo de sellado (Sealer Time).
La inspección que sigue a la operación de sellado se modela al usar el primer módu-
lo Decidir (Decide). Aceptaremos el Tipo (Type) predeterminado, 2 vías por probabi-
lidad (2-way by Chance), ya que sólo tenemos la opción de aprobar o fallar y esto lo
decidirá la suerte. El cuadro de diálogo requiere que introduzcamos un Porcentaje verda-
dero (Percent True) y proporciona dos maneras de que las entidades dejen el módulo (ver-
dadero o falso). En este caso, introduciremos el Porcentaje verdadero (Percent True)
como de 9% de las entidades (que trataremos como los artículos que fallaron) que si-
guen la rama Verdadero y 91% (los artículos que aprobaron) que siguen la rama Falso.1
1
Podríamos sólo haber invertido la interpretación de Verdadero como falla y Falso como aprobación, en cuyo caso
el Porcentaje verdadero (Percent True) sería de 91 (y con probabilidad cambiaríamos el módulo Nombre a Inspec-
ción de sellado aprobada [Passed Sealer Inspection]).
Modelación de operaciones y entradas básicas 123
Inspección
de sellado
fallida
Las partes que pasan se envían a Envío (Shipping) y las que fallan se remiten a Retrabajo
(Rework). Los datos para este módulo Decidir (Decide) se indican en la pantalla 4-7. A propó-
sito, si ha ido construyendo el presente modelo conforme a este material, ahora sería un buen
momento para hacer clic en el botón Guardar (Save): ¡nunca se sabe cuándo alguien puede
apagar el interruptor de la electricidad!
El módulo Proceso (Process) restante se usará para modelar la actividad de retrabajo. Los
datos para este módulo Proceso (Process) se encuentran en la pantalla 4-8. Este módulo es
muy similar a los módulos Proceso (Process) de preparación A y B, con excepción de Nombre
(Name), Nombre del recurso (Resource Name) y Expresión (Expression).
El módulo final Decidir (Decide) se usa para separar las partes recuperadas y descartadas
después del retrabajo. Los datos para este módulo Decidir (Decide) aparecen en la pantalla 4-9.
Elegimos la rama Verdadero para representar a las partes descartadas (20%) y la rama Falso
para representar a las partes recuperadas.
Habiendo definido todas las operaciones, ahora necesitamos llenar los módulos Grabar, Re-
gistrar (Record) y de Disposición (Dispose). Recuerde que, como parte del resultado de la simu-
lación, quisimos recopilar estadísticas en cuanto al uso del recurso, número en la cola y tiempo en
la cola en cada una de las operaciones. Estas tres estadísticas son recopiladas de forma automática
siempre que use el módulo Proceso (Process) con una opción Acción (Action) que requiera un
Recurso (Resource) (asumiendo que el cuadro de Reportar estadísticas [Reportar Statistics] para
el módulo se revise y que el cuadro Procesos [Processes] se revise en Ejecutar > Configuración >
Parámetros del proyecto [Run > Setup > Project Parameters]). También quisimos estadísticas de
los tiempos del ciclo separados por partes enviadas, recuperadas y descartadas. El módulo Gra-
bar, Registrar (Record) proporciona la capacidad de recopilar estos tiempos de ciclo en la forma
de Tallies (Cuentas). El cuadro de diálogo completo para las partes tally (cuenta) descartadas se
indica en la pantalla 4-10. Elegimos el Tipo (Type) Intervalo de tiempo (Time Inter-
val) de la lista de sugerencias. El Nombre de Cuenta (Tally Name) se predetermina en el nombre
del módulo. Esto hará que Arena grabe el tiempo entre el atributo que lleva el tiempo de llegada
(Arrive Time) de la parte al sistema y el tiempo en el que llegó a este módulo Grabar, Registrar
(Record) como una estadística Tally (Cuenta), que será el tiempo de la entidad en el sistema.
Los dos módulos Grabar, Registrar (Record) restantes se llaman Record Salvaged
Parts (Grabar partes recuperadas) y Record Shipped Parts (Grabar partes
enviadas). No debimos preocuparnos por incluir pantallas en estos módulos puesto que son
completamente análogas al módulo Record Scrapped Parts (Grabar Partes des-
cartadas) de la pantalla 4-10.
Los tres últimos módulos son de Disposición (Dispose) de las entidades conforme dejan el
sistema. Para este modelo, pudimos haber dirigido todas las entidades a un solo módulo de Dis-
posición (Dispose). Sin embargo, una de las características del módulo de Disposición (Dispose)
es la inclusión de una variable de animación, que aparece cerca de la esquina inferior derecha del
Grabar
Partes des-
cartadas
Pantalla 4-10. Cuadro de diálogo Grabar Partes descartadas (Record Scrapped Parts)
Modelación de operaciones y entradas básicas 125
Descartadas
módulo. Esta variable de animación desplegará la cuenta actual del número total de entidades
que pasaron por este módulo durante la ejecución y permitirá, a quien lo ve, discernir la propor-
ción de entidades que tomaron cada una de los tres posibles caminos a través del sistema.
Los datos para el módulo de Disposición (Dispose) Scrapped (Descartadas) se indican
en la pantalla 4-11. Predeterminamos en la verificación del cuadro titulado Grabar estadísticas de
entidad (Record Entity Statistics). Sin embargo, si hubiéramos querido mantener las estadísticas
de flujo de la entidad sólo en las partes que se enviaron, incluyendo las partes recuperadas, enton-
ces hubiéramos despejado este cuadro (dejando las verificaciones en los dos módulos de Disposi-
ción [Dispose] restantes). Hacerlo hubiera ocasionado que se incluyera en las estadísticas de flujo
de entidades automáticas sólo a las partes seleccionadas. Por supuesto, debe asegurarse de que el
cuadro Entidades (Entities) en Run > Setup > Project Parameters (Ejecutar > Configuración >
Parámetros del proyecto) esté marcado con la finalidad de obtener cualquiera de estos resultados.
Los otros dos módulos de Disposición (Dispose), Salvaged (Recuperadas) y Ship-
ped (Enviadas), se llenan de forma similar.
El lector se encuentra muy cerca de ejecutar el modelo. Aunque ha tomado algo de tiempo
llegar hasta aquí, una vez que se acostumbre a trabajar con Arena descubrirá que podrá realizar
estos pasos en sólo unos pocos minutos.
El modelo podría de hecho ejecutarse en este punto, pero una vez empezado continuaría
ejecutándose por siempre, pues Arena no sabe cuándo detener la simulación. El lector establece
los parámetros de ejecución para el modelo al seleccionar Run > Setup (Ejecutar > Configura-
ción). El cuadro de diálogo Run Setup tiene seis páginas etiquetadas que se pueden usar para
controlar la ejecución de la simulación. Los datos para la primera etiqueta, Parámetros del
proyecto (Project Parameters), se indican en la pantalla 4-12. Introdujimos el título del proyecto
y el nombre del analista así que aparecerán en los registros de resultado y también una breve
sinopsis en Descripción del proyecto (Project Description) para propósitos de documentación.
En el área de recopilación de estadísticas, despejamos la selección Entidades (Entities) pues no
necesitamos esos datos para nuestro análisis (así que no obtendremos estadísticas de tiempos
en el sistema acomodados por tipo de entidad). El lector puede intentar ejecutar la simulación
con este cuadro marcado para ver la diferencia entre los reportes de resultados.
También hay que especificar la duración de la ejecución, que se hace bajo la etiqueta Pará-
metros de réplica (Replication Parameters). Configuramos la duración de la réplica (Replica-
tion Length) en 32 horas (cuatro turnos consecutivos de 8 horas), el tiempo base (Base Time)
en Minutes (Minutos) y los campos restantes como predeterminados. También aceptamos
las cuatro etiquetas restantes como predeterminadas en Run > Setup (Ejecutar > Configura-
126 Capítulo 4
Pantalla 4-12. Parámetros del proyecto de Ejecutar configuración (Run Setup Project Parameters)
ción): tamaños de la selección (Array Sizes), velocidad de ejecución (Run Speed), control de
ejecución (Run Control) y reportes (Reports). Se pueden ver estas etiquetas para tener una idea
de las opciones disponibles.
Antes de ejecutar nuestro nuevo modelo creado, vamos a darle un toque final. Puesto que te-
nemos dos tipos de partes diferentes, sería bueno que pudiéramos distinguirlas en la animación.
Haga clic en el módulo Datos de la entidad (Entity data) que se encuentran en el Basic Process
panel (Panel de procesos básicos) y note que la imagen inicial para ambas partes es Picture.
Report. Cuando ejecutamos nuestro modelo, todas nuestras partes usarán el mismo ícono
para desplegar entidades en la animación.
Ahora haga clic en la celda Imagen inicial (Initial Picture) para la Parte A y use la lista para
seleccionar una imagen diferente. Elegimos la bola azul para la Parte A y la bola roja para la
Parte B, como se indica en la pantalla 4-14. Ello nos permitirá distinguir con facilidad entre las
dos partes de la animación. Si está interesado en ver cómo se ven estos íconos, puede seleccio-
nar Edit > Entity Pictures (Editar > Imágenes de la entidad) de la barra del menú en la parte
superior de su pantalla para abrir la ventana Localización de imagen de entidad (Entity Picture
Placement), que le permitirá ver los íconos disponibles en la actualidad hacia abajo en la colum-
na derecha. Después le mostraremos en más detalle cómo usar esta característica.
Su modelo final debería verse parecido al de la figura 4-3.
Modelación de operaciones y entradas básicas 127
Pantalla 4-13. Parámetros de réplica al ejecutar configuración (Run Setup Replication Parameters)
Entity
(Entidad)
Initial Picture (Part A) [Imagen inicial Parte A] Picture.Blue Ball (Imagen. Bola Azul)
Initial Picture (Part B) [Imagen inicial Parte B] Picture.Red Ball (Imagen. Bola Roja)
Proceso de
sellado
Asignar sellador
Proceso de pre-
Llega Parte B de la Parte B
paración de B
y el tiempo de
llegada
Verdadero Verdadero
Inspección Registro de
Inspección de Proceso de Descartadas
de revisión partes des-
sellado fallida Retrabajo
fallida cartadas
Falso Falso
Registro de
partes recu- Recuperadas
peradas
Registro
de partes Enviadas
enviadas
que introduzca un error de manera intencional en su modelo e intente con estas características.
Conforme construya modelos más complejos, podrá usar tales características bastante seguido.
Si la revisión de su modelo no resulta con errores, ahora está listo para ejecutar la simula-
ción. Existen cuatro formas de ejecutar una simulación, pero aquí sólo hablaremos de tres de
ellas. La primera forma es ejecutar la simulación con la animación. Use el botón Go (Ir) ( ) en
la barra de herramientas Estándar (Standard), el comando Run > Go (Ejecutar > Ir) o la tecla
F5. Si aún no ha revisado su modelo o si hizo un cambio desde la última revisión, Arena revisa-
rá primero el modelo, luego lo iniciará con sus datos y por último lo ejecutará. Durante la eje-
cución se dará cuenta que Arena esconde algunas de las gráficas de forma que su enfoque radica
en la animación. Pero no se preocupe. Ellas regresarán cuando finalice la ejecución (o puede
revisar para ver que todavía están ahí, usando el comando View > Layers [Vista > Capas]).
Si se deja la barra de estatus activa (en la parte inferior de la pantalla), se puede deducir qué
es lo que está haciendo Arena. Hacia la derecha de tal barra hay tres bloques de información: el
número de réplica, el tiempo actual de la simulación y el estatus de la simulación.
Después que la simulación comienza a ejecutarse, se puede acelerar o retrasar la animación.
Puede hacerlo mientras el modelo se encuentra ejecutándose con la barra que se desliza en el
extremo derecho de la barra de herramientas Estándar (Standard) o al presionar la tecla “<”
para retrasarla o la tecla “>” para acelerarla. Si pulsa cualquiera de las dos, el factor de veloci-
Modelación de operaciones y entradas básicas 129
que el botón End [Finalizar] ya no estará al final, necesitará usar en su lugar la opción del menú
Run > End [Ejecutar > Finalizar]).
Asignar sella-
Proceso de
dor de la Parte
Llega Parte A preparación
A y el tiempo
de llegada de A
Proceso de
sellado
Registro de
partes recu- Recuperadas
peradas
Registro
de partes Enviadas
enviadas
cuentra plagada con tiempos de espera y longitudes de la cola que son mucho más grandes que
para las otras estaciones (también puede corroborar este desequilibrio en el congestionamiento
al ver las secciones Proceso [Process] y Recursos [Resources] del Reporte General de Categorías
[Category Overview report]). Esto implica que el área de revisión no tiene suficiente capacidad
para manejar su trabajo, o bien que hay un gran trato de variabilidad en esta sección. Haremos
referencia a tal tema en breve, en la sección 4.2. (A propósito, note que en algunos lugares en
el Reporte General de Categorías [Category Overview report], obtiene una gráfica codificada a
color para algunos de los resultados.)
2
Por supuesto, el lector ya estará muy familiarizado con el término “bug (bicho)” en referencia a un error en un
programa de computadora, pero ¿conoce la etimología de este neologismo entomológico? Nosotros sí. El “bug” de
computadora original fue una polilla sin suerte electrocutada en un panel de transmisión de una computadora antigua
usada por el venerable Grace Murria Hopper (quien acuñó el término) en el Colegio Vassar, que paró circuitos y oca-
sionó errores; puede ver su foto post mórtem en http://www.cs.vassar.edu/images/Bug.GIF.
Modelación de operaciones y entradas básicas 133
cerse a sí mismo y otros no creyentes que su modelo en verdad puede captar y predecir eventos
del sistema real. Analizaremos ambas actividades con más detalle en el capítulo 13.
Por ahora, asumamos que como parte de este esfuerzo le mostró el modelo y los resultados
que le acompañan a la administradora de producción. Su primera observación fue que no tuvo
una definición completa de cómo funciona el sistema. Quien haya desarrollado la definición del
problema sólo vio la operación del primer turno. Pero de hecho este sistema opera dos turnos
por día, y en el segundo de ellos hay dos operadores asignados a la operación de revisión. Esto
explicaría nuestra observación anterior cuando pensamos que la operación de revisión podría no
tener suficiente capacidad. La administradora de producción también notó que tiene un proble-
ma de falla en la operación del sellado. Con periodicidad, la máquina selladora se descompone.
Los de ingeniería vieron el problema hace tiempo y recopilaron datos para determinar el efecto
en la operación de sellado. Ellos pensaron que estas fallas no requerían ningún esfuerzo sig-
nificativo para corregir el problema porque no percibían que la operación de sellado resultara
un cuello de botella. Sin embargo, sí registraron sus observaciones, que aún están disponibles.
Asumamos que se encontró que el tiempo de funcionamiento medio (del final de una falla al
comienzo de la siguiente) era de 120 minutos y que la distribución del tiempo de funcionamien-
to es exponencial (que, por cierto, a menudo se le usa como un modelo realista para tiempos
de funcionamiento, si las fallas ocurren aleatoriamente a una tasa uniforme en el tiempo). El
tiempo para reparar también sigue una distribución exponencial con una media de 4 minutos.
Además, la administradora de producción indicó estar considerando la compra de estantes
especiales para almacenar las partes en espera en el área de revisión. Estos estantes pueden
tener diez ensamblados cada uno y a ella le gustaría saber cuántos estantes comprar. Nuestro
siguiente paso es modificar el modelo para incluir estos tres nuevos aspectos, que nos permiti-
rán usar algunas características adicionales de Arena.
Con la finalidad de incorporar estos cambios en nuestro modelo, necesitaremos introdu-
cir varios conceptos nuevos. El cambiar una operación de un turno a una de dos es bastante
sencillo. En el modelo 4-1 configuramos nuestra duración de la ejecución de cuatro turnos de
8 horas, y no hicimos intento alguno por mantener el rastro de cada turno del día durante la
ejecución. Sólo asumimos que las condiciones del sistema al final de un turno eran las mismas
que al inicio del siguiente e ignoramos el tiempo intermedio. Ahora necesitamos modelar de
forma explícita el cambio en los turnos, porque sólo tenemos un operador en el primer turno y
dos en el segundo para el proceso de revisión.
Añadiremos esto a nuestro modelo al introducir un Programa del recurso (Resource Sche-
dule) para el recurso de revisión, que de forma automática cambiará el número de recursos de
revisión durante la ejecución al ajustar la capacidad del recurso. Mientras hacemos este cambio,
también aumentaremos la duración de la ejecución, de tal manera que simulemos más que sólo
dos días de la operación de dos turnos. Modelaremos las fallas del sellador al usar Falla del
recurso (Resource Failure), que nos permite cambiar la capacidad disponible del recurso (muy
parecido al Resource Schedule [Programa del recurso]), pero con características adicionales
específicamente diseñadas para representar fallas de equipo. Por último, usaremos la estadística
de frecuencias para obtener el tipo de información que necesitamos para determinar el núme-
ro de estantes que deberían comprarse.
Comienza Termina
interrupción interrupción
programada programada
Nuevo fin de
interrupción en 1:15
Línea de tiempo
Esperar
Duración de
interrupción
reducida
12 del medio 1 pm
día
Figura 4-6. Reglas de programa Preempt (Dejar inconcluso), Wait (Esperar) e Ignore (Ignorar)
opciones para la Regla del programa (Schedule Rule): Esperar (la predeterminada), Ignorar y
dejar inconcluso. Si se programa que ocurra una disminución de la capacidad de x unidades y
por lo menos x unidades del recurso están ociosas, las tres opciones hacen que x unidades de
la(s) unidad(es) del recurso se queden Inactivas. Pero si hay menos de x unidades del recurso
ociosas, cada Regla del programa (Schedule Rule) responde de diferente manera (las tres opcio-
nes se señalan en la figura 4-6):
< La opción Ignore (Ignorar) disminuye inmediatamente la capacidad de recurso, soslayan-
do el hecho de que el recurso está actualmente ubicado en una entidad, pero “el trabajo”
en las entidades en servicio continúa sin disminución. Cuando las unidades del recurso
se liberan por la entidad, tales unidades se colocan en estado inactivo. Sin embargo, si
la capacidad del recurso aumenta de nuevo (esto es, expira el tiempo programado en la
capacidad más baja) antes de que las entidades liberen las unidades del recurso, es como
si el cambio de programa nunca ocurriera. El efecto neto es que el tiempo para el cual la
capacidad de recurso está programado que se reduzca quizá se acorte con esta opción.
< La opción Wait (Esperar), como su nombre lo indica, aguardará hasta que las entidades
en proceso liberen sus unidades del recurso antes de comenzar la disminución de la capa-
cidad real. De esta manera el tiempo de capacidad reducido siempre será de la duración
específica, pero el tiempo entre estas reducciones puede aumentar.
< La opción Preempt (Dejar inconcluso) intenta dejar inacabada la última unidad del recurso
tomado para echarlo fuera de la entidad de control. Si dejar inconcluso tiene éxito y es su-
ficiente una unidad de capacidad, entonces la reducción de capacidad comienza inmedia-
tamente. Arena mantiene internamente la entidad dejada inconclusa hasta que el recurso
esté disponible, en cuyo tiempo la entidad reubicará al recurso y continuará con su tiempo
de proceso restante. Esto proporciona una forma adecuada para modelar programas y
fallas porque, en muchos casos, el proceso de una parte se suspende al final de un turno
o cuando falla el recurso. Si el dejar inconcluso no tiene éxito o si se necesita más de una
unidad, entonces se usará la regla Ignore (Ignorar) para cualquier capacidad pendiente.
136 Capítulo 4
Resource
(Recurso)
Así que, ¿cuándo se debería usar cada una de las reglas? Por lo general, recomendamos que
el lector examine de cerca el proceso actual y seleccione la opción que mejor describa lo que de
hecho ocurre en el momento de un cambio de programa hacia abajo o de falla de recurso. Si el
recurso bajo consideración es un cuello de botella para el sistema, su opción podría afectar sig-
nificativamente los resultados obtenidos. Pero algunas veces no está claro qué hacer, y, mientras
no haya una instrucción estricta, ayudarán unas cuantas reglas generales. Primero, si la dura-
ción de la disminución del programa en capacidad es muy grande comparada con el tiempo de
proceso, la opción Ignorar (Ignore) puede ser una representación adecuada. Si el tiempo entre
las disminuciones de capacidad es grande en comparación con la duración de la disminución, se
puede considerar la opción Esperar (Wait). Para este modelo, seleccionamos la opción Ignore
(Ignorar) porque, en la mayoría de los casos, un operador terminará su tarea antes de irse y
ese tiempo de trabajo adicional se considera en pocas ocasiones.
La vista final de la hoja de cálculo de las primeras cuatro columnas se indica en la pantalla
4-15 (de hecho hay columnas adicionales a la derecha, que no se muestran aquí). También hay
una forma de diálogo para introducir estos datos, que se puede abrir al hacer clic con el botón
derecho en la celda revisar en la columna Nombre (Name) y seleccionando Edit via Dialog
(Editar vía Diálogo).
Ahora que el lector ha nombrado el programa e indicado la regla de programa, tiene que
definir el programa actual que debería seguir el recurso. Una forma de hacer esto es haciedo clic
en el módulo de datos del programa y metiendo la información del programa en la vista de hoja
de cálculo. Previamente se ha agregado un renglón que contiene nuestro nuevo Rework Sche-
dule (Programa de Retrabajo) definido. Al hacer clic en la columna Duraciones (Durations)
se abrirá el Graphical Schedule Editor (Editor gráfico de programa), una interfaz gráfica para
introducir los datos programados. El eje horizontal es el calendario o tiempo de simulación.
(Note que un día se define como 16 horas, con base en nuestra definición de día en el cuadro
de diálogo Run Setup (Ejecutar configuración.) El eje vertical es la capacidad del recurso. El
lector ingresará los datos al hacer clic en la ubicación x-y que representa el día uno, hora uno y
un valor de capacidad de uno. Esto hará que aparezca una barra azul gruesa que representa la
capacidad deseada durante esta hora; en este caso, uno. Puede completarse la entrada de datos
haciéndose clic repetidamente o al hacer clic, mantener presionado, y luego arrastrar la barra
sobre las primeras ocho horas. Complétese el programa de datos al introducir una capacidad
de 2 para las horas nueve hasta 16. No es necesario añadir los datos para el día (Day) 2, pues
Modelación de operaciones y entradas básicas 137
los datos introducidos para el Día (Day) 1 serán repetidos automáticamente para el resto de la
simulación ejecución. El programa completo se muestra en la figura 4-7. Puede observarse que
usamos el botón Options (Opciones) para reducir nuestro valor del eje vertical máximo (capa-
cidad) de diez a cuatro; otros datos se pueden cambiar en el cuadro de diálogo Options, como
qué tanto dura una ranura de tiempo, el número de ranuras de tiempo, y si se repite el programa
desde el principio o se mantiene para siempre en un nivel de capacidad fija.
El lector también puede introducir estos datos de forma manual al hacer clic con el bo-
tón derecho en la columna Durations (Duraciones), en la vista de hoja de cálculo del módulo
Schedule (Programa) y al seleccionar Edit via Dialog (Editar vía Diálogo). Si se selecciona esta
opción, primero deberá introducirse el nombre del programa, luego hacer clic en el botón Add
(Añadir) para abrir la ventana Durations (Duraciones). Aquí el lector define los pares (Capa-
city, Duration [Capacidad, Duración]) que prepararán el programa. En este caso, nuestros dos
pares son 1, 8 y 2, 8 (pantalla 4-16). Esto implica que la capacidad se colocará en 1 para los pri-
meros 480 minutos, después 2 para los siguientes 480 minutos. Este programa luego se repetirá
para la duración de la ejecución de simulación. Puede tener tantos pares (Capacity, Duration)
como requiera para modelar su sistema adecuadamente. Por ejemplo, el lector puede incluir
interrupciones de operador y el tiempo de almuerzo en su programa. Hay una precaución, o
característica3 que debe saber. Si, para cualquier par no se hace ninguna entrada para la Dura-
ción, ésta será predeterminada al infinito. Ello hará que el recurso tenga la capacidad para todo
el tiempo restante de la ejecución de simulación. Siempre y cuando haya entradas positivas para
todas las duraciones, el programa se repetirá para toda la ejecución de simulación.
Si usted usa el Graphical Schedule Editor (Editor gráfico de programas de eventos) para
crear el programa y después abre el cuadro de diálogo, encontrará que los datos se introdujeron
automáticamente. Note que no se puede usar el Graphical Schedule Editor si tiene algún tiem-
3
Esto se llama una característica, si se hace intencionalmente, y un error, si se hace de forma accidental.
138 Capítulo 4
Schedule
(Programa)
po de duración que no esté integrado, o si alguna entrada requiere una Expression [Expresión]
(por ejemplo, una duración de tiempo es un dibujo de una variable aleatoria).
Failure
(Falla)
conteo puede ser un número fijo o generado de cualquier expresión. Las actividades Count-based
(con base en el conteo) son bastante comunes en los modelos industriales. Por ejemplo, el reem-
plazo de herramientas, la limpieza, y el ajuste de máquina se basan generalmente en el número
de partes que se han procesado más que en el tiempo transcurrido. Aunque éstas pueden no ser
normalmente vistas como “fallas”, ocurren periódicamente e impiden que el recurso produzca las
partes. Por otro lado, con frecuencia se modelan fallas basadas en el tiempo porque ésa es la forma
en que nosotros hemos recopilado los datos de falla. En nuestro modelo, el problema requiere una
falla basada en el tiempo. Así que haga clic en la celda Type y seleccione la opción Time (Tiem-
po). Cuando haga esto, la columna más hacia la derecha en la hoja de cálculo cambiará para
reflejar los diferentes requerimientos de datos entre las dos opciones. Nuestras entradas Up Time
(Tiempo de funcionamiento) y Down Time (Tiempo fuera de funcionamiento) son distribuciones
exponenciales con medias de 120 y 4 minutos, respectivamente. También necesitamos cambiar las
Up Time Units (Unidades de tiempo de funcionamiento) y las Down Time Units (Unidades de
tiempo fuera de funcionamiento) de Horas (Hours) a Minutos (Minutes).
El último campo, Tiempo de funcionamiento (Uptime) en este Único Estado (State Only),
nos permite definir el estado del recurso que se puede considerar como “contado” para
los tiempos de funcionamiento. Si este campo está predeterminado, entonces se consideran
todos los estados. El uso de esta característica depende mucho de cómo fueron recopilados sus
datos y el tiempo en el calendario de su modelo. La mayoría de los datos de falla simplemen-
te son datos registrados; por ejemplo, sólo se registra el tiempo de la falla. Si éste es el caso,
entonces los días festivos, los tiempos de almuerzo y el tiempo ocioso se incluyen en el tiempo
entre fallas, y el lector debe predeterminar este campo. Sólo si su tiempo entre fallas se puede
vincular directamente con un estado específico se debería escoger esta opción. Muchas veces
los vendedores de los equipos proporcionarán los datos de falla con base en horas de operación
actual; en este caso, el lector seleccionará esta opción y especificará el estado Busy (Ocupado).
Note que si escoge esta opción también deberá definir el estado Busy usando el módulo de da-
tos StateSet (Conjunto de estado) que se encuentra en el panel de proceso avanzado.
La vista final de la hoja de cálculo para nuestra Sealer Failure (Falla de Sellado) se indica
en la pantalla 4-17.
Al tener completa la definición de dicha Sealer Failure, ahora hay que adjuntarla al recurso
Sealer. Abra el módulo de datos Resource (atrás en el Basic Process panel [panel de Procesos bási-
140 Capítulo 4
Resource
(Recurso)
cos]) y haga clic en la columna Failures para la cola de recurso Sealer. Esto abrirá otra ventana con
la vista de la hoja de cálculo Fallas (Failures). Haga doble clic para añadir una nueva cola y, en la
celda Failure Name (Nombre de Falla), seleccione Sealer Failure de la lista. También debe-
mos seleccionar la Failure Rule (Regla de Falla) –Ignore, Wait o Preempt. Estas opciones son las
mismas que para los programas, y se responden de idéntica forma. Regresamos a nuestras reglas
generales para escoger la opción Failure Rule: debido a que nuestro tiempo en funcionamiento es-
perado (120 minutos) es largo en comparación a nuestra duración de falla (4 minutos), usaremos la
opción Wait. La vista final de la hoja de cálculo se indica en la pantalla 4-18. Si el lector tiene recursos
múltiples con el mismo perfil de falla, todos ellos pueden referirse al mismo Failure Name. Aunque
éstos usarán el mismo perfil de falla, cada uno obtendrá sus propias muestras aleatorias inde-
pendientes durante la ejecución de la simulación.
4.2.4 Frecuencias
Éstas se usan para registrar la frecuencia de ocurrencia persistente en el tiempo de una variable,
expresión o estado de recurso de Arena. Podemos usar el tipo estadístico Frecuencias (Frequen-
cies) para obtener la información que necesitamos para determinar el número de estantes reque-
ridos en el área de retrabajo (Rework). Estamos interesados en el estado de la cola de retrabajo:
específicamente, cuántos estantes de 10 debemos comprar para asegurar que tendremos suficiente
espacio de almacenamiento casi todo el tiempo. En este caso, nos interesamos por la cantidad
de tiempo que el número en la cola es 0 (sin necesitar estantes), mayor a 0 pero no más de 10 (se
necesita un estante), mayor de 10 pero no más de 20 (se necesitan dos estantes), etcétera.
Las estadísticas de frecuencia se introducen al usar el módulo de datos Statistic (Estadísti-
ca), que se puede encontrar en el Advanced Process panel. Al hacer clic en este módulo de datos
se abrirá la vista de hoja de cálculo, que inicialmente está vacía; haga doble clic para añadir una
cola nueva. Primero introduciremos el nombre como Rework Queue Stats (Estadísti-
cas de la cola de revisión). Después, seleccione Frequency en la lista Tipo (Type) y
predetermine en la entrada Value (Valor) para el Frequency Type (Tipo de frecuencia). El
lector notará que cuando seleccionamos el Type, la celda Report Label (Etiqueta del reporte)
dio automáticamente el mismo número que la celda Name, Rework Queue Stats, que acep-
taremos para etiquetar este resultado en los reportes.
Ahora necesitamos desarrollar una Expresión (Expression) que represente el número en la
cola de revisión. Para solicitar esta información, hay que saber el nombre de la variable Arena
para el número en la cola, NQ, por sus siglas en inglés. Podemos obtener el nombre de la cola,
Rework Process.Queue (Cola.Proceso de Retrabajo), del módulo de datos Queue
(Cola) que se encuentra en el Basic Process panel. De esta manera, la Expresión que queremos
Modelación de operaciones y entradas básicas 141
Statistic
(Estadística)
Statistic
(Estadística)
Pantalla 4-22. Módulo de datos Estadística (Statistic) para los Estados de sellado (Sealer States)
disfrutan de un viaje mucho más rápido a través de la operación Rework (tal vez haciéndolas
sentir mejor después de fallar la inspección), siendo el efecto neto que su tiempo promedio en el
sistema parezca disminuir bastante.
Ahora necesitamos analizar un punto más fino acerca de la utilización. Para cada recurso,
Arena reporta dos estadísticas de utilización, llamadas Instantaneus Utilization (Utilización ins-
tantánea) y Scheduled Utilization (Utilización programada).
< Instantaneus Utilization (Utilización instantánea) se calcula al computar la utilización
en un instante particular de tiempo (esto es, [número de unidades de recurso ocupa
das]/[número de unidades de recurso programadas] en ese punto del tiempo), y después
calculando un promedio ponderado del tiempo de esto sobre la ejecución completa para
obtener el valor que se muestra en los reportes. Si no hay unidades del Resource progra-
madas en un instante particular en el tiempo, la razón anterior se define simplemente a
cero, y se cuenta como un cero en el promedio de peso del tiempo reportado. Esto puede
ser una estadística útil para rastrear la utilización en el tiempo (por ejemplo, una gráfica
de utilización). Sin embargo, debe usarse con precaución ya que puede proporcionar
resultados confusos bajo ciertas condiciones (se abundará en esto en breve). Si le gustan
las matemáticas (y si no, también), podemos expresar todo esto como sigue. Sea B(t) el
número de unidades del Resource que están ocupadas en el tiempo t, y M(t) el número
de unidades de ese Resource que están programadas (ocupadas o no) en el tiempo t.
Digamos que U(t) = B(t) / M(t) siempre y cuando M(t) > 0, y simplemente definamos
que U(t) sea 0 si M(t) = 0. Si la ejecución es desde el tiempo 0 al tiempo T, entonces la
Utilización instantánea (Instantaneous Utilization) reportada es
T
∫ U (t)dt/T
0
que es sólo el tiempo promedio de la función U(t) como se define arriba. Es importante
notar que al reportar esto, Arena cuenta por periodos de tiempo cuando no hay capacidad
programada como periodos de tiempo con una utilización de cero.
< Scheduled Utilization (Utilización programada) es el tiempo promedio de unidades del re-
curso que están ocupadas (tomadas de la ejecución completa), divididas entre el tiempo
promedio de unidades del recurso que están programadas (en la ejecución completa). En
la anotación anterior, la Scheduled Utilization (Utilización programada) reportada es
T T
∫ B (t)dt/T = ∫ B (t)dt
0 0
T T
∫ M (t)dt/T ∫ M (t)dt
0 0
Aquí no hay problema con dividir entre cero siempre que el Resource sea programado
por completo para tener unidades disponibles (la única situación que tiene sentido si el
Resource está presente en el modelo).
Bajo condiciones diferentes, cada una de estas utilizaciones reportadas puede proporcionar
información útil. Si la capacidad de un Resource se mantiene constante en la ejecución de toda
la simulación (el Resource nunca se encuentra en un estado Inactivo [Inactive] o Descompuesto
[Failed]), las dos utilizaciones reportadas serán las mismas (se le pedirá probarlo en el ejercicio
146 Capítulo 4
4-19, y usted puede verificar a partir de la tabla 4-1 que esto también es así en el modelo 4-2
para el Resource que tiene capacidad fija). Si se adjunta un Programa (Schedule) al Resource y
las capacidades programadas son cero o una sola constante positiva (por ejemplo, 1), la Utili-
zación instantánea (Instantaneous Utilization) reportada dice al lector qué tan ocupado estaba
el Resource durante toda la ejecución (contando periodos de capacidad cero como periodos de
utilización cero); una gráfica de U(t) como se definió anteriormente le diría qué tan cerca está
su Schedule (Programa) de las veces que se pidió el Resource (Recurso), así que puede ser útil
para investigar requerimientos de personal. La Utilización programada (Scheduled Utilization)
reportada le dice qué tan ocupado estuvo el recurso en el tiempo en que se encontraba disponi-
ble (en otras palabras, la capacidad no era cero).
Por ejemplo, considere el caso donde se programa que un Resource esté disponible 2/3 del
tiempo con una capacidad de 1, y no disponible el otro 1/3 del tiempo (Capacidad de 0). Supon-
ga incluso que durante el tiempo en que el Resource se encontraba disponible, estuvo ocupado
la mitad del tiempo. Para este ejemplo, la Utilización instantánea (Instantaneous Utilization)
reportada sería de 0.3333 y la Utilización programada (Scheduled Utilization) que se reportó
sería 0.5000. Esto le dice que durante la ejecución completa el recurso se utilizó 1/3 del tiempo,
pero durante el tiempo que estuvo programado para que estuviera disponible, se utilizó 1/2 del
tiempo. En este caso, la Utilización instantánea (Instantaneous Utilization) reportada es menor
o igual a la Utilización programada (Scheduled Utilization) reportada.
Vamos a modificar lo anterior con un punto más fino. Si se selecciona una Schedule Rule
que no sea Esperar (Wait), es posible obtener una Utilización programada (Scheduled Utiliza-
tion) reportada mayor que 1. Por ejemplo, si selecciona la opción Ignorar (Ignore) y el recurso
se halla asignado cuando está programado para que no se encuentre disponible (capacidad de
0), la capacidad del Resource disminuye a cero, pero el Resource se mantiene asignado hasta
que se libere. Digamos que se tiene un tiempo de ejecución de diez horas y que el recurso se
programa para hallarse disponible durante sólo las primeras cinco horas. Supongamos que el
recurso se ubicó en el tiempo 0 para una actividad con duración de 6 horas. En el tiempo 5, la
capacidad del recurso se reduciría a 0, pero se mantendría ubicado hasta el tiempo 6. La Utili-
zación instantánea (Instantaneous Utilization) reportada sería 0.6 (se utilizó 6 de las 10 horas),
mientras la Utilización programada (Scheduled Utilization) reportada sería de 1.2 (se utilizó 6
horas, pero se programó para que estuviera disponible sólo 5 horas).
Una complicación más (y, prometemos, final) para lo anterior surge cuando un Schedule (Pro-
grama) se adjunta al recurso y las capacidades programadas varían entre los diferentes valores
Modelación de operaciones y entradas básicas 147
positivos en el tiempo (por ejemplo, 1, 7, 4, etc.) más que variar sólo entre 0 y una sola constante
positiva. Si se tiene esta situación, recomendamos mucho que no use la Utilización instantánea
(Instantaneous Utilization) aunque se va a seguir reportando. Dependiendo de las capacidades,
las duraciones de tiempo y el uso, esta utilización puede ser menor que, igual a o mayor que la
Utilización programada (Scheduled Utilization) (se le pide demostrar esto en el ejercicio 4-20). En
este caso, le sugerimos en cambio que tome ventaja de la estadística de Frecuencias (Frequencies),
lo que le dará información detallada y precisa de cómo se utilizó el recurso; véase el tema Help
(Ayuda) “Resource Statistics: Instantaneous Utilization vs. Scheduled Utilization (Estadísticas
de Recuso: Utilización instantánea contra Utilización programada)” para más información. Así
que, por ejemplo, en el modelo 4-2 para el Rework Resource, le sugeriríamos que usara la Utiliza-
ción programada de 0.8567 de la tabla 4-1 en lugar de la Utilización instantánea de 0.8641.
Las nuevas estadísticas de frecuencia no son parte del reporte de la Revisión de categoría
(Category Overview) normal. Usted debe hacer clic en el reporte Frequencies (Frecuencias) en
el panel Reports de la barra de proyectos. Los resultados se dan en la figura 4-8.
La primera sección muestra las estadísticas que requerimos para determinar el número de
estantes necesarios en el proceso de revisión. En esta ejecución en particular, nunca hubo más
de 20 en la cola de revisión (esto es, no hay datos enlistados para tres o cuatro estantes), y hubo
más de 10 sólo 5.35% del tiempo. Esto debería implicar que el lector puede arreglárselas con un
solo estante, o por mucho, dos. Las estadísticas Sealer States (Estados del sellado) dan el por-
centaje de veces que el sellador pasó en los estados de Busy (Ocupado), Failed (Descompuesto)
e Idle (Ocioso).
Una última nota que vale la pena mencionar acerca de las estadísticas de frecuencia. Para
nuestros resultados, las últimas dos columnas, Estándar (Standard) y Restricted Percent (Por-
centaje de restricción), tienen los mismos valores. Es posible excluir datos selectivos que re-
sultan en diferencias entre estas columnas. Por ejemplo, si se excluye el estado Descompuesto
(Failed) para la Frecuencia (Frequency) de sellado, el Porcentaje estándar (Standard Percent)
se mantendría igual, pero la columna Porcentaje de restricción (Restricted Percent) tendría va-
lores sólo para Ocupado (Busy) y Ocioso (Idle), los cuales sumarían 100 por ciento.
entidades de espera durante la ejecución. Arena también colocó automáticamente las variables
para representar el número de entidades que se ubican en un módulo o que han salido de él.
De la forma en que se sugirió de cómo vienen a existir en el modelo (añadido cuando el lector
colocó el módulo) las construcciones de animación se “adjuntan” al módulo en dos sentidos. Pri-
mero, sus nombres, o Identificadores (Identifiers), provienen de valores en el cuadro de diálogo del
módulo; el lector no puede cambiarlos directamente en el cuadro de diálogo de construcciones de
animación. Segundo, si se mueve el módulo, los objetos de animación que fueron proporcionados
automáticamente se mueven con él; sin embargo, si se quiere que la animación se mantenga donde
está, sólo hay que mantener presionada la tecla Shift (mayúsculas) cuando mueva el módulo. En el
segundo punto, si por alguna razón se reemplazan los objetos de animación (por ejemplo, colas,
contadores) que vienen de forma automática con el módulo, éstos no se mueven con él.
Algunas veces es útil “llevar aparte” la animación a un área completamente diferente en
la ventana del modelo, lejos de la lógica. Si se hace eso, el lector debe considerar configurar
algunas Vistas Nombradas (Named Views) (véase la sección 3.4.13) para facilitar el ir atrás y
adelante. Si se quiere desconectar totalmente una construcción de animación del módulo que
originalmente acompañaba, Córtela (Cut) póngala en el Portapapeles (Clipboard) y Péguela
(Paste) de nuevo en el modelo. Eso retendrá todas sus características, pero ya no tendrá nin-
guna asociación con el módulo. Un método alternativo es borrar la construcción de anima-
ción que viene con el módulo y añadirla de nuevo desde el inicio, usando las construcciones
de la barra de herramientas Animar (Animate).
Si quiere dejar algunas de las construcciones de animación automáticamente colocadas con
los módulos y sólo hacer copias de ellas para la animación por separado, hay varias reglas bási-
cas a seguir. Cualquier construcción de animación que proporcione información (por ejemplo,
variables y gráficas) se puede duplicar. Las construcciones de animación que muestren una acti-
vidad de una entidad (por ejemplo, colas y recursos) no se deben duplicar en una animación. La
razón es muy sencilla. Si usted tiene dos colas animadas con el mismo nombre, Arena no sabrá
qué cola animada debería mostrar a una entidad en espera. Aunque Arena puede permitirle
duplicar una cola animada, generalmente mostrará todas las entidades en espera de la última
cola animada que colocó.
Nosotros usaremos el método “llevar aparte” para crear nuestra animación mejorada.
Empecemos por usar la característica alejar, View > Zoom Out [Ver > Alejar] ( o la tecla
−), para reducir el tamaño de nuestro modelo. Ahora haga clic en una cola y use Edit > Cut
[Editar > Cortar] ( o Ctrl + X) para cortar o quitarla del modelo actual y después Edit >
Paste [Editar > Pegar] ( o Ctrl + V) para colocar la cola en el área general donde el lector
quiera construir su animación (haga clic para colocar el rectángulo flotante). Repita esta acción
para las colas restantes, colocándolas en el mismo patrón general como en el modelo original.
Ahora puede acercar el enfoque en la nueva área y comenzar a desarrollar la animación mejorada.
Comenzaremos con cambiar nuestras colas. Luego crearemos imágenes nuevas para nuestras en-
tidades y añadiremos imágenes de recurso. Por último, añadiremos algunas gráficas y variables.
7JTUB
3FXPSL1SPDFTT2VFVF
7JTUB
3FXPSL1SPDFTT2VFVF
7JTUB 3FXPSL1SPDFTT2VFVF
7JTUB
3FXPSL1SPDFTT2VFVF
tener 30 entidades en la cola, pero si sólo 14 encajan en la animación, sólo se mostrarán las
primeras 14. Entonces, conforme se quita una entidad de la cola, se mostrará la siguiente.
Aunque las estadísticas de resultados reportadas al final serán correctas, esto puede ser más
bien engañoso para los principiantes y puede ocasionar que se suponga que el sistema está
trabajando bien cuando, de hecho, las colas son muy largas. Hay tres formas obvias (al menos
para nosotros) de evitar este problema: una es ver la variable de animación para el número en
la cola, la segunda es aumentar el tamaño de la cola de animación, y la tercera es disminuir el
tamaño de la imagen de entidad (si permanece visualmente adecuada).
Por principio de cuentas aumentemos el tamaño de la cola. La figura 4-9 muestra los pasos
que seguiremos para modificar nuestra cola. Primero seleccionamos la cola (View [Vista] 1) con
hacer clic en la cola Rework (Retrabajo), Rework Process.Queue. Note que aparecen dos
asas, una en cada extremo. Ahora el lector puede colocar su puntero sobre el asa en el extremo
izquierdo y cambiará a una cruz de líneas delgadas. Arrastre el asa para reducir la cola hacia
cualquier longitud y dirección que quiera (View [Vista] 2). Si corre la simulación ahora, ocasio-
nalmente observará muchas más partes esperando en Rework (Retrabajo).
También podemos cambiar la forma de la cola para representar el punto de ubicación físico
de cada entidad en ella. Haga doble clic en la cola seleccionada y aparecerá el cuadro de diálogo
Cola (Queue) como en la pantalla 4-23.
Seleccione el Tipo de punto (Point Type) de la cola y haga clic en el botón Points (Puntos).
Después añada puntos al hacer clic sucesivamente en Add (Añadir). Podríamos cambiar la ro-
Type (Tipo)
Point (Punto) seleccionado
3FXPSL1SPDFTT2VFVF
tación de la entidad en cada punto, pero por ahora aceptaremos estos valores predeterminados.
Cuando usted acepte estos cambios, la cola que resulta puede parecerse a la que se muestra en la
Vista (View) 3 de la figura 4-9. Observe que el frente de la cola se destaca con un punto rodeado
por dos círculos. Entonces puede arrastrar cualquiera de estos puntos a cualquier formación
que quiera (View [Vista] 4). Si quiere que todos estos puntos se alineen de forma ordenada, pue-
de usar la opción Coincidir (Snap) analizada en el capítulo 3. Arena ahora colocará entidades
en los puntos durante una ejecución de animación y los moverá hacia adelante, muy parecido a
como funciona una línea de espera en la vida real.
Para nuestra animación, simplemente disminuimos las colas (como se muestra en la Vista
2 de la figura 4-9) para las áreas Prep A, Prep B y Sellador (Sealer). Echamos mano de un
poco de imaginación con la cola Rework. Cambiamos la forma de la cola a puntos y añadimos
38 puntos. Esto nos permitió alinearlos en cuatro líneas de diez para representar cuatro estantes
disponibles como se muestra en la figura 4-10 (esto fue mucho más fácil de hacer con la opción
Coincidir [Snap] encendida).
New (Nuevo), crear sus propias imágenes y guardar el archivo para usarlo posteriormente. O
puede usar clip art (galería multimedia) al usar los comandos estándar copiar y pegar.
Para este ejemplo, como para la mayoría de ellos, mantendremos nuestras imágenes bastan-
te sencillas, pero el lector puede hacer sus imágenes de entidad y recurso tan elaboradas como
quiera. Puesto que las bolas azules y rojas son del tamaño correcto, usémoslas como punto de
inicio. Haga clic en el ícono Picture.Blue Ball (Imagen.Bola Azul) de la lista de la
izquierda y después haga clic en Copy. Ahora seleccione una de estas dos imágenes idénticas y
cambie el nombre (en el cuadro de diálogo Value) a Picture.Part A [Imagen.Parte A]
(¿no es eso obvio ahora?). Note que a medida que escribe el nuevo nombre también cambia en el
ícono seleccionado. Para cambiar la imagen, haga doble clic en el ícono de la imagen. Esto abre
la ventana Picture Editor (Editor de imagen) que le permitirá modificar el dibujo de la imagen.
Antes de que cambie esta imagen, observe el pequeño círculo gris en el centro del cuadrado; es el
punto de referencia de la entidad, que determina la relación de la entidad con los otros objetos de
la animación. Básicamente, este punto seguirá las huellas cuando la entidad se mueva, residirá en
el punto tomado cuando la entidad tenga el control de un recurso, y así sucesivamente.
Transformaremos esta imagen al insertar la letra “A” en el centro de la bola y cambiando a
un color de relleno más claro para que la letra sea visible. Cuando cierre esta ventana, el nuevo
dibujo se mostrará junto al nombre Picture.Part A. Ahora repita el mismo procedimiento para
hacer una nueva imagen de la Parte (Part) B. Sus imágenes finales se verán como la figura 4-12.
Si hace clic en una de las imágenes, el nombre completo se mostrará en el campo Value en la
parte superior. También hay un campo Factor de tamaño (Size Factor) en la parte izquierda más
inferior de la ventana (véase la figura 4-11). Puede aumentar o disminuir el tamaño de su imagen
de entidad al cambiar este valor. Para nuestra animación, aumentamos el Size Factor de 1 a 1.3.
El último paso es asignar estas nuevas imágenes a nuestras partes, de tal forma que ellas
se mostrarán en la animación. Para ello haga clic en el módulo de datos Entity e introduzca
los nuevos nombres en la celda Initial Picture (Imagen inicial) para nuestras dos partes. Verá
que sus nuevos nombres no aparecen en la lista de sugerencias, así que tendrá que escribirlos.
Sin embargo, una vez que el lector introduzca los nuevos nombres y acepte los datos, ellos se
reflejarán en la lista.
a su biblioteca y guárdelas. Su última imagen de recurso se verá como aquellas que se muestran
en la figura 4-13. También aumentamos nuestro Size Factor (Tamaño del factor) a 1.3, así que el
tamaño del recurso será consistente con nuestro tamaño de entidad.
Cuando acepte las imágenes de recurso y regrese a la ventana del modelo principal, su pun-
tero será una cruz de líneas delgadas. Coloque este puntero en el área aproximada donde usted
quiera colocar el recurso y haga clic. Esto coloca al recurso nuevo en su animación. (Por cierto,
¿se acordó de guardar su modelo recientemente?) Su nuevo ícono de recurso puede ser más
grande de lo que quería, así que ajústelo adecuadamente arrastrando una de las asas de sus
esquinas. La imagen de recurso también contiene un objeto que aparece como un círculo doble
con una línea de guiones conectada a la parte izquierda debajo de la imagen de recurso, la Seize
Area (Área tomada). Esta Seize Area se localiza donde su entidad debería estar cuando tenga
control del recurso; arrástrela al centro de su imagen de recurso si es necesario. Ahora ejecute
su animación para ver si sus imágenes de entidad y recurso son las tomas que quería. Si no lo
son, puede ajustar la posición del área tomada deteniendo la ejecución, mostrando las áreas
tomadas (usando la opción de menú View > Layers [Vista > Capas]), y arrastrándolas a la
posición deseada. Después de ajustar su posición, puede apagar la presentación de la capa del
área tomada antes de terminar la ejecución.
Una vez que esté satisfecho con su animación del recurso Prep A, puede añadir animaciones
al resto de los recursos. Para ello repita el proceso anterior para cada recurso, o copie y pegue
el recurso Prep A para las imágenes Prep B y Sealer. Una vez que haga esto, tendrá que hacer
doble clic en el recurso pegado recientemente para abrir la ventana Resource Picture Placement
y seleccionar el nombre adecuado de la lista de sugerencias del campo Identifier.
La imagen del recurso de revisión tendrá que modificarse porque tiene una capacidad de 2
durante el segundo cambio. Comencemos haciendo un copiar/pegar como antes, pero cuan-
do abrimos la ventana Resource Picture Placement, hay que editar la imagen Idle (Ocioso) y
añadir otro cuadrado (Edit > Duplicate [Editar > Duplicar] o Edit > Copy [Editar > Copiar]
seguidos de Edit > Paste [Editar > Pegar]) junto o debajo de la primera imagen. Esto dará espa-
cio para que dos entidades residan durante el segundo cambio. Copie esta imagen nueva en su
154 Capítulo 4
biblioteca y úsela para crear las imágenes de revisión restantes. Renombre el recurso (Rework)
y cierre la ventana.
El recurso de animación original tuvo un área de toma, así que haga doble clic en ella, luego
un clic en el botón Points (Puntos) y añada una segunda área de toma. Las áreas de toma son
más como colas de puntos y tienen cualquier número de puntos, aunque el número de puntos
usados depende en la capacidad del recurso. Como una cola, las áreas de toma se pueden mos-
trar a manera de una línea. Cierre esa ventana y coloque los dos puntos de área de toma dentro
de las dos cajas que representan el recurso.
En este punto debe tener una animación que comienza a verse más como su sistema percibi-
do. Puede que quiera reposicionar los recursos, colas, estaciones y así sucesivamente, mientras
que esté satisfecho con la forma en que la animación luce. Si ha construido este modelo por sí
mismo y con base en el modelo 4-2, necesitará despejar (no seleccionar) Run > Run Control
> Batch Run (No Animation) [Ejecutar > Control de ejecución > Ejecutar Modelo en lotes (Sin
animación)] para disfrutar los frutos de su trabajo artístico al crear el modelo 4-3. También
podrá añadir texto a etiquetas de elementos, colocar líneas o cajas para indicar colas o paredes
e incluso añadir “unas cuantas plantas con maceta”.
posición). Por último, usamos la herramienta Texto (Text) de la barra de herramientas Animate
para etiquetar estas variables.
Ahora añadimos una gráfica para el número en la cola de retrabajo. Haga clic en el botón
Plot (Gráfica) ( ) de la barra de herramientas Animate que abre la ventana Plot. Use el botón
Add para introducir la expresión NQ(Rework Process.Queue). Recuerde que usamos esta
misma expresión cuando creamos nuestros datos de Frecuencias. También hicimos un número
de otras entradas como se presenta en la pantalla 4-24. Después de aceptar estos datos, puede
aumentar el tamaño de la gráfica en la ventana del modelo y moverla hacia otro lugar en la ani-
mación. Por último, usamos la herramienta Texto (Text) de la barra de herramientas Animar
(Animate) para añadir los límites del eje y a nuestra gráfica.
Su animación ahora debería estar completa y verse parecida a la instantánea que se muestra
en la figura 4-15, tomada en el tiempo de simulación de 5453.0640 minutos. Los resultados
numéricos finales son, por supuesto, los mismos que los del modelo 4-2 ya que sólo cambiamos
los aspectos de la animación para crear el presente modelo 4-3.
156 Capítulo 4
Prep A #
3 4 Scrapped
" " " " " " "
" 9
8 Sealer
#
1 2 2 Salvaged
" # " # " # " # " "
11
Prep B 1 6 6 7 Shipped
#
# # # # # # # # # # #
12
4.4 Modelo 4-4: montaje electrónico y sistema de prueba con movimientos de piezas
Hasta ahora en este capítulo hemos desarrollado modelos sucesivos de montaje electrónico y
sistema de prueba, con el supuesto de que todas las transferencias de partes entre las opera-
ciones ocurrieron de forma instantánea. Generalicemos ese supuesto y ahora modelemos el
sistema con todas las transferencias de partes que toman dos minutos, sin importar el lugar
de donde provienen o al que van. Esto incluye la transferencia de partes que llegan a las
áreas de preparación y la transferencia de las partes que salen, ya sea de la estación Sellado
(Sealer) o Retrabajo (Rework) para ser descartadas, rescatadas o enviadas. Modificaremos el
modelo 4-3 para crear el modelo 4-4.
Primero, miremos la lógica del modelo (entidades que se mueven de un módulo a otro durante
la ejecución). Por debajo de la cubierta del rotor, como descubrimos (en concienzudo detalle) en
el capítulo 2, una ejecución de simulación la conducen las entidades (creándolas, moviéndolas
a través de la lógica, colocándolas en el calendario de eventos cuando va a ocurrir un retraso
en el tiempo y al final destruyéndolas). Desde esta perspectiva, una transferencia de estaciones
(ruta) es simplemente otro medio de incurrir en un retraso de tiempo.
Cuando una entidad deja un módulo que especifica una Ruta (Route) como un mecanismo
de transferencia, Arena coloca la entidad en el calendario de eventos con un tiempo de evento
dictado por la duración de la ruta (análogo al módulo Demora [Delay]). Más tarde, cuando es
el turno de la entidad de salir del calendario de eventos, Arena regresa la entidad al flujo de la
lógica del modelo al encontrar el módulo que define su estación de destino, generalmente a un
módulo Estación (Station). Por ejemplo, supongamos que se usa un módulo Route (Ruta) para
enviar una entidad a una estación llamada Sellado (Sealer). Cuando la entidad sale del
calendario de eventos, Arena encuentra el módulo que define la estación Sellado (Sealer)
y la entidad es dirigida o enviada a ese módulo. Éste es un ligero contraste con las conexiones
de módulo directo que hemos visto hasta ahora, en donde la transferencia de una entidad de
un módulo a otro ocurría sin colocar la entidad en el calendario de eventos y se representaba
de forma gráfica en el modelo por una línea de conexión entre dos módulos. Aunque las co-
nexiones directas proporcionan a un módulo una apariencia parecida al diagrama de flujo, al
hacer obvio cómo las entidades se moverán entre los módulos, la transferencia de estaciones
proporciona un gran trato de poder y flexibilidad al expedir entidades a través de un modelo,
como veremos cuando estudiemos Secuencias (Sequences) en la sección 7.1.
Las estaciones (Stations) y transferencia de estaciones (Station Transfers) también propor-
cionan la fuerza impulsora que hay detrás de una parte importante de la animación del modelo,
al desplegar el movimiento de entidades entre las estaciones conforme progresa la ejecución
del modelo. Las estaciones por sí mismas se representan en la vista del diagrama de flujo del
modelo al usar los símbolos de marcas de estación. Estas estaciones establecen ubicaciones en
el dibujo del modelo en donde se puede iniciar o terminar la transferencia de estaciones. El
movimiento de entidades entre las estaciones se define mediante los objetos del camino de ruta,
que con frecuencia conectan las estaciones entre ellas para la animación y establecen la vía de
movimiento entre las estaciones para las entidades que están enrutadas.
Pronto el lector verá que las marcas de las estaciones definen ya sea una estación de destino
(para una estación de término o un camino de ruta), o una estación de origen que permite la
transferencia fuera del módulo a través de una estación de transferencia (para el inicio de un ca-
mino de ruta). Se añaden estaciones de animación a través del objeto de la estación de la barra
de herramientas Animar Transferencia (Animate Transfer). Se añaden caminos de ruta al usar
el objeto Ruta (Route) de la barra de herramientas Animar Transferencia (Animate Transfer) y
dibujando una polilínea que establece la vía gráfica que siguen las entidades durante sus rutas.
Cuando la simulación está ejecutándose, verá imágenes de entidades que se mueven de forma
ininterrumpida a través de tales caminos de ruta. Ello hace surgir la pregunta: ¿cómo se relacio-
na esto con la lógica subyacente en donde aprendimos que una entidad reside en el calendario
de eventos durante su retraso de tiempo en la ruta? La respuesta es que la “maquinaria” de
animación de Arena se coordina con la “maquinaria” lógica subyacente, en este caso, el calen-
dario de eventos. Cuando una entidad encuentra una ruta en la lógica del modelo y se coloca
en el calendario de eventos, la animación muestra la imagen de la entidad moviéndose entre las
estaciones en el camino de ruta. Las dos maquinarias se coordinan de tal manera que el tiempo
158 Capítulo 4
Asignar a Parte
B Sellador y Estación de Ruta para
Llega la
Tiempo de llegada de prepara-
Parte B
llegada la Parte B ción B
Añadimos los mismos dos módulos al flujo de llegada de la Parte B. Las entradas de datos son
esencialmente las mismas, excepto que usamos todos los acontecimientos de la Parte B en lugar
de la Parte A (quienes modelen y sean tanto perezosos como listos duplicarán estos dos módulos,
harán las pocas ediciones que se requieren y luego las conexiones necesarias). Observe que no hay
conexiones directas que salgan de los dos módulos Ruta (Route). Como se analizó antes, Arena
se encargará de enviar las entidades a sus estaciones correctas.
Ahora pasemos a las áreas de preparación y hagamos las modificaciones necesarias, cuyo
resultado se señala en la figura 4-17 (casi... haremos una ligera modificación aquí antes de ter-
minar). Los dos módulos que preceden a los módulos Proceso (Process) de las áreas de prepara-
ción son módulos Estación (Station) que definen las nuevas ubicaciones de las estaciones, Prep
A Station y Prep B Station. Las entradas de los datos son básicamente las mismas que
para los módulos Estación (Station) previos (pantalla 4-25), con excepción del módulo Nombre
(Name) y Nombre de la estación (Station Name). Las partes que se transfieren desde la sec-
ción de llegada de la parte al usar los módulos Ruta (Route) llegarán a una de esas estaciones.
Los dos módulos Proceso (Process) restantes permanecen igual. Después añadimos un solo
módulo Ruta (Route), con conectores de llegada desde ambas áreas de preparación. Aun-
que las dos áreas de preparación se encuentran en diferentes ubicaciones, las partes se transfie-
ren a la misma estación, Estación de sellado (Sealer Station). Arena seguirá la pis-
ta de dónde se originaron las partes, la estación Prep A o Prep B. De nuevo, el único cambio de
los módulos Ruta (Route) colocados con anterioridad son el módulo Nombre (Name), Ruta
al sellador (Route to Sealer) y el Nombre de la estación de destino (destination Sta-
tion Name), Estación de sellado (Sealer Station).
Por ahora se puede ver qué falta para completar los cambios de nuestro modelo. Simple-
mente necesitamos evadir nuestras ubicaciones diferentes y añadir los módulos Estación y Ruta
en donde se requieran. La lógica del modelo para las áreas de Sellado y Retrabajo se mues-
tran en la figura 4-18. Usamos la misma notación que antes con nuestras nuevas estaciones
Estación de sellado (Sealer Station), Estación de retrabajo (Rework
Station), Estación de descarte (Scrapped Station), Estación de recupe-
ración (Salvaged Station) y Estación de envío (Shipped Station).
La lógica del modelo para nuestras áreas de descarte, recuperación y envío se muestra en la
figura 4-19.
Figura 4-18. Los módulos lógicos de las áreas Sellado (Sealer) y Retrabajo (Rework)
Modelación de operaciones y entradas básicas 161
Estación de llegada
de partes descartadas Registro de partes
Descartadas
(Scrapped Parts Arrival descartadas (Record
(Scrapped)
Station) Scrapped Parts)
Estación de llegada
de partes recuperadas Registro de partes Recuperadas
(Salvaged Parts Arrival recuperadas (Record (Salvaged)
Station) Salvaged Parts)
Estación de llegada
de partes enviadas Registro de partes Enviadas
(Shipped Parts Arrival enviadas (Record (Shipped)
Station) Shipped Parts)
En este punto, su modelo debería estar listo para ejecutarse (de forma correcta), aunque
probablemente no notará mucha diferencia en la animación, excepto que tal vez las colas para
Part B Prep y Retrabajo parecen ser mucho más largas (ya que hicimos más espacio en estas
animaciones de cola y establecimos una nueva escala para el eje y en la gráfica Cola de revisión
[Rework Queue]). Si mira sus resultados, podrá observar que los tiempos de ciclo de las partes
son mayores que en los modelos 4-3 y 4-2, que ocurren al añadir tiempos de transferencia; si
fuera a hacer réplicas múltiples de cada uno de estos modelos (véase la sección 2.6.2), notaría
bastante variabilidad en estas medidas de desempeño de resultado a través de las réplicas, con-
cluyendo de la simple réplica de este modelo contra el modelo 4-3 (o de forma equivalente, el
modelo 4-2) que es un negocio riesgoso.
Quizá se pregunte acerca de un enfoque más sencillo para modelar tiempos de transferencia
diferentes de cero: en lugar de todos estos módulos Estación y Ruta en todos lados, ¿por qué no
sólo quedarse en un módulo Proceso que interrumpa cada arco del diagrama de flujo, en donde
ocurre el tiempo de transferencia con Acción = Demora (Action = Delay) y un Tipo de demora
(Delay Type) que sea una constante de 2 minutos? De hecho, esto podría funcionar y producir
resultados numéricos válidos. Sin embargo, no nos permitiría animar las entidades que se mue-
ven alrededor, lo que nos gustaría hacer (por una parte, es divertido ver... brevemente). Así que
ahora añadiremos las transferencias de ruta a nuestra animación.
tación “gratis” en cada terminación de la animación Ruta. Después haga doble clic en la marca
de estación (suponiendo que ya está en su modelo... si no, podría nombrarla aquí y olvidar la
lista de sugerencias); haga lo mismo para la marca de estación final.
Si ésta es su primera ruta animada, querrá continuar y ejecutar su modelo de manera que
pueda ver las partes que llegan moverse de Part A Station a Prep A Station. Si no
queda contento con la colocación de las rutas, se pueden cambiar con facilidad. Por ejemplo,
si hace clic en la marca de estación arriba de la cola Prep A.Process (o, si tiene las opciones
marcadas bajo Vista > Consejos de datos [View > Data Tips], simplemente coloque su cursor
sobre la marca de estación), el nombre de la estación (Prep A Station) aparecerá debajo
de la marca. Puede arrastrar la marca de estación a donde desee (bueno, casi, siempre y cuando
permanezca dentro de la ventana del modelo). Note que si mueve la marca de estación, las rutas
permanecen adjuntadas. Una vez que haya satisfecho su curiosidad, coloque las estaciones y el
camino de ruta para la llegada de la Parte B y la transferencia a la estación Prep B.
Si usted añade las estaciones y rutas restantes, su animación estará completa. Sin embargo,
desde una perspectiva visual puede no tener una animación que capte con precisión el flu-
jo de las partes. Recuerde que colocamos las estaciones de preparación justo encima de las
colas de preparación, que están a la izquierda de las áreas de preparación. Asumamos que en
la instalación física las partes salen del lado derecho del área. Si ha usado las estaciones de
preparación existentes, las partes hubieran comenzado sus rutas desde el lado izquierdo de las
áreas. La solución a este problema es sencilla: sólo añada una segunda marca de estación en
las áreas de preparación (colocadas en el lado derecho) con el mismo Identificador (Identifier)
para la estación lógica. Cuando Arena necesite enrutar una entidad, buscará el camino de ruta,
no sólo la estación. Así que conforme construya las rutas restantes, deberá tener dos marcas de
estación (con el mismo nombre) en cada una de las áreas de preparación, del área de sellado y
del área de revisión. Su animación final debería verse parecida a la figura 4-20.
Por último, hay un punto sutil que puede no haber notado. Ejecute su animación y observe
las entidades de la Parte B conforme pasan de la llegada al área de preparación de la Parte B.
Recuerde que estamos creando cuatro entidades a la vez, pero sólo vemos una moviéndose.
Ahora note qué sucede conforme llegan a la cola (de pronto hay cuatro entidades). Conforme
sale, en verdad hay cuatro entidades que están siendo transferidas, es sólo que están una encima
de la otra durante la transferencia (se mueven precisamente a la misma velocidad porque los
tiempos de transferencia son constantes para todas las entidades). El lector puede verificar esto
al abrir la Ruta al módulo Ruta de Prep B y cambiar el Tiempo de ruta (Route Time) de una
constante 2 a EXPO(2), ocasionando que los tiempos de recorrido de las entidades difieran.
Ahora cuando se ejecute la animación, debería ver a las cuatro entidades comenzar una encima
de la otra y después separarse conforme se mueven hacia la cola. Puede exagerar esto al hacer
164 Capítulo 4
# #
# #
Figura 4-21. La imagen de entidad del lote B
clic en el camino de ruta para convertirlo en mucho más largo. Aunque ello mostrará cuatro
entidades en movimiento, no podría representar la realidad puesto que, si usted cree en los su-
puestos de modelación, se conjeturó que este tiempo de recorrido fuera constante por 2 minutos
(pero su jefe probablemente nunca lo sabrá).
Aquí hay una prestidigitación evidente para mantener los supuestos del modelo y aun hacer
que la animación se vea correcta. Si mostramos las partes B llegando, con cada parte animada
como una imagen de “gran lote”, obtendremos los resultados visuales deseados. Aún habrá
cuatro moviéndose a través de la estación Prep B, pero sólo se mostrará la de hasta arriba. Sólo
hay que volver a convertir la imagen en una sola entidad cuando entren a la cola del área de
preparación. Para implementar este concepto, necesitaremos crear una nueva imagen de “gran
lote” y hacerle dos cambios al modelo.
Primero utilice Editar > Imágenes de entidad (Edit > Entity Pictures) para abrir la ventana
Localización de imagen de entidad (Entity Picture Placement). Después haga una copia de la
imagen Picture.Part B y vuélvala a nombrar como Picture.Batch B en el campo
Valor (Value) de arriba. Edite este nuevo dibujo de imagen al hacer doble clic en su botón en la
lista. En el Editor de imagen (Picture Editor), use Copiar (Copy) y Pegar (Paste) para obtener
cuatro círculos Parte B como se muestra en la figura 4-21; mueva el punto de referencia de la
entidad cerca del centro de su paquete de cuatro. Después cierre la ventana Editar imagen (Pic-
ture Edit) y haga clic en Aceptar (OK) para regresar a la ventana del modelo.
Ahora que tenemos una imagen de lote, necesitamos decirle a Arena cuándo hay que usarla.
Abra el módulo Asignar (Assign) Assign Part B Sealer and Arrive Time y añada
(Add) otra tarea (en este caso, no importa en dónde se agregue en la lista de tareas, puesto que
no existe dependencia de una en otra en éstas). Dicha nueva tarea será de Tipo (Type) Entity
Picture, siendo éste Picture.Batch B (que deberá teclear aquí por primera vez). Esto
hará que Arena muestre la imagen de lote cuando enrute las llegadas de la Parte B a la estación
Prep B. Ahora necesitamos convertir de nuevo la imagen a una sola entidad cuando llegue al
área Prep B. Tendrá que insertar un nuevo módulo Asignar (Assign Picture) entre la es-
tación Prep B, Prep B Arrival Station y el módulo Proceso, Prep B Process. Esta
tarea tendrá el Tipo Entity Picture, siendo éste Picture.Part B (que estará en la lista
desplegada hacia abajo para Imagen de entidad [Entity Picture]). Así, cuando las entidades
entren a la cola o a servicio en Prep B Process, serán desplegadas como partes individuales.
Ahora, si ejecuta la simulación (con la animación encendida), verá llegar un lote que se
enruta al área Prep B, y partes individuales cuando el lote entra a la cola. Definir diferentes
imágenes de entidad le permite ver los distintos tipos de partes que se mueven a través del sis-
tema. Note el lote de cuatro partes B cuando entran al sistema. Aunque aún hay cuatro de esas
imágenes, una encima de la otra, la nueva imagen Lote B (Batch B) da la ilusión de un solo lote
de cuatro partes que entran.
Ahora que entiende el concepto de rutas, las estudiaremos en el capítulo 7 en un sistema
más complejo.
Modelación de operaciones y entradas básicas 165
Este mensaje le dice que el símbolo TNOW (la variable mal deletreada de Arena TNOW) no
está definido. Haga clic en Editar (Edit) y Arena lo llevará de forma directa al cuadro de diálo-
go del módulo Asignar (Assign) en donde colocamos el error. Continúe y corríjalo. Durante la
revisión, si encuentra que empleó mal un nombre o sólo quiere saber en dónde se usó una va-
riable, use la opción Editar > Encontrar (Edit > Find) para localizar todos los acontecimientos
de una serie de caracteres. Usted puede probar esta opción al usar la serie TNOW. Si por alguna
razón olvidó cuál era el error, use Ejecutar > Revisar errores (Run > Review Errors) para reabrir
la ventana de error que contiene el último mensaje de error.
Existe una cantidad de formas de revisar la exactitud del modelo o de encontrar errores lógi-
cos. La más obvia es a través del uso de una animación que muestra qué es lo que hace la lógica
del modelo. Sin embargo, hay veces en las que debe excavar aún más profundo con la finalidad
de resolver un problema. Primero veamos la opción Señalizar módulo activo (Highlight Active
Module) al seleccionar Ejecutar > Control de ejecución > Señalizar módulo activo (Run > Run
Control > Highlight Active Module).
Ahora ejecute su modelo. Si sus módulos no están visibles al inicio de la ejecución, Arena
cambiará la vista para que pueda ver los módulos destacados como entidades que pasan. Sin
embargo, en algunas computadoras esto sucede tan rápido que por lo general sólo verá los
módulos destacados en donde la entidad se detiene; es decir, en los módulos Demora (Delay) y
Disponer (Dispose). Si el lector no nos cree, use la opción enfocar (zoom) para ver de cerca, de
tal manera que sólo uno o dos módulos llenen la pantalla completa. Ahora haga clic ya sea en el
botón Ir (Go) o en el Paso (Step) y verá que Arena brinca alrededor e intenta mostrarle sólo los
módulos activos. De nuevo, por lo general trabaja tan rápido que no todos los módulos están
destacados, pero al menos intenta mostrarlos. Cuando finalmente se aburra, detenga su modelo
y despeje la opción Señalizar módulo activo (Highlight Active Module).
Modelación de operaciones y entradas básicas 167
También tiene algunas opciones que ver cuando el modelo está ejecutándose. Seleccione
Vista > Capas (View > Layers) para traer el cuadro de diálogo que se muestra en la figura 4-22.
Puede hacer esto mientras que todavía se encuentra en el modo Ejecutar (Run). Este cuadro de
diálogo le permitirá encender (revisar) o apagar (despejar) los diferentes artículos del desplega-
do durante la ejecución del modelo.
Ahora supongamos que usted tiene un problema con su modelo y que se halla receloso
del módulo Proceso (Process) en la lógica del sellado, Sealer Process. Sería bueno que la
simulación se detuviera cuando una entidad alcanzara este módulo y existen algunas formas
para hacer que esto suceda. Puede usar la opción Ejecutar > Control de ejecución > Pausa en
módulo (Run > Run Control > Break on Module) o el botón Pausa en módulo (Module Break)
en la barra de herramientas Ejecutar Interacción (Run Interaction). Primero necesita destacar
el o los módulos en los que desea detenerse. Luego seleccione Ejecutar > Control de ejecución >
Pausa en módulo (Run > Run Control > Break on Module) o presione el botón Pausa en módulo
(Module Break). Esto hará que las opciones seleccionadas se perfilen en un cuadro rojo. Ahora
haga clic en el botón Ir (Go). Su modelo se ejecutará hasta que una entidad llegue al módulo
seleccionado (¡eso puede tomar un rato!) El módulo hará una pausa cuando la siguiente enti-
dad llegue al módulo seleccionado. Ahora puede intentar encontrar su error (por ejemplo, al
hacer repetidamente clic en el botón Paso [Step] hasta que note algo raro) o haga clic en Ir (Go)
y la ejecución continuará hasta que la siguiente entidad llegue a este módulo. Cuando ya no
quiera seguir con las pausas, señalice el módulo y use Ejecutar > Control de ejecución > Pausa
en módulo (Run > Run Control > Break on Module) para apagar la pausa.
Ahora le presentaremos la barra de depuración (Debug Bar). Se puede activar esta ventana al
seleccionar Vista > Barra de depuración (View > Debug Bar) o la opción Ejecutar > Control de
ejecución > Puntos de pausa (Run > Run Control > Breakpoints). Esta ventana tiene varias eti-
quetas en el fondo que modifican sus contenidos y le permiten llevar a cabo diferentes funciones.
< La ventana Puntos de pausa (Breakpoints) proporciona la capacidad de manejar la
ejecución para examinar operaciones y lógica, evaluar cambios en el estado del sistema
o hacer presentaciones para otros. Las pausas en la ejecución se pueden establecer en
tiempos específicos (cuando un número de entidad específico se vuelve activo) en un
módulo o en un enunciado condicional.
< La ventana Calendario (Calendar) le permite ver todos los eventos futuros progra-
mados en el calendario de eventos de Arena para la simulación que se ejecuta. Los
tiempos de los eventos, los números de las entidades y las descripciones de los eventos
se muestran en un formato de tabla.
< La ventana Entidad activa (Active Entity) muestra los valores de los atributos de una en-
tidad activa en una organización en vista de árbol. El valor definido por el usuario y otros
atributos que pueden ser asignados pueden cambiarse a través de esa vista de árbol.
< Las ventanas de Monitoreo de valores (Watch) proporcionan tres ventanas de Monito-
reo de valores idénticas que le permiten supervisar los valores de cualquier expresión
en la simulación.
Ahora supongamos que el lector piensa que tiene un problema que sucede cerca del tiempo
29 y le gustaría detener la simulación en ese tiempo para ver si puede ubicar el problema per-
cibido. Podría retrasar el modelo e intentar presionar el botón Pausa (Pause) en el tiempo 29,
pero es muy probable que encuentre esto tedioso y difícil de hacer. Para facilitar el camino se
selecciona la etiqueta Puntos de pausa (Breakpoints), en la ventana ahora abierta de Depura-
168 Capítulo 4
ción (Debug), y después se presiona el botón Nuevo punto de pausa (New Breakpoint) en la es-
quina superior izquierda de esa ventana. Aparecerá el diálogo Propiedades del punto de pausa
(Breakpoint Properties), lo que le permite establecer un nuevo punto de pausa. Aceptaremos
los predeterminados excepto para el campo Tiempo (Time) en donde introduciremos un valor
de 29, como se indica en la pantalla 4-29.
Cuando hace clic en Aceptar (OK), la ventana debería parecerse a la figura 4-23.
Ahora haga clic en Ir (Go) y verá ejecutarse su simulación y la pausa en el tiempo 29. Antes de
proceder, echemos un vistazo a las otras ventanas. Seleccione la etiqueta Calendario (Calendar)
y debería ver los datos como se despliegan en la figura 4-24. Esto indica que el siguiente evento
(mostrado entre paréntesis) se encuentra programado para ocurrir en un tiempo de 29.2390. Tal
es el tiempo de simulación en minutos. La información a la derecha muestra el tiempo con base
en cómo configuró su calendario. Nosotros no utilizamos esta característica, así que muestra el
día y hora actuales. Debe notar que dicho tiempo se enlista como 00:29:14, que parece ser un
tiempo ligeramente diferente. Es lo mismo, porque el primer tiempo está expresado en unidades
fraccionales de las unidades de tiempo base (minutos) y el segundo en horas:minutos:segundos.
También le dice que es la entidad 17 e introducirá un bloque Asignar (Assign) que es parte del
módulo Proceso (Process) llamado Prep A Process (explicaremos más adelante de dónde
proviene este bloque mágico Asignar [Assign]). También le muestra los eventos restantes progra-
mados, incluyendo la última entrada, que es el fin de la réplica en un tiempo de 9 600 minutos.
Sólo por curiosidad, presione el botón Paso (Step) y verá cómo la simulación da el siguiente
paso y se detiene en un tiempo de 29.2390, justo como se predijo. También puede revisar los con-
tenidos de otras ventanas, pero encontrará que en el momento no contienen entrada alguna.
Ahora abramos la ventana Elementos de tiempos de ejecución al seleccionar la opción
Vista > Barra de elementos de ejecución (View > Runtime Elements Bar). Esta ventana le per-
mite echar un vistazo a los valores de propiedad actuales de los elementos de simulación en una
forma fácil (es decir, recursos, colas, transportadores, etc.) durante una ejecución de simulación.
Conforme se definen los elementos adicionales, aparecerán de forma automática como una
nueva etiqueta debajo de esta barra. Nuestra ventana contiene seis etiquetas; Variables, Colas,
Recursos, Estadísticas, Áreas activas y Procesos. La etiqueta Variables (Variables) muestra una
ventana con todas las variables y sus valores que se usaron en este modelo. En tal caso no es
muy interesante, puesto que no definimos ninguna variable del usuario y sólo contiene aquéllas
definidas por Arena.
Ahora examinemos los contenidos de la ventana Colas (Queues). Después de abrir esta ven-
tana, asegúrese de que la animación se muestre en la parte superior de su pantalla. Si no está
ahí, vuelva a posicionar la muestra. Debería ver cuatro colas, una para cada uno de los módulos
Proceso (Process) de nuestro modelo. También debería notar que el número actual de cada cola
concuerda con el número que se muestra en la animación. Ahora presione el signo “+” a la iz-
quierda de Prep B Process.Queue. Después expanda las Entidades (Entities) en la sección Cola
(Queue), luego la segunda entidad (Entidad [Entity] 13) y por último los Atributos (Attributes)
y las entradas Definidas por el usuario (User-Defined) para esa entidad. La ventana que resulta
se muestra en la figura 4-25.
Esta ventana muestra ahora los detalles para la segunda entidad en la cola Prep B. También
podría obtener la misma información si va a la animación y hace doble clic en la segunda entidad
de esa cola. La mayor parte de tal información debería explicarse por sí misma. Habiendo dicho
esto, expliquemos la diferencia entre el Número de entidad (Entity Number) (13) y el Número
del serial (Serial Number) (8). Cada uno de estos identificadores es único en el sentido de que
conforme se crean nuevas entidades, se les asignan números. Normalmente sólo se incrementan
en uno, aunque éste no siempre es el caso. El número del serial se refiere a las entidades creadas
por el modelo y el número de la entidad se refiere a las entidades proyectadas por Arena, inclu-
yendo las entidades realizadas por el modelo. Si vuelve a la figura 4-24, verá que las entidades 1,
2 y 3 fueron creadas por Arena y representan eventos que están programados por él: el fin de una
réplica, una falla en el sellado y un cambio en la capacidad para el recurso Revisión (Rework). A
la primera entidad creada por el modelo se le asignó el número de entidad 5 y el número de serie
170 Capítulo 4
1 (no se muestra en la figura 4-24). Si quiere verificar esto, puede inicializar de nuevo su modelo
y usar el botón Paso (Step) para seguir paso a paso la primera pareja de eventos.
En cualquiera de estas vistas, los valores definidos por el usuario y otros atributos que se
asignan pueden cambiar, así que probemos con esta característica. Primero haga doble clic en
el valor para la Imagen de animación (Animation Picture), 9, de la entidad. Cambiémosla a 1,
que resulta ser un avión. Si quiere saber qué imágenes están disponibles, necesitará ir a la vista
de elementos SIMAN (véase la sección 7.16). Si usted puede ver su animación, notará que el
avión ahora se encuentra visible en nuestra cola Prep B. Haga ahora doble clic en el Tiempo de
sellado (Sealer Time), 2.768368 e introduzca el valor de 100.
Antes de ejecutar nuestro modelo, mire las otras etiquetas de la barra de elementos de eje-
cución (Runtime Elements Bar). La mayor parte de esta información no requiere explicación.
Encontrará una entrada en la etiqueta Procesos (Processes) para cada uno de los módulos Pro-
ceso (Process) en el modelo. La etiqueta Recursos (Resources) muestra los recursos en nuestro
modelo y la etiqueta Áreas de actividad (Activity Areas) muestra las áreas de actividad del mo-
delo. Tales áreas de actividad se definieron por Arena conforme construimos nuestro modelo.
Los usuarios también pueden definir áreas de actividad, pero más que cubrirlas ahora, lo remi-
tiremos a la ayuda en línea de Arena. Por último, la etiqueta Estadísticas (Statistics) muestra los
valores actuales de la recolección de estadísticas por nuestro modelo.
Ilustremos algunas características adicionales al configurar otro punto de pausa en la cola
de sellado. Puesto que cambiamos el tiempo de proceso de sellado para la entidad 13, debería-
mos esperar ver que la cola se hace más larga una vez que la entidad está siendo procesada en
el sellador. Abra un nuevo diálogo de punto de pausa y seleccione Condición (Condition) de la
lista de sugerencias para el campo Pausa en (Break On) e introduzca la expresión NQ (Sealer
Process.Queue) > 20 en el campo Condición Expresión (Condition Expression). Eso hará
que Arena se detenga cuando el número de entidades en la cola de sellado exceda de 20.
Modelación de operaciones y entradas básicas 171
Ahora presione Ir (Go) y observe la animación. Debería ver entrar el avión y tomar el recur-
so de sellado y entonces mirar el crecimiento la cola de sellado. En el tiempo 119.7135, la ejecu-
ción hará una pausa debido a nuestro punto de pausa, con 22 entidades en la cola de sellado. Si
usted revisa el calendario, observará que la entidad 13 (nuestro avión) no está programada para
dejar el sellador hasta el tiempo 156.0733, así que esperaríamos que la cola siga creciendo por
al menos los siguientes 35 minutos de nuestra simulación.
Ahora es tiempo de presentarle al comando impulsado por Arena, Controlador de ejecu-
ción (Run Controller). Antes de ir al Controlador de ejecución (Run Controller), definamos
dos variables de Arena que usaremos: MR y NR. Existen muchas variables de Arena que se
pueden usar al desarrollar la lógica de un modelo y que logran verse durante el tiempo de
ejecución. Las dos de interés son:
MR (Nombre del recurso [Resource Name]): Capacidad del recurso (Resource capacity)
NR (Nombre del recurso [Resource Name]): Número de unidades de recurso ocupadas
(Number of busy resource units)
Note que éstas pueden cambiar durante la simulación, así que sus valores se refieren al es-
tado en ese momento.
Puede pensar en las variables de Arena como palabras mágicas puesto que proporcionan
información acerca del estado actual de la simulación. Sin embargo, también son palabras
reservadas, así que no puede redefinir sus significados o usarlos como sus propios nombres
para nada. Le recomendamos que tome unos pocos minutos para examinar la lista extensa de
variables de Arena en el sistema de Ayuda (Help).
Abra la ventana Comando de control de ejecución (Run Control Command) (que se mues-
tra en la figura 4-26) mediante la opción Ejecutar > Control de ejecución > Comando (Run >
Run Control > Command) o el botón Comando (Command) ( ) en la barra de herramientas
Ejecutar interacción (Run Interaction).
Ahora usemos las características de la ventana Comando de control de ejecución (Run Con-
trol Command) para aumentar la capacidad del recurso de sellado. Primero verificaremos los
valores actuales de NR y MR para el recurso Sellado (Sealer). Para hacer esto, use la caracte-
rística desplegable hacia abajo para seleccionar el comando MOSTRAR (SHOW) (el campo
muestra ahora el comando ASIGNAR [ASSIGN]). Después presione el botón Insertar coman-
y que resultan potencialmente tan importantes para los resultados como lo son los supuestos
de modelación estructural.
Así que ¿de dónde obtuvimos todos esos números y distribuciones para el modelo 4-2 (así
como para prácticamente todos los otros modelos de este libro)? Bueno, admitimos que sólo los
inventamos, después de juguetear un tiempo, para obtener las clases de resultados que queríamos
con la finalidad de ilustrar varios puntos. Buscamos esto ya que sólo estamos escribiendo un libro
más que se encuentra haciendo un trabajo real pero, desafortunadamente, el lector no tendrá tal
lujo. Más bien, tendrá que observar el sistema real (si es que existe) o usar las especificaciones para
él (si es que no existe), recopilar datos en lo que corresponda a su modelación cuantitativa de en-
trada y analizarlos para acercarse con “modelos” razonables o representaciones de cómo se espe-
cificarán o generarán en la simulación. Para el modelo 4-2 esto supondría la recolección de datos
en tiempos de entre llegadas reales para la Parte A, tiempos de proceso para la Prep de la Parte B,
tiempos de funcionamiento para el sellado y dotación de personal real en la estación de revisión
(así como todas las otras entradas cuantitativas requeridas para especificar el modelo). Entonces
necesitaría echarle una mirada a estos datos y hacer algún tipo de análisis en ellos para especificar
las entradas correspondientes para su modelo en una forma adecuada, realista y válida.
En esta sección describiremos este proceso y le mostraremos cómo usar el Analizador de
datos de entrada de Arena (Arena Input Analyzer) (que es una aplicación por separado que
acompaña y funciona con Arena), para ayudarlo a adecuar las distribuciones de probabilidad
a los datos observados en cantidades sujetas a variación.
Arena para esto y ejecútelo por un tiempo largo); de hecho, en la ejecución larga, resulta que
el número promedio de clientes en la cola es de 58.0167, muy distinto de 0. De forma intuitiva,
lo que sucede aquí es que, con el modelo aleatorio (correcto), a veces sucede que algún cliente
odioso tenga una gran demanda de servicio o que varios clientes lleguen casi al mismo tiempo;
son precisamente estos tipos de situaciones aleatorias las que ocasionan que la cola aumente, lo
que nunca sucede en un modelo determinista (incorrecto).
to, entonces los datos de orden almacenados en los anteriores ocho meses ya no son útiles
directamente, puesto que no contienen la nueva opción. Los cambios son que si se usan los
datos históricos de forma directa, no puede experimentarse ningún otro valor como los regis-
trados; pero si se muestrea a partir de una distribución de probabilidad ajustada, se pueden
obtener valores que no son posibles (por ejemplo, de las colas de distribuciones sin límites) o
perder características importantes (por ejemplo, datos bimodales, patrones secuenciales).
Las consideraciones prácticas pueden también venir dentro del juego. Puede que no se ten-
gan suficientes datos históricos para dirigir una ejecución de simulación que sea lo bastante
larga como para soportar su análisis. Se podría tener que considerar mucho el efecto de tener
acceso a archivos a la velocidad en que también se ejecuta su simulación. Leer muchos datos de
un archivo es mucho más lento que muestrear de una distribución de probabilidad, así que im-
pulsar el modelo con los datos históricos durante una ejecución puede disminuir su velocidad.
A pesar de su elección, Arena tiene herramientas incluidas para cuidar de la mecánica de
usar los datos históricos en su modelo. Si decide ajustar una distribución de probabilidad a los
datos, el Analizador de datos de entrada (Input Analyzer) facilita este proceso, proporcionando
una expresión que podrá usar directamente en su modelo; ahondaremos en esto en la sección
4.6.4. Si quiere dirigir el modelo directamente desde los datos históricos, puede traer los valores
una vez para convertirlos en parte de la estructura de los datos del modelo, o puede leer los da-
tos dinámicamente durante la ejecución de simulación, lo cual se analizará en la sección 10.1.
6.1 9.4 8.1 3.2 6.5 7.2 7.8 4.9 3.5 6.6 6.1 5.1 4.9 4.2
6.4 8.1 6.0 8.2 6.8 5.9 5.2
6.5 5.4 5.9 9.3 5.4 6.5 7.4
6.0 12.6 6.8 5.6 5.8 6.2 5.6 6.4 9.5 7.2 5.6 4.7 4.5 7.0
7.7 6.9 5.4 6.3 8.1 4.9 5.3 5.0 4.7 5.7 4.9 5.3 6.4 7.5
4.4 4.9 7.6 3.6 8.3 5.6 6.2 5.0
7.4 5.2 5.0 6.5 8.0 6.2 5.0 4.8 6.2 4.9
7.0 7.7 4.7 5.0 6.0 9.0 5.7 7.1 5.0 5.6
4.9 7.8 7.1 7.1 11.5 5.4 5.2
6.1 6.8 5.4 3.5 7.1 5.7 5.4
5.7 6.1 4.2 8.8 7.4 5.5
5.3 5.9 5.2 6.4 4.5 5.1 5.6 6.1
8.1 8.1 5.1 8.3 7.5 7.6 10.9 6.5 9.0 5.9 6.8 9.0 6.5 6.0
5.8 5.0 6.4 4.7 4.5 6.2 5.2 7.9 5.5 4.9 7.2 4.9 4.5 6.0
6.3 8.3 5.5 7.8 5.4 5.3 6.6 3.6 7.3 5.3 8.9 6.8 7.1 8.7
6.4 3.3 7.0 7.7 6.7 7.6 7.6 7.1 5.6 5.9 4.1 7.5 7.7 5.4
4.8 5.5 8.8 7.2 6.3 10.0 4.3 4.9 5.7 5.1 6.7 6.0 5.6 7.2
7.0 7.8 6.3 6.1 8.4
a través del texto. Otras opciones, como cambiar las características del histograma, se describen
en la Ayuda en línea.
El menú Ajustar (Fit) del Analizador de datos de entrada da opciones para ajustar las dis-
tribuciones de probabilidad individuales a los datos (esto es, estimar los parámetros requeridos
para una distribución dada). Después de que se ajusta una distribución, se dibuja su función
de densidad sobre el histograma mostrado y se presenta un resumen de las características del
ajuste en la sección de texto de la ventana. (Esta información también se escribe en un archivo
de texto ASCII plano que se llama DISTRIBUTION.OUT, donde DISTRIBUTION indica la
distribución que escogió para ajustar, así como TRIÁNGULO para triangular.) La expresión
exacta requerida para representar los datos en Arena también se da en la ventana de texto. Se
puede transferir esto a Arena si selecciona Editar > Copiar expresión (Edit > Copy Expression)
en el Analizador de datos de entrada, abre en Arena el cuadro de diálogo apropiado y pega la
expresión (Ctrl + V) en el campo deseado. La figura 4-29 muestra esto para ajustar una dis-
tribución triangular a los datos en el archivo partbprp.dst. Aunque veremos el tema de la
bondad del ajuste más adelante, en la gráfica de la figura 4-29 queda claro que la distribución
triangular no se amolda muy bien a los datos.
Si planea usar una distribución teórica en su modelo, puede comenzar seleccionando Ajus-
tar > Ajustar todos (Fit > Fit All) (o el botón en la barra de herramientas). Esto automá-
ticamente ajusta todas las distribuciones aplicables a los datos, calcula estadísticas de pruebas
para cada una (punto analizado más adelante), y presenta la distribución que tiene un valor
de error cuadrático mínimo (una medida de la calidad de la correspondencia de la distribución
con los datos). La figura 4-30 muestra los resultados de la opción Ajustar todos (Fit All) para
nuestros tiempos Prep de la parte B e indica que una distribución gamma con β = 0.775 y
α = 4.29, cambiada a la derecha por 3, proporciona el “mejor” ajuste en el sentido del mínimo
180 Capítulo 4
error cuadrático. La comparación de la gráfica con la de la figura 4-29 indica que esta distribu-
ción gamma ajustada por supuesto parece ser una mejor representación de los datos de lo que
hizo la distribución triangular ajustada. Más adelante se analizan otras consideraciones para
seleccionar qué distribución teórica usar en un modelo.
Si quiere usar una distribución empírica discreta o continua, use la opción Empírica (Em-
pirical) del menú Ajustar (Fit). Primero deberá ajustar el número de celdas del histograma,
que determina cuántos pares de probabilidad/valor se calcularán para la distribución empírica.
Para hacer eso, seleccione Opciones > Parámetros > Histograma (Options > Parameters > His-
togram) y cambie el número de intervalos.
Además de “ver a ojo de buen cubero” las densidades ajustadas sobre los histogramas, el
Analizador de datos de entrada proporciona tres medidas numéricas de la calidad del ajuste
de una distribución a los datos para ayudarle a decidir. Lo primero, y más sencillo de entender,
es el error cuadrático medio. Éste es el promedio de los términos de error cuadrático para cada
celda del histograma, que son los cuadrados de las diferencias entre las frecuencias relativas de
las observaciones en una celda y la frecuencia relativa para la función de distribución de proba-
bilidad, ajustada sobre esos datos de rangos de las celdas. A mayor valor de error cuadrático,
más lejana está la distribución ajustada de los datos verdaderos (y por lo tanto se tiene un peor
ajuste). Si ajusta todas las distribuciones aplicables a los datos, la tabla Resumen de ajustar to-
dos (Fit All Summary) ordena las distribuciones de menor a mayor error cuadrático (seleccione
Ventana > Resumen de ajustar todos [Window > Fit All Summary]), mostrado en la figura 4-31
para el archivo partbprp.dst. Si bien vemos que en el concurso de error cuadrático ganó la
gamma, estuvo seguida de cerca por la Weibull, beta, y Erlang, cualquiera de las cuales proba-
blemente será sólo tan adecuada como la gamma para usarse como entrada del modelo.
Modelación de operaciones y entradas básicas 181
Function Sq Error
Gamma 0.00387
Weibull 0.00443
Beta 0.00444
Erlang 0.00487
Normal 0.00633
Lognormal 0.00871
Triangular 0.0246
Uniform 0.0773
Exponential 0.0806
Las otras dos medidas de ajuste de distribución a los datos son las pruebas de hipótesis de
bondad de ajuste chi cuadrada y Kolmogorov-Smirnov (K-S). Éstas son pruebas estándar de
hipótesis estadísticas que se pueden usar para evaluar si una distribución teórica ajustada es
un buen ajuste de los datos. El Analizador de datos de entrada reporta información acerca de
las pruebas en la ventana de texto (véase la parte inferior de las figuras 4-29 y 4-30). De interés
particular es el valor p correspondiente, que siempre caerá entre 0 y 1.4 Para interpretar esto,
valores de p más grandes indican mejores ajustes. Los valores de p correspondientes menores a
0.05 indican que no hay un muy buen ajuste de la distribución. Por supuesto, como con cual-
quier prueba de hipótesis estadística, un valor de p alto no constituye una “prueba” de un buen
ajuste, sólo una falta de evidencia contra el ajuste.
Cuando se trata de ajustar o escoger el uso de una distribución, no hay un enfoque riguroso,
universalmente aceptado que se pueda utilizar para elegir la “mejor” distribución. Pruebas es-
tadísticas diferentes (como la K-S y la chi cuadrada) deben clasificar las distribuciones en forma
diferente, o los cambios en la preparación de los datos (por ejemplo, el número de celdas del
histograma) deben reordenar qué tan bien se ajustan las distribuciones.
Su primera decisión crítica es si usar una distribución teórica o una empírica. Puede ser
de utilidad examinar los resultados de las pruebas K-S y chi cuadrada. Si los valores de p
para una o más distribuciones son bastante altos (por ejemplo, 0.10 o mayor), entonces se pue-
de usar una distribución teórica y tener un buen grado de confianza de que está obteniendo una
buena representación de los datos (a menos que su muestra sea muy pequeña, en cuyo caso el
poder de discriminación de las pruebas de bondad de ajuste es muy débil). Si los valores de p
son bajos, se puede usar una distribución empírica para hacer un mejor trabajo al capturar las
características de los datos.
Si se decidió usar una distribución teórica, a menudo habrá algunas de ellas con estadísticas
de bondad de ajuste muy cercanas. En este caso, otros temas pueden ser de considerable valor
para seleccionar entre ellos:
< Antes que nada, se puede restringir a considerar sólo distribuciones con o sin límites,
con base en su entendimiento de cómo se usarán los datos en el modelo. Por ejemplo, a
menudo las distribuciones triangular (con límites) y normal (sin límites) serían buenos
ajustes de los datos como los tiempos de proceso. En una ejecución de simulación larga,
cada uno de ellos puede proporcionar resultados similares, pero durante la ejecución, la
distribución normal puede regresar con periodicidad valores bastante largos que pue-
den no ocurrir de forma práctica en el sistema real. Una distribución normal con una
4
Dicho con más precisión, el valor de p es la probabilidad de obtener un conjunto de datos que es más inconsistente
con la distribución ajustada que el conjunto de datos que de hecho tiene, si la distribución de ajuste es en realidad “la
verdad”.
182 Capítulo 4
media cercana a cero puede regresar un número artificialmente grande de muestras con
valor cero si la distribución se está usando para algo que no puede ser negativo, como
el tiempo (Arena cambiará todos los valores de entrada negativos a cero si se dan en un
contexto donde los valores negativos no tienen sentido, como un tiempo entre llegada o
de proceso); esto puede ser una razón convincente para evitar que la distribución normal
represente cantidades como tiempos de proceso que no pueden ser negativos. Por otro
lado, limitar la triangular para obtener una representación general fiel de los datos puede
excluir algunos valores distantes que se deberían capturar en el modelo de simulación.
< Otra consideración es de una naturaleza más práctica; a saber, que es más fácil ajustar
parámetros de algunas distribuciones que de otras. Si planea hacer cualquier cambio a
su modelo que incluya ajustar los parámetros de la distribución (por ejemplo, para aná-
lisis de sensibilidad o para analizar diferentes escenarios), debe favorecer aquéllos con
parámetros más fáciles de entender. Por ejemplo, al representar tiempos entre llegadas,
las distribuciones Weibull y exponencial pueden proporcionar ajustes de calidad similar,
pero es mucho más fácil cambiar una media de tiempo entre llegadas ajustando una
media exponencial que cambiar los parámetros de una distribución Weibull, ya que la
media en el último caso es una función complicada de los parámetros.
< Si está preocupado sobre si está haciendo la elección correcta, ejecute el modelo con
cada una de sus opciones para ver si hay alguna diferencia significativa en los resultados
(es posible que tenga que esperar hasta que el modelo esté casi terminado para poder
trazar una buena conclusión). Puede investigar más los factores que afectan los ajustes
de distribución (como las pruebas de bondad de ajuste) consultando la ayuda en línea de
Arena u otras fuentes, como Pedgen, Shannon y Sadowski (1995) o Law y Kelton (2000).
Por lo demás, seleccione una distribución con base en los temas cualitativos y prácticos
analizados antes.
Antes de dejar nuestra discusión sobre el Analizador de datos de entrada, queremos revisar
un tema que mencionamos previamente, a saber: qué hacer si sus datos parecen tener máximos
múltiples o quizá ciertos valores extremos, algunas veces llamados valores atípicos. Cualquie-
ra de estas situaciones por lo general hace imposible obtener un ajuste decente de cualquier
distribución teórica estándar. Como mencionamos antes, una opción es usar una distribución
empírica, que es probablemente la mejor ruta a menos que su tamaño de muestra sea muy
pequeño. En el caso de valores atípicos, desde luego irá a su conjunto de datos y se asegurará
que de hecho estén correctos en lugar de ser sólo ser algún tipo de error, tal vez sólo una fe de
erratas; si los valores de datos parecen estar en un error y no puede rastrear para confirmarlos
o corregirlos, entonces probablemente tenga que quitarlos.
En el caso tanto de máximos múltiples como valores atípicos (correctos), deberá considerar
dividir su conjunto de datos en dos subconjuntos (quizá más) antes de leerlos en el Analizador
de datos de entrada. Por ejemplo, suponga que tiene datos de máquinas sin funcionar y nota
a partir del histograma que hay dos máximos distintos; esto eso, los datos son bimodales. Al
revisar los registros originales, descubre que estos tiempos sin funcionar resultaron de dos si-
mulaciones diferentes (interrupción y mantenimiento programado). Separar los datos en dos
subconjuntos revela que los tiempos sin funcionar que resultan de las interrupciones tienden
a ser más largos que los tiempos sin funcionar debidos al mantenimiento programado, lo que
explica los dos máximos. Entonces puede separar los datos (antes de ir al Analizador de datos
de entrada), ajustar las distribuciones por separado de estos conjuntos de datos y después mo-
dificar su modelo lógico para contabilizar ambos tipos de tiempos sin funcionar.
Modelación de operaciones y entradas básicas 183
También puede separar los datos de una forma diferente directamente en el Analizador de
datos de entrada, con base puramente en sus rangos. Después de cargar el archivo de datos,
seleccione Opciones > Parámetros > Histograma [Options > Parameters > Histogram] para es-
pecificar topes para los Valores bajos (Low Value) y altos (High Value), y estos límites entonces
definirán a su vez los de un subconjunto de su conjunto de datos completo. Para los datos bimo-
dales, se enfocará en el máximo izquierdo al dejar solo el Valor bajo (Low Value) y al especificar
el Valor alto (High Value) como el punto donde el histograma toca fondo entre los dos máximos,
y después se enfocará en el máximo derecho al usar este punto de corte como el Valor bajo (Low
Value) y usar el Valor alto (High Value) original para todo el conjunto de datos; obtener el
punto de corte correcto puede requerir algún ensayo de prueba y error. Luego ajustar cualquier
distribución parece prometedor para cada subconjunto de datos (o usar la opción Ajustar todos)
para representar ese rango de los datos. Si ya ajustó una distribución (o usó Ajustar todos) antes
de hacer el corte de los Valores bajo/alto (Low/High Value), el Analizador de datos de entrada
inmediatamente rehará el ajuste y le dará los nuevos resultados para el subconjunto de datos
incluido en su corte; si eligió Ajustar todos (Fit All), una distribución diferente de entre todas
juntas puede aparecer como “la mejor”. Tendrá que repetir este proceso para cada subconjun-
to de datos. Como cuestión práctica, a lo mejor debería limitar el número de subconjuntos a
dos o tres ya que este proceso puede volverse difícil de manejar, y probablemente no sea obvio
dónde estarán mejor los puntos de corte. Para generar en su modelo de simulación dibujos que
representen a todo el conjunto de datos original, la idea es seleccionar uno de los subconjuntos
de datos aleatoriamente, con la selección de probabilidades correspondiendo al tamaño rela-
tivo de los subconjuntos y entonces generar un valor de la distribución que usted decidió para
ese subconjunto. Por ejemplo, si comenzó con un conjunto de datos bimodal de tamaño 200 y
configuró su punto de corte como el más pequeño con 120 puntos representando el máximo
izquierdo, y el más grande en 80 puntos representando el máximo derecho, generaría de la dis-
tribución ajustada de la parte izquierda de los datos con probabilidad de 0.6 y generaría para la
distribución ajustada de la parte derecha de los datos con una probabilidad de 0.4. Este tipo de
operación no se proporciona automáticamente en un módulo sencillo de Arena, así que deberá
reunir algo. Si el valor involucrado es un tiempo de actividad como una demora de tiempo en
que incurre una entidad, una posibilidad sería usar el módulo Decidir (Decide) con un Tipo de
2 rutas por Oportunidad (Chance) o N rutas por Oportunidad, dependiendo de si usted tiene
dos o más de dos subconjuntos para hacer un “volado” que decida de qué subconjunto generar,
entonces conecte (Connect) a uno de varios módulos Asignar (Assign) para dar un valor a un
atributo de entidad como un dibujo a partir de la distribución apropiada, y usar este atributo
hacia abajo para lo que sea que se vaya a hacer. Un enfoque diferente sería configurar una Expre-
sión de Arena (Expression Arena) para todo; las expresiones se cubren en la sección 5.2.3.
Uniforme Mínimo, Máximo Todos los valores igual- Poco conocimiento del
mente parecidos proceso
Límite en ambos lados
entradas adecuadas con el fin de tener una idea realista de qué tanta fe poner en sus resultados.
Necesitará ya sea recoger algún valor determinístico que usará en su estudio (o ejecutar el mo-
delo un número de veces con diferentes valores), o representar las características del sistema al
usar una distribución de probabilidad.
Si los valores son para algún otro asunto que una demora en el tiempo, como probabilidades,
parámetros de operación o características de diseño físicas, también podrá seleccionar una cons-
tante, valor determinístico o, en algunos casos, usar una distribución de probabilidad. Si usa un
valor determinístico al introducir una constante en el modelo (por ejemplo, 15% de oportunidad
de fallar en la inspección), es una buena idea presentar algunos análisis de sensibilidad para eva-
luar qué efecto tiene el parámetro en los resultados del modelo. Si los pequeños cambios al valor
influyen en el desempeño del sistema, habrá que analizar el sistema ampliamente por un rango
de valores (quizá chico, mediano y grande) en lugar que sólo por su mejor suposición.
Si los datos representan una demora de tiempo, casi seguro usará una distribución de proba-
bilidad para captar tanto la variabilidad inherente a la actividad como su incertidumbre acerca
del propio valor. Cuál distribución usará dependerá tanto en la naturaleza de la actividad como
en el tipo de datos que tiene. Cuando haya seleccionado la distribución, entonces necesitará
proporcionar los parámetros apropiados con base en sus estimados y su evaluación de la varia-
bilidad en el proceso.
Para seleccionar la distribución en ausencia de datos empíricos, primero deberá considerar
las distribuciones exponencial, triangular, normal y uniforme. Los parámetros para estas distri-
buciones son bastante fáciles de entender y proporcionan un buen rango de características para
un rango de aplicaciones de modelación, tal y como lo indica la tabla 4-2.
Si los tiempos varían de forma independiente (esto es, un valor no influye en el siguiente),
su estimación de la media no es tan grande y hay una gran cantidad de variabilidad en ellos,
la distribución exponencial debería ser una buena elección. Se usa con mayor frecuencia para
tiempos entre llegadas; ejemplos serían los clientes que acuden a un restaurante o llevar pedidos
de un almacén.
Si los tiempos representan una actividad donde hay un tiempo “más parecido” con alguna
variación de ellos, a menudo se usa la distribución triangular porque puede capturar los procesos
con grados de variabilidad chicos o grandes y sus parámetros son bastante fáciles de entender.
La distribución triangular se define por valores mínimos, los más probables (moda) y máxi-
mos, que es una forma natural de estimar el tiempo requerido para alguna actividad. Tiene
Modelación de operaciones y entradas básicas 185
la ventaja de permitir una distribución no simétrica de valores alrededor del más probable, el
cual es comúnmente encontrado en los procesos reales. También es una distribución de límites
(ningún valor será menor que el mínimo o mayor que el máximo) que puede ser o no una buena
representación del proceso real.
Estará deseando saber por qué estamos evitando la que debe ser la distribución más familiar
de todas, la distribución normal que es la clásica “curva de campana” definida por una media
y desviación estándar. Ésta regresa valores que son distribuidos simétricamente alrededor de la
media y es una distribución sin límites, lo que significa que puede obtener un valor muy grande
o muy pequeño de vez en cuando. En casos donde los valores negativos no pueden usarse en
un modelo (por ejemplo, el tiempo de retraso en un proceso), las muestras negativas de una
distribución normal son configuradas por Arena para un valor de 0; si la media de su distribu-
ción es cercana a 0 (por ejemplo, no más de tres o cuatro veces la desviación estándar de 0), la
distribución normal puede ser inapropiada.
Por otro lado, si la media es positiva y un poco más grande que la desviación estándar, habrá
sólo una pequeña oportunidad de obtener un valor negativo, puede ser que una en un millón.
Ésta parece (y es) pequeña, pero recuerde que en una ejecución de simulación grande, o una
que se repita muchas veces, una en un millón puede suceder, especialmente con computadoras
modernas y rápidas; y en ese caso, Arena truncaría el valor negativo a cero si su uso en el mo-
delo sólo puede ser positivo, a lo mejor causando que se tome una acción no deseada o extrema
y posiblemente incluso invalidando sus resultados. La figura 4-32 muestra un pequeño modelo
de Arena bastante inútil (modelo 4-5) en donde las entidades llegan, espaciadas exactamente
una hora entre ellas, una observación de una distribución normal con media μ = 3.0 y se asig-
na una desviación estándar σ = 1 al atributo Observación normal (Normal Observation), y la
entidad va a uno de dos módulos Grabar (Record), dependiendo de si la Observación normal
es no negativa o negativa, la cual cuenta el número de observaciones no negativas y negativas
obtenidas del total (le dejaremos ver a través de este modelo por usted mismo). La tabla 4-3 da
los resultados para varios valores de μ (manteniendo σ en 1), y se puede observar que esto va a
ocurrir aún si la media es tres o cuatro (o más) desviaciones estándar sobre cero. Al usar tablas
normales electrónicas, se puede calcular la probabilidad exacta de obtener un valor negativo,
y un número sobre éstos otorga el número aproximado de observaciones (en promedio) que
se necesitarían para obtener un valor negativo; no demasiados, considerando la velocidad de
generar éstos (toma alrededor de tres segundos en una gran variedad de computadoras portá-
tiles de 2.1 GHz completar cada una de las ejecuciones de un millón de tiradas, y menos de 30
Contar una
Observación
Set mu = 4.753672 para no negativa
P(negativo) = 1/(un millón)
Falso
Contar una
Observación
negativa
Tabla 4-3. Obtención de valores negativos de una distribución normal con desviación estándar σ = 1
periodos. Cuente el número de llegadas en cada periodo y luego calcule un índice diferente para
cada periodo. Por ejemplo, suponga que el centro de llamadas experimenta los siguientes núme-
ros de llamadas entrantes para cuatro periodos de 30 minutos entre 8:00 a.m. y 10:00 a.m.: 20,
35, 45 y 50. Entonces los índices, en unidades de llamadas por minuto, para los primeros cuatro
periodos de 30 minutos serían 0.67, 1.17, 1.50 y 1.67.
Una vez que haya estimado la función de razón de llegadas de esta forma, tiene que asegu-
rarse que Arena siga este patrón al generar las llegadas a su modelo. El módulo Crear (Create)
lo hará si selecciona Programa (Schedule) como un Tipo para Tiempo entre llegadas (Time
Between Arrivals). Luego debe especificar la función de razón de llegadas vía el módulo de
datos Programa (Schedule), similar a lo que se hizo en la sección 4.2.2 para un Programa
de recurso (Resource Schedule). Una precaución aquí: Arena le permite combinar y corres-
ponder cualquier unidad de tiempo que quiera, pero hay que tener cuidado que los números y
unidades de tiempo se definan adecuadamente. Haremos esto en el modelo 5-2 en el capítulo 5.
En el capítulo 12 hablaremos más acerca de estimar la función de razón de llegadas, así como
qué subyace en el método de generación de Arena para las llegadas no estacionarias.
4.8 Ejercicios
4-1 Los viajeros llegan a la puerta de entrada principal de la terminal de una aerolínea de
acuerdo a una distribución de tiempo entre llegadas exponencial con media de 1.6 minutos,
con la primera llegada en el tiempo 0. El tiempo de viaje de la entrada al registro se distribuye
de forma uniforme entre 2 y 3 minutos. En el contador de registro, los viajeros esperan en una
sola línea hasta que uno de los cinco agentes esté disponible para darles el servicio. El tiempo
de registro (en minutos) sigue una distribución Weibull con parámetros β = 7.76 y α = 3.91.
Una vez terminado su registro, son libres de ir a su puerta. Genere un modelo de simulación,
con animación (que incluya el tiempo de viaje de la entrada al registro) de este sistema. Ejecute
la simulación por 16 horas para determinar el tiempo promedio en el sistema, el número de
pasajeros que completan el registro y la longitud promedio de la cola de registro.
4-2 Desarrolle un modelo de un sistema serial sencillo de dos procesos. Los artículos llegan
al sistema con una media de tiempo entre llegadas de 10 minutos, con la primera llegada en
el tiempo 0. De inmediato se envían al proceso 1, que tiene un recurso sencillo con tiempo de
servicio medio de 9 minutos. Una vez completo, se mandan al proceso 2, que es idéntico al 1
(pero independiente de él). Los artículos salen del sistema cuando completan el proceso 2. Las
medidas de desempeño de interés son los números promedio en la cola en cada proceso y el
tiempo total de un artículo en el sistema. Usando una longitud de réplica de 10 000 minutos,
haga las siguientes cuatro ejecuciones y compare los resultados (notando que la estructura del
modelo no cambia, y que sólo son las distribuciones de entrada las que se modifican):
4-3 Modifique el problema de registro del ejercicio 4-1 al agregar recesos de los agentes. Las
16 horas se dividen en dos turnos de 8 horas. Los recesos de los agentes son escalonados, co-
menzando en 90 minutos en cada cambio. A cada agente se le da un receso de 15 minutos. Los
tiempos de almuerzo de los agentes (30 minutos) también son escalonados, comenzando en 3.5
horas en cada turno. Los agentes son mal educados y, si se encuentran ocupados cuando están
por ir a su tiempo de receso, dejan cualquier cosa y hacen que el pasajero espere hasta que se
termine su receso antes de terminar con él. Compare los resultados de este modelo con aquellos
del modelo sin recesos para los agentes.
4-4 Dos tipos de partes diferentes llegan a una instalación para su proceso. Las partes de
tipo 1 arriban con tiempos entre llegadas siguiendo una distribución lognormal con una media
log de 11.5 horas y desviación estándar log de 2.0 horas (note que estos valores son la media y
la desviación estándar de esta misma variable aleatoria lognormal); la primer llegada es en el
tiempo 0. Estas partes que llegan esperan en una cola designada sólo para partes de tipo 1 hasta
que un operador (humano) esté disponible para procesarlas (sólo hay un operador humano en
la instalación) y los tiempos de proceso siguen una distribución triangular con parámetros de
5, 6 y 8 horas. Las partes de tipo 2 llegan con tiempos entre llegadas siguiendo una distribución
exponencial con media de 15 horas; la primera llegada es en el tiempo 0. Estas partes esperan
en una segunda cola (designada sólo para partes de tipo 2) hasta que el mismo solitario opera-
dor (humano) esté disponible para procesarlas; los tiempos de proceso siguen una distribución
Modelación de operaciones y entradas básicas 189
triangular con parámetros de 3, 7 y 8 horas. Después de ser procesadas por el operador humano,
todas las partes se envían para procesarlas a una máquina automática que no requiere un ope-
rador humano, que tiene tiempos de proceso distribuidos de forma triangular con parámetros
de 4, 6 y 8 horas para ambos tipos de partes; todas las partes comparten la misma primera cola
a su llegada, primera en servicio para esta máquina automática. Las partes completas salen del
sistema. Suponga que los tiempos para todas las transferencias de partes son insignificantes.
Ejecute la simulación por 5 000 horas para determinar el tiempo total promedio en el sistema
(algunas veces llamado tiempo del ciclo) para todas las partes (agrupadas sin importar el tipo),
y el número promedio de artículos en las colas designadas para las partes que llegan. Anime su
modelo, incluyendo el uso de diferentes imágenes para los diferentes tipos de partes, y emplee
recursos que parezcan diferentes para ocupado y ocioso.
4-5 Durante el proceso de verificación del sistema de registro de la aerolínea del ejercicio 4-3,
se descubrió que había en realidad dos tipos de pasajeros. El primer tipo de pasajero arriba de
acuerdo con una distribución entre llegadas exponencial con una media de 2.4 minutos y tiene
un tiempo de servicio (en minutos) que sigue una distribución gamma con parámetros β = 0.42
y α = 14.4. El segundo tipo de pasajeros arriba de acuerdo a una distribución exponencial con
media de 4.4 minutos y tiene un tiempo de servicio (en minutos) que sigue 3 más una distribu-
ción Erlang con parámetros ExpMean = 0.54 y k = 15 (esto es, la Expresión para el tiempo de
servicio es 3 + ERLA(0.54, 15)). Un pasajero de cada tipo llega en el tiempo 0. Modifique el
modelo del ejercicio 4-3 para incluir esta nueva información. Compare los resultados.
4-6 Las partes llegan a un único sistema de estación de trabajo de acuerdo con una distribu-
ción entre llegadas exponencial con media de 21 segundos; la primera llegada es en el tiempo
0. Una vez que llegan, las partes inician el proceso. La distribución de tiempo de proceso es
TRIA(16, 19, 22) segundos. Hay varias características visuales fáciles de identificar que determi-
nan si una parte tiene un potencial problema de calidad. Estas partes, alrededor de 10% (deter-
minadas después del proceso inicial), se envían a una estación donde experimentan una inspec-
ción meticulosa. Las partes restantes se consideran buenas y se sacan del sistema. La distribu-
ción del tiempo de inspección es 95 más una variable aleatoria WEIB(48.5, 4.04), en segundos.
Cerca de 14% de estas partes fallan la inspección y se envían al desecho. Las partes que pasan
la inspección se clasifican como buenas y se envían fuera del sistema (así que estas partes no
necesitaron la inspección minuciosa, pero ya se sabe lo que se dice acerca de la retrospección).
Ejecute la simulación por 10 000 segundos para observar el número de partes buenas que salen
del sistema, el de partes desechadas y de partes que recibieron la inspección minuciosa. Anime
su modelo.
se estima que esta probabilidad, la misma para las cuatro estaciones de trabajo, será entre 5 y 10
por ciento. Desarrolle el modelo de simulación y haga seis ejecuciones de 10 000 minutos cada una
para probabilidades de 5, 6, 7, 8, 9 y 10 por ciento. Usando los resultados, construya una gráfica
del tiempo del ciclo promedio (tiempo del sistema) contra la probabilidad de una nueva visita.
También incluya el tiempo de ciclo máximo para cada ejecución en su gráfica.
4-9 Una oficina que distribuye placas de autos ha dividido a sus clientes en categorías para
equilibrar su volumen de trabajo. Los clientes llegan y entran en una de tres líneas según la
ubicación de su lugar de residencia. Modele esta actividad de llegada como tres flujos de lle-
gada independientes, usando una distribución entre llegadas exponencial con una media de 10
minutos para cada flujo, y una llegada en el tiempo 0 para cada flujo. A cada tipo de cliente se
le asigna un solo empleado separado para procesar la solicitud y aceptar el pago, con una cola
separada para cada uno. El tiempo de servicio es UNIF(8, 10) minutos para todos los tipos de
clientes. Después de completar este paso, la totalidad de los clientes es enviada a un segundo
empleado solo, que revisa las solicitudes y emite las placas (este empleado trabaja los tres tipos
de clientes, que se unen en una única cola de primera llegada, primer trabajo para este emplea-
do). El tiempo de servicio para esta actividad es UNIF(2.66, 3.33) minutos para todos los tipos
de clientes. Desarrolle un modelo de este sistema y ejecútelo por 5 000 minutos; observe los
tiempos promedio y máximo en el sistema para todos los tipos de cliente combinados.
Un consultor recomendó que la oficina no haga diferencias entre clientes en la primera
etapa y que use una línea sencilla con tres empleados que puedan procesar a cualquier tipo de
cliente. Desarrolle un modelo de este sistema, ejecútelo por 5 000 minutos y compare los resul-
tados con los del primer sistema.
4-10 Los clientes llegan a ordenar a un mostrador entre llegadas exponenciales con media de
10 minutos; el primer cliente llega en el tiempo 0. Un solo empleado acepta y revisa sus pedidos
y procesa los pagos, tardando UNIF(8, 10) minutos. Una vez completada esta actividad, los
pedidos son asignados aleatoriamente a uno de los dos almacenistas disponibles (cada almace-
Modelación de operaciones y entradas básicas 191
nista tiene 50% de oportunidad de obtener cualquier tarea individual) que monta los pedidos
para los clientes, lo que tarda UNIF(16, 20) minutos. Estos almacenistas sólo montan los pedi-
dos de los clientes que se les asignaron específicamente a ellos. Una vez recibidos sus pedidos,
los clientes salen del sistema. Desarrolle un modelo de tal sistema y ejecute la simulación por
5 000 minutos, observe los tiempos promedio y máximo de cada cliente en el sistema.
Un joven y brillante ingeniero recomienda que eliminen la asignación de un pedido a un
almacenista específico y permita a ambos seleccionar su siguiente actividad de una cola de pe-
didos de primera llegada, primer trabajo. Desarrolle un modelo de este sistema, ejecútelo por
5 000 minutos y compare los resultados con los del primer sistema.
4-11 Usando el modelo del ejercicio 4-2, configure la distribución de tiempos entre llegadas
en exponencial y la distribución de tiempos de proceso para cada proceso para uniformar en el
intervalo [9 – h, 9 + h]. Fije el valor de h en 1.732, 3.464 y 5.196, calcule la varianza (exacta) de
esta distribución y haga tres ejecuciones diferentes de 10 000 minutos cada una y compare los
resultados. Note que la media del tiempo de proceso siempre es 9 y la forma de la distribución
siempre es la misma (uniforme), la desviación estándar (y por lo tanto la varianza) es lo único
que cambia.
4-12 Usando el modelo del ejercicio 4-11, suponga que el tiempo de proceso tiene una media
de 9 y una varianza de 4. Calcule los parámetros para una distribución gamma que dé estos va-
lores. Haga una ejecución y compare los resultados con los del caso h = 3.464 del ejercicio 4-11.
Note que aquí tanto la media como la varianza son las mismas (sólo la forma de la distribución
es diferente).
4-13 Las partes llegan a un sistema de única máquina de acuerdo con una distribución entre
llegadas exponencial con media de 20 minutos; la primera parte llega en el tiempo 0. Una vez
que arriban, las partes se procesan en la máquina. La distribución de los tiempos de proceso es
TRIA(11, 16, 18) minutos. Las partes se inspeccionan y alrededor de 25% se envían de vuelta
a la misma máquina para reprocesarlas (el mismo tiempo de proceso). Ejecute la simulación
por 20 000 minutos para observar el número promedio y máximo de veces que una parte se
procesa, el número promedio de partes en la cola de la máquina y el tiempo del ciclo promedio
de las partes (el tiempo en que una parte entra en el sistema hasta su salida después de que, no
obstante, se requieran muchos pasos a través del sistema de máquina).
4-14 Usando el modelo del ejercicio 4-13, haga dos ejecuciones adicionales con tiempos de eje-
cución de 60 000 minutos y 100 000 minutos y compare los resultados con los del ejercicio 4-13.
4-15 Los artículos llegan de un sistema de recolección de inventario de acuerdo con una dis-
tribución entre llegadas exponencial con una media de 1.1 (todos los tiempos en minutos), con
la primera llegada en el tiempo 0. Una vez que llegan, los artículos son empacados por uno de
cuatro empacadores idénticos, con una sola cola “alimentando” a los cuatro empacadores. El
tiempo de empaque es TRIA(2.75, 3.3, 4.0). Las cajas empacadas entonces son separadas por
tipo (20% internacional y 80% nacional), y enviadas al embarque. Hay un único embarcador
para paquetes internacionales y dos para los nacionales con una sola cola alimentando a los
dos embarcadores nacionales. El tiempo de embarque internacional es TRIA(2.3, 3.3, 4.8), y el
tiempo del embarque nacional es TRIA(1.7, 2.0, 2.7). Este sistema de empaque funciona con
tres turnos de 8 horas, cinco días a la semana. A todos los empacadores y embarcadores se les
192 Capítulo 4
da un receso de 15 minutos a las dos horas en su turno, un tiempo para almorzar de 30 minutos
a las cuatro horas de su turno, y un segundo receso de 15 minutos a las seis horas de su turno;
use la Regla de programa de espera (Wait Schedule Rule). Ejecute la simulación por dos sema-
nas (diez días de trabajo) para determinar el número promedio y máximo de artículos o cajas
en cada una de las tres colas. Anime su modelo, incluyendo un cambio en la apariencia de las
entidades después de que son empacadas en una caja.
4-16 Usando el modelo del ejercicio 4-15, cambie los programas del empacador y embarcador
nacional para escalonar los recesos, de tal forma que siempre estén trabajando por lo menos
tres empacadores y un embarcador nacional. Comience el primer receso del empacador de 15
minutos en la primera hora del turno, el tiempo para almuerzo de 30 minutos a las tres horas, y
el segundo receso de 15 minutos a las seis horas de comenzado el turno. El primer receso de 15
minutos del embarcador nacional comienza a los 90 minutos del turno, el receso para almorzar
de 30 minutos a las 3.5 horas, y el segundo receso de 15 minutos a las seis horas del turno. Com-
pare los nuevos resultados con los del ejercicio 4-15.
4-17 Usando el Analizador de datos de entrada (Input Analyzer), abra una ventana nueva y
genere un nuevo archivo de datos (use Archivo > Archivo de datos > Generar nuevo [File > Data
File > Generate New]) que contenga 50 puntos para una distribución Erlang con parámetros:
ExpMean igual a 12, k igual a 3 y compensación igual a 5. Una vez que tenga el archivo de
datos, desempeñe un Ajustar todos (Fit All) para encontrar “el mejor” ajuste entre las distri-
buciones disponibles. Repita este proceso para 500, 5 000 y 25 000 puntos de datos, usando los
mismos parámetros Erlang. Compare los resultados de Ajustar todos para los cuatro diferentes
tamaños de muestra.
4-18 Hungry’s Fine Fast Foods está interesado en observar a su personal en la hora pico del
almuerzo, que va de 10 a.m. a 2 p.m. Las personas llegan caminando, en auto, o en un autobús
(apenas) programado, como sigue:
< Caminando: uno a la vez, los tiempos entre llegadas son exponenciales con media de 3
minutos; la primera persona que llega ocurre EXPO(3) minutos después de las 10 a.m.
< En auto: con 1, 2, 3 o 4 personas por auto con probabilidades respectivas 0.2, 0.3, 0.3
y 0.2; las entre llegadas se distribuyen como exponenciales con media de 5 minutos; el
primer auto llega EXPO(5) minutos después de las 10 a.m.
< Un solo autobús llega cada día a veces entre las 11 a.m. y 1 p.m. (el tiempo de llegada
distribuido de manera uniforme en este periodo). El número de personas en el autobús
varía de un día a otro, pero parece seguir una distribución Poisson con una media de 30
personas.
Una vez que las personas llegan, tanto solas como en grupo de cualquier fuente, funcionan
independientes sin importar su proveniencia. La primera parada es con uno de los emplea-
dos en el mostrador ordenar/pagar, donde ordenar toma TRIA(1, 2, 4) minutos y pagar toma
TRIA (1, 2, 3) minutos; estas dos operaciones son secuenciales, primero se toma la orden luego
se paga, por el mismo empleado para un cliente dado. La siguiente parada es para recoger la
comida ordenada, que toma una cantidad de tiempo distribuida de manera uniforme entre 30
segundos y 2 minutos. Entonces cada cliente va al comedor, que tiene 30 asientos (las personas
esperan sentarse en cualquier lugar, no necesariamente con su grupo), y participa de los alimen-
Modelación de operaciones y entradas básicas 193
tos sublimes, en lo que se tarda unos agradables TRIA(10, 20, 30) minutos. Después de eso, el
cliente camina satisfecho a la puerta y se va. Está permitido formarse en cada una de las tres
estaciones de “servicio” (ordenar/pagar, recoger la comida y el comedor), con una disciplina
FIFO. Hay un tiempo de viaje de EXPO(30) segundos desde cada estación para todos, excepto
para la puerta de salida (entrar para ordenar/pagar, ordenar/pagar para recoger la comida, y
recoger la comida para pasar al comedor). Después de comer, las personas se mueven más des-
pacio, así que el tiempo de viaje desde el comedor hasta la salida es de EXPO(1) minuto.
Los empleados tanto en ordenar/pagar como en recoger la comida tienen un único receso
que “comparten” rotándose. Más específicamente, en 10:50, 11:50, 12:50 y 1:50, un empleado
de cada estación tiene un receso de 10 minutos; si la persona que debe ir al receso en una esta-
ción está ocupado en el tiempo de receso, termina de servir al cliente pero aún así tiene que estar
de vuelta a la hora (así que el receso puede ser un poco más corto que 10 minutos).
El personal es el artículo principal que enfrenta Hungry’s. Actualmente, hay seis empleados
en la estación ordenar/pagar y dos en la estación de recoger la comida durante todo el periodo
de 4 horas. Ya que saben que el autobús llega a veces durante las dos horas de en medio, están
considerando un plan de personal variable en el que, para la primera y última hora habría tres
en la estación ordenar/pagar y uno en la de recoger la comida, y para las dos horas de en medio
habría nueve en la estación ordenar/pagar y tres en la de recoger la comida (note que el número
total de personas por hora en la nómina es el mismo, 32, bajo cualquiera de los dos planes: el
plan actual de personal o el plan alternativo, así que que el costo de la nómina es el mismo).
¿Cuál es su consejo?
En términos de resultados, observe la longitud promedio y máxima de cada cola, el tiempo
promedio y máximo en cada cola y el número total de clientes que completaron el servicio y sa-
lieron por la puerta. Haga gráficas de las colas para entrar en el ordenar/pagar, recoger la comi-
da y el comedor. Anime todas las colas, recursos y movimientos entre estaciones. Tome de una
biblioteca de imágenes .plb una imagen de humanoide para las entidades (diferente para cada
fuente de llegada), y haga un cambio adecuado en su apariencia después de que hayan termi-
nado de comer y dejado el comedor. También, aunque no sea capaz de animar a los empleados
individuales o los asientos en el comedor, seleccione imágenes razonables también para ellos.
4-19 En el análisis de los valores de salida de Utilización instantánea contra Utilización pro-
gramada de Arena de la sección 4.2.5, expusimos que si el Recurso (Resource) tiene una capa-
cidad fija (digamos, M(t ) = c > 0 para todos los tiempos t), entonces la Utilización instantánea
y la programada serán la misma. Compruebe esto.
4-20 En el análisis de los valores de salida de Utilización instantánea contra Utilización pro-
gramada de Arena de la sección 4.2.5, expusimos que ninguna de las dos medidas es siempre
más larga. Compruebe esto; recuerde que para corroborar que una declaración general no es
cierta usted sólo tiene que dar un ejemplo sencillo (llamado un contraejemplo) para lo que no
sea cierto.
4-21 Modifique sus resultados del ejercicio 4-7 para incluir tiempos de transferencia entre la
parte que llega y la primera estación de trabajo, entre las estaciones de trabajo (tanto para avan-
zar como para reprocesar), y entre la última estación de trabajo y la salida del sistema. Asuma
que todos los tiempos de transferencia de las partes son UNIF(2,5). Anime su modelo para
194 Capítulo 4
mostrar movimiento de la entidad y ejecútelo por 10 000 minutos usando una probabilidad de
retrabajo de 8 por ciento.
Modelado de operaciones
detalladas
En el capítulo 4 se mostraron los tipos de modelado que se podían hacer con módulos prove-
nientes en su mayoría del panel Basic Process (panel de procesos básicos). Son módulos de rela-
tivamente alto nivel, fáciles de usar que por lo general permiten avanzar hacia la construcción
de un modelo con un suficiente nivel de detalle. A veces será todo lo que necesite.
Pero a veces no lo es. Conforme adquiera experiencia en el modelado y sus modelos se
hagan más grandes, complejos y detallados, puede descubrir que le gustaría poder controlar
o modelar cosas a un menor nivel, con más detalle o sólo de forma diferente a lo que ofrecen
los módulos del panel de procesos básicos. Arena no lo deja varado en este nivel ni lo obliga a
aceptar un número limitado de construcciones de modelado “enlatadas”, ni tampoco le impone
aprender un lenguaje de programación o alguna sintaxis de seudoprogramación para captar
aspectos complicados del sistema. Más bien, ofrece una jerarquía rica y profunda de varios
niveles diferentes de modelado para obtener la flexibilidad que puede necesitar para modelar
alguna lógica específica de forma apropiada. Probablemente sea una buena idea comenzar con
los módulos de alto nivel, llevarlos tan lejos como vayan (quizá sea todo el camino) y cuando
necesite mayor flexibilidad de la que ellos proporcionan ir a un nivel más bajo y detallado. Esta
estructura le permite aprovecharse de las construcciones de modelado fáciles y de alto nivel,
hasta donde sea posible, y profundizar cuando lo necesite. Y debido a que los módulos de
Arena estándar proporcionan todo este poder de modelado, se acostumbrará a utilizarlos. Para
ponerlos a funcionar, simplemente necesitará familiarizarse con lo que hacen.
Este capítulo explora algunas de las construcciones (ciertamente no todas) de modelado
detalladas y de menor nivel que están disponibles en los paneles Advanced Process (Proceso
avanzado) y Blocks (de Bloque); este último proporciona la lógica del modelo del nivel más
bajo, en donde los módulos corresponden a los bloques en el lenguaje de simulación SIMAN
que subyace en Arena.
El ejemplo que usaremos para esto es un centro de llamadas telefónicas, incluyendo sopor-
te técnico, ventas y revisión del estado de los pedidos. En la sección 5.1 se describe el sistema
inicial y en la sección 5.2 se habla acerca de cómo modelarlo, al usar algunos nuevos conceptos
de modelado de Arena. En la sección 5.3 se describe nuestra estrategia básica de modelado. La
lógica del modelo y animación se desarrollan en la sección 5.4. En la 5.5 embellecemos nuestro
modelo y presentamos varios conceptos nuevos de modelado de Arena. Luego le mostraremos
cómo modificar el modelo original para crear el modelo embellecido. También mencionaremos
los temas importantes de los procesos de llegada no estacionarios (dependientes del tiempo) y
un mayor nivel de personalización en la animación. En la sección 5.6 añadimos más medidas
de resultado a nuestro modelo mejorado. Cerramos el capítulo en la sección 5.7 con un tipo de
modelo completamente diferente, un sistema de inventario, y aprovecharemos esta oportuni-
dad para ilustrar el uso de uno de los niveles de modelado más bajos y detallados de Arena, el
Blocks panel (panel de bloques) que compone el lenguaje de simulación SIMAN subyacente.
Después de leer este capítulo, el lector deberá ser capaz de construir modelos muy detallados
y complejos y de explotar la jerarquía rica y profunda de niveles de modelado de Arena.
196 Capítulo 5
balking [renuncia] en los sistemas de colas, aunque esto por lo general significa una decisión
por parte del consumidor de no entrar, más que ser rechazado como en nuestro modelo). Sin
embargo, no consideraremos el abandono (reneging), es decir, los clientes que llegan a una lí-
nea principal al inicio pero que después cuelgan el teléfono antes de que se les atienda (véase la
sección 9.3 para un análisis de cómo modelar el reneging [abandono]).
Algunas estadísticas de interés para estos tipos de sistemas son el número de rechazos al
cliente (señales de ocupado), tiempo total en la línea por tipo de cliente, tiempo de espera para
hablar con un operador telefónico por tipo de cliente, número de llamadas que esperan servicio
por tipo de cliente y utilización del personal.
un módulo Decide (Decidir) para verificar si alguna unidad del recurso “línea principal” está
disponible. Si hay una disponible, se permite que la entidad proceda y tome el recurso. Si no hay
ninguna disponible, se envía la entidad a la sección de quienes renuncian (balking) de entrar en
el modelo. Usaremos este segundo método en nuestro modelo.
Balking (renunciar) y rejection (rechazar) claramente representan una clase de falla del siste-
ma a la hora de satisfacer las necesidades de los clientes, así que contaremos el número de veces
que esto sucede en la simulación; cuanto más pequeño, mejor.
La primera llevará la cuenta del número de llamadas en el sistema y la segunda se usará para
terminar la generación de llamadas entrantes después de diez horas.
Las expresiones definidas por el usuario, por otra parte, no almacenan un valor. En lugar
de eso, proporcionan una forma de asociar un nombre con alguna expresión matemática.
Dondequiera que se haga referencia al nombre en el modelo, la expresión asociada es evalua-
da y se regresa su valor numérico. Por lo general, las expresiones se usan para calcular valo-
res de una distribución o de una ecuación compleja con base en los valores de los atributos
de la entidad, o incluso en los valores actuales de las variables del sistema. Si la expresión
matemática se usa sólo en un lugar en el modelo, podría ser más fácil introducirla de for-
ma directa en donde se requiera. Sin embargo, si la expresión se usa en varios lugares, o la
forma de la expresión que se va a usar depende del atributo de una entidad, a menudo es
mejor una expresión definida por el usuario. Para nuestro centro de llamadas, emplearemos
el módulo Expressions (Expresiones) para generar los tiempos de soporte técnico.
Las variables y expresiones tienen otros muchos usos que esperamos se conviertan en obvios
conforme el lector se familiarice más con Arena.
del modelo de simulación (por supuesto, existen elementos de juicio en este tipo de decisión). Se
pueden mezclar las construcciones de modelado desde diferentes niveles y paneles en el mismo
modelo. Conforme se familiarice con estos paneles (y niveles de modelado), debería hacerlo de
forma natural. Antes de seguir, analicemos brevemente los paneles disponibles.
El Basic Process panel (panel de procesos básicos) proporciona el nivel más alto de modela-
do. Está diseñado para permitirle crear modelos de alto nivel en la mayoría de los sistemas de
forma rápida y fácil. Usar una combinación de los módulos Crear (Create), Proceso (Process),
Decidir (Decide), Asignar (Assign), Grabar (Record), Lote (Batch), Separar (Separate) y Dis-
poner (Dispose) le permite una gran flexibilidad. De hecho, si le echa un vistazo a estos módu-
los encontrará numerosas características adicionales que no hemos analizado aún. En muchos
casos, estos módulos solos proporcionarán todo el detalle que se requiere para un proyecto de
simulación; incluso proporcionan las funciones comunes requeridas por casi todos los modelos,
así que es probable que los use a pesar de su nivel previsto de detalle.
El Advanced Process panel (panel de procesos avanzados) aumenta el Basic Process panel
(panel de procesos básicos al proporcionar capacidades adicionales y más detalladas de mode-
lado. Por ejemplo, la secuencia de los módulos Seize-Delay-Release (Tomar-Demorar-Liberar)
proporciona básicamente la misma lógica de modelado fundamental que un módulo Proceso,
pero podría dar más flexibilidad que éste. La característica práctica de los módulos del Advanced
Process panel es que se pueden juntar con casi cualquier combinación requerida para su modelo.
De hecho, muchos modeladores experimentados comienzan en este nivel porque sienten que el
modelo resultante es más transparente para el usuario, quien puede o no ser el modelador.
El Advanced Transfer panel (panel avanzado de transferencia) proporciona las construcciones
de modelado para las actividades de manejo de material (como transportadores) y para el movi-
miento de la entidad en general. Igual que las capacidades generales de modelado proporcionadas
por el Advanced Process panel, los módulos del Advanced Transfer panel le dan más flexibilidad.
El Blocks panel [panel de bloques] (parte de las plantillas SIMAN) proporciona un nivel
aún más bajo de capacidad de modelado. De hecho, ofrece la funcionalidad básica que se usó
para crear todos los módulos que se encuentran en los paneles de Procesos básicos, Procesos
avanzados y de Transferencia. Además, proporciona muchas otras construcciones de modelado
con propósitos especiales no disponibles en módulos de niveles más altos. Los ejemplos inclui-
rían rodeos “de un rato”, probabilística combinada y ramales lógicos, así como características
automáticas de búsqueda. Observe que varios de los módulos tienen los mismos nombres que
aquellos que se encuentran en paneles de niveles más altos. Aunque los nombres son los mis-
mos, los módulos no lo son. Se puede distinguir entre dos por el color y la forma.
La diferencia entre el Blocks panel (panel de bloques) por una parte y los paneles de Pro-
cesos básicos, Procesos avanzados y de Transferencia por otra, es fácil de entender si ya usó
SIMAN anteriormente, en donde se define el modelo y los marcos de experimento por sepa-
rado, incluso cuando se puede hacer todo esto en Arena. La diferencia quizá se ilustra mejor
entre los módulos Asignar de los dos paneles. Cuando se usa el módulo Asignar del panel de
procesos básicos, recibe la opción del tipo de tarea que desea hacer. Si asigna una tarea a un
nuevo atributo, Arena definirá de forma automática ese nuevo atributo y lo añadirá a las listas
de sugerencias para los atributos en cualquier parte de su modelo. Una razón para permanecer
en el nivel más alto posible es que el módulo Blocks Assign (asignar bloques) sólo le permite
hacer una tarea (no define el nuevo atributo). Aun con esta deficiencia, existen numerosas ca-
racterísticas poderosas y útiles disponibles sólo en el Blocks panel.
202 Capítulo 5
Además, el Elements panel (panel de elementos) presenta los módulos de marco del experimen-
to. Aquí es en donde, por ejemplo, puede encontrar el módulo Attributes (Atributos) para definir
su nuevo atributo. En raras ocasiones necesitará estas características, puesto que éstas se encuen-
tran combinadas con los módulos de las plantillas de Arena, pero si necesita este nivel tan bajo
para una característica especial de modelado (puede ir a Visual Basic o C, si es un verdadero glotón
de castigos), la encontrará disponible mediante la misma interfaz de Arena que todo lo demás.
Los paneles de bloques y de elementos también proporcionan módulos diseñados para el
modelado de sistemas continuos (al contrario que el proceso discreto que hemos visto). Vere-
mos éstos en el capítulo 11, junto con el Flow Process panel (panel de proceso de flujos) especí-
ficamente diseñado para esto.
Ahora regresemos a nuestro sistema de centro de llamadas, que sí requiere características
que no se encuentran en los módulos del panel de procesos básicos. En el desarrollo de nuestro
modelo, usaremos módulos de los paneles de Procesos básicos, Procesos avanzados y de Bloques.
En algunos casos, emplearemos construcciones de niveles más bajos porque así se requieren; en
otros casos, los utilizaremos sólo para ilustrar sus capacidades. Cuando modele con construc-
ciones de nivel bajo, necesitará acercarse al desarrollo del modelo de una manera ligeramente
diferente. Con las construcciones de un nivel más alto, hay que concentrarse en las actividades
reales. En cierto sentido, su modelo se convierte en un detallado diagrama de flujo de tales acti-
vidades. Por desgracia, hasta que no esté familiarizado con la lógica en los módulos disponibles,
es difícil desarrollar ese diagrama de flujo.
%FUFSNJOBS
UJQPEF
MMBNBEB
0USP
Figura 5-1. Lógica del proceso de selección de llegadas y servicio
tes de que sus modelos se vuelvan realmente complicados (¡y lo harán!) Muchos modeladores
usan un lápiz (una pluma los más confiados) y papel para esbozar su lógica usando terminolo-
gía familiar. Otros echan mano de un enfoque más formal y crean un diagrama lógico de clasi-
ficaciones que usan símbolos estándares de diagrama de flujo. Aun otro enfoque es desarrollar
una lista secuencial de actividades que necesitan ocurrir. Desarrollamos tal lista para la lógica
que se requiere para crear y dirigir llegadas (lo que parece ser muy similar a los módulos de
diagrama de flujo en la figura 5-1):
Create arriving calls (Crear llamadas que llegan)
Record attempted call (Grabar llamada de intento)
If a trunk line is available – Seize (Si una línea principal
está disponible – Tomarla)
Increment call counter (Aumentar el contador de llamadas)
Delay for recording (Demorar para grabar)
Direct call type (Determinar tipo de llamada)
Else [all trunk lines are busy] [Otro (todas las líneas prin-
cipales están ocupadas)]
Count rejected call (Contar llamadas rechazadas)
Dispose of call (Disposición de llamada)
Estos tipos de enfoque le ayudarán a formalizar los pasos de modelado y reducir el número
de errores y cambios en el modelo. Conforme el lector se haga más competente, puede llegar al
punto en donde comenzará a preparar su lógica básica usando los módulos de Arena (después
de todo, son similares a los elementos del diagrama de flujo). Sin embargo, aun entonces le re-
comendamos que prepare su lógica completa antes de comenzar a llenar los detalles.
El módulo Create (Crear), que crea entidades (llegadas) de acuerdo con nuestro proceso
definido con anterioridad, se describe en la pantalla 5-1.
Nosotros usamos un módulo Crear muy similar al de los modelos de los capítulos 3 y 4, con
excepción de la entrada en el campo Max Arrivals (Llegadas máximas). Recuerde que el sistema se
cierra a nuevas llamadas después de las 6 p.m. En la siguiente sección le mostraremos cómo usar la
variable MaxCalls (llamadas máximas) para terminar las llegadas de llamadas.
En la mayoría de los casos en los que se define un objeto nuevo (variable, atributo, etc.) en
los módulos de los paneles Procesos básicos y procesos avanzados, de forma automática Arena
hará una entrada en el módulo de datos apropiado. Esto sucede siempre que especifica el Tipo;
es decir, variable, atributo, etc. Sin embargo, en este caso, nosotros simplemente introdujimos
la variable MaxCalls sin especificar el tipo. Por lo tanto, necesitamos definir nuestra variable
MaxCalls. Hacemos esto en el módulo de datos Variable que se encuentra en el panel de
procesos básicos, que se ve en la figura 5-2. Abra este módulo de datos al hacer un clic en él y
un doble clic para añadir una nueva fila. Después teclee el Nombre de nuestra nueva variable,
MaxCalls y haga clic en la celda Initial Values (Valores iniciales) para abrir la ventana de la
hoja de cálculo en donde meter el valor inicial. Introdujimos un valor de 999999, lo que signi-
fica que el proceso de llegada se terminará después de 999999 llamadas de llegada (claramente,
un truco que explicamos más abajo).
Conforme continuamos con el desarrollo de este modelo, a veces estaremos pensando de an-
temano en cómo nos gustaría animarlo. Supongamos que queremos que la llamada que llega sea
animada como una bola negra. Podríamos asignar una imagen al usar un módulo Assign (Asig-
nar), pero especificaremos en nuestro módulo Crear que el tipo de entidad sea IncomingCall,
así que en este punto deberíamos hacer clic en nuestro módulo de datos Entity (Entidad) y seleccio-
nar Picture.BlackBall de la lista de sugerencias en la celda Initial Picture (Imagen inicial).
En este punto en el modelo, queremos grabar el número de llamadas de intención al usar un
módulo Record, como se indica en la pantalla 5-2.
Después hay que verificar una línea principal disponible. Si hay alguna línea disponible, la
tomamos; de otra forma, se rechaza (reject) la llamada del sistema. En la sección 5.2.1, analiza-
remos dos formas obvias (al menos para nosotros) de lograr esto. Para este modelo usaremos
un módulo Decide (Decidir), seguido por otro Seize [Tomar] (en el panel de procesos avanza-
dos) si hay alguna línea disponible.
El módulo Decide se usa para revisar si hay disponible alguna unidad del recurso Trunk
Line (Línea principal). Se podría usar el Expression Builder (Constructor de expresio-
nes) para desarrollar esta condición. La expresión NR (Trunk Line) < MR (Trunk Line)
contiene las variables MR y NR. La variable NR es el número actual de unidades ocupadas del
recurso y la variable MR es el número actual de unidades programadas del recurso o el número
total de unidades del recurso actualmente en existencia (ocupadas o de otra manera). Las en-
tradas para el módulo Decide se indican en la pantalla 5-3.
Una condición puede ser cualquier expresión válida, pero en general contiene algún tipo de
comparación. Tales condiciones pueden incluir cualquiera de las notaciones que se muestran en
la tabla 5-1. También se pueden usar las expresiones lógicas.
Si hay disponible alguna unidad del recurso Trunk Line (Línea principal), permi-
timos a la entidad proceder al módulo Seize [Tomar] (pantalla 5-4 del panel de procesos avan-
zados) en donde tomamos ese recurso. Normalmente, debiéramos usar el módulo Process pero,
en este caso, necesitamos separar la parte tomada del módulo Process de la parte demorada (en
breve se verá por qué). A diferencia del módulo Process, el módulo Seize sólo incluye la cola y
las acciones de tomar. Cuando se define el recurso en el módulo Seize, ese recurso entrará en
el módulo de datos Resource (Basic Process panel) de forma automática, pero su capacidad se
predeterminará en 1. Puesto que hay 26 líneas principales, necesitará abrir el módulo de datos
Resource y cambiar la capacidad a 26.
Después de tomar una unidad del recurso Trunk Line (Línea principal ), se envía
dicha entidad al siguiente módulo Assign [Asignar] (en la pantalla 5-5), en donde aumentamos
Opciones de Opciones de
Descripción sintaxis Descripción sintaxis
Y (And) .AND. O (Or) .OR.
Mayor que (Greater Than) .GT. > Mayor que o igual a (Greater than .GE. >=
or equal to)
Menor que (Less Than) .LT. < Menor que o igual a (Less than or .LE. <=
equal to)
Igual a (Equal To) .EQ. == Diferente a (Not equal to) .NE. <>
206 Capítulo 5
la variable Total WIP (Trabajo en proceso total). Esta variable se usará para man-
tener el rastro de cuántas llamadas activas se encuentran actualmente en el sistema. Más ade-
lante usaremos esta variable para determinar cuándo detener la ejecución de la simulación.
Entonces la entidad entra al módulo Store (Almacenar) (del panel de procesos avanzados)
en donde colocamos la entidad en el Storage (Almacenamiento) Initial Recording De-
lay Storage, en la pantalla 5-6. Aun cuando pensemos en esto como en colocar la entidad
en el almacenamiento, ello no impide que la entidad proceda según la lógica del modelo. Usa-
mos este Storage (Almacenamiento) de manera que podamos mostrar la entidad en la anima-
ción durante la demora inicial de la grabación. Le mostraremos cómo añadir tal animación de
almacenamiento en la sección 5.4.7.
Una vez que la entidad está en el almacenamiento, entra a un módulo Delay (Demora) en
donde incurre una demora UNIF(0.1, 0.6) que representa la grabación y el tiempo de la selec-
ción de una opción, en la pantalla 5-7.
In
crement Active Call Counter (Aumentar el
Name (Nombre)
contador de llamadas activas)
Assignments (Tareas)
Type (Tipo) Variable (Variable)
Variable Name (Nombre de la variable) Total WIP (WIP total)
New Value ((Nuevo valor) Total WIP + 1 (WIP total + 1)
Pantalla 5-5. Módulo Assign (Asignar) para aumentar el contador de llamadas activas
Modelado de operaciones detalladas 207
sentan las llamadas de soporte técnico y de ventas. El punto de salida Exit (Salir) se usará para
dirigir las llamadas del estado de la orden (8% restante).
La primera ramificación de Decide (Decidir) representa una llamada para soporte técnico. Las
entidades que toman esta ramificación se envían a un módulo Assign (Asignar) en donde asig-
namos la sección de llamada de soporte técnico de nuestro modelo. Las entidades que toman la
segunda ramificación se remiten a la sección de llamadas de ventas de nuestro modelo y las entida-
des restantes, la tercera ramificación, se canalizan a la sección de llamadas de estado de la orden.
Una vez tratadas las llamadas entrantes que son asignadas con éxito a una línea principal, ahora
debemos lidiar con aquéllas desafortunadas que reciben una señal de ocupado (las entidades recha-
zadas [rejected]). Éstas son enviadas al módulo Record (Grabar) en donde se cuentan las llamadas
rechazadas en el contador Rejected Calls (Llamadas rechazadas), pantalla 5-10.
Por último, estas entidades se envían a un módulo Dispose (Disponer), en donde salen del
sistema.
$SFBSFOUJEBE %JTQPTJDJÓOEFMB
EFDPSUFEF $PSUBSMMBNBEBT
FOUJEBEEFDPSUF
MMFHBEB FOUSBOUFT
EFMMFHBEB
método cortaría las llegadas (aunque no terminaría la ejecución), hemos elegido ser más astu-
tos e introducir el concepto de una entidad lógica para cortar las llamadas que lleguen.
En los modelos desarrollados hasta ahora, cada entidad que hemos creado ha representado
algún objeto físico, una llamada en el caso de nuestro modelo actual. Las entidades lógicas son
igual que cualquier otra entidad, pero se crean y usan para desempeñar alguna tarea lógica o de
control. En este caso, creamos una entidad lógica que cortará las llamadas entrantes y después
se destruirá. Las actividades para lograr esto se muestran aquí y los módulos de diagrama de
flujo aparecen en la figura 5-3:
Crear entidad de corte de llegada
Cortar llamadas entrantes
Disponer de la entidad
Notará que estos tres módulos parecen ser totalmente independientes del resto de nuestro
modelo. Sí lo son, excepto que esta sección de nuestro modelo interactuará con el resto del
modelo a través de una variable global. Comenzamos creando nuestra entidad de control con
un módulo Create, en la pantalla 5-11. Especificamos un tipo de llegada constante con un valor
de 999999. Si esto fuera todo lo que introdujéramos, tendríamos una llegada en el tiempo 0 y
después cada 999999 unidades de tiempo. Sin embargo, especificamos que la primera llegada
sucederá en el tiempo 600 (campo de primera creación) y que sólo habrá una llegada máxima
(campo de Max Arrivals). Como resulta ser, podríamos haber seleccionado cualquier tipo y
cualquier valor o conjunto de valores porque nunca se usan.
La única entidad lógica creada en el tiempo 600 entra al siguiente módulo Assign (Asignar)
en donde asignamos a la variable MaxCalls un valor de 1, como en la pantalla 5-12.
1SPDFTBSUJQPEF
QSPEVDUP
MMBNBEBUÊDOJDB
%FUFSNJOBSUJQP
EFQSPEVDUP
1SPDFTBSUJQPEF
0USP QSPEVDUP
MMBNBEBUÊDOJDB
1SPDFTBSUJQPEF
QSPEVDUP
MMBNBEBUÊDOJDB
Aquí una segunda grabación pregunta qué tipo de producto usa quien llama. En la sección
5.4.1 decidimos colocar una llamada entrante en un Almacenamiento para la primera grabación,
de tal manera que pudiéramos mostrarla en nuestra animación. Haremos lo mismo aquí, así que
primero colocaremos esa entidad en el Tech Call Recording Delay Storage (Alma-
cenamiento de demora de grabación de llamada técnica), como se indica abajo
en la pantalla 5-14.
Pantalla 5-18. Módulo proceso de llamada de soporte técnico para el tipo de producto 1
La expresión Tech Time se define usando el módulo de datos Expression (Expresión) que
se encuentra en el panel de Advanced Process (Procesos Avanzados). Haga clic en el módulo,
doble clic para añadir una nueva fila e introduzca el Name (Nombre) de la expresión, Tech
Time. Después haga clic en la celda Expression Values (Valores de la expresión), que abrirá una
hoja de cálculo, e introduzca la expresión TRIA (3, 6, 18) como se muestra en la figura 5-5.
Los dos módulos Process (Proceso) restantes de esta sección consiguen la misma tarea para
los productos de Tipo 2 y 3 que necesiten tomar un recurso Tech 2 y Tech 3, respectivamen-
te. Las capacidades para ambos recursos también tienen que colocarse en 3 en el módulo de
datos Resource (Recurso).
A continuación desarrollaremos la parte de llamadas de ventas de nuestro modelo.
"TJHOBSUJQPFJNBHFO --BNBEBEF
EFMBFOUJEBEEF WFOUBTFO
MMBNBEBEFWFOUBT QSPDFTP
Una llamada de ventas que llega se envía a un módulo Assign (Asignar), donde asignamos
el Entity Type (Tipo de entidad) a Sales Call (Llamada de ventas), y a la Imagen de
la entidad Picture.Green Ball, como en la pantalla 5-19.
Entonces esto procede a un módulo Process [Proceso] (pantalla 5-20) donde se toma una
unidad del recurso Sales (Ventas), se demora para el servicio TRIA (4, 15, 45) minutos y
libera su unidad del recurso Sales.
7FSEBEFSP
"TJHOBSUJQPF
y/PTFSFRVJFSFB
JNBHFOEFFOUJEBE %FNPSB
OJOHÙOFNQMFBEP
EFFTUBEPEFPSEFO
EFWFOUBT
53*"
'BMTP
Pantalla 5-21. Asignar tipo e imagen de entidad a la llamada de estado del pedido
216 Capítulo 5
Process (Proceso) que usamos en nuestra lógica de llamada de ventas y cambiar la selección
Priority (Prioridad) a High [Alta] (1). Entonces usaríamos otro módulo Process (Proceso) para
tomar el recurso de ventas de nuestras llamadas de estado del pedido y configurar la selección
de Prioridad a Medium [Media] (2) o Low [Baja] (3). Esto podría resolver nuestro problema de
asignación del recurso. Pero continuemos nuestro análisis de asignación de recursos y veamos
si hay otro camino.
Si todas las prioridades son iguales, Arena aplica una regla predeterminada para romper el
empate, y el recurso se asigna con base en la entidad que estuvo esperando más sin tener en cuenta
la cola en la que está. Por lo tanto, es esencialmente una regla romper el empate FIFO entre una
fusión de las colas involucradas. Esto significa que si sus colas estaban clasificadas de acuerdo con
los primeros datos apropiados, entonces la entidad que satisfaga ese criterio puede no siempre ser
asignada al recurso. Por ejemplo, un trabajo tardío puede haber apenas entrado a una cola, mien-
tras que un trabajo temprano puede estar al frente de otra cola y haber esperado más.
Arena proporciona una solución a este problema potencial en la forma de una cola comparti-
da. Una cola compartida es justo lo que su nombre indica (una sola cola que puede compartirse
para dos o más actividades de tomar). Esto permite definir una sola cola donde todas las enti-
dades que pidan el recurso se colocarán sin importar dónde estén sus actividades de tomar en su
modelo. Arena desempeña la contabilidad para asegurar que una entidad en una cola comparti-
da continúe en el lugar adecuado en la lógica del modelo cuando se le asigna un recurso.
En nuestro modelo, cada llamada de ventas y un pequeño porcentaje (15%) de las llamadas
de estado del pedido requerirán una unidad del recurso Sales (Ventas). Puesto que estas ac-
tividades se modelaron por separado, usaremos una cola compartida cuando intentemos tomar
una unidad del recurso Sales (Ventas). A ambos tipos de llamadas se les asigna una unidad
del recurso Sales (Ventas) con base en una regla FIFO, o el tiempo de espera más largo,
así que no se requiere una cola compartida en nuestro modelo para asegurar que la llamada
correcta se asigna al recurso. Sin embargo, una cola compartida también nos permite recopi-
lar estadísticas compuestas fácilmente del número total de llamadas que esperan a un recurso
Sales (Ventas) y proporciona la habilidad de mostrar todas estas llamadas de espera en la
misma cola (por si decidimos animar esa cola).
Puesto que no asignamos una prioridad a las llamadas de ventas, sacaremos ventaja del hecho
de que para una entidad con un valor sin asignar de un atributo, ese valor será cero de forma
predeterminada. Ahora usaremos un módulo Assign (Asignar) para definir un atributo nuevo,
Sales Call Priority (Prioridad de llamada de ventas), para aquellas llamadas
de estado del pedido que requieren una unidad del recurso Sales (Ventas) y configurar su valor
en 1, como en la pantalla 5-24.
El resultado es que las llamadas de ventas tendrán una Sales Call Priority (Prio-
ridad de llamada de ventas) con un valor de 0, mientras las llamadas de es-
Pantalla 5-27. Liberación del recurso ventas del estado del pedido
Las entidades que llegan entran a un módulo Release (Liberar) en donde liberamos el recur-
so Trunk Line (línea troncal), en la pantalla 5-28.
Al salir del módulo Release (Liberar), ellas entran a un módulo Assign (Asignar) donde
disminuimos el contador de llamadas activas, la variable Total WIP (WIP Total), presentada
en la pantalla 5-29.
Entonces usamos un módulo Record (Grabar) para grabar la llamada completa en el conta-
dor Completed Calls (Llamadas completas), pantalla 5-30.
Por fin la entidad se envía a un módulo Dispose (Disponer) en donde se destruye.
Antes de que podamos probar nuestro modelo, necesitamos abrir el diálogo Run Setup
(Configurar ejecución) y hacer entradas para el Project Title (Título del proyecto), Analyst
Name (Nombre del analista) y Project Description (Descripción del proyecto) que se encuen-
tran bajo el tabulador Project Parameters (Parámetros del proyecto). También aceptamos los
predeterminados bajo la sección Statistics Collection (Colección de estadísticas), que significa
que obtendremos de forma automática estadísticas de las entidades, recursos y colas. Ahora
vaya al tabulador Replication Parameters (Parámetros de réplica) en donde pedimos una sola
réplica sin periodo de calentamiento, una duración de réplica infinita y donde especificamos las
unidades de tiempo base como minutos.
En este punto, debe recordar (creemos que ahora ya lo olvidó) que antes, al principio de
la primera parte de la sección 5.4.1, le comentamos que íbamos a usar la variable Total WIP
para determinar cuándo detener la simulación. El centro de llamadas acepta llamadas entran-
tes sólo de 8 a.m. a 6 p.m. (600 minutos), pero cualquier llamada que esté en el sistema a las
6 p.m. se debe completar. Podríamos haber configurado sólo un tiempo de réplica largo de
forma arbitraria, pero esto podría dar resultados no precisos, en especial en utilizaciones del
recurso y otras estadísticas de tiempo persistente. Hay dos condiciones que deben ser ciertas
antes de que podamos apagar el sistema y terminar la ejecución de la simulación. La primera
es que el tiempo de la simulación debe ser por lo menos de 600 minutos. La segunda condición
es que debemos completar todas las llamadas. Puesto que la variable Total WIP se usa para
mantener el rastro de cuántas llamadas se encuentran actualmente en el sistema, sólo necesita-
mos revisar si aquélla es cero, lo que implica que todas las llamadas se han completado. Así que
introduciremos la expresión
TNOW >= 600.0 && Total WIP = =0
En el campo Terminating Condition (Condición de término); && significa “y”. De hecho,
usamos el Expression Builder (Constructor de expresión) para desarrollar la expresión.
Definimos esta variable especialmente para nuestros propósitos, aunque también podía-
mos usar la variable de Arena NR(Trunk Line). Esta variable nos dice qué tantas líneas
principales se hallan ocupadas en el momento, así cuando este valor es cero, no hay llamadas
activas en el sistema.
Por ahora tiene que entender muy bien cómo usar los módulos del panel Advanced Process
(Proceso avanzado), y lograr una mejor comprensión de qué proporcionan los módulos prin-
cipales en el panel Basic Process (Proceso básico). Habrá notado que la lógica de las últimas
dos secciones, llamadas de ventas y estado del pedido, tienen varios componentes en común.
Al definir y asignar un tipo de llamada y las expresiones para las demoras de tiempo, podría-
mos haber desarrollado una sección general de lógica que manejara ambos tipos de llamadas.
(Consideramos hacerlo.) Sin embargo, a veces este enfoque se complica bastante, y este tipo
de lógica pocas veces es obvia para otro modelador (o cliente) si alguien más tiene que usar o
modificar su modelo. A menos que pueda combinar cantidades significativas de la lógica del
modelo y hacerlas relativamente transparentes, le recomendamos que presente cada sección de
lógica por separado, aunque hacer esto puede ser a veces un poco redundante. Básicamente, es
una cuestión de gusto.
Eso completa nuestro desarrollo del modelo, pero antes intentemos ejecutarlo: desarrolle-
mos nuestra animación.
5.4.7 Animación
No vamos a ser extravagantes con la animación de nuestro modelo, pero sí queremos represen-
tar sus actividades. Animaremos nuestras demoras de grabación (Storages [Almacenamientos]),
recursos, colas de recurso, número de llamadas activas en cada sección del modelo y número
total de líneas troncales en uso. Nuestra animación final aparece en la figura 5-9. Esto muestra
el estado en aproximadamente 281.6 minutos de la ejecución de simulación.
Modelado de operaciones detalladas 223
Empecemos por colocar las animaciones de Almacenamiento para las demoras de graba-
ción. El objeto de animación de Almacenamiento se localiza en la barra de herramientas Ani-
mate Transfer (Transferencia Animar), que puede necesitar añadir a su modelo. Al seleccionar
el botón Storage (Almacenamiento) se abrirá el diálogo Storage que se presenta en la pantalla
5-31. Entonces puede seleccionar el almacenamiento que quiera animar de la lista de suge-
rencias Identifier (Identificador). Un almacenamiento animado contiene las mismas opciones
que una cola animada. Nosotros elegimos usar las predeterminadas, que resultarán en un al-
macenamiento en línea. Al presionar OK (Aceptar) se coloca el almacenamiento en línea en
su animación. Cuando una entidad se encuentra en este almacenamiento, aparecerá en nuestra
animación como si estuviera en una cola.
Una vez colocado el almacenamiento para la demora de grabación inicial, colocamos los al-
macenamientos para la llamada de soporte técnico y demoras de grabación de estado del pedido.
Cada vez que colocamos un módulo Process (Proceso) o Seize (Tomar) en nuestro modelo,
Arena proporcionó automáticamente una cola animada libre. Se pueden simplemente mover
estas colas a la porción de animación de su modelo, pero hay un punto sutil por saber. Estas
colas se adjuntan al módulo que las creó. Si mueve la cola a su animación y más tarde mueve
el módulo, la cola animada también se moverá. Esto puede ser bastante molesto cuando se
encuentre creando una animación inicial y después mueva módulos para hacer que su modelo
luzca mejor o para añadirle lógica. Hay dos formas de vencer este problema. La primera es
borrar todas las colas que se crearon cuando se colocó un módulo y luego añadirlas de nuevo
usando el objeto Queue (Cola) que se encuentra en la barra de animación Animate (Animar).
Una forma más conveniente es hacer clic en la cola, oprimir el botón Cut (Cortar) (o Ctrl-X)
para borrarla de la animación y luego usar el botón Paste (Pegar) (o Crtl-V) para agregarla de
nuevo. Nosotros hicimos esto para las cuatro colas de interés (las tres colas de soporte técnico
y la cola de llamada de ventas).
Luego añadimos animaciones de recurso para nuestro soporte técnico y ventas, igual que en
el modelo 3-3 (sección 3.5.2), modelo 3-5 (sección 3.5.3), modelo 4-3 (sección 4.3.3) y modelo
4-4 (sección 4.4), como se muestra en las figuras 5-9 y 5-10.
A continuación añadimos variables para indicar el número total de llamadas en nuestras
áreas principales (las tres áreas de soporte técnico y área de ventas). Usamos dos diferentes for-
mas de obtener esta información en nuestra animación. Primero veamos lo que hicimos para el
área de ventas. Añadimos una variable empleando el botón Variable de la barra de herramien-
tas Animate (Animar) e introdujimos la expresión NR (Sales) + NQ (Process Sales
Call.Queue). Esta expresión representa el número actual de unidades de recurso Sales
(Ventas) ocupadas además del número de llamadas en la cola que esperan por un recurso.
Echamos mano de un enfoque diferente para las áreas de soporte técnico. Arena guarda
un número bastante largo de variables, así que le sugerimos usar la ayuda de Arena para
aprender más acerca de qué variables tiene disponibles. Para nuestras necesidades, hay una
variable apropiada. Para cada módulo Process (Proceso) que coloca en su modelo, Arena
define de forma automática una variable NAME.WIP (NOMBRE.WIP), donde NAME
(NOMBRE) es el nombre que introduce para el módulo. También resulta que cuando co-
loca y llena un módulo Process (Proceso), Arena proporciona esa variable como parte de
la animación estándar para ese módulo, junto con la cola. Si observa de cerca su modelo
cuando no está en ejecución, verá un 0 rojo centrado directamente debajo de cada módulo
Modelado de operaciones detalladas 225
Process (Proceso). Para nuestro soporte técnico del producto Type (Tipo) 1, eso resulta ser
la variable Process Product Type 1 Tech Call.WIP. El lector puede colocar una
nueva variable al usar el botón Variable e introducir el nombre (no se encuentra en la lista
de sugerencias) o puede cortar y pegar la variable que proporciona el módulo Process (Pro-
ceso). De hecho usamos las funciones copiar y pegar al crear nuestra animación. Arena no
le permitirá animar colas múltiples o recursos con el mismo nombre, pero sí lo dejará para
las variables. Empleamos este enfoque para añadir las tres variables WIP a nuestra parte de
soporte técnico de la animación.
La última cosa que añadimos a nuestro modelo fue el número total de líneas principales en
uso. Podríamos haber usado la variable de Arena NR (Trunk Lines), que nos hubiera dado
el número actual de llamadas en el sistema. En su lugar, decidimos añadir una gráfica, de la
misma variable, que nos da una buena visión de cómo cambia la demanda en nuestro sistema
durante la ejecución de simulación. Para completar nuestra animación, agregamos algunas eti-
quetas y color de fondo.
Si ejecuta su modelo, puede darse cuenta, al ver nuestra gráfica del número de líneas princi-
pales ocupadas, que el sistema se encuentra algo lleno o cerca de estar lleno casi todo el tiempo;
la “parte alta llana” de la gráfica, a la altura 26, confirma nuestra lógica de llegada que rechaza
llamadas entrantes cuando las 26 líneas principales se hallan ocupadas. Al ver los resultados
de la ejecución, observamos que hubo 735 intentos de llamadas con 644 de ellas completas y
91 rechazadas (rejected) o de usuarios que renunciaron (balked). También puede notar que la
longitud de ejecución de la simulación fue sólo un poco más de 641 minutos. Los últimos 41 mi-
nutos fueron el tiempo que tomó completar las llamadas que estaban en el sistema a las 6 p.m.;
note que la gráfica de líneas principales disminuye a cero al final de la simulación, confirmando
nuestra lógica de terminación descrita antes.
Eso completa al modelo 5-1.
A continuación veamos a nuestro personal. Aunque nuestro modelo inicial supuso niveles
de personal constantes para nuestras áreas de ventas y soporte técnico, el nivel de éste de hecho
varía durante el día. Resulta que hay seis personas de ventas con el escalonamiento de los pro-
gramas diarios resumidos como (número de personas @ periodo de tiempo en minutos): 1@60,
3@60, 4@90, 5@60, 6@60, 5@90, 6@90, 5@30, 3@60 y 2@60.
Nuestros empleados de soporte técnico trabajan un día de ocho horas con 30 minutos libres
para almorzar (el almuerzo no está incluido en las ocho horas). Hay 11 personas de soporte
técnico cuyos programas de trabajo se muestran en la tabla 5-3. Charity y Noah sólo están
calificados para manejar llamadas del producto tipo 1; Tierney, Aidan y Emma sólo manejan
llamadas del producto tipo 2; Shelley, Jenny y Christie sólo del producto tipo 3. Molly se en-
cuentra calificada para manejar productos tipo 1 y 3, y Anna y Sammy están calificados para
manejar llamadas de cualquiera de los tres tipos de producto.
El último detalle que omitimos de nuestro modelo inicial fue que el cuatro por ciento de
las llamadas técnicas requieren más investigación después de completar la llamada de teléfo-
no. Las preguntas planteadas por estas personas que llaman se envían a otro grupo técnico,
fuera de los límites de nuestro modelo, para preparar una respuesta. El tiempo de prepara-
ción de tales respuestas se estima que sea EXPO(60) minutos. La respuesta que resulta se
envía de regreso al mismo empleado de soporte técnico que contestó la llamada original. Esta
persona entonces llama al cliente, que toma TRIA(2, 4, 9) minutos. Tales llamadas devueltas
requieren una de las 26 líneas troncales y reciben prioridad sobre las llamadas que entran. Si
una llamada devuelta no se completa en el mismo día que se recibió la llamada original, se
aplaza al día siguiente.
Si vamos a considerar cambiar nuestros niveles de personal para aumentar la satisfacción
del cliente, también debemos tener más detalles de cuándo se congestiona el sistema. Así que
añadamos contadores a nuestro modelo, los cuales usaremos para contar el número de llama-
das rechazadas durante cada hora de operación.
ponencial con una media de 20 con facilidad1 podríamos regresar un valor mayor a 31 para el
tiempo de la siguiente llegada. Esto daría como resultado ninguna llegada durante el segundo
periodo, cuando de hecho debería haber un valor esperado de 30 llegadas.2 En general, usar este
método simplista ocasiona una disminución incorrecta en el número de llegadas cuando se va
de un periodo al siguiente con un aumento en la razón de llegadas, o con una disminución en el
tiempo entre llegadas. Ir de un periodo al siguiente con una disminución en la razón de llegadas
aumentará de forma incorrecta el número de llegadas en el segundo periodo.
No obstante, es importante poder modelar y generar tales procesos de llegada correctamen-
te ya que ellos parecen surgir todo el tiempo, e ignorar la no estacionalidad puede crear serios
errores de validación del modelo, ya que los máximos y los mínimos pueden tener un impacto
significativo en el desempeño del sistema. Por fortuna, Arena tiene una habilidad propia para
generar llegadas Poisson no estacionarias (y para hacerlo de forma correcta) en el módulo
Create (Crear). El método adyacente utilizado se describe en la sección 12.3.
El segundo concepto nuevo es la necesidad de modelar una entidad que llega a una ubicación
o estación y seleccionar uno de los diversos objetos similares (pero no muy idénticos). La situa-
ción más común es la selección de un recurso disponible de un fondo común de recursos. Asu-
mamos que tiene tres operadores: Sean, Lynn y Michael. Cualquiera de ellos puede desempeñar
la tarea requerida, y seleccionaría a cualquiera de los tres, siempre y cuando uno se encuentre
disponible actualmente. El módulo de datos Sets (Conjuntos) en el panel Basic Process (Proceso
Básico) proporciona las bases para esta funcionalidad. Los conjuntos de Arena son grupos de
objetos del mismo tipo a los que se puede hacer referencia mediante un nombre común (el nombre
del conjunto) y un índice de conjunto. Los objetos que componen el conjunto se refieren como
miembros del conjunto. Los miembros de un conjunto en particular deben ser el mismo tipo de
objeto, tales como recursos, colas, imágenes, etc. Puede recolectar casi cualquier tipo de objetos
de Arena en un conjunto, dependiendo de los requerimientos de su modelación. Un objeto tam-
bién puede residir en más de un conjunto. Supongamos que en nuestro conjunto Operators
(Operadores) Lynn también está calificada como una persona de configuración. Por lo tanto,
debemos definir un segundo conjunto de recursos con el nombre Setup (Configurar) con
Lynn y Doug (Doug no es un operador). Ahora, si se requiere un operador, seleccionaremos del
conjunto de nombre Operators (Operadores), si se necesita una persona de configuración,
seleccionaríamos del conjunto llamado Setup (Configurar). Se debería escoger a Lynn me-
diante cualquier caso porque ella es miembro de ambos conjuntos. Puede tener tantos conjuntos
como desee con tantos o tan pocos traslapes como requiera.
Para nuestro centro de atención telefónica, tendremos que usar conjuntos para modelar el
personal de soporte técnico de forma correcta. También tendremos que considerar cómo mode-
lar las llamadas de soporte técnico devueltas. Éstas son únicas en que la misma persona de so-
porte técnico que manejó la llamada original debe devolverla, así que debemos tener una forma
1
Con probabilidad e−31/20 = 0.21, será (casi siempre) exacta. De hecho esta figura es la probabilidad condicional de
no llegadas en el segundo periodo, dado que haya llegadas en el primer periodo y que el último de éstos fuera en el
tiempo 29. Aunque esto no es lo que deseamos; queremos la probabilidad incondicional de no ver llegadas en el segundo
periodo. Es posible trabajar esto, pero es complicado. Sin embargo, es fácil ver que un límite bajo en esta probabilidad
se da para la probabilidad de que la primera llegada después del tiempo 0, generada como exponencial con una media
de 20 minutos, ocurra después del tiempo 60 (ésta es una forma [no la única] de no tener llegadas en el segundo periodo,
y tiene probabilidad e−60/20 = e−3 = 0.0498). Por lo tanto, el método incorrecto nos daría por lo menos 5% de oportunidad
de no tener llegadas en el segundo periodo. Ahora, regrese al texto, lea la oración que continúa y vea la siguiente nota
a pie de página.
2
La probabilidad de no tener llegadas en el segundo periodo debe ser e−60(1/2) = 0.000000000000093576.
Modelado de operaciones detalladas 229
de rastrear quién atendió la llamada original. Haremos esto al almacenar el índice de conjunto
del recurso específico asignado del personal de soporte técnico seleccionado, así sabremos qué
individuo tiene que devolver la llamada, si es necesario.
esa capacidad en cero. Esto podría haber resultado en el programa correcto para el primer día. El
problema al usar esta opción es que si decidimos tener réplicas múltiples y escogimos no iniciar el
sistema al inicio de cada día (en el diálogo Run Setup [Configurar Ejecución]), esto siempre daría
como resultado una capacidad cero después de la primera réplica. Por lo tanto, queremos estar
seguros que los últimos cinco periodos de tiempo de media hora tengan explícitamente capacidad
de cero. Logrará esto haciendo clic en el botón derecho en la celda Durations (Duraciones) del
programa y seleccionando Edit (Editar) vía Dialog (Diálogo) o Edit (Editar) vía Spreadsheet
(Hoja de cálculo). Al seleccionar Edit vía Spreadsheet se abre la ventana Durations (Duraciones),
en la figura 5-12, que le permite hacer doble clic para añadir una nueva fila y entonces introducir
la combinación de Value (Valor) y Duration (Duración) de 0, 5. Esto representa cinco periodos de
30 minutos con una capacidad de cero, así de forma explícita se llenan todas las 11 horas del día.
Al seleccionar Edit (Editar) vía Dialog (Diálogo) se abre el diálogo Durations (Duraciones),
que le permite introducir los mismos valores que se presentan en la pantalla 5-32. Si vuelve a
abrir el Graphical Schedule Editor (Editor gráfico de programas de eventos) después de añadir
estos datos, la figura se verá igual que antes. Unas palabras de precaución: asegúrese de que
salió del editor sin guardar los datos, o los datos añadidos (0, 5) serán borrados.
Incluso desarrollamos un programa para el personal de ventas y para el proceso de llegada.
Desarrolle el programa de proceso de llegada de la misma forma que desarrolló los programas de
recurso, con la excepción de que tiene que seleccionar Arrival (Llegada), en la celda Type
(Tipo), en lugar de Capacity (Capacidad).
El siguiente paso es definir nuestros 13 recursos en el módulo de datos Resource (Recurso).
Seleccionamos la opción Ignore (Ignorar) para el tipo Schedule (Programa), aún aunque
parezca que la opción Wait (Esperar) es la más prometedora para este tipo de operación. Si
una persona de soporte técnico se encuentra al teléfono cuando se programa que tenga un receso,
esa persona por lo general completaría la llamada y entonces tomaría un receso completo (la
opción Wait [Esperar]). Esto funcionará bien si nosotros ejecutamos sólo una réplica o ejecu-
tamos réplicas múltiples e iniciamos el sistema al principio de cada réplica. Desafortunadamente,
ése no siempre es el caso. Si elegimos la opción Wait (Esperar) y un recurso fue demorado
para almorzar durante 10 minutos, el resto del programa del día se recorrería 10 minutos. Aunque
éste no sea el problema, esa demora de 10 minutos se presentaría en el programa del día siguiente.
Todas las demoras serían acumulativas con el tiempo. ¡Eso podría ser un problema!
También hemos incluido algunos datos de costos (Ocupado/Hora y Ocioso/Hora) para
nuestro personal de soporte técnico y de ventas. La vista de hoja de cálculo final se muestra
en al figura 5-13.
Al tener establecidos nuestros recursos, ahora podemos definir nuestros conjuntos al usar el
módulo de datos Set (Conjunto) que se encuentra en el panel Basic Process (Proceso básico).
Primero definimos tres conjuntos de recursos. Ellos son:
Modelado de operaciones detalladas 231
Value (Valor) 0
Duration (Duración) 5
Figura 5-14. Ventana de hoja de cálculo Members (Miembros) del conjunto del producto 1
El módulo Set (Conjunto) nos permite formar conjuntos de recursos, contadores, tallies
(cuentas), tipos de entidad e imágenes de entidad. También se pueden formar conjuntos de cual-
quier otro objeto de Arena al usar el módulo de datos Advanced Set (Conjunto avanzado) que
se encuentra en el panel Advanced Process (Proceso avanzado). Forme un conjunto al hacer clic
en el módulo Set (Conjunto) y después haga doble clic en la vista de hoja de cálculo para añadir
una nueva entrada. Guiaremos al lector por los detalles para crear el primer conjunto de recursos.
Introduzca Product 1 (Producto 1) en la celda Name (Nombre), y seleccione Resource
(Recurso) de la lista de la celda Type (Tipo). Para definir a los miembros del conjunto, haga
clic en “0 Rows (0 Filas)” en la columna Members (Miembros) con el fin de abrir una hoja de
cálculo para enlistar a los miembros, y luego haga doble clic para abrir una nueva fila en blanco.
Puesto que hemos definido nuestros recursos, puede usar la opción de la lista de sugerencias para
seleccionar el Resource Name (Nombre del recurso) para cada miembro. Para añadir miembros
adicionales al conjunto, sólo haga doble clic donde se indica para añadir más filas nuevas. La vista
de la hoja de cálculo de miembros completa para el conjunto de Product 1 (Producto 1) se mues-
tra en la figura 5-14. Se necesitará repetir esto para los conjuntos de los Productos 2 y 3.
También definimos un conjunto Counter (Contador) (llamado Rejected Calls [Llama-
das rechazadas]) con diez miembros, que usaremos para mantener el rastro del número de
llamadas rechazadas (tonos de ocupado) para cada periodo de tiempo de una hora. Para este
conjunto, primero definimos los diez contadores al usar el módulo de datos Statistic [Estadís-
tica] (en el panel Advanced Process [Proceso avanzado]). Asignamos los nombres estadísticos
como Period 01 (Periodo 01) hasta Period 10 (Periodo 10) y los Counter Names
(Nombres de contadores) correspondientes como Period 01 Rejected Calls (Periodo
01 llamadas rechazadas) hasta Period 10 Rejected Calls (Periodo 10 lla-
madas rechazadas) (los 0 iniciales para los periodos 1 al 9 son elementos para ordenar de
forma adecuada los reportes de resultados con base en el alfabeto). También seleccionamos
Replicate (Replicar) para la celda Initialize Option (Opción iniciar), que hará que los
contadores se hallen despejados cada vez que las otras estadísticas estén libres, como se especi-
ficó en el diálogo Run > Setup (Ejecutar > Configurar). Podemos también seleccionar la opción
Yes (Sí); si la opción No está especificada y se presentan réplicas múltiples, entonces el valor del
contador al final de la réplica se mantendrá como el valor inicial al comienzo de la siguiente ré-
plica así los valores reportados serán acumulativos conforme se hacen las réplicas. Las primeras
cinco entradas de contador se muestran en la figura 5-15.
El módulo de datos Set (Conjunto) completo se muestra en la figura 5-16, la cual incluye tres
conjuntos Resource (Recurso) y uno Counter (Contador).
no lo aburriremos con los detalles de cada uno. En lugar de eso, nos enfocaremos en los nuevos
módulos y conceptos.
Comencemos con la sección de llegadas de llamadas. Hicimos nuestro primer cambio al mó-
dulo Create (Crear) que crea nuestras llamadas entrantes. En la sección Time Between Arrivals
(Tiempo entre llegadas), seleccionamos Schedule (Programa) de la lista Type (Tipo) de su-
gerencias. El programa de llegada, Arrival Schedule (Programa de llegada), que
creamos arriba se introdujo en el campo Schedule Name (Nombre del programa). Puesto que
el módulo Crate (Crear) seguirá nuestro programa y se detendrá de forma automática creando
nuevas llegadas con 11 horas en la simulación, podemos borrar los tres módulos que teníamos en
nuestra sección límite de llegada del modelo 5-1. También borramos el módulo Assign (Asignar),
Increment Active Call Counter (Aumentar contador de llamada acti-
va), usado para aumentar la variable Total WIP. Usamos esta variable en la expresión que
introdujimos en la porción Terminating Condition (Condición de término) en el diálogo Run
> Setup (Ejecutar > Configurar) del modelo 5-1. Reemplazamos esa variable con una variable
NR(Trunk Lines). Procedimos de esta manera por dos razones. Primera, nosotros realmente
no necesitamos la primera variable, así que hicimos más simple el modelo al borrarla de nuestro
nuevo modelo. La segunda razón es que usar la variable Total WIP, en la nueva lógica reque-
rida para manejar las llamadas devueltas en nuestra área de soporte técnico, ocasiona algunos
problemas de modelado. Podríamos haber tenido que disminuir la variable cuando la llamada
devuelta se envió a la oficina de apoyo y luego incrementarla cuando la respuesta se devolvió a
soporte técnico. Por lo que tomamos el camino de salida fácil ya que esa variable en realidad no
se necesitó y se eliminó de nuestro modelo. El último cambio requerido para esta primera sección
de nuestro modelo fue para el módulo Record (Grabar) usado para grabar el número de llamadas
rechazadas. Como se mencionó antes, decidimos mantener el rastro del número de llamadas re-
chazadas en cada periodo de tiempo de una hora. Para llevar a cabo esto, definimos 10 contadores
en el módulo de datos Statistic (Estadística) y formamos un conjunto llamado Rejected Ca-
lls (Llamadas rechazadas) que contiene estos contadores. Alteramos el módulo Record
(Grabar) al revisar Grabar en el cuadro Set (Conjunto) e introdujimos el nombre del conjunto.
Entonces desarrollamos una expresión AINT ((TNOW/60)+1) que daría un valor integral que
234 Capítulo 5
Name (Nombre) Record Rejected Call for Current Hour Period (Grabar
llamada rechazada para el periodo de hora actual)
Type (Tipo) Count (Contar)
Value (Valor) 1
Record into Set (Grabar dentro del Check (Checar)
conjunto)
Counter Set Name (Nombre del conjunto Rejected Calls (Llamadas rechazadas)
de contador)
Set Index (Índice del conjunto) AINT((TNOW/60)+1)
-JCFSBDJÓOEFMÎOFB
QBSBMBJOWFTUJHBDJÓO
"VNFOUBSMB
%FNPSB WBSJBCMF8*1
FOMPTSFHJTUSPTEF
MBPGJDJOB EFEFWPMVDJÓO
0USP %JTNJOVJSMB
5PNBSBHFOUF -MBNBEB -JCFSBSBHFOUF
WBSJBCMF8*1EF
y*OWFTUJHBDJÓOFO 5JQPEFQSPEVDUP5FDI$ UFDOPMÓHJDPUJQP SFHSFTBEBUJQP UFDOPMÓHJDPUJQP MMBNBEBUÊDOJDB
MBPGJDJOBEFBQPZP 5JQPEFQSPEVDUP5FDI$ EFWVFMUB
ZEFWPMVDJPOEF 7FSEBEFSP
MMBNBEB
5PNBSBHFOUF -MBNBEB -JCFSBSBHFOUF
'BMTP UFDOPMÓHJDPUJQP SFHSFTBEBUJQP UFDOPMÓHJDPUJQP
índice del recurso colocado en Save Attribute (Guardar atributo) Tech Agent Index (Índice
de agente técnico) porque necesitaremos saber qué persona tomó la llamada si se requiere
una futura investigación y devolución de la llamada. Esto completa los cambios a esta sección de
nuestro modelo, pero siempre que tratemos con llamadas de soporte técnico, desarrollaremos una
nueva sección para nuestro modelo para manejar las llamadas técnicas que se devuelven.
La lógica para esta sección se muestra aquí y los módulos de diagrama de flujo aparecen en
la figura 5-17:
If customer call requieres further investigation (Si la llamada del cliente
requiere investigación adicional)
Release trunk line resource (Liberar el recurso de la línea troncal)
Delay for back office research (Demorar para investigación en la oficina de apoyo)
Increment Tech Return WIP variable (Aumentar la variable WIP de llamada técnica
devuelta)
Determine product type and direct (Determinar el tipo de producto y canalizar)
Seize technical support resource (Tomar el recurso de soporte técnico)
Seize trunk line resource (Tomar el recurso de línea troncal)
Delay for return-call service (Demorar para el servicio de llamada devuelta)
Release trunk line resource (Liberar recurso de línea troncal)
Release technical support resource (Liberar recurso de soporte técnico)
Decrement Tech Return WIP variable (Disminuir la variable WIP de llamada técnica
devuelta)
Send to system exit (Enviar a la salida del sistema)
La entidad de llamada técnica completa se envía al módulo Decide (Decidir) que se llama
“Backoffice Research and Return Call?” (“¿Investigación en la oficina de
apoyo y devolver llamada?”) en donde 96% de las llamadas se consideran completas (mon-
tamos esto como la ramificación Falsa) y están dirigidas a la misma salida del sistema que usamos
en el modelo 5-1. El 4% restante (la ramificación Verdadera) se envía al módulo Release (Liberar)
en donde se libera la línea principal puesto que la llamada ahora está fuera de línea. El siguiente
módulo Delay (Demorar) retiene a la entidad durante EXPO(60) minutos, que es el tiempo que se
requiere para una investigación adicional, conducida por recursos no definidos fuera de los límites
de nuestro modelo (a cualquiera que haga cola afuera se le empuja al tiempo EXPO[60]). Si una
llamada entra a esta demora hacia el final de un día y no se le puede terminar, se le aplazaría, en la
236 Capítulo 5
realidad, para el siguiente día. Puesto que nuestro modelo se ejecuta sólo por un día, tales llamadas
simplemente no se terminan dentro de la ejecución. También definimos e introdujimos la Storage
ID (Identificación de Almacenamiento) Backoffice Research Storage (Almacena-
miento de investigación en la oficina de apoyo) de manera que pudiéramos
mostrar estas entidades en nuestra animación. Después de la demora, se envía la entidad al módulo
Assign (Asignar), en donde aumentamos la variable arreglada en una dimensión Tech Return
WIP al usar el valor del atributo Tech Call Type como el índice. Se puede definir esta variable
en el módulo Assign (Asignar), pero primero hay que abrir el módulo de datos Variable y meter
un valor de 3 en la celda de Rows (Filas), lo que define el tamaño del arreglo. Después detecta-
mos el tipo de producto con una prueba de N-way by Condition (N-vías por probabilidad) en el
módulo Decide (Decidir) “Product Type?” (“¿Tipo de producto?”) y dirigimos la
llamada devuelta a la ramificación correcta.
La entidad de devolución de llamada debe tomar tanto la línea principal (las llamadas que salen
necesitan una línea principal así como las entrantes) y la persona de soporte técnico apropiada, que
tiene que ser la que atendió la llamada entrante original. Describiremos cosas para el Tipo (Type)
de producto 1; los otros dos son similares. En el siguiente módulo Seize (Tomar), la devolución de la
llamada de soporte técnico para el Tipo de producto 1 toma del conjunto de recursos apropiado de
personas de soporte técnico. Es posible hacer cola y usamos una (así como animación) por separa-
do para ello, además de que especificamos la prioridad de la Toma como Alta (1), conforme toman
prioridad las llamadas devueltas que salen sobre las entrantes. Aquí tomamos sólo al empleado de
soporte técnico y no la línea principal (haremos eso en el módulo siguiente). Como esta llamada
devuelta debe ir a la misma persona de soporte técnico que tomó la llamada original del cliente,
usamos la regla de selección de Specific Member (Miembro específico) y especificamos el atributo
Tech Agent Index en el campo Set Index (Índice de conjunto) para asegurar esto.
Ya habiendo tomado el agente correcto Tech 1, la devolución de la llamada Tech 1 ahora toma
una línea troncal en el siguiente módulo Process (Proceso), con una prioridad Alta sobre las lla-
madas entrantes con una prioridad media. La demora del proceso se basa en la expresión Return
Tech Time (Tiempo de llmada técnica devuelta) y cuando se completa, se libera la
línea principal. En este módulo se podría hacer cola si no hay ninguna línea disponible de forma
inmediata. Durante ese tiempo, la animación aún es adecuada puesto que la imagen de la entidad
se muestra en el área de toma de la animación del recurso, así que no hay animación de cola por
separado para esto. Cuando se completa la llamada, se libera la persona específica de soporte
técnico en el siguiente módulo Release (Liberar).
En nuestro primer intento al desarrollar esta sección, se utilizó un solo módulo Process (Proce-
so) con una alta prioridad para tomar al mismo tiempo tanto la persona de soporte técnico como
la línea principal. Al ejecutar nuestra simulación y observar la animación, nos dimos cuenta que
esas llamadas devueltas estuvieron esperando mucho tiempo antes de ser procesadas. Eso hace
que cuando se toma este enfoque de modelación ambos recursos deben hallarse disponibles al
mismo tiempo para que proceda la entidad. Si sólo se encuentra disponible uno de los recursos
especificados y el sistema está ocupado, con probabilidad será destinado a otra entidad en espera.
Puesto que tales llamadas devueltas tienen una prioridad alta, decidimos tomar los recursos de
forma separada. Nos dimos cuenta que en el sistema real la llamada devuelta con probabilidad se
le daría a una persona de soporte técnico en específico, quien intentaría devolver la llamada tan
pronto como se encuentre disponible. Por supuesto que al hacer esto, el empleado debería primero
tomar una línea principal disponible. Así que modificamos la lógica del modelo al separar las dos
acciones de toma como se describió con anterioridad.
Modelado de operaciones detalladas 237
Una vez completada la llamada de devolución, la entidad entra en un módulo Assign (Asig-
nar) en donde disminuye la variable arreglada Tech Return WIP. La llamada completa
ahora está lista para ser enviada a la salida del sistema. En cualquier otro caso en el que una
llamada completa se envíe a la salida del sistema, aún tiene el recurso de línea principal, así
que el primer módulo fue el de Release para liberar ese recurso. Estas entidades ya liberaron el
recurso de línea principal, así que necesitamos enviar las entidades al módulo Record (Grabar)
que sigue al módulo Release (Liberar).
Si el lector se fija en el módulo Statistic (Estadística) de datos (en panel de Advanced Pro-
cess [procesos avanzados]), verá las diez entradas tipo contador que describimos antes. También
montamos cuatro estadísticas de tipo persistente en el tiempo para solicitar resultados (promedio
de tiempo, mínimo y máximo) en el número total de llamadas de investigación de la oficina de
apoyo para una devolución de llamada (variable de rastreo NSTO [Backoffice Research
Storage]) y para los números totales de cada tipo de producto del soporte técnico en el sistema
(expresiones de rastreo Tech 1 Total Online WIP, Tech 2 Total Online WIP y
Tech 3 Total Online WIP).
Nuestro nuevo modelo no necesita cambio alguno en las llamadas de ventas o en las de
estado del pedido del modelo 5-1, así que no se requieren más cambios.
Ahora revisemos las modificaciones a nuestra animación. Los tres Almacenamientos anima-
dos para las demoras de grabación, la gráfica de líneas principales ocupadas, la variable para las
ventas WIP y las colas para las llamadas que esperan soporte técnico y ventas permanecen igua-
les. Primero borramos los recursos Tech 1, Tech 2 y Tech 3 de nuestra animación. Después cam-
biamos los nombres de las variables de las tres muestras WIP para que correspondan a nuestro
nuevo modelo. Por ejemplo, cambiamos la variable WIP para el Tipo de producto 1 de Process
Product Type 1 Tech Call.WIP a Tech 1 Total Online WIP, que es una expresión
que definimos en el módulo de datos Expression (Expresión) para que sea Process Product
Type 1 Tech Call.WIP+Tech Return WIP (1) así que, todas las veces, es el número total o
llamadas técnicas para el Tipo de producto 1 que están “abiertas”, ya sea como llamada entrante
o en la oficina de apoyo para una llamada de devolución. También volvimos a arreglar nuestra
nueva animación para permitir una en el área de Investigación de la oficina de apoyo y añadi-
mos una variable WIP, NSTO (Backoffice Research Storage); NSTO es una función
ya incluida en Arena que regresa el número de entidades en el Almacenamiento dado en este
argumento.
También añadimos tres nuevas colas al área de soporte técnico para mostrar las llamadas
de devolución que esperan servicio. Esta cola para el área Tech 1 es Seize Tech Agent
Type 1.Queue. Luego añadimos una animación de almacenamiento para mostrar las lla-
madas de devolución que teníamos bajo investigación para la nueva área de investigación en la
oficina de apoyo, Backoffice Research Storage.
El cambio final fue añadir los recursos para nuestro nuevo personal de soporte técnico.
Nosotros seleccionamos a Charity de la lista de recursos y abrimos la biblioteca de imágenes
de oficina de Arena, Office.plb. Ahí encontramos una imagen de un personaje sentado en
su escritorio con un teléfono desocupado y una segunda imagen con el personaje hablando por
teléfono. Copiamos la primera imagen para representar nuestra imagen Desocupado y la segun-
da para que fuera la imagen Ocupado. Para nuestro estado Inactivo, alteramos la primera ima-
gen para quitar al personaje de forma que estuviera el escritorio desatendido. Entonces cerra-
mos la ventana y colocamos nuestro recurso. Después de tomar nuestro recurso, usamos la op-
ción Text (Texto) para etiquetarlo. Luego hicimos una copia de estos dos objetos y cambiamos
238 Capítulo 5
los identificadores para representar a Noah. Repetimos esto para Tierney, pero cambiamos el
color de la camisa en las imágenes Desocupado y Ocupado. Nuestro plan era usar diferentes
colores de camisa para representar diferentes capacidades del personal de soporte.
La simulación animada final es similar a la figura 5-18, que se tomó en un tiempo aproxi-
mado de 340.7. En el Category Overview report (Reporte general de categorías), vemos de los
Contadores de la sección especificados por el usuario que la mayoría de las llamadas rejected
(rechazadas) suceden en las horas 5-8 (que corresponden de mediodía a las 4:00 p.m.), así que
éste debe ser un periodo de tiempo para mirar con atención al personal (aunque sólo hicimos
una réplica aquí, tal conclusión es sospechosa estadísticamente); retomaremos esto en una for-
ma más organizada y estadísticamente confiable en el capítulo 6.
5.6 M
odelo 5-3: el centro de llamadas mejorado con más medidas
del desempeño de la salida
Mientras que el modelo 5-2 produce más que suficientes medidas del rendimiento de la salida, no
arroja una cifra económica total de mérito con la que pudiéramos hacer comparaciones de forma
fácil entre las diferentes configuraciones. Muchos de los estudios de simulación se enfocan en una
reducción del costo (o, de forma ideal, una minimización del costo), así que crearemos una medida
de costo global como la salida principal. Al mismo tiempo, añadiremos algunas opciones al mode-
lo para establecer el Almacenamiento para una comparación de alternativas y para una búsqueda
óptima en el capítulo 6. Para obtener una mejor precisión estadística, también haremos cinco
réplicas, que representen una semana de trabajo, y nos enfocaremos en los costos semanales.
Existen dos áreas básicas en las que aparecen los costos: 1) costos de personal y recursos,
que son bastante tangibles y fácilmente medibles y 2) costos debido a un mal servicio al cliente,
que son menos tangibles y pueden ser difíciles de cuantificar. Consideraremos estas dos clases
de costos en forma separada.
Primero, miremos los costos de personal y recursos, algunos de los cuales se definieron en el
modelo 5-2 pero no se usaron. En el módulo Resource (Recurso) del modelo 5-2, definimos un cos-
to de 20 dólares la hora para el personal de ventas y entre 18 y 22 dólares la hora para el personal
de soporte técnico, dependiendo de su nivel de capacitación y flexibilidad; estos costos aparecieron
dondequiera que el personal estuviera presente de acuerdo con sus horarios, sin importar si estuvie-
ron ocupados o no. Al usar la información del personal descrita en la sección 5.5 (y definida en el
módulo de datos Schedule [Programa] del modelo 5-2), el costo semanal por el personal actual es:
Modelado de operaciones detalladas 239
Pantalla 5-34. El diálogo Sales Schedule (Programa de ventas) cambiado del modelo 5-3
240 Capítulo 5
Para añadir fácilmente un número variable controlado de personal de ventas, definimos que
una variable New Sales (Ventas nuevas) sea el número de personal de ventas adicional
que contratamos para este periodo de cuatro horas cada día, a un costo de 17 dólares la hora.
Así, cada persona adicional del personal de ventas trabajará 20 horas a la semana, por lo que el
costo adicional es de 17 dólares la hora × 20 horas a la semana = 340 dólares por semana para
cada uno de los nuevos miembros del personal de ventas. Para colocar al nuevo personal de ventas
en el modelo, editamos la línea Sales Schedule (Programa de ventas) en el módulo
de datos Schedule (Programa). Puesto que usaremos una variable (New Sales) (Ventas
nuevas) como parte del programa, no podemos usar el Graphical Schedule Editor (Editor grá-
fico de programas de eventos) y debemos acceder a este programa a través de su diálogo (u hoja
de datos); con un clic en el botón derecho en la línea Programa de ventas y después con la
selección Edit (Editar) a través de Dialog (Diálogo). La pantalla 5-34 ilustra en dónde se hacen
las ediciones. Por supuesto, si fijáramos New Sales en 0, tendríamos la misma configuración de
personal de ventas como en el modelo base.
Seguimos una estrategia similar para añadir personas de soporte técnico durante este periodo
de 12:00 p.m. a 4:00 p.m. Definimos que las nuevas variables, New Tech 1, New Tech 2 y New
Tech 3 sean el número de personal adicional de soporte técnico añadido que está calificado en
los tipos de producto 1, 2 o 3, respectivamente y que New Tech All sea el número de personas
de soporte técnico añadidas que están calificadas en los tres tipos de producto. Naturalmente,
los nuevos técnicos del tipo 1 se llaman todos Larry, los nuevos técnicos del tipo 2 llevan todos
el nombre de Moe, todos los nuevos técnicos del tipo 3 se llaman Curly y los nuevos técnicos de
todo tipo se llaman en su totalidad Hermann. Se añadieron cuatro nuevas entradas en el módulo
de datos Recurso (Resource) para crear estos recursos y definir las razones por hora para ellos (16
dólares para cada Larry, Moe y Curly y 18 dólares para cada Hermann). Para expresar sus capa-
cidades, añadimos a Larry al conjunto Product 1 en el módulo Set (Conjunto), a Moe al con-
Pantalla 5-35. El diálogo Larry Schedule (Programa de Larry) del modelo 5-3
Modelado de operaciones detalladas 241
Pantalla 5-36. La expresión New Res Cost (nuevo costo del recurso) del modelo 5-3
junto Product 2, a Curly al conjunto Product 3 y a Hermann a los tres de estos conjuntos.
Creamos las entradas de programa para estos cuatro nuevos recursos. El programa de Larry está
en la pantalla 5-35 y los otros tres son iguales; como el programa de ventas, éstos se pueden editar
sólo a través del diálogo (u hoja de datos) y no por el Graphical Schedule Editor (Editor gráfico
de programas de eventos) ya que involucran variables. Como para los costos, incurrimos en 16 ×
4 × 5 = 320 dólares por semana para cada Larry, Moe y Curly y 17 × 4 × 5 = 360 dólares por
semana para cada Hermann.
La última forma de alterar la mezcla del recurso es considerar cambiar el número de líneas
troncales, que con anterioridad supusimos que se fijara en 26. El recurso Trunk Line (Lí-
nea troncal) se define en el módulo Resource (Recurso) como un sencillo Fixed Capacity
resource (Recurso de capacidad fija), así que sólo alteraremos la entrada ahí si queremos cam-
biar el número de líneas principales. Para construir un costo dentro, incurrimos en unos rotun-
dos 98 dólares por semana para cada línea principal, un trato que incluye todos los usos locales
y de larga distancia de esa línea.
Para reunir todos los costos de recursos anteriores, definimos una Expresión llamada New
Res Cost (Nuevo costo del recurso). La pantalla 5-36 muestra la entrada para ella en el
módulo de datos Expression. Todo lo involucrado en esta Expression se analizó antes, con excep-
ción de MR (Trunk Line) (MR [Línea troncal]), que usa la función MR incluida en
Arena para dar el número de unidades del Resource en el argumento, en este caso, Trunk Line
(Línea troncal). Note que esta expresión no depende de lo que suceda durante la simulación
y sólo se usa al final del módulo Statistic (Estadística) para ayudar a producir las medidas finales
de rendimiento de la salida.
Ahora vayamos a la otra categoría de costos del sistema, aquellos en los que se incurre
al hacer esperar a los clientes. Claramente, éstos se intercambian en contra del recurso y los
costos del personal; podemos usar nuestro modelo para explorar tal intercambio y quizá hasta
intentar optimizarlo. En la práctica, este tipo de costos de insatisfacción del cliente son difíciles
de cuantificar, así que habremos de confiar en las encuestas a clientes y técnicas como análi-
sis de regresión para acercarnos a los números.
Suponemos que la mayoría de las personas están ahora lo suficientemente endurecidas para
soportar algún tiempo de espera cuando tratan con un centro de llamadas, pero en algún punto,
los usuarios comenzarán a enfadarse y el sistema iniciará a incurrir en un costo. Para cada lla-
mada técnica, este punto es de 3 minutos; para las llamadas de ventas, es de 1 minuto y para las
llamadas de estado del pedido, es de 2 minutos. Más allá de este punto de tolerancia para cada
tipo de llamada, el sistema incurrirá en un costo de 36.8 centavos por minuto para las llamadas
técnicas, 81.8 centavos por minuto para las llamadas de ventas y 34.6 centavos por minuto para
las llamadas de estado del pedido que continúen en espera. Para cada tipo de llamada, acumu-
lamos en una variable el “exceso” de tiempos de espera en la cola (esto es, el tiempo de espera
242 Capítulo 5
Name (Nombre) Assign Excess Tech Wait Time (Asignar exceso de tiempo de
espera técnica)
Assignments (Tareas)
Type (Tipo) Variable (Variable)
Variable Name (Nombre de Excess Tech Wait Time (Exceso de tiempo de espera
la variable) técnica)
New Value (Nuevo valor) Excess Tech Wait Time + MAX(ENTITY.WAITTIME – 3,0)
Pantalla 5-37. El nuevo módulo Assign (Asignar) para acumular excesos de tiempos de
espera técnica para el modelo 5-3
en la cola más allá del corte de tolerancia) de todas las llamadas completas a través de un nuevo
módulo Assign (Asignar) por el que pasan las entidades después de que se hicieron sus llamadas.
La pantalla 5-37 indica este nuevo módulo Assign para las llamadas de soporte técnico y los
otros dos son iguales (ponemos cuadros color naranja brillante detrás de estos nuevos módulos
Asignar de forma que pueda reconocerlos rápido en el modelo). Note que ENTITY. WAITTI-
ME es un atributo ya incluido en Arena que acumula de forma automática el total de todos los
tiempos en la cola para una entidad a medida que ésta avanza, así como cualquier otro tiempo
de demora que se encuentre colocado en “Espera”. En nuestro modelo, no existen tales coloca-
ciones de demora ni otras demoras de cola con flujo ascendente más que las que esperan a que
se conteste la llamada, así que este valor sí contiene lo que queremos en este caso. (El cálculo de
ENTITY.WAITTIME sucede sólo si el cuadro Cost se encuentra marcado en el diálogo Ejecutar
> Configuración > Parámetros del proyecto, así que hay que asegurarse de que sí lo esté.) Al final
de la simulación, la variable Excess Tech Wait Time será el número total de minutos más
allá de los 3 minutos de tolerancia que las llamadas técnicas completadas soportaron durante la
ejecución de un solo día y, por encima de las cinco réplicas, éstas se promediarán para producir,
en el resultado final, un promedio diario del exceso de tiempo de espera técnica. Si multiplicamos
esto por el costo por minuto de 36.8 centavos, obtendríamos el costo por el exceso en el tiempo
de espera técnica por un día, pero estamos calculando el costo de las cosas en una base semanal,
así que necesitamos multiplicar esto por 36.8 centavos × 5 = 1.84 dólares para obtener el costo
semanal. Los costos para los otros dos tipos de llamadas se calculan de forma similar (los facto-
res por los cuales hay que multiplicar el exceso en los tiempos de espera para obtener los costos
semanales son 81.8 centavos × 5 = 4.09 dólares, para las llamadas de ventas, y 34.6 centavos × 5
= 1.73 dólares, para las llamadas de estado del pedido). Aunque estamos haciendo cinco réplicas
de un día, que podrían considerarse como una semana de trabajo, el modelo construido de esta
manera producirá estimados de costo semanales sin importar el número de réplicas hechas (usa-
remos este modelo en el capítulo 6 con muchas más de cinco réplicas, para mejorar la precisión
del resultado).
Reunir todos estos costos en una sola medida de costo total es bastante sencillo. Dados
todos los análisis y configuraciones anteriores, la medida de rendimiento de la salida global
Total Cost (Costo total) es:
New Res Cost (Nuevo costo del recurso)
+ Excess Sales Wait Time*4.09 (+ Exceso en el tiempo de espera de ventas *4.09)
+ Excess Status Wait Time*1.73 (+ Exceso en el tiempo de espera del estado *1.73)
+ Excess Tech Wait Time*1.84 (+ Exceso en el tiempo de espera técnica *1.84)
+ 12820,
Modelado de operaciones detalladas 243
que introducimos en el módulo de datos Statistic (Estadística) (en el Panel Advanced Process);
el tipo de esta Statistic se elige que sea Output, que significa que es una cantidad que se calcula
sólo al final de la simulación y sólo queremos ver su valor en los reportes. Puesto que estamos
definiendo este resultado nosotros mismos, más que dejar que lo calcule Arena de forma in-
terna, aparecerá bajo User Specified (Especificado por el usuario) → Output (Resultado) en el
Category Overview Report.
En este punto, probablemente se pregunte por aquellas pobres almas desafortunadas que
llamaron sólo para ser ignoradas inmediatamente por una señal de ocupado. Ellas ni siquiera
tuvieron la oportunidad de enfurecerse después de su tiempo de tolerancia en espera y comen-
zar a cargar un costo en contra del sistema (aun cuando ellos estuvieron realmente enojados).
Podríamos haber estimado un costo (grande) por cada tono de ocupado y construirlo en nuestra
estructura de costo, pero en su lugar decidimos sólo calcular el porcentaje de llamadas entran-
tes que reciben un tono de ocupado y producirlo como un resultado por separado. En lugar de
ver esto como parte del objetivo de medición del rendimiento del modelo, lo veremos después
como un requisito (parecido a una restricción, excepto que radica en el resultado más que en la
entrada) de que no más de 5% de las llamadas entrantes reciban un tono de ocupado; cualquier
configuración de modelo que no satisfaga este requisito se le considerará como inaceptable sin
importar qué tan bajo pudiera ser su resultado de Total Cost.
Para calcular el porcentaje de llamadas entrantes que obtienen tonos de ocupado, necesitamos
saber el número total de llamadas intentadas que son rechazadas. Ya tenemos un módulo Grabar
que cuenta el número de llamadas intentadas (el contador Attempted Calls [Llamadas
intentadas]). También contamos el número de llamadas rechazadas, pero en la actualidad gra-
bamos estas últimas con base en una persona por hora. Podríamos sólo sumar los valores de estos
diez contadores, pero tomamos la salida fácil y añadimos otro módulo Record en la sección de lle-
gadas de llamadas de la lógica del modelo (con un cuadro de color naranja brillante detrás) que nos
dará el total (contador Total Rejected Calls [Total de llamadas rechazadas]).
Para calcular el valor de salida Percent Rejected (Porcentaje de rechazadas), aña-
dimos una línea al módulo Statistic con el nombre y la expresión 100*NC (Total Rejected
Calls) / NC (Attempted Calls)[Total de llamadas intentadas]; NC es la función
ya incluida en Arena que regresa el valor del contador llamado en su argumento.
Debido a que solicitamos réplicas múltiples (cinco), necesitamos decirle a Arena qué hacer
entre ellas. Existen cuatro posibles opciones:
Opción 1: Iniciar el sistema (sí), Iniciar Statistics (sí)
Esto dará como resultado cinco réplicas y reportes estadísticamente independientes e idénti-
cos, cada uno comenzando con un sistema vacío en el tiempo 0 ejecutándose hasta por 660
minutos. El generador de número aleatorio (véase la sección 12.1) sólo se mantiene en proceso
entre las réplicas, haciéndolas independientes e idénticamente distribuidas (IID). Se perderán
las posibles llamadas devueltas de soporte técnico que se aplazan para el siguiente día.
Opción 2: Iniciar el sistema (sí), Iniciar Statistics (no)
Esto dará como resultado cinco réplicas independientes, cada una comenzando con un siste-
ma vacío en el tiempo 0 y ejecutándose hasta por 660 minutos, con los reportes siendo acu-
mulados. Así, el Reporte 2 incluiría las estadísticas para las dos primeras réplicas, el Reporte 3
contendría las estadísticas para las primeras tres réplicas, etc. El generador de número aleato-
rio se comporta como en la opción 1.
244 Capítulo 5
varios escenarios diferentes, o cuál sería el mejor escenario de todos. Éstos son exactamente los
temas que retomaremos en el capítulo 6 y usaremos el modelo 5-3 para ver dentro de ellos.
3
Como lo señaló el difunto Carl M. Harris, “hacer cola (queueing)” evidentemente es la única palabra en inglés con
cinco o más vocales consecutivas; véase Gass y Gross (2000).
246 Capítulo 5
Sin embargo, un pedido colocado al inicio de un día no llega de forma instantánea, sino
más bien a veces durante la última mitad de ese día, después
de una demora de reparto (a.k.a.
tiempo de entrega) distribuido uniformemente entre 0.5 y 1 día. Así que cuando llega el pedido,
el nivel de inventario aparece en una cantidad igual a la del pedido original pero, si hubo alguna
demanda desde que se colocó el pedido, éste aparecerá en algo menor que S cuando el pedido
finalmente se entregue. Note que los tiempos relativos a las evaluaciones del inventario y a las
demoras de reparto son tales que nunca debe haber más de un pedido en camino, puesto que un
pedido colocado al inicio del día llegará, por mucho, justo antes de que el día termine, lo que
es el inicio del día siguiente, la primera oportunidad para colocar otro pedido; véase el ejercicio
5-18 para implicaciones de modelado de esta situación numérica en particular.
Bucky está interesado en el costo de operación total promedio por día de este sistema duran-
te 120 días, lo que será la suma de tres componentes:
< Costo de pedido promedio por día: Cada vez que se coloca un pedido, se incurre en un costo
de 32 dólares sin importar la cantidad del pedido, más 3 dólares por artículo pedido; si no
se coloca ningún pedido no hay costo por el mismo, ni siquiera el costo fijo de 32 dólares.
Los 3 dólares no es el precio (al mayoreo) del trasto, sino más bien el costo operacional
administrativo de Bucky de pedir un trasto (no estamos considerando ningún precio en
este modelo). Al final de la simulación de 120 días, el total acumulado de todos los costos
de los pedidos se divide entre 120 para obtener el costo promedio de pedido por día.
< Costo por mantener promedio por día: Siempre que haya artículos físicamente en inventa-
rio (esto es, I(t) > 0), se incurre en un costo por mantenerlos de 1 dólar por trasto cada
día. Entonces, el costo total de mantenerlos es
120
∫0
1 × máx (I(t), 0)dt
(piense en ello) y el costo promedio por mantenerlos cada día es este total dividido entre
la duración de la simulación, 120 días.
< Costo por faltante promedio por día: Siempre que tengamos un retraso (esto es, I(t) < 0),
se incurrirá en un costo por faltante de 5 dólares por trasto, un castigo más severo que
por mantener el inventario en positivo. El costo por faltante total es por lo tanto:
120
(piense en ello un poco más) y el costo por faltante promedio por día es este total dividido
entre la duración de la simulación.
Note que para los periodos en los que no tenemos ni retraso ni artículos físicamente en
inventario (esto es, I(t) = 0) no hay ni costos por faltante ni por mantenerlos (nirvana de conta-
bilidad de costos). También, puede percatarse que no estamos contabilizando en ningún lado el
precio al mayoreo o al menudeo de los trastos; en este modelo, suponemos que esos precios son
fijos e inducen esta demanda, lo que sucederá a toda costa, de tal forma que los ingresos y las
ganancias son fijos y es sólo el costo de operación lo que podemos intentar afectar.
Un punto final antes de construir nuestra (bastante sencilla) simulación. Las evaluaciones
de inventario suceden al inicio de cada día, esto es, cuando el reloj es un entero y cualquier costo
Modelado de operaciones detalladas 247
Modelo 5-4 de
inventario (s, S ) con
retraso
de pedido incurre en ese tiempo. Sucede que se supone que la ejecución termine al final de un
tiempo entero (120), así que normalmente habría ahí entonces una evaluación de inventario y,
posiblemente, un pedido colocado que no llegaría sino hasta después del fin del mundo, así que
nunca lo obtendríamos pero deberíamos pagar el costo de pedido. Así que se tiene que evitar
que suceda una evaluación en el tiempo 120, lo que haremos al detener de hecho la ejecución en
el tiempo 119.9999 (una versión lenta por nuestra parte, pero le pediremos que limpie lo sucio
en el ejercicio 5-19).
inicio para una variable, se predetermina en cero. Lo dejaremos explorar por su propia cuenta
por las entradas en este módulo, que se definen como sigue:
ntory Level (Nivel de inventario): en cualquier momento de la simu-
Inve
lación, éste es el nivel de inventario (positivo, cero o negativo) y aquí se inicia en 60.
Tal variable es la función I(t).
Little s (s minúscula): ésta es s, iniciada en 20.
Big S (S mayúscula): ésta es S, iniciada en 40.
l Ordering Cost (Costo de pedido total): una variable de acumula-
Tota
dor estadístico a la que se suman todos los costos de pedido; no se inicia (así que
implícitamente comienza en el tiempo 0).
Setup Cost (Costo de configuración): el costo fijo por pedir, iniciado
en 32.
emental Cost (Costo gradual): la variable costo (por trasto) por recibir
Incr
el pedido, iniciada en 3.
Unit Holding Cost (Costo por mantener la unidad): el costo por man
tener un trasto en el inventario por un día, iniciado en 1.
Unit Sho rtage Cost (Costo de faltante de la unidad): el costo por tener un
trasto en retraso por un día, iniciado en 5.
Days to R un (Días a ejecutarse): la duración de la simulación (en días), iniciada
en 119.9999 por nuestra versión, como se describió antes.
Definimos cuatro Expressions (Expresiones) a través del elemento Expressions, en la figura
5-21 con una entrada visible para Demand Size (Tamaño de la demanda). Estas expresio-
nes definen las distribuciones de probabilidad para las cantidades indicadas por sus nombres y
deberían explicarse ellas mismas cuando se observan detalladamente. Decidimos definir Eva-
Modelado de operaciones detalladas 249
luation Interval (Intervalo de evaluación) como una Expression más que como
una variable, aun cuando es sólo una constante (1), por razones de generalidad de modelación
si deseáramos intentar alguna clase de intervalo de evaluación aleatorio en el futuro (pero,
como se ve en el ejercicio 6-12, también hay una ventaja para definirlo como Variable.
El elemento Attributes (Atributos) sólo tiene una entrada, que se usa para declarar Or-
der Quantity (Cantidad del pedido) como un atributo a añadirse a las entidades.
El elemento Entities (Entidades) declara los dos tipos de entidades que usaremos, Customer
(Cliente) e Inventory Evaluator (Evaluador de inventario). El elemento
Project (Proyecto) permite especificar un Title (Título), Analyst Name (Nombre del analista)
y otra documentación, así como controlar algo de los reportes, de forma similar a la opción
Run > Setup > Project Parameters (Ejecutar > Configuración >Parámetros del proyecto) que
usamos antes. No hay mucho que ver en estos módulos, así que nos brincaremos las figuras y le
dejaremos verlos por su cuenta.
El elemento Replicate (Replicar), que se muestra en la figura 5-22, básicamente repite lo que
está disponible a través de Run > Setup > Project Parameters (Ejecutar > Configuración >Pará-
metros del proyecto). Sólo tenemos dos entradas no predeterminadas. Primero, cambiamos Base
Time Units (Unidades de tiempo base) a Days (Días), ya que todas las medidas de tiempo de
entrada están en días y los bloques del panel Blocks (Bloques) no tienen suministro para especi-
ficar unidades de tiempo de entrada, suponiendo que se encuentran todos en Base Time Units
(Unidades de tiempo base). Segundo, especificamos que Replication Length (Duración de la ré-
plica) sea Days to Run (Días a ejecutarse), la variable que iniciamos en 119.9999,
nuestra versión barata para evitar la inútil evaluación de inventario en el tiempo 120.
El elemento DStats, en la figura 5-23 con la entrada Holding Cost (Costo de man-
tener) visible, hace lo mismo que las entradas del módulo Statistic (Estadística) de Time-Per-
sistent (Persistencia al tiempo), en este caso, decir que queremos acumular valores persistentes
en el tiempo para los costos de mantener y escasez. La Expression SIMAN parcialmente escon-
dida en la figura 5-23 es
Figura 5-25. El Create Block (Bloque crear) para las llegadas de los clientes
do-costo del costo total promedio, lo que puede ser interesante en sí mismo). Y la función de
Arena DAVG regresa el promedio de persistencia al tiempo de este argumento (así que se usa
dos veces en los reportes).
Ahora regresemos a los módulos lógicos del panel Blocks, que se llaman bloques. El grupo
alto de bloques en la figura 5-19 representa a los clientes que llegan, que hacen demandas en
contra del inventario y se van.
Figura 5-26. Assign Block (Bloque asignar) para las demandas de los clientes contra el inventario
Modelado de operaciones detalladas 253
El bloque Create (Crear), que se muestra en la figura 5-25, requirió tres entradas no pre-
determinadas. Tanto para First Creation (Primera creación) como para Interval (Intervalo),
introdujimos Interdemand Time (Tiempo entre demandas), definido en el elemen-
to Expressions como EXPO(0.1). El Entity Type (Tipo de entidad) aquí lo definimos como
Customer (Cliente).
El siguiente bloque Assign (Asignar), en la figura 5-26, disminuye la demanda de los clientes
del Inventory Level (Nivel de inventario). La Expression (Expresión) Demand
Size (Tamaño de la demanda) se definió en el módulo Expressions (Expresiones) como
una variable aleatoria discreta para devolver demandas de 1, 2, 3 o 4 con las probabilidades
apropiadas.
La entidad Customer (Cliente) entonces avanza vía el bloque Dispose (Disponer), en
donde lo único que hicimos fue despejarle el cuadro a Record Entity Statistics [Grabar estadís-
ticas de la entidad] (no nos ocupamos de ellas en este modelo).
El grupo central de bloques en la figura 5-19 representa la evaluación periódica del inven-
tario y la decisión de hacer el pedido. Si se coloca un pedido, esperamos que llegue y que luego
aumente el nivel de inventario; si no se coloca ningún pedido, no hay nada que hacer.
Esta lógica comienza con un bloque Create (Crear), en la figura 5-27, para insertar dentro del
modelo de lo que se puede considerar como un contador de trastos (no de frijoles) que enumerará
los trastos, decidirá si colocar un pedido, y luego, si se coloca uno, esperará a que sea entregado,
y entonces pondrá los trastos en el estante. Nosotros queremos que First Creation (Primera crea-
ción) esté en el tiempo 0 ya que nuestras llamadas del sistema para una evaluación de inventario
se hallan en el inicio de la ejecución. El Entity Type (Tipo de entidad) es Inventory Evalua-
tor (Evaluador de inventario) y el intervalo de tiempo entre creaciones sucesivas es la
Expression (Expresión) Evaluation Interval (Intervalo de evaluación), que se
especificó para que sea la constante 1 en el elemento Expressions (Expresiones).
Una vez creada, la entidad Inventory Evaluator (Evaluador de inventario)
procede al Branch block (bloque de Sección), en la figura 5-28, que hace parte de las mismas co-
sas que el módulo Decide (Decidir) del panel Basic Process (Proceso Básico), con el que el lector
ya estará familiarizado. En tal caso, queremos decidir si colocar un pedido en este momento.
Primero Añadimos una sección de tipo Si con la condición Inventory Level < Little
s (Nivel de inventario < s pequeña), que, si es cierta, indica que queremos colocar
un pedido ahora (el cuadro de diálogo para esta ramificación aparece en la figura 5-28). La otra
ramificación es del tipo Else (Otro) y es la única otra posibilidad, indicando que ningún pedido se
coloca en este momento. Los puntos de salida del Branch block (bloque de Sección), corresponden
a la realidad de las ramificaciones correspondientes; en este caso, se sigue el primer punto de salida
si vamos a colocar un pedido (y nos dirigimos al Assign block [bloque Asignar] a la derecha del
Branch block [bloque de Sección]) y el segundo punto de salida corresponde a la ramificación Else
(Otro) y significa que no se hará nada (así que la entidad inmediatamente va al Dispose block
[bloque Disponer] a la derecha del Branch block [bloque de Sección]). Una parte importante
del Branch block (bloque de Sección) es el campo Max Number of Branches (Número máximo
de secciones), que predetermina al infinito (y que, en su lugar, configuramos en 1); en general,
el Branch block (bloque de Sección) evalúa en secuencia cada ramificación de la lista, y envía
fuera a la entidad entrante (o un duplicado de ella) mediante cada ramificación que evalúa una
True (Verdad), hasta que se use el Max Number of Branches (Número máximo de secciones).
Ésta es una capacidad poderosa pero que puede conducir a errores si las entradas en el bloque
no se hacen y se coordinan con cuidado.
Si necesitamos colocar un pedido, la entidad Inventory Evaluator (Evaluador
de inventario) va a continuación al siguiente bloque Assign (Asignar), visto en la figura
5-29, que primero calcula la Order Quantity [Cantidad de orden] (un atributo que se
adjunta a la entidad) como Big S – Inventory Level. La siguiente tarea de este bloque
incurre el costo por hacer el pedido para tal orden al reemplazar la variable Total Ordering
Cost (Costo total por hacer el pedido) por esta expresión
Modelado de operaciones detalladas 255
de entrega) (tenga en cuenta que las Base Time Units [Unidades de tiempo base] sólo están
disponibles en los bloques). Recuerde que Delivery Lag (Retraso de entrega) se
definió en el elemento Expressions (Expresiones) como UNIF(0.5, 1.0).
Después del retraso de entrega, el Inventory Evaluator (Evaluador de inventa-
rio) va al siguiente bloque asignar, en la figura 5-31, donde aumenta el Inventory Level
(Nivel de inventario) por su atributo Order Quantity (Cantidad de orden).
Después de que se entrega el pedido, está hecho el trabajo del Inventory Evaluator
(Evaluador de inventario), así que va al bloque final Dispose (Disponer) (pero no se
ponga triste, porque pronto se creará otra de estas entidades).
Ahora añadamos una pequeña animación (sólo una pequeña). En la figura 5-32 se muestra
nuestro cuadro de diálogo Plot (Gráfica), que grafica el Inventory Level (Nivel de
inventario) en el tiempo. Quisiéramos tener colores diferentes dependiendo de si el In-
ventory Level (Nivel de inventario) es positivo (en negro) o negativo (en rojo),
lo que lograremos al graficar dos curvas separadas. Para mostrar los niveles de inventario po-
sitivos, graficaremos la expresión MX(Inventory Level, 0) en negro, y para niveles de
inventario negativos, graficaremos MN(Inventory Level, 0), que serán valores negativos,
en rojo (MN es una función propia de Arena para regresar el mínimo de sus argumentos). No
te que cuando “gana” 0 en cualquiera de estas gráficas, obtendremos una línea plana en cero, lo
que probablemente no sea tan malo ya que visualmente delinea dónde se encuentra el cero (en
una moda divertida y multicolor).
También debe ser divertido ver de alguna forma el inventario por sí mismo (no, no vamos a
animar contenedores de pequeños trastos o fantasmas de ellos). Para eso, instalamos un par de
animaciones Level (Nivel) (a veces llamadas animaciones de termómetro) justo a la izquierda de
la gráfica. La animación de arriba (la negra, que se presenta en la figura 5-33) grafica físicamen-
te el número de trastos que hay en el inventario, lo que se expresa por MX(Inventory Level,
0) y la graficaremos de manera que continúe a medida que el inventario se vuelva más positivo.
Modelado de operaciones detalladas 257
La animación de abajo (la roja, de la que no nos molestamos en hacer una figura aquí) grafica
el número de trastos en retraso, que es MX(-Inventory Level, 0); cuando nos hallemos
en retraso, éste es un número positivo, pero nos gustaría graficarlo más abajo del nivel del cero
a medida que el retraso se hace más acusado, así que seleccionamos que Fill Direction (Rellenar
dirección) sea Down (Baja).
Después de añadir unas cuantas etiquetas y demás, estamos listos para avanzar. Observe la
gráfica y los termómetros para ver caer el nivel de inventario a medida que ocurre la demanda,
para luego aparecer de nuevo cuando lleguen los pedidos. Los costos diarios promedio (redon-
deados al centavo más cercano) fueron 9.37 por mantener, 17.03 por escasez y 100.39 por hacer
el pedido, para un total de 126.79. Saber si (s, S) = (20, 40) es la mejor política es una buena
pregunta y una de la que le pediremos se ocupe (de una forma estadísticamente correcta) en los
ejercicios 6-10 y 6-11 al final del capítulo 6.
5.9 Ejercicios
5-1 Desarrolle un modelo del problema que describimos en el capítulo 2 modelado como el
modelo 3-1, pero esta vez usando sólo módulos del panel Advanced Process (Proceso avanzado)
que reemplacen el módulo Process (Proceso). Use las características Plot (Graficar) y Variable
de la barra de herramientas Animate (Animar) para completar su modelo. Ejecútelo por 20
minutos y compare sus resultados con los obtenidos antes.
5-2 Las partes llegan a un sistema de dos máquinas de acuerdo con una distribución entre
llegadas exponencial con media de 20 minutos. En la llegada, las partes se envían a la Máquina
1 y se procesan. La distribución del tiempo de proceso es TRIA(4.5, 9.3, 11) minutos. Las par-
tes entonces se procesan en la Máquina 2 con una distribución de tiempo de proceso de TRIA
(16.4, 19.1, 21.8) minutos. Las partes de la Máquina 2 se dirigen de vuelta a la Máquina 1 para
ser procesadas una segunda vez (el mismo tiempo de proceso). Entonces las partes completas
salen del sistema. Ejecute la simulación para una sola réplica de 20 000 minutos para observar
el número promedio de colas en la máquina y el tiempo de ciclo promedio de la parte.
5-3 Montones de papel llegan a un proceso de corte con tiempos entre llegadas de EXPO
(10); todos los tiempos están en minutos. Hay dos cortadoras, una primaria y una secundaria.
La totalidad de las llegadas se envían a la cortadora primaria. Si la cola al frente de la cortadora
primaria es menor a cinco, el montón de papel entra en esa cola para esperar a ser guillotinado
por la cortadora primaria, una operación de duración TRIA(9, 12, 15). Si ya hay cinco monto-
nes en la cola primaria, el montón se rechaza hacia la cortadora secundaria (que tiene una cola
de capacidad infinita) para ser guillotinado, de duración TRIA(17, 19, 21). Después de que la
Modelado de operaciones detalladas 259
cortadora primaria haya guillotinado 25 montones, debe apagarse para limpiarla, lo que tarda
EXPO(30). Durante este tiempo, los montones en la cola para la cortadora primaria esperan
a que vuelva a hallarse disponible. Anime y ejecute su simulación por 5 000 minutos. Recopile
estadísticas por guillotina, para el tiempo de ciclo, utilización del recurso, número en la cola y
tiempo en la cola. En la medida en la que le sea posible, emplee los módulos del panel Advanced
Process (Proceso avanzado).
5-4 Los camiones arriban con tiempos entre llegadas EXPO(9) (todos los tiempos están en
minutos) a un área de descarga que posee tres puertos. Los tiempos de descarga son TRIA(25,
28, 30), TRIA(23, 26, 28) y TRIA(22, 25, 27) para los puertos 1, 2 y 3 respectivamente. Si hay
un puerto vacío, el camión procede inmediatamente hacia ese puerto. Suponga cero tiempos de
viaje para todos los puertos. Si hay más de un puerto vacío, el camión se coloca de preferencia
en el puerto de mayor número (3, 2, 1). Si todos los puertos se encuentran ocupados, escoge el
puerto con el número mínimo de camiones en espera. Si hay un empate, se coloca de preferencia
en el puerto con menor numeración (1, 2, 3). Desarrolle un modelo de simulación con módulos
del panel Advanced Process (Proceso avanzado), usando módulos requeridos del panel Basic
Process (Proceso básico) para implementar la lógica de selección. Ejecute su modelo por 20 000
minutos y recopile estadísticas de utilización de puertos, número en la cola, tiempo en la cola y
el tiempo en el sistema.
5-5 Equipos de ventiladores de techo arriban a un sistema de ensamble con tiempos entre
llegadas TRIA(2, 5, 10) (todos los tiempos están en minutos). Hay cuatro operadores de en-
samblaje y los equipos se envían de forma automática al primer operador disponible para su
ensamblaje. El tiempo de ensamblaje del ventilador depende del operador según se muestra a
continuación.
5-6 El personal de control de calidad para el área de ensamble de ventiladores del ejercicio
5-5 decidió que si un ventilador se rechaza una segunda vez, debe ser rechazado del sistema y
enviado a un área diferente para revisión. Haga los cambios necesarios al modelo, ejecute la
simulación por 20 000 minutos y compare los resultados (con base en sólo una replica de cada
modelo). También mantenga el rastro del número de ventiladores rechazados del sistema.
260 Capítulo 5
5-7 Desarrolle un modelo de una línea de producción serial con tres estaciones de trabajo con
altos índices de rechazos: 7% después de cada estación. Las partes rechazadas después de la pri-
mera estación de trabajo se envían al desecho. Las partes rechazadas después de la segunda esta-
ción de trabajo se devuelven a la primera estación de trabajo en donde se revisan, lo que requiere
un “trazo” nuevo de la distribución de tiempo de proceso pero aumentado en 50% de la distribu-
ción de la operación original. (Este factor de castigo de 1.5 aplica sólo en la estación de trabajo 1
y no en la 2, cuando la parte regresa a ella.) Las partes rechazadas en la tercera estación de trabajo
se devuelven a la segunda estación de trabajo donde son revisadas, con un 50% de castigo (pero no
en su nueva visita a la estación de trabajo 3). Los tiempos de operación son TRIA(6, 9, 12), TRIA
(5, 8.5, 13) y TRIA(6.5, 8.9, 12.5) para las estaciones de trabajo 1, 2 y 3 respectivamente (todos
los tiempos están en minutos). Los tiempos entre llegadas de las partes para el sistema son UNIF
(6, 14). Ejecute el modelo por 20 000 minutos, recopilando estadísticas del número en la cola en
cada estación de trabajo, el número de partes desechadas, utilización de estaciones de trabajo y
los tiempos promedio y de ciclo máximo para partes, que no se rechazan en ninguna estación de
trabajo, y para partes que son rechazadas por lo menos una ocasión. También, recopile estadísti-
cas del número de veces que una parte rechazada lo fue.
5-8 Con la finalidad de disminuir el tiempo del ciclo de la parte en el ejercicio 5-7, se está
considerando un nuevo plan prioritario. La prioridad de la cola se basa en el número total de
veces que se rechaza una parte, sin importar de dónde fue rechazada, con la mayor cantidad
de rechazos condenados en contra de una parte, lo más atrás de la cola. ¿Hay alguna diferencia
en los tiempos de ciclo para este nuevo plan prioritario? PISTA: Emplee el módulo de datos
Queue (Cola) para usar el conteo de rechazos como un plan de clasificación de la cola.
5-9 Las partes arriban a una tienda de máquinas con tiempos entre llegadas EXPO(25)
(todos los tiempos están en minutos). La tienda tiene dos máquinas, y las partes que llegan
se asignan a una de las máquinas con un volado (justo). Excepto por los tiempos de proceso,
ambas máquinas operan de la misma forma. Cuando una parte entra en el área de máquina,
requiere la atención de un operador para montar la parte en la máquina (sólo hay un operador
en la tienda). Después de que la parte está montada, la máquina puede procesarla sin el ope-
rador. Una vez completado el proceso, el operador es requerido de nuevo para retirar la parte.
Después de terminar, la parte sale del sistema (las partes tienen que ir sólo a una máquina). El
mismo operador hace todos los montajes y quita todas las partes, con la prioridad dada a la
máquina que espera más por operador. Los tiempos son (los parámetros son para distribucio-
nes triangulares):
5-10 Un pequeño almacén proporciona almacenamiento de trabajo en proceso para una ins-
talación de fabricación que produce cuatro tipos diferentes de partes. Los porcentajes de tipo
de parte y los costos de inventario por parte son:
Costo de inventario
Tipo de parte Porcentaje Por parte
1 20 $5.50
2 30 $6.50
3 30 $8.00
4 20 $10.50
La interpretación de “costo de inventario por parte” es como sigue. Cada parte en inventario
contribuye con una cantidad de la última columna de la tabla anterior al costo total (valor) del
inventario que se mantiene en el momento. Por ejemplo, si el inventario actual es de tres unida-
des de la parte 1, ninguna de la parte 2, cinco de la parte 3 y una de la parte 4, entonces el costo
de inventario actual es
Conforme las partes entran y salen, como se describe a continuación, este costo de inventario
aumentará y disminuirá.
Las partes arriban con tiempos entre llegadas TRIA(1.5, 2.0, 2.8) (todos los tiempos están
en minutos). Dos grúas almacenan y retiran las partes con un tiempo de viaje UNIF(1.2, 2.9)
para cada camino. Las peticiones de remoción de partes siguen el mismo patrón que para las
llegadas. Si no hay ninguna parte disponible, la petición no se llena. Todas las peticiones de
partes tienen prioridad sobre los almacenajes y la prioridad se da para recuperarse con base en
el costo más alto por parte.
Para las llegadas de partes, aumente el costo de inventario sobre llegada y el número total
de partes en inventario después de que la parte es almacenada. Para peticiones de partes, dis-
minuya el número total de partes en inventario, tan pronto como sepa que hay una parte por
recuperar, y el costo de inventario después de que la parte sea recuperada.
Ejecute su modelo por 5 000 minutos comenzando con cuatro partes de cada tipo en el
almacén. Recopile estadísticas en la utilización de grúa, el costo promedio de inventario, el nú-
mero promedio de cada tipo de parte en el almacén y el número de peticiones sin llenar debido
a que no se tienen partes del tipo requerido.
PISTAS: Use las variables índice para el inventario de partes y el costo por parte. (Note que
necesita emplear la opción “Other” [Otro] en el módulo Assign (Asignar) cuando se asignen a
variables índice.) Use la distribución discreta para determinar el tipo de parte, y el módulo de
datos Statistic (Estadística) para recopilar algunas de las estadísticas requeridas.
equipaje y proceden a la aduana. Los tiempos entre llegadas para aduanas se distribuyen como
EXPO(0.2); todos los tiempos están en minutos. El plan actual es tener dos agentes de aduanas
dedicados a pasajeros a quienes no se les revisará su equipaje, con tiempos de servicio distri-
buidos como EXPO(0.55). Un nuevo analista de sistemas de aeropuerto desarrolló un método
probabilístico para decidir a qué clientes se les revisará el equipaje. La decisión se toma cuando
los pasajeros están por entrar a la cola normal de aduana. El proceso de decisión es como sigue:
un número se genera primero de una distribución Poisson con una media de 7.0. Este número se
aumenta en 1, para evitar obtener un cero, y se comienza una cuenta. Cuando la cuenta alcanza
el número generado, ese desafortunado pasajero es enviado a una segunda línea para revisar su
equipaje. Se produce un nuevo número de búsqueda y el proceso comienza de nuevo. Un sólo
agente está dedicado a estos pasajeros, con tiempos de servicio distribuidos como EXPO(3).
El número de pasajeros que llega en estos grandes aviones se encuentra distribuido de manera
uniforme entre 240 y 350 y la simulación tiene que ejecutarse hasta que todos los pasajeros del
avión hayan sido procesados por completo. Desarrolle una simulación del sistema propuesto
y haga 20 réplicas, observando las estadísticas en el tiempo del sistema por tipo de pasajero
(revisado contra no revisado), el número de pasajeros, y la utilización de agentes.
5-12 Un centro estatal de examen para licencias de conducir quisiera evaluar su operación
para una mejora potencial. Los clientes que llegan entran al edificio y toman un número para
determinar su lugar en la línea para un examen escrito, que es autoadministrado por uno de
los cinco examinadores electrónicos. Los tiempos de la prueba se encuentran distribuidos como
EXPO(8); todos los tiempos están en minutos. Trece por ciento de los clientes fallan la prueba
(es un examen complicado con muchas preguntas). A estos clientes se les da un folleto de las
reglas estatales de manejo para su estudio posterior y dejan el sistema (a pie). Los clientes que
pasan la prueba seleccionan una de las dos cabinas donde se les toma su fotografía y se expide
la nueva licencia. Los tiempos de la cabina fotográfica son distribuidos como TRIA(2.5, 3.6,
4.3). Las cabinas de fotos tienen líneas separadas y los clientes entran a la línea con el menor
número de clientes esperando en la cola, ignorando si alguna está en servicio; si las líneas son
iguales, entran a la cabina más cercana que es la 1. Note que este conjunto de reglas puede ori-
ginar lo que puede parecer un comportamiento irracional del cliente en el caso de que ninguna
cabina tenga una cola (esto es, las longitudes de ambas colas son cero), la cabina 1 está ocupada
y la cabina 2 ociosa; un cliente que llega al área de fotografía escogería formarse en la cola de
la cabina 1 (vía la regla de romper el empate, ya que las longitudes de las colas son iguales a
cero) en lugar de ir a la derecha al servicio en la cabina 2 (pero escuche, ¡ellos no pueden ver den-
tro de las cabinas fotográficas!) Luego, estos clientes dejan el sistema (manejando), sosteniendo
orgullosamente sus nuevas licencias. El centro está abierto para los clientes que llegan ocho
horas al día, aunque los servicios continúan por una hora más para satisfacer a los que faltan.
El patrón de llegada de los clientes varía durante el día y se resume a continuación:
Ejecute su simulación por diez días, manteniendo las estadísticas en el número promedio
de pruebas fallidas por día, examinadores electrónicos y utilización de cabinas fotográficas (no
la utilización para todo el recurso de prueba, pero sí utilizaciones separadas para cada cabina
fotográfica), número promedio en la cola y tiempo promedio de clientes en el sistema para
aquellos que pasan el examen escrito. Anime todas las cabinas de pruebas electrónicas y las
fotográficas.
5-13 Una oficina de un departamento estatal de licencias tiene dos tipos de llegadas. Los indivi-
duos interesados en comprar nuevas placas se caracterizan por tener tiempos entre llegadas dis-
tribuidos como EXPO(6.8) y tiempos de servicio TRIA(8.7, 13.7, 15.2); todos los tiempos están
en minutos. Los individuos que quieren renovar o solicitar una licencia de manejo tienen tiempos
entre llegadas distribuidos como EXPO(8.7) y tiempos de servicio TRIA(16.7, 20.5, 29.2). La ofi-
cina tiene dos líneas, una para cada tipo de cliente, y cinco empleados: dos dedicados a las placas
(Mary y Kathy), dos a las licencias (Sue y Jean), y el líder del equipo (Neil) que puede servir a
ambos tipos de clientes. Neil servirá al cliente que haya estado esperando el mayor tiempo. Su-
ponga que todos los empleados se encuentran disponibles todo el tiempo durante las ocho horas
del día. Note que cuando las entidades del frente de colas FIFO múltiples (que corresponden a
módulos Process [Proceso] múltiples) intentan tomar el mismo Resource (Recurso), la lógica para
seleccionar qué entidad “gana” es como si todas las colas estuvieran fusionadas juntas en una sola
cola FIFO. Observe el sistema o tiempo de ciclo para ambos tipos de cliente.
5-14 La oficina descrita en el ejercicio 5-13 está considerando capacitar a Kathy para que
pueda servir a ambos tipos de clientes. Modifique el modelo para representar esto y observe qué
efecto tiene en el tiempo del sistema por cliente.
5-15 Modifique el modelo del ejercicio 5-14 para incluir un receso para almorzar de 30 minu-
tos para cada empleado. Comience el primer receso a los 180 minutos del día. Los recesos para
almorzar deberían seguirse uno tras otro cubriendo 150 minutos de periodo de tiempo durante
la mitad del día. Los recesos deberían darse en el siguiente orden: Mary, Sue, Neil, Kathy y
Jean. ¿Qué impacto tiene esto en el tiempo del sistema por cliente?
5-16 Modifique el modelo del tablero de probabilidad del ejercicio 3-10 para que las probabi-
lidades de límite derecho para todas las clavijas se puedan cambiar a la vez al modificar el valor
de una sola variable. Ejecútelo con las probabilidades de límite derecho configuradas en 0.25 y
compare con el resultado de la versión del viento del modelo del ejercicio 3-10.
5-17 Recree el modelo 5-4 (el modelo del inventario) sin emplear ninguno de los paneles Bloc-
ks (Bloques) o Elements (Elementos), y usando sólo módulos del panel Basic Process (Proceso
Básico) y Advanced Process (Proceso Avanzado).
5-18 En el modelo 5-4 los tiempos relativos del intervalo de evaluación de inventario y el retra-
so de entrega fueron tales, que en ningún momento pudieron ser mayores a un pedido pendiente.
¿Qué pasaría si los números fueran diferentes para que así pudiera haber pedidos múltiples en el
camino en un momento dado? ¿Seguiría funcionando el modelo 5-4? (Note que en el modelo 5-4
representamos la cantidad de pedidos, si los hay, por un atributo de la entidad del evaluador de
inventario; ¿qué pasaría si esa cantidad de pedido se hubiera representado con una variable?)
264 Capítulo 5
5-19 En el modelo 5-4 quite el “factor engañoso” de terminar en tiempo 119.9999 en lugar
del 120 correcto. Ejecute la simulación al tiempo exacto 120, pero añada lógica para evitar una
evaluación de inventario inútil en el tiempo 120; ¿cuál es el efecto en el resultado?
5-20 Generalice el modelo 5-4 para tener dos tipos adicionales de artículos (adornos y acceso-
rios), así como trastos. Los clientes llegan en el mismo patrón que antes, pero ahora cada uno
tendrá una demanda de adornos y accesorios, así como de trastos. Las demandas de trastos son
como antes, las demandas de adornos son POIS(1.9), y de accesorios son POIS(2.3); suponga
que la demanda de un cliente para un artículo es independiente de sus demandas para los otros
dos artículos. Aún hay un evaluador de inventario, que sigue llegando al inicio de cada día, pero
ahora tiene que ver los tres inventarios y pedir de acuerdo a políticas separadas (s, S) para cada
uno de los tres. Para trastos, (s, S) = (20, 40) como antes; para adornos, (s, S) = (15, 35); y para
accesorios, (s, S) = (25, 45). Los retrasos en la entrega para los trastos son UNIF(0.5, 1.0) como
antes; para los adornos, es UNIF(0.4, 0.8); y para accesorios, es UNIF(0.8, 1.7). Los costos
por hacer el pedido (tanto configurado como incremental), por mantener y por faltante para
adornos y accesorios son los mismos que para los trastos. Ejecute la simulación por la misma
duración de tiempo que en el modelo 5-4 (esto significa que es correcto suavizar el punto final
para evitar evaluaciones de inventario inútiles en el tiempo 120), y obtenga el costo total diario,
así como el costo por mantener y el de faltante por separado para cada tipo de artículo.
5-21 En el ejercicio 5-20, suponga que los proveedores de los tres artículos se fusionan y ofre-
cen un acuerdo para eliminar los costos de configuración múltiples en los pedidos de un día
determinado, esto es, si Bucky ordena un artículo de cualquier tipo al inicio del día, sólo tiene
que pagar el costo de configuración de 32 dólares una vez para ese día, no uno separado de 32
dólares para cada tipo de artículo que ordene. (Si no se coloca ningún pedido de ninguna cosa,
no hay costo de configuración.) Modifique su modelo del ejercicio 5-20 para hacer esto. ¿Qué
tipo de incentivos cree usted que esta estructura de costo alterna debe ofrecer a Bucky en térmi-
nos de recoger mejores valores de s y S para cada artículo? (Véanse los ejercicios 6-13 y 6-14.)
5-22 En el modelo de reparación de la máquina del ejercicio 3-14, suponga que cuesta 80
dólares en pérdida de productividad por cada hora que cada máquina está descompuesta y 19
dólares/hora para emplear a cada técnico de reparación (a los técnicos se les paga tales horas
sin importar si están ocupados u ociosos). Modifique el modelo para recopilar estos datos de
costos y reporte el costo total promedio por hora. También muestre las máquinas en el estado
“de funcionamiento” en un área separada de la animación, haga imágenes independientes de
animación de las máquinas en funcionamiento contra descompuestas y siga el rastro del nú-
mero de máquinas en funcionamiento (y grafíquelas). Realice una Variable del número de má-
quinas en la tienda. Si usted lector quiere minimizar el costo promedio total, ¿es dos el número
correcto de técnicos de reparación? Experimente (aunque consulte el ejercicio 6-21 para ver una
forma estadísticamente válida de experimentación).
CAPÍTULO 6
Como advertimos antes al lector en la sección 2.6 con la simulación a mano, existe un tema de
aleatoriedad y por lo tanto de análisis estadístico cuando se construye un modelo con cualquier
entrada aleatoria (es decir, dirigida por distribución o probabilidad), como ha sido el caso de
todos nuestros modelos hasta ahora. En esta sección, le mostraremos cómo recopilar los datos
apropiados para la simulación y después analizarlos de los reportes que ha estado obteniendo,
usando el modelo 5-3 de la tercera versión del modelo del centro de atención telefónica que se
creó en el capítulo 5. También le mostraremos cómo hacer análisis estadísticos más sofisticados
con la ayuda del Output Analyzer [Analizador de resultados] (para comparar dos versiones
alternativas de su modelo, llamadas escenarios), el Process Analyzer [Analizador de Procesos]
(para ejecutar varios escenarios de forma conveniente y quizá seleccionar el mejor o medir los
efectos de las entradas en los resultados) y el OptQuest para Arena (que “toma el mando” de la
ejecución de su modelo en búsqueda de una configuración de controles de entrada que optimice
una respuesta seleccionada de resultados).
En la sección 6.1 hablaremos acerca del marco de tiempo de las simulaciones, lo que afecta la
clase de análisis que el lector hace. Después, en las secciones 6.2 y 6.3, describiremos la estrate-
gia básica para la recopilación de datos y análisis estadístico en el contexto de una sola variante
(el caso base del modelo 5-3, con el número de líneas principales aún en 26 y sin contratación de
personal adicional para las horas de 5 a 8). Haremos algunos cambios sencillos a los paráme-
tros de entrada del modelo en la sección 6.4 y usaremos el Ouput Analyzer de Arena para ver
si hay alguna diferencia (estadísticamente significativa). En la sección 6.5 presentaremos más
variantes del modelo y usaremos el Process Analyzer de Arena para ejecutarlas en una manera
eficiente y organizada, y resolveremos cuál de ellas es probablemente la mejor. Por último, en la
sección 6.6, usaremos el OptQuest para Arena para buscar de forma inteligente y eficiente entre
un número desconcertante de posibles combinaciones de entradas-parámetros para una confi-
guración del modelo que parezca ser óptima en algún sentido. Ilustraremos detalladamente los
métodos que resulten en un análisis estadístico confiable y preciso, que promueva decisiones
informadas y responsables.
En el pasado, que afortunadamente ya transcurrió, muchas de las personas ignoraban
bastante este tipo de temas lo que es una verdadera vergüenza. Con sólo ejecutar su modelo
una vez y después probar unos pocos escenarios elegidos al azar (y ejecutarlos también sólo una
vez) no se tiene idea de qué tan válidos, precisos o generales puedan ser sus resultados o conclu-
siones. A veces la verdad acerca de la validez, la precisión y la generalidad puede ser desagra-
dable y por consiguiente peligrosa si es que se desconoce, ya que se correría un riesgo real de
obtener bajos estimados y tomar malas decisiones. Como se verá, no toma mucho tiempo de su
parte hacer bien estas cosas; su computadora puede tener un trabajo duro, pero como sea, pasa
la mayor parte del tiempo sin hacer nada y además, a diferencia de usted, es barata (comparada
con la importancia de las decisiones que tomará con base en los resultados de su simulación).
Ha trabajado arduamente para construir su modelo, así que ahora es tiempo de dejar que sea
266 Capítulo 6
su modelo (y su computadora) el que trabaje duro para averiguar en verdad cómo se comporta
para que luego usted pueda transmitir confiadamente ese conocimiento a decisiones sólidas.
1
Aunque conceptualmente sencillo, esto aún puede implicar mucho tiempo de ejecución para modelos grandes o
con muchas variables.
Análisis estadístico de resultados de las simulaciones terminadas 267
encuentren marcados. Estos cambios harán que la simulación se repita n veces, con cada réplica
empezando desde cero (estado del sistema y de los acumuladores estadísticos frescos) y usando
números aleatorios básicos por separado2 para conducir la simulación. Para cada réplica, se
genera una sección separada en el reporte Category by Replication (categoría por réplica) que
contiene los resultados de esa réplica (dichos resultados por réplica no están en el reporte Cate-
gory Overview [Vista general de categorías]).
Por ejemplo, creamos el modelo 6-1 para ser el mismo que el caso base del modelo 5-3 (el nú-
mero de líneas principales igual a 26 y sin contratación de personas adicionales para las horas
5 a 8), excepto que hicimos que n = 10 réplicas para obtener los valores de la tabla 6-1 para las
medidas de desempeño Total Cost (Costo total) y Percent Rejected (Porcen-
taje de rechazo). Es importante recordar que cada uno de estos valores es el resultado de
una ejecución de simulación completa así como una “observación” (o “comprensión”) de una
variable aleatoria que representa el Total Cost y el Percent Rejected en una réplica
“aleatoria” con estas condiciones de inicio y detención.
¿Cómo supimos de antemano que n = 10 era el número apropiado de réplicas a hacer? Lo
desconocíamos. Y todavía no lo sabemos ya que no hemos hecho ningún análisis de estos datos.
Esto es típico pues no se sabe por adelantado qué tanta variación se obtiene en el resultado.
Tendremos más que decir después acerca de elegir (o adivinar) un valor apropiado para el nú-
mero de réplicas. Por cierto, cuando el lector haga de forma mecánica réplicas como ésta para
análisis estadístico, apague la animación para no mover las cosas, como lo hicimos para el mo-
delo 6-1: elija Run > Run Control (Ejecutar > Control de ejecución) y seleccione (marque) Batch
Run (No Animation) (ejecución de grupo sin animación); para después regresar a la animación,
tendrá que volver y despejar la misma entrada.
Probablemente no querrá copiar todos los valores para la totalidad de las medidas de des-
empeño de interés en todas las réplicas y después teclear o pegarlas en algún paquete estadísti-
co, hoja de datos o una calculadora para el análisis. Afortunadamente, Arena sigue el rastro de
2
De hecho, cada réplica sólo se mantiene avanzando dentro de los mismos “flujos” de números aleatorios que se
han usado; véase el capítulo 12 para más información sobre cómo funcionan y se controlan los generadores de números
aleatorios.
268 Capítulo 6
forma interna de todos los resultados en los reportes para la totalidad de las réplicas. Si se está
haciendo más de una réplica, el reporte Category Overview (Vista general de categorías) le dará
un porcentaje de cada resultado en las réplicas, junto con la mitad de un intervalo de confianza
(nominal) de 95% en el valor esperado del resultado de salida; analizaremos más adelante lo
que todo esto significa en la sección 6.3.
También se puede usar Arena para guardar en archivos binarios “.dat” (para alimentar el
Output Analyzer de Arena, una aplicación por separado que analizaremos después en la sección
6.4) lo que se desee del resumen de cada réplica. Haga esto en el módulo de datos Statistic (Esta-
dística), al especificar los nombres de los archivos en la columna Output File (Archivo de resul-
tados) a la derecha de cada fila que tenga Output (Resultado) como la selección en su columna
Type (Tipo). Así, este archivo contendrá la clase de datos que enlistamos en la tabla 6-1.
Tabla 6-2. Análisis estadístico de diez repeticiones del modelo 6-1 (igual que el modelo 5-3)
Porcentaje
Costo total ($)
de rechazo
Media de la muestra 21 547.82 12.33
Desviación estándar de la muestra 2 243.38 2.31
Mitad del intervalo de confianza de 95% 1 604.82 1.66
Resumen de valor de resultados mínimos 19 565.40 9.30
Resumen de valor de resultados máximos 23 834.40 17.61
Análisis estadístico de resultados de las simulaciones terminadas 269
Figura 6-1. Resultados de diez repeticiones del modelo 6-1 (igual que el modelo 5-3)
Probablemente sea obvio que la forma para reducir la mitad del intervalo de confianza
esperado en el Total Cost o en el Percent Rejected (o en cualquier ámbito, para ese
tema) sea aumentar el tamaño de la muestra, n. ¿Pero cuánto? Si usted tiene cierta “pequeñez”
en mente que le gustaría (o toleraría) para el intervalo de confianza, puede darse fácilmente una
idea, pero no una respuesta exacta, de qué tan grande debe ser n para alcanzar esta meta. Su-
ponga que tiene un conjunto inicial de réplicas de las que calcula un promedio y una desviación
estándar de la muestra y entonces un intervalo de confianza cuya mitad es decepcionantemente
grande. Por ejemplo, de nuestras 10 réplicas iniciales anteriores en el caso de Total Cost,
obtuvimos una media de la muestra de = $21 547.82, una desviación estándar de la muestra
de s = $2 243.38 y la mitad del intervalo de confianza a 95% resultó ser
s 2 243.38
tn −1,1− Ĝ / 2 = 2.262 = $1 604.71
n 10
(hacia arriba2 para redondear),s2 que representa un 7.4% de error en la estimación del punto
n = tSi
$21 547.82. n −1desea
. una mitad específica del intervalo h, presumiblemente menor que la
,1− Ĝ / 2 lograr
h 2
que obtuvo de susconjunto inicial 2 243.de
38 réplicas, intente estableciendo h igual a la fórmula de la
t = 2.262y resuelva =n:$1 604.71
tn −1,1− Ĝ / 2 n
mitad del 1,1− Ĝ / 2
n −intervalo anterior 10
0
s2
n = tn2−1,1− Ĝ / 2 .
h2
tn −1,1− Ĝ / 2 con esto es que en realidad no se resolvió para n, ya que el lado derecho aún
La dificultad
0
depende de n (a través de los grados de libertad en el valor crítico de la distribución t y, aunque
la notación no lo muestra, a través de la desviación estándar s, que depende no sólo de n sino
de todos los datos obtenidos del conjunto inicial de n réplicas). Sin embargo, para obtener al
menos una tosca aproximación al tamaño requerido de la muestra, se podría reemplazar el va-
lor crítico de la distribución t en la fórmula anterior con el valor crítico de la normal estándar
(están cercanos a n más de 30) y pretender que el estimado actual s sea algo similar cuando se
calcula en una muestra más grande. Esto conduce a lo siguiente como un tamaño aproximado
de la muestra requerida para lograr un intervalo de confianza con una mitad igual al valor h
deseado y preespecificado:
270 Capítulo 6
z1 − Ĝ /2
s2
n ƹ z12− Ĝ /2 2
h
z1 − Ĝ /2
en donde s es sla22desviación estándar de la muestra de un conjunto inicial de n réplicas (que de-
nƹ
bería h
z 2− Ĝ /hecho
haber
n 1ƹ n20 h 202 antes de hacer esto). Una aproximación más sencilla pero un poco diferente
es (dejaremos hal lector el álgebra)
zz1 − Ĝ /2
h021 − Ĝ /2 22
n ƹ n0 222 s2 243.38 2
nƹ 2 s
n ƹh1zz11.96 / 2 = 77.3 (first approximation)
− Ĝ /2 2
h
− Ĝ
h 2 500 2
en donde n0 es el número de réplicas iniciales que tiene y h0 es la mitad del intervalo que obtuvo
2 2 2243.38 del Total Cost anterior, para reducir la mitad del intervalo de h =
2
de ellas. En el
n 1.96 h 2
hejemplo = 77.3 (firstentonces
ƹ n n 0 0
nƹ
$1 604.71 ƹa,ndigamos,
0
0 1 2604.71
2 500
2
2 h = $500.00, approximation)
necesitaremos un total de algo como
n ƹ10 hh
0
= 103.0 (second approximation)
500 2
11604 2
2 243
2.71 243..38
2 2
38 2 = 77.3 (first
n ƹ .96 2
n ƹn10ƹ1.96 2 = 103 2 .0=(second
77.3 (first
(primera aproximación)
approximation)
approximation)
approximation)
500 500 500 2
s 2 243.38
o tn −1,1− Ĝ / 2 = 2.262 = $1 604.71
1 n 10
1 604
604..71
2
712 = 103.0
n
nƹƹ10
10 = 103.0 (second
(segunda
(second aproximación)
approximation)
approximation) s2
500 2
500
2
n = tn2−1,1− Ĝ / 2 2 .
h
(redondeada hacia arriba) réplicas en lugar de las diez que originalmente hicimos. La segun-
da aproximación será siempre mayor ya que usa tn −1,1− Ĝ / 2 más que z1 − Ĝ /2 . Note el deprimente
0
crecimiento cuadrático del número de réplicas conforme h disminuye (esto s 2 es, exigimos más
precisión); para reducir la mitad del intervalo a la mitad de su nvalor
ƹ z12−inicial,
Ĝ / 2 2 se necesitan casi
cuatro veces más réplicas. Aunque esto parece ser injusto (para hacerlo doshveces también debe
trabajar cuatro veces más duro), la intuición es que a medida que se añaden más y más réplicas,
cada réplica adicional conlleva cada vez menos aumento del porcentajeh0en 2
su almacén acumu-
n ƹ n 0 2
lado de conocimiento. h
Puesto que este modelo se ejecuta muy rápido sin la animación, decidimos ser conserva-
dores (de forma estadística, pero no necesariamente de forma política) y hacer 110 réplicas. El
2 2 243.38 Parameters
2
único cambio que se requirió para el modelo 6-1 fue en Run > Setup > Replication
n ƹ 1. 96
(Ejecución > Configuración > Parámetros de réplica) en donde cambiamos el 500 77.3 (first approximation)
10 2en el=Number
of Replications (Número de réplicas) a 110; lo llamaremos el modelo 6-2 de resultado. Esto
produjo un intervalo de confianza a 95% de
22 241.71 ± 413.52 1 604.712
n ƹ10
= 103.0 (second approximation)
500ahora).
o en otras palabras, [21 828.12, 22 655.16] (dejaremos las unidades “$” desde
2
Note que
esto coincide con nuestra meta de bajar la mitad del intervalo a 500 o menos y sí, está por deba-
jo de 500, así que quizá nos pasamos un poco en el número de réplicas; por otra parte, podría
haber sucedido que la mitad del intervalo estuviera todavía por encima de 500, ya que aquéllas
en realidad son sólo aproximaciones y no son exactas. En la sección 12.5 analizaremos muestreo
secuencial, que para nosotros serán formas de engañar a Arena en una ejecución continua hasta
que produzca intervalos de confianza que realmente sean de la precisión deseada.
Análisis estadístico de resultados de las simulaciones terminadas 271
Por cierto, de las 100 réplicas ejecutadas del modelo 6-2, el intervalo de confianza a 95%
aproximado en el porcentaje esperado de llamadas entrantes que son rechazadas fue de 11.6536
± 0.53. Esto parece ser un intervalo de confianza bastante estrecho, con la mitad del intervalo
de la mitad de un punto porcentual (en una escala sin dimensiones sería siempre entre 0 y 100
para un porcentaje). Sin embargo, si lo que se quería era una precisión más ajustada, se po-
drían repetir las aproximaciones anteriores para el número requerido de réplicas y después usar
el máximo de esto y el 110 que obtuvimos para la medida de desempeño del resultado Total
Cost, de manera que se pudieran satisfacer las necesidades de precisión en ambos resultados.
Es importante entender qué es (y qué no es) un intervalo de confianza. Tome la medida de
resultado Total Cost como ejemplo. Cada réplica produce un valor de Total Cost para
esa réplica y, debido a las entradas aleatorias, estos valores varían entre las réplicas. El prome-
dio de 110 valores, estará de acuerdo el lector, es probablemente un “mejor” indicador de qué
esperar de una ejecución “típica” que de cualquiera de los valores individuales. También, es
intuitivo que entre más réplicas se hagan, “mejor” será tal promedio. Al promedio esperado,
que por lo general se denota por alguna clase de notación como μ, se le puede considerar como
el Total Cost promediado en un número infinito de réplicas; como tal, μ no tendrá una in-
certidumbre asociada a él.
Desafortunadamente, los simples mortales como nosotros no podemos esperar un núme-
ro infinito de réplicas, así que debemos hacerlo con un estimado de muestra finita como el
22 241.71 de nuestras 110 réplicas. El intervalo de confianza centrado alrededor de 22 241.71
puede pensarse como un intervalo “aleatorio” (el siguiente conjunto de 110 réplicas le dará
un intervalo diferente) que tiene (en este caso) aproximadamente un 95% de probabilidades de
contener o “cubrir” al μ en el sentido de que si realizamos muchos conjuntos de 110 réplicas
e hicimos un intervalo para cada conjunto, casi 95% de esos intervalos cubrirían al μ. Así, un
intervalo de confianza le da tanto un “punto” estimado (22 241.71) del μ, como la idea de qué
tan preciso es este estimado.
Un intervalo de confianza no es un intervalo en el que, por ejemplo, 95% de las medidas
Total Cost de las réplicas caerán. Un intervalo así, llamado intervalo de predicción, es útil y
básicamente también puede estar derivado de los mismos datos. Una diferencia clara entre es-
tos dos tipos de intervalo es que el intervalo de confianza disminuirá a un solo punto conforme
n aumente, pero un intervalo de predicción no lo hará ya que necesita permitir una variación
en réplicas (futuras).
Un último acercamiento a los intervalos de confianza refiere a nuestra cobertura del enun-
ciado de nivel de confianza (“aproximadamente” 95%, etc.). Los métodos estándares para
hacer esto, los cuales usa Arena, suponen que los datos básicos, como las 110 observaciones
en el Total Cost entre réplicas, son IID (eso es satisfactorio para nosotros) y normal-
mente distribuidos (que no es satisfactorio). Básicamente, el uso de la distribución t en la
fórmula del intervalo de confianza requiere una normalidad de los datos. Así que, ¿cuál es el
efecto en el nivel de confianza actual (en oposición al indicado) de violación de este supues-
to de normalidad? Podemos señalar firmemente y sin lugar a dudas que depende de varias
cosas, incluyendo la distribución “verdadera” así como el número, n, de réplicas. El teorema
del límite central, uno de los fundamentos de la teoría estadística, nos asegura que estaremos
bastante bien (en términos de que la confianza real se encuentre cercana a la confianza indi-
cada) si n es “grande”. Pero ¿qué tan grande? La respuesta a esto es bastante imponderable
y depende de qué tanto se parezca la distribución de los datos a una distribución normal,
particularmente en términos de simetría. Esto puede ser verificado al menos cualitativamen-
272 Capítulo 6
te al hacer un histograma de los valores de los datos, como aparece en la figura 6-2 para
n = 1 000 réplicas en lugar de las 110 originales (el histograma con sólo 110 puntos no ilustró
mucho). Para hacer esta gráfica, modificamos el modelo 6-2 en el modelo 6-3, al cambiar pri-
mero el Number of Replications de 110 a 1 000 en Run > Setup > Replication Parameters
y también al guardar los 1 000 valores individuales de Total Cost en un archivo llamado
Total Cost.dat, que llamamos en la columna Output File (Archivo de resultado) en la
fila para Total Cost en el módulo de datos Statistic (Estadística). Entonces ejecutamos
el Output Analyzer de Arena (tendremos más qué decir sobre esto en un apartado adicional
de software en la sección 6.4) para leer Total Cost.dat; lo exportamos a un archivo de
texto llano de ASCII (File > Data File > Export [Archivo > Archivo de datos > Exportar] en
el Output Analyzer), lo reacomodamos y lo hicimos más eficiente en una hoja de cálculo, lo
guardamos como archivo de texto ASCII y después lo trajimos al Input Analyzer (Analiza-
dor de entrada) de Arena (véase la sección 4.6.4), aun cuando no son datos “de entrada” para
un modelo de simulación.
Aunque la verdad es que con sólo observar los datos vemos que la forma del histograma no
es muy diferente a la conocida curva “de campana” de la función normal de densidad (aunque
parece estar un poco torcida hacia la derecha), ello sugiere que probablemente estamos en
lo correcto en cuanto a usar el método estándar del intervalo de confianza aun para un va-
lor relativamente pequeño de n. Para este modelo (que tardó casi 40 segundos en ejecutar las
1 000 réplicas en una máquina de 2.13 GHz) nos dimos el lujo de hacer estas 1 000 réplicas para
revisar su normalidad; con un gran modelo de fortaleza industrial, no se podrá realizar nada
de esto, así que ¿cómo se revisa en la práctica? ¿O es sólo un artículo de fe? Muy distante de ser
un enunciado de verdad general, mucha de la experiencia de simulación (respaldada por alguna
teoría en la forma de versiones más generales del teorema del límite central) indica que si el
Análisis estadístico de resultados de las simulaciones terminadas 273
valor que se obtiene de cada réplica individual es una suma del porcentaje de algo, en oposición
a un valor extremo, el uso de métodos de inferencia estadística de la teoría normal estándar
es bastante seguro. Nuestra medida Total Cost se encuentra en forma de “suma”, quizá al
explicar su normalidad aproximada en la figura 6-2 y al justificar el uso de métodos estadísticos
con base en la teoría normal de Arena.
la sección 6.3 que, de 110 réplicas del escenario del caso base, un intervalo de confianza de 95%
en el Total Cost esperado es
Regresando al modelo en la configuración con más recursos, también con 110 réplicas, el inter-
valo de confianza se convierte en
Estos dos intervalos no coinciden del todo, sugiriendo que los Total Costs son significati-
vamente diferentes. Volviendo a la medición del resultado de Percent Rejected, el interva-
lo de confianza del caso base fue de 11.6536 ± 0.53, mientras que el intervalo del caso con más
recursos fue de 1.6396 ± 0.28; estos dos intervalos no coinciden, lo que sugiere una diferencia
estadísticamente significativa en esta medición. Sin embargo, fijarse si los intervalos de confian-
za coinciden o no, no es exactamente el procedimiento correcto; para hacer la comparación de
la forma correcta, usaremos el Output Analyzer de Arena que se aborda a continuación.
Como mencionamos con anterioridad, el Output Analyzer es una aplicación por separado
que se ejecuta aparte de Arena, pero que opera en archivos de resultados creados por Arena a
través del módulo de datos Statistic (los archivos .dat que ya mencionamos). Aunque algunas de
las actividades que hace el Output Analyzer también las realiza Arena (como formar los inter-
valos de confianza en las medidas de desempeño del resultado esperadas), el Output Analyzer
tiene capacidades adicionales y una comparación estadística entre dos escenarios.
Para guardar los valores de Total Cost de cada réplica en un archivo .dat para el Output
Analyzer, introdujimos Total Cost.dat en la columna de Output File (Archivo de resultado)
para la fila Total Cost en el módulo de datos Statistic y de forma similar para Percent Re-
jected. Después de que se ejecuta la simulación, estos archivos contendrán los 100 valores de
esas medidas del desempeño de resultados en las 110 réplicas; sin embargo, el formato del archivo
es binario y sólo se puede leer mediante el Output Analyzer, por lo que no será legible en apli-
caciones como procesadores de texto u hojas de cálculo. Puesto que queremos guardar los valo-
res de Total Cost y Percent Rejected durante las 110 réplicas de ambos escenarios, tanto
del caso base como del de más recursos, y ya que tendremos dos archivos así para cada medi-
da del desempeño de los resultados, necesitamos ya sea cambiar sus nombres de archivo en el
modelo de Arena antes de cada ejecución, o darles un nuevo nombre en el sistema operativo
después de cada ejecución para evitar sobrescribirlos en ejecuciones subsecuentes; tomamos la
última de estas rutas y agregamos “- Base Case” o “- More Resources” a los nombres
de los archivos. Una vez que el lector haya hecho sus ejecuciones de 110 réplicas de cada uno de
los dos escenarios, comience el Output Analyzer (probablemente se localice en la misma carpeta
que contiene a Arena, a menos que se haya realizado algo raro durante su instalación).
En el Output Analyzer, seleccione File >New (Archivo > Nuevo) (o Ctrl+N o ) para abrir
un grupo nuevo de datos. Esto no es un archivo .dat, sino más bien una lista de archivos de este
tipo que se selecciona como aquellos en los que tiene un interés actual; esto básicamente elimina
los muchos otros posibles archivos .dat y, mientras no se requiera, simplifica las cosas. Se puede
guardar este archivo de grupo de datos (la extensión del nombre del archivo predeterminada es
.dgr) después de llenarlo con nombres de archivo .dat, así que la próxima ocasión sólo lo abrirá
en lugar de seleccionar los archivos .dat otra vez; guardamos este grupo de datos como Model
06-04.dgr.
Análisis estadístico de resultados de las simulaciones terminadas 275
Use el botón Add (Añadir) en la ventana del grupo de datos para seleccionar (abrir) los
archivos Total Cost – Base Case.dat y Total Cost – More Resources-dat
y ponerlos disponibles para el análisis; después haga lo mismo para los dos archivos Per-
cent Rejected.dat. El Output Analyzer puede hacer la comparación que queremos a
través de Analyze >Compare Means (Analizar > Comparativo de medias). La pantalla 6-1 llena
la información para la función Compare Means (Comparativo de medias) (la parte gráfica
de la pantalla 6-1 también indica el grupo de datos como una ventana arriba y a la izquierda
detrás de otras). Note que, en el diálogo Compare Means, despejamos el cuadro de revisión
para Scale Display (Muestra a escala); dejarlo marcado pondría las muestras gráficas para las
dos comparaciones a la misma escala, lo que podría tener sentido si las unidades de medición
Pantalla 6-1. Uso de la característica Compare Means (Comparativo de medias) del Output Analyzer
276 Capítulo 6
fueran iguales para las dos comparaciones, pero en nuestro caso, una está en dólares y la otra
en porcentajes, así que ponerlas juntas en la misma escala no tendría sentido.
Primero añadimos los archivos de datos, un par para Total Cost y el segundo para Per-
cent Rejected, requiriendo la especificación para aquéllos de ambos escenarios (llamados
A y B en el cuadro de diálogo, ambos Lumped [Agrupados] de manera que las 110 réplicas
para cada escenario se encuentran “agrupadas” juntas para nuestro análisis), luego llenamos
un Title (Título) y aceptamos o cambiamos el Confidence Level (Nivel de confianza) para la
comparación. El grupo de botones de opciones para Paired-t Test (Prueba del par t) (la prede-
terminada) contra Two-Sample-t Test (Prueba de dos muestras t) se refiere a un tema de asigna-
ción de números aleatorios e independencia estadística, que abordaremos en la sección 12.4.1;
el enfoque Paired-t Test resulta más general y será el que usemos, a menos que hayamos seguido
pasos deliberados para hacer que los escenarios sean estadísticamente independientes (que no
fue así) o si intentamos mejorar la precisión al asignar los números aleatorios con cuidado (que
no hemos hecho aquí). Como se notó antes, despejamos el cuadro de revisión para Scale Dis-
play, pues en este caso las unidades son diferentes para las dos comparaciones.
Los resultados aparecen en la figura 6-3. El Output Analyzer hace la sustracción de medias
en la dirección A – B; puesto que llamamos A al caso base y B al escenario con más recursos, y el
segundo tendió a aumentar el Total Cost pero a disminuir el Percent Rejected, los signos
de las diferencias son los esperados. Para ver si éstas son diferencias estadísticamente significativas
(es decir, si tales diferencias se encuentran muy alejadas de cero para ser explicadas razonablemen-
te por el ruido aleatorio), el Output Analyzer da intervalos de confianza de 95% en las diferencias
esperadas; puesto que ambos intervalos excluyen al cero, concluimos que hay diferencias estadís-
ticamente significativas en ambas medidas del desempeño de resultados y que los recursos que se
incrementan en esta forma aumentan significativamente el Total Cost y disminuyen significa-
tivamente el Percent Rejected (los resultados de la prueba de hipótesis equivalente de dos
caras para una diferencia esperada de cero también se muestran en la parte baja de la ventana).
Los intervalos de confianza realmente son una mejor manera de expresar todo esto frente a las
pruebas de hipótesis, ya que contienen las conclusiones “no rechazar” o “rechazar” de las pruebas
(el intervalo contempla o excluye al cero), pero también cuantifican la magnitud de cualquier di-
ferencia estadísticamente significativa. Si el lector hizo tal comparación porque está considerando
implementar dicho cambio, ahora tiene una idea de cuál será el aumento en Total Cost y cuál
la disminución en Percent Rejected si aumenta los recursos de esta manera.
6.5 E
valuación de varios escenarios con el Process
Analyzer (PAN) (Analizador de procesos)
En la sección 6.4 definimos dos alternativas diferentes de configuraciones de sistema en tér-
minos de seis parámetros de entrada (capacidad del recurso Trunk Line y las variables New
Tech 1, New Tech 2, New Tech 3, New Tech All y New Sales), ejecutamos el
modelo en ambas configuraciones y llevamos a cabo un análisis estadístico para estar seguros
de que nos hallábamos esbozando las conclusiones correctas acerca de la diferencia entre los
dos escenarios en términos de dos medidas de desempeño de resultados en particular (Total
Cost y Percent Rejected). ¿Qué pasaría si el lector tuviera más (o quizá muchos más) de
dos escenarios que quisiera ejecutar y comparar? Se enfrentaría a dos cuestiones:
(1) Manejar la mecánica práctica de hacer que cambie el modelo para todos los escenarios
diferentes, lo que podría ser tedioso y laborioso si tiene muchos escenarios, y definir
que cada uno involucra muchos de los cambios de parámetros en el modelo. No olvide
además cambiar el nombre de cualquier archivo de resultados guardado, ya sea al edi-
tar el modelo o al cambiar los nombres de los archivos en el sistema operativo.
(2) Evaluar los resultados de una forma correcta para resolver cuáles escenarios difieren
significativamente de otros en relación a qué medidas de desempeño de resultados,
y cuáles otros podrían ser significativamente mejores o incluso el mejor entre todos
aquellos que considere.
Arena se vende junto con otra aplicación por separado llamada Process Analyzer (Anali-
zador de procesos o PAN, por su abreviatura en inglés) que facilita mucho su carga en el tema
(1) anterior y también proporciona soporte para el tema (2) para ayudarlo a evaluar sus resul-
tados de una forma estadísticamente válida y tomar decisiones responsables. PAN opera en los
archivos del programa Arena y normalmente tiene como extensión del nombre del archivo .p;
después de ejecutar un modelo, el archivo .p estará ahí o puede crearlo de Arena sin ejecutarlo
al revisar su modelo (Run > Check Model [Ejecutar > Revisar modelo] o con la tecla F4 o con el
botón ). Se inicia PAN como lo haría con cualquier aplicación, por ejemplo al navegar hacia
él a través del botón Start (Inicio) de Windows (predeterminado en el mismo lugar que Arena)
o desde dentro de Arena a través de Tools > Process Analyzer (Herramientas > Analizador de
procesos). De cualquier forma que lo haga, PAN se ejecutará por sí mismo en una ventana se-
parada de Arena (si es que tiene a Arena ejecutándose).
Un escenario para PAN es una combinación de un archivo (.p) del programa que existe en
algún lugar en su sistema, un conjunto de valores para los controles de entrada para ese archivo
del programa que el lector seleccione, un conjunto de respuestas de resultado para ese archivo del
programa que usted también elija, así como un Name (Nombre) descriptivo para el escenario. Un
proyecto PAN es una recopilación de tales escenarios y se puede grabar en un archivo PAN (exten-
sión .pan) para su uso posterior. Los archivos del programa (.p) definidos para diferentes escena-
278 Capítulo 6
rios pueden de hecho ser el mismo archivo de programa o pueden resultar de diferentes archivos
(.doe) del modelo de Arena, dependiendo de qué es lo que se quiera ejecutar y comparar. Como
veremos, se seleccionan los controles de entre las capacidades Variables y Resource de sus mode-
los y luego se seleccionan las respuestas de los resultados de los modelos (como producidos por
Arena) y las propias Variables que el lector tenga. Una vez que haya definido sus escenarios, PAN
ejecutará los que seleccione (puede seleccionarlos todos si lo desea), con los controles montados
en los valores que defina para cada escenario y entregará los resultados de las respuestas en una
tabla, junto con el reporte de los valores de los controles para cada escenario. Esto es equivalente
a ir y editar su modelo para los valores de los controles de cada escenario y después ejecutarlos de
forma individual desde el interior de Arena; por supuesto, realizar esto a través de PAN es mucho
más fácil y rápido y también apoya una comparación estadística válida entre los resultados. Para
hacer un uso eficaz de PAN, debería anticipar, conforme construya su modelo, qué parámetros de
entrada va a querer cambiar para definir diferentes escenarios y asegurarse de configurarlos como
Variables de Arena (o capacidades Resource) en su modelo, de manera que puedan seleccionarse
para convertirse en controles en un escenario PAN.
Después de iniciar PAN, cree un nuevo proyecto PAN a través de File > New (Archivo > Nue-
vo) (o Ctrl+N o ), o abra un archivo de proyecto guardado con anterioridad (extensión .pan)
a través de File > Open (Archivo > Abrir) (o Ctrl+O o ); en nuestro caso, PAN sólo tiene una
ventana de proyecto abierta a la vez, pero puede tener muchos ejemplos de PAN ejecutándose
simultáneamente. Para añadir una nueva línea de escenario al proyecto, haga doble clic en don-
de se indica para traer el cuado de diálogo Scenario Properties (Propiedades del escenario) en
donde puede darle al escenario un Name (elegimos Base Case para este escenario) y un Tool
Tip Text (Texto de pista de herramienta) y asociar un archivo de programa (.p) existente con este
escenario (use el botón Browse [Buscar] para navegar al archivo .p que desee). El modelo que usa-
remos para nuestros experimentos con PAN será el modelo 6-5, que es el mismo que el modelo 6-4
con excepción de que quitamos las entradas de Output File (Archivo de resultados) Total Cost
.dat y Percent Rejected.dat en el módulo de datos Statistic, ya que PAN puede por sí
mismo seguir el rastro de tales datos y escribirlos otra vez en nuestro propio archivo sólo sería
una pérdida de tiempo; todavía haremos 110 réplicas para cada escenario. Revisamos este mode-
lo para producir Model 06-05.p y seleccionamos eso para nuestro Program File (Archivo de
programa). Si el lector desea editar después estos elementos, sólo haga clic con el botón derecho
en la línea para el escenario y seleccione Scenario Properties (Propiedades de Escenario). Para
seleccionar los controles de este escenario, haga clic con el botón derecho en su línea (excepto
en el extremo izquierdo) o en la etiqueta de arriba Scenario Properties, o use la opción del menú
Insert > Controls (Insertar > Controles) y seleccione Insert Control (Insertar control) para abrir
el cuadro de diálogo que contiene un árbol expansible de controles posibles de entre los recursos
(Resources), variables del sistema (número y duración de las réplicas) y variables especificadas por
el usuario; hacer clic en el signo más en cualquier árbol lo expande para permitirle seleccionar
cualquier entrada con un doble clic en ella, lo que ocasiona que aparezca como un Control en la
fila del escenario. Para nuestros experimentos con este modelo, seleccionamos seis controles, uno
del Resource y los otros cinco de entre las variables especificadas por el usuario:
< Bajo Resources, la capacidad de Trunk Line; seleccione Integer (Integral) para el Data
Type (Tipo de datos) en la lista de sugerencias y después haga clic en OK (Aceptar).
< Bajo User Specified (Especificado por el usuario), cada uno de New Tech 1, New Tech
2, New Tech 3, New Tech All y New Sales, al seleccionar Integer para el Data
Type en cada caso.
Análisis estadístico de resultados de las simulaciones terminadas 279
Una vez que haya seleccionado todos los controles que desee, haga clic con el botón derecho
de nuevo en la fila o en la parte superior y seleccione Insert Response (Insertar respuesta) para
seleccionar su(s) respuesta(s) de la misma forma; seleccionamos dos Responses del grupo espe-
cificado por el usuario, Total Cost (al seleccionar dos decimales) y Percent Rejected
(Porcentaje de rechazo) (un decimal). Los valores de los controles se muestran como
los que tienen en el modelo como fue definido, pero (aquí radica el poder de PAN) el lector
puede cambiarlos para la ejecución de tal escenario sólo con editar sus valores en esta fila del
escenario en la ventana de proyecto PAN; para el escenario del caso base, dejamos los valores
de control como se encontraban en el modelo original (26 y los cinco ceros). Los valores de las
respuestas se hallan en blanco ya que aún no hemos ejecutado el escenario. La figura 6-4 mues-
tra el estado de la parte de la ventana del proyecto PAN después de que definimos este escenario
y guardamos el proyecto como Experiment 06-05.pan (escogimos “Experiment” ya que
éste es realmente un experimento completo en marcha, que incluso podría ser uno estadística-
mente diseñado aunque no está aquí; véase la sección 12.6).
Se podría repetir el proceso anterior para escenarios adicionales. Sin embargo, si son simila-
res a uno que ya haya definido, se puede duplicar (haga clic con el botón derecho en su número
de escenario a la izquierda y seleccione Duplicate Scenario(s) [Duplicar escenario(s)]), y enton-
ces sólo haga ediciones en el escenario duplicado.
Para definir un conjunto sensible de escenarios para este modelo, suponga que recibió una
orden superior que le da $1 300/semana más para gastar en recursos adicionales, los cuales debe
dedicar íntegramente a un único tipo de recurso. ¿A cuál de los seis recursos “de expansión”
asignaría el nuevo dinero? Dados los costos semanales de los recursos, usted podría obtener
13 líneas principales más ($98 cada una), o 4 más de cualquiera de las personas adicionales en
soporte técnico de un solo producto ($320 cada una), o 3 de las personas adicionales en soporte
técnico para todos los productos ($360 cada una), o 4 personas adicionales en ventas ($340
cada una). La figura 6-5 muestra el proyecto PAN lleno con los seis escenarios posibles, además
del escenario caso base en la parte de arriba.
Para ejecutar uno o todos los escenarios, seleccione sus filas al hacer clic en la columna más
hacia la izquierda de cada fila (Ctrl + clic para extender la selección o Shift + clic para seleccio-
nar un conjunto de líneas contiguas). Luego seleccione Run > Go (Ejecutar > Ir) (o la tecla de
función F5 o el botón ). La figura 6-6 muestra los resultados de ejecutar los siete escenarios;
la columna Responses (Respuestas) brinda un promedio de 110 réplicas de cada escenario. Al
observar la columna Total Cost, parece que lo mejor sería aumentar el personal de llamadas
280 Capítulo 6
Figura 6-5. El proyecto PAN Experiment 06-05.pan después de definir todos los escenarios
de ventas; al observar la columna Percent Rejected, es posible que lo mejor fuera agregar
más líneas principales.
Mientras que las conclusiones anteriores están basadas en más que sólo una réplica de cada
escenario (recuerde que configuramos el número de réplicas en el archivo del modelo a 110
por escenario, así que esto es lo que PAN ejecuta, pues no lo anulamos a través de Num Reps
[Número de réplicas] en el System Controls [Controles del sistema]), sería mucho mejor tener
alguna idea de su validación estadística. Para investigar esto en la medida Total Cost, selec-
cione esa columna (haga clic en la etiqueta Responses [Respuestas] sobre la celda Total Cost
arriba para seleccionar esta columna de resultados) y luego Insert > Chart [Insertar > Gráfico]
(o ) o haga clic con el botón derecho en esta columna y seleccione Insert Chart [Insertar
gráfico]). Hay muchas opciones aquí, así que sólo lo guiaremos a través de una de ellas y le de-
jaremos explorar las otras por usted mismo, con el auxilio de Help (Ayuda). Debajo del Chart
Type (Tipo de gráfico), seleccione Box and Whisker (Caja y Dispersión), haga clic en Next
(Siguiente), asegúrese que Total Cost se encuentre seleccionado bajo Use these Responses
(Utilizar estas respuestas) y acepte lo predeterminado en la ventana Next (Siguiente) (tercera).
En la última ventana (la cuarta), seleccione la caja Identify Best Scenarios (Identificar el mejor
escenario), luego seleccione “Smaller is Best (el menor es el mejor)” e introduzca 0 para la Error
Tolerance (Tolerancia al error) (anulando lo que está predeterminado). Entonces haga clic en
“Show best scenarios” (Mostrar el mejor escenario) y observe lo que aparece en la ventana
debajo de ese botón; haga clic en Finish (Terminar) para obtener la gráfica. Por último, repita
todo lo anterior para la columna Percent Rejected para producir una segunda gráfica
Box and Whisker (Caja y Dispersión) para esos valores.
En la parte baja de la ventana PAN, se verá algo como lo que aparece en la figura 6-7; si
quiere cambiar el tamaño de las gráficas para hacerlas más grandes, selecciónelas y arrastre
las esquinas que las rodean. Si hace clic con el botón derecho en una gráfica, seleccione Chart
Options (Opciones de gráfica), y después el tabulador Data (Datos); ahí puede ver, para cada
escenario, resultados numéricos detrás de las medias que están en la tabla, como el mínimo y
máximo entre las réplicas, la mitad de los intervalos de confianza a 95% y los valores bajo y alto
que se encuentran en los límites de los intervalos de confianza. En la gráfica misma, las gráficas
de caja vertical indican 95% de los intervalos de confianza en los valores esperados para cada
alternativa de escenario, y los coloreados en rojo están determinados a ser significativamente
mejores (más pequeños) que aquellos coloreados en azul (circulamos las cajas para que así
pueda ver cuál es cuál en éste). Con más precisión, lo que esto significa es que los escenarios
“rojos” de un subconjunto de escenarios tienen 95% de probabilidades de contener el mejor
escenario verdadero en términos del valor esperado verdadero (y desconocido) de esa respuesta.
Si hubiéramos escogido una Error Tolerance (Tolerancia al error) mayor a 0, el subconjunto
“rojo” contendrá el mejor escenario o uno dentro de la mejor Error Tolerance (Tolerancia al
error), con 95% de confianza. Recuerde que estas conclusiones se basan en el número de répli-
cas que usted especificó para cada escenario (en nuestro caso, especificamos 110 réplicas para
cada escenario, pero pudimos haber especificado números diferentes de réplicas para diferentes
escenarios); si se quiere disminuir el subconjunto seleccionado (rojo), se podría aumentar el nú-
mero de réplicas para los escenarios. También se podría disminuir el subconjunto seleccionado
(rojo) al especificar la Error Tolerance (Tolerancia al error), para que sea un número positivo
que represente una cantidad suficientemente pequeña para que no haya que preocuparse si el
o los escenarios seleccionados son de hecho inferiores al mejor verdadero para casi toda esta
cantidad; así una Error Tolerance (Tolerancia al error) positiva puede reducir el número de
escenarios seleccionados con el riesgo de estar fuera por muy poco. Este procedimiento de
selección se basa firmemente en la sólida teoría estadística desarrollada por Nelson, Swann,
Goldsman y Song (2001).
Así que dependiendo de si el lector considera Total Cost o Percent Rejected como
la respuesta más importante, ahora tiene una indicación de cuál de estos seis escenarios (siete,
si se incluye el caso base) pudiera ser mejor. Es difícil pensar en alguna forma sensible de com-
binar estas dos respuestas en una con la cual optimizar. ¿No sería agradable si, por ejemplo,
pudiéramos buscar minimizar el Total Cost mientras se mantiene el Percent Rejected
en no más de cinco aproximadamente? Siga avanzando (a la sección 6.6).
Pero ¿adónde ir desde aquí? Ésta tampoco es una pregunta fácil de responder, por decir lo
menos. Muchas personas han investigado en estos temas durante muchos años y han desarro-
llado una variedad de métodos para enfocar tal problema. Arena viene con un paquete que se
llama OptQuest®, de OptTek Systems Inc., que usa la heurística conocida como búsqueda tabú
y búsqueda dispersa (además de otros métodos) para desplazarse en el espacio de control de
entradas de forma inteligente y tratar de converger rápida y confiablemente en un punto ópti-
mo. OptQuest, es, en cierta forma, similar a PAN en que “se hace cargo” de la ejecución de su
modelo Arena; la diferencia es que más que confiar en el usuario para especificar qué escenarios
específicos simular, OptQuest decide por sí mismo cuáles considerar en un modo iterativo que
con optimismo dirija a algo cerca de una combinación óptima de valores de control de entra-
da. Para información detallada de cómo funciona OptQuest con Arena, véase Help > Product
Manuals > Arena OptQuest User’s Guide (Ayuda > Manuales del producto > Guía del usuario
OptQuest de Arena).
Para ejecutar OptQuest para Arena, primero active la ventana de Arena del modelo que le
interese. Básicamente nosotros usaremos el modelo 6-5, excepto que OptQuest requiere que se
especifique una Run Length (Distancia de Ejecución) en Run > Setup > Replication Parameters
(Ejecutar > Fijar > Parámetros de replicación), así que introdujimos 1 000 horas, que nunca
serán alcanzadas ya que mantenemos nuestra regla de detención de sensibilidad del modelo,
la cual prácticamente detendrá casi siempre la réplica antes del tiempo 1 000 horas. Nosotros
llamamos al resultado modelo 6-6. Después seleccione Tools > OptQuest for Arena (Herra-
mientas > OptQuest para Arena) para abrir la ventana de aplicación de OptQuest, luego New
Optimization (Nueva optimización).
OptQuest se toma un momento para examinar su modelo en busca de Controles (inclu-
yendo las capacidades de recursos y las variables de Arena que el lector definió) y Respuestas
(considerando también los resultados de costos incluidos en Arena y todos los resultados que
usted definió) y presentarlos en un árbol a la izquierda que se expande y contrae. Éstos son los
parámetros de entrada que usted puede escoger para permitir a OptQuest cambiar conforme
los busque; en programación matemática o lenguaje de optimización, éstas son las variables de
elección o variables de decisión y nosotros buscamos una combinación que optimice (minimice
o maximice) un objetivo que se elegirá después de obtener los resultados de la simulación. Co-
mience al hacer clic en la palabra Controls (Controles) en el árbol de la izquierda (o la opción
de menú View > Controls [Ver > Controles]), para mostrar una lista de todos los Resources
(Recursos) y User Specified variables (variables especificadas por el usuario) y revise las cajas en
la columna Included (Incluido) para Trunk Line, New Sales, New Tech 1, New Tech
2, New Tech 3 y New Tech All. En cada una de estas líneas Included Control (Control
Incluido), haga doble clic para abrir una ventana donde especifique Lower Bound (Límite in-
ferior), Suggested Value (Valor sugerido) (esto es, los valores que comienzan como se anali-
zó anteriormente), Upper Bound (Límite superior) adecuados y quizá una breve Description
(Descripción); también revise el Type (Tipo) que sea apropiado, que para todos nuestros con-
troles será Integer (Integral). Luego puede hacer clic en el encabezado de la columna Included
y su flecha para recopilar los controles que seleccionó arriba o abajo. Note que, puesto que el
conjunto de todo el nuevo personal contratado no debe ser mayor a 15, ciertamente cada uno
debe ser menor a 15, estableciendo esos Upper (High) Bounds (Límites de arriba [Altos]). La
figura 6-8 muestra la ventana OptQuest con toda la sección Controls (Controles) visible.
284 Capítulo 6
La entrada Options (Opciones) del árbol de la izquierda (o View > Options [Ver > Opcio-
nes]) proporciona varias formas de controlar la forma en la que OptQuest decide detener la
búsqueda, una tolerancia con respecto a dos valores objetivo por igual, control en las réplicas
por escenario y un lugar para un registro completo de qué considera OptQuest durante su eje-
cución. Puesto que sabemos que este modelo tiene una variación considerable entre las réplicas,
debajo de Replications (Réplicas) por simulación, especifique un mínimo de 10 y un máximo de
110 réplicas. Por otro lado aceptaremos las opciones predeterminadas y en particular la opción
Automatic Stop (Detención automática), lo que significa que OptQuest dejará de buscar cuan-
do no se vea una mejoría significativa de 100 escenarios diferentes en una fila.
De la ventana Options (Opciones), el lector podría hacer clic en el botón Optimize (Optimizar)
para iniciar OptQuest o, de forma alternada, hacer clic en el botón Start Optimization (Empezar
optimización) ( ) en la barra de herramientas, o seleccionar Run > Start Optimization (Ejecutar
> Empezar optimización) (o la tecla F5). Esto hace que OptQuest simule su modelo en el punto de
inicio que se elija y después decida por sí mismo cómo buscar mejor, a través de la región factible
del espacio de seis dimensiones, una combinación de controles de entrada que minimice Total
Cost mientras satisface ambas restricciones. Conforme hace esto, se puede observar su progreso
al seleccionar Optimization (Optimización) en el árbol de la izquierda, para ver el mejor valor
objetivo hasta el momento, el valor objetivo actual y cuántos escenarios (lo que OptQuest llama
“simulaciones”) se han ejecutado. También se pueden observar los controles mejores y actuales y
aquellos que las restricciones están cumpliendo durante la búsqueda (o violando ocasionalmen-
te). La gráfica de abajo plasma el mejor objetivo (el menor para nosotros) encontrado hasta el
momento, como una función de cuántas “simulaciones” (escenarios) han sido probadas. La vista
final de esta información aparece en la figura 6-12, que muestra el mejor conjunto de controles en-
contrado y la función objetivo asociada. Esta gráfica es típica, con grandes mejoras (reducciones)
hechas anteriormente (el fenómeno de las oportunidades más asequibles), seguida por mejoras
más difíciles y eventualmente una disminución. OptQuest evaluó 429 escenarios (0.03% de los
1 356 600 posibles), encontrando de entre ellos que el mejor era el escenario número 329 que con-
sideró (y entonces no hubo mejoras para 100 escenarios más, pues es la regla de detención prede-
terminada). El mejor Total Cost fue 20 368.83, un 15% menor que el punto de inicio; la forma
de lograr eso sería quedarse con 26 líneas principales, contratar dos nuevas personas de ventas
y una de soporte técnico para el tipo 1, tipo 3 y de todos los tipos. Se puede revisar el archivo de
registro creado OptQuest (véase la ventana Options para observar su nombre y ubicación en su
sistema) para observar la historia completa de su viaje a través de un espacio de seis. También, al
hacer clic en Best Solutions (Mejores soluciones) en el árbol de la izquierda obtiene una ventana
que da no sólo las mejores soluciones, sino que las clasifica en orden, así puede considerar otros
buenos escenarios en caso que el mejor sea problemático por algunas razones externas (por ejem-
plo, políticas de la empresa). El lector puede guardar todo esto en un archivo .opt, para abrirlo
después desde OptQuest, a través de File > Save (Archivo > Guardar) o (nosotros guardamos
éste como el archivo Optimum Seeking 06-06.opt).
Análisis estadístico de resultados de las simulaciones terminadas 287
Ahora OptQuest no puede garantizar de manera absoluta que encontró el óptimo exacto
en cada caso; después de todo, éste es un problema muy desafiante, no sólo porque hay tantas
posibilidades para examinar, sino también porque el objetivo (la medida de desempeño del
resultado del modelo de simulación a ser optimizado) no se puede medir con certeza. Sin em-
bargo, en la mayoría de los casos, OptQuest hará un trabajo mucho mejor que nosotros al sólo
entretenerse y probar opciones, así que en general tiene un considerable valor. Para tener ante-
cedentes de lo que está haciendo OptQuest, véase Glover, Kelly y Laguna (1999), por ejemplo.
6.8 Ejercicios
6-1 En el ejercicio 5-1 compare estadísticamente sus resultados con los que obtuvimos antes;
haga esta comparación informalmente al hacer intervalos de confianza a 95% con base en 50
réplicas para ambos modelos y observe si se traslapan. Como medidas de desempeño, emplee el
tiempo promedio de espera en la cola, longitud promedio en la cola y utilización del servidor.
6-2 Usando el modelo del ejercicio 5-2, cambie el tiempo de proceso para el segundo paso
en la máquina 1 a TRIA(6.7, 9.1, 13.6). Ejecute la simulación por 20 000 minutos y compare
los resultados con respecto a las mismas tres medidas de desempeño de resultados. Realice una
comparación estadística “informal” al hacer 20 réplicas de ambas versiones del modelo, for-
mando intervalos de confianza de 95% y observando la relación entre éstos.
6-3 En el ejercicio 5-3, ¿alrededor de cuántas réplicas se requerirían para la mitad de un in-
tervalo de confianza de 95%, para el tiempo de ciclo promedio esperado para ambos arreglos
menores a un minuto? (No necesita hacer esto, sólo realice algo para calcular el número aproxi-
mado de réplicas que se podrían requerir.)
6-4 La instalación del ejercicio 5-4 se localiza en un área urbana congestionada en donde la
tierra es cara y se le ha pedido que decida cuánto espacio debe planearse para la cola de camio-
nes para descarga; dirija esta pregunta (permanezca atento a temas estadísticos).
6-5 En el ejercicio 5-5 suponga que puede contratar a una persona más y que ésta puede
ser un segundo operador (idéntico) en cualquiera de las cuatro ubicaciones. ¿Cuál debería de
ser? Emplee PAN con cinco réplicas por escenario y seleccione la mejor en términos del menor
tiempo promedio en el sistema. En retrospectiva, ¿su opción es sorprendente? ¿Qué tan crítico
es obtener esta opción correcta?
Ahora suponga que puede contratar hasta cinco personas más y ubicarlas de cualquier
forma que quiera a los cuatro operadores existentes, incluyendo ubicar a los cinco nuevos en un
solo operador. ¿Cuál es la mejor opción por escoger? Emplee OptQuest para buscar la óptima
ubicación de este máximo de cinco personas más, con el objetivo de minimizar el tiempo pro-
medio en el sistema.
6-6 En el ejercicio 4-1 suponga que 7% de los clientes que arriban son clasificados justo des-
pués de llegar a ser voladores frecuentes. Ejecute su simulación por cinco réplicas (cinco días).
Suponga que todos los tiempos son iguales a los anteriores y observe estadísticas en el tiempo
promedio en el sistema por tipo de cliente (voladores frecuentes y no frecuentes) bajo cada uno
de los siguientes escenarios:
a) Asigne cuatro de los agentes actuales a servir sólo a voladores no frecuentes y el quinto
a atender sólo a voladores frecuentes.
Análisis estadístico de resultados de las simulaciones terminadas 289
c) Cambie su modelo de manera que cualquier agente pueda atender a cualquier cliente,
pero dando prioridad siempre a voladores frecuentes.
¿Cuál de los tres escenarios anteriores piensa usted que es el “mejor” para los voladores
frecuentes? ¿Qué hay de 93% de clientes que no lo son? Viendo esto como una simulación ter-
minada, dirija estas preguntas de comparación en una forma estadísticamente válida.
6-8 En el ejercicio 5-14, haga 30 réplicas y estime la diferencia esperada entre éstas y el mo-
delo del ejercicio 5-13 (con base en el tiempo del sistema por cliente). Esté seguro de usar una
técnica estadística formal adecuada.
6-9 En el ejercicio 5-15, haga 30 réplicas y estime la diferencia esperada entre este modelo
y el del ejercicio 5-14 (con base en el tiempo del sistema por cliente), empleando una técnica
estadística formal adecuada.
6-10 Para el sistema de inventario del modelo 5-4, haga una comparación PAN para investi-
gar el costo total promedio que resulta de cada uno de los siguientes pares (s, S):
Ejecute 50 réplicas para cada caso y escoja la mejor (de menor costo) entre éstas en una forma es-
tadísticamente válida. Dicha comparación proviene de la sección 1.5.5 de Law y Kelton (2000).
6-11 Para el sistema de inventario del modelo 5-4, use OptQuest para buscar el mejor con-
junto (minimización del costo total) para (s, S). Haga que s se ejecute entre 1 y 99 (por una
vez) y que S se ejecute entre 2 y 100 (por una vez); recuerde que s y S deben ser enteros y que
debemos tener s < S. Saque sus propios juicios acerca del tiempo de ejecución, número de
réplicas, etc..
6-12 En el ejercicio 6-11, investigue si tomar un inventario al inicio de cada día es necesaria-
mente la mejor política al añadir el intervalo de evaluación de inventario (actualmente confi-
gurado en un día) para la combinación variable de búsqueda del óptimo y permita a OptQuest
variarla (continuamente) entre medio día y cinco días, así como simultáneamente permitiendo
a s y S variar como en el ejercicio 6-11. Si usa Model 05-04.doe como una base, tendrá que
cambiar el Evaluation Interval (Intervalo de evaluación) de una Expression (Ex-
presión) a una Variable para que OptQuest pueda llegar hasta él.
290 Capítulo 6
6-13 Aplique OptQuest en los seis valores de (s, S) del ejercicio 5-20. Haga que cada rango
de s se localice entre 1 y 99 (por una vez) y cada rango de S entre 2 y 100 (por una vez); por
supuesto s y S deben ser interos y para cada uno de los tres artículos en el inventario debemos
tener s < S.
6-14 Aplique OptQuest a los seis valores de (s, S) del ejercicio 5-21, con los mismos rangos
que en el ejercicio 6-13. Compare sus resultados con los del ejercicio 6-13 y explíquelos en tér-
minos de los incentivos ofrecidos por el proveedor en esta diferente estructura de costos.
6-15 En el ejercicio 4-22, suponga que pudiera contratar una persona más y ese empleado pu-
diera asignarse tanto al registro manual, automático o a seguridad. ¿Dónde sería mejor usada
esta persona adicional? Como un criterio general de “bondad” de un sistema, use el tiempo pro-
medio total en el sistema de todos los tipos de pasajeros combinados. Configure una ejecución
PAN y decida acerca del número de réplicas necesarias para llegar a una conclusión confiable.
6-16 En el ejercicio 6-15, suponga que pudiera contratar un total de cinco personas más (en
lugar de sólo una) para ubicarlas de cualquier forma en el personal existente en el registro
manual, automático o en seguridad. No se puede reducir el personal de ninguna forma de los
niveles que aparecen en el ejercicio 4-22. Usando el tiempo promedio total en el sistema de to-
dos los tipos de pasajeros combinados, ¿cuál sería el mejor despliegue de estas cinco personas
adicionales? ¿Usaría siempre a los cinco? Configure una ejecución OptQuest y decida acerca del
tiempo de ejecución y los números de réplicas.
6-17 En el ejercicio 4-22 (con personal fijo en los niveles originales), la aerolínea notó que
muchas de las personas que optan por el registro manual realmente no necesitan los servicios
extras y podrían haber usado el registro automático. En lugar de 35 y 50% originales que van
al manual y al automático, respectivamente, suponga que a través de más “aliento” efectivo de
las personas con los uniformes rojos y voces altas, puede llegar a ser 10 y 75%. (Probablemente
hay 10% de pasajeros que genuinamente necesitan los servicios adicionales del registro manual.)
¿Cómo podría este cambio en las actitudes (o quizá valentía) de los pasajeros afectar el tiempo
promedio total en el sistema de aquéllos? Base sus comparaciones en 200 réplicas del modelo
en cada configuración.
6-18 El ejercicio 2-8 describe un cambio en el modelo 3-1. Lleve a cabo un estudio estadísti-
camente válido para medir el efecto de este cambio en el tiempo promedio de espera en la cola
y en la utilización del servidor. Tome sus propias decisiones acerca de los números de réplicas
para llegar a conclusiones significativas y razonablemente precisas.
6-19 Recuerde los modelos 3-2, 3-3, 3-4 y 3-5 del capítulo 3, comparando las operaciones se-
riales especializadas con las paralelas generalizadas en ambientes tanto de tiempos de servicio
de varianza alta como baja (de hecho sin varianza). Apareció en la tabla 3-1 que el ordenamien-
to de paralelas generalizadas proporciona un mejor servicio, aunque la mejora fue mucho más
fuerte en el ambiente de tiempo de servicio de varianza alta. Escoja medidas de desempeño de
resultados relevantes y haga comparaciones estadísticas válidas para ver si lo que parece ser
cierto en la tabla 3-1 (de una sola ejecución) es estadísticamente válido.
Análisis estadístico de resultados de las simulaciones terminadas 291
6-20 Recuerde el ejercicio 3-13, que modificó el modelo 3-3 para añadir 18% en los tiempos
de tarea individual en la configuración paralela de trabajo integrado generalizado del modelo
3-3. Elija medidas de desempeño de resultado relevantes y realice una comparación estadística
válida para ver si el modelo del ejercicio 3-13 difiere significativamente de la configuración serial
especializada original del modelo 3-2. En otras palabras, si tuvo que aguantar este aumento
de 18% en los tiempos de proceso de tarea, ¿se seguiría moviendo de la configuración serial de
trabajo especializado a la configuración paralela de trabajo generalizado?
6-21 Para mejorar el modelo de reparación de la máquina del ejercicio 5-22, haga un análisis
estadístico válido que defienda su elección del número de técnicos de reparación a contratar
con la finalidad de minimizar el costo promedio total. Tome su propia decisión en número de
réplicas y modifíquelo si es necesario.
6-22 Use Arena para simular el problema del voceador de la sección 2.7.1. Considere sólo el
caso q = 140 y ejecute por 30 días para obtener una ganancia promedio diaria y un intervalo de
confianza de 95%, así como la proporción de días en que ocurre una pérdida.
6-23 Generalice su modelo de Arena del ejercicio 6-22 para considerar los cinco valores de q
en la sección 2.7.1, usando la misma realización de demanda diaria para cada valor de q.
6-24 Reejecute la búsqueda de OptQuest de la sección 6.6, excepto comenzando con el mode-
lo caso base (26 líneas principales y sin empleados nuevos). También, vuelva a ejecutar la bús-
queda comenzando con el escenario 6 del experimento PAN de la figura 6-6 (que casi siempre
es factible [pero no mucho] con respecto a Percent Rejected). Comente el efecto de los
diferentes puntos de inicio en las búsquedas de optimización.
CAPÍTULO 7
Muchos de los elementos esenciales de modelar con Arena se cubrieron en los capítulos 3, 4 y
5, incluyendo el uso básico de algunos módulos de los paneles Basic Process (Proceso básico)
y Advanced Process (Proceso avanzado), el control del flujo de entidades, Resource Schedules
(Programas del recurso) y States (Estados), Sets (Conjuntos), Variables (Variables), Expres-
sions (Expresiones), Stations (Estaciones), Transfers (Transferencias) y la mejora de la anima-
ción. En este capítulo, desarrollaremos varios conceptos que le permiten un modelado más
detallado. Como antes, ilustraremos los tópicos de forma concreta por medio de un ejemplo
bastante elaborado. Primero iniciaremos con un nuevo ejemplo descrito en la sección 7.1; ex-
presarlo en Arena requiere el concepto de Sequences (Secuencias) dependientes de la entidad,
que se analiza en la sección 7.1.1. Después, en la sección 7.1.2, abordamos el tema general de
cómo funciona el modelado de un sistema, el nivel de detalle apropiado para el proyecto y la ne-
cesidad de poner atención a los requerimientos y disponibilidad de los datos. La parte de datos
que se necesita para el modelo se construye en la sección 7.1.3 y el modelo lógico en la sección
7.1.4. En la sección 7.1.5 desarrollamos una animación, al incluir el análisis de importar dibujos
CAD existentes para ese bosquejo. Concluimos esta sección con un análisis que verifique que la
representación de un modelo en Arena en realidad hace lo que el lector desea.
Continuando con nuestro tema de observar todos los aspectos de los proyectos de simula-
ción a través de un estudio, reanudamos el tópico del análisis estadístico de los datos de resul-
tado en la sección 7.2, pero esta vez es para simulaciones de estado estable, al usar el modelo
de la sección 7.1.
Para cuando lea y digiera el material de este capítulo, el lector tendrá una muy buena idea
de cómo modelar con un detalle considerable. También se encontrará en la posición de esbozar
conclusiones estadísticamente válidas acerca del desempeño de los sistemas conforme operan
en el largo plazo.
A2 A
E LD FU
ER
C
RO
NT
DE
A1 ER
A
E LD FU NT
R O
A3
C DE
LD
O C E
R
NT
DE O
R
NT
DE
A DA4
FU
ER E L
C
Figura 7-1. El diseño de un pequeño sistema de fabricación
Parte 3. Las partes entran por la izquierda, salen por la derecha y sólo se mueven conforme a las
manecillas del reloj a través del sistema. Por ahora, también supondremos que el tiempo para
moverse entre cualquier par de celdas es de dos minutos, a pesar de la distancia (arreglaremos
esto después). Queremos recopilar las estadísticas en cuanto a utilización del recurso, tiempo
y número en la cola, así como, tiempo de ciclo (tiempo en el sistema, desde la entrada hasta la
salida) por tipo de parte. Inicialmente, ejecutaremos nuestra simulación durante 32 horas.
Tipo de parte Celda/Tiempo Celda /Tiempo Celda /Tiempo Celda /Tiempo Celda /Tiempo
1 1 2 3 4
6, 8, 10 5, 8, 10 15, 20, 25 8, 12, 16
2 1 2 4 2 3
11, 13, 15 4, 6, 8 15, 18, 21 6, 9, 12 27, 33, 39
3 2 1 3
7, 9, 11 7, 10, 13 18, 23, 28
Modelado intermedio y análisis estadístico de estado estable 295
la simulación. Si usamos la opción Connect en este nuevo modelo, tendríamos que incluir un
número de módulos Decide (Decidir) para dirigir las partes a la siguiente estación correcta en
la secuencia seguida por ambos módulos Route para modelar el tiempo de transferencia de dos
minutos y permitir la animación de los movimientos de las partes. Como puede esperarse, existe
un concepto de Arena, secuencias, que permite un modelado fácil del flujo de las entidades a
través del sistema mientras permite el tiempo de transferencia de las partes y su animación.
Muchos sistemas se caracterizan por entidades que siguen caminos predeterminados pero
diferentes a través del sistema. La mayoría de los sistemas de fabricación tienen planes de partes
o procesos que especifican una lista de operaciones que cada parte debe completar antes de salir
del sistema. Muchos sistemas de servicio poseen tipos similares de requerimientos. Por ejemplo,
un modelo de tráfico de pasajeros en un aeropuerto puede necesitar diferentes caminos a través
del mismo, dependiendo de si los pasajeros deben hacer revisar sus maletas o sólo tienen equi-
paje de mano, así como si abordan vuelos nacionales o internacionales.
Arena puede enviar entidades a través del sistema de forma automática de acuerdo con una
secuencia de visitas a la estación. El módulo de datos Sequence, en el panel Advanced Transfer
(Transferencia avanzada), nos permite definir una lista ordenada de Stations (Estaciones) que
puede incluir tareas de atributos o variables en cada estación. Para dirigir a una entidad para
que siga su patrón de visitas a la estación, asignamos la secuencia a la entidad (al emplear un atri-
buto de secuencia ya incluido que se describe más adelante) y usamos la opción “By Sequence”
(“Por secuencia”) en el módulo Route cuando transferimos la entidad a su siguiente destino.
Conforme la entidad toma su camino con su secuencia, Arena asumirá toda la responsabili-
dad necesaria para seguir el rastro de dónde se encuentra la entidad y adónde irá después. Esto
se logra a través del uso de tres atributos de Arena especiales y definidos de forma automática:
Entity.Station (o M), Entity.Sequence (o NS) y Entity.JobStep (o IS). Cada entidad tiene estos
tres atributos, con los valores predeterminados para entidades creadas recientemente que sean
0. El atributo Entity.Station contiene la estación actual de la entidad o la estación a la cual la
entidad está siendo transferida actualmente. El atributo Entity.Sequence contiene la secuencia
que seguirá la entidad, si es que la hay; se debe asignar esto a cada entidad que sea transferida
a través de una secuencia. El atributo Entity.JobStep especifica la posición de la entidad dentro
de la secuencia, así que normalmente comienza en 0 y después se incrementa en 1 conforme la
entidad se mueve a cada nueva estación de su secuencia.
Primero definimos y nombramos la lista de estaciones que cada tipo de entidad va a visitar
(por tipo de parte, en nuestro ejemplo) usando el módulo de datos Sequence en el panel Ad-
vanced Transfer. Después, cuando hagamos que una nueva parte llegue al sistema, asociamos
una Sequence específica con esa entidad asignando el nombre de la secuencia al atributo Entity.
Sequence de la entidad, NS.1 Cuando la entidad se encuentre lista para transferirse a la siguiente
estación de su secuencia, seleccionamos la opción By Sequence en el campo Destination Type
(Tipo de destino) del módulo que usemos para transferir la entidad a la siguiente estación. En este
punto durante la ejecución, Arena primero aumenta el atributo Entity.JobStep (IS) en 1. Después
recupera la estación de destino de Sequence con base en los valores actuales para los atributos
Entity.Sequence y Entity.JobStep. Cualquier tarea adicional se realiza (como esté definida en
Sequence) y el atributo Station de la entidad (Entity.Station) se configura a la estación de des-
tino. Por último, Arena transfiere la entidad a esa estación.
1
Arena usa M, NS e IS de forma interna como nombres para estos atributos, pero proporciona los alias Entity.
Station, Entity.Sequence y Entity.JobStep en la lista de despliegue.
296 Capítulo 7
Por lo general, una entidad seguirá una secuencia hasta su conclusión y después saldrá del
modelo. Sin embargo, esto no es un requisito. El atributo Entity.JobStep aumenta sólo cuando
la entidad se transfiere al usar la opción By Sequence. El lector puede suspender temporal-
mente la transferencia por la secuencia, transferir la entidad directamente a otra estación y
después volver a meter la secuencia. Esto podría ser útil si se requiere que algunas de las partes
sean revisadas en algún punto del proceso. Una vez completada la revisión, podrían volver a
entrar a la secuencia normal.
También se pueden reasignar los atributos de la secuencia en cualquier momento. Por ejem-
plo, podría manejarse una falla de parte al asignar un nuevo atributo Entity.Sequence y volver
a configurar el atributo Entity.JobStep en 0. Esta nueva Sequence podría transferir la parte a
través de una serie de estaciones del área de revisión. Asimismo se puede avanzar o retroceder en
la secuencia al disminuir o aumentar el atributo Entity.JobStep. Sin embargo, se recomienda pre-
caución y estar seguro de cómo restaurar el atributo Entity.JobStep de forma correcta, recordan-
do que Arena primero lo aumentará y después buscará la estación de destino en la secuencia.
Como se indicó antes, las tareas de atributos y variables también se pueden hacer en cada
uno de los pasos de la secuencia. Por ejemplo, el lector podría cambiar la imagen de la entidad
o asignar un tiempo de proceso a un atributo definido por el usuario. Para nuestro pequeño mo-
delo de fabricación, usaremos esta opción para definir algunos de nuestros tiempos de proceso
que son específicos de la parte y de la estación.
estructura de datos que utilice. Aunque los modelos que desarrollaremos en este libro no son
tan complicados, siempre es aconsejable considerar sus requerimientos de datos antes de que
comience con el modelado.
Para nuestro pequeño sistema de fabricación, la estructura de datos afectará, en cierto
grado, nuestro diseño del modelo. Usaremos Sequences para controlar el flujo de las partes a
través del sistema y la característica de tarea opcional en el módulo de datos Sequence para
introducir atributos para los tiempos de proceso de las partes para todas las Celdas menos
para la Celda 1. Emplearemos una Expression para definir los tiempos de proceso de las
partes de la Celda 1. El tiempo de transferencia de la parte y el factor de 80% para el tiempo
requerido por la máquina nueva en la Celda 3 aprovechará el concepto de Variables. Aunque
normalmente no pensamos en Sets como una parte de nuestro diseño de datos, su uso puede
afectar el método del modelado. En este modelo, usaremos Sets, combinados con un índice
definido por el usuario, para asegurarnos de asociar la secuencia y la imagen correctas con
cada tipo de parte.
Primero, introduciremos los módulos de datos como lo analizamos antes. Después, la parte
principal del modelo, que requerirá varios módulos nuevos. A continuación, animaremos el
modelo usando un CAD u otro dibujo como un punto de inicio. Finalmente, analizaremos
brevemente el concepto de la verificación del modelo. En este momento el lector debería estar
bastante familiarizado con la apertura y el llenado de los cuadros de diálogo de Arena, así que
no insistiremos en detalles mundanos de cómo introducir la información en Arena. En el caso
de los módulos y conceptos que le presentamos en capítulos anteriores, sólo indicaremos los
datos que deberá introducir. Para ver la “gran imagen” de hacia dónde nos dirigimos, puede
echarse un vistazo a la figura 7-5 que muestra el modelo completo.
A continuación, definiremos la expresión para los tiempos del proceso de las partes de la
Celda 1, al usar el módulo de datos Expression del panel Advanced Process. La expresión que
queremos se llamará Cell 1 Times y contendrá las distribuciones del tiempo de proceso de
las partes para los tres componentes de la Celda 1. Podríamos sólo haber introducido fácilmen-
te estos módulos Sequences previos, pero elegimos usar una expresión de forma que se puedan
ver varias formas diferentes de asignar los tiempos del proceso. Tenemos tres diferentes partes
que usan la Celda 1, así que necesitamos una expresión ordenada con tres filas, una para cada
tipo de parte. La pantalla 7-2 indica los datos para este módulo.
Después, usaremos el módulo de datos Variable del panel Basic Process para definir el factor
de velocidad de la máquina para la Celda 3 y el tiempo de transferencia. Antes de definir nuestra
variable Factor, hicimos la observación y el supuesto siguientes. Los tiempos de proceso de las
partes para la Celda 3, introducidos en el módulo de datos Sequence, son para la vieja máquina.
Supondremos que la máquina nueva será referenciada como 1 y que la vieja lo será como 2. De
Expression (Expresión)
Name (Nombre) Cell 1 Times (Tiempos de la Celda 1)
Rows (Filas) 3
Expression Values (Valores de la expresión)
Expression Value (Valor de la expresión) TRIA(6, 8, 10)
Expression Value (Valor de la expresión) TRIA(11, 13, 15)
Expression Value (Valor de la expresión) TRIA(7, 10, 13)
esta manera, el valor del primer factor es 0.8 (para la máquina nueva) y el del segundo factor es
1.0 (para la vieja). El valor del tiempo de transferencia (que no tiene que ser una selección) simple-
mente se introdujo como 2. Esto nos permite cambiar tal valor en un solo lugar en un momento
posterior. Si pensamos que podríamos cambiar esto a una distribución, lo habríamos introducido
como una Expression en lugar de una Variable. La pantalla 7-3 indica las entradas requeridas.
Usaremos el módulo de datos Set del panel Basic Process para formar conjuntos para nues-
tras máquinas de la Celda 3, imágenes de partes y tipos de entidades. El primero es un conjunto
Resource, Cell 3 Machines, que contiene dos miembros: Cell 3 New y Cell 3 Old.
Nuestro conjunto Entity Picture (Imagen de entidad) se llama Part Pictures y contiene tres
miembros: Picture.Part 1, Picture.Part 2 y Picture.Part 3. Por último, nuestro
conjunto Entity Type (Tipo de entidad) se llama Entity Types y contiene tres miembros:
Part 1, Part 2 y Part 3.
En tanto que estemos creando conjuntos, añadamos uno más para nuestra secuencia de
partes. Si el lector intenta usar el módulo de datos Set, rápidamente hallará que los tipos dis-
ponibles son Resource, Counter (Contador), Tally (Cuenta), Entity Type y Entity Picture. Este
problema se resuelve al emplear el módulo de datos Advanced Set (Conjunto avanzado) que se
encuentra en el panel Advanced Process. Este módulo enlista tres tipos: Queue (Cola), Storage
(Almacenamiento) y Other (Otro). El tipo Other es una opción de comodín que atrapa todo
que le permite formar conjuntos de casi cualquier objeto similar de Arena. Usaremos esta
opción para introducir nuestro conjunto llamado Part Sequences, que contiene tres miem-
bros: Part 1 Process Plan, Part 2 Process Plan y Part 3 Process Plan.
Antes de comenzar a colocar los módulos lógicos, abramos el cuadro de diálogo Run >
Setup y configuremos nuestra Replication Length (Duración de réplica) en 32 horas y nuestras
Base Time Units (Unidades de tiempo base) en minutos. También seleccionamos Edit > Entity
Pictures (Editar > Imágenes de entidad) para abrir la ventana Entity Picture Placement (Locali-
zación de imagen de entidad), en donde creamos tres diferentes imágenes, Picture.Part 1,
Picture.Part 2 y Picture.Part 3. En nuestro ejemplo, copiamos bolas azules, rojas
y verdes; les dimos un nuevo nombre y colocamos un objeto de texto con 1, 2 y 3, respectiva-
mente, para denotar los tres tipos diferentes de partes. Habiendo definido todos los módulos
de datos, ahora estaremos listos para colocar y rellenar los módulos para el modelo principal y
definir así las características lógicas del sistema.
cuatro módulos que se muestran en la figura 7-2. El módulo Create (Crear) usa una distribución
Random (Expo) con una media de 13 minutos para generar las llegadas de las partes.
En este punto, aún no hemos asociado una secuencia con cada entidad de llegada. Hacemos
esta asociación en el módulo Assign (Asignar) como se indica en la pantalla 7-4. Estas tareas sir-
ven para dos propósitos: determinan qué tipo de parte llega y definen un índice, Part Index,
para nuestros conjuntos que nos permitirá asociar la secuencia adecuada, el tipo de entidad y
la imagen para cada llegada. Primero determinamos el índice de parte, o tipo de parte, con una
distribución discreta. La distribución nos permite generar ciertos valores con probabilidades
dadas. En nuestro ejemplo, estos valores son los enteros 1, 2 y 3 con probabilidades de 26, 48 y
26%, respectivamente. Se introducen estos valores en pares acumulados de probabilidad y valor.
La probabilidad acumulada para el último valor (en nuestro caso, 2) debería ser 1.0. En general,
los valores no necesitan ser enteros, sino que pueden tomar cualquier valor, incluyendo números
negativos. Los valores del índice de partes de 1, 2 y 3 nos permiten no sólo referirnos al tipo de
parte sino que, en este caso, también nos dejan catalogar el conjunto definido con anterioridad
Part Sequences de forma que la secuencia adecuada se asocie con la parte. Para realizarlo
así, asignamos la secuencia adecuada al atributo automático de Arena Entity.Sequence al usar el
atributo Part Index como un índice dentro del conjunto Part Sequences.
También hay que asociar el tipo de entidad y la imagen adecuados para la parte recién
llegada. Hacemos esto en las dos últimas tareas al usar el atributo Part Index para catalo-
garlo dentro de los conjuntos relevantes. Recuerde que creamos el conjunto Entity Types
(que consiste en Part 1, Part 2 y Part 3). También definimos tres imágenes (Picture.
Part 1, Picture.Part 2 y Picture.Part 3) y las agrupamos en un conjunto llamado
Part Pictures. Se puede pensar en estos conjuntos como una variable de arreglo (de una
dimensión) con el índice siendo el atributo Part Index que acabamos de asignar. Esto es
cierto en tal caso porque tenemos una relación uno a uno entre el tipo de parte (Part Index)
y la secuencia, imagen y tipo de entidad. Un índice de 1 implica que Part 1 sigue la primera
secuencia, etc. (Tenga cuidado en los modelos futuros porque esto puede no ser siempre cierto.
Sólo es verdad en este caso porque definimos nuestra estructura de datos de tal forma que ob-
tendríamos esta relación uno a uno.)
En este caso, el módulo Assign completo determina el tipo de parte y después asigna la se-
cuencia, tipo de entidad e imagen adecuados. Note que fue esencial definir primero el valor de
Part Index en este módulo Assign, el cual desempeña múltiples tareas en el orden enlistado,
ya que el valor de Part Index determinado en el primer paso se usa en tareas posteriores.
Ahora estamos listos para enviar a nuestra parte a la primera estación de su secuencia.
Conseguiremos esto con el módulo Route (Ruta) del panel Advanced Transfer. Antes de
hacer esto, necesitamos decir a Arena en dónde reside en la actualidad nuestra entidad, o par-
te (su ubicación actual en la estación). Si el lector ha estado construyendo su propio modelo
junto con nosotros (y poniendo atención), puede haber notado el atributo llamado Entity.
Station en la lista de sugerencias del módulo Assign que acabamos de completar. (Regrese
y véalo si lo desea.) Puede sentirse tentado a añadir una tarea que defina la ubicación actual
de nuestra parte. Por desgracia, si emplea este enfoque, Arena le marcará un error cuando
intente ejecutar su modelo; en su lugar, usamos el módulo Station (Estación) como se describe
a continuación.
Nuestro modelo completo tendrá seis estaciones: Order Release, Cell 1, Cell 2,
Cell 3, Cell 4 y Exit System. Las últimas cinco estaciones se definieron cuando llena-
mos la información para nuestras secuencias de parte. La primera estación, Order Release,
se definirá cuando enviemos a la entidad a través del módulo Station (panel Advanced Trans-
fer), que definirá la estación y dirá a Arena que la entidad actual se encuentra en esa ubicación.
Nuestro módulo Station completo se indica en la pantalla 7-5.
Por último estamos listos para enviar a nuestra parte a la primera estación en su secuencia
con el módulo Route (panel Advanced Transfer). El módulo Route transfiere una entidad a una
estación específica o a la siguiente estación en la secuencia de visita de estación definida para
la entidad. Puede definirse un Route Time (Tiempo de ruta) para transferir a la siguiente esta-
ción. En nuestro modelo, la variable Transfer Time definida con anterioridad se introduce
para el Route Time; véase la pantalla 7-6. Seleccionamos la opción By Sequence como el
Destination Type. Esto hace que desaparezca el campo Station Name (Nombre de la estación)
y que cuando ejecutemos el modelo, Arena enrute a las entidades que llegan de acuerdo a las
secuencias que definimos y las adjunte a las entidades después de que se crearon.
Ahora que se enrutaron las partes que llegan de acuerdo con sus secuencias asignadas, ne-
cesitamos desarrollar una lógica para nuestras cuatro Celdas. La lógica para todas las cuatro
Celdas es esencialmente la misma. Una parte llega a la Celda (a una estación), hace cola para
una máquina, la máquina la procesa y se envía a su siguiente paso en la secuencia de la parte.
Las cuatro Celdas se pueden modelar de forma fácil al usar la secuencia del módulo Station-
Process-Route que se muestra en la figura 7-3 (para la Celda 1).
El módulo Station proporciona la ubicación a la que se enviará una parte. En nuestro mode-
lo, usamos secuencias para todas las transferencias de partes, así que la parte que se transfiere
llegaría a la siguiente ubicación de su secuencia. Las entradas para el módulo Station para la
Celda 1 se indican en la pantalla 7-7.
Una parte que llega a la estación de la Celda 1 se envía al siguiente módulo Process (al usar
una conexión directa). Para la Expression del tiempo de demora, introdujimos la expresión
arreglada que definimos antes Cell 1 Times al usar el atributo Part Index para referen-
ciar el tiempo de proceso de parte apropiado en la expresión arreglada. Esta expresión generará
una muestra de la distribución triangular con los parámetros que definimos antes. Las entradas
restantes se presentan en la pantalla 7-8.
Una vez terminado el proceso en la Celda 1, se dirige a la entidad al módulo Route, des-
crito en la pantalla 7-9, en donde se enruta a su siguiente paso en la secuencia de parte. Con
excepción del Name (Nombre), este módulo Route es idéntico al otro que usamos para iniciar
nuestra secuencia en la estación Order Release de la pantalla 7-6.
Las tres Celdas restantes son muy similares a la Celda 1, así que obviaremos los detalles.
Para crear su lógica, copiamos los tres módulos para la Celda 1 tres veces y después editamos
los datos requeridos. Para cada uno de los nuevos módulos Station y Route, simplemente cam-
biamos todos los acontecimientos de Cell 1 a Cell 2, Cell 3 o Cell 4. Hicimos las mis-
mas ediciones para los tres módulos Process adicionales y cambiamos la Expression de demora
para las Celdas 2 y 4 a Process Time. Recuerde que en el módulo Sequence definimos los
tiempos del proceso de las partes para las Celdas 2, 3 y 4 al asignarlas a un atributo de entidad
Process Time. Cuando se enrutó la parte a una de estas Celdas, Arena asignó de forma au-
tomática tal valor para que pudiera usarse en el módulo.
En este punto, usted debería estar consciente de que de alguna forma usamos de manera
arbitraria una Expression (Expresión) para los tiempos de proceso de la parte de la Celda 1 y
para las tareas de atributo en las secuencias para las Celdas restantes. De hecho empleamos este
enfoque para ilustrar que con frecuencia existen varias formas diferentes para estructurar datos
y tener acceso a ellos en un modelo de simulación. Pudimos haber incorporado fácilmente los
tiempos de proceso de parte a la Celda 1 dentro de las secuencias, junto con el resto de los tiem-
pos. También pudimos haber usado Expressions (Expresiones) para estos tiempos en la Celda
2 porque la Parte 2 visita esa Celda dos veces y los tiempos de proceso son diferentes, como
se muestra en la tabla 7-1. De esta manera, habríamos tenido que incluir en nuestro modelo
la habilidad para saber si la parte estaba en su primera o segunda visita a la Celda 2 y definir
nuestra expresión para reconocerla. Podría ser un ejercicio interesante, pero desde el punto de
vista del modelador, ¿por qué no sólo definir estos valores en las secuencias? También debería re-
conocer que este modelo de muestra es relativamente pequeño en términos del número de Celdas
y partes. En la práctica, sería común tener de 30 a 50 máquinas con cientos de tipos diferentes
de partes. Si el lector asumiera un problema de ese tamaño, le recomendaríamos que tuviera
mucho cuidado en el diseño de la estructura de los datos, ya que puede marcar la diferencia
entre el éxito y fracaso de un proyecto de simulación.
El módulo Process para la Celda 3 es ligeramente diferente porque tenemos dos distintas
máquinas, una nueva y la otra vieja, que procesan partes a diversas tasas. Si las máquinas
fueran idénticas, podríamos haber usado un solo recurso e introducido una capacidad de 2.
Hicimos notar esta situación antes y agrupamos las dos máquinas en un Set llamado Cell 3
Machines. Ahora necesitamos emplear este conjunto en la Celda 3. La pantalla 7-10 presenta
las entradas de los datos que se requieren para completar el módulo Process para esta Celda.
En la sección Resource, seleccionamos Set de la lista de sugerencias para nuestro Resource
Type. Esto nos permite seleccionar de nuestro conjunto específico Cell 3 Machines para el
campo Set Name (Nombre del conjunto). También se puede tomar (Seize) un Specific Member
(Miembro específico) de un conjunto; ese miembro puede especificarse como un atributo de la
entidad. Para nuestra selección de Resource Set (Conjunto de recursos), aceptamos la regla de
selección predeterminada, Cyclical (Cíclica), que hace que la entidad intente escoger el primer
recurso disponible comenzando con el sucesor del último recurso seleccionado. En nuestro caso,
Arena intentará seleccionar nuestros dos recursos de forma alternada; sin embargo, si sólo hay un
recurso disponible en la actualidad, será escogido. Obviamente, esas reglas se usan sólo si hay
más de un recurso disponible para la selección. La regla Random (Aleatoria) ocasionaría una
selección aleatoria (con probabilidades iguales) de entre aquellos disponibles y la regla Preferred
Order (Orden preferido) seleccionaría el primer recurso disponible (con la numeración más baja)
en el conjunto. Si seleccionáramos esta opción, Arena habría usado siempre la máquina nueva,
si estuviera disponible, porque es el primer recurso en el conjunto. Las reglas restantes aplicarían
sólo si uno o más de nuestros recursos tuvieran una capacidad mayor a 1.
La opción Save Attribute (Guardar atributo) nos permite guardar el índice, que es una re-
ferencia al miembro del conjunto seleccionado, en un atributo especificado por el usuario. En
nuestro caso, guardaremos este valor en el atributo Machine Index (Índice de máqui-
na). Si se selecciona la máquina nueva, a este atributo se le asignará un valor de 1 y si se seleccio-
na la máquina vieja, al atributo se le asignará el valor de 2. Esta numeración se basa en el orden
en el que introdujimos nuestros recursos cuando definimos el conjunto. La Expression para el
tiempo de demora usa nuestro atributo Process Time, asignado por la secuencia, multiplicado
Modelado intermedio y análisis estadístico de estado estable 305
Salir de la
Disponer de
estación del
la parte
sistema
0
por nuestra variable Factor (Machine Index). Recuerde que nuestros tiempos de proceso
son para la máquina vieja y que la máquina nueva puede procesar partes en 80% de ese tiempo.
Aunque probablemente sea obvio por ahora cómo funciona esta expresión, la ilustraremos. Si se
selecciona el primer recurso del conjunto (la máquina nueva), a Machine Index se le asignará
un valor de 1 y la variable Factor (Machine Index) empleará este tributo para tomar un
valor de 0.8. Si se selecciona la segunda máquina (la vieja), Machine Index se configura en 2,
la variable Factor (Machine Index) tomará un valor de 1.0 y se usará el tiempo de proceso
original. Aunque tal método puede parecer demasiado complicado para este ejemplo, se echa
mano de él para ilustrar la tremenda flexibilidad que proporciona Arena. Un método alternati-
vo, que no requeriría la variable, sería haber usado la siguiente expresión lógica:
0 0
0 0
Figura 7-5. El modelo completo
306 Capítulo 7
En este punto, podríamos ejecutar nuestro modelo, pero sería difícil decir si nuestras se-
cuencias están funcionando de forma adecuada. Así que antes de empezar cualquier análisis,
primero desarrollaremos nuestra animación para ayudarnos a determinar si el modelo funciona
de forma correcta. También supongamos que deberemos presentar este modelo a un adminis-
trativo del mayor nivel, así que deseamos desarrollar una animación algo más elaborada.
7.1.5 Animación
Podríamos desarrollar nuestra animación de la misma forma que lo hicimos en el capítulo 5:
crear nuestras propias imágenes de entidad, símbolos de recurso y fondo con base en la imagen
que se presenta en la figura 7-1. Sin embargo, puede ser que ya haya una imagen que refleje una
representación adecuada del sistema. De hecho, es posible que exista como un archivo CAD en
alguna parte de su organización. Por ejemplo, el dibujo que se presenta en la figura 7-1 se desa-
rrolló con el uso del paquete AutoCAD® de AutoDesk. Arena apoya la integración de archivos
provenientes de programas CAD en sus áreas de trabajo. Los archivos guardados con formato
DXF definidos por AutoCAD pueden importarse directamente en Arena. Los archivos genera-
dos en otros CAD o programas de dibujo (por ejemplo, Microsoft® Visio®) podrían transferirse
a Arena siempre y cuando se adhieran al formato DXF estándar de AutoCAD.
Si el dibujo original CAD está en doble dimensión, sólo hay que guardarlo en el formato
DXF y después importar ese archivo de forma directa a Arena. Si el dibujo está en tercera di-
mensión, primero hay que convertir el archivo a doble dimensión. Los colores se pierden durante
tal conversión, pero se pueden añadir otra vez en AutoCAD o en Arena. Dicha conversión tam-
bién transforma todos los objetos a líneas, así que el dibujo importado sólo se pude manipular en
Arena como líneas individuales o las líneas se pueden agrupar como objetos. Supondremos que
tenemos un archivo DXF y lo referimos a la ayuda en línea (el tema Importar archivos DXF)
para los detalles en cuanto a la creación del archivo DXF o a la conversión de un dibujo en ter-
cera dimensión. Un consejo: un archivo convertido se importa a Arena como líneas blancas así
que si su fondo actual es blanco, puede parecer que no se importó nada. Simplemente cambie el
Window Background Color (Color de fondo de la ventana) ( en la barra de herramientas
Draw [Dibujo]) o seleccione todas las líneas y cambie el color de las líneas ( ).
Para nuestro pequeño sistema de manufactura, comenzamos con un dibujo en 3-D y lo con-
vertimos a 2-D. Después guardamos el archivo 2-D en el formato DXF (Model 07-01.dxf).
Un archivo DXF se importa en su archivo actual del modelo al seleccionar File > DXF Import
(Archivo > Importar DXF). Seleccione el archivo y cuando mueva su cursor a la ventana del
modelo, éste aparecerá como una cruz de líneas delgadas. Usando el cursor, trace un cuadro
para contener el dibujo completo a importar. Si el dibujo importado no es de la medida correc-
ta, puede seleccionar el dibujo completo y darle otro tamaño según se requiera. Ahora se puede
emplear este dibujo como el inicio de su animación.
Para nuestra animación, debería borrar toda la escritura y flechas. Después moveremos el
objeto de animación de la cola Celda 1 del módulo Process (Cell 1 Process) a su posición
aproximada en el dibujo.
Ahora coloque su cursor cerca de la esquina superior izquierda de una máquina y arrás-
trelo de forma que el contorno limitado resultante encierre todo el dibujo. Use el botón Copy
(Copiar) para copiar el dibujo de la máquina en el portapapeles. Ahora abriremos la ventana
Resource Picture Placement (Localización de imagen recurso) haciendo un clic en el botón
Resource ( ) de la barra de herramientas Animate (Animar). Haga doble clic en el símbolo del
recurso desocupado y reemplace la imagen actual con una copia de los contenidos del portapa-
Modelado intermedio y análisis estadístico de estado estable 307
peles. Borre la base de la máquina y dibuje dos cajas encima de la presentación para la sección
alta de la parte de la máquina. Esto es necesario pues nuestro dibujo consiste sólo de líneas y
queremos añadir un color de relleno a la máquina. Ahora borre todas las líneas de la copia
original y rellene las cajas con su color favorito. Copie este nuevo símbolo en su biblioteca y
después colóquelo en la imagen Busy (Ocupado). Guarde su biblioteca, salga de la ventana del
recurso y por último coloque éste. Ahora tiene una imagen de recurso que no cambiará, pero
después podríamos regresar y añadir más efectos de animación.
Para el siguiente paso, dibuje una caja del mismo tamaño que la base de la máquina y des-
pués borre todo el dibujo de la máquina. Rellene esta nueva caja con un color diferente y a con-
tinuación coloque el símbolo del recurso encima de ella (puede ser que deba cambiar la medida
del símbolo del recurso al tamaño correcto). Ahora mueva el punto de tomar de tal forma que
esté colocado en el centro de nuestra máquina nueva, haga copias sucesivas de nuestro nuevo
recurso y base de la máquina y cambie los nombres. Si sigue tal procedimiento, observará que
necesitará dar la vuelta a los recursos de las Celdas 3 y 4.
Para completar esta fase de la animación, necesita mover y dar un nuevo tamaño a las colas
restantes. Una vez hecho esto, puede ejecutar su animación y mirar su trabajo. No se verán
partes moviéndose en el sistema (todavía no están las rutas), pero las observará en las colas y
en las máquinas. Si mira de cerca una de las máquinas mientras se ejecuta la animación, notará
que las partes están justo en la parte superior de toda la máquina. La muestra no es lo que
queremos. Idealmente, la parte debería hallarse en la parte alta de la base, pero por debajo de la
parte alta de nuestra máquina (el recurso). Representar esto no es un problema. Seleccione un
recurso (puede hacer esto en el modo editar o al detener de forma temporal la ejecución) y use
la característica Bring to Front (Traer objeto al frente) con Arrange > Bring to Front (Organizar
>Traer objeto al frente) o el botón ( ) en la barra de herramientas Arrange (Organizar). Ahora
cuando ejecute su animación, obtendrá el efecto deseado. Estamos listos entonces para animar
el movimiento de nuestra parte.
En nuestras animaciones previas, básicamente sólo teníamos un camino a través del sistema
así que añadir las rutas era bastante sencillo. En nuestro pequeño sistema de manufactura,
existen múltiples caminos a través del sistema, así que hay que tener cuidado al añadir las rutas
para cada posibilidad de viaje. Por ejemplo, una parte que deja la Celda 2 puede ir a la Celda
1, 3 o 4. Primero hay que colocar las estaciones; añada los objetos de animación de la estación
al usar el botón Station en la barra de herramientas Animate Transfer (Animar transferencia).
Después, coloque las rutas. Si de alguna forma se descuida al colocar una ruta, la simulación
aún enviará (de forma correcta) la entidad a la estación correcta con un tiempo de transferencia
de 2; sin embargo, este movimiento de la entidad no aparecerá en su animación. También el
lector debe estar consciente de que las rutas se pueden usar en ambas direcciones. Por ejemplo,
supongamos que se añade una ruta de la Celda 1 a la Celda 2, pero se perdió la ruta de la 2 a
la 1. Cuando una Parte 2 completa su proceso en la Celda 2, Arena busca enrutar esa parte a la
Celda 1, al moverla de la 2 a la 1. Si la ruta faltara, buscaría la ruta de la 1 a la 2 y la usaría. Así,
se vería a la parte moverse de la entrada de la Celda 2 a la Salida de la Celda 1 en una dirección
en contra de las manecillas del reloj (un error de animación para este modelo).
Si ejecuta y observa su nuevo modelo animado, debería notar que de forma ocasional las
partes se atropellarán o pasarán entre ellas. Esto se debe a la combinación de los datos sumi-
nistrados y a la manera en que animamos el modelo. Recuerde que todas las transferencias de
partes se supusieron para ser de dos minutos a pesar de la distancia a recorrer. Arena configura
la velocidad de una entidad enrutada con base en el tiempo de transferencia y la distancia física
308 Capítulo 7
de la ruta en la animación. En nuestro modelo, algunas de estas rutas son muy cortas (de la
Celda 1 a la Celda 2) y otras muy largas (de la Celda 2 a la Celda 1). Así, las entidades que se
transfieren se moverán a diferentes velocidades entre ellas. Si esto fuera importante, podríamos
solicitar o recopilar mejores tiempos de transferencia e incorporarlos en nuestro modelo. La
forma más fácil sería borrar la variable Transfer Time y asignar estos nuevos tiempos de
transferencia a un nuevo atributo en el módulo Sequences. Si sus tiempos de transferencia y
dibujo son adecuados, las entidades deberían moverse ahora a la misma velocidad. El único
problema potencial es que una parte puede introducirse al pasillo principal al mismo tiempo
que otra pase por ahí, resultando en que una de las partes se sobreponga a la otra hasta que
sus caminos se separen. Éste es un problema más difícil de resolver y puede no valer la pena
molestarse. Si la única preocupación es para propósitos de presentación, observe la animación
y encuentre un periodo de tiempo largo en el que no ocurra esto; muestre sólo tal periodo du-
rante su presentación. La alternativa es emplear construcciones de manejo de material, lo cual
haremos en el capítulo 8.
Después de añadir un poco de anotación, la animación final debería verse parecida a la figu-
ra 7-6 (ésta es una vista del sistema en el tiempo 541.28). En tal punto de su animación, podría
comprobar si su modelo se ejecuta de forma correcta o por lo menos de la manera en que lo
deseaba. Retomaremos dicho tema en nuestra siguiente sección.
7.1.6 Verificación
La verificación es el proceso de asegurar que el modelo Arena se comporta en la forma en que
se pensó de acuerdo con las suposiciones hechas de modelado. Esto es de hecho bastante fácil
comparado con la validación del modelo, que es el proceso de asegurar que aquél se comporta
igual que el sistema real. Analizaremos con más detalle ambos aspectos en el capítulo 13. Aquí
sólo presentaremos de forma breve el tema de la verificación del modelo.
La verificación trata con problemas obvios así como con los no tan evidentes. Por ejemplo, si el
lector trató de ejecutar su modelo y Arena le regresó un mensaje de error que indica que se descui-
dó al definir uno de los recursos de la máquina en la Celda 3, el modelo obviamente no funciona
de la forma que intenta. De hecho, ¡normalmente llamaríamos a esto el proceso de depuración!
Celda 1 Celda 2
Celda 4 Celda 3
Sin embargo, puesto que supusimos que no cometerá este tipo de errores (o que si incurre en ellos,
puede ingeniárselas para arreglarlos), trataremos con los problemas no tan obvios.
La verificación es bastante fácil cuando está desarrollando pequeños problemas del tamaño
de una clase como los de este libro. Cuando comience a desarrollar modelos de tamaño más
realista, encontrará que es un proceso mucho más difícil y quizá nunca esté 100% seguro de
modelos muy, muy grandes.
Un método de verificación fácil es permitir sólo una única entidad para introducir el sistema
y seguirla para estar seguros que la lógica y los datos del modelo sean correctos. Podría usar el
botón Step (Paso) ( ) que se encuentra en la barra de herramientas Standard (Estándar) para
controlar la ejecución del modelo y seguir a la entidad a través del sistema. Para este modelo, el
lector podría configurar en 1 el campo Max Arrivals (Llegadas máximas) en el módulo Create
(Crear). Para controlar el tipo de entidad, podría reemplazar la distribución discreta en el mó-
dulo Assign (Asignar) que determina el tipo de parte con la especificidad que quiere observar.
Esto le permitiría revisar cada una de las secuencias de partes. Otro método común es reem-
plazar algunos o todos los datos del modelo con constantes. Usar datos deterministas permite
predecir de forma exacta el comportamiento del sistema.
Si va a usar su modelo para tomar decisiones reales, también debería comprobar cómo se
comporta aquél bajo condiciones extremas. Por ejemplo, introduzca sólo un tipo de parte o
aumente/disminuya los tiempos entre llegadas de parte o de servicio. Si su modelo va a tener
problemas, por lo general aparecerán durante estos tipos de ejecuciones forzadas. También,
intente hacer un uso efectivo de su animación (a menudo ésta puede revelar problemas cuando
es vista por una persona familiarizada con la operación del sistema que se modela).
Comúnmente es buena idea, y de buen gusto, hacer ejecuciones largas para diferentes
datos y observar los resultados del resumen para problemas potenciales. Una habilidad que
puede ser de mucho uso durante este proceso es aquella de estimación de desempeño. Hace
mucho, mucho tiempo, antes de la invención de las calculadoras y ciertamente antes de la
aparición de las computadoras personales, los ingenieros llevaban consigo ramas llamadas
reglas de cálculo (a menudo protegidas con fundas de piel y orgullosamente sujetas a los
cinturones de los ingenieros). Éstas se usaban para calcular las respuestas a problemas com-
plicados que les daban sus profesores o jefes. Estos artículos lograban tal hazaña mágica al
agregar o sustraer troncos (no troncos de árbol, sino logaritmos). Aunque funcionaban bas-
tante bien (pero no tan correctamente, tan fácil, o tan rápido como una calculadora), sólo
devolvían (de hecho se leía de la rama) una secuencia de dígitos, digamos 3642. Dependía
del ingeniero entender dónde poner el punto decimal. Por lo tanto, los ingenieros se volvie-
ron muy buenos al desarrollar estimados aproximados de las respuestas a problemas antes
de usar las ramas. Por ejemplo, si el ingeniero estimaba que la respuesta fuera alrededor de
400, entonces la respuesta era 364.2. Sin embargo, si el estimado era alrededor de 900, había
un problema. En ese punto, era necesario determinar si el problema estaba en el proceso de
estimación o en el proceso de la regla de cálculo. Suponemos que en este punto el lector se
está haciendo dos preguntas: 1) ¿por qué la larga historia irrelevante?, y 2) ¿realmente alguna
vez usamos tales reglas? Bueno, las respuestas son: 1) para ilustrar un punto, y 2) ¡todos los
autores de este libro lo hicieron!
Así que ¿cómo usa esta gran habilidad de estimación de desempeño? Se define un conjunto
de condiciones para la simulación, se estima lo que resultará, se hace una ejecución y se obser-
van los datos del resumen para ver si estuvo correcto. Si lo estuvo, siéntase bien e inténtelo para
310 Capítulo 7
;
; Model statements for module: Process 3
;
10$ ASSIGN: Cell 3 Process.NumberIn=Cell 3 Process.NumberIn + 1:
Cell 3 Process.WIP=Cell 3 Process.WIP+1;
138$ QUEUE, Cell 3 Process.Queue;
137$ SEIZE, 2,VA:
SELECT(Cell 3 Machines,CYC,Machine Index),1:NEXT(136$);
136$ DELAY: Process Time * Factor( Machine Index ),,VA;
135$ RELEASE: Cell 3 Machines(Machine Index),1;
183$ ASSIGN: Cell 3 Process.NumberOut=Cell 3 Process.NumberOut + 1:
Cell 3 Process.WIP=Cell 3 Process.WIP-1:NEXT(11$);
Figura 7-7. Archivo del modelo SIMAN para el módulo Process (Proceso)
escriba los archivos .mod y .exp. Después edite los módulos al seleccionar opciones diferentes
y escriba los nuevos archivos. Observe las diferencias entre los dos archivos .mod. Hacer esto le
facilitaría entender en gran medida cómo funciona este proceso.
lugar, es una apuesta segura que no se sepa mucho acerca del estado del sistema “típico” en el
estado estable o qué tan suficientemente “larga” es la ejecución de un sistema. Así que proba-
blemente vaya a terminar inicializando en un estadio que es muy extraño desde el punto de
vista del estado estable y tratando sólo algunas longitudes de ejecución (largas). Si el lector se
inicializa vacío y ocioso en una simulación donde los elementos finalmente se congestionan, sus
datos de salida para algún periodo de tiempo después de la inicialización tenderán a subestimar
la congestión final; esto es, sus datos serán desviados a la baja.
Para remediar lo anterior se puede intentar iniciar en un estado que sea “mejor” que vacío y
ocioso. Esto significaría colocar, en el tiempo 0, algún número de entidades alrededor del modelo
y comenzar las cosas de esa forma. Aunque sea posible hacer esto en su modelo, es muy incon-
veniente. Es más problemático que generalmente no se tenga idea de cuántas entidades colocar
alrededor del tiempo 0; esto es, después de todo, una de las preguntas que la simulación se supone
debe contestar.
Otra forma de tratar con el inicio parcial es ejecutar el modelo sólo por el tiempo suficiente
para que cualquier desviación que pueda estar ahí al inicio sea sobrepasada por la cantidad de
datos posteriores. Esto puede funcionar en algunos modelos si los efectos de la desviación de las
condiciones iniciales desaparecen rápido.
Sin embargo, lo que las personas hacen por lo general es iniciarse vacías y ociosas, dándose
cuenta que esto no es representativo del estado estable, pero luego permiten al modelo calentar
por un momento hasta que parece que los efectos de las condiciones iniciales artificiales se ago-
taron. En ese instante, se pueden despejar los acumuladores estadísticos (pero no el estado del
sistema) y comenzar de nuevo, reuniendo estadísticas para el análisis desde ahí. En efecto, esto
es iniciar en un estado diferente a vacío y ocioso, pero permita que el modelo decida cuántas
entidades tener alrededor cuando comience (de nuevo) a observar sus medidas de desempeño.
La longitud de ejecución debe seguir siendo larga, pero a lo mejor no tan larga como necesitaría
para abrumar la desviación inicial mediante gran aritmética.
Es muy fácil especificar un Warm-up Period (Periodo de calentamiento) inicial en Arena. Sólo
abra el cuadro de diálogo Run > Setup > Replication Parameters (Ejecutar > Configuración >
Parámetros de réplica) y llene un valor (asegúrese de verificar las Time Units [Unidades de tiem-
po]). Cada réplica de su modelo se ejecutará igual comenzando como hizo antes, pero al final del
periodo de calentamiento todos los acumuladores estadísticos se despejan y sus reportes (y cual-
quier dato guardado por tipo de salida del módulo Statistic [Estadística] de los resultados entre
las réplicas) reflejan sólo lo que ocurrió después de que termina el periodo de calentamiento. De
esta forma, se pueden “descontaminar” los datos de las condiciones iniciales de desviación.
La parte difícil es conocer qué tan largo debe ser el periodo de calentamiento. Probablemen-
te la idea más práctica es sólo hacer algunas gráficas de las salidas clave desde la ejecución, y
echar un vistazo cuando parezcan estabilizarse. Para ilustrar esto, tomamos el modelo 7-1 de la
sección 7.1 y realizamos las siguientes modificaciones, llamando modelo 7-2 al resultado.
< Para establecer una sola medida de desempeño de salida general, hicimos una entrada en
el módulo Statistic (Estadística) con el fin de calcular el trabajo total en el proceso (WIP)
de todas las tres partes combinadas. El Name (Nombre) y Report Label (Etiqueta del
reporte) son ambos Total WIP, y el Type (Tipo) es Time-Persistent. Para intro-
ducir la Expression (Expresión) que queremos rastrear en el tiempo, hicimos clic con el
botón derecho en ese campo y seleccionamos Build Expression (Construir expresión),
luego otro clic en el árbol vía Basic Process Variables → Entity → Number in Process
314 Capítulo 7
Si nosotros hiciéramos las ejecuciones (y gráficas) por un periodo más largo de tiempo, o si
el calentamiento del modelo ocurriera más rápido, puede ser difícil ver el periodo de calenta-
miento apropiado en el extremo izquierdo de las curvas. Si así ocurre, el lector podría “Zoom
in (acercar imagen)” sólo en la primera parte de cada réplica a través del área “Display Time
(Tiempo de muestra) de . . . a . . .” en el cuadro de diálogo “Plot”.
En los modelos en donde esté interesado en múltiples medidas de desempeño de resultados,
necesitaría hacer una gráfica como la de la figura 7-11 para cada salida. Podría haber un des-
acuerdo entre las medidas de salida en el índice de calentamiento, en cuyo caso, el movimiento
seguro es tomar el máximo de los calentamientos individuales como el único a usar para todo.
más réplicas con esta longitud de ejecución y calentamiento o mantener el mismo número de
réplicas y ampliar la longitud de ejecución. (Presumiblemente el calentamiento original seguiría
siendo adecuado.) Es probablemente más sencillo mantenerse con la misma longitud de ejecu-
ción y sólo hacer más réplicas, que es lo mismo que aumentar el tamaño de la muestra esta-
dística. Sin embargo, hay que decir algo para extender las longitudes de ejecución y mantener
el mismo número de réplicas; el incremento en la precisión con esta estrategia proviene no de
aumentar el “tamaño de muestra” (estadísticamente, grados de libertad), sino de disminuir la
variabilidad de cada promedio dentro de la ejecución ya que se está tomando de una ejecución
más larga. Más aún, al hacer las ejecuciones más largas, se tiene mayor seguridad que se está
ejecutando lo suficiente para “lograr” el estado estable.
Si el lector puede identificar una longitud de ejecución y un periodo de calentamiento apro-
piados para su modelo, y si el periodo de calentamiento no es muy largo, entonces es bastante
atractiva la estrategia de réplica truncada. Es bastante sencillo, con relación a otras estrategias
de análisis de estado estable y le brinda observaciones independientes verdaderas (los resulta-
dos de cada réplica truncada), lo que es una gran ventaja al momento de hacer el análisis esta-
dístico. Esto aplica no sólo para hacer simplemente intervalos de confianza como hicimos aquí,
sino también para comparar alternativas así como otros logros estadísticos.
Ahora la dificultad es que sólo tenemos una “réplica” en cada medida de desempeño con
la cual hacer nuestro análisis y no está claro cómo vamos a calcular un estimado de varianza,
que es la cantidad básica necesaria para hacer inferencia estadística. Ver cada observación in-
dividual o valor persistente al tiempo dentro de una ejecución como un “punto de datos” por
separado nos permitiría hacer la aritmética para calcular una varianza de muestra dentro de
la ejecución, pero hacerlo es extremadamente peligroso ya que la posible correlación pesada
(véase la sección C.2.4 del apéndice C) de puntos en una ejecución hará que estos estimados se
encuentren severamente desviados con respecto a la verdadera varianza de una observación. De
alguna manera, hay que tomar en cuenta esta correlación o de otra forma “fabricar” algún tipo
de “observaciones independientes” a raíz de esta sola ejecución larga para obtener un estimado
decente de la varianza.
Hay varias formas diferentes para proceder con el análisis estadístico de una sola ejecución
larga. Una idea relativamente sencilla (que también parece funcionar así como otros métodos más
complicados) es intentar fabricar “observaciones” casi sin correlacionar al romper la ejecución en
unos pocos lotes largos de muchos puntos individuales, calcular los promedios de los puntos den-
tro de cada lote y tratarlos como las observaciones IID básicas sobre las cuales hacer análisis esta-
dístico (comenzando con la estimación de varianza). Entonces estas medias por intervalos toman
el lugar de las medias de dentro de las réplicas múltiples en el enfoque de réplica truncada: se han
reemplazado las réplicas por lotes. En la gráfica WIP de la figura 7-12 las gruesas líneas verticales
divisorias ilustran la idea; tomaríamos el nivel WIP de tiempo promedio entre las líneas como los
“datos” básicos para análisis estadístico. Para obtener un estimado de varianza imparcial, necesi-
tamos que las medias por intervalos sean casi no correlacionadas, que es por lo que necesitamos
hacer los lotes grandes; seguirá habiendo alguna correlación pesada de puntos individuales cerca
de cualquier lado de un límite de lote, pero estos puntos serán una minoría pequeña dentro de sus
propios lotes grandes, que esperamos hagan a las medias por intervalos casi no correlacionadas.
En cualquier caso, Arena intentará hacer lotes lo suficientemente grandes para parecer no corre-
lacionados y hará saber al lector si su ejecución fue demasiado corta como para fabricar medias
por intervalos que “parezcan” (en el sentido de una prueba estadística) casi no correlacionadas,
en cuyo caso tendría que hacer su ejecución más larga.
Como acabamos de insinuar, Arena intenta calcular de forma automática los intervalos de
confianza de 95% a través de las medias por intervalos para las medias de todas las estadísticas
de salida, brindando los resultados en la columna Half Width (Mitad del intervalo) junto a la
columna Average (Promedio) en el reporte de cada réplica. Si se encuentra haciendo sólo una
réplica, como hemos estado analizando, éste es su intervalo de confianza de medias por inter-
valos. Por otra parte, si realizó varias réplicas, vea esto en el reporte Category by Replication
(Categoría por réplica) para cada réplica; el Half Width (Mitad del intervalo) en el reporte Ca-
tegory Overview (Vista general de categoría) es entre réplicas, como analizamos en las secciones
6.3 y 7.2.2. Decimos “intenta calcular” ya que se hacen revisiones internas para ver si su réplica
es lo suficientemente larga para producir suficientes datos para un intervalo de confianza válido
de medias por intervalos en una estadística de salida; si no, sólo se obtiene un mensaje para este
efecto, sin un valor de mitad del intervalo (bajo la teoría de que una respuesta equivocada es
peor que no tener respuesta) para esta estadística. Si especificó un periodo de calentamiento,
los datos recopilados durante tal periodo no son usados en el cálculo del intervalo de confian-
za. Para entender cómo funciona este procedimiento, piense en Arena como agrupamiento “al
vuelo” (es decir, observando los datos de salida durante su ejecución y preparándolos en lotes
conforme su simulación progresa).
Modelado intermedio y análisis estadístico de estado estable 319
Así que, ¿qué significa “datos suficientes”? Hay dos niveles de revisiones que pasar, el pri-
mero de los cuales es sólo comenzar. Para una estadística de cuenta, Arena exige un mínimo
de 320 observaciones. Para una estadística persistente al tiempo, debe tener por lo menos cinco
unidades de tiempo simuladas durante las cuales haya al menos 320 cambios en el nivel de la
variable de cambio discreta. La verdad es que éstos son valores y condiciones algo arbitrarios,
pero tenemos que comenzar de algún modo y la prueba estadística más definitiva, que también
hay que pasar, se realiza al final de este procedimiento. Si su ejecución no es lo suficientemente
larga para lograr esta primera revisión, Arena reporta “(Insufficient [Insuficiente])” en la co-
lumna Half Width (Mitad del intervalo) para esta variable. Con sólo hacer su réplica más larga
puede al final producir suficientes datos para satisfacer estos requerimientos de inicio.
Si tiene suficientes datos para empezar, entonces Arena comienza agrupando al formar 20
medias por intervalos para cada estadística de cuenta y persistente al tiempo. Para las estadís-
ticas de cuenta, cada media de lote será el promedio de 16 observaciones consecutivas; para
estadísticas persistentes al tiempo, cada una será el promedio de tiempo durante 0.25 unidades
de tiempo base. Conforme progrese su ejecución, finalmente acumulará suficientes datos para
otro lote de estos mismos “tamaños”, que se forma luego como el lote número 21. Si continúa
su simulación, obtendrá los lotes 22, 23 y así sucesivamente, hasta alcanzar 40. En este punto,
Arena reagrupará estos 40 lotes al promediar los lotes uno y dos en un nuevo (y más grande) lote
uno, los lotes tres y cuatro en un nuevo (más grande) lote dos, etc., así que el lector regresará de
nuevo a los 20 lotes, pero cada uno será el doble de “grande”. Conforme proceda su simulación,
Arena continuará formando nuevos lotes (21, 22, etc.), cada uno de este gran tamaño, hasta que
se formen de nuevo 40 lotes, cuando la reagrupación baje de nuevo a 20 se presentará otra vez.
Por lo tanto, cuando esté hecho, tendrá entre 20 y 39 lotes completos de cierto tamaño. A menos
que sea realmente afortunado, también tendrá algunos datos a la izquierda y al final en un lote
parcial que no se usarán en el cálculo del intervalo de confianza. La razón para tal reagrupa-
miento en lotes más grandes se estima de un análisis de Schmeiser (1982), quien demostró que
no hay ventaja para la otra opción, de continuar obteniendo más y más lotes de un tamaño fijo
para reducir la mitad del intervalo, ya que los lotes más grandes tendrán inherentemente una
varianza menor, compensando por tener menos de ellos. Por otra parte, tener lotes que sean muy
pequeños, aún si se tienen muchos de ellos, es peligroso ya que es más probable que produzcan
medias por intervalos correlacionadas y por lo tanto, un intervalo de confianza inválido.
La revisión final es para observar si los lotes son lo suficientemente grandes para soportar
los supuestos de independencia entre las medias por intervalos. Arena prueba esto usando una
prueba de hipótesis estadística debida a Fishman (1978). Si pasa la prueba, obtendrá la mitad
del intervalo para esta variable de salida en su reporte. Si no, el lector obtendrá “(Correlated
[Correlación])” que indica que su proceso es evidentemente muy pesado en la autocorrelación
para su longitud de ejecución como para producir lotes casi no correlacionados; de nuevo, el
prolongar su ejecución puede resolver este problema, aunque, dependiendo de la situación,
puede tener que prolongarla mucho.
Regresando al modelo 7-4, después de hacer una ejecución de 50 días y de borrar los dos
primeros como un periodo de calentamiento, Arena produjo en el reporte Category Overview
un intervalo de confianza de 95% de las medias por intervalos de 13.6394 ± 1.38366 en el WIP
promedio esperado. La razón por la que este intervalo de confianza de medias por intervalos se
muestra aquí en el reporte Category Overview es que sólo hicimos una sola réplica.
En la mayoría de los casos, estos intervalos automáticos de confianza de medias por interva-
los serán suficientes para que entienda qué tan precisos son sus promedios y son bastante fáciles
320 Capítulo 7
(no requieren mucho trabajo de su parte). Pero hay algunas consideraciones que deben tenerse
en mente. Primero, no olvide que aquéllos son relevantes sólo para simulaciones de estado esta-
ble; si tiene una simulación terminada (capítulo 6), debe realizar réplicas independientes y hacer
su análisis en ellas, en cuyo caso Arena reporta mitades del intervalo de confianza de cruce de
réplicas como en el capítulo 6, y no una agrupación dentro de la ejecución. Segundo, todavía
debe echar una mirada al periodo de calentamiento para su modelo, como en la sección 7.2.1,
ya que los intervalos de confianza de medias por intervalos automáticos no hacen nada para co-
rregir la desviación de inicio si no se especifica un periodo de calentamiento. Por último, puede
revisar el valor de las mitades automáticas de intervalos de las medias por intervalos conforme
se calcula durante su ejecución, a través de las variables de Arena THALF(Tally ID) para esta-
dísticas de cuenta y DHALF(Dstat ID) para estadísticas persistentes al tiempo (a.k.a. Dstat);
una razón para estar interesado en esto es que se podría usar una de ellas para una medición
de salida crítica en el campo Terminating Condition (Condición terminante) de su módulo
Simulate (Simular), para ejecutar su modelo lo necesario para que se haga lo suficientemente
pequeño (esto es, preciso) para que se ajuste a sus requerimientos; véase la sección 12.5 para
más información sobre el tema e ideas relacionadas.
Debemos mencionar que, si realmente lo desea, el lector puede decidir sus propios tamaños
de lote, calcular y guardar las medias por intervalos, después usarlas en procedimientos estadís-
ticos como formación de intervalos de confianza y comparación de dos alternativas (véanse las
secciones 6.3 y 6.4). De forma breve, la manera en que esto funciona es guardando la historia de
sus observaciones desde la ejecución igual que lo hicimos nosotros, con el fin de elaborar nues-
tras gráficas de determinación de calentamiento, leer este archivo en el Output Analyzer (Ana-
lizador de salida), y usar su capacidad Analyze > Batch/Truncate Obs’ns (Analizar > Observa-
ciones Lote/truncado) para hacer los lotes y los promedios, guardando las medias por intervalos
que luego debe tratar como lo hicimos en las medias de cruce de réplicas en las secciones 6.3 y
6.4. Cuando agrupa, el Output Analyzer desempeña la misma prueba estadística para los lotes
no correlacionados y le hará saber si el tamaño del lote que seleccionó es demasiado pequeño.
Algunas razones para pasar por esto son si se desea algo más que un nivel de confianza de 95%,
si se quiere hacer el uso más eficiente de los datos y minimizar el gasto al final o si se necesita
hacer una comparación estadística entre dos alternativas con base en su desempeño de estado
estable. Sin embargo, ciertamente es mucho más trabajo.
obvio, es fácil de realizar (una vez que haya hecho algunas gráficas e identificado
un periodo de calentamiento razonable) y básicamente concluye el procedimiento
sólo como análisis estadístico para simulaciones terminadas, excepto para el
calentamiento. También le permite aprovecharse de las capacidades de análisis más
sofisticadas en PAN y OptQuest.
3. Si encuentra que su modelo se calienta despacio, entonces debe considerar las medias
por intervalos, con un único calentamiento al inicio de su única ejecución realmente
larga. Podría también aceptar ya sea los intervalos de confianza de medias por
intervalos automáticos de Arena o realizar a mano las suyas. Sin embargo, no puede
usar los métodos estadísticos en PAN u OptQuest con el enfoque de medias por
intervalos (parte de la razón por lo que es el último en nuestra lista de preferencias).
7.4 Ejercicios
7-1 En el ejercicio 4-7, ¿la ejecución es lo suficientemente larga para generar un intervalo
de confianza con base en medias por intervalos para el tiempo de ciclo promedio esperado de
estado estable? ¿Por qué?
7-2 Modifique la solución de su ejercicio 5-2 para incluir tiempos de transferencia entre la
parte que llega y la primera máquina, entre máquinas y entre la última Máquina 1 y la salida
del sistema. Suponga que todos los tiempos de transferencia de partes son UNIF(1.5, 3.2).
Anime su modelo para mostrar las transferencias de partes con la imagen de entidad de partes
cambiando cuando sale de la Máquina 2. Ejecute por 20 000 minutos. En la medida de lo posi-
ble, indique los intervalos de confianza con base en las medias por intervalos en las medidas de
desempeño esperadas de estado estable de la presente ejecución.
322 Capítulo 7
7-3 Usando el modelo del ejercicio 7-2, cambie el tiempo de proceso para el segundo paso en
la Máquina 1 a TRIA(6.7, 9.1, 13.6) usando Sequences (Secuencias) para controlar el flujo de
partes a través del sistema y la asignación de tiempos de proceso en cada máquina. Ejecute la
simulación por 20 000 minutos. En la medida de lo posible, indique los intervalos de confianza
con base en las medias por intervalos en las medidas de desempeño esperadas de estado estable
de esta ejecución.
7-4 Una parte llega cada diez minutos a un sistema que tiene tres estaciones de trabajo (A, B
y C), en donde cada una de éstas posee una única máquina; la primera parte llega en el tiempo 0.
Hay cuatro tipos de partes, cada una con igual probabilidad de llegar. Los planes de proceso de
los cuatro tipos de partes se dan a continuación. Las entradas para los tiempos de proceso son los
parámetros para una distribución triangular (en minutos).
Suponga que el tiempo de transferencia entre la llegada y la primera estación, entre todas las
estaciones y entre la última estación y la salida del sistema, es de tres minutos. Emplee la carac-
terística Sequence (Secuencia) para dirigir las partes a través del sistema y asignar los tiempos
de proceso en cada estación. Use la característica Sets (Conjuntos) para recopilar los tiempos de
ciclo (tiempos totales en el sistema) para cada uno de los tipos de partes por separado. Anime
su modelo (incluyendo las transferencias de partes) y ejecute la simulación por 10 000 minutos.
7-5 Modifique la solución de su ejercicio 7-4 para usar la característica Expressions (Ex-
presiones) y determinar los tiempos de proceso (en lugar de asignarlos en el módulo de datos
Sequence [Secuencia]). Ejecute por 10 000 minutos y compare los resultados con aquellos del
ejercicio 7-4. ¿Los resultados sin diferentes? Si así es, indique el porqué.
7-6 Modifique sus resultados del ejercicio 7-5 de manera que todas las partes sigan el mismo
camino a través del sistema: Estación de trabajo A-Estación de trabajo B-Estación de trabajo
C. Si una parte no requiere proceso en una estación de trabajo, aún debe esperar en la cola,
pero incurre en una demora de tiempo de proceso cero. Compare los resultados con aquellos
obtenidos de los ejercicios 7-4 y 7-5.
7-7 Tres tipos de clientes llegan a un pequeño aeropuerto: registro de equipaje (30%), compra
de los boletos (15%) y continuar adelante (55%). La distribución del tiempo entre llegadas para
todos los clientes combinados es EXPO(1.3); todos los tiempos están en minutos y la primera
Modelado intermedio y análisis estadístico de estado estable 323
7-8 Las partes llegan a un sistema de cuatro máquinas de acuerdo con una distribución ex-
ponencial entre llegadas con media de 10 minutos. Las cuatro máquinas son todas diferentes
y sólo hay una de cada tipo. Hay cinco tipos de partes con los porcentajes de llegada y planes
de proceso dados a continuación. Las entradas para los tiempos de proceso son los parámetros
para una distribución triangular (en minutos).
El tiempo de transferencia entre la llegada y la primera máquina, entre todas las máquinas y
entre la última máquina y la salida del sistema, sigue una distribución triangular con paráme-
tros 8, 10, 12 (minutos). Recopile el tiempo de ciclo del sistema (tiempo total en el sistema) y
utilizaciones de las máquinas. Anime su modelo (incluyendo transferencias de partes) y ejecute
la simulación por 10 000 minutos. Si la ejecución es lo suficientemente larga, dé los intervalos
de confianza con base en las medias por intervalos de los valores esperados de estado estable de
los resultados.
7-9 Modifique sus resultados del ejercicio 7-8 para incluir los tiempos de viaje que son es-
pecíficos en su movimiento. Tales tiempos se brindan a continuación así como los parámetros
para una distribución triangular (en minutos). Compare sus resultados. ¿Es ésta una compara-
ción estadísticamente confiable?
324 Capítulo 7
7-10 Modifique sus respuestas del ejercicio 4-21 para usar secuencias que controlen el flujo de
las partes a través del sistema. (PISTA: Vuelva a poner el valor de Entity.Jobstep o IS.)
7-11 Modifique el modelo 7-1 para justificar y adquirir un nuevo cliente, además del que pro-
porciona los tres tipos de parte existentes. Este nuevo cliente proporcionará dos nuevos tipos de
partes (llámelas Type 4 y Type 5). El proceso de llegada está además del original (e independien-
te de él) para los tres tipos de partes y posee tiempos entre llegadas exponenciales con media de
15 minutos; la primera llegada es en el tiempo 0. Cuando las partes lleguen, asigne 40% de las
nuevas partes para que sean de Type 4 y el resto de Type 5. Aquí se muestran los planes de
proceso y tiempos medios de proceso (en minutos) para los nuevos tipos de partes:
Part Type Cell/ Mean Cell/ Mean Cell/ Mean Cell/ Mean
(Tipo de parte) Proc. Time Proc. Time Proc. Time Proc. Time
(Celda/Tiempo (Celda/Tiempo (Celda/Tiempo (Celda/Tiempo
de proceso medio) de proceso medio) de proceso medio) de proceso medio)
4 1 3 2 4
6.1 5.2 1.3 2.4
5 2 3 4 1
3.5 4.1 3.2 2.0
Aunque las personas se sienten bien con estos tiempos medios de proceso, no hay muy buena
información acerca de sus distribuciones, así que sólo se le pide suponer que las distribuciones
son uniformes con la media indicada pero más o menos 0.2 minutos en cada caso. Por ejemplo,
si se muestra una media de 6.1, suponga que la distribución es uniforme entre 5.9 y 6.3. Haga
todos los cambios necesarios al modelo, incluyendo los módulos, las imágenes de animación
(cree nuevas imágenes de entidad para los nuevos tipos de parte) y cualquier otra cosa que se
requiera. Asegúrese de que la animación funcione adecuadamente, incluyendo el movimiento
sólo en el sentido de las manecillas del reloj de todas las entidades y los nuevos tipos de partes.
Modelado intermedio y análisis estadístico de estado estable 325
a) Claramente, el añadir este nuevo cliente va a atascar el sistema comparado a como es-
taba. Usar el número total de partes de promedio de tiempo en las cuatro colas combi-
nadas, ¿qué tan malo es comparado con el sistema original? Sólo realice una ejecución
de cada alternativa (hará un mejor trabajo en análisis estadístico en la siguiente parte
del ejercicio).
7-12 Modifique sus resultados del ejercicio 5-2 para usar Sequences (Secuencias) y controlar
el flujo de partes por el sistema. También añada un tiempo de transferencia entre la llegada y la
primera máquina, entre ambas máquinas y entre la última y la salida del sistema que sigue una
distribución triangular con parámetros 7, 9, 14 (minutos). Vea esto como una simulación ter-
minada y haga diez réplicas de dicho modelo así como para el ejercicio 5-2, usando PAN para
comparar los resultados para el tiempo total promedio en el sistema y las longitudes promedio
de cada cola.
7-13 Modifique sus resultados del ejercicio 7-12 para justificar un 20% de aumento en el tiem-
po de proceso cuando la parte regresa a la primera máquina para su última operación. Vea esto
como una simulación terminada y haga 50 réplicas de este modelo así como para el ejercicio
7-12, usando PAN para comparar los resultados para las mismas medidas de desempeño de
salida que en el ejercicio 7-12.
CAPÍTULO 8
Transferencia de entidades
Hasta ahora, se han considerado dos casos diferentes relacionados con cuánto tardan las en-
tidades en moverse de un lugar a otro. Se les ha movido de módulo a módulo, sin tiempo de
recorrido, a través de Connections (Conexiones). En otros modelos, se les ha movido mediante
Routing (Enrutamiento) entre estaciones, con algo de demora en el tránsito. En ambos casos,
las entidades siguieron su curso desembarazadas, como si todas tuvieran sus propios pies y
hubiera espacio suficiente en las vías de tránsito como para que se movieran al mismo tiempo
tantas de ellas como se quisiera.
Por supuesto, las cosas no siempre resultan tan bellas. Pudiera haber un límite en el número
concurrente de entidades en tránsito, como un sistema de comunicación en donde las entidades
sean paquetes de información y el ancho de banda esté limitado a un cierto número de paquetes
en transmisión a la vez. También pudiera haber situaciones en la que algo como un montacar-
gas o una persona venga, recoja una entidad y, a continuación, la transporte. Existen también
clases diferentes de transportadores en los cuales se pueden ver las entidades como si compitie-
ran por el espacio sobre la banda o línea. En este capítulo se examinarán algunas de estas ideas
de modelado y capacidades. A menudo es importante modelar con exactitud esa transferencia
de entidades, ya que los estudios han demostrado que las demoras y las faltas de eficiencia en
las operaciones podrían ser causadas en mayor proporción sólo por la necesidad de mover las
cosas de uno a otro lado, que por realizar verdaderamente el trabajo.
En la sección 8.1 se discuten con más detalle las diferentes clases de movimiento y transfe-
rencia de entidades, así como la manera en que se pueden modelar. En la sección 8.2 se indicará
cómo puede usar las herramientas de modelado de Arena que ya tiene, con el fin de representar
una restricción sobre el número de entidades que pueden estar en movimiento a la vez (aunque
todas las entidades todavía tengan sus propios pies). Los aparatos de transporte como los mon-
tacargas, las carretillas de mano y (por supuesto) la gente se abordan en la sección 8.3. En la
8.4, se describe el modelado de transportadores de tipos diferentes.
Después de leer este capítulo y considerar los ejemplos, el lector será capaz de modelar una
rica variedad de movimientos y transferencia de entidades que pueden añadir validez a su mo-
delo y realismo a sus animaciones.
simultáneos que se están transfiriendo por cada eslabón de la red o por esta última completa. La
solución es más bien sencilla; piense en los eslabones de la red como recursos con una capacidad
igual al número máximo de mensajes simultáneos permitidos. Si la capacidad depende del tama-
ño de los mensajes, entonces se define la capacidad del recurso en términos de este tamaño y se
establece el requisito de que cada mensaje tome el número requerido de unidades de este recurso,
determinado por su tamaño, antes de que pueda transferirse. Llamemos a este tipo de transferencia
de entidades restringida por el recurso y, en la sección 8.2, se le discutirá con más detalle.
El uso de un recurso para restringir el número de transferencias simultáneas puede funcio-
nar bien para una red de comunicaciones, pero no permite modelar con exactitud una clase
o categoría completas de transferencia de entidades mencionadas en general como manejo de
materiales. Los requisitos del modelado para distintos sistemas de manejo de materiales pueden
variar mucho y el número de tipos diferentes de aparatos para ese manejo es enorme. De hecho,
existe un manual completo dedicado a este tema (véase Kulwiec, 1985). No obstante, es posible
dividir estos aparatos en dos categorías generales, con base en sus requisitos de modelado.
< En la primera categoría se restringe el número de transferencias simultáneas con base en el
número de aparatos por separado, para manejo de materiales, de los que se dispone. Los
aparatos para manejo de materiales que caen en esta categoría son los carros, las carreti-
llas, los montacargas de horquilla, los AVG, la gente, etc. Sin embargo, se tiene un requisito
adicional en el sentido de que cada uno de estos aparatos tiene una ubicación física. Si se
requiere una transferencia, puede ser que, en primer lugar, tenga que moverse el aparato al
lugar en donde reside la entidad que lo solicita, antes que se pueda realizar la transferencia
real. Desde el punto de vista de un modelado, se podrían concebir aquéllos como recursos
movibles, conocidos en Arena como Transporters (Transportadores).
< En la segunda categoría se restringe la capacidad para iniciar una transferencia con
base en la disponibilidad de espacio. También se requiere que se limite el número total
de transferencias simultáneas entre dos lugares, pero es típico que este límite se base en
el requisito de espacio. Los aparatos de manejo de materiales que caen en tal categoría
incluyen los transportadores, las carretillas elevadas, los sistemas energizados y libres,
las líneas de remolque y más. Una escalera mecánica es un ejemplo conocido de este tipo
de aparato de manejo de materiales. Si se requiere una transferencia, en principio se tiene
que obtener la cantidad requerida de espacio disponible o no ocupado en el aparato,
en el lugar en que se está esperando, antes que se pueda iniciar la transferencia. Estos
aparatos requieren una capacidad significativamente diferente de modelado, aludidos en
Arena como Conveyors (Transportadores continuos).
Las construcciones Transporter y Conveyor de Arena permiten modelar con facilidad casi
cualquier tipo de sistema de manejo de materiales. Empero, existen unos cuantos aparatos para
manejo de materiales que tienen requisitos tan únicos, que pueden crear un reto de modelado. Las
grúas de caballete o de puente son ejemplos clásicos de esos aparatos. Una sola grúa se modela
con facilidad con las construcciones de transportadores. Si usted cuenta con más de una grúa
en una sola vía, el método que se utiliza para controlar la manera en que las grúas se mueven es
crítico para modelar tales aparatos con exactitud. Desgraciadamente, casi todos los sistemas que
tienen grúas múltiples son controlados por los operarios de las mismas, quienes, en general, resi-
den en las cabinas ubicadas en ellas. Estos operarios pueden verse y hablar entre sí y sus decisiones
no son necesariamente predecibles. En este caso, es fácil modelar las grúas; la parte difícil es cómo
incorporar la lógica humana que impide que esas grúas choquen o se bloqueen.
Transferencia de entidades 329
Por lo tanto, se han definido tres tipos de transferencias restringidas de entidades: restrin-
gidas por los recursos, transportadores y transportadores continuos. En primer lugar, en la
sección 8.2, se discutirán con brevedad las transferencias restringidas por los recursos, a con-
tinuación, en las secciones 8.3 y 8.4, se presentarán los transportadores y los transportadores
continuos, usándolos en el pequeño sistema de fabricación del capítulo 7 (modelo 7-1).
8.2 M
odelo 8-1: el pequeño sistema de fabricación con transferencias
restringidas por los recursos
En el modelo inicial (modelo 7-1) del pequeño sistema de fabricación, se supuso que todos los
tiempos de transferencia eran de dos minutos. Si tales tiempos de transferencia dependen de
la disponibilidad de los aparatos de manejo de materiales, los tiempos reales pueden ser bastan-
te diferentes entre sí en el curso de la operación del sistema. Debido a esto, el primer modelo
podría dar estimaciones razonables de la capacidad potencial máxima del sistema; sin embargo,
lo más probable es que no proporcionarían estimaciones muy exactas acerca de los tiempos
de ciclo de las piezas. El método más sencillo es incluir las transferencias restringidas por los
recursos. De este modo, supongamos que la capacidad de transferencia es de dos, con el mismo
tiempo de transferencia de dos minutos en todos los casos. Lo que significa que puede haber un
máximo de dos transferencias al mismo tiempo. Si otras entidades están listas para transferirse,
tendrán que esperar hasta que se complete una de las transferencias en curso.
El empleo de un recurso para restringir el número de transferencias simultáneas de entida-
des es una adición más o menos fácil para un modelo. Es necesario definir cómo se concibe una
nueva clase de transferencia de recursos, tomar una unidad de ese recurso antes de iniciar la
ruta para salir del lugar y dejarlo cuando se llega a la estación o lugar siguientes. Éste es un re-
curso común de Arena, pero se le concibe de modo diferente para modelar las transferencias.
Se tienen dos maneras diferentes con las que se podría añadir esta lógica al modelo existente.
La más obvia (al menos para nosotros) es insertar un módulo Seize (Tomar) del panel Advanced
Process (Proceso avanzado), precisamente antes de cada uno de los módulos Route existentes
(en el modelo actual, se tienen cinco). Cada módulo Seize solicitaría una unidad del recurso de
transferencia; por ejemplo, Transfer (Transferencia). También se necesitaría cambiar a
2 la capacidad de este nuevo recurso en el módulo de datos de Resource (Recurso). Existe un
concepto adicional que debe de considerarse mientras se están haciendo tales modificaciones:
“¿cada módulo Seize debe tener una cola separada?”. Si se usa una sola cola compartida (véase la
sección 5.4.5 y el modelo 5-1) para todos los módulos Seize recientemente introducidos, entonces
el recurso se repartiría con base en una regla FIFO. Si se especificara una cola diferente en cada
módulo Seize, se tendría la posibilidad de aplicar prioridades al proceso de selección. Por ejemplo,
se podría querer dar a las entidades de nuevo arribo la prioridad más alta. Esto permitiría que las
piezas recién llegadas se enviarán a su primera operación tan pronto como sea posible, con la es-
peranza de que se permitiría iniciar el procesamiento de la pieza con una reducción resultante en el
tiempo del ciclo de ésta. (Si se pasara mucho tiempo reflexionando acerca de tal asunto, se podría
concluir que ésta es una lógica defectuosa.) Si todas las prioridades son las mismas, se finaliza con
la misma regla FIFO como con el enfoque de la cola compartida. De modo que parecería que los
dos procedimientos son los mismos. Esto no es por completo cierto si se planea mostrar las piezas
en espera en la animación (lo cual se hará aquí). Mediante el uso de colas separadas antes (lo pre-
determinado) de cada ruta, se pueden mostrar con facilidad las piezas en espera en la animación.
Habiendo tomado el recurso de transferencia, antes de transferir cada pieza a través de una
ruta, ahora se necesita liberar ese recurso una vez que esa pieza llega a su destino. Esto se lleva
330 Capítulo 8
a cabo al insertar un módulo Release (Liberar) después de cada módulo Station (Estación) en
el modelo. (La única excepción es Order Release Station [Estación de liberación de pe-
didos], el cual sólo se usa para decir a Arena la ubicación de las piezas recién llegadas.) En cada
uno de estos módulos, sencillamente se libera el recurso Transfer.
El segundo método es reemplazar los módulos Route con los módulos Leave (Salir) (del
panel Advanced Transfer, Transferencia avanzada) y los módulos Station con los Enter (Entrar)
(también del panel Advanced Transfer). El módulo Leave permite tomar el recurso y también
encaminar la pieza en el mismo módulo. De manera análoga, el módulo Enter permite combi-
nar las características de los módulos Station y Release. Aquí se elegirá este segundo método,
porque permite introducir dos módulos nuevos y facilita la conversión del modelo para incluir
otras características de transferencia.
El módulo Leave permite tomar un recurso de transferencia antes de que salga de la estación.
Cuál recurso tomar se puede definir como un recurso en particular, un conjunto de recursos,
un miembro específico de un conjunto o un recurso basado en la evaluación de una expresión.
También se puede especificar una Priority (Prioridad) en la lógica Transfer Out (Salida de la
transferencia), lo que permitiría controlar a cuál entidad se le daría el recurso de transferencia
si se está esperando más de una entidad. Entre menor sea el número, más alta será la prioridad.
Para el sistema que se está tratando, sólo tendrá que seleccionarse la opción Seize Resour-
ce (Tomar recurso) e introducir un nombre del recurso de transferencia. También se tendrá
que introducir la información adicional de enrutamiento.
Empecemos por reemplazar el módulo de Ruteo Start Sequence (Iniciar secuen-
cia) con el módulo Leave que se muestra en la pantalla 8-1. Se usará el mismo nombre de
módulo, Start Sequence, selecciónese la lógica de Transfer Out como Seize Resource
e introdúzcase el Resource Name (Nombre del recurso) como Transfer. Por último, selec-
ciónese Route como el Connect Type (Tipo de conexión), introdúzcase Transfer Time
(Tiempo de transferencia) en Move Time (Tiempo del movimiento), selecciónese Mi-
nutes (Minutos) así como By Sequence (En secuencia) como el Station Type (Tipo de
estación). En los cuadros restantes se han dejado los valores predeterminados. Nótese que esto
da colas separadas para las piezas que esperan el recurso Transfer. Destáquese también que
con la selección de la lógica Transfer Out del recurso, se agregó una cola (Start Sequen-
ce.Queue) al módulo cuando se aceptó el cuadro de diálogo. En este punto, se podría desear
mover esta cola a la posición apropiada en la animación.
Ahora se pueden reemplazar los cuatro módulos Route restantes con módulos Leave. Con
la excepción de Name (se usó el mismo nombre que el empleado en el módulo Route reempla-
zado), las entradas de datos son las mismas que las mostradas en la pantalla 8-1.
El módulo Enter permite liberar el recurso de transferencia y proporciona la opción de in-
cluir una demora por la descarga. Empecemos con el reemplazo del módulo Cell 1 Station
(Estación Celda 1) con un módulo Enter, como en la pantalla 8-2. Bórrese el módulo Sta-
tion existente y agréguese el nuevo módulo Enter. Se usará el mismo Name, Cell 1 Station,
y selecciónese Cell 1 como el Station Name (Nombre de estación) en la lista desplegable. En la
sección de lógica, sólo necesita seleccionar Release Resource (Liberar recurso) para
la entrada Transfer In (Entrada de transferencia) y seleccionar el recurso Transfer como el
Resource Name que debe liberarse.
Reemplácense los cuatro módulos Station restantes con módulos Enter (pero no el Order
Release Station). Como antes, las entradas de datos son las mismas que las que se mues-
tran en la pantalla 8-2, con la excepción de Name (se usó el mismo nombre que el que se ocupó
en el módulo Station reemplazado).
Transferencia de entidades 331
Siempre que ya se hayan movido las nuevas colas de espera hacia la animación, se está
casi listo para ejecutar el modelo. Antes de hacer eso, se debe de estar consciente de que toda-
vía no se ha definido la capacidad del recurso restrictivo, la cual determina el número máxi-
mo de piezas que pudieran estar en tránsito al mismo tiempo. Aunque se ha definido la existen-
cia de tal recurso, Arena establece de manera predeterminada una capacidad de 1 para él. Se ne-
cesitará abrir el módulo de datos de Resource (panel Basic Process [Proceso básico]) y cambiar
a 2 la capacidad del recurso Transfer. El modelo resultante se mira idéntico al modelo 7-1,
porque los reemplazos fueron uno por uno y se ocuparon los mismos nombres. Se usó la misma
animación, con la adición de las cinco nuevas colas de espera. En la figura 8-1 se muestran las
posiciones de estas últimas.
Si se ejecuta este modelo y se observa la animación, con rapidez se observará que rara vez
existe una pieza esperando para ser transferida. Si el lector tiene dudas acerca de la exactitud
de su modelo, cambie a 1 la capacidad del recurso Transfer y observe la animación. Si se
comparan los resultados de este modelo (con dos recursos Transfer) con los del modelo 7-1,
se verá un ligero aumento en el tiempo total de la pieza en el sistema, debido al tiempo que per-
manece esperando en una cola por el recurso Transfer. La diferencia es entre 3 y 9 minutos,
dependiendo del tipo de pieza.
332 Capítulo 8
Cell 1 Cell 2
Order Exit
Release System
Cell 4 Cell 3
Name Cart
Number of Units 2
Velocity 50
se describe en este libro, se sugiere que empiece con una copia del modelo 8-1, el cual se acaba de
completar. En este caso, sólo se necesita introducir el Name del transportador, Number of Units
(Número de unidades), Type (Free Path en comparación con Guided), el Distance Set (Conjunto
de distancias) al cual se referirá el transportador al moverse y calcular el tiempo para ello (lo
que se discute más adelante), la Velocity (Velocidad) y las Units (Unidades de tiempo) para esta
velocidad, así como la información sobre el Initial Position Status (Estado inicial de posición)
de los transportadores (pantalla 8-3). Se aceptarán los valores predeterminados para el nombre
del Distance Set (se regresará a este concepto más adelante), las Units (Unidades de tiempo), la
Initial Position de los carros y las Report Statistics (Estadísticas del informe).
Es necesario tener cuidado al definir la Velocity, de introducir una cantidad que sea apro-
piada para las unidades de tiempo y de distancia que se estén usando en el modelo. En tal caso,
se tomaron como predeterminadas las Units de tiempo como Per Minute (Por minuto), las
mismas unidades para la velocidad establecida, pero es necesario asegurarse que las distancias
se especifiquen en pies.
Habiendo definido el transportador, ahora se puede desarrollar la imagen que represente el
carro. Esto se hace casi de la misma manera que como se hizo para la entidad o el recurso. Ha-
ciendo clic en el botón Transporter ( ), que se encuentra en la barra de herramientas Animate
Transfer (Animar transferencia), se abre la ventana Transporter Picture Placement (Colocación de
la imagen del transportador). Reemplacemos la imagen predeterminada con un cuadro (se usó un
ancho de línea de 5 pixeles) que sea blanco, con una línea verde cuando se encuentre desocupado
y azul al hallarse ocupado. Cuando el carro esté llevando una pieza, Arena también necesita saber
en dónde colocarla en la imagen de carro ocupado. Esta colocación es semejante a un punto de
toma para un recurso. En tal caso, se llama Ride Point (Punto de estiba) y se puede hallar debajo
del menú Object (Objeto) de la ventana del Arena Picture Editor (Editor de imágenes de Arena),
al editar la imagen de ocupado. Si se selecciona Object > Ride Point se cambia el puntero a una
cruz de líneas delgadas. Muévase este puntero hasta el centro del carro y hágase clic. El punto de
estiba, el cual aparece como ⊗ en el carro ocupado, da como resultado que la entidad se coloque
en posición, de modo que su punto de referencia se alinee con ese punto. Cuando se haya termi-
nado de crear las imágenes, acéptense los cambios para cerrar la ventana de Transporter Picture
Placement. El puntero se convierte en la cruz de líneas delgadas que se debe posicionar en alguna
parte cercana a la animación y hacer clic. Esta acción coloca la imagen del carro desocupado en la
ventana del modelo. No es necesario preocuparse acerca de en dónde se coloca el transportador,
ya que sólo se acomoda en el modelo en caso de que se necesite reeditarlo posteriormente. En el
transcurso de una ejecución, esta imagen permanecerá oculta y, a través de la animación, se mo-
verán réplicas de ella por cada unidad transportadora por separado.
Transferencia de entidades 335
Para solicitar un carro en la lógica del modelo, se usarán los mismos módulos que se em-
plearon para tomar un recurso: los módulos Leave. En la pantalla 8-4 se muestran las entradas
para el módulo Leave Start Sequence. Las otras entradas del módulo Leave son idénticas,
excepto por sus nombres. Se ha introducido una demora de 0.25 minuto para tomar en cuenta
la actividad de carga y seleccionado la opción Request Transporter de la lista para el
tipo de Transfer Out. La entrada de Selection Rule determina cuál transportador se destinará
si, en el momento, más de uno están libres: Cyclic, Random, Preferred Order, Specific Member,
Largest Distance o Smallest Distance. Con la regla Cyclic se intenta establecer un ciclo a través
de los transportadores, nivelando de este modo sus utilizaciones. Con la Preferred Order se
intenta seleccionar siempre el transportador disponible con el número más bajo. Se ha elegido
la regla Smallest Distance, la cual conduce a destinar el carro más cercano a la entidad
solicitante. Se define un nuevo Attribute (Atributo), Cart # (# Carro) y se usa para guardar
336 Capítulo 8
el número del carro que se destinó (se habla más acerca de esto páginas adelante). También se
selecciona la opción Transport para el Connect Type. Nótese que cuando se hace esta selec-
ción, desaparece el campo Move Time. El tiempo real del movimiento se calculará a partir de la
distancia recorrida y la velocidad del transportador.
El módulo Leave realiza cuatro actividades: destinar un transportador, mover el transpor-
tador vacío hasta el lugar en el que se encuentra la pieza solicitante, establecer la demora por
el tiempo de carga y transportar la pieza hasta su destino. Existen maneras alternas para mo-
delar estas actividades. Por ejemplo, se podría haber usado la combinación de módulos Re-
quest-Delay (Demorar)-Transport para realizar las mismas actividades. El módulo Request
(panel Advanced Transfer) realiza las dos primeras; el módulo Delay, la actividad de carga,
y el módulo Transport (panel Advanced Transfer), la última actividad. Aunque esto requiere
tres módulos, en realidad proporciona algo de flexibilidad adicional en el modelado. Se pueden
especificar velocidades diferentes de recorrido, tanto para mover el transportador vacío como
para transportar la pieza hasta su lugar de destino. De hecho, se podría especificar la velocidad
de transportación como una expresión de un atributo de la pieza; por ejemplo, el peso de ésta.
También se podría reemplazar el módulo Delay con un módulo Process, lo cual podría requerir
la disponibilidad de un operario o de un manejador de materiales (modelados como un recurso)
para cargar la pieza. Por último, se podría reemplazar el módulo Request con una combinación
Allocate (Repartir)-Move (Mover). El módulo Allocate (panel Advanced Transfer) destina un
transportador, en tanto que el Move (panel Advanced Transfer) mueve el transportador vacío
hasta la ubicación de la pieza solicitante. Una vez más, esto permitiría insertar lógica adicional
entre estas dos actividades, si se requiriese tal lógica para modelar con exactitud el sistema.
Cuando la pieza llega a su ubicación siguiente, necesita liberar el carro de modo que
pueda ser usado por otras piezas. Con el fin de liberar el carro, se usarán los mismos módu-
los que se emplearon para liberar el recurso en el módulo anterior: los módulos Enter. En
la pantalla 8-5 se muestran las entradas para el módulo Enter Cell 1 Station (Entrar
a la estación celda 1). Las otras entradas del módulo Enter son idénticas, excepto por
sus nombres. Se ha introducido el Delay (demora) de descarga en minutos y se seleccionó la
opción Free Transporter para Transfer In. En el modelo que se está trabajando, también
se introdujo el Transporter Name, Cart, y el nombre del atributo en donde se guardó el Unit
Number (Número de la unidad), Cart #. Estos dos últimos campos se pudieron haber de-
jado vacíos. Arena sigue el rastro de cuál carro se destinó a la entidad y libera ese carro. Sin
embargo, si se introduce el Transporter Name y se tienen más de un transportador, también
se necesita registrar el Unit Number. Si sólo se introduce el Transporter Name, Arena siempre
intentaría liberar el primer transportador.
Como con el módulo Leave, el módulo Enter realiza múltiples actividades: definir la es-
tación, establecer la demora por el tiempo de descarga y liberar el transportador. De nuevo,
existen maneras alternativas para modelar estas funciones. Se pudo haber usado una combina-
ción de módulos Station-Delay-Free para efectuar las mismas actividades. El módulo Station
define la estación; el Delay, la actividad de descarga, y el Free (panel Advanced Transfer) libera
el transportador. La separación de estas tres actividades permitiría introducir lógica adicional
del modelo, si lo requiere el sistema. Por ejemplo, se podría reemplazar el módulo Delay con un
modelo Process, lo cual requeriría la disponibilidad de un operario o manejador de materiales
(modelados como un recurso) para descargar la pieza.
Transferencia de entidades 337
Hasta ahora, se han definido los carros y cambiado la lógica del modelo para Request,
Transport y Free de esos carros, para modelar la lógica requerida para transferir las piezas a
través del sistema. El tiempo real de recorrido depende de la velocidad del transportador, la cual
se establece con los carros y la distancia de la transferencia. Cuando se definieron los carros
(pantalla 8-3), se aceptó una referencia predeterminada para una Distance Set, con el nombre
(predeterminado) Cart.Distance (Carro.Distancia). Ahora se deben proporcionar es-
tas distancias de modo que Arena pueda consultarlas siempre que se presente una solicitud o
transporte. Empecemos por considerar sólo los movimientos desde una estación a la siguiente
hechos por las piezas conforme recorren su camino a través del sistema (véase la tabla 7-1). Tal
información se proporciona en la tabla 8-1. Estas entradas de tablas incluyen un par de estacio-
nes, o ubicaciones, así como la distancia (en pies) entre esas estaciones. Por ejemplo, la primera
entrada es para el movimiento de la Order Release hasta la Cell 1, la cual es una distancia
de 37 pies. Las entradas en blanco de la tabla 8-1 son para parejas desde-hasta que no ocurren
para los movimientos de la pieza (véase la tabla 7-1).
338 Capítulo 8
Hasta
Cell 1 Cell 2 Cell 3 Cell 4 Exit System
Order Release 37 74
Cell 1 45 92
Desde
A medida que se agregan las once distancias, se podría querer considerar también la activa-
ción de los comandos Grid (Cuadrícula) y Snap to Grid (Coincidir con cuadrícula) de la barra de
herramientas View (Ver). Se sugiere que agregue estas distancias en el orden en que aparecen en
la hoja de cálculo para el módulo de datos Distance. Con esto se evitará confusión, reducién-
dose la posibilidad de pasar por alto una. Si ocurriera que las distancias no se encuentran en
donde se les quiere, son fáciles de editar. Hágase clic sobre la línea de distancia para seleccio-
narla. Póngase atención especial a la forma del apuntador en el curso de este proceso. Cuando
se resalta la línea aparecerán los puntos de arrastre sobre la misma. Cuando se mueva el apun-
tador directamente sobre uno de estos puntos, cambiará a la cruz de líneas delgadas; hágase clic
y sosténgase para arrastrar el punto. Si el apuntador todavía tiene la forma de flecha y se hace
clic y se sostiene, se moverán todos los puntos interiores de la recta. Si, de modo accidental,
se hace esto, no hay que olvidar que se puede usar el botón Undo (Deshacer). Si se encuentra
que se necesitan puntos adicionales, o que se tienen demasiados, sencillamente hágase doble clic
sobre la línea de distancia para abrir el cuadro de diálogo y cambiar el número de puntos. Cuan-
do se agregan o se quitan puntos de la línea de distancia, siempre aparecerán o desaparecerán
en el extremo de la estación de destino de esa línea.
Si se corriera el modelo y se observara ahora la animación, se vería el transportador moviendo
las piezas por el sistema, pero una vez que se liberara el transportador, desaparecería de la anima-
ción hasta que empezara a moverse de nuevo. Esto se debe a que no se le ha indicado a Arena en
dónde tienen que estar los transportadores cuando queden vacíos. Se hace esto al agregar zonas
de estacionamiento a la animación. Si se hace clic en el botón Parking (Estacionamiento) ( ) de la
barra de herramientas Animate Transfer se abrirá el cuadro de diálogo Parking que se muestra en
la pantalla 8-8. La aceptación del diálogo cambiará el apuntador a la cruz de líneas delgadas. Si-
túese el apuntador cerca de la esquina inferior izquierda de una Station en la animación y hágase
clic. Conforme se mueva el apuntador, se debe de ver un contorno limitante estirándose desde la
estación hasta la posición en curso del propio apuntador. Si no se tiene esto, hágase clic de nueva
cuenta hasta lograrlo. Ahora colóquese el apuntador en donde se quiera que el transportador
se asiente al quedar vacío y hágase clic; muévase el apuntador hasta una posición en donde se
asentaría un segundo transportador vacío y hágase doble clic. Esto debe producir que se salga de
la actividad zona de estacionamiento y regrese el puntero a su flecha normal. Si de manera acci-
dental se crearan demasiadas (o muy pocas) zonas de estacionamiento, se puede hacer doble clic
en una de esas zonas que se agregaron y volver a abrir el cuadro de diálogo Parking Area. Úsese
el botón Points para editar el número de puntos o áreas de estacionamiento. En el ejemplo que se
está trabajando se quieren dos, porque es posible tener tantos como dos carros en el mismo lugar
al mismo tiempo. Repítase esta acción para cada estación en el modelo.
340 Capítulo 8
La colocación final para las estaciones Order Release y Cell 1 debe de verse como se ilustra
en la figura 8.2.
En este punto, el lector puede ejecutar el modelo y la animación pero, si lo hace, con gran
rapidez la ejecución se detendrá y aparecerá la ventana Arena Error/Warning (Error de Arena/
Advertencia). Se desplegará un aviso que indicará que no se ha especificado una distancia entre
un par de estaciones, lo que fuerza a Arena a suponer una distancia de 0 y se recomendará que
se resuelva el problema. (Arena supone de manera arriesgada que quien creó el modelo olvidó
introducir el valor.) Se puede cerrar esta ventana y continuar con la ejecución, pero volverá a
aparecer el mensaje. Lo más probable es que el problema sea causado por un carro que se está
liberando en las ubicaciones Exit System (Salida del sistema), Cell 3 o Cell 4,
cuando se está solicitando ese carro en la ubicación Order Release. Arena intenta transferir
hasta esta última ubicación y no puede encontrar una distancia; por lo tanto, se tiene un pro-
blema. De hecho, se tienen más problemas que sólo éste. Si se libera un carro en la Cell 1 o la
Cell 2 y se solicita en Order Release, viajará hacia atrás más de una vuelta en el sentido
del movimiento de las manecillas del reloj como se desea. Para evitar esto, se sumarán las dis-
tancias para todas las transferencias, con carga y en vacío, que podrían ocurrir.
En general, si se tienen n lugares, existen n(n – 1) distancias posibles. Se puede concebir esto
de manera aproximada como una matriz de n por n con ceros a lo largo de la diagonal. Esto
supone que todos los movimientos son posibles y que la distancia entre dos lugares cualesquie-
ra podría depender de la dirección de recorrido. Para el ejemplo, se tienen seis ubicaciones, es
decir, 30 distancias posibles (en el modelo, la distancia sí depende de la dirección del recorrido).
Cell 1
Order
Release
Desde
Order Release Cell 1 Cell 2 Cell 3 Cell 4 Exit System
Order Release 37 74
Cell 1 155 45 92 129
Cell 2 118 139 55 147
Hasta
Si las distancias no dependen de la dirección, sólo se tiene la mitad de este número de distancias.
Asimismo, a menudo se tienen muchos movimientos que nunca ocurrirán. En el ejemplo, se
puede requerir que el carro vacío se mueva desde la ubicación Exit System hasta la Order
Release, pero nunca en la dirección opuesta. (¡Piénsese acerca de ello!) Los datos contenidos
en la tabla 8-1 sólo fueron para los movimientos del carro cargado. Si se enumeran todos los
movimientos posibles del carro vacío y se elimina toda duplicación del primer conjunto, se
tienen las distancias adicionales que se dan en la tabla 8-2. Las entradas sombreadas correspon-
den a las primeras distancias de la tabla 8-1. En conjunto, se tienen 25 movimientos posibles.
Si el número de distancias se vuelve excesivo, se sugiere considerar el cambio a transporta-
dores guiados, en los cuales se usa una red en lugar de parejas de distancias por separado. En
relación con un repaso de los conceptos de los transportadores guiados, consúltese el capítulo 5
de la Arena User’s Guide (Guía del usuario de Arena) [que se encuentra a través de Help > Pro-
duct Manuals (Ayuda > Manuales del producto)] o en el capítulo 9, “Advanced Manufacturing
Features” (“Características avanzadas de fabricación”) de Pegden, Shannon y Sadowski (1995).
También se podría encontrar en el sistema de ayuda en línea de Arena para los temas relaciona-
dos con los transportadores guiados, asimismo, consúltese el ejemplo Smarts195.doe en la
carpeta Smarts (Inteligentes), la cual se encuentra adentro de la carpeta de Arena 10.0.
La animación final se verá muy semejante a la primera, pero cuando se ejecuta el modelo
se verán los carros moviéndose de uno a otro lado y las piezas con ellos. Todavía es posible que
uno de los carros aparezca encima de otro, ya que se están usando transportadores de camino
libre. Sin embargo, con sólo dos carros en el sistema, debe de ocurrir con mucho menos fre-
cuencia que en el modelo anterior, en el que se usaron rutas no restringidas. En la figura 8-3 se
muestra una vista de la ejecución de la animación aproximadamente en el tiempo 643.
Cell 1 Cell 2
Order Exit
Release System
Cell 4 Cell 3
un carro, la entidad deja de estar en la cola de peticiones en el curso del recorrido de ese carro
hasta su propia ubicación. (No es necesario detallar dónde se encuentra en realidad la entidad
en este momento.) La manera más sencilla de animar esta actividad es con la característica
Storage (Almacenamiento), usada en los modelos 5-2 y 5-3. Un almacenamiento de Arena es
un lugar para que la entidad resida mientras está esperando que el transportador se mueva has-
ta la ubicación en la que se encuentra, de modo que se mostrará en la animación. Cada vez que
una entidad entra a un almacenamiento, una variable de almacenamiento se incrementa en 1,
y cuando sale, tal variable disminuye en 1. Esto también permite obtener estadísticas referentes
al número en el almacenamiento.
Por desgracia, la opción almacenamiento no se encuentra disponible con los módulos que
se localizan en el panel Advanced Transfer. Sin embargo, se dispone de ella si se usan módulos
del panel Blocks (Bloques) [no se dispone de la vista de hoja de cálculo con los módulos de los
paneles Blocks o Elements (Elementos)]. Se mostrará brevemente cómo hacer los cambios ne-
cesarios al modelo que se está trabajando. Empecemos con el modelo 8-2 y guardémoslo como
modelo 8-3. Lo primero que se debe de hacer es borrar los cinco módulos Leave del modelo y
reemplazarlos con la combinación de módulos Queue-Request-Delay-Transport que se mues-
tra en la figura 8-4. (Los módulos mostrados en la figura 8-4 reemplazan el módulo Start
Sequence Leave.) Estos cuatro módulos se tomaron del panel Blocks.
Type Attribute
Name Cart #
Value 0
Al módulo Queue Block le sigue un módulo Request Block. Este módulo destina un Cart
vacío y lo mueve hasta la ubicación de la pieza. También permite especificar una ubicación de
almacenamiento, la cual se puede usar para animar la pieza durante el tiempo en que el carro
se mueve hasta ella. Los datos para las entradas Storage ID (Identificación del almacenamien-
to) y Entity Location (Ubicación de la entidad) se pueden seleccionar de la lista en la pantalla
8-12. La entrada Transporter Unit (Unidad del transportador) requiere explicación adicional.
En primer lugar, podría haberse advertido que el cuadro se encuentra sombreado, lo que indica
que éste es un campo requerido para este módulo. Existen tres formas diferentes que se pueden
usar para especificar el transportador. La primera es el Transporter ID (Number), en donde
Transporter ID es el nombre del transportador; en este caso, Cart. El Number es el número
de la unidad del transportador que se está solicitando. En el ejemplo, se tienen dos carros, de
modo que el número de la unidad sería 1 o 2. Por lo tanto, si se aplica esta forma, en efecto
se está solicitando un carro específico. También se debe de estar consciente que si se omite el
Number, Arena lo toma de manera predeterminada como 1. La segunda forma es Transporter
ID (TSR) en donde las siglas TSR aluden a la regla de selección del transportador (transporter
selection rule). Para el ejemplo, ésta sería la regla de la distancia más corta, SDS (del inglés
Smallest Distance to Station). Cuando se usa el módulo Request Block, se debe emplear la de-
signación de Arena para estas reglas. La última forma es Transporter ID (TSR,AttributeID),
en donde AttributeID es el nombre del atributo en donde Arena debe de almacenar el número
seleccionado de la unidad del transportador. En el ejemplo, éste sería el atributo Cart #. Por
consiguiente, la entrada es Cart (SDS,Cart #).
Transferencia de entidades 345
Duration 0.25
Storage ID Order Release Pickup
Cuando el carro llega a la estación de levantamiento, la pieza saldrá del módulo Request
Block y entrará al módulo Delay Block, como se ilustra en la pantalla 8-13. Se ha introducido
la demora debida a la acción de cargar, 0.25, y una segunda Storage ID, Order Release
Pickup (Levantamiento en la liberación del pedido). Se discutirá por qué se
agregó este segundo almacenamiento al modificar la animación.
Una vez que la pieza se ha cargado en el Cart, se envía al módulo siguiente Transport Block,
como se ve en la pantalla 8-14. Allí se introdujo el carro que se va a usar, Cart(Cart #), y el
destino, SEQ, (el nombre abreviado de Arena para Sequence). En este ejemplo, en forma inten-
cional se ha seguido el rastro del Cart que se destinó, de modo que se pudiera tener la seguridad
de que se ha liberado el carro correcto a la llegada a la estación de destino.
Los módulos restantes se llenaron con las mismas entradas como éstas, excepto por los valo-
res de la Entity Location de la Storage ID (los cuales son específicos para la ubicación).
Modifiquemos ahora la animación. En primer lugar se debe de comprobar si las colas de
espera han desaparecido (como en el caso del ejemplo del libro). La razón por la que desapa-
recieron es que fueron parte de los módulos Leave que se reemplazaron. Sencillamente, se han
movido las colas que vinieron con los módulos Leave al lugar apropiado en la animación. Si
se ha usado el botón Queue ( ), que se encuentra en la barra de herramientas Animate para
añadir las colas, todavía estarían allí. Si no se hizo así, sígase adelante y utilícese ese botón para
añadir las cinco colas de espera.
Ahora es necesario agregar los diez almacenamientos. Se usará el botón Storage ( ) de la ba-
rra de herramientas Animate Transfer para hacer estas adiciones. Se colocaron las colas de espera
de modo que hubiera espacio entre el punto de levantamiento y la cola para que se puedan colo-
car los almacenamientos de levantamiento. Se necesitan dos posiciones para cada levantamiento,
346 Capítulo 8
porque se podrían tener tantos como dos carros moviéndose hacia un lugar al mismo tiempo.
Entonces se colocó el almacenamiento de levantamiento directamente sobre la posición de esta-
cionamiento, en donde el carro se asentará en el transcurso de su operación de carga. Sólo se usó
un almacenamiento para la posición de levantamiento, aun cuando es posible que se tengan dos
piezas levantándose en la misma estación al mismo tiempo. Si éste fuera el caso, el segundo carro
y la segunda pieza se asentarían en la parte superior del primero. Si se quiere ver con exactitud
cómo se hace esto, se sugiere echar un vistazo al archivo Model 08-03.doe. Si se ejecuta la
simulación desarrollada por el lector (o la del texto), se verá la pieza inicialmente en la cola de es-
pera. Tan pronto como un carro queda disponible y se destina a la pieza, la imagen de esta última
se moverá hasta el almacenamiento de levantamiento y permanecerá allí hasta que el carro llegue
a la estación. En ese momento, la pieza aparecerá sobre el transportador y permanecerá allí hasta
que se complete la demora para la actividad de cargar. Enseguida, la pieza saldrá con el carro.
Existe una manera más sencilla de crear una animación en donde las piezas no desapare-
cen en el transcurso del movimiento y la actividad que produce demora. En este método, se
usaría una combinación de módulos Store-Request-Delay-Unstore (Almacenar-Solicitar-De-
morar-Desalmacenar), en lugar de los módulos de Leave. Los módulos Request y Transport
son del panel Advanced Transfer, en tanto que los módulos Store y Unstore se encuentra en
el panel Advanced Process. Estos dos últimos módulos permiten aumentar y disminuir los al-
macenamientos. Si se aplica este método, no se animaría la cola de espera. Todas las piezas se
colocarían en un solo almacenamiento, mientras esperaran a que se les destine un carro, para
que éste se moviera hasta la estación y por la demora por el tiempo de carga. Se ha elegido no
proporcionar los detalles, pero siéntase libre para intentarlo por sí mismo.
Antes de ejecutar el modelo, se debe de usar el comando Run > Setup (Ejecutar > Configura-
ción) y solicitar que se reúnan las estadísticas del transportador [la tabulación Project Parameters
Transferencia de entidades 347
(Parámetros del proyecto)]. Si se observa la animación, rara vez se verá una cola de piezas espe-
rando por los carros, de modo que no son de esperarse diferencias importantes entre esta ejecu-
ción y la original (modelo 8-1). Los carros sólo se encuentran en uso alrededor de 60% del tiempo.
Una vez más, se debe ser cauto contra la suposición de que no existen diferencias entre estos dos
sistemas. El tiempo de ejecución es relativamente corto, y puede ser que todavía se halle en un
estado de arranque transitorio (si se tiene interés en el comportamiento de estado estacionario),
para no mencionar los efectos de la variación estadística que pueden nublar la comparación.
Si se cambia la velocidad del carro a 25 (la mitad de la velocidad original) y se corre el
modelo, se verá que no se tiene una diferencia enorme en los resultados entre las ejecucio-
nes. Si se piensa acerca de esto, en realidad tiene sentido. La distancia promedio recorrida por
movimiento del carro es menor de 100 pies, y cuando los carros se mueven se ocupan más, lo
que hace menos probable que viajen vacíos (a veces conocido como viaje de vuelta sin carga).
Recuérdese que si se libera un carro y se tienen varias solicitudes, el carro tomará la pieza más
cercana. De modo que el tiempo promedio del movimiento de la pieza sólo es de alrededor de
2 minutos. Asimismo, hubo un tiempo de carga y de descarga de 0.25 minutos, lo cual perma-
nece inalterado (¿recuerda la regla de cálculo?). Se podría sugerir que se experimente con este
modelo cambiando la velocidad del carro, los tiempos de carga y descarga, la regla de selección
del transportador y el número de carros, para ver cómo se comporta el sistema. Por supuesto,
se debe de realizar un número apropiado de replicaciones y efectuar las comparaciones estadís-
ticas correctas, como se describió en el capítulo 6.
Cell 1 Cell 2
Order Exit
Release System
Cell 4 Cell 3
Para hacer que las características del transportador se flexibilicen tanto como sea posible,
Arena permite definir el tamaño de celda; es decir, dividir la longitud del transportador en una
serie de celdas consecutivas de igual tamaño. Cada celda no puede contener más de una entidad.
Esto crea un dilema un tanto interesante porque sería deseable que las celdas fueran tan peque-
ñas como sea posible, con el fin de obtener la mayor exactitud del modelado, no obstante tam-
bién se podría anhelar que las celdas fueran tan grandes como sea posible para obtener la mayor
eficiencia computacional. Considérese un ejemplo sencillo para ilustrar este dilema. Se tiene un
transportador con 100 pies de largo y se quiere transportar piezas de 2 pies de largo. Debido a
que se han expresado las longitudes en pies, la primera respuesta podría ser fijar el tamaño de
celda en 1 pie. Esto significa que el transportador tiene 100 celdas y que cada pieza necesita dos
celdas para transportarse. Se pudo haber fijado con igual facilidad el tamaño de celda en 2 pies
(50 celdas) o en 1 pulgada (1 200 celdas). Con las computadoras actuales, ¿por qué debe sentirse
preocupación acerca de si se tienen 50 o 1 200 celdas? Debe de haber un impacto despreciable
sobre la velocidad de computación del modelo, ¿cierto? Sin embargo, se han visto modelos que
han incluido más de 5 millas de transportadores continuos, y es evidente que existe preocupación
acerca de la velocidad del modelo. La diferencia entre el tamaño de celda de 1 pulgada o de 100
pies tendría un impacto significativo sobre el tiempo para ejecutar el modelo.
Por lo tanto, ¿por qué no siempre se hacen las celdas tan grandes como sea posible? Bien,
cuando una entidad intenta tener acceso a un transportador, sólo se permite cuando al final
de la celda anterior, o al principio de la siguiente, el transportador queda alineado con la ubi-
cación de la entidad. En la analogía de la escalera mecánica, esto corresponde a esperar a que
aparezca el siguiente escalón en la zona de carga. Considérese la situación en donde acaba
precisamente de llegar a un transportador vacío e intenta abordarlo. Se ha especificado un
tamaño de celda de 100 pies y el final de la última celda acaba de pasar por ese lugar, digamos
en 1/2 pulgada. La entidad tendría que esperar a que llegue el final de la celda en curso, en
99 pies 11 1/2 pulgadas. Si se hubiera especificado el tamaño de celda en 1 pulgada, la espera
sólo habría sido para que pasara 1/2 pulgada de espacio del transportador.
El mensaje básico es que se necesita considerar el impacto del tamaño de celda con respecto a
la aplicación específica que se está modelando. Si el transportador no se utiliza con intensidad, o
Transferencia de entidades 349
la leve demora potencial en el ritmo no tiene impacto sobre el comportamiento del sistema, uti-
lícese un tamaño grande de celda. Si cualquiera de tales factores es crítico para el desempeño del
sistema, empléese un tamaño pequeño de celda. Existen dos restricciones a considerar al tomar
esta decisión. El tamaño de la entidad, expresado en número de celdas, debe ser un entero, de
modo que no se pueda tener una entidad pidiendo 1.5 celdas; se tendría que usar una o dos celdas
como el tamaño de la entidad. También, los segmentos del transportador (la longitud de una sec-
ción del transportador de un lugar a otro) deben constar de un número entero de celdas. De modo
que, si el transportador tuviera 100 pies de largo, no se podría usar un tamaño de celda de tres.
Antes de empezar a agregar transportadores continuos al modelo, pasemos por unos cuan-
tos conceptos más que se espera sean útiles cuando el lector trate de construir sus propios mo-
delos con transportadores. Como con Resources y Transporters, los Conveyors tienen varias
palabras claves: Access (Tener acceso), Convey (Transportar) y Exit (Salir). Para transferir una
entidad con los transportadores continuos de Arena, primero se debe Acceder (Access) al espa-
cio en el transportador, enseguida Acarrear (Convey) la entidad hasta su destino y, por último,
Salir (Exit) de ese transportador (para liberar el espacio). Para representar la disposición física,
un transportador continuo de Arena consta de una serie de segmentos que se enlazan entre sí
para formar un transportador completo. Cada segmento se inicia y termina en una estación
de Arena. Sólo se pueden enlazar estos segmentos para formar un transportador lineal o de
circuito cerrado. Por consiguiente, un transportador simple no puede tener un punto de diver-
gencia que dé por resultado una división en dos o más líneas corriente abajo, o un punto de
convergencia en donde se unan dos o más líneas corriente arriba. Por ejemplo, en un sistema
divergente, se transportaría la entidad hasta el punto de divergencia, Acceder (Access) al espa-
cio en el transportador apropiado siguiente, Salir (Exit) del transportador en curso y Acarrear
(Convey) la entidad hasta su destino siguiente. Para el pequeño sistema de fabricación que se
está manejando, se usará un transportador continuo de un solo circuito cerrado.
Arena tiene dos tipos de Conveyors: Nonaccumulating (No acumuladores) y Accumulating
(Acumuladores). Los dos tipos viajan sólo en una dirección y no se pueden invertir. Estos trans-
portadores funcionan de manera muy semejante a como su nombre lo implicaría. Ejemplos de
un transportador no acumulador sería uno de cangilones o de banda, o la escalera mecánica
que se ha estado mencionando. El espaciamiento entre las entidades que viajan sobre estos
tipos de transportadores nunca cambia, a menos que una de aquéllas salga y vuelva a tener
acceso al espacio. Debido a esta restricción, los transportadores continuos no acumuladores
operan de una manera única. Cuando una entidad adquiere el espacio sobre este tipo de trans-
portador, en realidad todo el transportador suspende el movimiento o se desembraga. Cuando
la entidad se transporta, el transportador se vuelve a embragar mientras la misma viaja hacia
su destino. El transportador se detiene cuando la entidad llega a su destino, dicha entidad sale
y el transportador vuelve a arrancar. No transcurre tiempo entre Access y Convey, o cuando la
entidad llega a su destino y, a continuación, sale; entonces es como si el transportador nunca se
detuviera. Sin embargo, sí existe una demora —como para toda actividad de carga o descarga,
de duración positiva, el cual es el caso para el sistema que se está tratando—, se verá que el
transportador se detiene temporalmente mientras ocurre la carga o descarga.
Los transportadores acumuladores difieren en el sentido de que nunca suspenden el movi-
miento. Si una entidad se detiene sobre un transportador acumulador, todas las demás enti-
dades en ese transportador seguirán su camino. No obstante, la entidad detenida impide que
cualesquiera otras entidades lleguen a ese lugar, de modo que las entidades que arriban se acu-
mulan detrás de la entidad que bloquea. Cuando la entidad bloqueadora sale del transportador
350 Capítulo 8
o sigue su camino, las entidades acumuladas también quedan en libertad para moverse hacia
sus destinos. Sin embargo, dependiendo de los requisitos de espaciamiento especificados en el
modelo, puede ser que no todo empiece a moverse al mismo tiempo. Se podría pensar en los
automóviles acumulados o bloqueados en una autopista. Cuando los autos se detienen, tienden
a estar bastante próximos entre sí (principalmente para impedir que algún conductor desconsi-
derado se meta por delante de ellos). Cuando se elimina el bloqueo, los automóviles empiezan
a moverse, uno a la vez, para dejar más espacio entre ellos. Páginas adelante, en este capítulo, se
describirán estos requisitos de datos.
gitudes del transportador (en realidad, se hizo un poco de trampa con estas longitudes para llevar
a cabo este trabajo). Puesto que se requieren 6 pies de espacio para cada pieza, se tiene un máximo
de dos celdas ocupadas por cada pieza. Arena requiere esta información para asegurar que tiene
suficiente espacio de almacenamiento para seguirle el rastro a una entidad, cuando llegue al final
del transportador. Puesto que el transportador continuo del ejemplo es un circuito cerrado y no
tiene final, en realidad no tiene impacto para este modelo. Pero, en general, se necesita introducir
el número más grande de celdas que cualquier entidad puede ocupar durante el tránsito.
La incorporación de transportadores continuos en el modelo es muy semejante a la inclu-
sión de transportadores discretos, por lo que no se entrará en una gran cantidad de detalles. Es
necesario cambiar todos los módulos Leave y Enter, de modo muy semejante a como se hizo
con los transportadores discretos. En la pantalla 8-16 se muestran las entradas para el módulo
Leave llamado Start Sequence. Se han incluido sólo los cambios que se requirieron par-
tiendo del modelo 8-1. Se podría advertir que cada pieza requiere dos celdas (cada una con un
tamaño de 3 pies) para acceder al transportador, y que se ha utilizado la variable Load Time
que se sugirió al principio.
En la pantalla 8-17Name
se muestran las entradas Loop
para elConveyor.Segment
módulo Cell 1 Station Enter.
Ahora se está listoBeginning
para colocar los
Station segmentos del transportador
Order Release continuo en la animación.
Como fue el caso con las distancias (Distances) usadas en el último modelo, en primer lugar
se necesitarán definir los datos del segmento requeridos tanto por el modelo como por la ani-
mación. Se definen estos
Name segmentos con el uso Cell
del módulo de datos Segment (Segmento) que
1 Station
Station Type Station
se encuentra en el panel Advanced Transfer. En la pantalla 8-18 se muestra la primera entrada
para la vista principalStation Name
de hoja Cell 1
de cálculo de este módulo. De manera arbitraria, se inició el
Logic
Loop Conveyor (Transportador continuo de circuito cerrado) en la estación
Delay Unload Time
Order Release. Units Minutes
Transfer In Exit Conveyor
Conveyor Name Loop Conveyor
La pantalla 8-19 muestra las entradas de datos de la hoja de cálculo para los seis segmentos.
Nótese que, para ese segmento, la Length se expresa en términos de la longitud real, no del
número de celdas. Estas longitudes se toman directamente de los valores proporcionados en la
figura 8-5.
Ahora el lector está listo para agregar los segmentos a la animación. En principio, se necesi-
tará mover cada símbolo de estación hasta el centro del circuito cerrado principal, directamente
enfrente de donde la pieza entrará al transportador o saldrá de él. Para añadir los segmentos,
se usa el botón Segment ( que se encuentra en la barra de herramientas Animate Transfer. Se
agregan los segmentos de modo muy semejante a como se incorporaron las distancias, excepto
en este modelo, sólo es necesario agregar seis segmentos. En la pantalla 8-20 se muestra el cua-
dro de diálogo Segment desde Release Order hasta Cell 1, en donde sencillamente se han
aceptado los valores predeterminados.
Para este modelo, sólo se necesitan colocar seis segmentos, como se muestra en la figura
8-6. Conforme van colocándose los segmentos, puede ser que se encuentre necesario volver a
colocar en posición los símbolos de estación, para hacer que los segmentos permanezcan en el
centro del circuito (¡y se hizo!).
Ahora se está casi listo para ejecutar el modelo animado. Primero se debe de usar el comando
Run > Setup (Ejecutar > Configuración) y solicitar que se reúnan las estadísticas del transporta-
dor continuo (la tabla Project Parameters). Si se ejecuta el modelo por completo, se notará que,
en el reporte, se incluyen dos nuevas estadísticas para el transportador. La primera expresa que el
transportador se bloqueó, o detuvo, alrededor de 17.65% del tiempo. Aun cuando, en un principio,
éste pueda parecer un valor grande, se debe de tener en cuenta de que cada vez que una pieza sale
de una estación o entra a ésta, tiene una demora por la actividad de carga o descarga. Durante tal
tiempo, el transportador se detiene o bloquea. Si se considera el número de movimientos y el de
piezas que han pasado por el sistema, este valor parece plausible. Si todavía no se está convencido,
todos los números se encuentran allí para tener una aproximación de lo que tal valor debe de ser.
La segunda estadística hace ver que el transportador se utilizó sólo alrededor de 6.6% del tiem-
po. Ésta no es la cantidad de tiempo que una pieza estuvo sobre el transportador, sino la cantidad
promedio de espacio ocupado por las piezas sobre éste. Ello es fácil de comprobar. Se puede deter-
minar la longitud total (168 pies) del transportador usando las longitudes proporcionadas en la fi-
gura 8-5. Sabiendo que cada celda tiene 3 pies, se puede determinar el número de celdas (56). Cada
pieza necesita dos celdas, lo que significa que el transportador sólo puede contener un máximo de
28 piezas en cualquier momento. Por lo tanto, si se multiplica la capacidad del transportador, 28
piezas, por la utilización promedio, (0.066), se sabe que en promedio se tuvieron alrededor de 1.85
piezas sobre ese transportador. Si se observa la animación, esto parecería ser correcto.
Si se comparan los tiempos del sistema para las piezas con las del modelo 8-1 se encontrará
que, en el modelo presente, son ligeramente más altos. Dados el bloqueo del transportador y la
velocidad, esto también parece ser razonable.
Si no se puede ver la detención del transportador en el curso de la actividad de carga y des-
carga (incluso si se fija el factor de velocidad de la animación en su ajuste más bajo), cámbiese
estas variables a 2 o 3 minutos. Con estos nuevos valores, más elevados, la detención debe de
ser bastante obvia.
También existen diversas maneras alternativas para cambiar los valores de las variables en el
curso de una simulación. Si se quieren hacer con frecuencia esos cambios en el curso de la ejecu-
ción de una simulación, se podría tener la intención de considerar el uso de la interfaz de Arena
para Visual Basic® for Applications (VBA, Visual Basic® para aplicaciones) (véase el capítulo
10). El segundo método es usar el Run Controller (Controlador de ejecución) accionado por
comandos de Arena. Empiécese ejecutando el modelo y, después de que haya corrido durante
un rato (se esperó hasta alrededor del tiempo 445), utilícese el comando Run > Pause (Ejecución
> Pausa), o bien, el botón Pause ( ) de la barra de herramientas Standard, para suspender de
manera temporal la ejecución del modelo. Entonces utilícese Run > Run Control > Command
(Ejecutar > Control de ejecución > Comando) o el botón Command ( ) de la barra de herra-
mientas Run Interaction (Interacción con la ejecución) para abrir la ventana del comando. Esta
ventana de texto tendrá presentado el tiempo en curso de la simulación, seguido por “>” como
un mensaje. Arena se encuentra listo para que se le introduzcan los comandos. Se usó el coman-
do SHOW (MOSTRAR) para ver el valor en curso de la variable LOAD TIME y, a continuación,
el comando ASSIGN (ASIGNAR) para cambiar ese valor (véase la figura 8-7). Enseguida, se
repiten estos dos pasos para el Unload Time. Ahora ciérrese esta ventana y utilícese la opción
de menú Run > Go (Ejecutar > Ir) o el botón Go ( ) de la barra de herramientas Standard para
ejecutar la simulación con los nuevos valores de las variables del tiempo en curso.
Si se observa la animación, en un periodo muy corto, se verá que el movimiento del trans-
portador es bastante desigual y que con prontitud se llena con más de diez piezas. Se puede
detener la ejecución de la simulación en cualquier momento para cambiar estos valores. Vale
Transferencia de entidades 355
458.39347 Minutes>
SIMAN Run Controller.
458.39347 Minutes>SHOW Load Time
LOAD TIME = 0.25
458.39347 Minutes>ASSIGN Load Time = 2
458.39347 Minutes>SHOW Unload Time
UNLOAD TIME = 0.25
458.39347 Minutes>ASSIGN Unload Time = 2
458.39347 Minutes>
la pena hacer notar que los cambios que se hacen en el Run Controller son temporales. No se
guardan en el modelo y la siguiente ocasión en que se ejecute éste, usará los valores originales
para estas variables.
Aun cuando observar la animación y hacer estos tipos de cambios a medida que se ejecuta
el modelo son maneras excelentes de verificar éste, no deben de cambiarse las condiciones del
modelo en el curso de la ejecución cuando, finalmente, se está usando ese modelo para los fines
de evaluación. Esto puede dar valores muy engañosos del comportamiento en los resultados y,
en esencia, será imposible replicar.
Type Accumulating
Accumulation Length 4
Pantalla 8-21. El cuadro de diálogo del módulo de datos del transportador continuo acumulador
356 Capítulo 8
8.6 Ejercicios
8-1 Cambie el modelo del ejercicio 7-4 para incluir montacargas de horquilla con el fin de
transportar las piezas entre las estaciones. Suponga que se tienen dos montacargas y que cada
uno viaja a 85 pies por minuto. Cargar y descargar una pieza por el montacargas requiere 0.25
minutos. En la tabla que sigue se da la distancia entre estaciones (en pies); nótese que, en gene-
ral, las distancias son direccionales:
Hasta
Arrive WS A WS B WS C Exit System
Arrive 0 100 100 200 300
WS A 100 0 150 100 225
Desde
Corra su simulación durante 100 000 minutos (puede ser que desee interrumpir la anima-
ción a través del comando Run > Run Control > Batch Run [No Animation], (Ejecutar> Control
de ejecución > Ejecutar en lotes [Sin animación]), después de confirmar que las cosas están fun-
cionando con propiedad). Suponga que los montacargas permanecen en la estación en donde
descargan la última pieza, si no está pendiente otra solicitud. Si están disponibles los dos mon-
tacargas, asuma que se selecciona el más cercano.
8-2 Cambie el modelo del ejercicio 7-4 para usar transportadores continuos no acumuladores
con el fin de transferir las piezas entre las estaciones. Suponga que se tiene un solo transportador
continuo que se inicia en la zona de llegada y continúa hasta la de salida: Arrive-WS A-WS B-WS
C-Exit (Llegada…Salida). Asuma que las distancias entre todas las estaciones adyacentes sobre
el transportador son de 100 pies. Suponga además que las celdas del transportador tienen 2 pies y
que cada pieza requiere 4 pies de espacio del transportador. Los tiempos de carga y descarga son
cada uno de 0.25 minutos. La velocidad del transportador es de 20 pies por minuto.
Transferencia de entidades 357
8-3 Cambie el modelo del ejercicio 5-2 para usar un montacargas (45 pies/minuto) para el
transporte de piezas en el sistema. Imagine que las piezas llegan a un andén de entrada y salen
en un segundo andén. Suponga que la distancia entre el andén de entrada y la Machine 2 (Má-
quina 2) es de 200 pies; todas las demás distancias son de 100 pies. Anime su solución.
8-4 Usando el modelo del ejercicio 8-3, fije el número de transportadores (discretos) en cua-
tro y haga tres ejecuciones usando las reglas de selección de los transportadores de Smallest
Distance, Largest Distance y Cyclical. Compare los resultados usando el Cycle Time (Tiempo
del ciclo) promedio.
8-5 Modifique el modelo 4-3 para incluir el uso de un solo montacargas para transferir las
piezas de las dos zonas de preparación a la de sellado. Suponga que la distancia entre cualquier
par de las tres estaciones es de 100 pies y que el montacargas viaja a razón de 75 pies por minu-
to. Anime su solución.
8-6 Modifique el modelo 4-3 para incluir el uso de dos transportadores continuos para trans-
ferir las piezas de las dos zonas de preparación a la de sellado. Los dos transportadores tienen
100 pies de largo y están constituidos por 20 celdas de 5 pies cada una. La velocidad de los
transportadores es de 30 pies por minuto. Anime su solución.
Tobogán
Inspección Escaneo
Maletas rechazadas
visual secundario
358 Capítulo 8
y se remiten para salir del sistema. Todos los transportadores son no acumuladores con una
velocidad de 40 pies por minuto. Cada maleta requiere un pie de espacio sobre cada uno de los
transportadores. Desarrolle un modelo de este sistema y ejecútelo durante 2 000 minutos. Use
una ruta restringida por los recursos para modelar el segundo escáner.
El diseño actual demanda una capacidad del tobogán de 20, en la zona de escaneo ini-
cial, y una capacidad total de 25 en la zona de escaneo secundario, sin incluir la maleta que
pasa por la inspección visual. ¿Qué porcentaje del tiempo esperaría el lector que se sobrepasara
esta capacidad? (Resuelva este ejercicio con capacidades infinitas de los toboganes y sólo obser-
ve el porcentaje del tiempo que se rebasarían las capacidades de los toboganes contempladas
en el párrafo anterior, si se pusieran en vigor.) PISTA: Agréguense dos estadísticas persisten-
tes en el tiempo para reunir esta información, usando expresiones lógicas que evalúen a cero si
el número de maletas es menor que la capacidad y a uno si se sobrepasa esa capacidad.
a) Suponga que la prioridad es tal que usted quiere transferir las tarimas que han estado
esperando durante más tiempo. [PISTA: Introduzca el nombre del atributo con el tiem-
po de llegada en el cuadro de prioridad del cuadro de diálogo Transfer Out (Transferir
hacia fuera).]
b) Debido a que se quiere tener la seguridad de que un camión entrante siempre pueda
descargarse, modifique su modelo del inciso a) anterior, de modo que la prioridad del
levantamiento se coloque en el andén de entrada con la mayor parte de tarimas. (PIS-
TA: Desarrolle una expresión usando NQ para el campo de prioridad.)
¿Cuál de las dos opciones anteriores parecería ser “la mejor”? Asegúrese de justificar sus con-
clusiones con un análisis estadístico válido. Además, para cada opción, estudie el efecto de
tener más montacargas (hasta siete); de nuevo, tenga conciencia de la brecha en la credibilidad
que resulta de un análisis estadístico inadecuado.
CAPÍTULO 9
Verdadero
0 Demora por tiem-
Estación de Espacio en la Salir en la Proceso en la
po de descarga
la Celda 1 Celda 1 Celda 1 Celda 1
en la Celda 1
0
0
Falso
Transportar Tener acceso Demora por Transportar
de regreso a al transportador el tiempo de desde la
la Celda 1 en la Celda 1 carga Celda 1
Con el fin de desarrollar el modelo nuevo, se empezará con el modelo 8-4 y se reemplazarán los
módulos Enter y Leave para la Cell 1 con los módulos nuevos, como se muestra en la figura 9-1.
En el módulo Enter que se está reemplazando se definió la estación, con el nombre de Cell
1 y también se salió del transportador. La definición de la estación es crítica porque Arena debe
saber hacia dónde enviar una entidad que se está transportando hacia la Cell 1. Por lo tanto,
se inició el reemplazo del conjunto de módulos con un módulo Station (Estación) del panel
Advanced Transfer, con el fin específico de definir el punto de entrada a la estación Cell 1.
Para este fin, también se pudo haber usado el módulo Enter, pero se desea mostrar el módulo
Station. El módulo Station sencillamente define la entrada lógica para las entidades que se es-
tán transfiriendo a esa estación. En el caso presente, el único valor proporcionado en el cuadro
de diálogo es el nombre de la estación, lo que se muestra en la pantalla 9-1.
Cuando una entidad, o pieza, llega a la estación Cell 1 se debe comprobar el estado de la
cola de espera, antes de determinar su destino. Se provoca que esto suceda enviando la entidad
al módulo Decide (Decidir), en donde se hace la comprobación para ver si el número de enti-
dades en la cola Cell 1 Process.Queue (Proceso en Celda 1.Cola) es igual a 0, lo
que se muestra en la pantalla 9-2. Éste es el mismo nombre de cola usado en el modelo 8-4, y se
definió en el módulo Process. Si, en este momento, la cola está ocupada por otra entidad, la que
llega tomará la rama False (Falso) del módulo.
En este caso, no se quiere que salga del transportador; en lugar de ello, se desea dejar la
pieza sobre ese transportador de circuito cerrado y llevarla por todo el circuito de regreso a la
misma estación. Esto se lleva a cabo enviando la entidad al módulo Convey, de la pantalla 9-5,
en donde se transporta la entidad en torno al circuito y de regreso a la Cell 1.
Transportar
de regreso a
la Celda 1
Salir en la
Celda 1
que la entidad se muestre en la animación, si tiene que esperar para que haya espacio disponible
en el transportador. Name Access Conveyor at Cell 1
Conveyor Name Loop Conveyor
Una vez que tiene acceso
# of Cells al espacio sobre 2
el transportador, la entidad se demora durante
el Load Time (Tiempo de Carga), a continuación, se envía hacia el módulo Convey en
donde se transporta según su secuencia especificada, Esto completa los módulos de reemplazo
para la Cell 1 del modelo 8-4.
También se necesita realizar el mismo conjunto de operaciones para la Cell 2. Sencillamente
repítanse estos pasos o hágase una copia de estos módulos y edítense por separado. Se eligió sólo
reemplazar el módulo Enter, conservando el Leave, para la Cell 2, como se muestra en la figura
9-2. Se supondrá que ahora ya el lector se siente cómodo haciendo los cambios requeridos.
Cuando se borran los módulos Enter y Leave, puede hallarse que también se ha borrado
esa parte de la animación. Esto se debe a que, con el módulo Leave, se recibió una cola ani-
Tener acceso al
transportador en
la Celda 1
Verdadero
Estación de 0 Transportar
Espacio en la Salir en la Proceso en la
la Celda 2 desde la
Celda 2 Celda 2 Celda 2
Celda 2
Falso 0
0
Transportar de
regreso a la
Celda 2
mada “libre”. Al editar o cambiar un modelo como éste, con frecuencia es más fácil animar
las características nuevas usando las construcciones de la barra de herramientas Animate, de
modo que cuando se desarrolló este modelo, se borraron las características agregadas de anima-
ción que fueron proporcionadas por los módulos nuevos y nosotros mismos animamos estas
nuevas características. En el modelo se borraron la cola y el almacenamiento para Cell 1. Senci-
llamente se agregó la nueva cola de acceso. Al correr el nuevo modelo, se pudieron ver piezas a
las que se les bloqueaba la entrada a Cell 1, empezando alrededor del tiempo 275.
Por supuesto, se pueden incluir todas las clases de adornos para esta actividad. Supóngase que
sólo una parte de las entidades necesita este accesorio. Se podría incluir con facilidad un módulo
Decide (Decidir) entre ellos para comprobar esta condición, como se muestra en la figura 9-5.
Los dos ejemplos en los que se utilizan los módulos Allocate y Move dieron por resulta-
do que el transportador se moviera a la ubicación de la entidad. Supongamos ahora que siem-
pre que se libera el transportador, se quiere que esté vagando por el sistema en búsqueda de
trabajo. Se tiene un camino predefinido que el transportador debe de seguir. Este camino sería
muy semejante a una secuencia de estaciones, excepto en que formaría un circuito cerrado.
Cada vez que el transportador que no ha sido destinado llegara a la estación siguiente en su
camino, se haría una comprobación para ver si hay, en ese momento, una petición proveniente
de algún lugar. Si no la hay, el transportador continúa en su viaje sin destino expreso. Si se tiene
una petición, el transportador se dirige de inmediato al lugar de donde proviene esa petición.
Para modelar esto, se crearía una sola entidad (llamémosla entidad de circuito cerrado)
que intentaría destinar el transportador con una prioridad muy baja (un número elevado para
la prioridad). Una vez destinado, el transportador vacío se mueve hasta la estación siguiente
en su camino. Después de llegar a esta estación, se libera el transportador de modo que pueda
responder a cualquier petición que haya en ese momento. La entidad en el circuito se dirige
hacia el módulo Allocate inicial, en donde una vez más se intenta destinar el transportador. En
esto se supone que cualquier petición existente en ese momento por el transportador tiene una
prioridad más alta que la entidad en el circuito. Recuérdese que la prioridad predeterminada es
1, teniendo el valor más bajo la prioridad más alta.
Una vez que un transportador llega a su destino, debe liberarse. El módulo Free (Liberar)
proporciona esta función. Sólo se necesita introducir el nombre del transportador en el cuadro
de diálogo y, en algunos casos, el número de unidad. Dos módulos adicionales, Halt (Detener) y
Activate (Activar), permiten controlar el número de transportadores activos o disponibles. El mó-
dulo Halt hace que sólo una unidad de los transportadores quede inactiva o no disponible para
destinarse. El módulo Activate hace que un transportador inactivo se vuelva activo o disponible.
Verdadero
Destinar Mover monta- Demora por Mover hasta la
montacargas de Accesorio
cargas hasta la la carga del ubicación de la
horquilla requerido
zona de tarimas accesorio entidad
Falso
abandono por parte de la entidad cuando ésta (o un cliente) se une a una cola a la llegada pero,
más tarde, decide salirse y alejarse, en principio arrepintiéndose de no tener que abandonar.
Consideremos el caso más complejo, en donde es posible tener tanto clientes que renuncian
como otros que abandonan. En primer lugar, definamos las diversas maneras en que pueden
ocurrir la renuncia y el abandono.
En la mayor parte de los sistemas de servicio se tiene una capacidad finita del sistema,
basada en el tamaño del espacio de espera. Cuando todo el espacio está ocupado, un cliente
no podrá entrar al sistema y será rechazado. Ésta es la forma más sencilla de renuncia. Por
desgracia, los sistemas en los que se puede verificar la renuncia son mucho más complicados.
Considérese una fila sencilla de servicio en donde, teóricamente, la capacidad de la cola o línea
de espera es infinita. En la mayor parte de los casos se tiene alguna capacidad finita basada
en el espacio, pero es posible que una fila de servicio pueda salir de un edificio y dar vuelta en
torno de la manzana (digamos, la línea de espera para obtener boletos para la Serie Mundial
o el Supertazón). En estos casos no se tiene un límite concreto para la capacidad, sino que
las decisiones de los clientes de formarse o retirarse del sistema se basan en su propia evalua-
ción de la situación. Como consecuencia, el punto o capacidad de renuncia frecuentemente
depende de la entidad. Un cliente puede aproximarse a una larga fila de servicio, decidir no
esperar y retirarse del sistema; sin embargo, el cliente que siga puede llegar a formarse.
El abandono por parte de la entidad es un aspecto incluso más complicado, en términos
tanto del modelado como de la representación en el software. Cada entidad o cliente que se
forma en una fila tiene un umbral diferente de tolerancia con respecto a cuánto esperar antes
de salirse de ella. A menudo, la decisión depende de cuánto desea cada cliente el servicio que se
está proporcionando. Algunos no abandonarán sin importar el tiempo de espera. Otros pueden
esperar durante un tiempo y, después, salirse de la fila porque se dan cuenta que no lograrán
que se les sirva en el tiempo que satisfaga sus necesidades. Es frecuente que las decisiones de los
clientes sobre permanecer en la fila o salirse de ella se basan tanto en el tiempo que ya han pa-
sado en ella como en el lugar en que se encuentran en la misma. Un cliente puede entrar a una
fila y decidir esperar durante diez minutos; si no se le da servicio en ese tiempo, planea salirse.
Sin embargo, después de que han transcurrido diez minutos, el cliente puede elegir permanecer
en ella si es él quien sigue para obtener el servicio.
El cambio de fila, o maniobra, es una forma incluso más complicada de abandono que se
presenta con frecuencia en las filas de las cajas de los supermercados, los restaurantes de co-
mida rápida y los bancos que no emplean una sola línea de espera. Un cliente selecciona la fila
para formarse y, más tarde, reevalúa esa decisión con base en lo largo de las filas en ese momen-
to. Después de todo, invariablemente nos formamos en la fila más lenta y, si cambiamos de fila,
la que dejamos avanza más rápido y en la que nos formamos el avance se hace más lento. Nunca
se cubrirá la lógica para la maniobra.
la muestra generada es de una distribución continua no será un entero, pero sólo se tiene interés
en si el número en la línea de espera es mayor que la tolerancia generada.
Se tienen dos maneras para modelar la actividad de renuncia. Supongamos que se crean las
llegadas, se genera el valor de la tolerancia a partir de la distribución triangular y se asigna tal
valor a un atributo de la entidad. Se podría enviar la llegada a un módulo Decide y comparar
el valor muestra con el número en la línea de espera en este momento, usando la variable NQ
(number in queue, número en la cola) de Arena. Si la tolerancia es menor que el número presen-
te en la cola o igual a éste, se retira la llegada del sistema. De lo contrario, se forma en la línea
de espera. Un método alternativo es asignar la tolerancia a una variable y usar también esta
misma variable para la capacidad de la cola del servidor. Entonces, se envía la llegada directa-
mente al servidor. Si el número presente en la cola es mayor que la tolerancia o igual a ésta, lo
cual es igual a la capacidad de la cola, la llegada se retirará en forma automática. Si se aplica
el segundo método, es posible asignar a la capacidad de la cola un valor menor que el número
presente en esta última. Este método funciona porque Arena sólo comprueba el valor de la
capacidad de la cola cuando una nueva entidad intenta formarse. Por lo tanto, las entidades
presentes permanecen con seguridad en la cola, sin importar el nuevo valor de la capacidad de
ella. Cuando se desarrolle el modelo, se aplicará este segundo método.
Para representar el abandono, supóngase que los clientes que llegan y deciden no renunciar
están deseando esperar sólo un periodo limitado antes de abandonar la cola. Se generará este
tiempo de tolerancia para el abandono a partir de una distribución ERLA(15, 2) (Erlang), la
cual tiene una media de 30 y se le asigna a un atributo de entidad en un módulo Assign. Mode-
lar la mecánica de la actividad de abandono puede representar un reto. Si se permite que la lle-
gada se forme en la cola y se alcanza el tiempo para abandonar, se necesita ser capaz de hallar la
entidad y eliminarla de esa cola. En este punto en la descripción del problema se podría querer
considerar métodos alternativos para manejar esto. Por ejemplo, se podría definir una variable
que siga el rastro de cuándo el servidor estará disponible de nueva cuenta. Primero se genera
el tiempo de procesamiento de la entidad y se le asigna a un atributo en un módulo Assign.
Entonces se envía la entidad al módulo Decide, en donde se hace la comprobación en cuanto
a la renuncia. Si la entidad no se retira, entonces se comprueba (en el mismo módulo Decide)
para ver si la entidad empezará a recibir el servicio antes de su tiempo para abandonar. Si no
es así, se hace que la entidad abandone. De lo contrario, la enviamos a un módulo Assign, en
donde se actualiza la variable que hace ver cuándo el servidor estará disponible; a continuación,
se envía la entidad a la cola. Esta lógica del modelo puede parecer complicada, pero se puede
resumir como sigue:
Def
inir tiempo para estar disponible (Define Available Time) = Tiempo en el futuro
cuando el servidor estará disponible
Crear (Create) llegada
Asignar tiempo de servicio (Assign Service Time)
Asignar
el Tiempo en el futuro en el que la actividad abandonaría, el cual es igual
a Tiempo de tolerancia (Tolerance Time) + TNOW (Tiempo ahora)
Asignar límite para renunciar (Assign Balk Limit)
Decidir (Decide)
Si el Límite para renunciar > Número en la cola
Hacer renunciar a la entidad (Balk entity)
Si el Tiempo para abandonar (Renege Time) < Tiempo en el que el servidor estará
disponible (Available Time)
Hacer que la entidad abandone (Renege entity)
Un muestrario de aspectos y técnicas adicionales de modelado 369
De lo contrario
Asignar tiempo en el que servidor estará disponible = MX(Tiempo
en el que servidor estará disponible , TNOW) + Tiempo para pro-
porcionar el servicio (Service Time)
Enviar (Send) la entidad a la cola
Se debe tener cuidado acerca de las estadísticas, pero este procedimiento capturará el proceso
de renuncia con exactitud y evitará tener que alterar la cola.
Añadamos una última advertencia antes de desarrollar el modelo. Supóngase que la decisión
real de si se ha de abandonar no sólo se basa en el tiempo para ello, sino también en la posición
del cliente en la cola. Por ejemplo, los clientes pueden haber alcanzado su límite de tolerancia
para abandonar, pero si ahora están al frente de la línea de espera puede ser que sólo espe-
ren para recibir el servicio (es decir, abandonar el abandono). Llamemos a esta posición en la
cola en donde el cliente elegirá permanecer, incluso si ha transcurrido su tiempo para renunciar,
la zona de permanencia del cliente. Por lo tanto, si la zona de permanencia del cliente es de 3 y
ha expirado su tiempo para abandonar, el cliente permanecerá en la fila de todas maneras, si
uno de los tres clientes que tiene por delante está por recibir el servicio.
Se generará este número de posición a partir de una distribución de Poisson, POIS(0.75).
Se ha usado esta distribución porque proporciona una aproximación razonable de este proce-
so y también da como respuesta un valor entero. Para aquellos lectores que no tengan acceso
a unas tablas de Poisson (¿quiere dar a entender el lector que en realidad vendió su libro de
estadística?), es aproximadamente equivalente a la distribución empírica discreta que se da a
continuación: DISC(0.472, 0, 0.827, 1, 0.959, 2, 0.993, 3, 0.999, 4, 1.0, 5). Véase el apéndice D
para obtener más detalles sobre esta distribución.
Este nuevo proceso de decisión significa que la lógica antes dada ya no es válida. Ahora
debe colocarse al cliente que llega en la línea de espera y evaluar el abandono después de que
ha transcurrido el tiempo para abandonar. Sin embargo, si en realidad se prosigue y se coloca
el cliente en la cola, no se tiene mecanismo para detectar que ha transcurrido el tiempo para
abandonar. Para vencer este problema, se hará un duplicado de cada entidad y se le demorará
en el tiempo para abandonar. La entidad original, que representa al cliente real, se enviará a
la cola de servicio. Después de la demora en el tiempo para abandonar, se hará que la entidad
duplicada compruebe la posición en la cola de la entidad original. Si el cliente ya no está en
la cola de servicio (es decir, se le dio servicio), sólo se dispondrá de la entidad duplicada. Si el
cliente todavía está en la cola, se hará la comprobación para ver si ese cliente abandonará. Si la
posición en ese momento en la cola se encuentra dentro de la zona de permanencia del cliente,
sólo se dispondrá de la entidad duplicada. De lo contrario, se hará que la entidad duplicada
elimine la entidad original de la cola de servicio y se dispondrá tanto de la duplicada como de
la original. Esta lógica del modelo se resume de la manera siguiente:
370 Capítulo 9
Para implementar esta lógica, es obvio que se necesitan unas cuantas características nue-
vas, como la capacidad de buscar en una cola y eliminar una entidad de una cola. Como es
de sospechar, los módulos de Arena que realizan estas funciones se pueden hallar en los pane-
les de Advanced Process y Blocks. En la figura 9-6 se muestra el modelo completado (modelo
9-3) de Arena.
Original
Crear cliente I Registrar
Asignar Duplicar Procesar
Cola Tomar tiempo del
que llega atributos entidad cliente
I sistema
Cola del Servidor
I I
servidor
Duplicar
Registrar Disponer de
renuncias renuncias
Demorar
Buscar en
durante el Asignar Hallado
cola del Registrar
tiempo para Buscar # Salida de
servidor clientes que
abandonar No hallado clientes
recibieron I
servicio
Zona de Verdadero
permanencia Disponer 3
OK I
Falso
Original
Eliminar de
la cola
Registrar
Entidad
abandonos
eliminada
Se empieza el modelo con un módulo Create que crea los clientes que llegan, los cuales en-
tonces se envían al módulo Assign siguiente, en donde se asignan los valores que se necesitarán
más adelante, como en la pantalla 9-7.
Las llegadas nuevas se envían a un módulo Separate (Separar). Este módulo permite hacer
duplicados (clones) de la entidad entrante. La entidad original sale del módulo por el punto de
salida que se ubica a la derecha de ese módulo. Las entidades duplicadas salen de éste por los
puntos de salida que están debajo de él. En este caso sólo se necesita introducir el nombre del
módulo, aceptando los datos restantes como los predeterminados.
Los duplicados son réplicas exactas de la entidad original (en términos de los atributos y
sus valores) y se pueden crear en cualquier cantidad. Si se hace más de un duplicado de una
entidad, se pueden considerar como un lote de entidades que se enviarán para que salgan por la
misma salida (de abajo). Nótese que si introduce un valor n para # de duplicados, en realidad
salen del módulo n + 1 entidades: n duplicados por el punto de conexión del fondo y 1 original
por el de arriba.
La entidad original (cliente) se envía a una secuencia de módulos Queue - Seize (Cola - To-
mar) (del panel Blocks), en donde intenta entrar a la cola Server Queue (Cola del ser-
vidor) para esperar ser atendido por el servidor. Con el fin de implementar este método, se
necesita ser capaz de fijar la capacidad de la cola que antecede al Seize, a la variable Server
Queue Capacity (Capacidad de la cola del servidor). Esto se realiza adjun-
tando el panel Blocks al modelo, y seleccionando y colocando un módulo Queue. (Nótese que
cuando se hace clic en el módulo Queue, no existe vista de hoja de cálculo asociada; éste será el
caso para cualesquiera módulos de los paneles Blocks y Elements.) Antes de abrir el cuadro de
diálogo Queue, se podría advertir que se tiene un solo punto de salida a la derecha del módulo.
Ahora se hace doble clic en el módulo y se introducen la etiqueta, el nombre y la capacidad,
372 Capítulo 9
Cola
como se muestra en la pantalla 9-8. Después de cerrar el cuadro de diálogo, debe de verse un
segundo punto de salida, cerca de la esquina inferior derecha del módulo. Ésta es la salida que
tomarán las entidades que renuncien.
La capacidad de esta cola se introdujo como la variable Server Queue Capacity, la
cual se fijó por el cliente que llega a su tolerancia para no renunciar, como se explicó al princi-
pio. Si el número en ese momento en la cola es menor que el valor en ese mismo instante de la
Server Queue Capacity, se permite que el cliente se forme en la cola. Si no es así, se hace
renunciar a la entidad cliente y se le envía al módulo Record (Registrar), en donde incrementa
el conteo de renuncias y, después, se le envía a un módulo Dispose, en donde sale del sistema
(véase la figura 9-6). Un cliente al que se forma en la cola espera el recurso Server.
Este módulo Queue necesita ser seguido por un módulo Seize. Cuando se agrega el módulo
Seize, es necesario asegurarse que viene del panel Blocks y no del Advanced Process. El módulo
de este último panel viene automáticamente con una cola y Arena quedaría confundido si se
intentara anteceder una construcción seize con dos colas. Entonces hágase doble clic sobre el
módulo y hágase las entradas que se muestran en la pantalla 9-9.
Cuando el cliente toma el servidor, se envía al módulo Process siguiente. En este módulo se
utiliza una Delay Release Action (Demorar Liberación Acción), la cual proporciona
la demora del servicio y libera el recurso servidor para el cliente que sigue. Un cliente que ha
recibido el servicio se envía a un módulo Record, en donde se cuenta el número y, enseguida, al
módulo Dispose siguiente.
La entidad duplicada se envía a un módulo Delay, en donde se demora en el tiempo de
abandono que se asignó al atributo Renege Time. Después de la demora, la entidad entra
a un módulo Assign, en donde se asigna el valor del atributo Customer # a una nueva va-
Un muestrario de aspectos y técnicas adicionales de modelado 373
Tomar
Servidor
Hallado
Buscar en
cola del
servidor
No hallado
Original
Eliminar de
la cola
Entidad
eliminada
na terminará la ejecución con un error. En el modelo que se está trabajando, se quiere eliminar
el cliente con rango J de la cola Server Queue, como se muestra en la pantalla 9-11.
Si se mira el módulo Remove, se verán dos puntos de salida en el lado derecho. La entidad
que entró a este módulo saldrá por el punto de salida superior; en el modelo que se está traba-
jando, se envía al mismo módulo Dispose que se usó para la primera rama del módulo Decide.
La entidad cliente eliminada de la cola del servidor saldrá por el punto de salida inferior y se
envía a un módulo Record para contar el número de clientes que abandonan. A continuación,
se envía al módulo Dispose.
Fijamos la duración de la Replication (Replicación) en 2 000 minutos. El resultado del re-
porte para este modelo muestra que tuvo 8 clientes que renunciaron y 41 que abandonaron,
habiéndose dado servicio a 332.
automóviles que llegan a la intersección como entidades que se retienen hasta que se les permite
seguir su camino. Ahora concíbase al policía como una entidad que, en cierto momento, da a
los automóviles que esperan una señal para seguir adelante. Puede haber diez automóviles espe-
rando, pero el policía puede dar permiso de continuar su camino sólo a los primeros seis.
El segundo método permite que las entidades se retengan por decisión propia para evaluar las
condiciones del sistema y determinar cuándo deben de seguir avanzando. Por ejemplo, piénsese
en un automóvil que quiere dar vuelta a través del tráfico para acceder a una entrada para coches,
desde una calle transitada con tráfico que está circulando; por desgracia, no hay semáforo ni un
policía. Si el automóvil es la entidad, espera hasta que las condiciones sean tales que no haya
otros automóviles que se aproximen dentro de una distancia razonable y el acceso esté libre para
la entrada. En este caso, la entidad evalúa en forma continua las condiciones hasta que se pueda
dar la vuelta con seguridad. Si hay un segundo automóvil que quiere realizar la misma vuelta di-
rectamente detrás del primero, espera hasta que se encuentre al frente de la fila y, a continuación,
realiza su propia evaluación. En el siguiente modelo 9-4 se ilustrarán los dos métodos.
También se tienen situaciones en donde es necesario formar lotes de artículos o entidades,
antes de que puedan avanzar. Tómese el caso más sencillo de formación de lotes de artículos
semejantes o idénticos. Por ejemplo, se está modelando la operación de empaque al final de
una línea de envasado en latas que produce bebidas. Se desea combinar o agrupar las bebidas
en paquetes de seis para la operación de empaque. También se podría tener una operación
secundaria que combine cuatro paquetes de seis en una caja. En esta ilustración, los artículos
o entidades que se van a agrupar son idénticos y lo más probable es que se formaría un gru-
po permanente (es decir, uno que nunca se querría separar de nuevo más adelante). De este
modo, seis entidades entran al proceso de agrupamiento y, del proceso, sale una entidad: el
paquete de seis. Sin embargo, si se está modelando una operación que agrupa entidades que
se van a separar más adelante para continuar por separado su camino, se desearía formar un
grupo temporal. En el primer caso, se pierde la información única del atributo, adjunta a cada
entidad. En el segundo caso, se quiere que cada entidad que parta de la operación conserve
la misma información del atributo que le pertenece cuando se unió al grupo. De modo que
cuando se está modelando una operación de agrupamiento, se necesita decidir si se quiere
formar un grupo temporal o permanente. A continuación, en el modelo 9-4 se discutirán las
dos opciones.
Cola de 0 Verdadero
espera menor
que 2
0
Falso
Escanear Demorar
Crear entidad Registrar
respecto a la durante 8
para escaneo arranques
condición minutos
0
Escanear
respecto a la
condición
Pantalla 9-13. Asignación del siguiente tamaño del lote para el proceso
380 Capítulo 9
Señal para
liberar el
lote
Lo normal es que se requiera que las entidades que llegan a un módulo Batch esperen hasta
que se haya armado el tamaño requerido del lote. Sin embargo, en el modelo que se está tra-
bajando, se definió que el tamaño del lote que se va a formar sea exactamente igual al número
de artículos que se acaban de liberar hacia el módulo; véase la pantalla 9-15. De este modo, los
artículos nunca tendrán que esperar en este módulo.
La entidad que ahora representa el lote de artículos se dirige hacia el módulo Delay: De-
lay for Process (Demorar en espera del proceso), en donde ocurre la demora en
espera del proceso. Nótese que tal demora depende del tamaño del lote que se está procesando:
3 minutos más 0.6 minuto por cada artículo en el lote.
El lote procesado se envía al módulo Decide siguiente, Wait Queue Less Than 2 (Cola
de espera menor que 2) en donde se comprueba si se tienen menos de dos artículos en
la cola de espera. Si es así, debe de pararse el proceso y esperar que lleguen más. Se hace esto
enviando la entidad al módulo Hold: Scan for Condition, antes discutido, para esperar
que lleguen los artículos suficientes para volver a arrancar el proceso. Si hay por lo menos dos
artículos esperando, se envía la entidad al módulo Assign: Assign Batch Size, en donde
se fija el próximo tamaño del lote para arrancar el siguiente procesamiento de este último.
Ya que los pocos párrafos anteriores fueron bastante complejos, repasemos la lógica que
controla la formación de lotes de artículos para el proceso. Téngase presente que las entidades
que llegan se colocan en una cola Hold, en donde se les retiene hasta que se recibe una señal
para que avancen. El primer proceso se inicia por el segundo módulo Create que crea sólo una
entidad de control. Esta entidad se retiene en la cola Scan hasta que han llegado los primeros
cuatro artículos. El valor 4 es el valor inicial de la variable Restart. Esta entidad de control
hace que se libere el primer lote para el procesamiento y, enseguida se dispone de él. Después
de eso, el último lote que complete el procesamiento se convierte en la entidad de control que
determina el siguiente tamaño de lote y cuándo dejar que este último avance para el procesa-
miento.
Antes de estar listo para ejecutar el modelo en OptQuest, se necesita definir una estadística
de salida en el módulo de datos Statistic que permitirá limitar el número promedio de entida-
des que esperen en la cola Hold for Signal.Queue. Se le ha dado el nombre Max Bat-
ch Value. La expresión es DMAX(Hold for Signal.Queue.NumberInQueue)(DMAX
(Retener por Señal.Cola.NumeroEnLaCola). La función DMAX dará como respuesta
382 Capítulo 9
el valor máximo de una estadística persistente en el tiempo de Arena. La estadística que intere-
sa se genera en forma automática como parte del informe de salida. El nombre de la estadística
es el nombre de la cola seguido por .NumberInQueue. El lector interesado puede hallar este
tipo de información en el tema de ayuda “Statistics (Automatically Generated by SIMAN)”
[“Estadísticas (Generadas automáticamente por SIMAN)”].
Se estableció que OptQuest haga oscilar la variable Max Batch desde 4 hasta 14, en incre-
mentos discretos de 2. La variable Restart se hizo oscilar desde 2 hasta 10, en incrementos
discretos de 1.
El objetivo fue minimizar el número de arranques con el requisito de que la estadística Max
Batch Value no sobrepasara 25. La mejor solución que se encontró fue:
Max Batch = 10
Restart = 8
Max Batch Value = 24.9
Startups = 30.6
Registrar
Crear entidades Asignar Estación
tiempo de Encaminar
de arranque atributos Almacén
recorrido
0
Demorar
en el
almacén
Original
0 Asignar
Estación para Crear la pieza espera del Tomar mon-
Tomar WS 1
WS 1 siguiente montaje en taje en WS 1
WS 1
0
Duplicado
deros cuellos de botella del sistema. Bien, ya que se ha ido tan lejos, ¡por qué no recorrer todo
el camino! Supongamos también que se quisiera saber el porcentaje del tiempo que las piezas
pasan en todos los estados posibles. Disponer esto es un problema mucho más difícil. En primer
lugar, definamos el tiempo en el sistema o del ciclo para una pieza como el que empieza cuando
se inicia la entrega y finaliza cuando esa pieza completa el procesamiento en la estación 3. Los
estados posibles de la pieza son: Travel (Recorrido) hasta WS 1, Wait (Esperar) a WS 1, Wait el
montaje en WS 1, Setup en WS 1, Process en WS 1, Blocked en WS 1, Wait a WS 2, Process en
WS 2, Blocked en WS 2, Wait el montaje en WS 3, Setup en WS 3 y Process en WS 3. Conforme
se desarrolle el modelo, se pondrá cuidado en incorporar los estados de los recursos. Pero, só-
lo se considerarán los estados de la pieza después de que se haya completado el desarrollo del
modelo. El lector tendrá que confiar en que los autores podrían saber lo que están haciendo.
Conjunto de
estados
Max Arrivals de 2. Esto hace que dos entidades, o piezas, se creen en el instante 0. Enseguida, el
módulo Create queda inactivo; no crea más entidades durante el resto de la simulación. Estas dos
piezas se envían a un módulo Assign, en donde se hacen dos asignaciones de atributos. Se asigna
el valor de TNOW al atributo Enter System (Entrar al sistema) y se asigna un valor ge-
nerado por UNIF(10, 15) al atributo Route Time (Tiempo de la ruta). El valor asignado
a Enter System es el momento en que la pieza entró al sistema y el Route Time es el tiempo
de entrega desde el almacén hasta la primera estación de trabajo. Puesto que se tiene interés en
conservar información detallada del estado de las piezas, éstas se envían a un módulo Record, en
donde se cuenta el Delivery Time (Tiempo de entrega) con base en la expresión Route
Time, la cual se asignó en el módulo Assign anterior. A continuación, la pieza se envía al módulo
Station (Estación) que sigue, en donde se define la Station Warehouse (Almacén). Después, se
usa el módulo Route (Encaminar) para encaminar desde la estación Warehouse hasta la esta-
ción WS 1, usando el Route Time que se asignó con anterioridad.
Después de completar esta transferencia, la pieza llega al módulo Station, Station for
WS 1 (Estación para WS 1). El módulo Seize que sigue intenta tomar 1 unidad del recurso
WS 1. Ahora es necesario tener cuidado en tres requerimientos adicionales. En primer lugar, se
necesitan especificar los estados del recurso y asegurarse que las estadísticas se mantienen co-
rrectamente. En segundo, es necesario hacer una petición de una pieza de reaprovisionamiento.
Por último, se requiere hacer que ocurra un montaje antes de que la pieza se procese.
Empecemos por definir los recursos con el uso del módulo de datos Resource. Se introducen
seis recursos: WS 1, WS 2A, WS 2B, WS 3, Setup Operator (Operario de montaje) y
Buffer. Los primeros cinco tienen capacidad de 1 y el recurso Buffer una capacidad de 2.
Anteriormente, en la sección 4.2.4, se mostró cómo usar Frequencies (Frecuencias) para
generar estadísticas de frecuencias acerca del número en una cola. Para obtener datos de fre-
cuencias acerca de los recursos en este modelo, en principio es necesario definir los StateSets
(Conjuntos de estados). Esto se lleva a cabo usando el módulo de datos StateSet del panel
Advanced Process. Se introducen cinco StateSets: WS 1 StateSet, WS 2A StateSet, WS
2B StateSet, WS 3 StateSet y Setup Operator StateSet. En la pantalla 9-16 se
muestran los estados para el WS 1 StateSet.
A continuación, se introducen las dos fallas (WS 1_3 Failure [Falla] y WS 2 Failu-
re) usando el módulo de datos Failure. Ahora se necesita regresar al módulo de datos Resource
y agregar los StateSets y Failures. Cuando se agregan las fallas, se selecciona Ignore (Igno-
rar) como la Failure Rule (Regla de Falla).
Ahora regresemos a la lógica del modelo de la figura 9-8. Habiendo abordado WS 1, se ne-
cesita tomar el recurso WS 1, lo que se muestra en la pantalla 9-17.
386 Capítulo 9
Tomar
WS 1
Name
Name Seize
Seize WS
WS 11
Allocation
Allocation Value
Value Added
Added
Resources
Resources
Type
Type Resource
Resource
Resource
ResourceName
Name WS
WS 11
Name
Name Assign
Assign Wait
Wait for
for Setup
Setup atat WS
WS 11
Assignments
Assignments
Type
Type Other
Other
Other
Other STATE( WS
STATE( WS 11 ))
Name New
NewValue
Value Waiting
Waiting for
Seize Setup
for WSSetup
1
Allocation Value Added
Resources Pantalla 9-18. Asignación del estado del recurso
Type Resource
Después, es necesarioResource Name WS 1
Name encargarse del reaprovisionamiento
Name Seize
Seize WS y de la actividad de montaje. La
WS 11 Setup
Setup
pieza que en estos Resources
instantes
Resourcesha tomado (Seized) el recurso estación de trabajo entra al módulo
Separate (Separar) queTypeType Resource
sigue, en el cual se crea una entidad duplicada. Ésta se envía al módulo
Resource
Resource
Resource Name
Delay: Warehouse Delay (Demorar enSetup
Name Setup Operator
Operator en el cual se toma en cuenta el
el almacén),
Resource
Resource State
State WS
WS 11 Setup
Setup
tiempo que espera la solicitud de reaprovisionamiento de la pieza hasta que se inicia la entrega
Name Assign Wait for Setup at WS 1
de la pieza siguiente, lo que tarda EXPO( 25 ). Entonces se envía esta entidad al mismo con-
Assignments
junto de módulos que se usaron para Other
Type causar la llegada de las dos primeras piezas. La entidad
original sale del módulo Separate hacia
Other un módulo
STATE( WS 1 )Assign, en donde se asigna el estado del
recurso WS 1 en Waiting New Value
for Setup Waiting for Setup
Operator (Esperar por el operario de
montaje), mostrado en la pantalla 9-18.
Liberar alma- 0
Tomar WS 2 cenamiento Tener WS 2A Verdadero
intermedio
Falso
hace cola para esperar al operario de montaje. Una vez que toma a este operario, fijando su
estado en Setup, asigna el estado del recurso WS 1 en Setup, se demora por el montaje, libe-
ra al operario, asigna el estado del recurso WS 1 de nuevo en Processing y se demora por
el procesamiento. Después de ser procesada, la parte hace cola para tomar una unidad del recurso
Buffer (capacidad de 2), fijando el estado del servidor en Blocked en el transcurso del tiempo
en que hace cola. Después de tomar el recurso de almacenamiento intermedio, libera el recurso
WS 1 y sale de la zona de la Workstation 1 con control de una unidad del recurso Buffer.
En la figura 9-9, se muestran los módulos para la Workstation 2, la cual tiene dos máquinas.
Recuérdese que las piezas que llegan a la Workstation 2 tienen control de una unidad del
recurso de almacenamiento intermedio. Como consecuencia, tan pronto como la pieza toma
una de las dos máquinas, debe liberarse ese almacenamiento porque ahora hay un espacio libre
delante de la estación de trabajo. Esta acción se realiza en el siguiente módulo Release: Re-
lease Buffer (Liberar almacenamiento intermedio).
Una vez que toma una máquina disponible y libera el recurso de almacenamiento interme-
dio, la parte entra al módulo Decide: Have WS 2A (Tener WS 2A), el cual se usa para deter-
minar cuál recurso de máquina se ha tomado, con base en el valor del atributo WS 2 Resour-
ce (Recurso de WS 2) asignado en el primer módulo Seize, cuando se asignó el recurso a la
pieza. Si a la pieza se le asignó el recurso WS 2A, el primer recurso en el conjunto, a este atributo
se le habría asignado un valor de 1. Se aplica esta lógica para determinar cuál máquina se ha
destinado y enviar la pieza según la lógica, específicamente para WS 2A o WS 2B. Los cinco
módulos de enmedio en la figura 9-9 son para WS 2A y los cinco de abajo corresponden a WS
2B. Ya que no se tiene montaje en la Workstation 2, el primer módulo Assign asigna el estado
del recurso máquina en Processing (Procesando) y dirige la pieza hacia el módulo De-
lay que sigue, el cual representa el procesamiento de la misma. El último módulo Assign asigna
el estado del recurso máquina en Blocked.
La pieza intenta entonces tomar el control del recurso WS 3, en el módulo Seize que sigue.
Si el recurso no está disponible, la pieza esperará en la cola Seize WS 3.Queue, la cual se
definió en el módulo Queue como compartida entre los dos módulos Seize. Ahora, si se tienen
dos piezas en espera, una para cada máquina, se desea que la pieza proveniente de WS 2A sea
la primera en la fila. Esto se realiza al seleccionar que Low Attribute Value (Valor bajo del atri-
buto) sea la regla para establecer el rango, con base en el valor del atributo WS 2 Resource.
Esto hace que se establezca el rango de todas las entidades que están en la cola según su valor
para el atributo WS 2 Resource. Con ello se garantiza que WS 2A recibirá preferencia.
Una vez que la pieza ha sido destinada al recurso WS 3, se transferirá a esa máquina en
tiempo 0. En la figura 9-10 se muestran los módulos que se usaron para modelar la Workstation
3. Se podría advertir que estos módulos se miran muy semejantes a los usados para modelar la
Workstation 1 y, en esencia, son los mismos. Una pieza entrante (que ya ha sido destinada al
recurso WS 3) primero asigna el estado del recurso de la estación de trabajo en Waiting for
setup y, enseguida, intenta tomar al operario de montaje. Después de asignarse el recurso
operario de montaje, el estado del recurso WS 3 se fija en Setup, la pieza se demora por el
montaje, se libera el operario de montaje, se fija el estado del recurso WS 3 en Processing y esa
pieza se demora por el tiempo del proceso. Una vez que se completa todo, se libera el recurso
WS 3, se registra el tiempo de ciclo de la pieza y se dispone de la entidad.
Ahora que se ha completado la lógica del modelo, se necesitan pedir las estadísticas de las
frecuencias para las estaciones de trabajo y el operario de montaje. Se necesitan las estadísticas
de frecuencias basadas en los estados de los recursos. En la pantalla 9-20 se muestran las entra-
das requeridas para el módulo Statistic con el fin de obtener estas frecuencias.
Recuérdese que cuando se estuvo describiendo el problema, también se quería obtener el
resultado del porcentaje de tiempo que las piezas pasan en todos los estados posibles. Obtener
esta información para los estados de los recursos es bastante fácil. Sencillamente se definen
tales estados y Arena reúne esta información y, a su vez, la reporta usando la característica
Frequencies. Por desgracia, este uso de Frequencies sólo es válido para los recursos.
Reunir el mismo tipo de información para el estado de la pieza o entidad es difícil, pues los es-
tados de las piezas se extienden por numerosas actividades sobre varios recursos. Esto crea un pro-
blema de modelado: ¿cuál es la mejor manera de obtener esta información? Antes de mostrar el
procedimiento adoptado en este texto, se discutirán varias alternativas, incluyendo sus defectos.
La primera idea de los autores fue definir una variable que se pudiera cambiar con base en
el estado en curso de la pieza. Entonces se pedirían las estadísticas de frecuencias acerca de esta
variable, de modo muy semejante a como se hizo para la cola de almacenamiento de las piezas
en la zona de reelaboración del modelo 4-2, en la sección 4.2.4. Por supuesto, esto requeriría
editar el modelo para añadir asignaciones a esta variable siempre que cambiara el estado de
la pieza. Aunque esto suena como una buena idea, se deja a un lado cuando se da uno cuenta
que pueden haber múltiples piezas en el sistema al mismo tiempo. Funcionaría sólo bien si se
limitara a uno el número de piezas en el sistema. Puesto que esto no estaba en la descripción del
problema, se decidió considerar maneras alternativas para reunir esta información.
La segunda idea fue suponer que toda la información requerida ya se estaba reuniendo (una
hipótesis válida). Dado esto, sólo se necesita ensamblar la información al final de la ejecución y
calcular las estadísticas deseadas. En forma automática, al final de cada ejecución, Arena llama
una rutina de conclusión. Se pudo escribir el código del usuario (véase la sección 9.2) que lleva-
ría a cabo esta función. Una desventaja es que no proporcionaría tal información si se decidiera
390 Capítulo 9
Set Operator Resource Número de observaciones Tiempo promedio Porcentaje estándar Porcentaje restringido
IDLE 2.166 9.1514 39.64 39.64
WS 1 Set up 1.668 9.0429 30.17 30.17
WS 3 Set up 1.666 9.0603 30.19 30.19
mirar el informe resumen antes de que finalizara la ejecución. Esto se miraba como que pudiera
ser una gran cantidad de trabajo, de modo que se examinaron otras opciones.
Como tercer procedimiento se decidió considerar la adición de estadísticas adicionales de
salida al módulo de datos Statistic. Esto no permitiría reunir estadísticas adicionales; sin em-
bargo, sí permite calcular valores adicionales de salida sobre las estadísticas que ya están sien-
do reunidas por el modelo. Puesto que el modelo se encuentra actualmente reuniendo toda la
información que se necesita, aun cuando no en la forma correcta, se aplicará esta opción para
hacer salir información sobre el estado de la pieza. En primer lugar, se introdujo una Replica-
tion Length (Duración de la Réplica) de 50 000 unidades de tiempo en el cuadro de diálogo Run
> Setup > Replication Parameter (Ejecución > Configurar > Parámetro de la Réplica).
Si se ejecutara el modelo en este punto, se obtendrían los resultados que se muestran en la
figura 9-11. Enfoquemos temporalmente nuestra atención en la estadística de frecuencias para
el WS 1 Resource. Ésta hace ver que la estación de trabajo se encuentra procesando piezas
sólo 50.21% del tiempo, con una gran cantidad del tiempo no productivo consumido en los
estados Waiting for setup y Setup.
Toda la información que se necesita para calcular estos valores ya está contenida en la salida
resumen. Consideremos el primer estado de la pieza, Travel to WS 1 (Recorrido hasta
WS 1). El tiempo promedio de entrega por pieza fue de 12.517, considerado para un total de
1 672 piezas. El tiempo del ciclo fue de 225.07 para 1 665 piezas. Se podría advertir que todavía
habían siete piezas (1672-1665) en el sistema, cuando se terminó la simulación. Regresaremos
a esto más adelante. De modo que si se desea el porcentaje de tiempo que una pieza promedio
pasa haciendo el recorrido hasta la Workstation 1, se podría calcular ese valor con la expresión
siguiente:
(( 12.517 ∗ 1672 ) / (225.07 ∗ 1665)) ∗ 100.0
es decir, 5.5848%. Se puede aplicar este procedimiento para calcular todos los demás valores.
Básicamente, se calcula el monto total del tiempo de la pieza pasado en cada actividad, se le
divide entre el monto total de ese tiempo pasado en todas las actividades y se multiplica por
100 para obtener los valores en porcentajes. Puesto que los dos últimos pasos de este cálculo
siempre son los mismos, primero se definirá una expresión, Tot, para representar este valor
(módulo de datos Expression). Nótese que al usar una expresión, sólo se le calculará cuando se
requiera. Esa expresión es como sigue
TAVG(Cycle Time) ƀ TNUM(Cycle Time)/100
TAVG y TNUM son las variables de Arena que dan como respuesta el promedio actual de
una Tally (Cuenta) y el número
TAVG(Delivery Time)total
ƀ de observaciones Tally,
TNUM(Delivery respectivamente. El argumento
Time)/Tot
de la variable es la TallyWS
TAVG(Seize ID.1.Queue.WaitingTime)
En este caso, se ha elegido usarƀ el nombre de la Tally según se defi-
TNUM(Seize
nió en el módulo Record. EnWSlos1.Queue.WaitingTime)/Tot
casos en donde Arena define el nombre de la Tally (por ejem-
TAVG(Seize WS 2.Queue.WaitingTime) ƀ
plo, para lasTNUM(Seize
cuentas de tiempo en la cola), se recomienda que se revise una lista desplegable de
WS 2.Queue.WaitingTime)/Tot
un módulo o se consulte Help (Ayuda) para obtener el nombre exacto.
La información requerida para
FRQTIM(Frequency ID,calcular tres de los estados de la pieza está contenida en las
Category)
Tallies:TAVG(Cycle
Travel to WS 1, Wait for
Time) ƀ TNUM(Cycle WS 1 y Wait for WS 2. Las expresiones requeridas
Time)/100
para calcular estos valores son las siguientes:
FRQTIM(WS 1 Resource, Setup)/Tot
TAVG(Delivery Time) ƀ TNUM(Delivery Time)/Tot
TAVG(Seize WS 1.Queue.WaitingTime) ƀ
TNUM(Seize WS 1.Queue.WaitingTime)/Tot
TAVG(Seize WS 2.Queue.WaitingTime) ƀ
TNUM(Seize WS 2.Queue.WaitingTime)/Tot
TAVG(Cycle Time) ƀ TNUM(Cycle Time)/100
La información para los estados
FRQTIM(Frequency ID, restantes
Category) de la pieza está contenida en las estadísticas de
frecuencias.
TAVG(Cycle
TAVG(Delivery Time)
Time)ƀ TNUM(Cycle
ƀ TNUM(Delivery Time)/100Time)/Tot
Como sería de esperar, Arena también proporciona variables que se traducirán en informa-
TAVG(Seize
FRQTIM(WS 1WS 1.Queue.WaitingTime)
Resource, Setup)/Tot ƀ
ción acercaTNUM(Seize
de las frecuencias.
WS 1.Queue.WaitingTime)/Tot como respuesta la cantidad
La variable FRQTIM de Arena da
TAVG(Seize
total del tiempo que unWS
TAVG(Delivery Time) 2.Queue.WaitingTime)
recurso especificado estuvo en una
ƀ TNUM(Delivery ƀ categoría
Time)/Toto estado especificados. La
expresión TNUM(Seize
TAVG(Seize
completa WSvariable
WSesta
para 2.Queue.WaitingTime)/Tot
1.Queue.WaitingTime)
es ƀ
TNUM(Seize WS 1.Queue.WaitingTime)/Tot
TAVG(Seize
FRQTIM(Frequency WS 2.Queue.WaitingTime)
ID, Category) ƀ
TNUM(Seize WS 2.Queue.WaitingTime)/Tot
El argumento Frequency ID (ID de la frecuencia) es el nombre de la frecuencia. El argu-
mento Category (Categoría)
FRQTIM(Frequency
FRQTIM(WS es el
1 Resource,ID,nombre de la categoría. Por lo tanto, la expresión para Setup
Category)
Setup)/Tot
at WS 1 queda
FRQTIM(WS 1 Resource, Setup)/Tot
392 Capítulo 9
El lector debe de notar que pudo haber dos piezas que se estuvieran procesando o fueran
bloqueadas en la Workstation 2. Por lo tanto, se han incluido términos para el recurso 2A así
como para el 2B en esta estación.
Ahora que se ha desarrollado un método, y las expresiones, para calcular el porcentaje
promedio de tiempo que las piezas pasan en cada estado, se usará el módulo de datos Statistic
para añadir esta información en el informe resumen. En la pantalla 9‑21 se muestran las nuevas
estadísticas que se agregaron al módulo de datos Statistic.
Antes de seguir adelante, encarguémonos de la discrepancia entre el número de observacio-
nes para las estadísticas del Delivery Time (Tiempo de Entrega) y el Cycle Time (Tiempo del
ciclo) en el informe resumen. Debido a los métodos que se usan para reunir las estadísticas, y
al hecho de que se inicia la simulación con el sistema vacío y ocioso, siempre existirá esta dis-
crepancia. Se tienen varias maneras para tratar con ella. Uno de los métodos sería terminar la
llegada de piezas al sistema y dejar que todas completen el procesamiento antes de terminar
la ejecución de la simulación. Aunque esto proporcionaría estadísticas sobre un conjunto idén-
tico de piezas, en realidad se está agregando un periodo de paro a la simulación. Lo cual signifi-
caría que se tendrían condiciones transitorias potenciales tanto en el arranque como al final de
la simulación, situación que afectaría los resultados de las estadísticas de los recursos.
Pantalla 9-21. Las estadísticas resumen para los estados de las piezas
Un muestrario de aspectos y técnicas adicionales de modelado 393
Salida Valor
Blocked at WS 1 0.3881
Blocked at WS 2 5.4040
Process at WS 1 6.6783
Process at WS 2 18.7632
Process at WS 3 5.4595
Setup at WS 1 4.0051
Setup at WS 3 4.0136
Travel to WS 1 5.5551
Wait for Setup at WS 1 1.5395
Wait for Setup at WS 3 1.3023
Wait for WS 1 36.5635
Wait for WS 2 10.3425
Se pudo aumentar la duración de la ejecución hasta que la diferencia relativa entre estas ob-
servaciones se volviera muy pequeña, reduciendo de esta manera el efecto sobre los resultados.
Aunque se pudo hacer esto con facilidad para este pequeño problema de libro de texto, podría
conducir a tiempos de ejecución inaceptablemente largos para un problema más grande. Si se
quisiera tener la seguridad de que todas las estadísticas de los estados de las piezas estuvieran
basadas en el mismo conjunto de piezas, se podrían reunir los tiempos que cada una de las
piezas pasa en cada actividad y almacenar estos tiempos en atributos de entidades. Cuando la
pieza sale del sistema, entonces se podrían Tally (Contar) todos los tiempos. Aun cuando esto
es posible, requeriría que se hicieran cambios sustanciales al modelo y sería de esperar que la
mayor exactitud no justificara estos cambios.
Si, por un momento, se va hacia atrás, el lector debe de darse cuenta que el problema de
tener estadísticas resumen basadas en actividades diferentes de las entidades no es único para
este problema. Existe para casi todas las simulaciones de estado estacionario que podría cons-
truir. De modo que se recomienda que, en este caso, se siga el mismo procedimiento que se
aplica para el análisis de simulaciones de estado estacionario. Por consiguiente, se agregaría
un Warm-up Period (Periodo de calentamiento) para eliminar las condiciones del arranque.
Debido a que el sistema del que se trató está estrechamente acoplado, no acumulará colas
grandes y su número de piezas tenderá a permanecer más o menos el mismo. En virtud de que
la demora en el almacén se modela como exponencial, es posible que pudiera no haber piezas
en el sistema, aunque esto es muy improbable. En el otro extremo, puede haber un máximo de
sólo ocho piezas en el sistema. Como consecuencia, al añadir un periodo de calentamiento al
modelo se empezará a reunir estadísticas cuando el sistema ya está en operación. Esto reducirá
la diferencia entre el número de observaciones para las Tallies. Por ahora, supongamos sólo un
Warm-up Period de 500 minutos y editemos el cuadro de diálogo Run > Setup > Replication
Parameters para incluir esa entrada. Si éste fuera un sistema mucho más grande que pudiera
acumular colas largas, se podría querer reconsiderar esta decisión.
Si ahora se ejecuta el modelo, se agregará al reporte la información que se muestra en la
figura 9-12.
394 Capítulo 9
Queue
Cola1
Cola 2
Queue
Cola 3
que se van a cargar sobre uno de dos transportadores continuos de los que dispone. En la fi-
gura 9-14 se muestran los módulos requeridos para esta parte del modelo (los módulos Access
son del panel Advanced Transfer). Nótese que no se pueden especificar colas internas para los
módulos Access y la decisión acerca de hacia cuál transportador se dirige la entidad se basa en
características de la cola, no de los transportadores. El módulo PickQ se puede usar para dirigir
las entidades hacia los módulos Access, Seize, Allocate, Request o Queue, o a cualquier módulo
que esté antecedido por una cola.
Ahora encarguémonos del aspecto de una cola Detached. Si se usa el módulo Queue del
panel Blocks, se da la opción de definir la cola como Detached (Separada). Esto significa que
la cola no está directamente ligada a un módulo corriente abajo. Una cola de este tipo se puede
ligar en forma indirecta, como fue el caso con el módulo QPick, o podría no haber enlace obvio.
Por ejemplo, se puede desear el uso de un conjunto de entidades cuyos valores de atributos con-
tuvieran información a la que se podría tener acceso y cambiar en el curso de una simulación.
Si esto es todo lo que se quiere hacer, podría ser más fácil usar una variable definida como una
matriz o, quizá, una base de datos externa. La ventaja de usar una cola es que también se puede
cambiar el establecimiento del rango de las entidades en la misma. Se puede tener acceso a cua-
lesquiera valores de atributos de entidades o cambiarlos, usando variables de Arena. También
se pueden usar los módulos Search (Buscar), Copy (Copiar), Insert (Insertar), Pickup (Tomar)
y Remove (Eliminar) del panel Blocks (o los módulos Search, Remove, Pickup y Dropoff [De-
jar] del panel Advanced Process) para interactuar con las entidades en la cola. Nótese que si es
importante el establecimiento del rango en la cola, Arena sólo lo establece para una entidad que
Access
Conveyor 1
PickQ
Access
Conveyor 2
entra en ella. Por consiguiente, si se cambia el atributo de una entidad, que se use para estable-
cer el rango en la cola, se debe sacar la entidad de esta última y después regresarla a la misma.
9.7 Ejercicios
9-1 Llegan paquetes, con tiempos entre arribos distribuidos como EXPO(0.46) minutos, a
una instalación de descarga. Se tienen cinco tipos diferentes de paquetes, cada uno con una
probabilidad igual para llegar y con su propia estación de descarga. Las estaciones de des-
carga están ubicadas alrededor de un transportador continuo que tiene espacio sólo para dos
paquetes en la cola, en cada una de esas estaciones. Los paquetes que llegan entran a una cola
de capacidad infinita para esperar que se tenga espacio en el transportador de circuito cerrado y
se requieren 2 pies de espacio por paquete. Después de entrar a este transportador, el paquete se
conduce hasta su estación de descarga. Si se tiene espacio en la cola en su estación de descarga,
el paquete se desvía en forma automática hacia esa cola, lo cual no toma tiempo. Entonces el
paquete espera para que lo baje un descargador dedicado (dedicado a esta estación, no a este
paquete), lo cual toma un tiempo distribuido como EXPO(2) minutos. Si un paquete llega a su
estación y encuentra que la cola está llena, se le transporta de manera automática alrededor del
circuito y realiza el intento la vez siguiente. Cada estación está ubicada a 10 pies de la siguiente
y la velocidad del transportador es de 12 pies por minuto. Anime su modelo.
Un muestrario de aspectos y técnicas adicionales de modelado 397
10 pies 10 pies
10 pies 10 pies
Descarga 5 Descarga 4 Descarga 3
a) Ejecute la simulación durante 500 minutos, reuniendo estadísticas acerca del tiempo en
el sistema (juntos todos los tipos de paquetes, no separados por tipo) y del número de
paquetes en la cola en la estación de llegada de éstos.
b) ¿Qué producirá más impacto sobre el tiempo promedio en el sistema: aumentar la ve-
locidad del transportador hasta 15 pies por minuto o incrementar la capacidad de cada
cola de descarga hasta 4?
9-2 Un sistema de transportadores continuos que se unen tiene un transportador principal
que consta de tres segmentos y dos transportadores ramales, como se ilustra en la figura que
sigue. Corrientes separadas de paquetes llegan al extremo de entrada de cada uno de los tres
transportadores, con tiempos entre llegadas distribuidos como EXPO(0.75) minutos. Los pa-
quetes entrantes forman cola para esperar que se haga espacio en el transportador. Los paque-
tes que llegan a la entrada del transportador principal se transportan directamente a la salida
del sistema. Los paquetes que arriban a las dos líneas ramales se transportan hacia el transpor-
tador principal, en donde esperan a que haya espacio. Una vez que se dispone de espacio, salen
de la línea ramal y son transportados hasta la salida del sistema. Todos los segmentos de los
transportadores son 20 pies (el principal tiene tres de esos segmentos) y los tres son acumulado-
res y se mueven a 15 pies por minuto. Cada paquete requiere 2 pies de espacio en un transporta-
dor. Cuando los paquetes llegan al punto de salida del sistema, se tiene un tiempo de descarga
de 0.2 minutos, en el transcurso del cual el paquete conserva el espacio sobre el transportador
principal.
Transportador ramal 2
Salida del
sistema
Transportador principal
Transportador ramal 1
398 Capítulo 9
Desarrolle un modelo y una animación para este sistema y ejecútela durante 300 minu-
tos, observando las estadísticas sobre el estado de los transportadores (como número de paque-
tes que se transportan y se acumulan en cada segmento) así como los tiempos en el sistema para
los paquetes.
9-3 Un pequeño sistema de montaje energizado y automatizado, y libre, consta de seis esta-
ciones de trabajo. (Un sistema energizado y libre podría representar cosas como cadenas remol-
cadoras y líneas de ganchos.) Las piezas se colocan sobre tarimas que se mueven por el sistema
y se detienen en cada estación de trabajo para que se realice una operación. Se tienen 12 tari-
mas en el sistema. Una pieza no trabajada se coloca en una tarima vacía, como parte de la ope-
ración en la Workstation 1 (Estación de trabajo 1). La unidad (pieza y tarima) entonces se mueve
en forma progresiva por el sistema, hasta que se completan todas las operaciones. La pieza final
ensamblada se quita de la tarima en la Workstation 6, como parte de la operación allí. El sistema
energizado y libre se mueve a 4 pies por minuto. Cada tarima requiere 2 pies de espacio. La distan-
cia entre estaciones de trabajo adyacentes es de 10 pies, excepto que la Workstation 6 (la operación
de montaje final) y la Workstation 1 (la operación de principio del montaje) están separadas 20
pies. En la figura que sigue se indica cómo están dispuestas las estaciones de trabajo. Los tiempos
de operación en cada una de las estaciones son WEIB(3.31, 4.2) minutos.
Estación de Estación de Estación de
trabajo 1 trabajo 2 trabajo 3
Desarrolle una simulación y una animación de este sistema y ejecútela durante 1 500 mi-
nutos, observando las estadísticas acerca de la producción por hora. (PISTA: Modele el sistema
energizado y libre como un transportador continuo acumulador. Al principio de su simulación,
cargue las tarimas vacías en la Workstation 6. Estas tarimas se convierten en una parte perma-
nente del sistema.) Observe el efecto sobre la producción por hora del número de tarimas. ¿Se-
rían preferibles más (o menos) de 12 tarimas? ¿Existe algo como un número óptimo de tarimas?
Asegúrese de respaldar sus afirmaciones con un análisis estadístico válido.
9-4 Un pequeño sistema de producción tiene piezas que arriban con tiempos entre llega-
das distribuidos como TRIA(6, 13, 19) minutos. Todas las piezas entran en la zona del andén
(Dock), se transportan a la Workstation 1, después a la Workstation 2, enseguida a la Work-
station 3 y, por último, al andén, como se indica en la figura que sigue. Todo el transporte de las
piezas lo proporcionan 2 carros, moviéndose cada uno a 60 pies por minuto. Las distancias del
andén hasta cada una de las Workstations 1 y 3 son de 50 pies, y las distancias entre cada par
de estaciones de trabajo también son de 50 pies. Las piezas se descargan del carro en las Work-
Un muestrario de aspectos y técnicas adicionales de modelado 399
Estación de trabajo 3
Desarrolle una simulación y una animación de este sistema y ejecútela durante 10 000 minutos;
observe las estadísticas sobre las utilizaciones del carro y la estación de trabajo, así como los
tiempos del ciclo de las piezas.
9-5 Un taller que satisface órdenes especiales recibe pedidos que arriban con tiempos entre
llegadas distribuidos como EXPO(30); todos los tiempos se dan en minutos. El número de pie-
zas en cada pedido es una variable aleatoria UNIF(3, 9) (truncada hasta el entero próximo más
pequeño). Al recibir el pedido, las piezas se sacan de inmediato del inventario y se envían a la
zona de preparación (esta transferencia se realiza en un tiempo cero), en donde pasan por una
operación de preparación por separado, el tiempo para la cual se distribuye como TRIA(2, 3,
4). Después de la operación de preparación, las piezas se transfieren (esta transferencia tarda
4 minutos) hasta una zona de anaqueles para esperar que se emita la autorización final del
pedido. Tal autorización tarda una cantidad de tiempo distribuida como UNIF(180, 240), des-
pués del cual, las piezas se liberan para ser procesadas, lo que requiere una cantidad de tiempo
distribuida como TRIA(3, 4, 6). Después de ser procesadas, las piezas se conforman en un lote
y se envían al empacador (tiempo cero de transferencia) para que se empaquen, lo cual dura
una cantidad de tiempo distribuida como TRIA(8, 10, 14) para el lote. Las piezas empacadas
salen del sistema. En el transcurso del proceso de autorización del pedido, se cancelan 4% de
las órdenes. Estas piezas se sacan de la cola en los anaqueles y se envían de regreso al inventario
(tiempo cero de transferencia). Desarrolle un modelo de simulación para este sistema y ejecúte-
lo durante 20 000 minutos, con un calentamiento de 500 minutos. Observe las estadísticas sobre
el número de pedidos y piezas cancelados, el tiempo en el sistema para los pedidos embarcados
y las utilizaciones de los recursos. Asimismo, use Frequencies con el fin de determinar el número
de rejillas requeridas para tener las piezas en la zona de anaqueles (cada rejilla puede admitir
25 piezas). (PISTA: Use Hold/Signal para la autorización de los pedidos y Search/Remove para
cancelarlos.)
9-6 Un sistema de procesamiento de alimentos arranca procesando un lote de 25 libras de
materia prima del producto, lo cual requiere 1.05 + WEIB(0.982, 5.03) minutos. Supóngase
un abastecimiento infinito del producto en bruto. Tan pronto como se ha completado el pro-
400 Capítulo 9
la más corta. Ningún movimiento adicional, o cambio de fila, en esa dirección ocurre por lo
menos en los 30 segundos siguientes. Desarrolle un modelo y una animación de este sistema y
ejecútelo durante 10 000 minutos. Observe las estadísticas sobre el número de cambios de fila,
la utilización de los recursos y las longitudes de las colas.
9-9 Un pequeño sistema de cruce de andén tiene tres andenes de entrada y cuatro de salida.
Llegan camiones a cada uno de los tres andenes de entrada con tiempos entre arribos distri-
buidos como UNIF(35, 55); todos los tiempos se dan en minutos. Cada camión que llega con-
tiene UNIF(15, 30) tarimas (truncado hasta el entero siguiente más pequeño), el cual se puede
suponer que está descargado en el instante cero. Cada tarima tiene una probabilidad igual de
ir hacia cualquiera de los cuatro andenes de salida. La transportación a través del andén la
proporcionan tres montacargas de horquilla, viajando cada uno de ellos a 60 pies por minuto.
Suponga que la distancia entre cualquier andén de entrada y cualquiera de los de salida es de
50 pies. Asimismo, considere que la distancia entre andenes de entrada adyacentes (y andenes
de salida adyacentes) es de 15 pies.
a) Desarrolle un modelo en el cual los montacargas permanezcan en donde dejaron su
última carga, si no existen nuevas solicitudes pendientes.
b) Modifique su modelo de modo que todos los montacargas libres se envíen al andén de
entrada que está enmedio (Dock 2) para esperar su siguiente carga.
c) Modifique su modelo de modo que cada montacargas se asigne a un andén diferente
de entrada que le sirva de estacionamiento de espera y se mueva a ese andén cuando no
tenga solicitudes adicionales pendientes.
Compare los resultados de los tres sistemas antes mencionados, usando el tiempo del sistema
de tarimas como la medida principal del rendimiento. Asegúrese de respaldar su comparación
con un análisis estadístico apropiado.
9-10 Desarrolle un modelo y una animación de un viaje en una rueda gigante de la fortuna
(conocida en el medio como rueda Ferris) de una chica y bulliciosa feria de una pequeña ciudad.
Clientes agitados (en su mayor parte niños pequeños y cubiertos de azúcar que no saben de algo
que sea mejor) llegan al aparato con tiempos entre arribos distribuidos como EXPO(3) minutos
y se forman en la cola principal. Cuando ha finalizado el viaje anterior y el primer cliente está
listo para bajar, a los cinco clientes siguientes (o menos, si no hay cinco en la cola principal) se
les permite entrar a la zona de ascenso. Conforme un cliente se baja de la rueda, el nuevo cliente
se sube. Nótese que puede haber más pasajeros por bajarse de la rueda que clientes nuevos, o
más clientes nuevos que pasajeros por bajar. Se requiere UNIF(0.05, 0.15) minutos para hacer
bajar a uno de los pasajeros y UNIF(0.1, 0.2) para hacer subir a uno nuevo. La rueda sólo tiene
cinco asientos sencillos con un espacio entre ellos de alrededor de 10 pies, y gira a una velocidad
de 20 pies por minuto. A cada cliente se le dan cinco vueltas en la rueda y no se permite abordar
a nuevos pasajeros hasta que se completa tal viaje. Los pasajeros que se bajan de la rueda co-
rren hacia la salida, lo cual toma 2 minutos. No se tiene la seguridad de si quieren irse o ser los
primeros en la fila en el bullicioso viaje siguiente. (PISTA: Emplee un transportador continuo
para representar esta rueda de la fortuna. Use Wait/Signal para implementar las reglas de carga
y descarga.) Por cierto, la rueda Ferris fue desarrollada por el ingeniero estadounidense G.W.G.
Ferris, quien murió en 1896; su nombre en alemán es Riesenrad, lo cual se traduce aproximada-
mente como “rueda gigante”.
CAPÍTULO 10
Integración y personalización
de Arena
En este capítulo se presentan los temas de integración de los modelos de Arena con otras apli-
caciones y la construcción de módulos personalizados. Se ilustrarán estos conceptos con un
modelo muy sencillo de un centro de atención telefónica (mucho más sencillo que el presentado
en el capítulo 5).
En el primer tema, en la sección 10.1, se presentará un modelo en el que se leen los tiempos
programados de llegada desde un archivo externo y, a continuación, se escriben los datos del
comportamiento en un archivo. Esto se ilustrará de varias maneras diferentes con el fin de in-
corporar datos de fuentes del exterior (como un archivo de texto) en un modelo de Arena. En
la sección 10.2 se presentarán dos tecnologías del sistema operativo Microsoft® Windows® que
explotan Arena para integrarse directamente con otros programas —ActiveX® Automation y
Visual Basic® para Aplicaciones (VBA)— y se describe cómo se ha incorporado VBA en Arena.
Se presentará este material suponiendo que el lector está familiarizado con la programación en
VBA o que tendrá acceso a otras fuentes para adquirir esa familiaridad; el tratamiento de este
tema se enfocará en que Arena dispone lo necesario para poner VBA en términos de usarse. En-
tonces, en la sección 10.3, se mostrará cómo se pueden aplicar estas tecnologías para crear una
interfaz personalizada para el usuario. En la sección 10.4 se continuará con el tema de VBA,
mejorando el centro de servicio telefónico para registrar los datos de las llamadas por separado
y trasladar a una tabla las duraciones de esas llamadas en Microsoft® Excel. Este capítulo se ce-
rrará en la sección 10.5 con un panorama general de cómo el usuario puede diseñar sus propios
módulos para acrecentar las construcciones estándares de Arena para el modelado. Cuando
el lector finalice este capítulo debe de tener una idea de los tipos de características que puede
emplear para integrar Arena con otras aplicaciones de escritorio y de unos cuantos medios para
crear interfaces personalizadas de Arena.
a 1.1 minutos. Para modelar el sistema, se utilizó un solo módulo Create (Crear), un solo módulo
Process (Proceso) y un solo módulo Dispose (Disponer) como se muestra en la figura 10-1.
En la pantalla 10-1 se muestran los datos para los tres módulos y los Replication Parameters
(Parámetros de replicación) deben de fijarse en Run > Setup > Replication Parameters (Ejecutar
> Fijar > Parámetros de replicación), como se ilustra en la pantalla 10-2. Después de crear este
modelo, se puede ejecutar y ver los resultados.
Aunque el modelo del centro de atención telefónica es bastante sencillo se tienen unas cuan-
tos oportunidades de hacerlo más realista. El gerente del centro acaba de informar que tiene
algunos tiempos históricos de llegadas de llamadas para un día típico. Usemos ese registro
de las llamadas reales recibidas durante un periodo para generar entidades en el modelo que
se está trabajando, en lugar de crear entidades basadas en el muestreo de una distribución de
probabilidad. Se podría seguir dicho procedimiento como parte de la validación del modelo
que se está trabajando. Si los resultados de la ejecución de una simulación que sea accionada
por las llegadas registradas del sistema real corresponden con mucha aproximación a los del
comportamiento de ese sistema real en el curso de ese periodo, entonces se tiene mayor fe en la
corrección del modelo lógico que se está aplicando. O se podría emplear esta lógica porque se
quiere realizar ejecuciones con base en un patrón específico de llegadas, como un programa fijo,
pero irregular, de camiones que arriban a los andenes de carga de un centro de distribución.
En la sección 10.1.1 se empezará con el fácil caso de leer los datos de las llegadas desde un
archivo de texto. Después, en la sección 10.1.2, se observará la lectura de datos semejantes pro-
venientes de otras fuentes.
Pantalla 10-1. Los módulos Create (Crear), Process (Procesar) y Dispose (Disponer)
1.038
2.374
4.749
9.899
10.52
17.09 ...
Figura 10-2. Datos de los tiempos de llamadas del modelo revisado del
centro de atención telefónica
Duplicada
Atender la Terminar la
llamada llamada
El módulo Create generará únicamente una sola entidad, como se muestra en la pantalla
10-3. Para este módulo Create, Arena creará una sola entidad al principio de cada replicación,
entonces “detendrá” la corriente de creación de entidades, dado que alcanzó el número de crea-
ciones de entidades especificadas en campo Max Arrivals (Llegadas máximas) (a saber, 1).
La entidad creada entra al módulo ReadWrite (LeerEscribir), véase pantalla 10-4, en donde
lee el valor siguiente del archivo de datos y asigna aquél al atributo de la entidad Call Start
Time (Tiempo de inicio de la llamada). El módulo ReadWrite, el cual se puede hallar
en el panel Advanced Process, lee uno o más valores de una fuente externa a Arena y los asigna a
las variables del modelo. El Arena File Name (Nombre de archivo de Arena), Arrivals File
(Archivo de llegadas), se usa como un identificador del modelo para el archivo. No debe de
confundirse con el nombre real del archivo que se encuentra en el disco duro (o en donde sea que
esté almacenado el archivo), el cual se definirá más adelante en el módulo de datos File.
Después de que la entidad lee el valor del archivo de datos, se mueve al módulo Delay (De-
morar) (pantalla 10-5) para esperar hasta el Call Start Time, de modo que la entidad real,
que representa la llamada, llegue, en la lógica del modelo, en el momento apropiado. Debido a
que los valores en el archivo de datos representan el número absoluto de minutos desde el prin-
cipio de la ejecución, para cada llamada, en lugar de los tiempos entre llegadas, el Delay Time
(Tiempo de demora) se especifica como Call Start Time - TNOW, de modo que la entidad
se retrasará hasta que se alcance el tiempo almacenado en el atributo Call Start Time.
Name (Nombre) Delay Until Actual Call Time (Demorar hasta que
se alcance el tiempo de la llamada real)
Delay Time (Tiempo de demora) Call Start Time – TNOW
Units (Unidades) Minutes (Minutos)
Name (Nombre) Separate into Duplicate Entity for Call Arrival (Separar en
entidad duplicada para llegada de llamada)
Usando los valores de los datos de la figura 10-2, para recorrer la lógica para las dos primeras
llamadas, el control de la entidad primero leerá un valor de 1.038 en su atributo Call Start
Time, después de que se crea en el tiempo 0 de la simulación (el inicio de la replicación). Se
demorará durante 1.038 – 0 unidades de tiempo, saliendo del módulo Delay en el tiempo 1.038.
En ese momento, crea un duplicado, enviándolo al módulo Queue para empezar el procesa-
miento real de una llamada. La entidad de control regresa al módulo ReadWrite, leyendo un
valor de 2.374 del archivo de datos y sobrescribiendo su atributo Call Start Time con este
valor. La entidad de control continúa hasta el módulo Delay, en donde se demora durante 2.374
– 1.038 = 1.336 unidades de tiempo, lo cual hace que Arena coloque esa entidad de control en
el calendario de eventos con un tiempo de ese evento que está 1.336 unidades de tiempo en el
futuro (o un tiempo del evento real de 2.374). Cuando es el turno para que la entidad de control
sea procesada de nuevo, en el tiempo de la simulación de 2.374, Arena la sacará del calendario
de eventos y la enviará al módulo Separate, en donde producirá una entidad de llamada con
el valor 2.374 del atributo Call Start Time, representando la segunda llamada que entra
al sistema. Esto continuará hasta que la entidad de control haya leído todos los valores en el
Model 10-02 Input.text.
La ejecución de la simulación terminará al cumplirse una de dos condiciones. Si se llega al
tiempo de finalización de la ejecución especificado en el cuadro de diálogo Run Setup (Ajuste
de ejecución) antes de que se hayan creado todas las llamadas cuya lista se da en el archivo de
datos, Arena finalizará la ejecución en ese momento; en ninguna condición se puede ejecutar
un modelo durante más tiempo que el definido. Por otra parte, el modelo puede terminar antes
que la duración especificada para la ejecución, si se han creado todas las llamadas que se listan
en el archivo de datos y completado el procesamiento, dejando vacío el calendario de eventos.
(Recuérdese que se dispone de la entidad de control después de que lee el último valor de los
datos.) Si Arena encuentra una condición en donde no hay entidades de más en el calendario
de eventos y no existen controles adicionales basados en el tiempo que tengan que procesarse,
terminará la ejecución después de que la última entidad sale del modelo.
10.1.2 Modelo 10-3 y modelo 10-4: lectura y escritura de archivos Access y de Excel
¿Qué sucede si, en lugar de en un archivo de texto, los datos de las llegadas de llamadas estuvie-
ran en una base de datos Microsoft® Access o en un archivo de hoja de cálculo de Microsoft®
Excel? Se examinará cómo se pueden tratar con facilidad esos dos casos.
En primer lugar, supongamos que se proporciona una base de datos Access que contiene la
información de las llegadas de llamadas, con una tabla nombrada ArrivalTimes para almacenar
los datos. En la figura 10-4 se muestran unos cuantos de los primeros valores de este archivo
(Model 10-03 Input.mdb).
410 Capítulo 10
Empezando con el Model 10.02.doe que se creó en la última sección, sólo se tienen que
hacer unos cuantos cambios pequeños para leer desde la base de datos. Todavía es útil la lógica
del modelo que se construyó para leer y usar esos datos con el fin de controlar la creación de la
entidad. Sólo es necesario cambiar algunos detalles acerca de dónde se obtienen los datos.
En esta ocasión, se empezará por describir el nuevo archivo de datos. Para hacerlo, se edita-
rá el módulo de datos existente de File, que se encuentra en el panel Advanced Process, como
se ve en la pantalla 10-8. Se puede dejar fijo el Arena File Name como Arrivals File.
Recuérdese que éste es el nombre usado dentro de la lógica del modelo (en tal caso, el módu-
lo ReadWrite) para especificar este archivo; no hay razón para cambiarlo. Pero sí se necesita
modificar el Operating System File Name a Model 10.03 Input.mdb.1 Se dejarán la mayor
parte de las demás opciones en sus valores predeterminados, incluyendo la acción de final del
archivo como Dispose, de modo que se dispondrá de la entidad de control después de que lea
el último valor que esté en el archivo, como antes.
Se notará que el campo Access Type (Tipo de acceso) tiene una lista desplegable de seleccio-
nes; en esta ocasión, se elegirá Microsoft Access (*.mdb). Cuando se haga esta selección,
se puede ver una diferencia en la presentación de los campos o columnas, porque los archivos
de bases de datos requieren información diferente a la de los archivos de texto. Específicamen-
te, debe de ver una nueva columna rotulada Recordsets (Conjuntos de registros), arriba de un
botón que, en un principio dice 0 filas. Al hacer clic en ese botón, el Recordsets Editor (Editor
de Recordsets) aparece como en la pantalla 10-9.
1
Cuando se usan archivos con la extensión .mdb (la predeterminada para los archivos de Access), téngase cuidado
en no nombrar el archivo en la misma forma que en su modelo. Arena almacena de forma automática su salida en
el archivo nombrado ModelName.mdbn (NombreDelModelo…) y se sentirá infeliz de ver cualquier estructura de
archivo allí, excepto la propia.
Integración y personalización de Arena 411
A medida que se lee desde una base de datos, se está leyendo un conjunto de registros de
una tabla o rango. Una sola base datos puede tener muchos conjuntos diferentes de registros.
Arena identifica cada conjunto al definir un Recordset Name. Cada uno de éstos debe ligarse a
una tabla en la base de datos. Se podría seleccionar cualquier nombre válido de símbolo para el
Recordset Name pero, por sencillez, se tecleará el mismo que el nombre de la tabla: Arrival
Times. Hágase clic en el botón Add/Update (Agregar/Actualizar) para completar la definición
del Recordset. Debajo del Table Name (Nombre de la tabla), si se hace clic en la flecha, se verá
una lista desplegable de todas las tablas actualmente definidas en la base de datos. En tal caso,
selecciónese la única definida, ArrivalTimes, como se muestra en la pantalla 10-9. Si se de-
seara ver alguna muestra de datos de un Recordset, en primer lugar resáltese ese Recordset en la
columna izquierda y, enseguida, hágase clic en el botón View (Ver).Cuando se haya terminado,
hágase clic en Close (Cerrar) para cerrar el visor. Por último, hágase clic en OK para salir del
Recordset Editor.
El lector se puede preguntar por qué se cambió las propiedades del archivo, antes de modifi-
car el módulo ReadWrite. Si se abre ahora este módulo (como en la pantalla 10-10), se verá que
su aspecto es un poco diferente. En esencia, se ajustó a sí mismo con el fin de reunir la infor-
mación requerida para el tipo de archivo que se está leyendo. En tal caso, reconoce que se está
leyendo de una base de datos y que se necesita identificar el Recordset; se seleccionará Arri-
valTimes de la lista desplegable. Si se quiere controlar la lectura del registro en cada iteración,
introdúzcase una expresión opcional en el campo Record Number (Número de registro). No
obstante, se le dejará en blanco de modo que, de manera predeterminada, lea los registros en
forma secuencial, empezando con el primero. Nótese que no se tiene que cambiar el Arena File
Name o las Assignments (Asignaciones). Hágase clic en OK y queda terminado.
¡Eso es todo! Guarde el modelo que se acaba de crear o búsque el archivo del Model 10-
03.doe que está incluido en el CD. Ahora estamos listos para ejecutar el modelo y hacerlo leer
sus datos del archivo Access, en lugar del archivo de texto.
Si el lector ha seguido con los autores en toda la primera parte de esta sección, se tienen
buenas noticias para él. Ahora ya sabe la mayor parte de lo que se necesita para leer archivos de
hojas de cálculo de Excel. Puede ser que usted advierta que las filas y las columnas de una hoja
de cálculo de Excel se semejan mucho a las filas y las columnas de una tabla de base de datos.
Excel no es un sistema de administración de bases de datos que exprese relación, pero con unas
cuantas advertencias, se puede tratar una hoja de cálculo de Excel de modo muy semejante a
como se maneja un archivo de base de datos de Access.
En Excel, un rango rectangular nombrado, un conjunto de celdas (filas y columnas), es el
equivalente de las filas y columnas de una tabla de Access. Si se le quiere tratar como una base
datos (lo cual se hace aquí), el rango nombrado debe referirse a un conjunto rectangular de por
lo menos dos celdas. Se puede crear un rango nombrado de Excel al hacer resaltar un conjunto
de celdas y, a continuación, seleccionar Insert > Name > Define (Insertar > Nombre > Definir)
y teclear un nombre. Por ejemplo, si se resaltan las celdas A3 a la C9 y se sigue el procedimiento
antes descrito, nombrando la selección del libro de trabajo MyRange (MiRango), tendría tres
columnas y siete filas que se miran de modo muy semejante a una tabla de Access. Si se busca en
la lista desplegable en el cuadro de nombres (por lo común, en la región superior izquierda de la
Integración y personalización de Arena 413
barra de menús), se encontrarán todos los nombres de los rangos de celdas que se hayan defini-
do. Una vez más, esto es equivalente a todo lo de las tablas en una base de datos de Access.
Resumamos con el Model 10-03.doe lo que se acaba de crear en los párrafos anteriores y
modifíquese para leer de Excel, en lugar de Access. En la figura 10-5 se ilustra el archivo de datos
muestra suministrado, Model 10-03 Input.xls. Se puede ver que se ha resaltado el rango
ArrivalTimes, tanto en el cuadro de nombre como en la propia hoja de cálculo. Una vez más,
se empezará por describir el nuevo archivo de datos que se encuentra en el módulo de datos File
existente, como en la pantalla 10-11. Se puede dejar casi todo el conjunto como estaba para Acce-
ss, excepto el File Name y Access Type. Cámbiese el Operating System File Name a Model 10-
03 Input.xls. En la lista desplegable Access Type, elíjase Microsoft Excel (*.xls).
Hagamos de nuevo clic en el botón para cargar el Recordsets Editor. Se tendrá definido un
Recordsets nombrado ArrivalTimes, pero como se elige un nuevo archivo, se ha borrado el
enlace. Selecciónese el Recordset previamente definido a la izquierda y restablézcase el enlace.
La lista desplegable que está debajo de Named Range (Rango nombrado) mostrará todos los
rangos nombrados que se encuentran definidos en ese archivo. Con suerte, ahí aparecería (está
bien, los autores lo planearon con anterioridad), la hoja de cálculo de Excel que tiene un rango
nombrado precisamente como la tabla que se usó con anterioridad. Selecciónese Arrival
Times y hágase clic en Add/Update para registrar el cambio. Si se quisieran ver algunos datos
muestra de un Recordset, en primer lugar hágase resaltar éste en la columna izquierda, ensegui-
da hágase clic en el botón View para ver algo parecido a la pantalla 10-12. Una vez que se haya
terminado, hágase clic en el botón Close para cerrar el visor. Por último, hágase clic en OK para
salir del Recordset Editor.
Puesto que ya se ha revisado el módulo Read/Write para leer del ArrivalTimes Recordset,
no se requieren cambios adicionales. Ahora estamos listos para ejecutar el modelo, en esta oca-
sión leyendo los datos del archivo de Excel.
Ahora que se sabe cómo leer archivos de Access y de Excel, estamos preparados también para
escribir en ellos. Básicamente, se tiene un cambio que es necesario escribir, en lugar de leer datos,
En el operando Type (Tipo) del módulo ReadWrite, elíjase Write to File (Escribir en
el archivo), en lugar de Read from File (Leer del archivo). Todo lo demás funciona
precisamente como se describió en la información acerca de leer antes dada. Por supuesto, casi
siempre existe una trampa. Aquí es que, cuando se está escribiendo en archivos de Access o Excel,
debe existir el archivo esquema. ActiveX® Data Objects (Objetos de datos ActiveX, ADO, por
sus siglas en inglés), una tecnología de Microsoft que proporciona acceso de alto rendimiento a
datos para diversos almacenes de éstos, obtiene su estructura del archivo y la información sobre
formateo del propio archivo. Específicamente, ya deben de existir la tabla o rango nombrado.
Una restricción adicional para los archivos de Excel es que si el rango no está formateado como
numérico, con algunos datos iniciales, entonces todos los datos se escribirán como cadenas. La
solución sencilla es poner algunos datos muestra formateados en el rango, antes de escribir. Para
obtener información más detallada, véase el tema de ayuda de Arena “Excel: Read/Write Limita-
tions Using ADO” (“Excel: Limitaciones de Lectura/Escritura al usar ADO”).
Se hará una mejora final al modelo del centro de atención telefónica que permita registrar los
tiempos de procesamiento en el mismo archivo de Excel del cual se leen los tiempos de llegada,
pero en una nueva hoja de cálculo. Se tiene un nuevo archivo de datos llamado Model 10-04
Call Data.xls, el cual contiene la misma información que el Model 10-03 Input.xls,
además de un nuevo rango llamado ProcessTimes (TiemposDeProceso) que se definió
en una nueva hoja de cálculo llamada OutputData (DatosDeSalida). El rango Process
Times se ha formateado como numérico y tiene un cero en la primera celda. Sólo para ilustrar
la posibilidad, también se ha agregado el esquema de una gráfica para la nueva hoja de cálculo.
Aun cuando ahora está vacía, cuando se escriban los datos en la hoja de cálculo se tomarán en
forma automática y se presentarán en la gráfica.
Integración y personalización de Arena 415
En primer lugar, se necesita cambiar el módulo de datos File para especificar el nombre del
nuevo archivo y usar el Recordsets Editor para especificar que se tiene un segundo rango en ese
archivo. Con estos cambios, el módulo debe de mirarse como la pantalla 10-13.
Se necesita ajustar la lógica de modo que después de que se complete el procesamiento de la
llamada, se pueda escribir en el archivo el tiempo transcurrido en el procesamiento. Agréguese
un módulo ReadWrite inmediatamente antes de la terminación de la llamada, como se muestra
en la figura 10-6.
Se quiere escribir en el mismo archivo, Model 10-04 Call Data.xls, del que se leyó
en el módulo ReadWrite anterior. Pero, en esta ocasión, se especificará ProcessTimes para
Duplicada
Escribir el
Atender la Terminar la
tiempo de pro-
llamada llamada
cesamiento
Figura 10-6. Lógica para escribir los datos de tiempo del proceso
416 Capítulo 10
la Recordset ID. El valor que se desea escribir es una expresión calculada, de modo que se ne-
cesita especificar el Type de Other (Otro). En el campo Other, se introduce la expresión para
el tiempo de procesamiento, con la cual se resta el Call Start Time del tiempo actual (TNOW),
como se muestra en la pantalla 10-14.
Ahora se está listo para realizar la ejecución. En este modelo, se leerán los mismos datos que
antes pero, ahora, conforme se complete cada llamada, su tiempo de procesamiento se escribirá
en la hoja de cálculo OutputData. Cuando se complete la ejecución, la hoja de cálculo se mirará
como algo semejante a la figura 10-7.
File para el modelo que se creó en la sección 10.1.1. En el módulo de datos File, selecciónese un
Access Type de Sequential File (Archivo secuencial). Para la Structure (Estructura),
se tecleará, en un formato de FORTRAN o de estilo C, describiendo que habrán de saltarse las
primeras ocho columnas y, a continuación, leer los datos; véase la pantalla 10-15.
De paso, ¿qué se podría hacer si los datos no estuvieran en las primeras columnas de la tabla?
Si se puede uno dar el lujo de cambiar el archivo, la elección obvia sería definir el rango o la tabla
de modo que abarque con exactitud los datos que es necesario leer. Por ejemplo, si se tuviera una
hoja de cálculo con un rango nombrado que se define como las columnas A hasta la C, pero los
datos sólo estuvieran en la columna C, el mejor procedimiento sería definir un nuevo rango de sólo
esta columna. Por desgracia, en muchos casos, no es posible cambiar el archivo; en esos casos, la
mejor elección puede ser sencillamente leer y descartar los datos extraños. Se puede hacer esto si
Part 1 1.038
Part 27 2.374
Part 5194.749
Part 67 9.899
Part 72 10.52
Part 1 6 2 1 7 . 0 9 ...
Figura 10-8. Más datos acerca del tiempo de las llamadas para el modelo
revisado del centro de atención telefónica
se define una variable desechable y leen los datos extraños hacia ésa. Para continuar el ejemplo, se
podría definir una variable llamada JunkValue (ValorBasura) y poblar el módulo Read como
se muestra en la pantalla 10-16 con el fin de pasar por alto las dos primeras columnas del rango.
No se desespere si los datos están en un archivo más complicado de Access o Excel que los que
se acaban de describir, si los datos requieren técnicas más refinadas para acceder a ellos o si son
de otro paquete. Microsoft tiene una solución para ayudar, ADO, y las buenas noticias son que el
lector ya la ha usado. Las interfaces de Excel y Access que se utilizaron en el ejemplo anterior se
implementaron usando ADO y Arena hizo la mayor parte del trabajo para facilitar la realización
de las tareas comunes. Sin embargo, si sucede que se encuentra algo un poco más complejo, el
esfuerzo de aprender un poco de ADO puede reportar grandes dividendos. No se ahondará en
ADO complejos, pero se mostrarán un par de ejemplos sólo para incitar la curiosidad del lector.
Si, en el módulo de datos File, se especifica un Access Type de Active Data Objects
(ADO) (Objetos activos de datos), aparecerá un campo nuevo (Connection String,
Provider=Microsoft.JET.OLEDB.4.0;
Data Source=C:\Documents\Book1.xls;
Extended Properties=””Excel 8.0; HDR=Yes;””
Cadena de conexión). La cadena de conexión se usa para personalizar la interfaz ADO al pre-
sentar información como el proveedor, el nombre del archivo y cualesquiera otros trozos esco-
gidos que se requieran para completar la conexión. Digamos que se quiere ignorar el soporte
integrado para Excel y personalizar el propio, quizá porque se desea soportar encabezados de
columnas. Se podría introducir la cadena de conexión especificada en la pantalla 10-17. O bien,
si se quiere usar el controlador para el SQL Server con el fin de conectarse a una base de datos
BizBikes en el Microsoft SQL Server RSI-Joe, se podría usar una cadena de conexión
como la de la pantalla 10-18. En los dos casos, estas cadenas se introducirían como una cadena
continua en el campo Connection String del módulo de datos File.
Es importante que el lector sepa que la entrada/salida (I/O) del archivo puede afectar la velo-
cidad de ejecución y puede ser lenta en comparación con las demás tareas de procesamiento. En
muchos casos, puede ser que no importe si el acceso es lento, porque la cantidad de tiempo que
se consume en la lectura o escritura de datos a menudo es trivial en comparación con el tiempo
requerido para ejecutar el resto del modelo. Pero la velocidad de I/O puede ser importante con
volúmenes muy elevados de datos. En esos casos, se podría querer especificar los datos para que
estén en la forma más rápida o más pequeña posible. Aun cuando, en general, ADO compite
bien en facilidad de uso y flexibilidad, a menudo tiene problemas con la velocidad de ejecución.
Con frecuencia, los ganadores en la competencia en la velocidad y tamaño del archivo son los
archivos binarios. En éstos, se almacenan los datos en una forma legible para la máquina que
la persona promedio no puede descifrar con facilidad. Por esa razón, es una mala selección si
las personas interactuarán directamente con los datos. Pero para pasar datos entre programas
en la misma plataforma se pueden generar archivos que sean muy pequeños y fáciles de leer y
de escribir en ellos. Para archivos grandes o para los que se debe de tener acceso con frecuencia,
ésta podría ser una consideración importante. La mayor parte de los lenguajes para computa-
dora soportan la lectura y escritura de archivos binarios. Incluso se puede utilizar Arena para
una antigua conversión de archivos hacia formas binarias que, entonces, se vuelven a usar con
frecuencia más adelante en el curso de ejecuciones con fines de experimentación.
Para experimentar con esta opción, en el módulo de datos File, seleccione un Access Type
de Sequential y una Structure de Unformatted (No formateado).
de la animación, obtener los valores de las estadísticas de salida de la simulación o cambiar los
valores de los operandos de módulos.
Cuando se escribe el código Visual Basic usando VBA en Arena, aquél se almacena con el
archivo del modelo del propio Arena (.doe), precisamente como las macros VBA en Excel se al-
macenan en los archivos de las hojas de cálculo (.xls). Se tiene a disposición el arsenal completo
de las características de VBA, incluyendo:
< construcciones de programación Visual Basic, como Sub, Function (Función), Class
(Clase), If (Si), Elseif (DeOtraManeraSi), Endif (FinalizarSi), While (Mientras), Wend
(Dirigir), Do (Hacer), On Error (En error) y Select Case (Seleccionar caso);
< UserForms (Formas del usuario) (a menudo mencionadas como cuadros de diálogo) con
un surtido de bonitos botones llamativos como aquellos de función alternante, barras
de desplazamiento, cuadros de entrada, botones de comandos y los siempre populares
botones de rotación.
< herramientas para eliminar errores en códigos como guardianes, puntos de interrupción
y varias opciones de pasos, y
< ayuda completa.
Para abrir el Visual Basic Editor en Arena, selecciónese Tools > Macro > Show Visual Basic
Editor, o bien, hágase clic en el botón correspondiente en la barra de herramientas de Integra-
tion (Integración) ( ). Con esto se abre una ventana separada que aloja todo lo referente al
código de VBA, formas, interfaz de corrección de errores y acceso a la ayuda de VBA, como se
ilustra en la figura 10-9.
Esta ventana es una “ventana hija” de la de Arena, de modo que si se abandona el progra-
ma, la ventana del Visual Basic Editor seguirá en forma automática a su padre, cerrándose
también. (Si sólo todos los niños se comportaran tan bien.) Además, los cambios en la ventana
de Arena, como la apertura de un modelo nuevo, se reflejan en la información proporcionada
en la ventana del Visual Basic Editor. Esta relación refleja la arquitectura del VBA integrado en
aplicaciones anfitrionas como Arena; el código de VBA le pertenece al documento padre y no
se puede tener acceso a él excepto a través de la aplicación anfitriona.
ModelLogic (LógicaDelModelo) en el Visual Basic Editor y elíjase el evento deseado (por ejem-
plo, RunBegin [EmpezarEjecución]) en la lista de procedimientos que está a la derecha.
Los eventos VBA integrados de Arena caen en tres amplias categorías. (Todos los nombres
reales de las funciones van precedidos por ModelLogic_ [LógicaDelModelo], como Mo-
delLogic_DocumentOpen [LógicaDelModelo_AbrirDocumento].)
< Eventos previos a la ejecución (por ejemplo, DocumentOpen [AbrirDocumento],
DocumentSave [GuardarDocumento]).
< Eventos de ejecución iniciados por Arena (por ejemplo, RunBegin [IniciarEjecu-
ción], RunBeginSimulation [IniciarEjecuciónDeSimulación], RunEnd
Replication [FinalizarEjecuciónDeReplicación]).
< Eventos de ejecución iniciados por el modelo/usuario (por ejemplo, UserFunction
[FunciónDelUsuario], VBA_Block_Fire [VBA_Block_Disparar), OnKey
stroke [GolpeDeTeclaParaAcción]).
Los eventos que se presentan en la lista de procedimientos proporcionan el conjunto com-
pleto de lugares en donde se puede activar el código VBA. De modo que una de las primeras
decisiones que hay que encarar es cuál(es) evento(s) se usará(n) de modo que se pueda llamar
el código en el momento apropiado para que realice cualquier caso que se desee que haga. Los
eventos previos a la ejecución, como DocumentOpen y DocumentSave, proporcionan opor-
tunidades para que se ejecute el código VBA con ciertas acciones iniciadas por el usuario (por
ejemplo, abrir y guardar un modelo). Sin embargo, la mayor parte del soporte para los eventos
de VBA en Arena se centra en torno a la ejecución de la simulación. Siempre que se inicia una
ejecución (por ejemplo, al seleccionar Run > Go [Ejecutar > Ir]), ocurre una secuencia de ac-
ciones de Arena y eventos de VBA (figura 10-10).
Arena llama en forma automática cada uno de estos eventos (cuya lista se da en negritas en
la figura 10-10) a medida que se inicia la ejecución, se realiza y termina. Si no se ha escrito el
código VBA para un evento, entonces no tendrán lugar acciones especiales; Arena se comporta
como si el evento no existiera. (Eso es lo que ha estado sucediendo desde el principio.) Sin em-
bargo, si se abre el Visual Basic Editor y se teclea el código VBA en uno o más de estos eventos,
entonces Arena ejecutará ese código en el transcurso de la ejecución, como se verá en las dos
secciones siguientes de este capítulo.
1. RunBegin (IniciarEjecución)
3. RunBeginSimulation (IniciarEjecuciónDeSimulación)
4. RunBeginReplication (IniciarEjecuciónDeReplicación)
OnKeystroke (GolpeDeTeclaParaAcción)
6. RunEndReplication (FinalizarEjecuciónDeReplicación)
7. RunEndSimulation (FinalizarEjecuciónDeSimulación)
9. RunEnd (FinalizarEjecución)
En la figura 10.10, también se señala un aspecto importante de los tiempos de estas llama-
das, sin importar el tipo de datos de los que se disponga para el código VBA. Mientras se esté
editando el modelo de Arena, se definen las variables de simulación, contadores, estadísticas,
etc., como parte de la estructura del modelo, a través de la información que se ha proporciona-
do en los módulos, pero todavía no se han creado para usarse en la ejecución de la simulación
(por ejemplo, aún no se tiene valor promedio de un número en la cola, o ningún estado para un
recurso). De modo que cuando el modelo se encuentre en tal estado de edición, sólo se puede
trabajar con los valores de los operandos de los módulos (los campos en los cuadros de diálogo
de los módulos y las celdas de las hojas de cálculo). En el modelo 10-5 se utilizará este procedi-
miento para modificar los valores en el campo Max Arrivals de dos módulos Create.
Cuando se arranca una ejecución, Arena hace las verificaciones e inicializa el modelo, tra-
duciendo la información que se ha proporcionado en los módulos hacia el formato requerido
para realizar la simulación y colocar el modelo en un estado de ejecución. En el transcurso de la
ejecución, se pueden examinar y cambiar los valores de las variables, los estados de los recur-
sos, las estadísticas, etc., a través del controlador de la ejecución de Arena y a través del código
VBA. En el modelo 10-6, en el cual se envían los valores de las estadísticas de la ejecución a
Microsoft Excel, se ilustra este uso de VBA. Al final de la ejecución, Arena destruye dicha in-
formación y regresa el modelo a un estado de edición.
Volviendo a los eventos integrados en Arena, se describirán con brevedad cada uno de los
pasos que se muestran en la figura 10-10. Nótese que los elementos de esta figura, cuya lista se
encuentra en negritas, corresponden a eventos de los que se dispone en Arena; las frases que
se muestran en cursivas sencillamente describen los pasos notables en el procesamiento de la
ejecución de Arena.
1. Se llama a ModelLogic_RunBegin.
En este punto, el código VBA puede realizar cambios en los datos estructurales del
modelo —es decir, los valores en los operandos de los módulos— y hace que éstos se
incluyan en la ejecución de la simulación. Sin embargo, RunBegin no puede cambiar
en forma directa los valores del tiempo de ejecución de la simulación (por ejemplo,
variables, atributos de entidades), porque todavía no se ha inicializado esa simulación.
Se podría utilizar este evento para comprobar las entradas que se sobrescribirán y
que están almacenadas en los módulos (por ejemplo, una probabilidad en un módulo
Decide). En el modelo 10-5 se ilustra tal uso del evento.
2. Arena hace las verificaciones del modelo e inicia la simulación para llevarla a un estado
de ejecución.
Este proceso tiene lugar detrás del escenario, en donde Arena verifica que el modelo
esté listo para ejecutarse. Después de que se verifica y se inicia el modelo en este paso,
Arena ignora lo que está contenido en los módulos, trabajando en lugar de ello con los
datos del tiempo de ejecución de la simulación, los cuales cambian en forma dinámica
una vez que se ha arrancado la ejecución. En este punto, a todas las variables se les han
asignado sus valores iniciales (por ejemplo, los números que se teclearon en la hoja de
cálculo Variables), los recursos se encuentran en sus capacidades iniciales, pero todavía
no se han introducido entidades al modelo.
3. Se llama a ModelLogic_RunBeginSimulation.
Aquí, Arena da la posibilidad de insertar el código VBA que se ejecutará sólo una
vez al principio de la ejecución de la simulación. (Por supuesto, si, en el paso 2, Arena
424 Capítulo 10
10.2.2. Si se escribe cualquier código que usa el objeto SIMAN, debe ejecutarse mientras el mo-
delo se encuentra en un estado de ejecución (es decir, entre los eventos RunBegin y RunEnd).
Las propiedades y métodos que el objeto SIMAN hace que se pongan a disponibilidad pro-
porcionan acceso a todas las variables y estadísticas relacionadas con la ejecución del modelo
(por ejemplo, número en la cola, valor promedio del conteo, tiempo actual de la simulación), así
como a unas cuantas acciones de modelado para crear entidades y enviarlas al modelo. El obje-
to SIMAN no proporciona capacidades de modelado ni datos de la simulación más allá de que
estén disponibles en un modelo de Arena. Esta interfaz de automatización es sencillamente una
manera alterna para alcanzar la información, o cambiar ésta, en el modelo. En la sección 10.4
se verá cómo puede ser útil esto, cuando se envían datos del modelo de Arena hacia Excel.
del Macro y la Description en este cuadro de diálogo, como se ilustra en la pantalla 10-19. (Nótese
que los nombres VBA de los macros no pueden contener espacios.)
Tan pronto como se selecciona OK, se empieza a grabar el macro (en un momento se hablará
más sobre ello) y la barra de herramientas Record Macro cambia a ) para indicar que se
encuentra en progreso una sesión de grabación de un macro. Se oprime el botón Start > Pause
> Resume (Comenzar > Pausa > Resumir) para indicar que en ese momento se están grabando
las acciones deseadas. Si se oprime el botón de nuevo, se pausa la grabación, pero no se finaliza
la sesión; sencillamente se vuelve a oprimir el botón para reanudar. Cuando se está grabando
o pausando una sesión, se dispone del botón End (una indicación de que se está grabando una
macro) que se puede oprimir en cualquier momento para detener la grabación.
Una vez que se activa la grabación de una macro, hay que asegurarse de realizar sólo aque-
llos pasos que se quieren grabar. Se pueden grabar las acciones definidas en el modelo de ob-
jetos de Arena, pero no algunas acciones como las entradas del cuadro de diálogo del módulo.
Si se quiere cambiar los datos del módulo, se debe hacer usando la interfaz de hoja de cálculo.
Debido a que se desea examinar cómo colocar un módulo y fijar sus operandos, eso es lo que
se hará a continuación. Selecciónese un módulo Create del panel Basic Process y colóquese en
Figura 10-14. Fijación de los parámetros de Create en el curso de la grabación de una macro
430 Capítulo 10
la ventana del modelo. Enseguida, utilícese la interfaz de hoja de cálculo para fijar el Name
(Nombre), Entity Type (Tipo de entidad) y Value (Valor), como se muestra en la figura 10-14.
Oprímase el botón End en la barra de herramientas Macro Record para detener la graba-
ción y, automáticamente, almacenar el código generado en el módulo VBA nombrado Place
CreateModule (ColocarMóduloCrear). Cárguese el Visual Basic Editor (Tools > Macro >
Show Visual Basic Editor) [Herramientas > Macro > Mostrar Editor de Visual Basic] y, después,
hágase doble clic sobre ThisDocument para ver el código que se acaba de generar, como se mues-
tra en la figura 10-15. Es una subrutina con el mismo nombre que se dio a la macro, seguido por la
descripción que se introdujo. La línea que sigue realiza el trabajo real de colocar el módulo en las
coordenadas x y y especificadas. Las tres líneas siguientes fijan los operandos que se cambiaron en
la interfaz de hoja de cálculo. Y, por último, la línea que se halla hasta el final cierra la subrutina
y finaliza el macro.
Cerremos el VB Editor y regrese al modelo para probar el nuevo código. Seleccione Tools >
Macro > Run Macro para abrir el cuadro de diálogo Run Arena Macro (ilustrado en la pantalla
10-20), el cual proporciona una lista de todos las macros que se han definido (sólo uno hasta
ahora) y da algunas opciones para la ejecución. Seleccióne el botón Run. Aunque, de hecho,
puede parecer que nada sucedió, se colocó un módulo Create nuevo en las coordenadas x/y
exactas del antiguo, precisamente como se dijo que se hiciera. Si se arrastra hacia un lado el
módulo de arriba, se verá el módulo original escondido directamente debajo. Una mirada más
cuidadosa muestra que los parámetros del módulo nuevo todavía se encuentran en sus valores
predeterminados. ¿Puede ser eso lo correcto? Se le dijo colocar un módulo Create y lo hizo.
Hasta aquí, muy bien. Pero miremos de nueva cuenta el código de la figura 10-15.
La mayor parte de los comandos VBA funcionan en el objeto seleccionado en este momen-
to (Model.ActiveView.Selection, [Modelo.VistaActiva.Selección]). En el caso
presente, el módulo que se creó todavía estaba activo y su etiqueta es object.11. Para fijar el
operando del módulo que se acaba de crear, cada una de las tres líneas ejecuta un smFindTag
(smHallarEtiqueta) sobre el “object.11”. De modo que parece que el macro tiene graba-
do en forma correcta exactamente lo que se hizo. Pero recorramos lo que sucede al ejecutarlo. La
primera línea posiciona un nuevo módulo Create exactamente en donde se colocó el original; ya
se ha visto ese trabajo. La segunda línea encuentra el object.11, el objeto original y fija su ope-
rando. El macro funciona como se diseñó, pero no como se pretende. Si se regresara al modelo,
borre los dos módulos y ejecute la macro de nuevo, ¿qué se esperaría que sucediera? Se obtendría
un error porque se estaría buscando un objeto que no existía.
Es obvio que la macro que se acaba de crear no es demasiado útil para ejecutarse, de modo
que podría surgir la pregunta ¿en dónde se encuentra su valor? Aunque hay algunas aplicaciones
Integración y personalización de Arena 431
en las cuales se puede grabar una macro y, a continuación, usarla repetidas veces sin cambios,
en la mayor parte de los casos esto no será cierto. Típicamente, el valor se encuentra al mirar el
código que se generó. Aun cuando la macro anterior fue trivial, proporciona una gran cantidad
de información. Se puede ver cómo colocar un módulo y cuáles parámetros se requieren. Se sabe
cómo hallar un objeto usando su etiqueta. Se conoce cómo fijar los operandos en un módulo y los
nombres de los tres operandos específicos que se deseaban cambiar. En pocas palabras, esa macro
sencilla dio un gran arranque en salto para escribir algún código real.
El valor primario del grabador de macros es hacer que sea más fácil aprender y establecer
como prototipos las extensiones del modelo VBA. Una vez que se sabe cómo se hace, se pueden
aplicar esas mismas técnicas para resolver otros problemas. No hay límite para el número de
macros que se pueden crear y pueden mezclarse y acoplarse técnicas a partir de varias diferentes,
según se necesite. En pocas palabras, la capacidad de grabación de macros, usada en combinación
con las otras técnicas que se aprendan en este capítulo, puede ser una adición poderosa al “saco
de trucos”.
Demorar hasta
Crear unidad Leer el tiempo Separar en entidad du-
que se alcance Original
de control para siguiente de plicada para la llegada
el tiempo de la
leer datos llegada de la llamada
llamada real
Duplicada
Atender la Terminar la
llamada llamada
Crear
llamada
cución, se desplegará una UserForm (término de VBA para referirse a un cuadro de diálogo)
que proporciona las opciones, como se muestra en la figura 10-16.
El usuario selecciona la opción deseada haciendo clic sobre el botón apropiado de opción,
enseguida da clic en OK para hacer que comience la ejecución de la simulación. Se escribirá el
código VBA para realizar los cambios requeridos al modelo, de modo que sólo uno de los tipos
de llegada de llamada envíe en realidad entidades hacia él. Y, después, al final de esta sección,
los autores tendrán una sorpresa para el lector que le añadirá un poco de buen tono al modelo
con un trocito rápido de código VBA. Por lo que no fisgonee adelante… ¡primero tendrá que
recorrer su camino por el material “divertido con formas”!
Antes de continuar, se van a hacer dos cambios adicionales al modelo que explotarán el có-
digo VBA con el fin de hallar los módulos Create apropiados. Aunque es probable que el lector
no se diera cuenta, cada objeto en un modelo de Arena tiene una etiqueta (tag) asociada. Tal
etiqueta no se muestra en cualquier parte cuando se visualizan los objetos; sólo es accesible a
través del cuadro de diálogo Properties (Propiedades), el cual se abre al hacer clic con el botón
derecho del mouse sobre el objeto y seleccionando la opción Properties, como se muestra en la
figura 10-18 para el módulo Create Arrivals (Crear llegadas).
Arena asigna estas etiquetas conforme se agregan los objetos, usando un formato “Object.
nnn”, en donde nnn es un entero que se incrementa a medida que se coloca cada objeto nuevo
en el modelo (por ejemplo, Object.283). Se cambiará la etiqueta para el módulo Create en el
que se use el proceso aleatorio a Create from random process (Crear a partir
de proceso aleatorio), como se muestra en la figura 10-18, y se cambiará la etiqueta del
módulo Create de llamadas de archivo a Create from file (Crear desde archivo).
Hágase clic con el botón derecho sobre cada módulo Create y selecciónese la opción Properties
Crear entidades
usando tiempos aleatorios
Crear
llamada
Figura 10-18. Cambio de la etiqueta del Module a través del cuadro de diálogo Properties
434 Capítulo 10
del menú, enseguida tecléense las etiquetas apropiadas. Más adelante, cuando el código VBA
necesite hallar estos módulos particulares, usará un método Find (Hallar) para buscar un valor
de etiqueta que corresponda, el cual se sabría que es singular, ya que son los únicos que se les
asignaron a estos módulos.
Por supuesto, se necesitará desplegar la forma para el usuario, quien seleccionará cuál tipo
de llegada se desea. Se hará eso al insertar una sola línea de código en el evento RunBegin. Se
puede llegar a este evento haciendo doble clic en ThisDocument, en el cuadro Project, selec-
cionando a continuación ModelLogic, en la lista desplegable de la izquierda, y en RunBegin,
en la lista de la derecha, como se muestra en la figura 10-21.
En la figura 10-22 se muestra el código para desplegar la forma, que se puede leer empezan-
do a la derecha y leyendo hacia el principio; se va a “Show” (“Mostrar”) el objeto (en este caso,
una UserForm) nombrado frmArrivalTypeSelection.
Esta línea del código presentará la forma y le pasará el control del programa a ella, siempre
que se inicie la ejecución de la simulación. Después de que se ejecuta el evento Show, se sus-
pende VBA hasta que el usuario realice alguna acción que inicie un evento VBA para la forma.
Asimismo, Arena queda en pausa hasta que el código VBA regresa del evento RunBegin,
dejando tiempo para que el usuario decida qué hacer y para que VBA complete su trabajo
RunBegin. De modo que si se quisiera ejecutar el modelo en este punto, VBA de Arena des-
plegaría de inmediato la forma y esperaría a que alguien le indique que siga adelante, de modo
que pueda iniciarse la ejecución. Todavía no se ha escrito algún código para que haga eso, de
modo que puede parecer que el lector se ha quedado atascado. Por suerte, la forma VBA tiene
un cuadro para cerrar (el pequeño botón que se localiza arriba a la derecha del cuadro de diá-
logo) en el que se puede dar clic para hacer que la forma se vaya y permitir que Arena arranque
la ejecución.
Aunque la siguiente vez que se desee que intervenga el código VBA será después de que el
usuario haya hecho la selección del tipo de llegada y dado clic en el botón OK. Aun cuando la
forma se despliegue, el usuario puede cambiar su manera de pensar tan a menudo como lo desee
haciendo clic en los botones de opción. Pero cuando ha formulado su respuesta final y hecho
clic en OK, se desea que el código VBA sea capaz de fijar los valores apropiados en los módulos
Create, hacer que la forma desaparezca y que se inicie la ejecución.
Las VBA UserForms han predefinido eventos semejantes a los de Arena. Se insertará el código
en el evento que está ligado al clic del usuario en el cmdOK de la UserForm. Ábrase la ventana de
diseño de la forma dando doble clic sobre la entrada frmArrivalTypeSelection del cuadro
Project, enseguida hágase doble clic sobre OK. El Visual Basic Editor de manera automática abre
la ventana del código que está asociada con la UserForm e inserta los enunciados para empezar y
finalizar para el evento cmdOK_Click( ), como se muestra en la figura 10-23.
En este evento, se escribirá todo el código que intervenga según la selección del usuario. El
código necesitará hacer lo siguiente:
< Localizar cada uno de los dos módulos Create
< Fijar el valor del campo Max Arrivals en cada módulo Create
< Agregar el código para la sorpresa divertida (¡y que el lector piensa que los autores ol-
vidaron!)
< Cerrar la UserForm
Resulta útil comprender que en el modelo de objeto de Arena, por lo común se diseña el
código para imitar las acciones que se tomarían en forma interactiva con un ratón y el teclado.
De modo que si se reflexiona sobre de los pasos que se han estado dando para modificar los
módulos Create, la primera acción sería hallar y abrir un módulo Create y editar sus campos, y
después se repetirían estos pasos para el segundo módulo Create.
Para describir el código para el evento cmdOK_Click, en principio se van a presentar sec-
ciones más pequeñas del código en las figuras 10-24, 10.25 y 10-28, de modo que el lector pueda
consultar con mayor facilidad las líneas del código VBA a medida que lee la narración. En la
figura 10-29, se repite todo el código en el procedimiento cmdOK_Click completo, de modo
que se pueda ver cómo se ajusta en conjunto.
Se empezará con el código para localizar cada uno de los dos módulos Create, de modo que
se puedan asignar los valores apropiados a los campos Max Arrivals. Se utilizarán los valores
de las etiquetas que se asignaron en la sección 10.3.1 con el fin de hallar los módulos VBA a
partir del código VBA, como en la figura 10-24. (Se incluyeron los enunciados Dim para las
Set the Max Arrivals fields (Fijar los campos Máx de llegadas)
If optFromRandomProcess.value = True Then
oCr
eateRandomProcessModule.Data(“Max Batches”) = “Infinite”
[Si DeProcesoAleatorio.valor = Verdadero Entonces oCrearMódu
loDeProcesoAleatorio.Datos(“Máx de lotes”) = “Infinito”]
oCr
eateFileModule.Data(“Max Batches”) = “0”
[oCrearMóduloDeArchivo.Datos(“Máx de lotes”) = “0”]
Else (De lo contrario)
oCr
eateRandomProcessModule.Data(“Max Batches”) = “0”
[oCrearMóduloDeProcesoAleatorio.Datos(“Máx de lotes”) = “0”]
oCr
eateFileModule.Data(“Max Batches”) = “1”
[oCrearMóduloDeArchivo.Datos(“Máx de lotes”) = “1”]
End If (Finalizar Si)
Figura 10-25. Actualización de los módulos Create con la selección del usuario
variables usadas en esta sección del código, aunque es usual —pero no requerido— colocar to-
das las declaraciones de las variables arriba de la función, como se hace en el código comple-
to cuya lista se da en la figura 10-25.) La línea que fija la variable nCreateRandomProcess
Index (nCrearÍndiceDeProcesoAleatorio) le dice a VBA que Find (Encuentre), en
la colección de Modules contenidos en el oArrivalsModel (oModeloDeLlegadas), el ele-
mento cuyo valor de etiqueta es Create from random process (Crear a partir de
proceso aleatorio). (La constante smFindTag [smHallarEtiqueta] exige Find con
base en la correspondencia de etiquetas, en lugar de los nombres de módulos.) De modo se-
mejante, la variable nCreateFileIndex (nCrearÍndiceDeArchivo) encuentra el módulo
Create por la creación de un archivo. Después de que se evalúa cada índice, se usa para apuntar la
variable correspondiente (oCreateRandomProcessModule u oCreateFileModule) hacia
el módulo Create. Las proposiciones If que prueban si los valores del índice que se reciben como
respuesta son iguales a 0 están allí para dar lugar a un mensaje de que ningún módulo tiene el
valor de etiqueta que se necesita (por ejemplo, si se ha borrado el módulo Create).
En este punto, se tienen dos variables apuntando hacia los módulos Create, de modo que
sencillamente se necesita comprobar los botones de opción en la UserForm para averiguar qué
seleccionó el usuario y hacer las asignaciones a los campos Max Arrivals. Para recuperar el
ajuste de un botón de opción, el código VBA prueba la propiedad Value, lo que se ve en la
figura 10-25. Si se seleccionó el botón nombrado optFromRandomProcess cuando se hizo
clic en OK, su Value es True. En este caso, se desea dejar que el módulo Create para procesos
aleatorios genere entidades (es decir, fije su valor de Max Arrivals en Infinite) y desactive el
otro módulo Create para la creación de entidades desde un archivo. De lo contrario, se desea fi-
jar el módulo Create de llegadas a partir de un proceso aleatorio en un máximo de 0 y el módulo
Create de un archivo en un máximo de 1 (de modo que la entidad de control entra al modelo
para leer tiempos de llegadas del archivo). Para modificar el valor de un campo (también cono-
cido como operando) en un módulo, se usa el método Data en el código VBA.
Si el lector está poniendo mucha atención (como los autores están seguros debe estar hacién-
dolo), puede ser que haya advertido que “Max Arrivals” no aparece en todas partes en este có-
digo. En lugar de ello, el campo en el módulo Create que define el número máximo de llegadas
se llama “Max Batches”. En los módulos de Arena, el texto que aparece en el cuadro de diálogo
del módulo se llama mensaje, y puede corresponder o no al nombre subyacente del operando
en la definición de ese módulo. El método Data de un objeto Module en VBA requiere este
nombre del operando. Para hallarlo, se busca el módulo en un archivo de texto que se instaló
con Arena (es decir, siempre que se localice el archivo de programas de Arena en el disco duro
del usuario). En este caso, el módulo Create viene del panel Basic Process, de modo que se abre
Integración y personalización de Arena 439
Para colocar el archivo en el modelo, regrésese a la ventana del modelo de Arena. Ensegui-
da, ábrase el navegador de archivos (por ejemplo, Explorer o Microsoft® Outlook®), localícese
el archivo de sonido y arrástrese hacia el modelo de Arena, como se ilustra en la figura 10-27.
El objeto de sonido en el modelo de Arena es un archivo intercalado que contiene una copia
que el usuario tuvo originalmente en su disco duro. Este archivo también pudo haberse colo-
cado en el modelo de Arena usando el portapapeles de Windows o través de la opción de menú
Edit > Insert New Object (Editar > Insertar nuevo objeto) de Arena. El propio objeto es sólo
un archivo de sonido almacenado en el disco duro; hágase doble clic sobre él para escuchar su
melodía inspiradora. Para proporcionar el objeto de sonido con una etiqueta única, hágase clic
con el botón derecho sobre su ícono en la ventana del modelo de Arena, selecciónese Properties
del menú e introdúzcase Mission Possible (Misión Posible) como el valor de la Tag.
Por último, regrésese a la ventana de Visual Basic Editor para insertar el código que activará el
archivo de sonido al principio de la ejecución, lo que se muestra en la figura 10-28. Una vez más,
se usa el método Find, en esta ocasión desde dentro de la colección Embeddeds (Intercala-
ciones) del objeto Model, con el fin de buscar el objeto deseado. Si se encuentra el objeto con la
etiqueta Mission Possible, entonces se le activa (en el caso de un archivo de sonido, reprodu-
ciéndolo) usando el método Do (Hacer) del elemento de la colección en el índice apropiado.
Después de que se ha ejecutado la simulación unas cuantas veces, puede ser que se encuentre
que se tiene una necesidad imperatoria de deshabilitar el archivo de sonido. Si es así, siéntase en li-
bertad de desactivar las bocinas de la computadora. O bien, se pueden hacer comentarios fuera de
las líneas ofensivas del código al colocar el enunciado If 0, antes de la primera línea (en donde
se recupera el valor de nSoundFileIndex (nÍndiceDelArchivoDeSonido) y el enunciado
End If (Finalizar si), después de la línea final (el método Do). Posteriormente, si se quiere
10.4 M
odelo 10-6: registro y construcción del gráfico de los resultados
del modelo en Microsoft Excel
Ya se ha visto en la sección 10.1.2 cómo se pueden escribir los datos en una hoja de cálculo
existente e incluso sacar ventaja de gráficas previas. En esta sección, se aprenderá cómo utilizar
VBA en Arena para tener un control más completo, incluyendo la creación de la hoja de cálcu-
lo, el formateo de los datos y la creación del gráfico. Se verá cómo usar VBA para registrar la
información acerca de cada llamada que termina en una hoja de cálculo de Excel. El objetivo
será crear un archivo de Excel en el que se haga la lista de tres partes de datos para cada llama-
da completada: el tiempo de inicio de la llamada, el de finalización y la duración. También se
desea trazar el gráfico de las duraciones de las llamadas para buscar cualesquiera tendencias
interesantes, como grupos de llamadas muy cortas o muy largas. En la figura 10.30 se presenta
una muestra de los resultados del modelo.
Para construir la lógica necesaria para crear la hoja de cálculo y trazar el gráfico de los
resultados, se requerirá realizar tres tareas. En primer lugar, se necesita escribir el código
VBA necesario para crear el archivo de Excel. Se abrirá éste al principio de la ejecución de la
simulación y se escribirán encabezados nuevos en la hoja de cálculo, de modo que se puedan
examinar los resultados para cada día de ocho horas. (Las hojas de cálculo son las páginas
con pestañas dentro de un archivo de Excel.) En segundo lugar, es preciso modificar la lógica
del modelo y escribir el código VBA necesario de modo que cada vez que se complete una
llamada de ventas, su entidad “dispare” un evento VBA para escribir los valores pertinentes
en la hoja de cálculo. Por último, se escribirá el código VBA para crear un gráfico de las
duraciones de las llamadas, al final de cada replicación, y guardar el archivo al final de la
ejecución de la simulación.
En las secciones siguientes, en las que se describen estos pasos, sólo se resaltarán los con-
ceptos y se hará la lista del código correspondiente. Si el lector tiene interés en profundizar más
en su comprensión de estos materiales, consulte la ayuda de Arena relacionada con VBA y el
modelo de sus objetos de Arena, y examine los modelos de la biblioteca SMART relacionados
con estos temas. También se recomiendan cualquiera de las numerosas obras relacionados con
el desarrollo de soluciones en Excel con VBA, con el fin de leer acerca de la automatización
de Excel. Existen además muchos otros recursos a disposición del lector para aprender Visual
Basic, incluyendo diversos libros, tutoriales en CD, cursos de capacitación y sitios web.
Option Explicit
' Global variables
Dim oSIMAN As Arena.SIMAN, nArrivalTimeAttrIndex As Long
Dim nNextRow As Long, nColumnA As Long, nColumnB As Long, nColumnC As Long
' Global Excel variables
Dim oExcelApp As Excel.Application, oWorkbook As Excel.Workbook, _
oWorksheet As Excel.Worksheet
proporciona acceso a los elementos contenidos en el modelo, y SIMAN es un objeto que es parte
del modelo y se le puede usar para pedir o modificar los datos del tiempo de ejecución del aquél
(como estados de los recursos, valores de las variables y atributos de las entidades).
Después de que se ha establecido la variable oSIMAN para apuntar hacia los datos de ejecu-
ción de SIMAN, se le usa para almacenar el valor del índice del atributo Call Start Time
en una de las variables globales — ArrivalTimeAttrIndex— de modo que se pueda usar a
todo lo largo de la ejecución hasta recuperar los valores por separado de los atributos a partir de
las entidades, a medida que salen del modelo. Se usa la función SymbolNumber del modelo de
objetos de Arena para convertir el nombre de algún elemento del modelo, como un atributo en
su índice de tiempo de ejecución de Arena (un entero entre 1 y el número de esos contenidos en el
modelo). Se utiliza esto para el atributo nombrado Call Start Time y almacenar el índice del
atributo en la variable global VBA, de modo que se requiere que Arena realice este cálculo sólo
una vez. El código que se ejecuta en el curso de la ejecución (en el VBA_Block_1_Fire event
[evento VBA_Block_1_Disparar], el cual se cubrirá en breve) pasará este índice hasta la
función apropiada EntityAttribute (AtributoDeEntidad) para recuperar el valor real
del atributo.
Enseguida, se inicia Excel usando la llamada CreateObject de ActiveX Automation y
se hace que sea visible fijando la propiedad Visible de la aplicación en True. Después se
crea un nuevo archivo de Excel (también conocido como libro de trabajo) mediante la automa-
tización de esa aplicación con el método oExcelApp.Workbooks.Add; se puede concebir
esto como “Add (Agregar) un elemento nuevo a la colección Workbooks de la aplicación
oExcelApp”. La variable oWorkbook almacenará un apuntador hacia el libro de trabajo de
Excel que se acaba de crear; también guardará ese libro en un archivo al finalizar la ejecución
de la simulación. Las líneas restantes del código en RunBeginSimulation fijan la variable
oWorksheet para que apunte a la hoja de cálculo del libro de trabajo de Excel que se acaba de
crear y establecen algunas de sus características. Si se está trabajando con Excel, se sugiere que
se examine sus capacidades de grabación de macros. Con frecuencia se puede crear una macro
446 Capítulo 10
en Excel y pegar su código en Arena, con pequeñas modificaciones; esto es mucho más rápido
que tratar de hundirse uno mismo en el objeto de Excel sólo para que la magia del código co-
rrecto realice alguna tarea.
En tanto que el evento RunBeginSimulation sólo se llama una vez, al principio de la
ejecución, Arena llama RunBeginReplication al principio de cada replicación. En la figura
10-34 se da la lista de su código para el modelo 10-6. Se usa este evento para escribir los enca-
bezados de las columnas para los datos del nuevo día. Para determinar las columnas en las que
se escribirán los datos, se emplea el número de la replicación en curso (recuperado de la parte
SIMAN del modelo de objeto de Arena, a través de la variable global oSIMAN que se inicializó
en RunBeginSimulation) se hace el cálculo apropiado con el fin de obtener las tres colum-
nas que se desean. (Consúltese la figura 10-30 para ver cómo se dispusieron las columnas, con
tres columnas de datos y, enseguida, una en blanco para cada replicación, lo cual representa el
acopio de llamadas de un día.)
Las líneas del código entre los enunciados With oWorksheet y End With utilizan el mode-
lo de objeto de Excel para asignar valores a varias celdas en la hoja de cálculo y para formatearlas
para que se ajusten al diseño que se muestra en la figura 10-30. Se dejará al lector que investigue
los detalles de la automatización de Excel, a través de la ayuda de éste. El enunciado final fija la
variable global nNextRow para empezar con un valor de 3; se usará este valor para determinar la
fila en la cual se van a escribir los resultados de la llamada en el transcurso de la ejecución.
Duplicada
Atender la Terminar la
VBA
llamada llamada
este caso, el disparo del código VBA no es tan predecible como los dos primeros eventos que
se examinaron, los cuales se definieron de modo que se llamaran al principio de la ejecución y
al principio de cada replicación. En lugar de ello, la dinámica del modelo de simulación deter-
minará cuándo debe de ejecutarse el código VBA. Arena proporciona un módulo VBA en el
panel Blocks sólo para esta finalidad. Cuando se coloca este módulo, Arena disparará el código
VBA que haya escrito para el módulo VBA, en lugar de incluir alguna lógica predefinida en el
propio módulo. En la figura 10-35 se muestra la lógica modificada para el centro de atención
telefónica, usando un caso del módulo VBA, que se inserta precisamente antes de disponer de
la entidad llamada de ventas.
Cuando se coloca un módulo VBA, Arena le asigna un valor único que se usa para asociar
un módulo VBA particular con su código en el proyecto de Visual Basic; estos números son
enteros que se inician en un valor de 1 y se incrementan en uno con cada nuevo módulo VBA
que se coloque. Con el fin de editar el código para un módulo VBA, se regresa al Visual Basic
Editor y se selecciona el elemento apropiado de la lista de objetos en la ventana del código para
la entrada de proyecto ThisDocument, como se muestra en la figura 10-36.
El evento asociado con el módulo VBA del que se está tratando se nombra VBA_Block_1_
Fire(), en donde 1 corresponde con el número proporcionado por Arena del módulo VBA.
En la figura 10-37 se muestra su código.
Cuando una entidad llamada completa su procesamiento y entra al módulo VBA, se in-
voca el código que se encuentra en el evento VBA_Block_1_Fire. Las dos primeras líneas
del procedimiento recuperan información proveniente de la simulación en ejecución (a través
Figura 10-36. Selección del evento VBA Module 1 en el Visual Basic Editor
448 Capítulo 10
conforme las entidades salen del modelo. Por último, se crearán los gráficos al final de cada
replicación.
Como se podría esperar, la integración de Arena con otras aplicaciones no se limita a la es-
critura de datos en Excel y la creación de gráficos. Si se ha instalado una aplicación que se puede
automatizar, la interfaz VBA de Arena permitirá realizar cualquier cosa que sea posible a través
del modelo de objeto de la aplicación externa, como la creación de un gráfico en una hoja de
cálculo de Excel o la catalogación de datos de ejecución en una base de datos Oracle.
Arena. Esto debe ser suficiente para cumplir con el objetivo de los autores de acrecentar el conoci-
miento del lector acerca de las capacidades de Arena. Para obtener un tratamiento más amplio de
la construcción de sus propios módulos, recomendamos al lector la consulta de la Arena Template
Developer’s Guide a través de Help > Product Manuals (Ayuda > Manuales del Producto).
muestra en la figura 10-39. Los autores creen que el lector pensará: “Bien, para mí, se parece a
cualquier otro módulo”. Y, de hecho, es precisamente como cualquier otro módulo. Cuando el
lector use las herramientas de diseño de plantillas para crear sus propios módulos, el resultado
final es un archivo de objeto panel de plantilla (.tpo), precisamente como los que ha estado
usando: BasicProcess.tpo, AdvancedProcess.tpo, etc. Una parte importante de la
filosofía que se encuentra detrás de Arena es permitir la fácil creación de construcciones persona-
lizadas de modelado que funcionen con las plantillas estándar.
uno o más puntos de entrada o salida, para conectarlos con otros módulos. Con referencia a la
figura 10-39, el módulo Create from File muestra el operando Name (alguna descripción
del módulo que el modelador escribe en su cuadro de diálogo) dentro de un cuadro con un lado
puntiagudo, y tiene un solo punto de salida (que lo conecta al módulo Process).
agregará un operando al módulo llamado File Name (Nombre de archivo) que permite
introducir un nuevo nombre de archivo cada vez que se coloque el módulo. Este nombre de
archivo se agregará al modelo como parte de los datos de File, usando un tipo especial de ope-
rando diseñado para esta finalidad. También se presentará un operando llamado Name, el cual
se presentará en la vista del usuario como parte del diagrama de flujo, y uno llamado Time
Units (Unidades de tiempo), para definir el tipo de información en el archivo de datos.
En la figura 10-42 se muestra el diálogo Create from File con el cual interactuará el usuario.
En la plantilla se diseña ese diálogo y, en la ventana de diseño del diálogo se definen sus operan-
dos, como se muestra en la figura 10-43. La ventana de diseño del diálogo tiene cuatro seccio-
nes. El área central es la ventana de diseño del diálogo, en la cual se presentan las disposiciones
de la forma del diálogo para el módulo y es equivalente a la pantalla de fondo en un procesador
de palabras, en donde se podría escribir. Las otras tres secciones son:
< la Toolbox (Caja de herramientas) (lado izquierdo) para agregar los controles del usuario
a las formas de diálogo,
< el Operand Explorer (Explorador de operandos) (arriba a la derecha) para navegar por
todos los objetos del diálogo en la definición del módulo, y
< las Design Properties (Propiedades de diseño) para editar las propiedades de uno o más
objetos seleccionados.
Cada ventana de diseño de diálogo debe tener por lo menos una forma de diálogo, la cual
se suministra de forma predeterminada. Ésta representa el diálogo que se despliega primero si
el usuario hace doble clic sobre el módulo en una ventana de modelo de Arena. En este punto,
se pueden cambiar el tamaño de una forma de diálogo, sencillamente al seleccionar y arrastrar
sus asas para cambio de tamaño. Nótese que la ventana de diseño del diálogo tiene una parte
superior y una inferior separadas por una barra divisora deslizante. La parte superior es para
elementos que el usuario ve (por ejemplo, diálogos, operandos). La inferior es para los operan-
dos escondidos; un lugar para almacenar datos a los que el usuario no entra de manera directa.
En un momento, se verá un ejemplo al respecto. Una forma de diálogo vacía no es interesante
ni útil, de modo que veamos cómo se le puede poblar para hacerla de utilidad.
La Toolbox proporciona una interfaz para agregar gráficamente controles de interfaces del
usuario (por ejemplo, cuadros de texto, cuadros combinados o botones de diálogo) así como
gráficas estáticas (por ejemplo, texto, líneas o cajas cuadros de grupos) a una forma de diálogo.
Se pueden agregar elementos a la forma de diálogo sencillamente haciendo clic en el elemento
deseado en la Toolbox, arrastrándolo después hasta la ubicación deseada en la forma de diálo-
go. Después de la colocación, se puede reubicar en forma gráfica y cambiarle de tamaño, según
se necesite. Si se tiene que colocar demasiada información en una sola forma de diálogo, enton-
ces uno de los controles será un botón de diálogo que cree una forma asociada de subdiálogo.
Aunque una forma de diálogo que contiene controles y gráficas estáticas es más interesante,
en realidad no se vuelve útil hasta que se definen las propiedades de los controles. Para ello,
hay que pasar a Design Properties, el cual también tiene dos partes. La parte superior es para
navegar por las propiedades y ver/editar los valores para cada una. La zona inferior de esta
ventana proporciona información útil acerca de la propiedad resaltada. Las propiedades que se
presenten cambiarán con base en el control y opciones seleccionados, pero aquí se encontrarán
todos los datos necesarios para definir el comportamiento de cada control.
Se tienen dos maneras de navegar entre los controles. La primera es sencillamente hacer clic
en uno de ellos para seleccionarlo. Éste puede ser el procedimiento más conveniente cuando to-
dos los controles se encuentran en una sola forma de diálogo, más o menos sencilla. Cuando se
tienen formas de diálogo complejas o anidadas se puede hallar más conveniente navegar usan-
do el Operand Explorer. Sólo hay que dar clic en un operando y se hará aparecer su forma de
diálogo (si es necesario), se seleccionará el control en la forma de diálogo y las propiedades de
ese control se presentarán en la Design Properties. Nótese que existe una diferencia significativa
entre el Operand Explorer y la forma de diálogo. En esta última, por lo común los operandos se
identifican por su propiedad Text, lo cual es la manera en la que el usuario reconoce un campo.
En el Operand Explorer los operandos se identifican por su propiedad Name, lo cual es como
se reconocen los controles dentro de la definición del módulo.
Regrésese ahora a la plantilla que se está trabajando. Con referencia a la figura 10-43, se verá la
ventana de diseño del diálogo para la forma de diálogo en cuestión, con el operando Data File
seleccionado. En la figura 10-44 se tiene una visión más cercana de ese operando en el Design
Properties. Se dio el nombre de Data File al operando (al cual se hará referencia en el módulo
de datos File); se aceptó el tipo Basic (Básico) predeterminado; se tomaron en cuenta cualesquiera
caracteres como entrada; se dejó vacío el Default Value (Valor predeterminado); se fijó
la opción In Userview (En VistaDelUsuario) como True, para presentar el nombre del
archivo debajo del asa del módulo en la ventana del modelo, y se marcó la opción Required
(Requerido) como True, de modo que un modelador debe proporcionar un valor no en blanco
al editar el módulo. También se especificó una propiedad Text de &File Name (&Nombre
del archivo), la cual se presenta en la forma de diálogo. El “&” antes de la “F” significa que se
puede llegar a este operando en el diálogo de Arena al oprimir las teclas “Alt-F”.
En la forma de diálogo, también se agregó un TextBox (CuadroDeTexto) nombrado Name,
el cual aparece en la ventana del modelo y que definirá parte del Arena File Name en los módu-
los ReadWrite y File. Se agregó un ComboBox (CuadroCombinado) nombrado Time Units
para proporcionar selecciones de Seconds (Segundos), Minutes (Minutos), Hours (Horas) y
Days (Días) en una lista desplegable; su valor se pasa al módulo Delay en la ventana lógica. Y,
por último, se agregó un HiddenOperand (OperandoEscondido), Destination (Destino),
en la parte inferior de la ventana principal; no se agrega a la forma de diálogo porque no será
directamente visible para el usuario. Éste es un tipo de Exit Point (Punto de salida) al cual se
Integración y personalización de Arena 455
hace referencia en el campo Next Label (Rótulo siguiente) del módulo Assign, en la ventana
lógica, para establecer el flujo de las entidades a través del modelo que contiene un caso del
módulo Create from File. Cuando Arena genera el modelo SIMAN (por ejemplo, cuan-
do se Comprueba [Check] el modelo), empezará con el módulo Create de la ventana lógica (ya
que Create es un módulo especial que inicia el flujo de entidades hacia un modelo); seguirá las
conexiones a través de los módulos ReadWrite, Delay, Separate y Assign; establecerá el circuito
de regreso para que la entidad primaria salga del Separate y regrese al módulo ReadWrite, y,
a través del operando Destination del módulo Assign (porque es del tipo especial de Exit
Point), conectará este último módulo con cualquier cosa a la que se conecte Create from
File, como el módulo Process de la figura 10-39.
Se podría concebir el tipo de operando Exit Point como un “elevador que asciende” en la
jerarquía, que conecta desde la lógica subyacente del módulo Create from File hasta la
lógica principal del modelo, en la cual está incluido. Y, lo que no es sorprendente, existe un tipo
de operando Entry Point (Punto de entrada) que es un “elevador que desciende”, estableciendo
una conexión desde la lógica que se encuentra en el nivel superior de la jerarquía hacia los mó-
dulos que están contenidos en otra ventana de lógica subyacente de módulo.
Los valores que un usuario introduce en el cuadro de diálogo del módulo se hacen descen-
der hacia los módulos de la ventana lógica a través del establecimiento de referencias para los
operandos. Si algún campo de un módulo de la ventana lógica se encierra entre comillas senci-
llas, ambas de apertura (‘), entonces su valor real viene del cuadro de diálogo del módulo; en
particular, el operando cuyo nombre se corresponde con el que se encuentra entre las comillas.
En el caso que nos ocupa, se definirá el Arena File Name en el cuadro de diálogo del módu-
lo ReadWrite y la hoja de cálculo del módulo File como ‘Name‘ArrivalsFile (como se
muestra en la figura 10-45). Por ejemplo, si alguien escribe June26Data (DatosDeJunio26)
como el Name del módulo en el Create del módulo File, entonces el nombre de archivo de Are-
na usado para la ejecución de la simulación (a través de los módulos ReadWrite y File) sería
June26Data.ArrivalsFile. Esta manera de hacer referencia a los operandos también es
el mecanismo usado para determinar aquellas conexiones que deben de salir del módulo Assign
a través del operando Destination; se escribió ‘Destination‘ en el campo Next Label del
módulo Assign de la ventana lógica para establecer este punto de salida del módulo.
456 Capítulo 10
Esto completa la definición que se da en este texto del módulo Create from File, lo que
permite que alguien que lo use en su modelo especifique el nombre del archivo que contenga los
tiempos de llegada y lo conecte a otro módulo. La lógica subyacente también establece algunos
elementos lógicos fijos (es decir, aspectos que no pueden ser cambiados por un modelador). En
particular, cada entidad que es enviada hacia el modelo por este módulo Create from File
tendrá un atributo nombrado Call Start Time que tiene un valor de tiempo de llegada,
porque el módulo ReadWrite todavía hace esa asignación. Cuando se diseña un módulo, se
necesita decidir cuáles aspectos se quiere permitir que cambie un usuario (como en el nombre
de archivo del ejemplo dado) y cuáles se quiere proteger contra modificaciones (por ejemplo, el
nombre del atributo y la asignación).
La mayor parte de los módulos que uno está acostumbrado a emplear contiene numerosos
operandos y, a menudo, incluye lógica compleja. Estos módulos, como los que se encuentran
en los paneles de plantilla de Arena, se crearon usando las capacidades de construcción de
plantillas de este programa. En sus íconos de paneles, vistas del usuario, operandos y lógica
subyacente se utilizan capacidades estándar de diseño de plantillas del software. El examen de
las características de estos módulos puede ayudar al lector a captar el potencial de las plantillas
de Arena. Aun cuando aquí sólo se han tocado la arquitectura y las capacidades del producto
básicas, se cerrará con algunas ideas acerca de cómo las personas por separado y las organiza-
ciones en conjunto podrían emplear las plantillas construidas según sus necesidades.
ra 10-46) y de los aparatos responsables de accionar y monitorear casi todo lo que se mueve en
una instalación automatizada. Se discutirán unas cuantas aplicaciones:
< Lógica del controlador del proceso de prueba de unidades.
< Prueba completa de sistemas de control.
< Diseño de la interfaz del operario.
< Capacitación/certificación del operario.
< Prueba de software de alto nivel.
El término tiempo real, como se estará usando aquí, sencillamente significa concurrente. De
manera más específica, dos o más programas de software se están ejecutando e interactuando
en forma concurrente (o en tiempo real) y, para los fines de lo que sigue, al menos uno de tales
programas es un modelo de simulación en ejecución. Los programas pueden estar ejecutándose
en el mismo procesador o en procesadores diferentes que están conectados de alguna manera
(digamos un cable en serie, una red o palomas mensajeras). Los programas pueden ser muy se-
mejantes (por ejemplo, dos de simulación) o pueden ser bastante diferentes (por ejemplo Arena
comunicándose con un controlador de hardware).
En general, la interacción consiste en información útil que se está enviando en una direc-
ción, por lo común regresándose al emisor por lo menos una respuesta (confirmación de la
recepción). En muchos casos, la interacción tiene información útil que se está intercambiando
en ambas direcciones. La interacción puede estar específicamente programada a propósito para
las aplicaciones, como se podría hacer usando VBA de Arena o interfaz C++ de código del
usuario, o bien, se puede realizar empleando estándares comunes para el intercambio de datos
como OLE for Process Control (OPC, OLE para control de procesos). El uso de procedimientos
de alto nivel como OPC permite que la interacción sea casi invisible para los usuarios.
Los tiempos para la interacción son importantes, dependiendo de la razón para esa inter-
acción. En algunos casos, es aceptable un tiempo de respuesta (por lo general, el tiempo que
transcurre entre el momento que se envía un mensaje y cuando se recibe su confirmación) de
unos cuantos segundos e incluso minutos; en otros casos, se esperan respuestas en unos cuantos
milisegundos. Es obvio que el requisito del tiempo de respuesta puede afectar la selección del
software, hardware y mecanismos de comunicación que se empleen.
Un aspecto final de la simulación en tiempo real es el del reloj registrador de la simulación. En
la mayor parte de los casos, cada programa con interfaz tiene su propio reloj registrador o, por
lo menos, algún concepto de tiempo. En el caso de dos programas de simulación que se ejecutan
en forma concurrente, es importante sincronizar (por lo menos en forma periódica) sus relojes
Integración y personalización de Arena 459
registradores. En algunos casos, un programa podría tener restricciones adicionales. Por ejemplo,
la mayor parte de los controladores de procesos tiene un fuerte concepto del tiempo pero no se
puede ejecutar en tiempo acelerado. Al establecer la interfaz con un controlador de proceso, pue-
de ser necesario sincronizar el reloj registrador de la simulación con uno del sistema global.
Existen muchos usos posibles para la simulación y pronto se examinarán unos cuantos de
ellos. Algunos de tales usos comprenden la emulación, por lo común definida como el proceso
de modelar el desempeño de un dispositivo o programa de computadora. Ya que se ve con cla-
ridad que la emulación es un subconjunto de la simulación y que, con frecuencia, es un poco
confuso cuando algo cambia de simulación a emulación, en las discusiones que siguen se usará
el término simulación, más genérico.
Ahora miremos un poco más hacia cada una de las aplicaciones que se presentaron con
anterioridad.
< Lógica del controlador del proceso de prueba de unidades: Ésta verifica que la lógica e
I/O (Ent/Sal) en el código del controlador se comporte de la manera en que se pretende.
Tradicionalmente, esto se intenta al conectar un controlador a una consola de prueba
física (mostrada en la figura 10-47) que contiene escalas graduadas, interruptores, luces
y otros dispositivos, de modo que los ingenieros puedan montar varias configuraciones y
poner a prueba los resultados. A veces, se escribe un juego de lógica independiente en el
controlador con el único propósito de ejercer el código principal del mismo. Cualquiera
de los dos métodos es difícil, tardado y, a menudo, no confiable. Una simulación puede
representar un conjunto de dispositivos (por ejemplo, interruptores, válvulas, motores)
que constituyen la esencia del piso de la planta. Cuando se establece la interfaz de un
controlador hacia la simulación, se comporta exactamente como si estuviera contro-
lando el sistema real y la simulación reaccionará de manera semejante a tal sistema.
Además, la simulación puede introducir tanto fallas determinísticas como estocásticas,
así como situaciones desacostumbradas, para desafiar al controlador y asegurarse que
puede manejar esas situaciones.
< Prueba completa del sistema de control: Ésta valida que un conjunto de controladores
trabajan juntos para manejar de manera correcta todas las situaciones que es posible
ocurran en el sistema vivo. Aun cuando algunas de las técnicas tradicionales usadas en la
prueba de unidades también se utilizan aquí, son incluso menos efectivas cuando se apli-
can a un sistema completo. Inevitablemente, los programas de control fallan en explicar
alguna secuencia imprevista de eventos o la interacción de componentes, pero la evalua-
ción del desempeño del sistema en una diversidad de escenarios y condiciones es una de
las fortalezas de la simulación. Se pueden usar una o más simulaciones de una manera
semejante a la que se describió en el párrafo anterior para dar certidumbre de que, como
un todo, el sistema funciona y que los aparatos interactúan de manera apropiada.
< Diseño de la interfaz del operario: Cada vez más procesos se están convirtiendo de las
escalas e interruptores tradicionales al control a través de una interfaz gráfica del usuario
(GUI, graphical user interface). Un banco de controles físicos se puede reemplazar por
un solo monitor de pantalla sensible al tacto con elaborado sistema de menús. El diseño
de estos sistemas, para que sean usados con eficacia por un operario, puede ser una tarea
atemorizante, a menudo hecho con simulaciones de los documentos del sistema propues-
to. En la fase final del diseño/primera implementación, se puede utilizar la simulación
para accionar la GUI propuesta e interactuar de manera muy semejante a como se haría
con el sistema real. Los operarios entonces pueden poner en práctica la GUI y hacer la
prueba con tareas comunes y no comunes, buscar errores y hallar mejoras bastante antes
de la entrega del sistema.
< Capacitación/certificación del operario: Con frecuencia, la capacitación inicial del operario
se realiza en el sistema real de producción. Esto sería un tanto parecido a la capacitación
del piloto de un 747 en los controles de un avión real de este tipo. Es obvio que eso no se
realiza en la aviación debido a consideraciones de seguridad y de costo, y no se debe de
hacer en la fabricación por razones similares. Precisamente como en la aviación, se puede
emplear la simulación para representar el sistema real y dejar que los operarios y la gente
de mantenimiento se relacionen con esa simulación como práctica para interacciones se-
mejantes con el sistema real. Asimismo, de modo semejante a la aviación, las personas que
se están entrenando pueden realizar una capacitación acelerada, practicar eventos no ruti-
narios e incluso adquirir certificaciones, todo sin tocar ni afectar el sistema real. Se puede
completar algo de tal capacitación aun antes de que se construya el sistema real.
< Prueba de software de alto nivel: El software de alto nivel (HLS, high-level software)
como el software para sistemas de ejecución de la fabricación, programación y manejo
de lotes es difícil de probar debido a la complejidad y variaciones de las configuraciones
y aplicaciones. La mayor parte de las pruebas se realizan en el sistema vivo. Pero el sis-
tema HLS se puede simular así como evaluar su reacción a la operación rutinaria y no
rutinaria antes del despliegue. También, por medio de la simulación en forma proactiva
de accionadores realistas para el sistema (por ejemplo, salida MRP), se puede probar y
validar la respuesta del HLS en varios escenarios.
La mayor parte de las aplicaciones afectan el tiempo de puesta en servicio de los sistemas
nuevos. El tiempo de puesta en servicio es el periodo que transcurre desde el momento en que
se entrega un sistema nuevo hasta que se está ejecutando a plena capacidad. En el transcurso de
tal periodo, se ha gastado todo el capital para el sistema pero todavía no está produciendo su
capacidad de diseño debido a aspectos como eliminación de errores del mismo y capacitación
del personal. La productividad perdida en el transcurso de este tiempo es un gasto importante
asociado con todo sistema nuevo. Según una investigación realizada en 2006 por al ARC Ad-
visory Group,2 es común gastar el 15% o más del presupuesto de un proyecto en los costos de
arranque, que no incluye el costo significativo de la producción perdida y el tiempo de demora
de salida al mercado. El uso de la simulación en las maneras que se han descrito puede reducir el
esfuerzo asociado con la puesta en servicio y desplazar los tiempos asociados con este esfuerzo
2
ARC Advisory Group es una empresa de investigación y asesoría en las soluciones de la cadena de fabricación y
abastecimiento.
Integración y personalización de Arena 461
La instalación
se vuelve
operativa
Tiempo
más al principio del proceso, cuando los cambios son más fáciles de realizar y menos costosos
para implementarse (lo que se detalla en la figura 10-48).
El lector podría preguntarse de qué características dispone Arena para introducir la im-
plementación en tiempo real. Para empezar, el lector puede utilizar rutinas VBA para estable-
cer una interfaz con otros programas. También puede usar de manera semejante las funciones
C/C++ codificadas por el usuario. Con cualquiera de estos dos procedimientos, puede emplear
cualquier mecanismo de comunicación que elija. Un procedimiento por completo diferente es
ocupar ActiveX para automatizar Arena desde el otro programa. En este caso, el otro programa
estaría controlando Arena, en lugar de trabajar como compañeros.
Arena Real-Time (Arena RT, Tiempo real de Arena) es un producto desarrollado teniendo
presentes las aplicaciones en tiempo real. Arena RT añade varias características útiles al propio
programa. En primer lugar, permite sincronizar el reloj registrador de la simulación con el de la
computadora, de modo que el modelo se puede ejecutar en tiempo real o en cualquier múltiplo
del éste. Ello no sólo resulta útil para las aplicaciones antes mencionadas, sino también para
acelerar (o desacelerar) procesos muy lentos (o muy rápidos) para fines de capacitación y eva-
luación. Como alternativa a la sincronización con el reloj de la computadora, en lugar de ello
se puede usar cualquier cronómetro externo. Esta característica es especialmente eficaz en la
462 Capítulo 10
10.8 Ejercicios
10-1 Partiendo del modelo 10-1, modifique la lógica para almacenar el tiempo entre llega-
das y el tiempo de procesamiento (excluyendo cualquier tiempo de espera) en los atributos.
3
Se puede obtener información adicional acerca de OPC en la página de la OPC Foundation, http://www.pcfoun-
dation.org.
Integración y personalización de Arena 463
Enseguida, utilice el módulo ReadWrite del panel de Advanced Process para escribir este par
de atributos en un archivo de Excel o de Access (o en un archivo de texto, si no tiene instalada
cualquiera de estas dos aplicaciones).
10-2 Empiece con el modelo 10-2 y use el archivo de datos que generó en el ejercicio 10-1
para especificar tanto la lógica de la llegada de llamadas como el tiempo de atención a las mis-
mas. Note que, dado que los datos son tiempo entre llegadas, en lugar de tiempo absoluto entre
llegadas, se requerirá una lógica un poco diferente. ¿Cómo se comparan sus resultados con los
del ejercicio 10-1?
10-3 Construya un modelo sencillo de cola con un solo servidor, con tiempos entre llegadas
de entidades de EXPO(0.25) minutos. Utilizando el módulo ReadWrite, presente un mensaje y
pregunte el tiempo medio de proceso del servidor (dé un valor predeterminado de 0.2 minutos).
Use este valor para establecer una distribución uniforme sobre [a, b], en donde a está 10% por
debajo de la media introducida y b se encuentra 10% por encima de esa media. Ejecute la simu-
lación hasta que hayan salido 300 entidades del modelo.
10-4 Cree el modelo descrito en el ejercicio 10-3, reemplazando los módulos ReadWrite con
una forma VBA que se despliegue al principio de la ejecución de la simulación.
10-5 Usando el modelo de un solo servidor del ejercicio 10-4, agregue una lógica para re-
producir un sonido o presentar un mensaje siempre que el número de entidades en la cola de
servicio sobrepase algún valor de umbral. Deje que el modelador establezca tal umbral en la
forma que se despliega al principio de la ejecución.
10-6 Presente una forma VBA al final de la ejecución de la simulación en la que se informe las
longitudes promedio y máxima de la cola para las colas del producto del modelo 10.1. Si tiene
un programa para construir gráficos (por ejemplo, Excel) instalado en su computadora, trace
también una gráfica de barras de los valores promedio.
10-7 Cree un modelo que escriba 1 000 registros en un archivo. Cada registro incluirá el nú-
mero del mismo y diez muestras aleatorias, cada una entre 0 y 100 000. En Run > Setup >
Reports, desactive la salida normal del modelo al seleccionar SIMAN Summary Report
(Informe resumen SIMAN) como la salida predeterminada y seleccione Disable gene-
ration of report database (Desactivar generación de la base de da-
tos del informe). Desactive Run > Run Control > Batch Run (No Animation) [Ejecutar >
Control de ejecución > Ejecución por lotes (Sin animación)] de modo que se pueda ejecutar tan
rápido como sea posible. Repita este experimento ocupando un archivo de texto, uno binario,
un archivo de Excel, uno de Access, un archivo XML y ningún archivo (sólo genere y descarte
las muestras aleatorias). Compare el tiempo de ejecución y los tamaños de los archivos para
cada ensayo. Si cuenta con una máquina rápida, repita con 10 000 y 100 000 registros.
CAPÍTULO 11
y se presentará un modelo de una operación de carga de carbón mineral para ilustrar cómo
funciona esto en Arena. Los sistemas continuos más complejos, donde la tasa de cambio puede
depender de otros aspectos del proceso, se analizarán en la sección 11.3 y se explorarán median-
te un modelo de horno de termodifusión.
Para dar crédito donde es debido, mucha de la descripción de los conceptos del modelado
continuo y discreto y continuo combinado de la sección 11.3, incluso el ejemplo del horno de
termodifusión, se basa en materiales de Pegden, Shannon y Sadowski (1995). Algunos de los
ejercicios de este capítulo provienen también de dicha fuente.
Después que haya digerido el material de este capítulo, el lector deberá entender cómo los
modelos de simulación de procesos continuos difieren de los de modelos discretos. Y, una vez
que haya completado de manera exitosa el trabajo con este material, se espera que se encuentre
dispuesto a poner en práctica estos poderosos métodos de modelado.
1
Para gráficas como ésta que muestra valores, se habilita la opción no escalonada (Non-Stepped) para mostrar
cambios como una línea continua y no como pasos discretos.
Modelos continuos y discretos/continuos combinados 467
Levels
(Niveles)
Number (Número) 1
Name (Nombre) Tank Volume (Volumen del tanque)
La pantalla 11-1 muestra las entradas para definir la variable de nivel, volumen del tanque
(Tank Volume), en el módulo Levels (Niveles) del panel Elements (Elementos). Se hará co-
rresponder cada nivel del modelo con su tasa variable correspondiente asignándoles números
únicos (1, en este caso). Arena hará corresponder una tasa y un nivel mediante estos números
para saber qué valor de tasa se debe aplicar, a fin de cambiar el valor de una variable de nivel
durante la ejecución. Estos números deben ser asignados para que haya una correspondencia
uno a uno entre niveles y tasas.
La Tasa de entrada del tanque (Tank Input Rate) se define en el módulo Rates
(Tasas) del panel Elements (Elementos), mostrado en la pantalla 11-2. Se le da el número 1 para
hacerla corresponder con el nivel Volumen de tanque (Tank Volume) y se le asigna un valor ini-
cial de 10, de modo que la tasa de cambio del volumen de tanque sea 10 unidades de volumen
por unidad de tiempo base (que se establecerá como minutos en el cuadro de diálogo Run >
Setup > Replication Parameters [Ejecutar > Fijar > Parámetros de réplica]).
Como puede ver el lector en la gráfica de la figura 11-1, el valor del volumen del tanque (un
nivel continuo) cambia sin problemas con el tiempo. Y, en ausencia de alguna lógica de evento
discreto para cambiar el valor del nivel o la tasa, el volumen del tanque continuaría subiendo a
esta tasa constante, 10 unidades de volumen por unidad de tiempo, hasta el final de la ejecución
de simulación.
Cuando un modelo contiene un componente continuo, Arena debe aumentar el avance de
tiempo discreto que es impulsado por el calendario de eventos con lógica para seguir el cambio
en las variables continuas con el tiempo. Si bien Arena no puede avanzar en realidad el tiempo
de manera continua, puede aproximar un cambio continuo en los valores de nivel realizando
una serie de pequeños pasos entre los eventos discretos usuales. En cada uno de estos tiempos
de actualización continua, Arena calcula nuevos valores para las variables de nivel con base en
sus tasas de cambio. Para esto, Arena integra los valores de tasa a fin de determinar los nuevos
valores correspondientes de los niveles.
468 Capítulo 11
Tasas
Number (Número) 1
Name (Nombre) Tank Input Rate (Tasa de entrada del tanque)
Initial Values (Valores iniciales) 10
Pantalla 11-2. Módulo Tasas que define la tasa de entrada del tanque
El módulo Continuous del panel Elements establece ajustes que son necesarios para confi-
gurar los cálculos continuos de Arena. En la pantalla 11-3 se muestra el módulo Continuous
para el modelo 11-1. En el caso de modelos simples de tasa constante, sólo son pertinentes algu-
nos de estos campos. El número de ecuaciones diferenciales (Number of Dif. Equations) define
cuántas ecuaciones diferenciales se evaluarán para este modelo. En sistemas de tasa constante,
cada par nivel/tasa debe ser contado entre las ecuaciones diferenciales, así que Arena calculará
nuevos valores mediante las actualizaciones de tiempo continuas. Para el modelo 11-1, se deja
este campo en su valor por omisión (en blanco), que fijara el número de tales ecuaciones igual al
número de pares nivel/tasa definidos por los módulos Levels y Rates (Niveles y Tasas) (en nues-
tro caso, uno). No se tiene ninguna ecuación de estado (de las cuales se hablará en la sección
11-3), así que ese campo se deja en el valor predeterminado. Los campos Minimum Step Size
(Tamaño de paso mínimo) y Maximum Step Size (Tamaño de paso máximo) dictan a Arena
la frecuencia de actualización de los cálculos continuos. Para este modelo, se dejarán en sus
valores predeterminados de 1.0 minuto. (Note que las unidades son de la selección de Unidades
de tiempo base [Base Time Units] en el cuadro de diálogo Run > Setup [Ejecutar > Fijar].) El
lector puede ver el efecto del tamaño de paso en el tiempo requerido para ejecutar la simula-
ción al cambiar ambos a algo más pequeño (por ejemplo, 0.001); a Arena le toma mucho más
tiempo llevar a cabo la misma ejecución, porque calcula con más frecuencia las actualizaciones
de variable continua. Se acepta también el valor por omisión para el Save Point Interval (Inter-
valo de Guardar punto), que se relaciona con los cálculos de estadísticas continuas; aún no los
estamos usando. En el campo Method (Método), se deja el valor predeterminado, Euler, que
es el algoritmo de integración apropiado que se usará cuando las tasas permanecen constantes
entre actualizaciones de tiempo continuo, como en nuestro modelo. Y, por último, se pedirá a
Arena que genere un mensaje de advertencia si viola alguna tolerancia límite de cruce; se verá
más acerca de esto en el modelo 11-2, como se describe en la sección 11.1.2.
Modelos continuos y discretos/continuos combinados 469
Continuo
2
Si el lector construye y ejecuta este modelo, verá que la gráfica termina a un paso deslumbrante. Para ver la cons-
trucción de la gráfica con más lentitud, abra el cuadro de diálogo Run > Setup > Speed (Ejecutar > Configuración >
Velocidad) y seleccione la opción Actualizar el tiempo de simulación cada 0.1 unidad de tiempo.
470 Capítulo 11
Si se tiene interés en otros eventos que pudieran afectar el nivel o el flujo, se puede modelar
el proceso “observando” el nivel del tanque en lugar de los retardos de tiempo fijo. Para este
método, se usará el módulo Detect (Detectar) del panel Blocks (Bloques). El módulo Detect
provee un punto en el que se crea una entidad en la porción de evento discreto del modelo, aná-
logo a un módulo Create (Crear). El tiempo de las creaciones de entidad se dicta observando
el valor de una variable de nivel continuo para cruzar un valor límite, en contraste con la serie
predefinida del módulo Create de llegadas con base en el tiempo. Siempre que se cruza el límite
especificado, Arena crea una entidad, que procede del módulo Detect hacia la lógica de diagra-
ma de flujo con la que el lector se encuentra íntimamente familiarizado.
En el modelo de líquido limpiador para alfombras, se desea hacer algo siempre que el tanque
se llene (es decir, que el Volumen del tanque [Tank Volume] llegue a 100 en la dirección
positiva) y siempre que se vacíe (o sea, llegue a cero disminuyendo). La lógica de modelo de la
figura 11-3 genera esta secuencia de eventos durante la ejecución y, no fortuitamente, produce la
Disponer la entidad
Asignar la
Detectar de detección de
tasa a 10
tanque vacío
Volumen del tanque
Figura 11-3. Lógica de llenado y vaciado por medio de módulos Detect (Detectar)
Modelos continuos y discretos/continuos combinados 471
Detectar
misma gráfica del Volumen del tanque (Tank Volume) como en la figura 11-2. (Se llama Model
11-02b.doe.)
El módulo Detect (Detectar) en la parte superior de la figura 11-3 se encarga de vigilar que
el nivel continuo del Volumen del tanque (Tank Volume) pase un valor de 100 en la
dirección positiva, como se aprecia en la pantalla 11-4.
Durante la ejecución de la simulación, siempre que Arena detecte este evento, se crea una
entidad y se despacha del módulo Detect al módulo Assign (Asignar), donde comienza el vacia-
do del tanque fijando el valor de la Tasa de entrada del tanque (Tank Input Rate)
en −10, como se muestra en la pantalla 11-5. Después, se elimina la entidad.
El segundo conjunto de lógica comienza con un módulo Detect que se encarga de vigilar
que el Volumen del tanque (Tank Volume) pase de 0 en la dirección negativa. Sus enti-
dades se crean siempre que se vacíe el tanque. Después, asignan a la Tasa de entrada del tanque
(Tank Input Rate) un valor de 10 para comenzar de nuevo el llenado del tanque y, por último,
se eliminan. En la ejecución de la simulación, Arena creará entidades en los módulos Detect
siempre que el tanque se llene o vacíe, lo cual produce un patrón repetido de llenado y vaciado
aproximadamente cada 10 minutos.
Volviendo al módulo Detect de la pantalla 11-4, hubo un campo adicional, la Tolerancia de
cruce (Crossing Tolerance), que se definió como 0.0. Esta cantidad define un intervalo de error
aceptable para la determinación de Arena del valor de cruce. Ya se mencionó que Arena no
puede hacer avanzar en realidad el tiempo en forma continua; en vez de eso, corta el tiempo en
pequeños pasos, cuyo tamaño se define en el módulo Continuous. Debido a que los cálculos de
valor continuo se llevan a cabo sólo en estos pasos de tiempo, existe la posibilidad de que Arena
pierda el tiempo exacto en el que un valor cruza un límite definido en un módulo Detectar.
472 Capítulo 11
Asignar
1
Pantalla 11-5. Módulo Assign (Asignar) que cambia la tasa de entrada del tanque
Puesto que se está usando el método de integración de Euler, Arena puede calcular den-
tro de la exactitud numérica de redondeo el tiempo exacto del evento que es detectado. Así,
en teoría, no hay razón para error, y el lector no debe aceptar ninguno. Observe que se dice
dentro de la exactitud del redondeo numérico. Cuando se especifica un Tamaño de paso mí-
nimo (Minimum Step Size) de 0.0 o una Tolerancia de cruce (Crossing Tolerance) de 0.0,
Arena usa en realidad un número muy pequeño internamente. Aunque tras bambalinas, se
ha rebasado un límite muy pequeño, desde nuestra perspectiva, esto capta la mayor parte de
los eventos exactos. Por tal razón, éstos son en general los mejores ajustes a emplear con el
método de integración de Euler.
En algunos casos, en particular con RKF u otros métodos de integración, el lector necesita
introducir estos parámetros con cuidado. Considere un módulo Detect que vigila que el valor
de un nivel cruce un límite de 100 en la dirección positiva con una tolerancia de 0.1. En la figura
11-4 se ilustra un caso donde el nivel cambió de un valor de 99.7, el cual es menor que el límite
de 100, en una actualización de tiempo continuo (tiempo 3.31) a un valor de 100.6, que excede
el límite mayor de tolerancia, en el siguiente tiempo de actualización (tiempo 3.32).
En tal caso, donde Arena no pudo llevar a cabo los cálculos continuos requeridos a la exacti-
tud que usted especifica, puede definir cómo desea que se comporte el modelo mediante el cam-
po Cross Severity (Severidad de cruce) en el módulo Continuous. La opción predeterminada es
Warning, en cuyo caso Arena mostrará un mensaje de advertencia que le indica que un módulo
Detect excedió la tolerancia de cruce, pero le permitirá continuar con la ejecución. El lector pue-
de elegir Fatal (que por fortuna describe cómo se debe tratar la ejecución de Arena, ¡no al mode-
lador!) para indicar a Arena que genere un mensaje de error y termine la ejecución si se pasa un
límite de cruce. O bien, si desea ignorar estos tipos de errores, elija No, y Arena continuará con
la ejecución del modelo como si usted tuviera una tolerancia muy grande para el error.
Modelos continuos y discretos/continuos combinados 473
Valor
Tamaño de
paso = 0.01
Tiempo
3.31 3.32
Esta descripción puede ayudarnos a determinar qué valores establecer para los dos ajus-
tes primarios de sistema continuo; el tamaño de paso en el módulo Continuous (Continuo)
y el (los) límite(s) de cruce en el (los) módulo(s) Detect (Detectar). Para decidir acerca de
un valor para el tamaño de paso, se tendrá que comprometer la exactitud del modelo con la
velocidad de la ejecución. A medida que el lector disminuye el tamaño de paso, generará, por
lo común, resultados más exactos porque Arena estará recalculando con más frecuencia las
variables de cambio continuas. Sin embargo, la ejecución de la simulación tomará más tiempo
a medida que usted disminuye el tamaño de paso debido a que los cálculos se realizan con
más frecuencia.
Después que ha seleccionado un valor para el tamaño de paso, puede calcular la toleran-
cia que necesitará para proveer a Arena sus módulos Detect. Con respecto a la figura 11-4, se
puede identificar una relación útil entre el tamaño de paso de tiempo continuo (la distancia a
lo largo del eje del tiempo entre cálculos), la tasa de cambio del valor de nivel (la pendiente de
la recta) y el valor de tolerancia (la distancia entre valores del nivel). Si se toma la tasa absoluta
máxima que será encontrada durante la ejecución (suponiendo que se conoce esta cantidad)
y se multiplica por el tiempo máximo-tamaño de paso, el resultado es el cambio máximo que
puede ocurrir en el valor del nivel en cualquier tiempo-paso simple.
Por ejemplo, si la tasa máxima de cambio es 100 unidades de volumen por hora y el tamaño
de paso es 0.01 horas, entonces el nivel no puede cambiar por más de una unidad de volumen
entre los cálculos de Arena de las variables continuas. Así que si se ha establecido el tamaño de
paso en 0.01, entonces se puede introducir un valor de 1 en los módulos Detect que vigilan ese
nivel y evitar perder algún cruce.
Muelles
RÍO LENTO
Almace-
namiento
principal
de carbón
Rampas de carbón
Remolcador
y barcazas
(por ejemplo, atributos, variables, estadísticas). Y antes, en este capítulo, se hizo una descrip-
ción de los procesos continuos como aquellos que cambian el estado del sistema continuamente
con el tiempo. Si se usan estos últimos como base para analizar la operación de carga de car-
bón, se pueden clasificar sus actividades como sigue:
< Llegada del remolcador: Evento discreto que inicia la lógica para modelar la demanda de
carga.
< Preparación para la carga de carbón: Evento discreto para un remolcador que entra a un
muelle.
< Comienzo de la carga: Evento discreto que comienza la carga de las barcazas del remol-
cador y cambia la distribución del carbón entre los muelles.
476 Capítulo 11
< Carga de carbón: Proceso continuo durante el cual el carbón fluye del área de almacenaje
a una o más barcazas atracadas. Note que la tasa de carbón que es entregado a un muelle
particular puede cambiar debido a la ocurrencia de otros eventos discretos (comienzo de
la carga, barcazas llenas).
< Barcazas llenas: Evento discreto que ocurre cuando las barcazas de un remolcador han
sido llenadas. El tiempo de este evento para cada entidad individual obedece a su evento
de comienzo de carga y la duración de la operación continua de carga de carbón, así
como los eventos intermedios causados por la llegada o partida de otros remolcadores.
< Partida del remolcador: Evento discreto que termina el procesamiento del remolcador en
el modelo de simulación.
Ya sabemos cómo modelar eventos discretos (y el lector también, si ha puesto atención a los
capítulos anteriores) por medio de conceptos familiares como entidades, recursos, colas, varia-
bles, etc. Y de hecho, se tiene la sensación de que se podría modelar todo con lo ya aprendido.
La lógica podría parecer algo como:
< Crear el remolcador que llega.
< Hacer cola para tomar un muelle.
< Asignar requisito de capacidad para remolcador (toneladas).
< Demora para atracar y preparar la carga de carbón.
< Demora para llenar las barcazas.
< Demora para desatar y abandonar el muelle.
< Liberar el muelle.
< Demora de entidad del remolcador.
Así que, ¿por qué se encuentra este modelo aquí en el capítulo de modelos continuos cuando
al parecer se puede hacer todo con los conceptos y módulos ya cubiertos? Considérese con ma-
yor detenimiento la secuencia de retrasos requerida para modelar las operaciones de llenado,
con el fin de ver si surge algo interesante para hacer que este problema ajuste aquí.
El primer paso para cargar las barcazas de un remolcador fue descrito como requerir un
equipo de trabajo (que se ha supuesto convenientemente como una restricción para este mo-
delo) y tomar TRIA(2, 5, 10) minutos. Al parecer, un módulo Delay (Retraso) debe funcionar
bien; retener la entidad del remolcador en el modelo hasta que transcurra la cantidad adecuada
de tiempo simulado (algo entre 2 y 10 minutos).
A continuación, se llenan con carbón mineral las barcazas del remolcador. Se conocen los
requisitos de capacidad en toneladas (tabla 11-1), y se nos dijo que el carbón viene del área de
almacenaje a una tasa de 2 400 toneladas por hora. Eso debe ser fácil también, sólo dividir la
capacidad (toneladas) entre la tasa (toneladas/hora) y se tendrá el tiempo de carga en horas,
lo cual se podría introducir en un módulo Delay. Por ejemplo, si un remolcador requiere 600
toneladas, completar la carga requiere 600/2 400 o 0.25 horas (15 minutos).
Por último, se anticipó que el remolcador se desata y se va, lo cual toma TRIA(3, 4.5, 7.5)
minutos. Éste es claramente otro módulo Delay antes que la entidad del remolcador libere el
recurso Muelle y salga del sistema.
Pero espere, hubo otro giro en la historia. Se dijo que si bien la tasa de carbón que sale del
área de almacenaje está fijada en 2 400 toneladas/hora, se divide después de modo uniforme
siempre que los muelles se encuentren ocupados por las barcazas que están siendo cargadas.
Esto complica el segundo cálculo de retraso. Cuando un remolcador ha terminado su primer
Modelos continuos y discretos/continuos combinados 477
retraso y se halla listo para cargar, no se puede estar seguro de cuánto tomará la operación de
carga. Si es el único remolcador en los muelles, entonces empezará con una tasa de carga de
2 400 toneladas por hora. Pero, si llegan otros remolcadores mientras aquél está siendo carga-
do, disminuirá la tasa entrante: primero a 1 200 toneladas/hora (2 400 dividido entre dos), luego
a 800 toneladas/hora (cuando tres están siendo cargados) y posiblemente a 600 toneladas/hora
si los cuatro muelles se encuentran ocupados antes que se llene el primer remolcador.
Cada una de estas ocurrencias es un evento discreto (el comienzo del evento de carga en la
lista previa), así que se podría tratar de captar la lógica necesaria para ajustar los tiempos de
retraso para los remolcadores en los muelles cuando llegan otros nuevos. Sin embargo, esto po-
dría volverse un poco complicado, y requeriría algún uso creativo de las capacidades avanzadas
de evento discreto de Arena. (Pruebe con un bonito problema.)
En cambio, se puede captar el flujo de carbón que se divide en múltiples corrientes y llenar
las barcazas con las características de modelado continuo de Arena. Aún se tendrán todas las
partes de evento discreto del modelo, pero cuando se llegue al espinoso asunto de cuánto per-
manece el remolcador en el muelle para la operación de carga real, se interconectará el modelo
discreto con los cálculos continuos efectuados por Arena.
Number (Número) 1
Name (Nombre) Barge Level (Nivel de barcaza)
1-D Array Index (Índice de arreglo 1-D) 4
Number (Número) 1
Name (Nombre) Barge Rate (Tasa de barcaza)
1-D Array Index (Índice de arreglo 1-D) 4
todo de integración de Euler, se establece el Tamaño de paso mínimo en 0.0, y cuando se llegue
a la Tolerancia de cruce, se dejará también en 0.0. Se fijará el Tamaño de paso máximo en 100
(cualquier número grande servirá) y se dejarán los campos restantes en sus valores predetermina-
dos para que Arena lleve a cabo los cálculos de actualización continua para todas las variables de
nivel y se generará una advertencia si se viola alguno de límites de detección de cruce.
Las primeras pocas actividades en el modelo llevarán a los remolcadores y sus barcazas a un
muelle y comenzará el llenado de las barcazas, según se ilustra en la figura 11-6.
El módulo Create genera entidades de tipo entidad Empty Barge (Barcaza vacía) de acuer-
do con un programa de llegadas llamado Barge Traffic Schedule (Programa de trán-
sito de barcazas), en la pantalla 11-9. La entidad creada representará un remolcador y
sus barcazas, que son vistas como un solo punto de demanda de carga. Se agrega un módulo
Schedule (Programa) para definir el patrón de llegada descrito en la tabla 11-2.
La entidad barcaza siguiente entra en un módulo Process (Proceso), pantalla 11-10, donde
intenta tomar uno de los muelles. Los muelles serán modelados como recursos individuales
(Muelle 1, Muelle 2, Muelle 3, Muelle 4), formados en un conjunto llamado Mue-
lles. En este proceso, se usa la acción Retraso para tomar lugar (Seize Delay) para que
el remolcador tome un muelle, pero aún no lo deja. Necesita permanecer en el recurso muelle
hasta que han sido llenadas sus barcazas y ha abandonado el muelle. Se almacena también el
índice del muelle individual asignado para la barcaza que llega a un atributo llamado Número
de muelle (Dock Number). Después de tomar un muelle, el remolcador se retrasa en el
módulo Process (Proceso) para la operación de sujeción, que toma TRIA(2, 5, 10) minutos.
Después que la entidad remolcador ha tomado un muelle y ha transcurrido su tiempo de
sujeción, entra a un módulo Assign (Asignar) para iniciar el flujo de carbón hacia las barca-
zas. Recuerde que la tasa real de carbón que entra a una barcaza en un muelle dependerá de
cuántos otros muelles están cargando actualmente carbón. Siempre que cambie el número de
muelles activos (es decir, con barcazas que están siendo cargadas), se necesita ajustar las 2 400
toneladas/hora de carbón que salen del área de almacenaje a fin de mantener una distribución
uniforme entre esos muelles. Se usará una variable global, Filling Docks (Muelles de
llenado), para rastrear el número de muelles que están cargando. Entonces, siempre que una
nueva barcaza comience a cargar o alcance su capacidad, se ajustarán las tasas de carga en los
muelles activos como 2 400/Muelles de llenado (2 400/Filling Docks) para man-
tener la distribución uniforme de carbón.
En el módulo Assign, pantalla 11-11, el remolcador incrementa primero en uno el número
de muelles que están siendo llenados actualmente (Filling Docks). Después, fija la tasa del
flujo de carbón que llega a su muelle asignando un nuevo valor a la tasa variable en su muelle,
Barge Rate (Dock Number) [Tasa de barcaza (Número de muelle)]. Y, para que se puedan
reunir después las estadísticas de tiempos de llenado, se asignará el tiempo de simulación actual
a una variable global, Begining Fill Time (Dock Number) [Tiempo de llenado inicial
(Número de muelle)]. Después en el modelo, cuando parte una barcaza llena, se registrará el
tiempo que pasó la barcaza en el muelle. Por último, el remolcador determina su tamaño to-
mando una muestra de una distribución de probabilidad discreta con los valores proporciona-
dos en la tabla 11-1. Esta cantidad se asigna a una variable, Barge Capacity (Dock Num-
ber) [Capacidad de la barcaza (Número de muelle)], que se usará como el valor límite para
un módulo Detect que se encarga de los remolcadores llenos en cada muelle. Se abrió también el
módulo Variable en el panel Basic Process y se definieron las variables Begining Fill Time
(Tiempo de llenado inicial) y Barge Capacity (Capacidad de barcaza),
cada una con cuatro renglones.
Después de comenzar el flujo apropiado de carbón hacia el muelle al que entró el remolca-
dor, se necesita ajustar a continuación el flujo hacia cualquier otro muelle en el que actualmente
480 Capítulo 11
están cargando las barcazas. Por ejemplo, si hubiera dos muelles ocupados cargando barcazas
al momento de una nueva llegada, cada uno de ellos habría estado recibiendo un flujo de 1 200
toneladas/hora. Cuando llega el nuevo remolcador y comienza a ser llenado, el flujo a cada
uno de los tres muelles ocupados necesita ser cambiado a 800 toneladas/hora (el total de 2 400
toneladas/hora dividido igualmente entre los tres muelles).
Para ajustar las tasas, se usará un módulo Asignar que cambia la tasa de llenado de las bar-
cazas en los muelles que actualmente se están llenando (es decir, tiene una Tasa de barcaza
(Barge Rate) mayor que 0) para ser nuestra nueva tasa para todos los muelles de llenado,
2400/Muelles de llenado (2 400/Filling Docks).
El módulo Assign, Cambiar la tasa de llenado a la llegada de una barcaza (Change Fil-
ling Rate On Barge Arrival), usa una expresión para asignar un nuevo valor a cada
una de las cuatro variables Tasa de barcaza (Barge Rate), que se muestra en la pantalla 11-
12. Estas expresiones multiplican dos cantidades juntas para asignar una nueva Tasa de barcaza
(Barge Rate). Si una barcaza particular (por ejemplo, la barcaza en el muelle 1) está siendo
llenada actualmente, su Tasa de barcaza (Barge Rate) será positiva (es decir, Barge Rate
(1) > 0 evaluará a 1). Esto dará como resultado su Tasa de barcaza (Barge Rate) a la
que se le asigna un valor de 1 * (2 400/Filling Docks), ajustando su tasa con base en
el nuevo número de muelles que están siendo llenados. Por otro lado, si un muelle no tiene una
barcaza que esté siendo llenada, entonces su Tasa de barcaza (Barge Rate) será 0, y la ex-
presión Barge Rate (1) > 0 evaluará a 0. Esto da como resultado una asignación de 0 *
(2 400/Filling Docks), que mantiene la Tasa de barcaza (Barge Rate) en 0.
Modelos continuos y discretos/continuos combinados 481
Después de hacer estas asignaciones, se puede eliminar la entidad remolcador, puesto que ha
sido asignada toda la información requerida a las variables. La lógica que se describirá tendrá
en cuenta el resto de las actividades del remolcador.
En este punto en la lógica, el remolcador que llega ha completado su atracamiento (es decir,
tomó un muelle y esperó un tiempo) y ha ajustado la variables de nivel continuo para represen-
tar la distribución apropiada del flujo de carga de carbón hacia los muelles. Ahora, el remol-
cador simplemente necesita esperar hasta que sus barcazas estén llenas y efectuar después las
actividades de partida (quitar amarras y dejar el muelle).
Para determinar cuándo están llenas las barcazas, se usará un módulo Detect, observando
que los valores continuos de Barge Level (Nivel de barcaza) en cada muelle excedan sus va-
lores correspondientes de Barge Capacity (Capacidad de barcaza). Esto creará una entidad
cuando esté llena una barcaza, sustituyendo esencialmente la entidad barcaza entrante que se
eliminó antes. En la figura 11-7 se ilustra la lógica para iniciar estas entidades de barcaza llena en
el modelo.
El módulo Detect, pantalla 11-13, considera las cuatro variables de nivel continuo definien-
do un intervalo de estación de 1 a 4. Para un módulo Detect con un intervalo de estación, Arena
vigila los valores de las Crossing Variables (Variables de cruce) (en este caso, las cuatro variables
indexadas Barge Level [Nivel de barcaza]) en la ejecución de la simulación. Como sucede
con el módulo Search (Buscar), la variable de índice de Arena, J, se usa para indicar lugares en
el módulo donde se deben usar los valores del intervalo. En este módulo Detect, se desea que
Arena vigile las cuatro variables de Barge Level (Nivel de barcaza) contra los cuatro valo-
res de Barge Capacity (Capacidad de barcaza). Siempre que uno de los niveles de barcaza
pase su valor límite (el valor de la variable Barge Capacity [Capacidad de barcaza] con un
índice correspondiente) en la dirección de cruce (positiva), se crea una entidad y abandona el
482 Capítulo 11
Falso
Estaciones
Muelle de barcaza 1
Muelle de barcaza 2
Muelle de barcaza 3
Muelle de barcaza 4
módulo Detect. Arena asigna también el índice que fue detectado (por ejemplo, 2 si el Nivel
de barcaza (2) pasó la Capacidad de barcaza (2) en la dirección positiva) al atri-
buto especial, Entity.Station, de la entidad recién creada. Este atributo es uno de aquellos que
Arena proporciona en forma automática para cada entidad (véase la sección 7.1.1). Se utiliza
en el modelado continuo con el módulo Detect para permitir la conveniencia de observar varias
variables de nivel con un solo módulo, como en el ejemplo. Puesto que aún se está usando el
método de integración de Euler, se empleará una tolerancia de cruce de 0.
Se agrega también un módulo Stations (Estaciones) del panel Elements para definir cuatro
estaciones. Aunque no se usan directamente en el modelo para transferencias de estación, se
requieren para permitir que el módulo Detect busque en el intervalo de estación.
Cuando se crea una entidad mediante dicho módulo Detect, ésta entra al módulo Assign
mostrado en la pantalla 11-4. Aquí se asigna el tipo de entidad a Barcaza completa (Full
Barge), que se usará después en el modelo para que se puedan enviar las barcazas entrantes y
estas barcazas llenas a la lógica de eliminación apropiada. Después se emplea el atributo En-
tity.Station, que fue inicializado por Arena en el módulo Detect, para asignar al atributo
Dock Number (Número de muelle) un valor del 1 al 4 para indexar en nuestras variables
ordenadas. La siguiente asignación termina el flujo de carbón a este muelle, y fija la tasa de
flujo, Barge Rate (Dock Number), en 0. Después, se restablece la variable Barge Level
(Nivel de barcaza) para este muelle a 0. Se fija también la variable Barge Capacity (Dock
Number) en 0. Por último, se disminuye en uno el número de Muelles de llenado (Filling
Docks), de modo que en los cálculos de ajuste no se incluya este muelle.
En este punto en el modelo, se tiene una entidad que el módulo Detect creó debido a que la
operación de llenado terminó en uno de los muelles. En el módulo Assign, se detuvo el flujo de
carbón hacia ese muelle. Ahora, se necesita ajustar el flujo hacia los otros muelles, si en alguno
se están llenando barcazas, para distribuir las 2 400 toneladas por hora de manera uniforme
entre ellas. Primero, se usará el módulo Decide (Decidir), mostrado en la pantalla 11-15, para
comprobar si en alguno de los muelles se está llenando una barcaza.
Name (Nombre) Any Barges Still Filling? (¿Está siendo llenada aún alguna
barcaza?)
Type (Tipo) 2-way by Condition (2 vías por condición)
If (Si) Expression (Expresión)
Value (Valor) Filling Docks > 0 (Muelles de llenado > 0)
Cambiar la tasa
de llenado a
Verdadero la salida de la
barcaza
Si hay algunos muelles ocupados por barcazas que están siendo llenadas, entonces se nece-
sita ajustar sus tasas de llenado. Se conectará el punto de salida Verdadero del módulo Decide
a una copia del módulo llamada Change Filling Rate on Barge Arrival [Cambiar
la tasa de llenado a la llegada de la barcaza] (nómbrela Change Filling Rate on Bar-
ge Departure [Cambiar la tasa de llenado a la salida de la barcaza], sin modificar los otros
operandos). Si no hay muelles ocupados con llenado en proceso, entonces la entidad saldrá vía
el punto de salida Falso del módulo Decide. Se conectará esto con la lógica mostrada en la fi-
gura 11-8, que se encarga de eliminar la entidad barcaza llena. (La conexión del punto de salida
Falso del módulo Decide es la línea del fondo de la figura.)
Para eliminar del modelo una barcaza llena, se necesita reunir estadísticas acerca de cuánto
toma llenar la barcaza, el tiempo que toma desatar las barcazas y salir del muelle y eliminar la
entidad.
Los tres módulos que eliminan del sistema una barcaza llena inician con el módulo Record
(Registro), Record Barge Fill Time (Registrar el tiempo de llenado de la barcaza),
mostrado en la pantalla 11-16. Esto se usa para contar cuánto toma llevar a cabo la operación
de llenado, sin incluir el tiempo requerido para atar el remolcador o desatarlo. Recuerde que
cuando una barcaza vacía, entrante, comienza su operación de llenado (figura 11-6), se asigna
el tiempo de inicio de la operación de llenado a una variable llamada Begining Fill Time
(Tiempo de llenado inicial) con el índice apropiado de Dock Number (Número de muelle)
(pantalla 11-11). Para determinar cuánto tiempo toma llenar las barcazas de un remolcador, se
resta el tiempo de inicio del tiempo de partida del remolcador, que es el tiempo de simulación
actual (TNOW) cuando la entidad llega al módulo Record. Se nombrará la estadística de cuenta
Barge Fill Time (Tiempo de llenado de la barcaza) para que podamos ver sus resultados
en el área especificada por el usuario de los informes de Arena.
Pantalla 11-17. Módulo Process (Proceso) para desatar el remolcador y liberar el muelle
A continuación, la entidad que representa la barcaza llena retrasa el tiempo requerido para
desatarla y libera el muelle. Se usa un módulo Process para estas operaciones, como en la pan-
talla 11-17. Después que se completa este proceso, nuestro procesamiento está hecho, así que se
destruye la barcaza en el módulo Dispose (Eliminar) denominado Dispose Barge Entity
(Desechar la entidad barcaza).
Para completar el modelo, se establecerán los parámetros de ejecución del análisis. Puesto
que esta operación se ejecuta 24 horas al día, 7 días a la semana, parece claro que será necesa-
rio analizarlo como un sistema sin terminación. Así que necesitamos establecer un tiempo de
calentamiento apropiado, la duración de la ejecución y el número de duplicaciones. Después
de llevar a cabo algunas ejecuciones piloto, se decide que un periodo de calentamiento de cin-
co días conduce al estado estable (véase la sección 7.2.1). Se añadirá a eso 200 días de tiempo
simulado para cada duplicación (para una duración de duplicación global de 205 días), y se
realizarán 15 duplicaciones para nuestro análisis. Se elige Horas como las Unidades de tiempo
base para hacer corresponder las unidades de tiempo que se usaron para las variables de tasa
continuas (un asunto importante por recordar). Estos ajustes Run > Setup (Ejecución > Confi-
guración) se muestran en la pantalla 11-18.
La animación para este modelo es bastante simple, como se ilustra en la figura 11-9. Se aña-
de una gráfica para cada uno de los muelles que muestra el valor de la variable Barge Capa-
city (Capacidad de la barcaza) y la variable Barge Level (Nivel de la barcaza) en el mismo
Nivel de la
1000 barcaza
Muelle 2
1000
Muelle 3
1000
Muelle 4
eje. Esto nos da una representación visual de cuándo las barcazas comenzaron y terminaron las
operaciones de llenado, sin incluir el tiempo para atar y desatar los remolcadores en los muelles.
Se grafica también el número de barcazas que esperan un muelle.
Para realizar la ejecución de la simulación, se selecciona la opción para Batch Run (No
Animation)[Ejecutar en Grupo sin Animación] bajo Run > Run Control (Ejecutar > Control de
ejecución) con el fin de realizar la ejecución lo más rápido posible. Después que se han comple-
tado las 15 duplicaciones, el informe de Revisión de categoría de Arena provee las estadísticas
de resumen en las duplicaciones.
La sección de cola del informe muestra que el tiempo de espera promedio para un muelle (en
la cola llamada Seize Dock and Prepare for Filling.Queue) fue aproximadamente
0.4 horas (24 minutos), y el valor máximo observado en todas la duplicaciones fue de alrededor
de 7 horas. (Las 15 duplicaciones produjeron una amplitud media de 0.01 para el promedio, así
que debemos sentirnos bien en cuanto a la precisión del promedio predicho en este análisis.) La
estadística Number Waiting (Número en espera) para la cola informa que hubo más o menos
un remolcador en espera de un muelle, en promedio, con un máximo de 30 en espera en algún
punto tenso durante las duplicaciones.
En la sección User Specified (Especificado por el usuario) del informe Category Overview
(Revisión de categoría) se encuentra la estadística adicional Tally (Cuenta) que se añadió al
modelo por medio de un módulo Record (Registro). El tiempo promedio de llenado de barcaza
fue de más o menos 0.62 horas (justo debajo de 40 minutos), el tiempo de llenado registrado
más corto fue de 0.125 horas (7.5 minutos), y el más largo fue de 1.6 horas. Como comproba-
ción, considérese estos números para ver si son lógicos (siempre una buena idea). El tiempo
de llenado más corto que se esperaría para este sistema sería una barcaza de 300 toneladas
(el tamaño más pequeño) que recibe la tasa total de 2 400 toneladas/hora para su tiempo de
Modelos continuos y discretos/continuos combinados 487
llenado completo. Esto daría como resultado un tiempo de llenado de 300/2 400 = 0.125 horas,
que corresponde con el valor mínimo observado (así que se debe haber tenido una barcaza
pequeña que se llenó por sí misma en algún punto). Al considerar el máximo, si una barcaza de
1 000 toneladas se llenó a la tasa mínima de 600 toneladas/hora (2 400 divididos entre los cua-
tro muelles), su tiempo de llenado habría sido de 1 000/600 o 1.67 horas. El máximo observado
de 1.6 horas es menor que el más largo posible (pero bastante próximo), así que de nuevo los
resultados parecen razonables.
Crear la Tiempo de
Tomar Almacenaje
barcaza atraca-
muelle principal de
entrante miento carbón
Registrar el Disponer la
Tiempo para Liberar el
tiempo de entidad bar-
salir del atra- muelle
carga de la caza llena
cadero
barcaza
Figura 11-10. Lógica del modelo del carbón con proceso de flujo
tario de carbón. Una barcaza puede ser representada por una entidad que recorre el proceso de
modo secuencial (como se ilustra en la figura 11.10). Se usarán estos pasos básicos:
< Crear la barcaza entrante.
< Tomar un muelle (tomar el módulo Regulator [Regulador]).
< Retraso para atracar y preparación de la carga de carbón.
< Preparar para el llenado (módulos Assign y Regulate).
< Llenar Barcaza (módulo Flow).
< Limpieza del llenado (módulos Assign y Regulate).
< Retraso por desatar y abandonar el muelle.
< Liberar el muelle (liberar el módulo Regulator).
< Eliminar la entidad barcaza.
Se empieza por representar el almacenamiento de carbón principal con un módulo Tank de
la plantilla Flow Process, mostrado en la figura 11-11. Por ahora se tendrán 10 000 unidades
Figura 11-12. Módulo Seize Regulator (Tomar Regulador) que representa un muelle
de capacidad y se especificará que está lleno (después se tratará con el reabastecimiento). Se es-
pecificará también que tiene un regulador para cada uno de los cuatro muelles de barcaza. Por
separado, se crea un nuevo conjunto que contiene los cuatro reguladores por medio del módulo
de datos Regulator Set (Conjunto regulador) del Flow Process (Proceso de flujo).
El módulo Create es idéntico a lo que se usó antes. En lugar del módulo Process que se em-
pleó para tomar el muelle y el retraso por el tiempo de preparación, esta vez se utilizarán dos
módulos: un Seize Regulator (Tomar Regulador) del proceso de flujo (véase figura 11-12) y un
Delay (Retraso) del proceso avanzado.
Las asignaciones que se deben hacer para preparar el llenado son similares a lo que se efec-
tuó antes, pero son menos complejas porque una sola entidad representa cada barcaza, así que
se pueden usar atributos en lugar de sistemas de variables, donde es apropiado. El Assign (Asig-
nar) que se empleó previamente para cambiar tasas de llenado se reemplaza por un módulo
Regulate (Regular) del proceso de flujo (figura 11-13).
La mayor parte de la “magia” ocurre en el módulo Flow del proceso de flujo. Se utiliza esto
para mover en realidad el carbón sobre la barcaza. Aquí (mostrado en la figura 11-14) se especi-
fica que se desea Remove (Eliminar) material del Regulador Set (Conjunto regulador) llamado
Barge Loaging Docks (Muelles de carga de barcazas) por medio del muelle especificado en
el atributo Dock Number (Número de muelle). Se dejará de traspasar cuando se ha transferido
Figura 11-13. Módulo Regulate (Regular) para establecer las tasas máximas de carga
490 Capítulo 11
Si el lector ejecuta el módulo terminado Model 11-04.doe, encontrará que los resultados
son similares a los de Model 11-03.doe. Aunque Model 11-04.doe no posee animación,
tiene muchas buenas oportunidades para animación. Si mira en la carpeta de Arena la sub-
carpeta \Examples\FlowProcess, hallará un modelo llamado Coal Loading.doe. Éste es el
mismo problema y método analizado en Model 11-04.doe, con algunos embellecimientos.
La mayor oportunidad para el modelo (que afectará los resultados) es que ya no se supondrá
que el inventario de carbón es infinito. En cambio, se tienen entregas periódicas por tren para
reabastecer el inventario. Se posee también una cantidad de inventario máxima fija que pue-
de limitar las entregas y, por supuesto, si la pila se vacía alguna vez, limitará los envíos. Otro
cambio es que se modela el movimiento de las barcazas en la vecindad inmediata. El resto son
cosméticos, inclusive la animación de los trenes y barcazas, la de las transferencias de carbón
por medio de niveles de flujo y cierta animación divertida que incluye trenes de pasajeros y un
esquiador acuático ocasional.
temperatura. Para los fines del ejemplo, se supondrá que el cambio tiene lugar inmediatamente
y es igual a la diferencia entre la temperatura del horno en el momento en que se inserta el lin-
gote y la temperatura del lingote, dividida entre el número actual de lingotes en el horno.
El proceso de calentamiento en el horno ocasiona que la temperatura cambie por el doble de
la diferencia entre 2 600 y la temperatura actual del horno. La tasa de cambio de la temperatura
de un lingote mientras se encuentra en el horno es 0.15 veces la diferencia entre la temperatura
del horno y la del lingote.
Para nuestro estudio, nos gustaría predecir cuántos lingotes se hallan en espera de ser carga-
dos en el horno y el intervalo de la temperatura del horno conforme varía con los lingotes que
son cargados y retirados.
3
Con optimismo, esto parece un poco familiar desde sus extensas bases en matemáticas. Si no, se intentará no
complicar las cosas y se contará con su iniciativa para hallar un buen texto de matemáticas con una explicación más
profunda de cómo funciona todo esto.
Modelos continuos y discretos/continuos combinados 493
den módulos Continuous (Continuos) a nuestro modelo, se vio un campo llamado Número de
ecuaciones diferenciales (por ejemplo, sección 11.1.1). Se tuvo la fortuna suficiente para poder
diferir mucha discusión de ese asunto, porque el valor predeterminado de Arena es calcular una
ecuación para cada para nivel/tasa que se define en el modelo. Ahora se descubrirá un poco más
acerca de lo que en realidad significa.
Para el ejemplo del horno, se necesita resolver una ecuación diferencial para cada una de
nuestras diez variables continuas. Si se denota como F la temperatura del horno, entonces su
tasa de cambio sigue la ecuación diferencial:
dF/dt = 2.0 (2 600 F )
dF/dt = 2.0 (2 600 F )
Cada uno de los lingotes del horno cambia la temperatura de acuerdo con la ecuación:
Tasa
Error de paso
Valor
∆t
Tiempo
donde la curva está graficando el valor de la variable continua (nivel) con el tiempo, y la línea
discontinua indica la tasa aproximada sobre el paso de tiempo.
La duración real del paso de tiempo entre cálculos, ∆t, depende del método de integración
seleccionado. Arena provee dos métodos incorporados para integrar numéricamente sistemas
continuos. El método de Euler es un enfoque simple, que funciona bien para procesos continuos
donde la tasa de cambio permanece constante entre pasos de tiempo. Se utilizó tal método para
modelos previos en el presente capítulo. El método de Euler utiliza un paso de tiempo fijo defi-
nido por el campo Máximum Step Size (Tamaño de paso máximo) del módulo Continuous.
Para otros procesos continuos, en los que una o más tasas cambian continuamente con el
tiempo, Arena provee un conjunto más avanzado de algoritmos bajo la selección RKF (por
Runge-Kutta-Fehlberg) en el módulo Continuous. Estos métodos para resolver ecuaciones di-
ferenciales utilizan un tamaño de paso variable, que se ajusta de modo automático cada vez
que Arena recalcula valores continuos. Cuando la tasa es cercana a lineal, un tamaño de paso
más grande (más próximo al máximo) puede dar buena exactitud. Sin embargo, cuando la tasa
es no lineal, son necesarios tamaños de paso más pequeños para proveer la misma calidad de
estimaciones (aunque con la penalización de cálculos más frecuentes, lo que puede causar eje-
cuciones más lentas).
En el módulo Continuous, para proveer a Arena toda la información requerida para este
método de RKF, el lector suministra dos valores de error: las cantidades de error absoluto y
relativo que son aceptables para cada paso en la integración. Con el uso de estas cantidades,
Arena determinará si un tamaño de paso es aceptable calculando el error total como (error
absoluto) + (valor de la variable continua) × (error relativo).
Se ha mencionado que cuando la tasa cambia continuamente, se construyen ecuaciones di-
ferenciales que Arena calcula en cada paso de tiempo continuo. Para añadirlas a un modelo de
Arena, es necesario emplear una de las interfases de Arena para rutinas escritas por el usuario
(en C, C++, VBA, etc.). Las ecuaciones se codifican en una rutina integrada especial llamada
ModelLogic_UserContinuousEquations en VBA o cstate en C/C++. Debido a que
se presentó la interfaz de VBA en el capítulo 10, se le usará para codificar las ecuaciones de los
cambios de temperatura del horno y el lingote.
El módulo Continuous, pantalla 11-19, define los parámetros para la porción continua de
nuestro modelo. Se tienen diez ecuaciones diferenciales, una para cada una de las nueve tempe-
raturas de lingote más otra para la temperatura del horno. Debido a que nuestras tasas cambian
continuamente con el tiempo, se selecciona el método de integración de RKF con un tamaño
de paso mínimo de 0.01, un tamaño de paso máximo de 0.1 y valores de 0.00001 para los
errores absoluto y relativo. Se utilizará también un intervalo de Guardar punto de 0.1, que
establece el tiempo máximo que puede transcurrir antes que se registren estadísticas continuas
(CStats).
Levels (Niveles)
Number (Número) 1
Name (Nombre) Ingot Temperature (Temperatura
del lingote)
1-D Array Index (Índice de arreglo 1-D) 9
Number (Número) 10
Name (Nombre) Furnace Temperature (Temperatura
del horno)
Pantalla 11-20. Entrada del módulo Levels (Niveles) que define los
niveles de temperatura de los lingotes
496 Capítulo 11
Rates (Tasas)
Number (Número) 1
Name (Nombre) Ingot Heating Temperature (Tasa de
calentamiento del lingote)
1-D Array Index (Índice de arreglo 1-D) 9
Number (Número) 10
Name (Nombre) Furnace Heating Temperature (Tasa
de calentamiento del horno)
Pantalla 11-21. Entrada del módulo Rates (Tasas) que define las tasas de calentamiento
En el módulo Levels (Niveles), se llamará a las variables de Nivel continuas que representan
la temperatura de los lingotes en el horno Ingot Temperature (Temperatura del horno) y se
establecerán nueve de ellas (una para cada posición en el horno), como se muestra en la pantalla
11-20. Tendrán nueve variables de tasa correspondientes llamadas Ingot Heating Tempe-
rature (Tasa de calentamiento del lingote), de modo que la Ingot Heating Temperatu-
re (1) [Tasa de calentamiento del lingote (1)] será la tasa de cambio de la Ingot Temperature
(1) [Temperatura de lingote (1)], etc..
Para la temperatura global del horno, se definirá el número de Nivel 10 que se llama
rá Furnace Temperature (Temperatura del horno) y el número de Tasa 10 que se llamará
Furnace Heating Rate (Tasa de calentamiento del horno). En la pantalla 11-21 se muestra
el cuadro de diálogo principal para el módulo Rates (Tasas), así como su entrada para la In-
got Heating Rate (Tasa de calentamiento del lingote).
El módulo CStats del panel Elements (Elementos) define las estadísticas persistentes con el
tiempo que se colectarán en variables continuas. Se añadirá una sola estadística sobre la tempe-
ratura del horno, en la pantalla 11-22. La expresión SIMAN es la variable de Nivel en la que se
desea colectar las estadísticas; a saber: Furnace Temperatura (Temperatura del horno). Se
define el Nombre como Temperature of Furnace (Temperatura de horno), que aparecerá
como la etiqueta de nuestra estadística en el informe de Arena definido por el usuario. En la sec-
ción Report Database Classification (Clasificación de base de datos del informe), se especifica
“Continuous” (Continuo) para el Tipo de datos (Data Type), “User Specified” (Especi-
ficado por el usuario) para la Categoría de informe y “Furnace Temperature” (Tempera-
tura del horno) para el Identificador en el informe. Arena listará el promedio, la semiamplitud,
Modelos continuos y discretos/continuos combinados 497
Pantalla 11-22. Módulo CStats que reúne la estadística de temperatura del horno
los valores máximo y mínimo para la Temperatura del horno en el informe especificado por el
usuario. (Las comillas alrededor de cada uno de estas entradas de clasificación de base de datos
de informe son requeridas por Arena en dicho módulo.)
Debido a que tenemos la confianza de que por ahora el lector es bastante apto en el modela-
do de procesos discretos en Arena, nos moveremos por el flujo de proceso con bastante rapidez
de modo que se pueda conseguir algo fenomenal: captar las temperaturas de todos estos ele-
mentos de manera exacta. En la figura 11-17 se muestra el flujo de proceso discreto para crear
entidades de lingote. Para generar lingotes en el sistema, el módulo Create crea una entidad al
azar (distribución exponencial entre llegadas) con una media de 2.25 horas. La entidad toma
Establecer las
Tomar Esperar a que
Crear lingotes temperaturas
posición en se caliente el
que llegan del lingote y el
el horno lingote
horno
una de las nueve posiciones en el horno vía un conjunto de recursos, y almacena la posición
seleccionada en un atributo llamado Ingot Number (Número de lingote). Luego lo mueve al
módulo Set Ingot and Furnace Temperatures Assign (asignación y establecimien-
to de las temperaturas del lingote y el horno), donde incrementa en uno una variable llamada
Number in Furnace (Número en el horno); asigna la variable de nivel Ingot Tempe-
rature (Ingot Number) [Temperatura de lingote (Número de lingote)] a una muestra
de una distribución UNIF(300, 500), y asigna la Temperatura del horno a su nuevo valor,
Furnace Temperature - (Furnace Temperature - Ingot Temperature (In-
got Number))/Number In Furnace [Temperatura del horno - (Temperatura del horno
- Temperatura de lingote (Número de lingote))/Número en el horno].
En este punto, los lingotes se encuentran listos para ser calentados. Se usa un módulo Hold
(Retención), Wait for Ingot to Heat (Esperar a que se caliente el lingote), manteniendo la
entidad en una cola en espera de una señal que corresponde con su atributo Ingot Number)
[Número de lingote] (que tiene un valor entre 1 y 9 que define su posición en el horno). Esta señal
será enviada por una entidad creada en un módulo Detect que observa que el valor de la tempe-
ratura del lingote cruce la temperatura objetivo (2 200 grados); en breve se explicará esta lógica.
Después que ha sido calentado, el lingote sale del módulo Hold y entra al módulo Assign
Ingot Temperature to 0 for Renoval (Asignar la temperatura del lingote a 0 para
eliminación), donde éste disminuye en uno la variable Number in Furnace (Número en el
horno) y establece en 0 el valor de nivel de Ingot Temperature (Ingot Number) [Tempe-
ratura del lingote (Número de lingote)] (indicando que la posición está ahora vacía). El lingote
libera entonces el recurso que tomó previamente y se elimina.
En la figura 11-18 se muestra la lógica para detectar el calentamiento de los lingotes a 2 200
grados. El módulo Detect observa las nueve variables de cruce (nivel) por medio de la expresión
Ingot Temperature (J) [Temperatura del lingote (J)] para el intervalo de estación 1 a
9. (El módulo Estaciones define las nueve estaciones.) Su límite es 2 200 grados y la dirección
de cruce es positiva, con una tolerancia de cruce de 5. Cuando un lingote ha alcanzado su
temperatura objetivo, el módulo Assign Ingot Number (Asignar número de lingote) asigna
el atributo Ingot Number (Número de lingote) igual al valor del atributo Entity.Station
(Entidad.Estación) (que el módulo Detect asigna de modo automático, con base en qué nivel
de Ingot Temperatura [Temperatura de lingote] se excedió el límite). La entidad envía
entonces un código de señal igual al Ingot Number (Número de lingote), que indica que su
posición en el horno ha sido aclarada y, por último, se elimina la entidad.
completará el modelo definiendo las ecuaciones diferenciales que dictarán las tasas de cambio
de las temperaturas del lingote y el horno.
Para habilitar esta característica en VBA, se requiere seleccionar la opción Continuous
Equations (Ecuaciones continuas) que se encuentra al dar clic en el botón Advanced Settings
(Configuración avanzada) en la pestaña Run Control (Control de ejecución) de Run > Setup
(Ejecutar > Configurar), mostrada en la figura 11-19. Esto establecerá que durante la ejecución
de la simulación, Arena deba llamar al código de VBA para las ecuaciones continuas del usua-
rio en cada actualización de integración.
En el editor de Visual Basic se escribe el código de VBA en la subrutina ModelLogit_
UserContinuousEquations, mostrado en la figura 11.20. Primero, se establece la varia-
ble oSIMAN para indicar los datos SIMAN, lo que dará acceso a las variables tasa y nivel. A
continuación, se guarda el valor de la variable de nivel FurnaceTemperature [Temperatura
del horno] (que es el número de nivel 10) en la variable VBA, dFurnaceTemp, usando una
llamada para la función LevelValue en la biblioteca de objetos de Arena. El lazo For va
por los valores de nIngotNum del 1 al 9. Llama a la función RateValue para establecer los
valores de las nueve variables de tasa (que cambian las temperaturas del lingote) igual a 15%
de la diferencia entre la temperatura actual del horno y la temperatura individual del horno.
Esto corresponde a la fórmula, dPj /dt = 0.15 × (F − Pj), presentada en la sección 11.3.2. Por
último, se actualiza la tasa de cambio de la temperatura del horno —número del valor de la tasa
10— tomando dos veces la diferencia entre 2 600 y la temperatura actual del horno (dFurna-
ceTemp), que representa la fórmula descrita antes, dF/dt = 2.0 × (2 600 − F).
Siempre que tenga ecuaciones diferenciales, el lector utilizará este método. Formule las ecua-
ciones en términos de niveles y tasas, y cree después el código para poner en práctica las fórmu-
las en VBA o C/C++. Durante la ejecución de la simulación, la rutina será llamada muchas
veces, actualizando los valores de las variables de nivel y tasa a medida que se realizan los pasos
de integración continua. Los ajustes en el módulo Continuous para el tamaño de paso mínimo
y máximo del algoritmo RKF determinan con cuánta frecuencia se ejecuta estas actualizacio-
nes. Con valores más pequeños para estos tamaños de paso, las variables continuas se calculan
de modo más frecuente, lo que puede dar como resultado mayor exactitud. Sin embargo, como
podría suponer, tal exactitud viene a expensas de tiempos de ejecución más largos puesto que el
código de VBA debe ser ejecutado en cada uno de los pasos de tiempo.
En relación con los tiempos de ejecución, cuando usted ejecuta este modelo puede notar que
toma un largo tiempo. Parte de ello se debe a la naturaleza de problemas continuos en general.
Además, el código de VBA interpretado es mucho más lento que el código C++ compilado.
Como se mencionó, el código de VBA debe ser ejecutado en cada tiempo de avance, y los avan-
ces de tiempo son cortos para mantener buena exactitud; la combinación coloca una carga pe-
sada en el código interpretado. Cuando el tiempo de ejecución se vuelve un problema, el lector
hallará que esto mejorará mucho cuando los algoritmos se codifican en C++.
Al examinar los resultados para diez duplicaciones de 5 100 horas cada una (con 100 horas
de tiempo de calentamiento), se puede ver en la sección Queue (Cola) del informe de Category
Review (Revisión de categoría) que el tiempo de espera promedio para los lingotes fríos que no
pudieron ser cargados en el horno fue de 0.3 horas, y el tiempo de espera máximo fue de 11.3
horas. También, en promedio, hubo 0.15 lingotes en espera, aunque en algún punto durante la
ejecución hubo nueve en la cola (de la columna Valor máximo de la tabla Número en espera).
La estadística sobre la temperatura del horno se encuentra en la sección especificada por el
usuario del informe de Revisión de categoría. Allí, la tabla (Continuous) Continua lista la in-
formación CStat, que muestra que la temperatura promedio del horno fue de 2 514 grados, la
mínima fue 301 grados y la máxima fue 2 600 grados.
11.5 Ejercicios
11-1 Construya un modelo de evento discreto que cambia el valor del volumen en un tanque,
como se describe para el modelo 11-2b con un tamaño de paso máximo de 0.01 minutos. Regis-
tre las estadísticas persistentes con el tiempo sobre el volumen en el tanque, y compare el volu-
men reportado promedio para una ejecución de 800 horas con los resultados del modelo con-
tinuo (11-2b). Compare también con el tiempo de cálculo requerido para efectuar la ejecución
de la simulación del caso discreto contra el método continuo. (Nota: Para esta comparación,
elimine la opción Update Simulation Time Every [Actualizar el tiempo de simulación Cada] en
Run > Setup > Run Speed [Ejecutar > Configurar > Velocidad de ejecución] del modelo 11-2b,
y ejecute ambos modelos en el modo por lotes. Para mostrar el tiempo de cálculo, seleccione
SIMAN Summary Report en Run > Setup > Reports [Ejecutar > Configurar > Reportes].)
11-2 El dueño de una franquicia de estaciones de gas se encuentra interesado en determinar
qué tan grande debe ser el tanque de almacenamiento en una nueva estación. Serán instaladas
cuatro bombas de gas a clientes del servicio. Todas entregan el mismo grado de combustible.
Los automóviles llegan de acuerdo con una distribución exponencial con una media de 0.8 mi-
nutos. (Se supondrá que esto es uniforme en las horas de operación de la estación.) Su tiempo
en la bomba (desde el comienzo hasta el final) sigue una distribución triangular con parámetros
2. 2.8 y 4 minutos. Los automóviles requieren diversas cantidades de combustible, distribuidas
de acuerdo con una distribución triangular con parámetros 4, 7.5 y 15 galones.
Los camiones de reabastecimiento llegan de acuerdo con una distribución uniforme con un
tiempo mínimo entre llegadas de 6.75 horas y un máximo de 8.25 horas. Llevan combustible
suficiente para rellenar el tanque de almacenamiento y lo hacen a una tasa de 300 galones por
minuto.
Si el tanque de almacenamiento se vacía antes que llegue un camión de reabastecimiento, las
bombas se cierran hasta que el tanque contiene 100 galones (desde su siguiente reabastecimien-
to). Para los fines del presente análisis, suponga que los automóviles que están en proceso cuan-
do se vacía el tanque pueden completar su servicio y que aquellos en espera permanecerán en
la estación hasta que se vuelva a abrir la bomba. Sin embargo, cualquier automóvil que llegue
mientras las bombas se encuentran cerradas partirá para hallar otro lugar donde abastecerse.
Determine (hasta los 100 galones más cercanos) la capacidad del tanque que dará como
resultado menos de 0.1% de automóviles detenidos debido las bombas cerradas.
502 Capítulo 11
11-3 Un analista serio para Grace Enterprises, el dueño de la operación de carga de carbón
descrita en el modelo 11-3, se ha preocupado al considerar que podría ser irreal suponer que el
carbón estará disponible siempre para carga en las barcazas. A ella le gustaría refinar las esti-
maciones de tiempos de carga y los números de barcazas en espera incorporando en su modelo
la entrega de carbón por tren al patio de almacenaje.
Se tiene programado que los trenes lleguen cada ocho horas en el día y la noche, y que por
lo general arriben a tiempo. Cada tren lleva 12 000 toneladas de carbón, que se descarga en el
patio de almacenaje a una tasa de 7 500 toneladas por hora. El patio de almacenamiento puede
retener 17 000 toneladas de carbón; para los fines del presente análisis, cancele la entrega de un
tren si el patio está lleno en el momento de la llegada programada del tren.
Modifique el modelo 11-3 para incorporar la disponibilidad de carbón en el patio de alma-
cenaje de modo que las barcazas esperen en el muelle hasta que el carbón esté disponible para
cargarse. Compare el promedio y el número máximo de barcazas en espera y el tiempo de carga
de las barcazas con los resultados del modelo 11-3.
11-4 O’Hare Candy Company, fabricante de sabrosos dulces, tiene previsto colocar una nue-
va instalación de producción de licor y necesita determinar las tasas a las que debe operar el
equipo. En particular, está interesado en las máquinas de corte y envoltura, ya que son proclives
a fallas frecuentes.
En tal instalación, hay tres líneas paralelas idénticas alimentadas por una sola cocina que
produce corrientes continuas de licor. Cada línea es abastecida con licor a una tasa de 1 374
kg/hora y tiene su propia máquina de corte y envoltura (modelada como un proceso simple).
Las máquinas de envoltura cortan el licor en piezas individuales y las envuelven a una tasa de
1 500 kg/hora. Estas máquinas experimentan fallas de varias formas. El análisis de datos de
falla de equipo similar ha concluido que la frecuencia es aproximadamente una falla por hora,
con un alto grado de variabilidad que puede ser representado mejor mediante una distribución
exponencial. El tiempo para reparar una falla varía bastante también; éste puede ser modelado
por una distribución triangular con parámetros 3.75, 4.5 y 8.25 minutos.
Es muy costoso detener la cocina, así que enfrente de cada máquina se colocarán mesas de
oleada. El diseño actual requiere una capacidad de mesa de oleada de 1 000 kg. Si la cantidad de
producto excede tal capacidad, entonces la tasa a la cual la cocina está alimentando producto a
esa máquina se reduce a 900 kg/hora hasta que en la mesa haya menos de 700 kg de licor.
Para el análisis de este sistema, comience la simulación con las tres mesas de oleada llenas.
Analice el sistema para evaluar si las capacidades planificadas de mesa de oleada son suficientes
y si aquél será capaz de producir licor a las tasas requeridas.
11-5 Hope Bottling Company opera una planta de embotellado, que maneja muchos tipos de
productos. Ellos están interesados en analizar la capacidad efectiva de una línea de embotellado
de jugo de naranja como parte de sus planes para expansión futura del negocio.
En esta instalación, los camiones entregan jugo de naranja a granel (2 000 galones por carga
de camión) que se bombea a un tanque de incremento que alimenta a una operación de embote-
llado. Los camiones llegan a una tasa promedio de 1.75 camiones por hora durante las primeras
8 horas de cada día y un promedio de un camión por hora durante el resto de cada día. A su
arribo, esperan en fila un solo muelle para descargar su jugo; después de descargar, desatracan
y salen del sistema. El tiempo de atracamiento y desatracamiento para un camión se distribuye
de manera uniforme entre 1 y 2 minutos. Durante la operación de descarga, el jugo se bombea
Modelos continuos y discretos/continuos combinados 503
del camión al tanque de incremento a una tasa de 200 galones por minuto, y de este último a la
operación de embotellado a una tasa de 48 galones por minuto.
Si el nivel de jugo en el tanque de incremento alcanza la capacidad del tanque de 10 000
galones, la operación de descarga del camión se suspende hasta que el nivel desciende en 500
galones. Cuando se vacía el tanque de incremento se detiene el embotellado, hasta que llega el
siguiente camión y comienza a descargar jugo en él.
La operación de empaque (que se ejecuta 24 horas por día, 7 días por semana) embotella el
jugo de naranja en recipientes de un galón y luego los combina en cajas de 12. Las cajas se agru-
pan entonces en conjuntos de cuatro y se colocan en una paleta para envío. Por consiguiente,
cada 48 galones de jugo que son procesados en la operación generarán una paleta para envío,
lo que da como resultado una tasa máxima de producción de operación de embotellado de una
paleta cada minuto. Sin embargo, la tasa de producción real podría ser menor que esto debido
a la escasez cuando el tanque de incremento se halla vacío. La operación de embotellado se
ejecuta sin ninguna falla operacional.
Prediga el tiempo de vuelta promedio de los camiones (es decir, desde la llegada a la insta-
lación hasta la partida) y el número de paletas que serán producidas por semana. Considere
también si aumentar la capacidad del tanque de incremento a 20 000 galones subiría en forma
notable la producción o reduciría el tiempo de descarga de los camiones.
11-6 Para el problema del horno de termodifusión (modelo 11-5), utilice el modelo para
evaluar la mejora de desempeño que resulta de precalentar los lingotes entrantes para que su
temperatura se distribuya uniformemente entre 600 y 700 grados. Suponga que los lingotes en
espera en el banco frío (es decir, los que no podrían ser cargados de inmediato en el horno a su
llegada) tienen una temperatura de 600 grados.
11-7 Simule la dinámica de población relacionada con el crecimiento y decaimiento de una
enfermedad infecciosa fácilmente curable. La enfermedad ocurre dentro de una sola población,
y la recuperación después de ella produce inmunidad. La población consta de los siguientes
tres grupos: 1) los que se encuentran sanos pero son susceptibles; 2) los que están enfermos y 3)
los que son curados y, por lo tanto, quedan inmunes. Aunque el estado del sistema cambia en
realidad discretamente, se supondrá que se puede aproximar con variables de cambio continuas
que describen el tamaño de cada grupo.
Se usarán las variables de estados llamadas Well (Sano), Sick (Enfermo) y Cured (Curado)
para denotar el tamaño actual de cada grupo. Al inicio, el tamaño de la población de personas
sanas es 1 000, la población enferma es 10 y los pacientes curados son 0. El siguiente sistema de
ecuaciones diferenciales gobierna la tasa de infección, donde d/dt indica la tasa de cambio del
tamaño de la población.
d/dt (Sano) = −0.0005 × Sano × Enfermo
d/dt (Enfermo) = 0.0005 × Sano × Enfermo − 0.07 × Enfermo
d/dt (Curado) = 0.07 × Enfermo
Si se supone que las fórmulas anteriores se basan en días, ¿cuánto tiempo transcurrirá hasta
que el tamaño del grupo de personas sanas disminuya a 2 por ciento de su tamaño original?
Incluya una gráfica de las tres poblaciones.
CAPÍTULO 12
Uno de los puntos que hemos tratado de elaborar de un modo consistente en este libro es
que un efectivo estudio de simulación requiere más que construir un buen modelo (aunque los
buenos modelos son sin duda muy importantes). En una simulación con entrada estocástica
(aleatoria), el lector obtendrá también un resultado aleatorio. Así, es crítico entender cómo las
simulaciones generan esta aleatoriedad en la entrada y qué puede hacer usted respecto a la alea-
toriedad obtenida en el resultado. Ya hemos combinado algunas de estas cuestiones estadísticas
con nuestro recorrido por la construcción y análisis de modelos, específicamente en la sección
2.6, sección 4.6, capítulo 6 y la sección 7.2. Parte del tema de tales secciones es que Arena puede
ayudarlo a tratar con estos asuntos, pero el lector debe estar consciente de que existen.
En este capítulo se analizan temas estadísticos adicionales relacionados con los lados de
entrada y salida de una simulación. Los generadores de números aleatorios, la fuente de toda
aleatoriedad en las simulaciones, se analizarán en la sección 12.1. Después, en la sección 12.2,
se hablará acerca de cómo generar observaciones en cualquier distribución de entrada que us-
ted decida usar como parte de su modelado. En la sección 12.3 se analizará la especificación y
generación de un tipo particular, pero importante, de entrada aleatoria, un proceso de Poisson
no estacionario (que, a propósito, se introdujo en el modelo 5-2). Las formas de reducir la va-
rianza de salida (aparte de sólo simular algo más) se describirán en la sección 12.4. La idea del
muestreo secuencial —es decir, decidir sobre la marcha cuántos datos generados por simulación
necesita— será el tema de la sección 12.5. El capítulo concluirá en la sección 12.6 con una men-
ción breve de la posibilidad de emplear el diseño experimental en la simulación. Al momento
de llegar al final de este capítulo, el lector debe tener una comprensión completa de los temas
estadísticos en la simulación y saber cómo Arena puede ayudarlo a tratar con ellos.
Resulta evidente que en el presente capítulo se utiliza mucho el material base de probabili-
dad y estadística. En el apéndice C del libro se proporciona un recordatorio de estos temas, los
cuales es posible que usted desee ver antes de continuar. Además, el apéndice D contiene una
lista de todas las distribuciones de probabilidad soportadas por Arena.
otra vez. Por esta razón, es común llamarlos generadores de números seudoaleatorios. Algunas
personas se han preocupado por la cuestión filosófica de que tales métodos son fundamental-
mente defectuosos, puesto que parte de lo que significa ser aleatorio será impredecible. Esto
podría dar lugar a un debate interesante para después de cenar, pero a un nivel práctico, el
tema en realidad no es muy importante. Los RNG modernos construidos de manera cuidadosa
tienen, por lo general, éxito en producir un flujo de números que parecen ser en realidad alea-
torios, pasar varias pruebas estadísticas de uniformidad e independencia, así como satisfacer
criterios derivados teóricamente para ser “buenos”. También, es bastante útil en la simulación
poder generar una sucesión específica de números aleatorios; ésta es una ayuda obvia en la de-
puración (sin mencionar el trabajo de clasificar), pero es útil también estadísticamente, como se
describirá en la sección 12.4.
No obstante, parece haber una percepción común de que cualquier método aparentemente
sin sentido generará, sólo porque parece extraño, números aleatorios. En realidad, se han pro-
porcionado y usado algunos métodos muy deficientes, que posiblemente producen resultados
de simulación no válidos. Diseñar y poner en práctica generadores de números aleatorios es en
realidad bastante sutil, y ha habido mucha investigación sobre estos temas. En parte porque
las computadoras se han vuelto rápidas, continúa el trabajo sobre el desarrollo de nuevos y
mejores RNG que pueden satisfacer el apetito voraz que los simuladores modernos tienen por
los números aleatorios.
Así que ¿cómo funcionan exactamente los RNG? A través de la historia, la forma más
común (y el tipo incorporado todavía en mucho del software de simulación, pero no Arena...
más sobre este tema a continuación) se llama generador de coherencia lineal (linear congruential
generator, LCG). Un LCG genera una sucesión Z1, Z2, Z3, . . . de enteros vía recursión
Zi = (aZi – 1+ c) mod m
donde m, a y c son constantes para el generador que deben ser elegidas con cuidado, con base
en fundamentos teóricos y empíricos, para producir un buen flujo de números aleatorios. La
operación “mod m” significa dividir entre m y luego devolver el residuo de esta división al lado
izquierdo como la siguiente Zi (por ejemplo, 422 mod 63 es 44). Como con cualquier recursión,
se debe inicializar un LCG, de modo que haya una semilla Z0 especificada para el generador.
Esta sucesión de letras Zi se encontrará compuesta de enteros, que en realidad no es lo que se
desea para una distribución continua entre 0 y 1. Sin embargo, puesto que las Zi son residuos de
la división de otros enteros entre m, permanecerán entre 0 y m – 1, así que el paso final es definir
Ui = Zi /m, que estará entre 0 y 1. La sucesión U1, U2, U3, . . . son los números seudoaleatorios
devueltos para uso en la simulación.
Como un pequeño ejemplo (nadie debe usar en realidad alguna vez este generador), tome
m = 63, a = 22, c = 4 y Z0 = 19. La recursión que genera las Zi es, por lo tanto, Zi = (22
Zi − 1 + 4) mod 63. En la tabla 12-1 se traza este generador por los primeros 70 números aleato-
rios generados, y el lector puede comprobar parte de la aritmética. (Se usó una hoja de cálculo
para generar esta tabla.) A primera vista, al examinar la columna Ui se tiene la impresión de que
éstos parecen números aleatorios bastante buenos; se encuentran sin duda entre 0 y 1 (como
lo garantiza la construcción), parecen estar dispersos de manera muy uniforme en el intervalo
[0, 1], y se hallan evidentemente bastante bien combinados (independientes). La media muestral
Cuestiones estadísticas adicionales 507
de las Ui es 0.4984 y la desviación estándar muestral es 0.2867, que son cercanas a lo que se espe-
raría de una distribución uniforme verdadera [0, 1] (1/2 y (1/12)1/2 = 0.2887, respectivamente).
Pero hay un par de cosas que notar aquí. Primero, a medida que lee las Zi, verá que Z63
= 19, que es la misma que la semilla Z0. Entonces, note que Z64 = 44 = Z1, Z65 = 27 = Z2,
etc. Las Zi se repiten en el mismo orden, y este ciclo completo se repetirá por siempre. Puesto
que las Ui son las Zi divididas entre 63, los números aleatorios se repetirán también por sí
mismos. Este ciclo de un LCG sucederá tan pronto como se encuentre con una Zi generada
previamente, puesto que cada número en la secuencia depende sólo de su predecesor, vía la
fórmula recursiva fija. Y es inevitable que el LCG entre en un ciclo puesto que hay, después
de todo, sólo m posibilidades para el resto de la división entre m; en otras palabras, el ciclo
durará a lo sumo m. En nuestro pequeño ejemplo, la duración del ciclo alcanzó en realidad
su máximo, m = 63, pero si los parámetros a y c se hubieran elegido de manera diferente, la
duración del ciclo podría haber sido más corta. (Pruebe con a = 6 pero deje todo lo demás
igual.) No sólo se tuvo suerte (o se fue persitente) en la elección, puesto que hay una teoría
508 Capítulo 12
completamente desarrollada sobre cómo hacer elecciones de valores de parámetros para los
LCG a fin de lograr duraciones de ciclo completas o por lo menos largas. Los LCG reales, a
diferencia del pequeño ejemplo anterior, toman m como por lo menos 231−1 = 2 147 483 647
(alrededor de 2.1 miles de millones) y eligen los otros parámetros para lograr la duración
completa o casi completa del ciclo. Aunque se puede recordar cuando 2.1 miles de millones
aún era mucho, tal duración de ciclo no es tan impresionante como alguna vez lo fue, dada la
potencia de cálculo actual. De hecho, con sólo una PC ordinaria, se puede agotar los 2.1 mi-
les de millones de números aleatorios posibles de tal LCG en cuestión de minutos o a lo sumo
unas horas, dependiendo de lo que se haga con los números aleatorios después de generarlos.
Si bien es posible elegir una m incluso más grande en los LCG, las personas han desarrollado
en cambio clases completamente diferentes de generadores con duraciones de ciclo enormes,
y Arena emplea una de éstas (más sobre el tema a continuación).
La otra cosa por entender acerca de las Ui en la tabla 12-1 es que podrían no ser tan “aleato-
rias” como el lector quisiera, como indican las dos gráficas de la figura 12-1. La de la izquierda
simplemente grafica los números aleatorios en el orden de su generación, y usted notará cierta
regularidad. Esto quizá no es tan molesto puesto que se sabe que el generador entrará en un
ciclo y repetirá exactamente el mismo patrón. El patrón para un generador real (con un valor
superior de m), no será tan evidente puesto que hay muchos más números aleatorios posibles y
que, en muchas aplicaciones, el lector estará usando por lo general sólo una pequeña parte de
un ciclo completo.
Pero la gráfica de la figura 12-1 podría ser más perturbadora. Ésta traza los pares (Ui, Ui+1)
sobre el ciclo completo, que es de interés natural si usted está empleando los números aleatorios
en pares en la simulación (por ejemplo, generar un tiempo entre llegadas seguido inmediata-
mente de una asignación aleatoria parcial. Como puede ver, tiene un patrón extraño que, de
hecho, se encontrará presente para cualquier LCG (como se muestra en el documento deno-
minado “Random Numbers Fall Mainly in the Planes” de Marsaglia, 1968). Un generador
verdaderamente aleatorio debe tener en cambio puntos dispersos al azar de manera uniforme
sobre el cuadrado unitario, en vez de estar ordenado de manera compulsiva y dejar espacios
comparativamente grandes donde ningún par es posible. Y esta estructura de retícula empeora
si construye (o imagina) tal gráfica con mayores dimensiones (ternas, cuádruplas, etc., de nú-
meros aleatorios sucesivos). Estas clases de consideraciones deben dejar claro que “diseñar”
buenos RNG no es una cuestión simple y, por lo tanto, debe tener cuidado al encontrar algún
RNG misterioso no documentado.
1.0 1.0
Ui 0.5 Ui + 1 0.5
0.0 0.0
0 35 70 0.0 0.5 1.0
i J
El RNG original en Arena, comenzando a principios de la década de 1980 con SIMAN, era
un LCG con m = 231 − 1, a = 75 = 16 807 y c = 0; la duración del ciclo de éste es m − 1 = 2.1
miles de millones. En su época, tal generador era aceptable puesto que había sido bien probado
y de hecho entregaba un flujo respetable de números aleatorios. Sin embargo, debido a que las
computadoras se han vuelto mucho más rápidas, es evidente que la duración de dicho ciclo ya
no es adecuada y que este viejo generador corría el riesgo de recorrer de nuevo todo el ciclo
dentro de unas horas o quizá incluso minutos de simulación (lo cual podría ser dañino para la
validez de sus resultados).
Así que se ha instalado un nuevo RNG en Arena (y se encuentra en la versión de Arena en el
CD que viene con este libro), con base en la investigación de L’Ecuyer (1996, 1999) y L’Ecuyer,
Simard, Chen y Kelton (2002). Si bien aquél usa algunas de las mismas ideas que los LCG (en
particular la operación de división de módulo), difiere en que: 1) tiene que ver con dos gene-
radores de componentes separados que después se combinan, y 2) la recursión para obtener
valores siguientes ve retrospectivamente más allá del simple valor precedente. Esta clase de
generador se llama generador recursivo múltiple combinado (Combined Multiple Recursive Gene-
rator, CMRG). Primero empieza las dos recursiones separadas, que el lector puede considerar
operan en paralelo al mismo tiempo:
Z /4294967088, si Zn > 0
Znnn /4294967088,
Z /4294967088, si Znn >
si Z > 00
4294967087/4294967088,
4294967087/4294967088, si Z = 00
o bien, Z /4294967088, si Zn > 0 si
4294967087/4294967088,
n Znnn =
si Z =0
4294967087/4294967088, si Zn = 0
Para empezar las dos recursiones, el generador debe definir un 6-vector de semillas, compuesto
de las tres primeras An y las tres primeras Bn.
Las constantes bastante espeluznantes relacionadas con este generador han sido elegidas de
manera cuidadosa, con base en los documentos citados antes, para asegurar dos propiedades
muy deseables. Primero, las propiedades estadísticas de los números aleatorios producidos son
extremadamente fuertes; se obtiene buena distribución de los puntos generados, como la gráfi-
ca del lado derecho de la figura 12-1, pero hacia arriba por un cubo de 45 dimensiones en vez de
sólo las dos dimensiones de la figura 12-1. Segundo, si bien este generador entrará en un ciclo
(como los LCG), la duración de éste es un abrumador 3.1 × 1057, en vez de 2.1 × 109 para el
generador anterior. Y la velocidad de ejecución sobre una base por número aleatorio del nuevo
generador es sólo un poco menor que la anterior.
510 Capítulo 12
ayuda en línea le proporciona más información acerca de lo que este módulo Seeds hace para
el generador anterior. Si desea usar el nuevo generador (lo cual se recomienda), sólo asegúrese
de no tener un módulo Seeds presente en su modelo.
12.2.1 Discretas
Comencemos considerando las variables aleatorias discretas (véase la sección C.2.2 en el apén-
dice C). Para tomar un ejemplo simple, suponga que se desea generar una variable aleatoria
discreta X con valores posibles −2, 0 y 3 con función de masa de probabilidad (PMF, por sus
siglas en inglés) dada por
ê
0.1 para x = –2
p(x) = P(X = x) = 0.5 para x = 0
0.4 para x = 3
Puesto que las probabilidades en una PMF tienen que sumar 1, se puede dividir el intervalo
unitario [0, 1] en subintervalos con amplitudes iguales a los valores individuales dados por la
PMF, en este caso, [0, 0.1), [0.1, 0.6) y [0.6, 1]. Si se genera un número aleatorio U, se distribuirá
de modo uniforme en el intervalo completo [0, 1], de modo que caerá en el primer subintervalo
con probabilidad 0.1 − 0 = 0.1, en el segundo con probabilidad 0.6 − 0.1 = 0.5 y en el tercero
con probabilidad 1 − 0.6 = 0.4. Así, se establecería X en su primer valor, −2, si U cae en el
primer subintervalo, lo cual sucederá con probabilidad 0.1 = p(−2), como se desea. De manera
similar, se establece X en 0 si U cae en el segundo subintervalo (probabilidad 0.5) y se establece
X en 3 si U cae en el tercer subintervalo (probabilidad 0.4). Este proceso, que es correcto para
generar X con la distribución deseada, se ilustra en la figura 12-2.
Otra forma de examinar este algoritmo es que invierte, en un sentido, la función de distri-
bución acumulada (Cumulative Distribution Function, CDF) de X, F(x) = P(X ≤ x), como se
ilustra en la figura 12-3. Primero, genere un número aleatorio U, después grafíquelo en el eje
vertical, luego lea en la gráfica (izquierda o derecha) hasta encontrar uno de los saltos en la
CDF y, por último, lea y devuelva X como xi (= −2, 0 o 3 en nuestro ejemplo). En el ejemplo
mostrado, U cae entre 0.6 y 1, y se obtiene una variable X = 3. Éste es claramente el mismo al-
goritmo descrito antes mostrado en la figura 12-2, pero prepara las cosas para generar variables
aleatorias continuas.
512 Capítulo 12
U:
X= 2 X= 0 X= 3
Figura 12-2. Generación de una variable aleatoria discreta
F(x)
1.0
0.6
0.1
x
2 0 3
Grupo X = 3
Figura 12-3. Generación de una variable aleatoria discreta vía inversión de la CDF
Cuestiones estadísticas adicionales 513
Para generar una variable X de esta distribución, inicie (como siempre) creando un número
aleatorio U. Después iguale U a la CDF (evaluada en la incógnita X) y despeje X en términos
del valor de U (no conocido):
U = 1 – e–X/5
= 11 –– U (ignorar el evento de probabilidad cero de que U = 0)
eU –X/5
= e–X/5
e –X/5
=
= 1ln–(1 U– U )
–X/5 (ln es el logaritmo natural; es decir, base e)
–X/5 =
X = –5ln (1
ln –(1U–) U)
X = –5 ln (1 – U)
(Obviamente, reemplazar el 5 con cualquier valor de β > 0 le da la forma general para generar
una variable exponencial.) Esta solución para X en términos de U se llama CDF inversa de U,
escrita como X = F−1(U) {=−5 ln (1 − U) en nuestro ejemplo}, puesto que esta transformación
“deshace” para U lo que F hace para X.
El algoritmo de la CDF inversa para este ejemplo se muestra en la figura 12-4. (Note la simi-
litud para el caso discreto en la figura 12-3.) Primero genere un número aleatorio U, grafíquelo
en el eje vertical, luego lea en la gráfica para obtener X, que es claramente la solución para la
ecuación U = F(X).
Para ver por qué este algoritmo es correcto, se necesita demostrar que la variable X devuelta
caerá a la izquierda de cualquier valor fijo x0 con probabilidad igual a F(x0 ), porque esto es
precisamente lo que significa para la CDF de X ser F. De la figura 12-4, se ve que, puesto que F
es una función creciente, se obtendrá X ≤ x0 si y sólo si se extrae una U que es ≤ F(x0); la figura
12-4 ilustra esto para tal valor de U. Así, los eventos “X ≤ x0” y “U ≤ F(x0)” son equivalentes,
por lo tanto deben tener la misma probabilidad. Pero puesto que U está distribuida de modo
uniforme en [0, 1], será ≤F(x0) con probabilidad F(x0), debido a que F(x0) se halla entre 0 y 1.
Así, P (variable devuelta X es ≤ x0) = F(x0), como se desea.
Aunque al lector podría parecerle extraño, hay en realidad una atracción intuitiva hacia
este algoritmo. Lo que se desea es que las X devueltas sigan la función de densidad f (x), así
que queremos muchas X donde f (x) es alta y no muchas donde f (x) es baja (véase la sección
C.2.3 en el apéndice C). Ahora la CDF F (x) es la integral (indefinida) de la PDF f (x); en otras
palabras, f(x) es la derivada (función pendiente) de F (x). Así, donde f (x) es alta, la pendiente
de F (x) será pronunciada; donde f (x) es baja, F (x) será creciente sólo de manera lenta (es decir,
con poca pendiente). En nuestro ejemplo exponencial, f (x) comienza en su punto más alto en
x = 0 (véase la entrada Exponencial en el apéndice D) y luego desciende; por lo tanto, F (x) se
incrementa de manera abruta justo a la derecha de 0, y luego se aplana su pendiente conforme
se avanza a la derecha, que es donde f (x) se vuelve más pequeña. Ahora, ubíquese en la figura
12-4 y párese justo a la derecha del eje vertical. Tome una manguera de jardín que rociará le-
tras U de modo uniforme a la derecha, y abra la llave. Cuando sus letras U se encuentren con
la curva F (x) escurrirán hacia el eje horizontal, aterrizando para definir sus X devueltas. Sus
514 Capítulo 12
1.0
F (x)
F(x0)
0.5
U
0.0
X x0
0 5 10 15 20
x
Figura 12-4. Generación de una variable aleatoria continua vía inversión de la CDF
letras U dispersadas de modo uniforme tendrán más probabilidades de chocar con la curva
F (x) donde está más inclinada (en este caso exponencial, al comienzo de su ascenso) puesto
que es un objetivo más grande desde donde usted está parado. Sólo algunas de sus letras U (las
más altas) chocarán con F (x) en su porción recta superior. Así, si examina dónde cayeron sus
X, habrá más en la parte izquierda (donde f (x) es alta y F (x) asciende abruptamente), y habrá
menos en la parte derecha (donde f (x) es baja y F (x) asciende poco). Esto es lo que se desea
para la presente distribución.
La idea de CDF inversa funciona, en principio, para cualquier distribución continua.
Pero, dependiendo de la distribución particular, ponerla en práctica podría no ser fácil. Algu-
nas distribuciones, a diferencia del ejemplo exponencial anterior, no tienen fórmula de forma
cerrada para la CDF F (x), así que no es posible una fórmula simple para generar las X (un
ejemplo notable de esto es la distribución normal). Sin embargo, en muchos casos, se puede
usar métodos numéricos para aproximar la solución de U = F(X) para X a un grado muy
alto de exactitud (con equivocación menor que el error de redondeo de la computadora). Hay
también métodos completamente diferentes para generar variables que se usan a veces, mas
no se tratarán aquí.
La mayor parte de las distribuciones continuas soportadas por Arena (véase el apéndice
D) usan el método de CDF inversa para la generación de variables, en algunos casos mediante
aproximación numérica muy exacta. No obstante, algunas de las distribuciones utilizan otros
métodos si son particularmente atractivos en ese caso; refiérase a la ayuda en línea bajo el tema
“Distribuciones” a fin de ver exactamente lo que hace Arena para generar muestras de cada
distribución continua.
entre eventos y generar los eventos durante la simulación como se ha hecho en muchos modelos
en el libro (por ejemplo, con el área de Tiempo entre llegadas en el módulo Create (Crear) del
panel Basic Process (Proceso Básico).
Sin embargo, muchos sistemas experimentan variación con el tiempo, o patrones de eventos
no estacionarios: la estampida para el almuerzo en los restaurantes de comida rápida, las horas
de mayor afluencia de los sistemas de tránsito en la mañana y la noche, los picos de llamadas de
media tarde que entran a un centro de llamadas o una racha de accidentes cuando es luna llena.
Si bien usted podría estar tentado a ignorar estos patrones, y hacer que los eventos ocurran a
cierta clase de tasa “promedio” en su simulación, proceder así podría conducir a resultados
muy inexactos si hay mucha variación en el patrón real. Por ejemplo, si se promedia la carga de
una autopista en 24 horas, hay poca duda de que una cantidad pequeña de carriles parecería ser
adecuada en el modelo; de hecho, las horas de mayor afluencia serían desórdenes imposibles.
Por lo tanto, modelar eventos externos no estacionarios puede ser una parte crítica del mode-
lado válido en general.
En realidad, ya se ha estudiado una situación como ésta, modelo 5-2. Los eventos externos
son los arribos de llamadas entrantes, y se especifican las tasas observadas (en arribos por hora)
para cada periodo de 30 minutos en la línea de Programa de llegadas (Arrival Schedule)
del módulo Schedule (Programa).
La forma usual de representar patrones de eventos que varían con el tiempo como éste es
mediante lo que se llama un proceso de Poisson no estacionario (NSPP, por sus siglas en inglés).
Para usar este tipo de proceso se necesita especificar una función de tasa, λ(t), que cambia con el
tiempo (t), con la interpretación aproximada de que λ(t) es alta para tiempos t cuando están su-
cediendo muchos eventos, y baja cuando las cosas se encuentran en calma. Con más precisión,
la definición de un NSPP es que los eventos ocurren uno a la vez, son independientes entre sí y
el número (cuenta) de eventos que ocurren durante un intervalo de tiempo [t1, t2] es una variable
aleatoria de Poisson (véase el apéndice D) con valor esperado dado por
t
Č(t1 , t2) âƞ 2ħ (t)dt
t1
que es grande en intervalos de tiempo donde λ(t) es alta y pequeña cuando λ(t) es baja.
Si desea usar un NSPP en una simulación, hay dos cuestiones: cómo formar una estimación
de λ(t), y luego cómo generar las llegadas de acuerdo con su función de tasa estimada. La fun-
ción de tasa estimada que se empleó en el modelo 5-2 fue constante por partes, con (posibles)
cambios de nivel que ocurren cada 30 minutos. Este método es probablemente el más práctico,
puesto que es bastante general y fácil de especificar (aunque el lector debe tener cuidado en
cuanto a mantener congruentes las unidades de tiempo). Sin embargo, hay formas más comple-
jas de estimar la función de tasa, incluso amplitudes y periodicidades, con fundamento firme
en teoría estadística; véase, por ejemplo, Leemis (1991); Johnson, Lee y Wilson (1994), y Kuhl
y Wilson (2000, 2001).
Mientras continúe con una función de tasa estimada constante por partes, Arena tiene un
método de generación integrado, cuyo uso se ilustra en el modelo 5-2. El algoritmo utilizado
es una variación acelerada de un método atribuido a Cinlar (1975, pp. 94-101). Si usted está
interesado en los detalles, véase el tema de ayuda de Arena “Distribución exponencial no esta-
cionaria”.
516 Capítulo 12
1
Bueno, sin ninguno pesado.
Cuestiones estadísticas adicionales 517
Por ejemplo, tome el modelo 7-2, el modelo de un pequeño sistema de manufactura con la
salida de trabajo en proceso (Work In Process, WIP) total promedio desarrollado en la sección
7.2.1. Considérese el modelo exactamente en el estado actual como un “caso base”. Se manten-
drá la duración de la duplicación en 5 días y el número de duplicaciones en 10; estamos viendo
esto implícitamente como una simulación de terminación o una simulación de estado estable al
usar el método de duplicaciones truncadas pero sin ningún periodo de calentamiento necesario.
Suponga que hay una oportunidad de tomar 3.5% más negocios, con la misma combinación de
tipos de partes, sucesiones y tiempos de procesamiento, que se traduce en una disminución en el
tiempo entre llegadas promedio entre partes de 13 minutos a 12.56 minutos (la tasa de llegadas
promedio 1/12.56 es 3.5% más que la tasa de llegadas promedio 1/13). Llame A a las alternati-
vas del modelo de caso base y B a la alternativa del modelo de llegada incrementada. Se hacen
las siguientes modificaciones al modelo 7-2 para producir lo que llamaremos modelo 12-1:
< Se hicieron los cambios de documentación apropiados en Run > Setup > Project Para-
meters (Ejecutar > Configurar > Parámetros de proyecto).
< En el módulo Statistic, se eliminó la entrada Total WIP History.dat del Output
File (Archivo de salida) para la estadística existente con nombre Total WIP, puesto
que ahora no se necesita guardar la trayectoria dentro de ejecución de esta cantidad.
< En el módulo Statistic se agregó un renglón para la nueva estadística con Name (Nom-
bre) Avg Total WIP, Type (Tipo) Output, Expression (Expresión) DAVG(Total
WIP), Report Label (Etiqueta de informe) Avg Total WIP y Output File (Archivo de
salida) Avg Total WIP.dat para guardar para ese archivo el WIP promediado en el
tiempo de cada duplicación que se usará en el Output Analyzer (Analizador de salida)
siguiente.
En la figura 12-5 se muestran las entradas en el módulo Statistic modificado. Por supuesto, nos
aseguramos de que se seleccionara Run > Run Control > Batch Run (No Animation) [Ejecutar
> Control de ejecución > Ejecutar en grupo (Sin animación)] puesto que se está interesado sólo
en los resultados numéricos y no en la animación.
La forma normal de proceder aquí es ejecutar la alternativa A, hacer el cambio para ir de la
alternativa A a la B (cambiar Value en el módulo Create de 13 a 12.56), ejecutar la alternati-
va B (por supuesto, debe recordar cambiar el nombre del Output File [Archivo de salida] en el
sistema operativo después de ejecutar A para no sobreescribirlo al ejecutar B), y usar Analyze >
Compare Means (Analizar > Comparar medias) en el Output Analyzer (Analizador de salida),
aceptando el valor predeterminado de la Paired-t Test (prueba t por pares) puesto que no se hizo
nada para poder usar números aleatorios separados en la ejecución de B; véase en la sección 6.4
una explicación de la mecánica y otras aclaraciones. Esto da como resultado la figura 12-6 de la
función Compare Means en el Output Analyzer. Recordando que la diferencia es en la dirección
A − B, es intuitivo que el estimador puntual de la media sea negativo, puesto que la alternativa
B es el modelo de llegada superior, así que se esperaría que WIP sea más grande. Sin embargo, el
intervalo de confianza en la diferencia esperada contiene cero, así que no se puede concluir que
hay una diferencia estadísticamente significante. Por supuesto, hacer más que las diez duplica-
ciones podría cambiar esto, pero estamos tratando de ser más inteligentes aquí.
Y aquí tiene una forma de ser más inteligente. Para estimar la diferencia entre los WIP
totales promedio producidos por las alternativas A y B, tiene sentido intuitivo simular ambas
en condiciones que sean lo más similares posible, excepto para el cambio de modelo que se
hizo. En simulación, a lo que se reducen las “condiciones” son las variables generadas desde
las distribuciones de entrada, como tiempos entre llegadas y de servicio. Si se vuelve a usar los
mismos números aleatorios en la ejecución B, como se hizo en la ejecución A, se podría esperar
obtener las mismas variables generadas. En ese sentido, cuando se examina la diferencia en los
resultados, se sabría que se debe a la diferencia en los modelos y no a los números aleatorios el
hecho de haber rebotado de modo distinto en las dos alternativas.
Si piensa al respecto, se emplearon en realidad los mismos números aleatorios en la ejecución
B y en la ejecución A, pero como se extrajo sólo una sucesión fija (flujo) de números aleatorios
para todo, es muy probable que el uso de estos números aleatorios se combine después de corto
tiempo entre las ejecuciones A y B, debido a la diferencia en las trayectorias seguidas por las
alternativas A y B en términos de generar variables. Esto no empeora nuestra comparación
estadística en la figura 12-6 (siempre que se siga la Prueba t por pares en vez de la Prueba t de
dos muestras), sino que no cumple el objetivo de generar las mismas variables para los mismos
propósitos en las ejecuciones A y B. Necesitamos ser incluso más inteligentes (así como tener un
buen generador de números aleatorios con muchos flujos y subflujos realmente largos, lo cual
posee Arena, como se describió en la sección 12.1).
Aquí tiene que ser incluso más inteligente. En este modelo, hay 14 fuentes de aleatoriedad,
tiempos entre llegadas, índices parciales y 12 distribuciones de tiempo de proceso como se de-
finen en la tabla 7-1. Para nuestra comparación, nos gustaría ejecutar ambas alternativas A y
B con las mismas “cargas” externas. En tal caso, esto significa partes en blanco que llegan en
los mismos tiempos, con los mismos índices parciales asignados y experimentando los mismos
tiempos de procesamiento en cada uno de los paros a lo largo de sus trayectorias. Cuando se
Cuestiones estadísticas adicionales 519
ejecutó antes esta comparación, y se obtuvo la figura 12-6, no se hizo nada para tratar de lograr
que algo de esto sucediera. Cierto, se usó el mismo flujo aleatorio (el flujo 10 predeterminado)
para todo en ambas alternativas, y tal flujo comenzó la primera de las diez duplicaciones de
la misma semilla para ambas alternativas. Pero debido al cambio hecho en el modelo entre las
alternativas, esta sucesión fija de números aleatorios se usará en un orden distinto si, en algún
punto durante las ejecuciones, hay una diferencia en el orden de ejecución en el que los 14 lu-
gares extrajeron las variables que necesitaban. Esto causa que las “cargas externas” difieran en
este punto, y probablemente de allí en adelante, lo cual no es el efecto que deseamos.
En cambio, se necesita sincronizar el uso de los números aleatorios en las alternativas de
modelo, o por lo menos hacerlo en la medida de lo posible dada la lógica del modelo y los
cambios entre alternativas. Un método (aunque no el único) para este fin es dedicar un flujo de
números aleatorios a cada uno de los 14 lugares en el modelo donde se generan las variables.
Esto es como canalizar en “grifos” separados de números aleatorios a cada generador de varia-
bles aleatorias y otras situaciones (como los módulos Decide tipo posibilidad y generación de
procesos de Poisson no estacionarios, ninguno de los cuales ocurre en este modelo) donde se
necesita un número aleatorio. De este modo, el lector puede obtener por lo general sincroniza-
ción razonable, aunque en los modelos complejos esto no podría asegurar que todo hace juego
en las alternativas (lo cual de ninguna manera convierte a su modelo en incorrecto o no válido,
pero no está lo bastante próximo a una correspondencia en las alternativas como usted quisiera
a fin de tener las “mismas” cargas externas presentadas para ambos modelos alternativos). Sin
embargo, aún habrá probablemente por lo menos algún beneficio de reducción de varianza
incluso aunque las correspondencias podrían no ser bastante perfectas. Éste es el método de
sincronización que se tomará en nuestro ejemplo siguiente.
Una forma diferente de intentar la sincronización de números aleatorios, que podría funcio-
nar mejor en algunos modelos, es asignar a cada entidad, inmediatamente a su llegada, valores
de atributo para todos los tiempos de procesamiento posibles, decisiones de ramificación, etc.,
que podrían necesitar en toda su trayectoria por el modelo. Cuando la entidad necesita uno de
estos valores durante su vida en el modelo, tal como un tiempo de procesamiento en alguna
parte, usted sólo lo lee del atributo apropiado de la entidad en vez de generarlo en el acto. Esto
podría acercar a algunos modelos al ideal de tener las “mismas” condiciones externas, pero
puede requerir mucha más memoria de computadora si necesita retener numerosos atributos
para muchas entidades al mismo tiempo. Si Arena tiene que usar su disco duro para ampliar
la memoria temporalmente (llamada memoria virtual), puede haber también un incremento
importante en tiempo de ejecución puesto que el acceso al disco es mucho más lento que el
acceso a la memoria. En esta situación, usted podría estar también libre utilizando este tiempo
de computadora extra haciendo más simulación (ya sea más duplicaciones o una sola ejecución
más larga). En el siguiente ejemplo no se llevará a cabo este método de sincronización, pero se
dejará para usted como ejercicios 12-1 y 12-2.
Algunas veces lograr cierta sincronización o toda en modelos complejos es impráctico, en
cuyo caso usted podría considerar hacer corresponder lo que usted pueda, y generar el resto
de modo independiente. Cuando el lector usa los mismos números aleatorios en alternativas
simuladas, sincronizadas de algún modo, está empleando una técnica de reducción de varianza
llamada números aleatorios comunes (Common Random Numbers, CRN), denominada a veces
pares coordinados o muestreo correlacionado.
Para poner en práctica el primero de los dos métodos de sincronización anteriores con CRN
(canalizando en llaves separadas de números aleatorios a las fuentes de aleatoriedad separadas
520 Capítulo 12
en un modelo) en el modelo 12-1, lo modificamos en lo que llamaremos modelo 12-2. Para cada
una de las 14 expresiones de generación de variables, se añade un parámetro extra (véase la
sección 12.1), asignando un número de flujo, dado en la tabla 12-2. Se definió en realidad una
variable para cada número de flujo, inicializadas en el módulo Variable, y se usaron los nombres
de variables en las expresiones de generación de variables; esto facilitó llevar a cabo más experi-
mentos después. Se pasó por alto el flujo 10 puesto que ésa es la predeterminada de Arena y se
utiliza para el generador integrado de proceso de Poisson no estacionario y cualquier módulo
Decide tipo posibilidad; por fortuna, no se tiene ninguno en nuestro modelo, así que es fácil
mantener sincronización adecuada. (Véase en el ejercicio 12-7 una forma de engañar a los mó-
dulos Decide tipo posibilidad al usar cualquier flujo de números aleatorios que desee.) En este
modelo, los tiempos de procesamiento son asignados para la Celda 1 vía una expresión, y para
las otras celdas vía asignaciones en las Sucesiones; en la tabla 12-2 se indica también dónde se
hizo el cambio requerido.
Estas asignaciones de flujo dedican un flujo separado de números aleatorios a cada fuente
de aleatoriedad en el modelo, y estarán en efecto para la ejecución de ambas alternativas A y
B. Recuerde que estamos haciendo diez duplicaciones de cada alternativa, y que el generador
de números aleatorios de Arena avanzará de modo automático al siguiente subflujo dentro de
cada flujo para cada nueva duplicación. De esta manera, se asegura que la correspondencia de
números aleatorios en las alternativas permanecerá sincronizada sólo para la primera dupli-
cación, incluso si las alternativas no concuerdan en lo referente a cuántos números aleatorios
se usan para una determinada duplicación. Puesto que tomará por lo menos 669 millones de
años para que una máquina representativa actual agote un subflujo, se puede estar bastante
seguro de que no nos “traslaparemos” nosotros mismos en términos de uso de subflujo de una
duplicación a la siguiente.
Número
de flujo Uso Nombre de la variable Ubicación del cambio
1 Tiempos entre llegadas S Interarrivals Módulo Create
2 Índices parciales S Part Index Módulo Assign
3 Tipo parcial 1 en la celda 1 S P1 C1 Módulo Expression
4 Tipo parcial 1 en la celda 2 S P1 C2 Módulo Sequence
5 Tipo parcial 1 en la celda 3 S P1 C3 Módulo Sequence
6 Tipo parcial 1 en la celda 4 S P1 C4 Módulo Sequence
7 Tipo parcial 2 en la celda 1 S P1 C1 Módulo Expression
8 Tipo parcial 2 en la celda 2 S P1 C2 Módulo Sequence
(primera visita)
9 Tipo parcial 2 en la celda 4 S P1 C4 Módulo Sequence
11 Tipo parcial 2 en la celda 2 S P1 C2 De nuevo Módulo Sequence
(segunda visita)
12 Tipo parcial 2 en la celda 3 S P1 C3 Módulo Sequence
13 Tipo parcial 3 en la celda 2 S P1 C2 Módulo Sequence
14 Tipo parcial 3 en la celda 1 S P1 C1 Módulo Expression
15 Tipo parcial 3 en la celda 3 S P1 C3 Módulo Sequence
Cuestiones estadísticas adicionales 521
Lo que se estableció antes es una asignación de números aleatorios sincronizada con bastan-
te cuidado para CRN. Lo que se hizo en la sección 6.4 y produjo la figura 12-6 anterior, usando
el mismo flujo (10) para todo se podría describir cómo usar los mismos números aleatorios
en las alternativas, pero en una forma desorganizada, fortuita y sobre todo no sincronizada,
diluyendo o incluso borrando el efecto. Es posible simular las alternativas al usar números
aleatorios completamente diferentes y, por lo tanto, independientes en las alternativas, pero el
lector tiene que trabajar para lograr que esto suceda aumentando los números de flujo en la
tabla 12-2 para, por ejemplo, la alternativa B (pero no A) de modo que no se utilicen los flujos
1-15. Así, en cierto modo, CRN es el valor predeterminado para la forma en que la mayor parte
de las personas ejecutarían de manera natural las comparaciones, pero es muy improbable que
la sincronización adecuada de uso de números aleatorios suceda por sí sola a menos que su
modelo sea bastante simple.
Si se procede como en la sección 6.4 y se realiza lo que se hizo para producir la figura
12-6 anterior, se producen diez duplicaciones de las alternativas A y B empleando el mode-
lo 12-2 para ambas, con las asignaciones de flujo analizadas antes, lo que da como resultado
CRN sincronizados. Después se invoca la opción de menú Analyze > Compare Means (Anali-
zar > Comparar medias) en el Output Analyzer (Analizador de salida) excepto que se requieren
las comparaciones de A contra la ejecución de B de CRN, a fin de obtener los resultados de la
figura 12-7 para un intervalo de confianza sobre la diferencia entre los WIP totales promedio
esperados para la alternativa A menos la alternativa B (la figura 12-7 incluye en realidad tan-
to la comparación de CRN sincronizada como la “natural” no sincronizada). Al observar de
nuevo la figura 12-6 (repetida como la comparación superior en la figura 12-7), la conclusión
cualitativa de los CRN sincronizados es la misma que antes, incrementar la tasa de llegadas au-
menta los WIP totales promedio, aunque la comparación “natural” podría no concluir eso con
la importancia estadística (al nivel 0.05) en tanto que sí lo puede hacer la comparación de CRN
sincronizados. En términos de la precisión de la estimación de la magnitud de este incremento,
el efecto de sincronizar los CRN es reducir el intervalo de confianza a la mitad en forma bas-
tante drástica, de 7.41 a alrededor de 0.711, sin hacer más trabajo de simulación que antes (diez
duplicaciones de ambos modelos alternativos). Así, para este modelo con tales comparaciones,
el beneficio de los CRN sincronizados de manera apropiada es bastante evidente. La magnitud
del efecto de los CRN es muy dependiente del modelo y la situación, y es bastante potente en
este ejemplo. Sin embargo, algunas veces, puede ser menos impresionante, pero el pequeño es-
fuerzo para sincronizar el uso del flujo es aún quizá importante en la mayoría de los casos.
Quizá haya observado en las figuras 12-6 y 12-7, o del cuadro de diálogo Analyze > Com-
pare Means (Analizar > Comparar medias) en la pantalla 6-1, que hemos usado una de dos
posibilidades para construir los intervalos de confianza en las diferencias esperadas, y para pro-
bar la hipótesis nula de que no hay diferencia entre las dos expectativas. Esta opción se llama
método t por pares (que es el predeterminado). Tal método toma las diferencias duplicación
por duplicación entre los resultados de las dos alternativas, así que “colapsa” las dos muestras
a una sola en la cual se hizo el análisis. La ventaja del método t por pares es que no requiere la
suposición de muestreo independiente en las alternativas para validez estadística, lo que permi-
te el uso de CRN. La desventaja es que el lector termina con una “muestra” cuyo tamaño es la
mitad del número de ejecuciones que hizo (en nuestro ejemplo van de 20 a 10), lo cual da como
resultado “pérdida” de grados de libertad (Degrees of Freedom, DF), que tiene el mismo efecto
de incrementar el semiancho del intervalo de confianza. La otra opción disponible, llamada
método t de dos muestras, retiene el tamaño de muestra “completo” (20 en nuestro caso), pero
522 Capítulo 12
requiere que las observaciones de las dos alternativas sean independientes entre sí; esto prohíbe
el uso de CRN así como el método “natural” puesto que utiliza los mismos números aleatorios,
aunque no sincroniza su uso. Si usted está utilizando CRN para su comparación, entonces no
tiene opción, debe usar el método de t por pares. Aun cuando está sufriendo la pérdida de gra-
dos de libertad, la reducción de varianza que usted está obteniendo de los CRN con frecuencia
hace más que compensar tal pérdida, lo que da como resultado un intervalo más ajustado. Si
usted encuentra haciendo muestreo completamente independiente en sus alternativas, podría
utilizar cualquier método. Se hizo un conjunto de diez duplicaciones completamente indepen-
dientes de la alternativa B cambiando las asignaciones de flujo en la tabla 12-2 al sumar 100 a
cada número de flujo para que sean diferentes de los flujos (1-15, excepto para 10) empleadas
en la ejecución. Las semiamplitudes de intervalos de confianza en las diferencias esperadas de
Compare Means (Comparar medias) fueron 4.53 con el método de t por pares y 4.92 con el mé-
todo de t de dos muestras; ambas son válidas, y no hay mucha diferencia entre ellas (se hallan
cerca de lo que se obtuvo de la comparación “natural”), pero incluso no están próximas a ser
tan precisas como el 0.711 que se obtuvo de los CRN sincronizados.
Si bien el atractivo intuitivo de los CRN sincronizados, para “comparar similar con similar”,
es claro, hay también una justificación matemática para la idea. Sean X y Y las variables aleato-
rias de salida para las alternativas A y B, respectivamente. En nuestro ejemplo, X y Y serían los
promedios sobre las diez duplicaciones de los WIP totales promedio en cada duplicación, en las
alternativas A y B. Lo que se desea estimar es E(X) − E(Y) = E(X − Y), y nuestro estimador
puntual (insesgado) de éste es X − Y. Si se toman las ejecuciones de modo independiente, la
varianza de nuestro estimador de muestras independientes es
puesto que, como variables aleatorias, X y Y son independientes. Sin embargo, si se usan CRN
sincronizados, lo que se está haciendo es inducir correlación, con esperanza positiva, entre X y
Y. Puesto que la correlación tiene el mismo signo que la covarianza (véase sección C.2.4 en el
apéndiceVar(
C),Xla–Y
varianza de)nuestro
) = Var(X + Var(Y)estimador de CRN es
que será menor que la varianza del estimador de muestras independientes puesto que se está
restando una covarianza positiva. Así, lo que se necesita para hacer que los CRN “funcionen”
es que los resultados se hallen correlacionados positivamente, y mientras más fuerte sea la
correlación mejor. Mientras el lector pueda hallar ejemplos donde la correlación es negativa,
lo que hace que fallen los CRN, tales modelos son en general patologías artificiales sólo para
poner de manifiesto. En la mayoría de los casos, los CRN funcionarán, algunas veces de forma
espectacular. Sin embargo, es cierto que usted no puede decir cuán bien funcionará esto hasta
que lo hace en realidad. Y, como ya observó, los CRN en su versión fortuita, no sincronizada,
son casi automáticos, así que se tiene que trabajar para evitarlo. Sin embargo, quizá no obten-
drá mucho beneficio a menos que haga algo para sincronizar el uso de números aleatorios en las
alternativas al asignar flujos de números aleatorios de modo cuidadoso y con una comprensión
de cómo funciona su modelo.
modelo 12-1, si se nota que, en una duplicación particular, el promedio de los tiempos entre
llegadas generados de partes es más pequeño que su valor esperado (lo cual se sabría puesto que
se especificó la distribución de tiempo entre llegadas como parte de la entrada del modelo), en-
tonces es probable que estemos viendo medidas de congestión mayores de lo esperado y, por lo
tanto, WIP promedio alto en esta duplicación. Así, se ajustarían estas medidas de salida hacia
abajo por alguna cantidad para “controlar” el hecho de que sabe que nuestras partes estuvieron
llegando más rápido que lo “usual”. De una duplicación a otra, entonces, este ajuste tendería
a disminuir la variación de los resultados en torno a sus expectativas (desconocidas), al reducir
la varianza. En un modelo dado, hay muchas posibles variables de control, y hay distintas for-
mas de seleccionar de entre ellas así como de especificar la dirección y magnitud del ajuste al
resultado de la simulación. Para más información sobre variable de control, véase, por ejemplo,
Bauer y Wilson (1992) o Nelson (1990).
al final de una duplicación, así que esto es necesario. Como resultado, obtendrá por lo general
una semiamplitud que no sólo está bajo la tolerancia que usted especifica, sino quizá incluso
más pequeña debido a esta duplicación extra. Es técnicamente posible (aunque improbable)
que su amplitud final media sea un poco más grande que la tolerancia que usted especifica
si la duplicación “extra”·al final produce un valor atípico, que por sí mismo hace que la es-
timación de la desviación estándar se incremente mucho. Esta situación completa no parece
particularmente onerosa, puesto que en el muestreo secuencial, usted está admitiendo que no
sabe en realidad cuántas duplicaciones hacer y que podría tener que hacer muchas de ellas; así,
pasarse por una no es gran cosa. Además, la tolerancia que usted especifica es probablemente
bastante arbitraria en su mente, así que estar un poco arriba o abajo no importa (sólo un cliente
insoportable demandaría que la persona detrás del mostrador pesará con exactitud la libra de
hummus de ajo que ordenó). El trozo de lógica de control añadida (que se coloca dentro de un
nuevo submodelo llamado Terminating Sequential-Sampling Control Logic) se
muestra en la figura 12-8. Un submodelo en Arena es sólo una forma de abarcar cierta lógica, y
lo que se encuentra dentro de ésta participa por completo en la simulación como si no estuviera
en un submodelo; para abrir un submodelo sólo dé doble clic en él y para cerrarlo, haga clic
con el botón derecho del ratón en un área en blanco dentro del submodelo y seleccione Close
Submodel (Cerrar submodelo) en el emergente, o utilice el panel Navigate en la Project Bar (Ba-
rra de proyecto). Para más información sobre submodelos, vaya a la Ayuda de Arena, pestaña
Index y escriba con el teclado Submodels.
El cuadro de diálogo completo para el módulo Create en este submodelo “control” se mues-
tra en la figura 12-9. Al establecer Max Arrivals (Llegadas máximas) en 1, se asegura que se
estará mostrando sólo una de tales entidades al comienzo de cada duplicación; se establece
también (de modo redundante) el Time Between Arrivals (Tiempo entre llegadas) como una
constante en un millón de horas.
Después que se crea la entidad, ésta pasa al módulo Decide, mostrado en la figura 12-10.
Aquí primero comprueba si el número de duplicaciones, NREP, es menor o igual a 2 (NREP
es el número de la duplicación que comienza). Si es así, puesto que se requieren por lo menos
dos duplicaciones completas para formar un intervalo de confianza, la entidad se elimina por sí
misma (vía la conexión gráfica visible en la figura 12-8), lo que significa que MREP permanece en
NREP <= 2
ORUNHALF (Avg Total Wip) >0.5
La entidad de ¿Continuar Disponer la
control llega al para otra dupli- entidad de
comienzo de cación? control
cada duplicación
De otro modo
Establecer
MREP en
NREP
Figura 12-11. Módulo Assign (Asignar) para lógica de control del muestro
secuencial en simulaciones de terminación
resultado un intento de crear una nueva variable definida por el usuario llamada MREP, que
entraría en conflicto con la variable Arena existente del mismo nombre (y causaría un error).
Se hace un cambio final en el módulo Statistic para eliminar el archivo de salida Avg To-
tal WIP.dat puesto que ya no se necesita guardar estos valores.
Se ejecuta este modelo y se decide parar después de 232 duplicaciones; la parte Especifi-
cada por el usuario (User Specified) del Informe de revisión de categoría (Category Overview
Report) aparece en la figura 12-12, que muestra sólo la parte pertinente. Note que, como se
advirtió, el semiancho del intervalo de confianza para WIP total promedio desciende a 0.5 (del
archivo .out el semiancho es en realidad 0.49699).
¿Por qué el número de duplicaciones requerido 232 (o, si usted prefiere, 231, debido a la
duplicación extra al final) es diferente de las 124 o 164 que sugieren las fórmulas de la sección
6.3? Como se mencionó allí, esas fórmulas son sólo aproximaciones, con errores que se deben al
hecho de que una utiliza la distribución normal y no la distribución t para el valor crítico, pero
principalmente debido al hecho de que ambas se basan en una estimación de varianza de sólo
un número inicial, un poco arbitrario, de duplicaciones (se utilizaron 25). Esta vez resultó que
la estimación de varianza de las 25 duplicaciones iniciales fue en apariencia bastante pequeña,
así que al final se requirieron bastantes duplicaciones más de las que predijeron las fórmulas
(podría haber resultado lo contrario).
El muestreo secuencial, quizá el nombre detención secuencial resulte más apropiado, puede
ser preparado también para otros propósitos. Por ejemplo, en la ejecución anterior, se deman-
daba que el semiancho del intervalo de confianza en sólo una de las (muchas) salidas se hiciera
descender por debajo de la tolerancia especificada 0.5; se hicieron las duplicaciones para sa-
tisfacer ese solo criterio. Sin embargo, la preparación del modelo anterior es suficientemente
general para permitir la fácil modificación a la demanda de que las amplitudes medias en varias
(o todas) las medidas de salida sean “controladas” como menores que las tolerancias separadas
para una de ellas; se le pedirá que examine esto en los ejercicios 12-3 y 12-5.
Otra modificación sería pedir no que el semiancho se hiciera más pequeño que una toleran-
cia, sino más bien que el semiancho dividida entre la estimación puntual (el promedio en las
duplicaciones) fuera reducida a ser menos que otra clase de tolerancia. Note que el semiancho
dividido entre el punto de estimación es una cantidad adimensional y, por lo tanto, en este caso
la tolerancia sería también adimensional, dándole una interpretación emocional universal. Por
ejemplo, si usted especifica esta tolerancia como 0.10, lo que está pidiendo es que el semiancho
del intervalo de confianza no sea más de 10% del promedio, en este caso, usted podría establecer
de nuevo el intervalo de confianza como algo como “estimación puntual más o menos 10%”.
Esto se llama a veces intervalo de confianza con una precisión relativa de 10%. Tal objetivo
podría ser útil en una situación donde usted no tiene mucha idea de lo que será la magnitud de
sus resultados, lo cual hace problemático especificar un valor sensible (absoluto) bajo el que a
usted le gustaría cayera el semiancho. En los ejercicios 12-4 y 12-5 se le pide preparar este tipo
de cuestión. Una precaución aquí, si el valor esperado que se estima es cero (o en cierto sentido
cercano a él) o la estimación puntual de este valor esperado es cero o cercano a él, usted puede
verse en dificultades al dividir entre un número que es cercano a cero, lo cual crea inestabilidad;
en tal caso, sería claramente mejor no usar un criterio de detención de precisión relativa (véase
el ejercicio 12-6).
Figura 12-13. Cuadro de diálogo de Run > Setup > Replication Parameters (Ejecutar >
Configurar > Parámetros de Réplica) para el muestreo secuencial en la simulación de estado
estable usando los intervalos de confianza automáticos de medias de lote
grande y conveniente para examinar muchas cosas e investigar los efectos de varias entradas y
configuraciones en numerosas salidas. Así, la simulación es la elección lógica para la aplicación
de algunas de las técnicas de diseño experimental clásicas presentadas por lo común para expe-
rimentos físicos en vez de los basados en la simulación.
Por ejemplo, considere un modelo con cinco parámetros o configuraciones de entrada di-
ferentes. A usted le gustaría saber cuál es el efecto en los resultados de cambiar un parámetro
o configuración de un nivel a otro. Al ver las entradas o configuraciones como factores expe-
rimentales, usted podría especificar dos niveles posibles para cada uno y realizar un diseño
factorial 25, del cual podría medir los efectos principales y posibles interacciones entre los fac-
tores de entrada en las salidas de interés, que son las respuestas para este experimento basado
en la simulación. A diferencia de la mayor parte de los experimentos físicos, el lector podría
entonces continuar fácilmente y duplicar todo el experimento factorial para colocar intervalos
de confianza alrededor de los efectos e interacciones principales esperadas. Otras posibilidades
incluyen utilizar números aleatorios comunes en los puntos de diseño (como una variable de
bloque en la terminología del diseño experimental), el uso de diseños de selección para decidir
cuáles de muchos factores son importantes en realidad y diseños de superficie de respuesta y
no lineales complejos. Para más detalles sobre estos temas y otros relacionados, véase Law y
Kelton (2000).
12.7 Ejercicios
12-1 Modifique el modelo 12-2 para una forma diferente de asignar números aleatorios a la
sincronización de soporte para CRN, como sigue. Cuando llega una nueva parte, pregenere y
guarde en los atributos de esta entidad sus requisitos de tiempo de procesamiento para todas
las celdas de su secuencia. Cuando una entidad parcial llega a una celda, tome su tiempo de
procesamiento del atributo apropiado de la entidad en vez de generarlo en el acto. Dependiendo
de cómo prepara esto, podría ser útil recordar que el atributo Entity.JobStep de una entidad
es su número de estación (1, 2, 3,...) cuando hace su recorrido por la secuencia. Usted podría
encontrar útil el elemento Attributes del panel Elements para definir un atributo con valores
vectoriales; para asignar valores a los elementos de este vector en un módulo Assign, necesitará
elegir que el Tipo sea Otro (Type to be Other). Use la misma asignación de flujo de números
aleatorios del modelo 12-1.
12-2 En el ejercicio 12-1, ¿es necesario haber dedicado los flujos de números aleatorios en
orden para lograr la sincronización adecuada? Analice esta cuestión, experimentando con al-
gunos ejemplos si es apropiado.
12-3 Modifique el modelo 12-3 de la sección 12.5.1 para demandar, además de que el semian-
cho del intervalo de confianza en el WIP total promedio esperado no sea más que 0.5, que el
semiancho de los intervalos de confianza de 95% en el tiempo total promedio esperado en el
sistema (para todos los tipos parciales combinados) no sea más de 4 minutos. Una manera de
hacer esto es modificar el módulo Decide en la figura 12-10 añadiendo una condición adicio-
nal para seguir con la duplicación (es decir, eliminar la entidad de comprobación) si alguna
semiamplitud es todavía demasiado grande.
12-4 Modifique el modelo 12-3 de la sección 12.5.1 para demandar en cambio que la relación
del semiancho del intervalo de confianza de 95% para la estimación puntual en el WIP total
promedio esperado sea menor que 0.05, como se describe al final de la sección 12.5.1; es decir,
forme un intervalo de confianza de precisión relativa de 5%. La variable de Arena ORUNAVG
(Output ID) es el promedio en las duplicaciones completas de la medida de salida con esta
Output ID (Identificación de salida).
12-5 Combine los ejercicios 12-3 y 12-4 como sigue. Prepare una ejecución de muestreo se-
cuencial de modo que obtenga intervalos de confianza de precisión relativa de 5% en el WIP
total promedio esperado así como en el tiempo total esperado en el sistema.
12.6 Modifique el modelo 12-4 de la sección 12.5.2 para determinar la duplicación cuando
la relación del semiancho al punto medio (estimación puntual) del intervalo de confianza auto-
mático en tiempo de ejecución de medias de lote en el WIP total esperado de estado estable cae
abajo de 0.05; es decir, cuando la precisión relativa es 5%. La variable de Arena DAVG(Dsta
ID) devuelve el promedio actual de la estadística Dstat indicada (es decir, persistente con el
tiempo). Note que la condición que se desea comprobar es de la forma H/A < 0.05, donde H
es el semiancho y A es la estimación puntual, que puede ser un cálculo incómodo si A = 0 (que
Cuestiones estadísticas adicionales 533
Por lo tanto, ¿cuáles son las lecciones a aprender? Primero, que el equipo de simulación tenía
que haber reconocido que los tiempos de operación para el nuevo sistema sólo eran estimados
y deberían haber realizado un análisis sensible de los resultados del modelo ante tales datos
de entrada. Esto hubiera predicho un problema potencial si los tiempos reales eran mayores
que los estimados proporcionados por el vendedor. Si los tiempos eran críticos, podría haberse
incluido en el contrato una cláusula de castigo para el nuevo equipamiento que estipulara que
éste se desarrollaría como se estimó. Segundo, el equipo de simulación debió haber seguido
monitoreando la implementación del nuevo sistema. Lo que les habría permitido evaluar las
modificaciones propuestas antes de su implementación. Eso no habría cambiado los resultados,
pero al menos los habría predicho.
Regresemos al tema inicial de lo que define un proyecto de simulación exitoso. Éxito rara vez
significa que se desarrolló un buen modelo de simulación. Con más frecuencia significa que el
estudio de simulación satisfizo los objetivos establecidos por los tomadores de decisiones. Eso
implica que es muy importante entender qué métricas se usarán.
Si se le pide llevar a cabo un estudio de simulación para rediseñar un sistema actual, infór-
mese más para entender mejor qué se espera de ello. Si esa información resulta en una decla-
ración que indica que la administración está interesada en descubrir si es posible hacer que el
sistema se desempeñe mejor, descubra qué significa para ellos “mejor”. Si “mejor” quiere decir
que se espera que se reduzca el WIP (work in process [trabajo en proceso]) en un 30%, los tiem-
pos de ciclo en 20%, que aumente el uso del recurso en un 15% y que se satisfagan todas las fu-
turas fechas límite de los clientes sin inversión de capital, al menos sabrá que enfrenta una tarea
imposible. Le recomendamos que elija no aceptar la misión. Sin embargo, si “mejor” significa
que las mediciones primarias de WIP, los tiempos de ciclo, el uso del recurso y las fechas de
vencimiento de los clientes estén equilibradas frente a la inversión de capital, al menos el lector
tendrá una oportunidad de diseñar un mejor sistema.
Por desgracia, rara vez se le va a preguntar si quiere hacer el estudio; en la mayoría de los
casos, simplemente se le dice que lo haga. Aun bajo estas circunstancias, debería identificar a
quien toma las decisiones e intentar definir las métricas con las que se medirá el proyecto.
Si está por emprender su primer estudio de simulación para una empresa o instalación, es
esencial que tenga éxito. Si el primer estudio de simulación se etiqueta como fracaso, es muy
poco probable que comience alguna vez un segundo estudio. Si tiene la oportunidad de elegir
entre varios proyectos de simulación, seleccione uno que sea sencillo y que casi sea seguro que
termine exitosamente. Una vez que alcance varios aciertos, podrá permitirse el lujo de un fra-
caso (pero no de un desastre).
También existe un dilema peculiar al que frecuentemente se enfrenta un analista de simu-
lación experimentado. Si se utiliza la simulación como una herramienta estándar a través del
diseño de un nuevo sistema y este nuevo sistema funciona como se anunció, ¿qué es lo que se
rescata? Si no se hubiera usado la simulación, ¿se habrían diferenciado en algo los resultados?
En realidad no se sabe. Así que la herramienta funcionó, o al menos el lector así lo piensa, pero
no tiene forma de cuantificar ningún ahorro resultante de la aplicación de la herramienta.
El enfoque que se sugiere con frecuencia, pero que rara vez se usa, es no emplear la simula-
ción para el diseño del siguiente sistema nuevo. La suposición aquí es que el sistema resultante
no se desempeñará como se anunció. Después de que está claro que el sistema tiene problemas,
eche mano de la simulación para mostrar cómo debió haberse diseñado el sistema. Esto le per-
mitirá cuantificar los ahorros si hubiera usado la simulación. Es claro que éste es un enfoque
extremo —y que nosotros no recomendamos— que se basa en muchas suposiciones. Por su-
538 Capítulo 13
puesto, siempre existe la posibilidad de que el sistema se desempeñe bien. (¡Eso puede suceder!)
Ello haría el valor de la simulación aún más dudoso a los ojos del administrador.
Cerramos esta sección sugiriéndole de nuevo que esté consciente de que su definición de
éxito puede no ser la misma que la de la gerencia. Aunque no pueda controlar la evaluación
de ésta, al menos debería intentar entender qué medidas usarán al hacer su evaluación. Ahora
procedamos con nuestro análisis de las actividades clave de un buen estudio de simulación.
cliente está interesado en asegurarse de que cualquiera que entre por la puerta reciba su comida
dentro de un periodo dado de tiempo. Esto es más parecido no a una métrica de desempeño,
sino a un objetivo de desempeño. Otras métricas de interés podrían ser el personal requerido,
las asignaciones de trabajo, la capacidad para sentarse y la frescura de la comida.
Una vez establecida la forma de medir el desempeño del sistema, averigüe si existen valores
iniciales actuales para tales métricas. Estos valores deberían hallarse disponibles si el sistema
existe en la actualidad. Si no, puede que haya sistemas similares existentes que podrían usarse
para proporcionar estimados. En el peor de los casos, por lo menos debería haber disponibles
valores de diseño. Sabiendo cuáles son las métricas iniciales (o al menos usando un estimado),
¿cuáles serán las expectativas del cliente? Este tipo de información debería proporcionar alguna
perspectiva como la magnitud del problema que se le entregó.
Para ese momento, el lector ya debería comprender muy bien el sistema (y su tamaño), las
métricas del desempeño y las expectativas del cliente. El siguiente paso es seleccionar una me-
todología de solución: no suponga que siempre usará la simulación.
empleado este enfoque incluyen líneas de ensamblaje, almacenamiento, comida rápida, centros
de distribución, centros de asistencia telefónica y células de fabricación. Un enfoque aún más
elegante se basa en el desarrollo de una plantilla especificada por la empresa. Dicho método se
analizó brevemente en la sección 10.5.5.
Supongamos que la simulación es la técnica correcta para el problema. Ahora hay que defi-
nir el sistema y los detalles de la simulación resultante.
Si el sistema es un diseño nuevo, averigüe si existen sistemas similares que pueda visitar.
Como mínimo, usted entenderá mejor el proceso completo que va a simular. Si el sistema sólo
existe en el papel, consulte el anteproyecto. Si no hay nada esbozado, desarrolle un diagrama de
flujo del proceso o un bosquejo aproximado del sistema potencial. Se debería hacer esto con el
cliente de manera que haya un total acuerdo en las especificaciones del sistema.
Una vez entendido el sistema a modelar, ahora es tiempo de juntar a todas las partes intere-
sadas en un salón de conferencias y desarrollar sus especificaciones. No existe una fórmula má-
gica para tales especificaciones, pero generalmente debería contener los siguientes elementos:
< Objetivos de la simulación.
< Descripción del sistema y enfoque de modelado.
< Exactitud en la animación.
< Entradas y salidas del modelo.
< Formas de entrega del proyecto.
El tiempo requerido para obtener toda la información necesaria puede variar entre una hora
y unos días. Los análisis que producen los detalles de estas especificaciones deberían incluir a
todas las partes interesadas. En la mayoría de los casos, los análisis se enfocan en el sistema más
que en la simulación, porque en este punto es la única base común. Los tipos de preguntas que
deberían formularse, y contestarse, son las siguientes:
< ¿Qué se incluirá en el modelo de simulación?
< ¿Qué nivel de detalle debería incluirse?
< ¿Cuáles son las fuentes primarias del sistema?
< ¿Qué tareas u operaciones pueden ellas desempeñar?
< ¿Hay disponibles planes del proceso o diagramas de flujo del proceso?
¿Están actualizados?
¿Siempre se siguen?
¿Bajo qué condiciones no se observan?
< ¿Existen restricciones físicas, tecnológicas o legales en cuanto a la forma de operar del
sistema?
¿Se pueden cambiar?
< ¿Existen procedimientos del sistema definidos?
¿Se observan?
¿Pueden considerarse nuevos procedimientos?
< ¿Cómo se toman las decisiones?
¿Existe alguna excepción?
< ¿Hay datos disponibles?
< ¿Quién recopilará o reunirá los datos?
¿Cuándo estarán disponibles?
¿En qué formato lo estarán?
¿Qué tan precisos son los datos?
¿Cambiarán? Y si así es, ¿cómo cambiarían?
< ¿Quién proporcionará los estimados de datos si éstos no se encuentran disponibles?
¿Qué tan precisos deberán ser?
¿Requerirán que se lleve a cabo un análisis de sensibilidad?
542 Capítulo 13
dos. Por último, puede ser aconsejable identificar la forma en la que se entregarán los datos, así
como quién es el responsable de recopilarlos, juntarlos u observarlos. Para un análisis sobre el
tema de datos, véase la sección 4.6.2.
Antes de retirarse de esta reunión, debe identificar a una persona del equipo de clientes que
le servirá como contacto principal durante el estudio. Cuando regrese a su oficina, tendrá que
organizar la información en un documento que se parezca a una especificación. Le recomen-
damos que lo haga tan pronto como sea posible, mientras que los detalles estén todavía frescos
en su mente. Aun entonces sin duda se encontrará estrujándose la cabeza ante al menos uno
de los temas en sus notas. Algo que estaba muy claro durante la reunión puede parecer ahora
confuso. ¡No hay problema! Busque el teléfono, fax, dirección de correo electrónico y aclárelo
con su contacto principal.
Una vez que haya desarrollado este documento, debería enviárselo al cliente para su revisión.
Pueden ocurrir varias iteraciones antes de que surja el documento final con el que concuerden
ambas partes. Una vez terminado, le recomendamos que aquéllas firmen este documento final.
Si, durante el estudio de simulación, encuentra que las condiciones cambian, los datos no están
disponibles, etc., puede que sea necesario revisar dicho documento.
Nos encantaría poder proporcionarle un conjunto de instrucciones detalladas en cuanto a
cómo llevar a cabo toda esta tarea. Por desgracia, cada estudio de simulación es diferente y las
circunstancias son las que en verdad dictan la cantidad de detalles que se requieren. Sin em-
bargo, podemos darle una idea de cómo luce una especificación. Fuimos afortunados, ya que
The Washington Post nos permitió incluir una especificación funcional para un estudio de
simulación (véase el apéndice A), que se desarrolló como parte de un proyecto realizado a
mediados de la década de 1990 por el grupo de consultoría Systems Modeling. Las espe-
cificaciones originales las desarrolló Scott Miller, un consultor de Systems Modeling, para
Gary Lucke y Olivier Girod del The Washington Post. Con excepción de unos pocos cambios
menores, hechos por razones de confidencialidad y de formato, se trata del documento original.
Le insistimos que se tome el tiempo de leerlo antes de llevar a cabo su primera especificación. Le
sugerimos no usar este formato para todas sus especificaciones, aunque le podría proporcionar
un excelente punto de inicio.
Durante todo este análisis, supusimos que es viable definir el estudio completo antes de em-
pezar a construir el modelo real. Pero hay circunstancias en donde no es posible. Estos tipos de
proyectos son de terminación abierta, en los que el proyecto completo no está todavía definido
o su dirección depende de los resultados obtenidos en las primeras fases. Aun cuando no pueda
ser posible especificar por completo todo el proyecto, a menudo es deseable el desarrollo de una
especificación. Por supuesto, eso significa que tal vez deba corregir o expandir la especificación
frecuentemente. Siempre que ambas partes se encuentren de acuerdo, no hay razón para evitar
estos tipos de proyectos. Sólo debe hallarse dispuesto a aceptar el hecho de que la dirección del
proyecto puede cambiar de forma drástica durante el tiempo que dure. Con frecuencia tales si-
tuaciones se llaman proyectos de espiral en cuanto a que tienden a subir vertiginosamente hasta
tener grandes proyectos o bajar rápidamente hasta no poseer ninguno.
Por ahora, supongamos que especificó la simulación y que por fin es tiempo de comenzar
el modelo.
544 Capítulo 13
sistema de ensamblaje complicado, que usaba una serie de transportadores elevados de ener-
gía hidráulica y libre para mover el montaje por todo el sistema (esto sucedió hace ya algunos
años). Unos dos días antes de entregar el modelo al cliente, desarrolló un virus. El consultor
afirmó que éste fue ocasionado por seres extraterrestres, pero sospechamos que sencillamente
fue un error de modelado. Después de dos largas noches sin dormir (acompañado por consejos
libremente ofrecidos de otros consultores) se descubrió el error. Se añadió una rápida compos-
tura al usar una serie de módulos Signal (Señal) y Hold (Esperar) (véase la sección 9.4) para
sincronizar la fusión de transportadores subensamblados, que resolvió el problema. El modelo
se entregó al cliente y al final el estudio fue un éxito.
Lo que es interesante acerca de esta experiencia extraterrestre es que durante los siguientes
años, cada modelo (y nos referimos a cada modelo) que creó el consultor tuvo al menos un par
de módulos Signal y Hold. Este hábito no dio como resultado modelos incorrectos, sino que
con frecuencia eran formas más sencillas y directas de modelar las características del sistema.
El consultor ha dejado de ser creativo en la construcción de sus modelos y siempre emplea esas
construcciones que salvaron su carrera en aquella fatídica noche. Esencialmente, había desarro-
llado un mal hábito, que, a propósito, fue muy difícil de romper.
Otro ejemplo que recordamos ocurrió aproximadamente en la época en que el sistema Are-
na se introdujo por primera vez. Antes de esos tiempos, los consultores en Systems Modeling
desarrollaban todos sus modelos de simulación usando el lenguaje SIMAN. Esto requería la
creación de dos archivos por separado, los archivos del experimento y del modelo (véase la
sección 7.1.6). Aunque había programas disponibles para ayudar a realizar tales archivos, casi
todos los consultores desarrollaban sus modelos en un editor de textos. Una vez que ejecutaban
sus modelos, creaban la animación de éstos por separado usando el software Cinema. Con el
lanzamiento del sistema Arena se pudo desarrollar todo un modelo, incluyendo la animación,
en un archivo que usaba el método seleccionar y hacer clic con el que el lector está ahora fa-
miliarizado. Los consultores se sentían muy cómodos con sus editores de texto y fueron muy
reacios a cambiar su método de modelado. De hecho, llegaron hasta a intentar convencer a los
clientes de que la vieja forma de hacerlo era la mejor.
Por último, se transmitió algo semejante a un edicto en el que se señalaba: “¡Usted usará
el nuevo sistema Arena para todos los modelos futuros!” Hubo muchos refunfuños y quejas,
pero en muy poco tiempo todos estuvieron trabajando con el nuevo software. De hecho, mucho
antes de que se comenzaran a escuchar comentarios tales como, “¿cómo podíamos hacer esto
antes de Arena?” Por supuesto, años más tarde, un individuo aún reclamaba que era más fácil
desarrollar modelos en un editor de textos. Hemos omitido los nombres para proteger a los
cándidos, o a los no tan inocentes.
Así que recomendamos que tenga la mente abierta acerca de los métodos que usa para
construir modelos y las construcciones que elige usar. Si hay más modeladores en su grupo, pre-
gúnteles cómo enfocarían un nuevo modelo. También debería considerar asistir a conferencias
o encuentros de grupos de usuarios para averiguar qué es lo que hacen sus colegas.
Con la anotación de esta última precaución, puede comenzar a construir su modelo. Si éste
es pequeño, debería colocar todos los módulos que se necesiten, llenar los datos requeridos y es-
perar que funcione de forma correcta a la primera. (Rara vez sucederá.) Si el sistema a modelar
requiere de un modelo grande y complicado, puede intentar dividir la construcción del modelo
en fases. Seleccione una parte del sistema y construya un modelo para esa parte, incluyendo
546 Capítulo 13
al menos una animación aproximada. Una vez que se encuentre convencido de que funciona
correctamente, añada la siguiente fase. Continúe de esta manera hasta que haya creado todo
el modelo. Tal enfoque hace que la verificación del modelo (nuestro siguiente tema) sea mucho
más fácil.
Una vez que este grupo le dé sus bendiciones, debería intentar un experimento más antes de
pronunciar la verificación de su modelo. Pregúntele al grupo si le gustaría cambiar el modelo de
alguna forma. Los individuos que se hallen familiarizados con el sistema, pero no con la simu-
lación, tienden a pensar de forma diferente. Puede que sólo le sugieran algunas modificaciones
que nunca consideró.
Antes de mostrar su modelo al grupo de clientes, debería darle cierta consideración al nivel
de detalle requerido en la animación. En la mayoría de los casos, es suficiente una animación
aproximada que muestre las actividades básicas. Tal vez deba describir lo que muestra su ani-
mación, pero una vez que los individuos vayan más allá de las bonitas imágenes, con frecuencia
podrán visualizar su sistema. Al mismo tiempo, permanezca sensible a la retroalimentación
proporcionada por los miembros del grupo cuando vean la animación por primera vez. Podría
sorprenderse de los tipos de reacciones que obtenga. Hemos visto individuos incapaces de ir
más allá del hecho de que las máquinas del modelo son azules y las de ellos son verdes. Si el lec-
tor detecta este tipo de comentarios, tómese el tiempo para hacer algunos cambios. Finalmente,
usted desea que el grupo de clientes acepte su modelo como una representación exacta de su
sistema. Si tiene suerte, ellos se convertirán en sus partidarios más fuertes conforme proceda
con el proyecto.
En este punto, probablemente debamos admitir que es casi imposible verificar un modelo
por completo para un sistema complejo. Hemos visto modelos verificados, que ya han sido
usados para un análisis extensivo, producir de repente resultados defectuosos. Por lo general,
esto es ocasionado por una combinación única de circunstancias que originalmente nunca se
consideraron impuestas al modelo. Por desgracia, al menos tiene que considerar que todo su
análisis previo puede estar incorrecto. También deberíamos señalar que no existe la magia para
la verificación, ni tampoco un solo método aceptado por todos. La clave es que el lector y su
cliente se convenzan por completo de que el modelo funciona en la forma en la que se pensó.
Una vez logrado esto, ahora está listo para considerar validar el modelo. Aunque estamos tra-
tando la verificación y la validación como dos temas o tareas separadas, la diferencia entre las
dos a menudo es difusa.
Con la finalidad de validar un modelo de simulación, debería comparar los resultados de
su modelo con los resultados del sistema real. Si el sistema aún no existe, usted se encuentra
en problemas desde antes de comenzar. Incluso si el sistema existe, tal comparación puede ser
una tarea difícil. Es muy común que las organizaciones mantengan métricas exhaustivas del
desempeño pasado del sistema, pero a menudo no guardan la información que le diga qué es lo
que el sistema hacía o a lo que estaba sujeto durante ese periodo pasado de tiempo. Incluso si
los datos existen, pueden ser incorrectos o engañosos.
Hace años, hubo un modelo de simulación grande y complejo que se desarrolló para una
instalación que producía transmisiones de servicio pesado. La instalación tenía aproximada-
mente 1 400 máquinas y recursos agrupados en unos 30 departamentos. El modelo se desarrolló
para determinar la sensibilidad de una mezcla de productos en el rendimiento total y el efecto
potencial de introducir una nueva línea de productos en el sistema. Todas las medidas de des-
empeño primarias estaban relacionadas con la capacidad del sistema. La totalidad de los planes
y los tiempos de proceso fueron descargados de las bases de datos de la instalación. Además,
estaban disponibles todas las emisiones de órdenes del último año de producción. Parecía como
si validar el modelo fuera una tarea fácil. Una vez verificado el modelo, se llevaba a cabo la
validación.
548 Capítulo 13
quier análisis, se diseñaría un conjunto completo de los experimentos que se tratan de realizar.
También decidiría los tipos de herramientas de análisis que emplearía. Aunque esto debiera
ser ideal, se halla muy lejos de la realidad. En algunos casos, simplemente no se tiene el lujo de
contar con el tiempo suficiente; en otros, en verdad no se sabe hacia dónde se va con el análisis
hasta que se llega ahí.
Por ejemplo, si su objetivo es mejorar el desempeño del sistema, puede no saber qué cambios
se requieren para lograr tal meta. A veces el mejor método de análisis es un grupo de eruditos
sentados alrededor de una computadora sugiriendo y probando alternativas. Por lo general
esto significa que casi todas las alternativas que se investigaron serán, por lo menos, viables. Un
problema con dicho tipo de enfoque es que puede sentirse tentado a recortar drásticamente los
tiempos de ejecución con la finalidad de reducir el tiempo que debe esperar para el siguiente
conjunto de resultados. O peor aún, quizá quiera evaluar el sistema con base sólo en una vista
de la animación. No ceda a tal presión ya que lo puede conducir a un desastre (y los desastres
pueden alterar la dirección de su carrera).
También podría considerar estructurar su experimentación con base en el tipo de análisis
que tiene que llevarse a cabo. Por el bien de este análisis, identifiquemos tres diferentes tipos de
análisis: de candidato, comparativo y predictivo.
Por lo general el análisis de candidato se hace durante las primeras fases del diseño de un
sistema. Generalmente se intenta identificar los mejores sistemas de candidato a partir de un
grupo mucho más grande de diseños potenciales que ameritan un estudio adicional. Los mode-
los para estos tipos de análisis por lo general carecen de detalle. Se puede pensar en tales mo-
delos como unos de capacidad tosca. Se intenta eliminar a los perdedores obvios e identificar
a los ganadores potenciales. Cuando se lleva a cabo dicho tipo de análisis, no se puede poner
mucha fe en la precisión del desempeño real del sistema. Todavía hay que asegurarse de tener un
número suficiente de réplicas para proporcionar buenos estimados del desempeño del sistema
(o de que los tiempos de la ejecución son lo suficientemente largos), pero aún existe muy poco
valor en aumentar el número de réplicas (o el tiempo de ejecución) para obtener unos límites de
confianza más cercanos a sus resultados.
El análisis comparativo normalmente sería el siguiente paso lógico al momento de seleccio-
nar el diseño de sistema final. Se tiene un conjunto finito de diseños y se desea compararlos
para identificar al mejor. Este tipo de análisis requiere por lo general un modelo más detalla-
do, pero sólo nos preocupa la comparación de un sistema con otro. Por ejemplo, puede haber
actividades del sistema que afectarán el desempeño del mismo, pero la magnitud del efecto es
común entre los sistemas bajo consideración. Por ejemplo, puede no ser necesario incorporar
un mantenimiento preventivo u horarios de los operadores en estos tipos de modelos. Las acti-
vidades que son comunes en todos los sistemas bajo consideración y que tienen el mismo efecto
no deben ser incluidas en los modelos. Para este tipo de sistemas, puede haber un valor en el
aumento de los tiempos de ejecución (o en el número de réplicas) para estimular su confianza al
momento de seleccionar el mejor sistema.
El análisis predictivo por lo general trata sólo con unos pocos sistemas; a menudo sólo con
uno. Para ese momento, seleccionó lo que parece ser el mejor sistema y ahora se encuentra in-
teresado en estimar el desempeño real del mismo. Este tipo de análisis requiere que se incluyan
todas las actividades que afectarán la habilidad del sistema para lograr el desempeño predicho.
En tal punto, seleccionó el mejor y seguirá con la recomendación de construirlo, siempre que
satisfaga los objetivos que se requieren. Estos tipos de modelos tienen que ser bastante detalla-
dos y también hay que confiar en los datos que se estén utilizando.
550 Capítulo 13
Sin importar el tipo de análisis que se realice, sea cuidadoso con no formar juicios fuertes
con base en la información limitada. Asegúrese de que sus resultados se basan en una sólida
práctica estadística y cuando concluya que un sistema es mejor que otro, constate que existe
una diferencia estadística entre ellos. Encontrará más detalles sobre tales temas en las secciones
6.4-6.6 y 12.4-12.6.
Antes de continuar, consideramos necesario señalar de nuevo que las actividades que cons-
tituyen un proyecto de simulación parecen seguir un patrón lógico de tiempo. En realidad, es
muy común retroceder y avanzar entre las actividades, a menudo volver a visitar las que se
pensaba estaban completadas. En la práctica, con frecuencia se descubre que un buen proyecto
obliga a pasar por varias iteraciones de dichas actividades.
cubierto la mayoría de las bases. Una alternativa es usar los métodos descritos en el capítulo 10
para incrustar estos temas directamente en el archivo de simulación.
También debe admitir que en la mayoría de los casos alguien más empleará la documenta-
ción, si es que se usa. Los individuos ascienden, cambian de posiciones o se mudan de organi-
zaciones, así que su mejor enfoque ante esta tarea es preguntarse qué es lo que desearía o nece-
sitaría saber si alguien más hubiera llevado a cabo el estudio original. Esto puede no servirle de
gran ayuda, pero la siguiente persona de seguro se lo agradecerá.
A.1 Introducción
Este apéndice contiene material de especificación funcional proporcionado a The Washington
Post como parte de un proyecto de consultoría de modelado de simulación de Systems Mode-
ling (a mediados de la década de 1990, que fue anterior a su adquisición por Rockwell Automa-
tion). El proyecto se entregó a Gary Lucke, gerente de ingeniería en sistemas de manufactura,
y a Olivier Girod, gerente de ingeniería industrial de The Washington Post. Este archivo ha
sido modificado ligeramente para retener la confidencialidad de cierta información de patentes.
Parte de la tecnología aparecerá fechada, pero dejamos la forma original del tiempo de este
proyecto porque el proceso no se ve afectado con ello.
tados generados por la simulación AGV Roll Delivery actualmente bajo desarrollo en Systems
Modeling (SM), un proveedor de manejo de material, y en el periódico.
El desarrollo de este modelo requiere una serie de tareas. Para empezar, es necesaria una
comprensión minuciosa de las instalaciones de Springfield y Maryland del periódico para
conceptualizar y desarrollar una representación precisa del sistema. Este proceso ha sido, y
continuará siendo, un esfuerzo conjunto entre The Washington Post y Systems Modeling. Tal
procedimiento define la conceptualización que el usuario hace del sistema que SM usará para
desarrollar el modelo de simulación de Arena. Se incluye en este proceso la definición de las
entradas y salidas del modelo, la verificación de que el modelo de Arena se ha implementado
de forma precisa y la validación de que el modelo representa la instalación también de forma
precisa.
Una vez terminado el proyecto, el periódico tendrá una herramienta que permitirá a un
analista especificar varios escenarios de operaciones para la instalación del departamento de
correspondencia, ejecutar los experimentos de simulación de los escenarios y llevar a cabo aná-
lisis estadísticos de los mismos.
A.2.2 Rotativas
Las rotativas serán el punto de partida dentro del modelo de simulación. El producto generado
por una rotativa se envía a una apiladora en donde se ata y después se remite al sistema de ban-
dejas. Ni las rotativas ni las apiladoras se modelarán en detalle para este proyecto. El producto
de las rotativas se elabora en cada una de las cuatro rotativas idénticas a una tasa de impresión
constante durante las operaciones normales. Suponiendo una constante (el tamaño del atado
de diarios definido por el usuario en la apiladora), los atados de diarios se modelarán entrando
al sistema a una tasa constante para cada rotativa. La tasa de producción para cada rotativa se
definirá en una base por hora sobre el horizonte de tiempo de una semana. La mayor parte del
tiempo, las ejecuciones de las rotativas deberían comenzar entre las 12:15 a.m. y las 12:30 a.m.
y terminar entre las 4:30 p.m. y las 4:40 p.m.
Al término del proyecto de simulación de AGV Roll Delivery, se añadirá la lógica de tal ma-
nera que la simulación AGV genere un programa de rotativas que incluya todos los tiempos de
funcionamiento y de falla para cada una de ellas. Estos programas de rotativas pueden usarse
después como archivos de entrada para la simulación del departamento de correspondencia.
La simulación de dicho departamento se diseñará de tal manera que el analista pueda elegir
emplear ya sea 1) los programas de salida de las rotativas de “ejecución tardía” generados en la
556 Apéndice A
simulación de AGV, o 2) los parámetros de las rotativas definidos por el usuario y las distribu-
ciones de tiempos de falla de las rotativas. Ambas opciones se describen a continuación.
A.2.2.3 Relaminado
Para cada rotativa, el relaminado ocurrirá de acuerdo con el programa definido por el usuario y
sus tiempos sin funcionamiento asociados se modelarán con el uso de una distribución con base
Tabla A-3. Tiempo sin funcionar inducido por el relaminado y definido por el usuario
se les dará a los atados de diarios un destino final (puertos de embarque [dock] o entarimador
[paletizer*]) con base en la tasa de viaje de las bandejas y los camiones que esperan actualmente
por el producto.
* Nota: Paletizador no existe como término en español, sin embargo se refiere a consolidar los diarios en tarimas de
determinado tamaño y peso para su transporte en volumen, por lo que se utlizará “entarimador” como traducción.
Una especificación funcional para The Washington Post 559
A.2.6.2 Autopista
Los camiones para autopista (highway, HWY, por sus siglas en inglés) se atienden en puertos
de autopista dedicados. Entarimadores completos de producto de avance se cargan en ellos con
montacargas. El usuario define la tasa de carga en tarimas por minuto y el tiempo para envol-
ver (para la última tarima) en minutos. El producto de encabezados destinado a los camiones
de autopista se envía al entarimador dedicado a ese camión HWY. Las tarimas se forman y des-
pués se cargan en camiones mediante montacargas. La tasa de carga y el tiempo para envolver
son los mismos que para las tarimas de avance. Además, existe un tiempo de cambio de puerto
entre camiones. Un camión HWY permanece en un puerto hasta que hayan sido cargados to-
dos los productos de avance y encabezados.
A.2.7 Puertos
En el modelo, existen tres tipos de puertos: 1) entarimado, 2) atado de diarios de avance y 3)
atado de diarios de encabezados. Los puertos de entarimado se diseñaron para un acceso a
los montacargas y para el servicio de los camiones HWY. Los puertos de atados de diarios de
avance se emplean para cargar el producto de avance en los camiones durante el periodo de
560 Apéndice A
rendimiento (n − 1). Los puertos de atados de diarios de encabezados se usan para cargar este
tipo de producto entregado a los camiones a través del sistema de bandejas. Un camión recibe el
producto de las rotativas según su tiempo de llegada (FIFO) a un área determinada del puerto
y no en su ubicación del puerto. Para cada tipo de puerto, el número de puertos activos será
definido por el usuario.
A.2.8 Entarimadores
Para los propósitos de la simulación, todas las tarimas se suponen idénticas. Una tarima se em-
plea para empacar atados de diarios de encabezados destinados al camión HWY en un puerto
de paletizado. Cada camión HWY en un puerto tiene dedicado. Para los propósitos del modelo,
una tarima actúa como un destino posible para los atados de diarios en el sistema de bande-
jas. La transportación del producto de avance en las tarimas no se modelará en este proyecto.
Los entarimadores operan a una tasa constante y forman tarimas de un tamaño constante. La
última tarima cargada será una tarima parcial con el suficiente producto que se necesite para
terminar la carga. La razón de entarimado y el tamaño de la tarima los define el usuario. Las
entarimadoras experimentan varios tiempos sin funcionamiento a intervalos aleatorios. Estos
tiempos sin funcionamiento pueden ya sea modelarse como tiempos sin funcionamiento al
combinar todos los modos de falla, o modelar cada modo de falla individual por separado.
Si un atado de diarios que llega a un entarimador debe esperar porque el equipo está ocupa-
do o no funciona, se acumulará en una cola. La capacidad de las colas de las tarimas se definirá
por el usuario. Si la cola en un entarimador alcanza el límite definido por el usuario, cualquier
atado de diarios adicional que llegue a ese entarimador será rechazado. Los atados de diarios
rechazados volverán a circular en el transportador de bandejas e intentarán salir al mismo en-
tarimador en el siguiente circuito.
Cada trabajador puede insertar 500 copias por hora. El tamaño del atado de diarios, el tamaño
del grupo de trabajadores y la capacidad de los trabajadores los define el usuario.
La inserción manual es un componente esencial de la simulación del departamento de co-
rrespondencia porque condiciona las operaciones de las líneas de empaque de las rotativas.
Para cada día de producción, la operación de las líneas de empaque de las rotativas experimenta
tres fases secuenciales: 1) la fase de entrega a domicilio (HD), 2) la fase combinada de entrega
a domicilio con venta en puestos de periódico y en la calle (HD+NS/SS), y 3) la fase de puestos
de periódicos y venta en la calle (NS/SS). Durante la primera fase, todos los atados de diarios
producidos por las líneas de empaque de las rotativas se ensamblan de forma mecánica y se
envían ya sea a los camiones HD o a los HWY. Durante la segunda fase, los atados de diarios
pueden enviarse ya sea a los camiones HD, HWY o a los NS/SS. Durante la tercera fase, todos
los atados de diarios se ensamblan de forma manual y se envían a los camiones NS/SS. La si-
guiente sección contiene descripciones de estas fases para la configuración de una sola rotativa.
El ejemplo se proporciona para ilustrar el concepto de la operación de una línea de empaque
de la rotativa.
Ejemplo
< Fase HD. Dos líneas de empaque operan en el modo regular y comparten la producción
de la rotativa (50%/50%). Una línea de empaque está en el modo de respaldo.
< Fase HD+NS/SS. Dos líneas de empaque operan en el modo regular y comparten el 80%
de la producción de la rotativa (40%/40%). Una línea de empaque opera en un modo de
inserción manual y alimenta el 20% de la producción de la rotativa. En la línea de inser-
ción a mano, los atados de diarios de encabezados que no se apartan por quien inserta a
mano, sino que se apilan hacia abajo en una tarima (el tamaño de la tarima lo define el
usuario) antes de que los atados de diarios alcancen el sistema de bandejas. Estos atados
de diarios de encabezados se almacenan hasta la fase NS/SS. Los que se apartan se revi-
san y transforman en atados de diarios NS/SS.
< Fase NS/SS. Mientras que la rotativa se encuentra todavía en ejecución, las tres líneas
de empaque operan en el modo de inserción manual y comparten la producción de la
rotativa (33%/33%/33%). En estas líneas de inserción a mano, los atados de diarios de
encabezados que no se apartan, y que revisan quienes insertan a mano, se apilan hacia
abajo en una tarima antes de alcanzar el sistema de bandejas. Estos atados de diarios se
almacenan hasta que la rotativa complete su orden de trabajo. Una vez que la rotativa
se apaga, todos los atados de diarios de encabezados vuelven a alimentar las líneas de
inserción a mano para la producción NS/SS.
En la simulación, el usuario establecerá la duración de una fase al definir la cantidad de
producto a elaborar por la rotativa durante esa fase. Cuando se haya elaborado tal cantidad
de producto, comenzará la siguiente fase. La fase NS/SS comenzará cuando todos los camio-
nes HD sean atendidos y terminará cuando todos los camiones NS/SS hayan sido servidos. El
usuario también definirá el modo de operación para cada línea de empaque durante cada fase.
Si una línea de empaque trabaja en el modo de inserción manual, el usuario definirá el número
de quienes insertan en la línea y la tasa de inserción a mano.
562 Apéndice A
A.3 Animación
El modelo de simulación de Arena incluirá una animación que capte el flujo general de los
atados de diarios a través del departamento de correspondencia y hacia los puertos y entari-
madores. La animación será una vista del sistema de arriba hacia abajo y de dos dimensiones,
que mostrará el movimiento de los atados de diarios a través del sistema de bandejas y hacia los
puertos y entarimadores de carga. Además, se desplegarán en la animación varias estadísticas
del sistema para mostrar criterios dinámicos de desempeño.
El periódico suministrará una distribución a escala tanto de la instalación de Springfield
como de la propuesta para Maryland en un formato CAD que proporcionará el antecedente
estático para la animación.
w Encabezado-HD (lento).
w Avance-HD.
w Encabezado-HD (lento).
w Avance-HD.
w HWY.
serán esenciales para esta validación. La cantidad de datos disponibles, en el formato adecuado,
determina el nivel de detalle del proceso de validación. SM y The Washington Post ejecutarán
las pruebas de validación iniciales de los modelos para confirmar el desempeño del sistema y la
lógica y algoritmos implementados.
A.5.4 Animación
El modelo de Arena incluirá una animación de dos dimensiones diseñada para permitir que el
analista comprenda las características dinámicas del modelo. La animación se parecerá mucho
a la distribución de la instalación proporcionada por el periódico en la forma de un archivo
CAD.
A.6 Aceptación
El estimado para el proyecto de modelado descrito anteriormente supondrá el trabajo de seis
personas/semanas que comenzarían después de que este documento de especificación funcional
sea firmado.
El costo de este esfuerzo es de $ xx. El pago se realizará con base en el siguiente calendario:
Aceptación de la especificación funcional $ xx
Finalización del desarrollo del modelo $ xx
Aceptación final $ xx
Tal costo no incluye el software que se requiere para ejecutar el modelo de simulación.
______________________________
Scott A. Miller, Gerente del proyecto
Servicios de simulación y consultoría
Systems Modeling Corporation
___________________________________
Representantes de The Washington Post:
Gary Lucke, Gerente de ingeniería de sistemas de manufactura
Olivier Girod, Gerente de ingeniería industrial
APÉNDICE B
Este apéndice contiene información de las primeras doce competencias de simulación de estu-
diantes IIE/Rockwell Automation (Systems Modeling). Equipos de tres estudiantes de universi-
dades de todo el mundo se enfrentan en esta competencia de forma anual. Los ganadores de los
primeros doce concursos fueron de la Universidad de Calgary, la Universidad Estatal de Kan-
sas, coganadores las Universidades de Pittsburgh y el Tecnológico de Virginia, la Universidad
de Queensland del Sur, el Instituto Politécnico del Sur y Universidad Estatal, la Universidad
Central de Florida (en dos ocasiones), la Universidad de Arizona, el ITESM Sonora Norte,
la Universidad de los Andes, Universidad Kyong-gii y la Universidad Estatal de Carolina del
Norte.
Las declaraciones detalladas para cada problema, junto con las tablas, figuras y, en algunos
casos, los archivos de datos por separado necesarios, están disponibles en la página web del
libro, sin que se requiera nombre o contraseña (véase el prefacio para el sitio URL de Internet).
Para cada concurso anual, existe un único archivo .zip descargable que contiene la descripción y
cualquier archivo adicional (es decir, datos de entrada); véase http://www.winzip.com si necesita
la utilidad WinZip® para descomprimir estos archivos .zip.
Aquí se enlistan los títulos de los concursos individuales, en orden cronológico:
1. SM Superstore (Supertienda).
2. SM Market (Tienda).
3. Sally Model’s SM Pizza Shop (Modelo SM de la Pizzería de Sally).
4. SM Office Repair (Reparación de oficina).
5. SM Rental (Renta).
6. SM Theme Parks (Parques temáticos).
7. SM Testing (Prueba).
8. SM Travel (Viaje).
9. SM Electronics (Electrónica).
10. SM Paints (Pinturas).
11. Rockland Steel Company (Acerería Rockland).
12. Rocksoft City Hospital (Hospital de la ciudad Rocksoft).
APÉNDICE C
El propósito de este apéndice es proporcionar una breve actualización de ciertos temas selec-
cionados de probabilidad y estadística necesarios para entender algunos de los fundamentos
probabilísticos de la simulación, así como para diseñar y analizar los experimentos de simu-
lación de forma apropiada. Aunque este material es la base de muchas de las partes del libro
(incluyendo cada vez que usamos una distribución de probabilidad en un modelo para repre-
sentar alguna cantidad de entrada aleatoria como una duración de tiempo), es particularmente
relevante en las secciones 2.6, 4.6 y 7.2, así como en los capítulos 6 y 12.
Pensamos en este apéndice para que sirva como un seminario muy breve y no como un
tratamiento exhaustivo de estos temas. Existen muchos textos excelentes de probabilidad y esta-
dística en general, como Anderson, Sweeney y Williams (2006), Devore (2004) y Hogg y Craig
(2005); para un “libro” gratuito en línea acerca del tema, que se une a recursos en línea adicio-
nales, véase Lane (2005) en http://davidmlane.com/hyperstat/index.html.
Aunque comenzaremos casi desde cero en probabilidad y estadística, suponemos que el lec-
tor se siente cómodo con manipulaciones algebraicas, incluyendo notación de suma. Para una
comprensión completa de variables aleatorias continuas (sección C.2.3) necesitará saber algo de
cálculo, particularmente integrales.
En la sección C.1 repasaremos las ideas y terminología básicas de la probabilidad. La sec-
ción C.2 contendrá un análisis acerca de las variables aleatorias en general, al describir variables
aleatorias discretas y continuas así como distribuciones conjuntas. La noción de muestreo y la
estructura probabilística asociada se analizarán en la sección C.3. La inferencia estadística, in-
cluyendo estimación puntual, intervalos de confianza y pruebas de hipótesis, se cubrirán en las
secciones C.4 a C.6. Durante todo el apéndice, realizaremos el análisis relevante a la simulación
por medio de ejemplos.
< Ejecute una simulación de un centro de atención telefónica (en lugar de operar el cen-
tro real) durante una semana simulada. Plantee las mismas preguntas que acabamos de
hacer, excepto que ahora es para lo que sucede en la simulación más que en la realidad;
si su modelo de simulación es válido, espere obtener las mismas respuestas, o al menos
muy cercanas.
El espacio muestral de un experimento es la lista completa de todos los resultados individua-
les que podrían ocurrir cuando se hace el experimento. Para algo como el lanzamiento de una
moneda o de un dado, es fácil anotar el espacio muestral. En otros casos, sin embargo, dicho
espacio podría tener un número infinito de posibilidades, como qué tanto le tomará manejar a
su trabajo mañana. Por fortuna, con frecuencia es posible entender un experimento y su estruc-
tura probabilística sin anotar explícitamente cuál es el espacio muestral.
Un evento es un subconjunto1 de un espacio muestral. A veces un evento puede describirse
con sólo enlistar los resultados individuales que definen el evento, si éste es lo suficientemente
sencillo. Por lo general, sin embargo, un evento se define por alguna condición de lo que suce-
de en el experimento; por ejemplo, en el centro de atención telefónica antes mencionado, un
evento de interés podría ser al menos 500 llamadas manejadas en un día. Con frecuencia los
eventos se denotan con letras mayúsculas como E, F, E1, E2, etc. Las operaciones habituales
de conjuntos aplican a eventos, tales como unión (E ∪ F ), intersección (E ∙ F ) y complemento
(E c = conjunto de resultados posibles que no estén en E), como se representa en la figura C-1.
La probabilidad de un evento es la relativa posibilidad que ocurrirá cuando se haga un ex-
perimento. Por convención (y por conveniencia de aritmética), las probabilidades siempre son
entre 0 y 1. P(E) denota la probabilidad de que ocurra el evento E. Aunque puede resultar im-
posible saber o derivar la probabilidad de un evento, se puede interpretar como la proporción
de veces en que ocurre el evento en muchas repeticiones independientes del experimento (aun
si de hecho no se puede repetir el experimento). Aquí hay algunas propiedades (entre muchas
otras) de las probabilidades:
< Si S es el espacio completo de la muestra, entonces P(S) = 1.
< Si ∅ es el evento vacío (nulo), entonces P(∅) = 0.
< P(E c) = 1 – P(E).
Espacio
muestral
E F E F E
EƛF E ƘF Ec
En tratamientos avanzados de probabilidad, no se permite que ningún evento sea algún subconjunto de un espacio
1
muestral, sino sólo una clase particular de subconjunto, llamada subconjunto mensurable. Para nuestros propósitos, sin
embargo, todos los subconjuntos que consideremos se podrán medir, por lo tanto serán eventos.
Una actualización en probabilidad y estadística 571
(suponiendo que P(F) > 0). La cuestión de esto es que saber que al ocurrir F reduce el “mundo”
de todo el espacio muestral hacia F y así la única parte relevante de E es aquella que interseca a
F. Entonces esta probabilidad se mide con relación al “tamaño” del mundo reducido, P(F).
Los eventos E y F se llaman independientes si P(E ∙ F) = P(E) P(F). Si esto es así, entonces
P(E ∙F) = P(E) y P(F ∙E) = P(F), por definición de la probabilidad condicional. En otras pala-
bras, saber que ha ocurrido uno de dos eventos individuales no dice nada acerca de si el otro
sucedió.
Existen muchas clases diferentes de eventos y probabilidades que aparecen en la simulación.
Por ejemplo, si pregunta la probabilidad de que:
< una parte pase la inspección.
< una parte que llega sea de prioridad 3.
< un tiempo de servicio esté entre 2 y 6.
< no llegará ningún cliente durante un intervalo de tiempo de cinco minutos.
< la longitud máxima de una cola durante una simulación excederá de 10.
< el tiempo promedio de las partes en el sistema sea menor a cuatro horas.
C.2.1 Bases
Una variable aleatoria es un número cuyo valor se determina por el resultado de un experimen-
to, así que se puede pensar en ella como en la cuantificación de un experimento. Técnicamente,
una variable aleatoria es una función definida del espacio muestral para los números reales. Así,
es una regla o función que asigna un número a cada resultado posible del experimento. Aunque
a veces se puede definir una variable aleatoria de esta forma, al regresar al espacio muestral y
asignar la función, con frecuencia sólo se empieza con la definición de la variable aleatoria sin
preocuparse del espacio muestral. Una forma razonable de pensar en una variable aleatoria
es que se trata de un número cuyo valor no se sabe de seguro antes de hacer el experimento,
pero que, por lo general, se sabrá algo acerca de él, como su rango de posibles valores o su pro-
572 Apéndice C
babilidad de ser igual a algo o fallar en algún rango. Generalmente, las variables aleatorias se
denotan con letras mayúsculas como X, Y, W1, W2, etcétera.
Las variables aleatorias vienen en dos “clases” diferentes: discretas y continuas. Una variable
aleatoria discreta puede tomar sólo ciertos valores separados. Por ejemplo, el número de objetos
defectuosos en una consignación de 50 artículos debería ser un número entero entre 0 y 50. Otro
ejemplo de una variable aleatoria discreta es el número de veces que una parte debe someterse
a una inspección con la finalidad de pasar; sin más información, esta variable aleatoria podría
ser un número entero positivo sin un límite superior. Así, una variable aleatoria discreta podría
tener un rango finito o infinito de posibles valores.
Una variable aleatoria continua, por otra parte, sólo puede tomar un valor real, cualquiera,
posiblemente limitado a la izquierda o a la derecha. Las variables aleatorias continuas por lo
general representan mediciones físicas como el tiempo o la distancia. Siempre hay infinitamente
muchos posibles valores para una variable aleatoria continua, aun si existen límites en su valor
a ambos lados. Por ejemplo, si X es el tiempo para procesar una parte en una máquina, el rango
sería [0, ∞) a menos que supongamos que no se permite que ninguna parte permanezca en la
máquina más de un cierto tiempo a, en cuyo caso el rango sería [0, a).
En simulación, las variables aleatorias se emplean para varios propósitos diferentes. A me-
nudo sirven como “modelos” para cantidades de entrada como duraciones de tiempo inciertas
(servicio o tiempos entre llegadas), el número de clientes en un grupo que arriba, o de cuál, de
entre varios tipos diferentes de partes, es una parte específica que llega. Las variables aleatorias
también se usan para representar cantidades de salida como el tiempo promedio en el sistema,
el número de clientes atendidos o la longitud máxima de un amortiguador (buffer).
El comportamiento probabilístico de una variable aleatoria se describe por su distribución de
probabilidad. Puesto que la naturaleza de esta distribución es algo diferente para las variables
aleatorias discretas y continuas, las consideraremos por separado; también definiremos algunas
propiedades básicas de variables aleatorias, como el valor y la varianza esperados.
C.2.2 Discretas
Para una variable aleatoria discreta X, habrá una lista x1, x2,... (finita o infinita) de posibles valores
que puede tomar. Note que las xi son valores fijos no aleatorios, pero la variable aleatoria X es,
bien, aleatoria. La función de densidad de probabilidad (PMF, por sus siglas en inglés) es simple-
mente una función que da la probabilidad que X tomará en cada uno de los posibles valores:
p(xp(x
i
) =i) P(X
= P(X
= x=i )xi )
para todas las i. Note que el enunciado “X = xi” es un evento que puede o no suceder y la PMS
da la probabilidad de que sí suceda. La PMF puede expresarse en una variedad de formas dife-
rentes: una lista o tabla numérica, una gráfica o algún tipo de fórmula matemática. Puesto que
la lista completa de las xi se supone que representa todos los posibles valores diferentes de X,
ŶŶp( xpi ()xâi ) â
todas i
todas i
1 lo general, la PMF es estimada a partir de los datos, o simplemente se supone.
1. Por
La función de distribución acumulada (CDF, por sus siglas en inglés) de una variable alea-
toria discreta X es una función que da la probabilidad de que X sea menor a o igual que su
argumento:
F ( x) â Ŷ
toda i tal que
p ( xi )
xi ǔ x
P (a ǔ X b ) â Ŷ p ( xi )
toda i tal que
a ǔ xi b
Una actualización en probabilidad y estadística 573
La suma adquirió todos los posibles valores xi que son ≤ que el argumento x de F. Note que 0
≤ F(x) ≤ 1 para todas las x, que F(x) → 0 cuando x → −∞ y que F(x) → 1 cuando x → +∞.
Así, F(x) es una función no decreciente que va del 0 al 1 cuando x va de izquierda a derecha.
Para una variable aleatoria discreta, F(x) es una función de “paso” que es llana entre posibles
valoresFadyacentes Ŷ
( x) â de xp (yxida
toda i tal que i
) un “salto” de altura p(x ) sobre x .
i i
La probabilidad xi ǔde
x que un evento involucre una variable aleatoria discreta X por lo general
se encuentra al añadir los valores apropiados de la PMF. Por ejemplo,
P (a ǔ X b ) â Ŷ p ( xi )
toda i tal que
Ŷ
a ǔ xi b
F ( x) â p ( xi )
toda i tal que
Esto sólo dice quexiañadamos
ǔx las probabilidades de aquellas xi que al menos son a pero (estric-
tamente) X) â Ŷ x
E (menores i p (b.
que )
xi Note que con las variables aleatorias discretas, tiene que tener cuidado
toda i
respecto a las desigualdades débiles versus fuertes.
P (a ǔ
Al igual X
que ) â Ŷ de datos
losbconjuntos p ( xi ) tienen un “centro” medido por el promedio de los datos,
las variables ) â Ŷ xi Źtienen
Var ( Xaleatorias Ĩ i2 tal
toda p(unxi ) “centro” en cierto sentido. El valor esperado de la variable
que
toda i a ǔ xi b
aleatoria discreta X se define como
E ( X ) â Ŷ xi p ( xi )
toda i
(a esto también se le llama media o esperanza de X y con frecuencia se denota con μ o, si hay
Varde
necesidad ) â Ŷ xi ŹlaĨvariable
( Xidentificar 2
p( xi ) aleatoria, μ ). Éste es un promedio ponderado de los posi-
X
toda i
bles valores xi para X, con las ponderaciones siendo respectivas probabilidades de ocurrencia de
cada xi. De esta forma, aquellas xi con una alta probabilidad de ocurrencia se cuentan más que
aquéllas con una probabilidad menor a ocurrir. Si hay finitamente muchas xi y cada una tiene
F ( x) â Ŷ
las mismas probabilidades
toda i tal que
p ( xi )
de ocurrir, entonces E(X) es sólo el promedio simple de las xi ya que
ellas “cuentan” igual. xi ǔ x A pesar del nombre, es importante entender que E(X) no se interpreta
como un valor de X que se “espera” obtener cuando se hace el experimento que define X. Efec-
tivamente, E(X) podría ni siquiera ser un posible valor de una variable aleatoria discreta X (las
xi podrían ǔX
P (aser b) â
números enteros Ŷ pero, p ( xidependiendo
) de la situación, E(X) no tiene que serlo). En
toda i tal que
lugar de eso, interprete el valor a ǔ xi besperado así: haga el experimento muchas veces (técnicamente,
un número infinito de veces), observe un valor de X cada vez y calcule el promedio de todos esos
valores de X que observa: este promedio será la esperanza de X.
E ( X ) â Ŷ xi p ( xi )
Y justo como los conjuntos de datos tienen una medida de variabilidad, así también las
toda i
variables aleatorias. La varianza de la variable aleatoria discreta X se define como
Var ( X ) â Ŷ xi Ź Ĩ 2 p( xi )
toda i
(con frecuencia denotada como σ2 o σ X2 ), en donde μ es el valor esperado de X. Éste es un pro-
medio ponderado de la desviación cuadrada de los posibles valores xi, cerca de la esperanza,
con las ponderaciones siendo la probabilidad de ocurrencia de cada xi. La varianza es una me-
dida de la “dispersión” de la variable aleatoria cerca de su media. Las unidades de la varianza
son los cuadrados de las unidades de X, así que las personas por lo general usan la raíz cuadra-
da positiva de la varianza (denotada como σ o σX) como una medida de dispersión; a esto se le
llama desviación estándar de X.
574 Apéndice C
Como se mencionó antes, existen varias formas diferentes de definir la PMF de una variable
aleatoria discreta. Arena apoya diferentes variables aleatorias discretas comunes para las canti-
dades de entrada del modelado y éstas se definen y describen en el apéndice D.
C.2.3 Continuas
Una variable aleatoria continua puede tomar cualquier valor real en algún rango. El rango
puede ser limitado o no en cualquiera de ambos extremos. No importa qué tan estrecho sea el
rango, una variable aleatoria continua siempre puede tomar números infinitos2 de valores reales
(esto es, cualquier valor de un continuo). Por lo tanto, no tiene sentido hablar sobre la proba-
bilidad de que una variable aleatoria continua igual (de forma exacta) a algún número fijo x;
técnicamente, esta probabilidad siempre será 0 aun cuando x esté dentro del rango de X.
En su lugar, el comportamiento probabilístico de una variable aleatoria continua se descri-
be en términos de que cae entre dos valores fijos, que pueden estar muy lejos o muy cerca uno
de otro. La función de densidad de probabilidad (PDF, por sus siglas en inglés) de una variable
aleatoria continua X se define como una función f(x) con las siguientes propiedades e interpre-
tación:
< f(x) ≥ 0 para todos los valores reales de x.
< El área total debajo de f(x) es 1. En terminología de cálculo, la integral total de f(x) es 1:
àƈ
ƞŹƈ
f (x) dx â1
àƈ
<
ƞŹƈ
(x) dx â1valor real fijo a y b, con a ≤ b, la probabilidad de que X caiga entre a y b
Paraf cualquier
b
esP(ela área
ǔ X debajo ƞ
ǔ b) â de ff(x)
a
entre a y b. En terminología de cálculo,
(x) dx
b
P(a ǔ X ǔ b) âƞ f (x) dx
a
Esta última propiedad dice que si deslizamos un intervalo reducido a izquierda y derecha
del eje x (manteniendo constante el ancho del intervalo), “recogemos” más área (probabilidad)
en aquellas regiones en donde la densidad es alta, así que es más probable observar muchos va-
lores de X en donde la densidad es alta que en donde sea baja. Si piensa repetir el experimento
muchas veces y marcar un punto en el eje x en donde el valor de la variable aleatoria X quede
cada vez, sus puntos serán muy densos en donde la función sea alta y bajos en donde la fun-
ción de densidad sea baja (¿entiende?). Note que la altura (valor) de f (x) por sí misma no es la
probabilidad de nada. Efectivamente, no requerimos que f (x) sea ≤ 1 y algunas PDF pueden
elevarse por encima de 1 en algunos puntos; lo que se requiere es que el área total bajo la PDF
sea igual a 1. Por ejemplo, considere una distribución uniforme entre 3.0 y 3.1. Para que el área
total debajo de PDF sea igual a 1, la altura f (x) para todos los posibles valores de x (entre 3.0
y 3.1) tiene que ser igual a 10. También, podríamos especificar que f (x) = 0 para los valores de
x dentro o fuera de algún rango, lo que significaría que esos rangos son imposibles para que
la variable aleatoria X caiga en ellos. A diferencia de las variables aleatorias discretas, aquí sí
podemos desentendernos de si los puntos finales de los rangos sobre los que queremos las pro-
2
Más preciso, un incontable número infinito de valores, para aquellos lectores que estén preocupados con los dife-
rentes tamaños del infinito.
Una actualización en probabilidad y estadística 575
babilidades sean definidos por desigualdades débiles o fuertes (esto es, < es lo mismo que ≤ y
> es lo mismo que ≥).
La función de distribución acumulada de una variable aleatoria continua X tiene la misma
definición e interpretación básica que para las variables aleatorias discretas: F(x) = P(X ≤ x)
para todos los valores reales de x. Así, F (x) es la probabilidad de que X caiga en x o a la izquier-
da de x. Sin embargo, calcular esto requiere obtener el área debajo de la función de densidad a
la izquierda de x:
x
F ( x) âƞ f (t )dt
Źƈ
Dependiendo de la forma de la PDF de f (x), la CDF de F (x) puede o no ser expresable como
una fórmula de formaàƈ cerrada que incluya a x. Por ejemplo, las distribuciones exponencial y
E ( X ) â xfapéndice
ƞ
de Weibull (véaseŹel
( x) dx D para las definiciones) sí tienen fórmulas simples para la CDF,
ƈ
pero las distribuciones gamma y normal no. Si la CDF no es expresable en una fórmula, su eva-
luación debe ser a la àƈ
izquierda de algún método numérico o una tabla (razón por la cual cada
libro deVar
estadísticaƞ
( X ) â posee( x ŹĨ )2 ftabla
una ( x )dx
para las áreas de distribución normal). Como en el caso de
Źƈ
las discretas, la CDF de F (x) para una variable aleatoria continua se eleva de 0 en el extremo
izquierdo hasta 1 en el extremo derecho, pero en este caso es una función continua más que
una función de paso. Puesto que f (x) es la pendiente (derivada) de F (x), aquellas regiones en
el eje x en donde F (x) se eleva abruptamente son las regiones en donde obtendríamos muchas
observaciones en X; en cambio, en donde F (x) es relativamente llana, no veremos muchas ob-
servaciones en X.
x
F ( x)esperado
El valor âƞ f (tde
)dtuna variable aleatoria continua es, como en el caso de la discreta, una
Źƈ
medida del “centro” de la distribución y es el promedio de infinitas observaciones en X. Se
define como x
F ( x) âƞ f (t )dt
Źà
ƈƈ
E ( X ) âƞ xf ( x) dx
Źƈ
àƈ
E ( X )seâdenota
y a menudo
ƞ ) dx μ o μX. Aproximadamente, éste es un “promedio” ponderado de
xf ( xcomo
los valores de x, que
Var ( X ) â ( x ŹĨ)2 f ( x )dxcomo la función de ponderación para contar más aquellos
usa la densidad
Ź ƈà ƈ
valores de x cerca deƞŹ ƈlos que la densidad es alta. La varianza de X, que mide su “extensión”, es
àƈ
Var ( X ) âƞ ( x ŹĨ)2 f ( x )dx
Źƈ
y a menudo se denota como σ2 o σ X2 ; la raíz cuadrada positiva de la varianza (denotada como
σ o σX) es la desviación estándar.
Arena respalda algunas variables aleatorias continuas diferentes para su uso en el modelado
de cantidades de entrada aleatorias; éstas se definen y analizan en el apéndice D.
Por parte de la salida, la simulación debería generar una secuencia W1, W2, W3,... que represen-
te las veces en el sistema de las partes terminadas en el orden de su salida. Un tema que surge
de forma natural, y que puede afectar la forma en que se modelan y analizan tales vectores
aleatorios, es si las variables aleatorias que los componen están relacionadas entre ellas, y si así
es, cómo es tal relación.
Para tratar esto, comenzaremos con la representación probabilística completa de vectores
aleatorios. Para mantener las cosas al menos parcialmente digeribles, consideraremos sólo un
par (dos tuplas) de variables aleatorias (X1, X2), pero obviamente las cosas se extienden para di-
mensiones mayores. La CDF común de (X1, X2) es una función de dos variables definida como
para todos los pares (x1, x2) de números reales. A menudo la palabra “y” se reemplaza con una
coma:
p
Si ambas variables aleatorias son discretas, la PMF común es
pP(a ǔ X ǔ b , a ǔ X ǔ b ) â b1 b2 f ( x , x )dx dx
p 1 1 1 2 2 2 ƞa1 ƞa2 1 2 2 1
P(a1 ǔ X1 ǔ b1 , a2 ǔ X2 ǔ b2 ) âƞ 1 ƞ 2 f ( x1 , x2 )dx2 dx1
b b
Si ambas variables aleatorias son continuas,
ab1 a 2b la PDF conjunta se denota f (x1, x2), la cual se
P(a1 ǔ X1 ǔ b1 , a2 ǔ X2 ǔ b2 ) âƞ 1 ƞ 2 f ( x1 , x2 )dx2 dx1
visualiza como una clase de superficie aque
1 a 2 flota sobre el plano (x , x ) y que tiene un volumen
1 2
total debajo de ella igual a uno. La interpretación de la PDF conjunta en el caso continuo es la
siguiente: la probabilidad de que X1 caiga entre a1 y b1 y, simultáneamente, que X2 caiga entre a2
y b2, espel volumen debajo de la PDF conjunta por encima del rectángulo [a1, b1] × [a2, b2] en el
plano (x1, x2). En notación de cálculo, esta interpretación se expresa como
P(a1 ǔ X1 ǔ b1 , a2 ǔ X2 ǔ b2 ) âƞ ƞ
b1 b2
f ( x1 , x2 )dx2 dx1
a1 a2
La distribución conjunta (expresada ya sea como CDF, PMF o PDF) contiene mucha informa-
ción acerca del vector aleatorio. En la práctica, por lo general no es posible saber, ni siquiera
estimar, toda la distribución conjunta. Afortunadamente, por lo general podemos tratar los
temas que necesitamos sin tener que saber o estimar la distribución conjunta desarrollada.
Dada una distribución conjunta de dos variables aleatorias, podemos obtener las distribu-
ciones individuales o marginales3 de cada una de las variables aleatorias solas. En el caso de la
discreta conjunta, la PMF marginal de X1 es, para todos los posibles valores x1i de X1,
toda
3 F X1 “marginal”Ŷ
El término
(x ) â p (x )
no es para 1i
X1 sugerir que estas distribuciones son de una integridad moral cuestionable. Más
todas i tal que
bien, se refiere simplementexal hecho de que, en dos dimensiones para el caso de la discreta conjunta, si las probabilida-
1i ǔx
des conjuntas son ordenadas en una tabla, entonces la suma de las filas y las columnas resulta en los valores sobre los
márgenes de la tabla, que serán las distribuciones “marginales” individuales.
àƈ
fx1 (x1 ) âƞ f (x1 , x2 )dx2
Źƈ
x1
FX (x1 ) â f X (t)dt
toda
toda
Una actualización en probabilidad y estadística 577
FXX11 ((xx)) â
F â Ŷ
Ŷ ppX1 ((xx1i ))
1i
todas i tal queXtoda
1
todas tal que
x1i iǔx
x1i ǔx
(aplican definiciones simétricas para X2). En el caso de la continua conjunta, la PDF marginal
de X1 es
F X1 (x ) âà ƈ Ŷ p X1 ( x1i )
1 âƞ
ffx1 ((xx1 )) â à ƈ i tal que
f (x1 ,, xx2 ))dx
todas
x1 ƞŹ ƈ fx1(i xǔx
Źƈ
1 2 dx2
2
y la CDF marginal de X1 es
âƞ
x
F â
FfXxX11(((xxx111)))â
àxƈ1f
1
(t)dt
1 ƞƞŹŹƈƈffX(Xx11 1(,t)xdt2 )dx2
Źƈ
(simétricamente para X2). Note que podemos obtener las distribuciones marginales de esta for-
ma de la distribución conjunta, pero el conocimiento de las distribuciones marginales por lo
x1 E ( X Ź E( X )) ( X Ź E( X ))
generalCov
Fno
Cov (xX
X1 ((es X22Ź)) ƈâ
,,â
X
ƞ
X1 1)1suficiente ((tX
âf XE1 para)dt
1Ź
1
determinar
E( X11 )) ( X22cuál
toda Ź E(es
X22la)) distribución conjunta (a menos que X1 y X2
sean variables aleatorias independientes, como se analiza a continuación).
La covarianza entre los componentes X1 y X2 de un vector aleatorio se define como
F X1 (x ) â Ŷ p X1 ( x1i )
Cov )âE
( X1 , X 2todas ( X
i tal 1 Ź E( X1 )) ( X 2 Ź E( X 2 ))
que
x1i ǔx
Observe que la cantidad dentro de los [ ] es una variable aleatoria con su propia distribución,
etc. y que la covarianza es la esperanza de esta variable aleatoria. La covarianza es una medida
de la relación (lineal) entre X1 y X2, y puede ser positiva, cero o negativa. Si la distribución con-
àƈ
x1 (x1 ) â
junta sefencuentra
tiende a hallarse por Źƈ ƞ
delineada
f (x1 , x2 )de
dxforma
2
que, cuando X1 está por encima de su media, entonces X2
encima de su media, entonces la covarianza es positiva; esto implica que
una X1 pequeña tiende a estar asociada con una X2 pequeña también. Por otra parte, si una X1
grande está asociada con una X2 pequeña (y viceversa), entonces la covarianza será negativa. Si
ƞ
x
no existe
FXuna â 1 f X1 (para
(x1 )tendencia t)dt que X1 y X2 ocurran conjuntamente de acuerdo o en desacuerdo
1 Źƈ
sobre si son grandes o pequeñas, entonces la covarianza será de cero. Así, la covarianza nos dice
si las dos variables aleatorias en el vector se encuentran (linealmente) relacionadas o no y si sí
lo están, si la relación es positiva o negativa.
2 ) â E ( X1 Ź E( X1 )) ( X 2 Ź E( X 2 ))
Sin Cov
embargo,
( X1 , Xla magnitud de la covarianza es difícil de interpretar ya que depende de las
unidades de medida. Para rectificar esto, la correlación entre X1 y X2 se define como
Está claro que la correlación tiene el mismo signo que la covarianza (o es cero junto con la
covarianza), así que la dirección de cualquier relación también se indica por el signo de la co-
rrelación. También la correlación es una cantidad sin dimensión (esto es, no tiene unidades de
medida y será la misma sin importar qué unidades de medición se elijan para X1 y X2). Lo que
quizá no es obvio (pero es cierto) es que la correlación siempre caerá entre –1 y +1, dando su
impacto emocional de magnitud universal. Sin saber nada acerca de la situación, se puede decir
que una correlación de 0.96 o – 0.98 es bastante fuerte, mientras que una correlación de 0.1 o
–0.08 es bastante débil. Así, la correlación proporciona una forma muy significativa de expresar
la dirección y fortaleza de una relación lineal4 entre variables aleatorias.
578 Apéndice C
4
La razón por la que mantenemos la cobertura del lenguaje con este calificador “lineal” para la covarianza y la
correlación es que tales medidas pueden no levantar relaciones no lineales que quizá están presentes. Sin embargo, en
la mayoría de las aplicaciones de modelado las relaciones estarán bastante cercanas a ser lineales, al menos en un rango
restringido.
5
En tal caso, algunas personas se han hecho populares por referirse a esto como la Declaración de Independencia,
ya que prácticamente lo es.
Una actualización en probabilidad y estadística 579
ŶŶ
n 2
( X( X
ŹXŹ)X )
i
2
iâ1 i
< La varianza de la muestra: s â
s 2â
2
iâ1
n Źn1Ź1
de de
número
número
pˆ â i que
Xi Xque está
está en en
BB
pˆ â
n n
2
( X()Xâ 2į n
)įâ
X()X
E (E â) â y Var
y Var n
Ŷ Xi
X â iâ1
n
n
Ŷ
iâ1
(X Ź X )
i
2
s 2â
580 Apéndice C n Ź1
Ŷ
n Ź1
mente produjeron n diferentes. De tal suerte, las estadísticas son, de hecho,
( Xi Ź X )2
variables aleatorias Ŷ
nnn
relativas
Ź X))2)2 2 al iâ1
2 Ŷ ( X Ź
i E( p
“experimento” X )2
ˆ ) â p ydeVar ( pˆ ) âuna
tomar p(1 Ź
muestra.
p) / n
n
Ŷ
iâ1
(((XX ŹXX Ŷ s â2
Xi iiŹ ( Xi Ź X )2
Por consiguiente, iâ1
número número número las
de deX Xs que
de â
estadísticas
X que queestá
está tienen
está
en en
B B
en Bsus propias distribuciones (a veces llamadas n Ź1
distri-
ˆâ
22
sss â
2 iâ1
iâ1
â pˆ â n Ź1 i i i n Ź1 s â
2 iâ1
bucionespˆdep â muestreo), nnŹ Ź11 esperanzas, n n n varianzas, etc. Aquí hay algunos resultados acerca n Ź 1de las
distribuciones de las tres estadísticas mencionadas: número de Xi que está en B
número de Xi que está en B pˆ â
(
E ( )
X número
número
número
() μâ ) yy de
Var
â y Var(de
de (X
X â) X
X (ˆ
p
) que
â
que
que
â
į â
)2į 2estáestá
está
nį n n2. enSien
en B
laB
B distribución subyacente a X es normal (véase
número elde Xi que nestá en B
apén-
Epˆppˆˆ âX
ââEâXy Var ii X
< i
n pˆ â
dice D para definiciones nnn de distribuciones), entonces la distribución de X también es
n
normal, escrita XX ~N ~X(NĨ ~(,N į,(į
Ĩ /Ĩ,/nį)n/ ) n ) ; usaremos la convención de que el segundoE “argumento” ( X )nâ y Var ( X ) âį 2 n
de la notación de E ( X2) â y Varnormal
distribución ( X ) âįes 2
n
la desviación estándar en lugar de la Ŷ X
varianza.
E(((X X)))â Var(((XX X)))â â įį
â i
EE X â2y2yyVar 2Var â į22 nnn E ( X ) â y iVar ( X ) âį 2 n
E(s
Aun E(s2 2) =
= įla
)E(s
si )į= į 2
distribución subyacente a X no es una normal, el teorema delXlímite â â1 central X ~ N ( Ĩ,į / n )
(n Ź1 (n Ź1 2) s2 2į22 2
)(nsque,Ź1 į) sX į X ~ N ( Ĩ,įleves,/ n ) la distribución de X será aproximadamente n
señala bajo
XX2 ~~NN((ĨĨ
~ N condiciones
( Ĩ,į , į /
,į/ / nn)) n ) bastante X ~ N ( Ĩ,į / n )
normal para ij n2ijŹn1 Źijuna 2
n grande. n E(s2) =n į 2
2 Ŷ
1n Ź 1
E(s ) = į2 2
ŶE(s X )2
< E(s
E(s
E(s 2 2) = į2 2 . Si la distribución subyacente es normal, entonces la cantidad
2
) )== į
į
2 Xi2 (n Ź1
) = į ) s2( Xį i2 Źtie-
E(E pˆ()E ˆ )(2â
pâ ppˆį)py2â yp Var
2 Var ˆn)(Ź1
pˆ ()(pâ
y( Var â
ppˆ()1)pâs(1pŹ
Ź 2 2
pį()1p/Ź)n/pn) / n X â (DF,iâ1
s) 2sâ iâ1
ne
(n((nnŹ1 una
Ź1)))sss22distribución
Ź1 įį 2 chi cuadrada con n – 1 grados de libertad (n Ź1 por 2sus2 siglas
į ijnn2Ź en
n Ź 11
inglés) denotados como ij 2
. Cualquier libro convencional de estadística tendrá una
ijij
2 n Ź 1
ij2n2Ź11 E(ijpˆn)Źâ1 p y Var ( pˆ )â p(1 Ź p ) / n
2
definiciónnnŹyŹ1análisis E (de
pˆ )â estap ydistribución.
Var ( ˆ ) â p(1 Ź p ) / n
p
n
Puesto que estamos estimando un parámetro con sólo un número (más E(s2)que = į 2un intervalo),
E( pˆ ) â p y aVar esto( pˆ ) â p(1 Ź p ) / n
se le llama estimación puntual. Aunque los estimados puntuales por(nsíŹ1mismos ) į
s 2 2 francamente no
valen mucho (ya que el lector no sabe qué tan cercanos, estables o buenos son en general), son
un comienzo y pueden tener algunas propiedades que valga la pena mencionar.
ij n2 Ź1
Una estadística que sirve como un estimador puntual se llamaEno â p y Var
( pˆ )sesgada para algún
( pˆ ) â p(1 Źpa- p) / n
rámetro población/distribución si E (estimador puntual) = parámetro. Parafraseando, esto in-
dica que si tomamos muchas muestras y calculamos el estimador puntual de cada muestra, el
promedio de estos estimadores sería igual al parámetro que se estima. Claramente, ésta es una
n
X
E ( X ) â y Var ( X ) âį 2 n n
Ŷ Xi
iâ1
X ~ N ( Ĩ,į / n ) X â n
ÖÞ
(n Ź 1) s 2 2 (n Ź 1) s 2 2
ÖÞ
Ź 1) s , (2n Ź 12) s
ij(nn22Ź1, ij Ź1,1)1Źs Ĝ /2 (n Ź 1) s 2
ÖÞ
1Ź Ĝ /2 ,( n nŹ
ij nŹ1, 1 ŹĜ /2 2 ij n2Ź 1, Ĝ,/2 2
ij ij n Ź 1, 1 Ź Ĝ / 2 n Ź 1, Ĝ / 2
ĨA – ĨB :
ĨA – ĨB :
ÖÞ
(n 2Ź 1)2s 2
ÖÞ
s A / sB ,
(n Ź 1) s 2
s A2 / s B2
ÖÞ
ij n2Ź1, 1 ŹĜ /2 s A2,ij/n2sŹB21, Ĝ /2 s2 / s2
Fn A Ź1, nB Ź1, 1 Ź Ĝ/2 Fn A Ź1, n,B Ź1, Ĝ/2A B
Fn A Ź1, nB Ź1, 1 Ź Ĝ/2 Fn A Ź1, nB Ź1, Ĝ/2
ĨA – ĨB :
tn Ź1, 1Ź Ĝ /2
582 Apéndice C
tn Ź1, 1Ź Ĝ /2
ÖÞ
(n Ź 1) s 2 (n Ź 1) s 2
, 2
en donde ij n Ź1, 1Ź Ĝ /2 esijel
2
1Ź Ĝ /2 crítico superior 1 − α/2 para una distribución chi cuadrada
punto
n Ź1,
ÖÞ
con(nn Ź – 11) sDF
2 (en
(n Ź 1) slas2 tablas de los libros de estadísticas). Este intervalo supone una
población/distribución ,
ij n2Ź1, 1Ź Ĝ /2 ij n2Ź1, 1Ź Ĝ /2 normal.
< La desviación estándar de población/distribución σ: Debido a la definición e interpre-
tación de los intervalos de confianza, sólo se pueden tomar las raíces cuadradas de los
tn Ź1,
puntos
ÖÞ
ij
(n Ź 1) s 2 (n Ź 1anterior:
1Ź Ĝ /2 finales del intervalo
2
ij
,
n Ź 1, 1 Ź Ĝ / 2
2
)s 2
n Ź 1, Ĝ / 2 tn Ź1, 1Ź Ĝ /2
(ÖÞ
(n Ź 1) s (n Ź 1) s
2 2
,Ĩ – ĨB :
ÖÞ
n Źij1) s (n Ź 1)ijs
2 2A 22
,
n Ź 1, 1 Ź Ĝ / 2 n Ź 1, Ĝ / 2
ÖÞ
ij 2
ij 2
(n Ź 1) s 2 (n Ź 1) s 2
n Ź1, 1Ź Ĝ /2 n Ź1, 1Ź Ĝ /2 ,
ÖÞ
2 2 2 2
< A
– ĨB :
LaĨdiferencia s / s las
entre
A B s /s
esperanzas
A B de dos poblaciones/distribuciones,
ij n2Ź1, 1Ź Ĝ /2 ij n2Ź1, 1Ź Ĝ /2 μA − μB: existen
diferentesFenfoques y fórmulas , resultantes para esto, analizadas en la sección 12.4.1. Un
n A Ź1, n B Ź1, 1 Ź Ĝ /2 Fn A Ź1, n B Ź1, Ĝ /2
tema importante en la decisión de qué enfoque usar es si el muestreo de las dos poblacio-
ÖÞ
2 2 2 2
s A / sB
nes/distribuciones
s A /de
s B forma independiente o no. La interpretación importante es
, se hizo
ÖÞ
nsinŹ 2
Ź ĜŹ
2
que(F este1) snintervalo
A Ź1, F kB,Ź1, 1( n /2 1F
1, k2,1ŹĜ / 2
) sn A Ź1, nB Ź0,
contiene 1, Ĝ la
/2 conclusión es que no podemos discernir una diferencia
ÖÞ
(n Źlas 2
ij n2Ź1, 1 ŹĜ /2 ij n2significativa
estadísticamente (en el nivel α) entre 1) sdos n Ź 1) s 2
(esperanzas; si el intervalo evita
Ź 1, Ĝ / 2 ,
el 0 entonces parece haber una diferencia significativa ij nŹ1, 1 ŹĜ /2entre
2
ij n2Źlas esperanzas.
1, Ĝ / 2
< El –FkĨ1B, k:2,1de
ĨAradio ŹĜ / 2las varianzas de dos poblaciones/distribuciones, σ 2 /σ 2 : el intervalo de con-
A B
fianza es ĨA – ĨB :
ÖÞ
s A2 / s B2 s A2 / s B2
,
ÖÞ
F F s A2 / s B2 s A2 / s B2
n A Ź1, n B Ź1, 1 Ź Ĝ /2 n A Ź1, n B Ź1, Ĝ /2 ,
F F
n A Ź1, n B Ź1, 1 Ź Ĝ /2 n A Ź1, n B Ź1, Ĝ /2
Fk 1, k2,1los
donde ŹĜ / 2 subíndices A y B en las varianzas y los tamaños de la muestra indican la
población/distribución correspondiente y Fk 1, k2,1ŹĜ /2 denota el punto crítico superior
1 − α/2 de la distribución F con (k1, k2) DF (en las tablas de los libros de estadísticas).
Se supone una población/distribución normal para este intervalo. Concluimos que existe
una diferencia estadísticamente significativa entre los parámetros de varianza si y sólo si
este intervalo no contiene 1.
< La proporción de las desviaciones estándar de dos poblaciones/distribuciones, σA/σB:
sólo toman la raíz cuadrada de los puntos finales en el intervalo de confianza precedente;
se concluye que los parámetros de la desviación estándar difieren significativamente si y
sólo
į A įsiBel intervalo evita el 1.
< La proporción B į AįįA Bį B
į A įpoblación/distribución p: el intervalo de confianza es
pˆ (1Ź pˆ )
pˆ ï z1Ź a /2 pˆ (1Ź pˆ ) pˆ (1pˆŹ(1pŹ
ˆ ) pˆ )
pˆ ï zn1Ź a /2 pˆ ïpˆ zï z 2 a /2
1Ź a1/Ź
n n n
z1Ź a /2
en donde z1Ź a /2 es el punto z1Źza1Ź crítico
/2 a /2 superior 1 − α/2 de la distribución normal estándar
(media = 0, desviación estándar = 1) (en las tablas de los libros de estadística). Éste es un
nintervalo
pˆ n (de
1Źcobertura
pˆ ) aproximado, válido para n grandes (una definición, entre muchas,
de “n grande” n pˆ es que Ź pˆn)pˆ n pˆ y n (1nŹ
n (1tanto (1Źpˆ ) pˆsean
) al menos 5).
La diferencia entre las proporciones de dos poblaciones/procesos pA − pB: el intervalo
pˆ A(1 Ź pˆA) pˆ B (1 Ź pˆB)
<
de Ź pˆ B ï z1Źesa /2
pˆ A confianza pˆàA(1 Ź pˆA) (1 Ź
pˆ BA(pˆ1AŹ (1 Ź
pˆAB)pˆA) pˆ B (pˆ1BŹ pˆB)pˆB)
pˆ A Ź pˆ B ï z1Ź n Aapˆ/2A pŹA pˆŹB pïB zï1Ź
ˆ ˆ / 2à
nzBa1Ź a /2 àà
nA nBA n A nB nB
pˆ (1Ź pˆ )
pˆ ï z1Ź a /2
n
z1Ź a /2
que sólo por casualidad obtenga datos que estén más a favor de H1, así que no hay una razón
en particular para sospechar de H0. Si el valor p está “en el límite”, digamos algo como 0.1, se
deja al lector con un resultado no concluyente, lo que a veces es todo lo que puede decir con
sus datos.
Un lugar en la simulación en que aparecen las pruebas de hipótesis es en las distribuciones
de probabilidad de entrada ajustadas para datos observados en la cantidad de entradas a ser
modeladas (sección 4.6). Aquí, H0 es la afirmación de que un candidato particular ajustado
a la distribución de forma adecuada explica los datos. Si H0 no se rechaza, entonces se tiene
evidencia insuficiente de que esta distribución es incorrecta, así que puede avanzar con ello. El
Input Analyzer de Arena tiene dos pruebas diferentes para esto ya incluidas, la prueba de la chi
cuadrada y la prueba de Kolmogorov-Smirnov. Dichas pruebas básicamente preguntan qué tan
cerca se encuentra la distribución ajustada a la distribución empírica definida directamente por
los datos; para detalles sobre cómo éstas y otras pruebas de bondad de ajuste funcionan, véase
cualquier libro convencional de estadística.
Otro lugar en la simulación en donde aparece la prueba de hipótesis es en el lado de los
resultados. Si hay varios modelos (más de dos) que se están comparando con base en alguna
medida de desempeño de salida seleccionada, una cuestión natural es si existe alguna diferencia
entre las medias de estas medidas de los diferentes modelos. Una recopilación de problemas y
técnicas específicos, llamada análisis de varianza (ANOVA, por sus siglas en inglés), es una parte
estándar de cualquier libro de estadística, así que no abundaremos en eso aquí. La hipótesis
nula es que todas las medias entre los diferentes modelos son las mismas; si no se rechaza esto,
se tiene evidencia insuficiente de cualquier diferencia en esta medida que la que hacen los dife-
rentes modelos. Pero si se rechaza H0, se está indicando que existe alguna diferencia en alguna
parte entre las medias, y no que ellas son únicas ni diferentes. Entonces, una cuestión natural en
tal caso es dilucidar precisamente qué medias difieren de las otras, a veces llamadas compara-
ciones múltiples en ANOVA. Se han desarrollado métodos diferentes para atacar este problema,
tres de los cuales se deben a Bonferroni, Scheffé y Tukey. El Output Analyzer de Arena (sección
6.4) tiene una característica incluida para llevar a cabo una prueba ANOVA, incluyendo estos
métodos de comparaciones múltiples.
Con relación a tal meta, pero más útil en el análisis de salida de la simulación, está la cues-
tión de cuál entre numerosas variantes (a veces llamadas escenarios) es la mejor según alguna
medida de desempeño general. El Process Analyzer de Arena, o PAN (sección 6.5), posee una
característica incluida para identificar los mejores escenarios y hacerlo en una forma relaciona-
da con las pruebas de hipótesis.
C.7 Ejercicios
C-1 Suponga que X es una variable aleatoria discreta con una función de masa de probabili-
dad dada por p (1) = 0.1, p (2) = 0.3, p (3) = 0.3, p (4) = 0.2 y p (5) = 0.1.
C-2 Suponga que X tiene una distribución uniforme (continua) entre 10 y 20 (véase el apén-
dice D).
C-3 Suponga que X es una variable aleatoria exponencial con una media de 5. (La función de
distribución acumulada es F (x) = 1 − ex/5 para x ≥ 0 y F (x) = 0 para x < 0; véase también el
apéndice D.)
C-4 Suponga que 7.3, 6.1, 3.8, 8.4, 6.9, 7.1, 5.3, 8.2, 4.9 y 5.8 son diez observaciones de una
distribución normal con media y varianza desconocidas. Calcule la media de la muestra, la
varianza de la muestra y un intervalo de confianza de 95 por ciento para la media de la pobla-
ción. Aquí hay una parte de la tabla t que contiene lo que necesitará (y algo más). Véase página
siguiente.
586 Apéndice C
1 – ³ /2
Grados de libertad 0.900 0.950 0.975 0.990 0.995
1 3.078 6.314 12.706 31.821 63.656
2 1.886 2.920 4.303 6.965 9.925
3 1.638 2.353 3.182 4.541 5.841
4 1.533 2.132 2.776 3.747 4.604
5 1.476 2.015 2.571 3.365 4.032
6 1.440 1.943 2.447 3.143 3.707
7 1.415 1.895 2.365 2.998 3.499
8 1.397 1.860 2.306 2.896 3.355
9 1.383 1.833 2.262 2.821 3.250
10 1.372 1.812 2.228 2.764 3.169
11 1.363 1.796 2.201 2.718 3.106
12 1.356 1.782 2.179 2.681 3.055
13 1.350 1.771 2.160 2.650 3.012
14 1.345 1.761 2.145 2.624 2.977
15 1.341 1.753 2.131 2.602 2.947
16 1.337 1.746 2.120 2.583 2.921
17 1.333 1.740 2.110 2.567 2.898
18 1.330 1.734 2.101 2.552 2.878
19 1.328 1.729 2.093 2.539 2.861
20 1.325 1.725 2.086 2.528 2.845
25 1.316 1.708 2.060 2.485 2.787
30 1.310 1.697 2.042 2.457 2.750
APÉNDICE D
Distribuciones de probabilidad
de Arena
Arena lleva incluido un conjunto de funciones para la generación de variables aleatorias a par-
tir de las distribuciones de probabilidad comúnmente usadas. Estas distribuciones aparecen en
los menús de sugerencias en muchos módulos de Arena en donde es probable que se usen. Tam-
bién encajan con las distribuciones en el Input Analyzer de Arena (excepto para la distribución
Johnson). Este apéndice describe todas las distribuciones de Arena.
Cada una de las distribuciones en Arena tiene uno o más valores de parámetros asociados
con ellas. Se deben especificar los valores de estos parámetros para definir la distribución por
completo. El número, significado y orden de los valores de los parámetros dependen de la dis-
tribución. En la tabla D-1 se da un resumen de las distribuciones (en orden alfabético) y los
valores de los parámetros.
Las distribuciones pueden especificarse empleando uno o dos formatos: se puede seleccio-
nar un sólo formato o mezclar los formatos dentro del mismo modelo. El formato se determina
por el nombre usado para especificar la distribución. El formato primario se selecciona ocupan-
do ya sea el nombre completo de la variable o una abreviatura de cuatro caracteres del nombre
que consiste en las primeras cuatro letras. Por ejemplo, UNIFORM o UNIF especifica la dis-
tribución uniforme en el formato primario. El formato secundario se selecciona especificando
588 Apéndice D
la distribución con una abreviatura de dos letras. Por ejemplo, UN especifica la distribución
uniforme en el formato secundario. Los nombres no son sensibles a mayúsculas o minúsculas.
En el formato primario se introducen explícitamente los parámetros de la distribución como
argumentos de la distribución. Por ejemplo, UNIFORM(10, 25) especifica una distribución
uniforme con un valor mínimo de 10 y uno máximo de 25. En el formato alternativo, se defi-
nen indirectamente los parámetros de la distribución al referenciar un conjunto de parámetros
dentro del módulo Parameters (Parámetros) del panel Elements (Elementos). Por ejemplo, UN
(DelayTime) especifica una distribución uniforme con los valores mínimo y máximo defini-
dos en el conjunto de parámetros llamado DelayTime. La principal ventaja del método indi-
recto de definir los parámetros proporcionados por el formato alternativo es que los parámetros
de la distribución se pueden modificar dentro del módulo Parameters.
El flujo de números aleatorios, usado en Arena al generar la muestra, también se puede espe-
cificar en ambos formatos. En el formato primario se introduce el número de flujo como el últi-
mo argumento que sigue a la lista de valores de parámetros. Por ejemplo, UNIFORM(10, 25,
2) especifica una muestra de una distribución uniforme al usar un flujo de números aleatorios
2. En el formato secundario, se introduce el flujo de números aleatorios como un segundo argu-
mento que sigue al identificador del conjunto de parámetros. Por ejemplo, UN(DelayTime,
PTimeStream)especifica una muestra a partir de una distribución uniforme al usar un flujo
de números aleatorios PTimeStream (que debe ser una expresión definida para ser el flujo que
el lector quiera y no es una entrada en el módulo Parameters).
En las siguientes páginas, le proporcionaremos un resumen de cada una de las distribuciones
respaldadas por Arena, enlistadas en orden alfabético para una fácil referencia. El resumen
incluye los formatos primario y secundario para especificar la distribución y una breve des-
cripción de la misma. Esta descripción incluye la función de masa o densidad, los parámetros,
rango, media, varianza y aplicaciones comunes para la distribución. Si se siente en la necesidad
de una breve actualización en probabilidad y estadística, vea el apéndice C.
Distribuciones de probabilidad de Arena 589
Función de f(x)
densidad de x ĝ Ź1 (1 Ź x)Ĝ Ź1
probabilidad f (x) = para 0 < x <1
B( ĝ , Ĝ)
x f (x)en
= donde B es
B(una
ĝ , Ĝ) para 0 < x <1
0 0.5 1.0 f (x) = B( ĝ , Ĝfunción
) de beta
completa dada por
0 de otra forma
B( ĝ , Ĝ) â t 0ĝ Ź1 (1Źt) ĜdeŹ1otra
ƞ dt forma
1
0
x
en donde B es una función de beta
x
en donde B es una función de beta
0 0.5 1.0
0 0.5 completa dada por
1.0
completa como
Parámetros Parámetros de forma beta (β) y alfa (α) especificados dada por
números reales positi-
ƞƞ
1 ĝŹ
B( ĝ , Ĝ ) â 1t
1
(1Źt) Ĝ Ź1dt
vos. B( ĝ , Ĝ) â 0 t ĝ Ź1 (1Źt) Ĝ Ź1dt
ĝ 0
ĝ àĜ
Rango [0, 1] (También se pueden transformar en un rango general [a, b] como se describe
después.)
ĝĜ
ĝ
( ĝĝàĜ ) ( ĝ àĜ à1)
2
Media ĝ àĜ
ĝ àĜ
ĝĜ
Varianza ĝĜ
( ĝ àĜ ) ( ĝ àĜ à1)
2
( ĝ àĜ ) ( ĝ àĜ à1)
2
Aplicaciones Por su capacidad para tomar una amplia variedad de formas, esta distribución a me-
nudo se usa como un modelo aproximado en la ausencia de datos. Debido a que el
rango de la distribución beta es de 0 a 1, la muestra X puede transformarse a una
muestra beta a escala Y con el rango desde a hasta b al usar la ecuación Y = a +
(b − a)X. La beta a menudo se usa para representar proporciones aleatorias, tales
como la proporción de artículos defectuosos en un lote. También se puede usar como
una distribución general y muy flexible para representar muchas cantidades de entra-
da que se supone que tienen un rango limitado a ambos extremos.
590 Apéndice D
Función de f(x)
densidad de c1
probabilidad
c3 – c2
x
xx
1 xx2 xx3 x
xn-1 xxnn
1 2 3 nŹ1
Función de F(x)
cn f(x)
=1
distribución
acumulada
c3
c2
c1
x
x1 x2 x3 xn-1 xn
x1 x2 x3 xnŹ1
xn
0 si x < x1 o x Ǖxn
Parámetros La función CONTINUOUS (Continua) en Arena regresa una muestra de una dis-
tribución empírica definida por el usuario. Se especifican los pares de probabilidades
acumuladas cj (= CumPj ) y los valores asociados xj (= Valj ). La muestra regresada
será un número real entre x1 y xn y será menor o igual que cada xj con la probabilidad
acumulada correspondiente cj. Las xj deben aumentar con j. Todas las cj deben ser de
entre 0 y 1, deben aumentar con j y cn debe ser 1.
La función de distribución acumulada F(x) es lineal por segmentos con “esqui-
nas” definidas por F(xj ) = cj para j = 1, 2, …., n. Así, para j ≥ 2, el valor regresado
estará en el intervalo (xj − 1, xj ] con probabilidad cj − cj − 1; dado que se encuentra en
este intervalo, se distribuirá uniformemente sobre ella.
Se debe tener cuidado al especificar c1 y x1 para obtener el efecto que desea al
extremo izquierdo de la distribución. La función CONTINUOUS regresará (exac-
tamente) el valor x1 con probabilidad c1. Así, si se especifica c1 > 0 esto de hecho
resulta en una distribución mixta continua-discreta que regresa (exactamente) x1 con
probabilidad c1 y con probabilidad 1 − c1 una variable aleatoria continua en (x1, xn]
como se describió antes. La gráfica de F (x) anterior representa una situación en don-
de c1 > 0. Por otra parte, si se especifica c1 = 0, se obtendrá una distribución continua
Distribuciones de probabilidad de Arena 591
(fielmente) en [x1, xn] como se describió antes, sin “masa” de probabilidad en x1; en
este caso, la gráfica F (x) sería continua, sin un brinco en x1.
Como en un caso del uso de una función CONTINUOUS, suponga que recopiló
un conjunto de datos x1, x2, . . ., xn (asumiendo que se clasificaron en un orden ascen-
dente) en tiempos de servicio, por ejemplo. En lugar de usar una distribución teórica
ajustada del Input Analyzer (sección 4.5), se quieren generar tiempos de servicio en
la simulación “directamente” de los datos, consistente con cómo se dispersan y se
agrupan, y entre la x1 mínima y la xn máxima que se observaron. Asumiendo que
no se quiere una “masa” de probabilidad directamente en x1, se especificaría c1 = 0 y
después cj= (j − 1)/(n − 1) para j = 2, 3, . . ., n.
Aplicaciones La distribución empírica continua se emplea para incorporar datos empíricos para
las variables aleatorias continuas directamente en el modelo. Esta distribución puede
usarse como una alternativa o una distribución teórica que ha sido ajustada a los
datos, así como en los datos que tienen un perfil multimodal o en donde haya valores
extremos significativos.
592 Apéndice D
Función de p(x)
masa de
probabilidad p(xj) = cj -cjŹ1
donde c0 = 0
c2cŹ2 –c
c11
cc11
x
xx11 xx2
2
. . . xxn
n
F(x)
Función de ccn3 = 1
distribución
acumulada c2
c1
x
xx11 xx22 . . . xxnn
Parámetros La función DISCRETA en Arena regresa una muestra de la distribución de probabi-
lidad discreta definida por el usuario. La distribución se define por el conjunto de va-
lores discretos posibles de n (denotados por x1, x2, . . ., xn ) que pueden regresarse por
la función y las probabilidades acumuladas (denotadas por c1, c2, . . ., cn ) asociadas
con estos valores discretos. La probabilidad acumulada (cj ) para xj se define como la
probabilidad de obtener un valor que sea menor o igual a xj. Por lo tanto, cj es igual
a la suma de p (xk ) para k que vaya de 1 a j. Por definición, cn = 1.
Aplicaciones La distribución empírica discreta se usa para incorporar datos empíricos discretos
directamente en el modelo. Con frecuencia se emplea esta distribución para tareas
discretas tales como el tipo de trabajo, secuencia de visitas o el tamaño del lote para
una entidad entrante.
Distribuciones de probabilidad de Arena 593
Función de f(x)
densidad de
ĝ Ź kx kŹ1eŹx /ĝ
probabilidad
k=1 (k Ź 1)! para x > 0
f (x) =
k=2
k=3
0 de otra forma
0 x
Parámetros Si X1, X2, . . ., Xk son variables aleatorias exponenciales IID (Independientes e Idén-
ticamente Distribuidas), entonces la suma de esas muestras k tienen una distribución
Erlang-k. La media (β) de cada uno de los componentes de las distribuciones expo-
nenciales y el número de variables aleatorias exponenciales (k) son los parámetros de
la distribución. La media exponencial se especifica como un número real positivo y k
se especifica como un número entero positivo.
Media kβ
Varianza kβ 2
Aplicaciones La distribución Erlang se usa en situaciones en las que ocurre una actividad en fases
sucesivas y cada fase tiene una distribución exponencial. Para k grandes, la Erlang se
aproxima a la distribución normal. A menudo la distribución Erlang se utiliza para
representar el tiempo requerido para completar una tarea. La distribución Erlang es
un caso especial de la distribución gamma en la que el parámetro de forma, α, es un
número entero (k).
594 Apéndice D
Función de f(x)
densidad de
1
probabilidad ĝ 1 Ź x /ĝ
e para x > 0
f (x) = ĝ
0 de otra forma
0 x
Media β
Varianza β2
Aplicaciones Esta distribución a menudo se usa para modelar tiempos entre eventos en llegadas y
procesos de no funcionamiento aleatorios, pero por lo general no es apropiada para
modelar tiempos de retraso del proceso.
Distribuciones de probabilidad de Arena 595
Función de f(x)
densidad de Ĝâ 1/2
ĝ ŹĜx Ĝ Ź1eŹx / ĝ
Ĝ=1/2 para x > 0
probabilidad f (x) = Ą (Ĝ )
Parámetros El parámetro de escala (β) y el parámetro de forma (α) especificados como valores
reales positivos.
Media αβ
Varianza αβ 2
Aplicaciones Para parámetros de forma de números enteros, la gamma es la misma que la distribu-
ción Erlang. La gamma se usa con frecuencia para representar el tiempo requerido
para completar alguna tarea (por ejemplo, un tiempo de máquina o un tiempo de
reparación de máquina).
596 Apéndice D
Función de
densidad de
probabilidad
0 0 1
Familia no acotada Familia acotada
Parámetros El parámetro de forma gamma (γ), parámetro de forma delta (δ > 0), parámetro de
escala lambda (λ > 0) y parámetro de ubicación Xi (ξ).
Aplicaciones La flexibilidad de la distribución Johnson permite ajustar muchos conjuntos de datos.
Arena puede muestrear de ambas formas, no acotada y acotada de la distribución.
Si delta (δ) pasa como un número positivo, se usa la forma con límite. Si delta pasa
como un valor negativo, se emplea la forma sin límite con ∙ δ ∙ como el parámetro.
(Actualmente, el Input Analyzer no respalda las distribuciones ajustadas de Johnson
a los datos.)
Distribuciones de probabilidad de Arena 597
x
į â ln (į à Ĩ ) / Ĩ 2l
2
l
2
l
0 1 2 2
0 de otra forma
1 2 2
Parámetros La media de LogMean
Ĩ à į 2 /2
eŹ(ln(x) Ź(σĨ)l /(>2į 0)) para
(μl > 0) y la desviación estándar de LogStd de lax > 0
Ĩ l aleatoria
variable âe lognormal. Ambos, LogMean f(x) y=LogStd, 12Ĭ especificarse
į xdeben Ź(ln( x) ŹĨ) 2 /( 2į 2) como
e para x > 0
números reales estrictamente positivos. f(x) = į x 2Ĭ
0 de otra forma
2 2
0 de otra forma
Rango [0, +∞)į l2 â e 2 Ĩ àį (eį Ź 1)
2
Ĩ l â e Ĩ àį /2
2
LogMean = Ĩ l â e àį /2
Ĩ
Media
2 2
Varianza (LogStd)2 = į l2 â e 2 Ĩ àį (eį Ź 1)
2 2
į l2 â e 2 Ĩ àį (eį Ź 1)
Aplicaciones La distribución lognormal se utiliza en situaciones en las que la cantidad es el pro-
ducto de un gran número de cantidades aleatorias. También es frecuente que se use
para representar tiempos de tareas que tienen una distribución desviada a la dere-
cha. Esta distribución se relaciona con la distribución normal como sigue. Si X tiene
una distribución Lognormal (μl, σl), entonces ln(X) tiene una distribución Normal
(μ, σ). Note que μ y σ no son la media y desviación estándar de la variable aleatoria
lognormal X, sino más bien la media y la desviación estándar de la variable aleatoria
normal lnX; la media de LogMean = μl y la varianza (LogStd)2 = σl2 de X se dan por
las fórmulas anteriormente citadas en esta página.
598 Apéndice D
Función de f(x)
densidad de
probabilidad
1 2 2
f (x) = eŹ(x ŹĨ) / (2į ) para todas
į 2Ĭ las x reales
0 x
Ĩ
Parámetros La media (μ) especificada como un número real y la desviación estándar (σ) especifi-
cada como un número real positivo.
Media μ
Varianza σ2
Aplicaciones La distribución normal se usa en situaciones en las que aplica el teorema del límite
central, esto es, las cantidades que son las sumas de otras cantidades. También se
utiliza de forma empírica para muchos procesos que parecen tener una distribución
simétrica. Debido a que el rango teórico es de −∞ a +∞, la distribución no debería
emplearse para cantidades positivas como tiempos de proceso.
Distribuciones de probabilidad de Arena 599
Función de (x)
pf(x)
masa de e Źħ ħx
probabilidad paraxġ {0, 1, . . .}
p(x) = x!
de otra forma
0 x
Rango {0, 1, . . .}
Media λ
Varianza λ
Aplicaciones La distribución Poisson es una distribución discreta que a menudo se utiliza para mo-
delar el número de eventos aleatorios que ocurren en un intervalo fijo de tiempo. Si el
tiempo entre los eventos sucesivos está distribuido de forma exponencial, entonces el
número de eventos que ocurren en un intervalo fijo de tiempo tiene una distribución
Poisson. La distribución Poisson también se usa para modelar tamaños de lote alea-
torios.
600 Apéndice D
Función de f(x)
2( x Ź a )
para a ǔx ǔm
densidad de ( m Ź a )( b Ź a)
probabilidad
f(x) = 2( b Ź x )
para m ǔx ǔb
(b Ź m)( b Ź a )
0 de otra forma
0 x
a m b
Parámetros Los valores mínimo (a), moda (m) y máximo (b) para la distribución se especifican
como números reales con a < m < b.
Rango [a, b]
Media (a + m + b)/3
Aplicaciones La distribución triangular se emplea habitualmente en situaciones en las que la forma
exacta de la distribución no se conoce, pero hay estimados (o suposiciones) del míni-
mo, máximo y de los valores más probables. La distribución triangular es más fácil de
usar y explicar que otras distribuciones que se pueden utilizar en esta situación (por
ejemplo, la distribución beta).
Distribuciones de probabilidad de Arena 601
Función de f(x)
densidad de
probabilidad 1
11
f (x) = b Ź a para a ǔx ǔ b
b Ľa
b–a
0 de otra forma
0 x
a b
Parámetros Los valores de mínimo (a) y máximo (b) para la distribución se especifican como nú-
mero reales con a < b.
Rango [a, b]
Media (a + b)/2
Varianza (b – a)2/12
Aplicaciones La distribución uniforme se usa cuando todos los valores en un rango finito se con-
sideran igualmente probables. A veces se emplea cuando no hay disponible ninguna
otra información más que el rango. La distribución uniforme tiene una varianza más
grande que otras distribuciones que se utilizan cuando escasea la información (por
ejemplo, la distribución triangular).
602 Apéndice D
Ĝ = 1/2
Función de f(x)
densidad de Ĝ=1
Ĝ=2
probabilidad Ĝ
Ĝĝ ŹĜ x Ĝ Ź1 eŹ(x /ĝ ) para x 0
Ĝ=3
f (x) =
0 de otra forma
Ĝ = 1/2
f(x)
Ĝ = 1/2
f(x) Ĝ=1
0 Ĝ=2
x Ĝ
Ĝ=1
Ĝ = 2Ĝ = 3 Ĝĝ ŹĜ x Ĝ Ź1 eŹ(x /ĝ )Ĝ para x 0
Ĝ=3
f (x) = Ĝĝ ŹĜ x Ĝ Ź1 eŹ(x /ĝ ) para x 0
f (x) =
0 de otra forma
ĝ 1
ÖÞ
0 de otra forma
Ą
Ĝ parámetro
Parámetros El Ĝ de escala (β) y el parámetro de forma (α) se especifican como números
0 x
reales
0 positivos. x
2
Rango
ĝ2
2Ą
[0, +∞)
Ĝ
ĝ 1
êÖÞ æÖÞèì
2
Ĝ Ĝ
Ź Ą
1
Ĝ
1
Media
Ą
ÖÞ
Ĝĝ Ą Ĝ1 , en donde Γ es la función gamma completa (véase la distribución gamma).
ÖÞ
Ĝ Ĝ
2
Varianza ĝ 22
ĝĜ 2Ą êÖÞ
2 1
æÖÞèì
1
Ź1 Ą 1
êÖÞ
2
Ĝ Ĝ æÖÞèì
2
Ĝ ŹĜ Ą Ĝ
2Ą
Ĝ Ĝ
Aplicaciones La distribución Weibull se emplea mucho en modelos de fiabilidad para representar el
tiempo de vida de un mecanismo. Si un sistema consiste en un gran número de partes
que fallan de forma independiente y si el sistema se descompone cuando cualquier
parte falla, entonces el tiempo entre fallas sucesivas puede aproximarse con la distri-
bución Weibull. Esta distribución también se utiliza para representar tiempos de tarea
no negativos.
APÉNDICE E
Instrucciones de instalación
del software académico
Arena requiere Microsoft® Windows® 98, Windows 98 SE, Windows ME, Windows 2000 (Paquete
de servicio 3 o posterior), Windows Server 2003 o Windows XP (Paquete de servicio 1 o poste-
rior). Con Windows 2000 y Windows XP, el lector debe contar con los privilegios del adminis-
trador para instalar el software.1
1
No se necesita tener los privilegios del administrador para ejecutar Arena después de su instalación. Para mayor
información o ayuda, por favor consulte su administrador de sistemas.
604 Apéndice E
Yerson, D. R., D. J. Sweeney y T. A. Williams, (2006), Essentials of Statistics for Business and
Economics, 4a. ed., Thomson South-Western, Cincinnati, OH.
Ashour, S. y S. G. Bindingnavle, (1973), “An Optimal Design of a Soaking Pit Rolling Mill
System”, Simulation, vol. 20, pp. 207-214.
Balci, O., (1990), “Guidelines for Successful Simulation Studies”, Proceedings of the 1990 Win-
ter Simulation Conference, O. Balci et al. (eds.), pp. 25-32.
Balci, O., (1995), “Principles and Techniques of Simulation Validation, Verification, and Tes-
ting”, Proceedings of the 1995 Winter Simulation Conference, C. Alexopoulos et al. (eds.),
pp. 147-154.
Banks, J. y R. R. Gibson, (1996), “Getting Started in Simulation Modeling”, IIE Solutions, vol.
28, pp. 34-39.
Bauer, K. W. y J. R. Wilson, (1992), “Control-Variate Selection Criteria”, Naval Research Lo-
gistics 39, pp. 307-321.
Bratley, P., B. L. Fox y L. E. Schrage, (1987), A Guide to Simulation, 2a. ed., Springer-Verlag,
Nueva York, NY.
Cinlar, E., (1975), Introduction to Stochastic Processes, Prentice-Hall, Englewood Cliffs, NJ.
Decisioneering, Inc., (2006), Crystal Ball, http://www.decisioneering.com/, Denver, CO.
Devore, J. L., (2003), Probability and Statistics for Engineering and the Sciences, 6a. ed.,
Wadsworth Inc, Belmont, CA.
Devroye, L, (1986), Non-Uniform Random Variate Generation, Springer-Verlag, Nueva York,
NY.
Farrington, P. A. y J. J. Swain, (1993), “Design of Simulation Experiments with Manufacturing
Applications”, Proceedings of the 1993 Winter Simulation Conference, G. W. Evans et al.
(eds.), pp. 69-75.
Fishman, G. S. (1978), “Grouping Observations in Digital Simulation”, Management Science
24, pp. 510-521.
Forgionne, G. A., (1983) “Corporate Management Science Activities: An Update”, Interfaces,
vol. 13, pp. 20-23.
Gass, Saul I. y Donald R. Gross, (2000), “In Memoriam: Carl M. Harris, 1940-2000”, INFOR-
MS Journal on Computing 12, pp. 257-260.
Glover, F., J. Kelly y M. Laguna, (1999), “New Advances for Wedding Optimization and Simu-
lation”, Proceedings of the 1999 Winter Simulation Conference, 255-260.
Goldsman, D., (1992), “Simulation Output Analysis”, Proceedings of the 1992 Winter Simula-
tion Conference, J. J. Swain et al. (eds.), pp. 97-103.
Gross, D. y C.M. Harris, (1998), Fundamentals of Queueing Theory, 3a. ed., Wiley, Nueva York,
NY.
Harpell, J. L., M. S. Lane y A. H. Mansour, (1989), “Operations Research in Practice: A Lon-
gitudinal Study”, Interfaces, vol. 19, pp. 65-74.
606 Referencias
para la variancia 582 Límite central, teorema del 271, 580, 582
significado del 271 Lindley, fórmula de 44
Inventario 39 Línea, ancho y estilo de (Line Width and
Inventario, modelo de 244 Style) 103
Inversa funcional 40 Línea límite de formato gráfico 71, 106
IS 295 Líneas 103, 105
Llegada 25
J Llegada, razón de 43, 226
J 374 Localización de entidades (Entity
Java 420 Location) 344
Jerárquico 11 Localización de imagen de entidad,
Ji cuadrada, distribución 181, 580, 582 ventana de 127, 150, 164
Ji cuadrada, prueba de la 584 Localización de imagen de transportador,
Jobstep, atributo 295 ventana (Transporter Picture
Johnson JOHN (JO), distribución de 587, Placement) 334
596 Localización de imagen recurso, ventana de
Johnson, M. 516, 606 (Resource Picture Placement) 68, 84, 152
Joshi, S. 607 Logaritmos 64
Lógica, módulos de
K crear (Create) 405, 432
Kang, K. 321, 607 demorar (Delay) 407
Kelly, J. 287, 605 lectura-escritura (ReadWrite) 406
Kelton, W.D. 182, 188, 244, 289, 321, 509, separar (Separate) 408
532, 535, 606 Lognormal LOGN (RL), distribución
Kleindorfer, G. 535, 606 176, 587, 597
Kolmogorov-Smirnov, prueba de 181, 584 Longitud de acumulación (Accumulation
Kuhl, M.E. 516 Length) 355
Kulwiec, R. 328, 606 Long, S. 6, 607
Lote Máximo (Max Batch) 377
L Lotes 318, 376
agrupar permanentemente 376
Laguna, M. 287, 605
agrupar temporalmente 376
Lane, D. 569
Lotes, formación de 375, 376
Lane, M. 6, 605, 606
Larga duración, 79, 131 Lotes, tamaños de los 320
Law, A. 182, 244, 289, 321, 532, 606 Lucke, G. 543, 553, 565
LCG 506 M
Leclerc, George Louis 8
Lectura de las llegadas de las entidades a M 271, 295
partir de un archivo de texto 405 Machines.plb 85
Lectura-escritura, módulo (ReadWrite) Macro 100, 428
406 Manage Named Views 104
L’Ecuyer, P. 509, 606 Mandar al fondo (Send to Back) 88, 100, 104
Lee, S. 516, 606 Manguera de jardín 514
Leemis, L. 516, 606 Manipulación 367
Liberar (Free) 337 Mano, simulación de la 25, 53, 405
Liberar (Release) 22, 64 Manssur, A. 6, 605, 606
Liberar (Release), módulo 330 Mantener (Holding) 375
Liberar módulo (Free Module ) 366 Mantener inventario, costo de 246
Liberar notas (Release Notes) 102 Marco de tiempo de las simulaciones 265
Liberar recurso 330 Markoviano 19
Liberar transportador (Free Transporter) Marsaglia, G. 508, 606
336 Materiales, manejo de 328
Libre 333 Máximo de celdas ocupadas (Max Cells
Licencia, activación de la 603 Occupied) 350
Índice analítico 621
Pegden, C.D. 58, 109, 182, 258, 311, 356, discreta 177, 369, 587, 592
394, 607 exponencial 19, 35, 62, 115, 118, 176,
Periodo de calentamiento (Warm-up 184, 587, 593-594
Period) 72, 313, 315, 316, 318, 393, gamma 176, 587, 593, 595
529 lognormal 176, 587, 597
pi, estimación de 8, 9 normal 39, 65, 176, 185, 580, 587, 598
PickQ Block 394 teórica 176
Pizzazz (con VBA) 432 triangular 35, 65, 115, 176, 184, 587, 600
Plantas en tiestos 154 uniforme 65, 176, 184, 587, 601
Plantilla, barra de herramientas (Template) Probabilidad, función de densidad de
451 (PDF) 511, 513, 572, 574
Plantillas 11, 55 Probabilidad, tablero de 112, 263
usos de las 456 Procesamiento concurrente 458
Plantillas, archivo de 450 Procesamiento especializado en serie 89
Plantillas, carpeta 80 Procesamiento generalizado en paralelo 89
Plantillas, construcción de 449 Proceso de flujo, módulos del panel
ventana de diseño del diálogo 453 asignar (Assign) 488
Plantillas enfocadas a la industria 456 flujo (Flow) 487
Plilínea (Polyline) 103, 105 liberar regulador (Release Regulator)
Plot, botón 85 488
PMF (función de masa de probabilidad) 572 regular (Regulate) 487
PMF (función de masa de probabilidad) sensor (Sensor ) 487
conjunta 576 tanque (Tank) 487
Población 579 tomar regulador (Seize Regulador) 488
Poisson POIS (PO), distribución de 369, Proceso de flujo, plantilla de (Flow
587, 599 Process Template) 487
Poisson, proceso estacionario de 228 Proceso de llegada no estacionario 186
Poisson, proceso no estacionario de Proceso, hoja de cálculo 66
(NSPP) 186, 228, 515 Proceso, orientación del 33
Polígono (Polygon) 103, 106 Procesos 33
Porcentaje estándar 147 Process, módulo 60, 64, 83, 117, 122, 123,
Porcentaje restringido 147 336
Porcentaje verdadero (Percent True) 122 Producción total 17
Posibilidad 570 Programación lineal 4
Posición inicial (Initial Position) 334 Programación matemática 39
Precisión 36, 270 Programa 66, 134, 240
Precisión relativa 529, 531 Programa, módulo (Schedule) 61, 136
Predicción, intervalo de 271 Programa, nombre (Schedule) 134
Presentación 82, 108, 117, 550 Programa, regla de (Schedule) 134
Presentaciones 82 dejar inconcluso Preempt 134, 135
Primera creación (First Creation) 253 esperar (Wait) 134, 135
Primeras entradas primeras salidas ignorar (Ignore) 134
(PEPS) (FIFO) 15, 67, 217, 329 Programa, tipo (Schedule) 231
Prioridades 64, 217, 330, 333 Promover ruta (Promote Path) 105
Prnt Scrn 57, 107 Propiedades, diálogo 432
Probabilidad 569, 570 Proyecto, barra del 56, 57, 80
Probabilidad acumulada 300 Proyecto, descripción de 61, 72
Probabilidad condicional 571 Proyecto, elemento del 248
Probabilidad, distribuciones de 34, 176, 569 Proyecto, parámetros del 72, 89, 125, 131
beta 176, 587, 589 Proyecto, título del 72, 89
continua 176, 587, 590 Proyectos en espiral 544
de Erlang 176, 587, 593, 595 Prueba completa del sistema de control 459
de Johnson 587, 596 Prueba de unidades, lógica del controlador
de Poisson 369, 587, 599 del proceso de 459
de Weibull 115-116, 176, 587, 602 Prueba t pareada 276, 522
626 Índice analítico
flechas conectoras (Connector Arrows) Visual Basic® 10, 11, 104, 202, 420
99 Visual Basic para aplicaciones [Visual
guías (Guides) 60 Basic® for Applications (VBA) ] 354
pausas de página (Page Breaks) 99 Volátil 40
pegar a guías (Glue to Guides) 60, 99
reglas (Rulers ) 59, 99 W
retícula (Grid) 59, 99
Weibull WEIB (WE), distribución de 115-
vistas nombradas (Named Views)
116, 176, 587, 602
99
Vista previa (View Previous) 104 Williams, T. 569, 605
Vista previa impresión (Print Preview) Wilson, J. 516, 524, 605, 606
103, 107 Windows® 2000 603
Vistas 58 Windows® 98 603
hoja de cálculo de 63 Windows® XP 603
nombradas (Named) 59 WIP 110, 537
Vistas nombradas (Named Views) 59, 89, www.arenauserzone.com 604
99, 107, 148 Wysk, R. 14, 607