Simulación Con Software Arena (4a. Ed.) PDF

S 1 M U l •
Simulación con software Arena

Simulación con software Arena
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
MÉXICO · BOGOTÁ · BUENOS AIRES · CARACAS · GUATEMALA · LISBOA · MADRID

NUEVA YORK · SAN JUAN · SANTIAGO · AUCKLAND · LONDRES · MILÁN
MONTREAL · NUEVA DELHI · SAN FRANCISCO · SINGAPUR · SAN LUIS · SIDNEY · TORONTO
Director Higher Education: Miguel Ángel Toledo
Director editorial: Ricardo A. del Bosque Alayón
Editor sponsor: Pablo Eduardo Roig
Editora de desarrollo: Ana Laura Delgado
Supervisor de producción: Zeferino García García
Traducción: María Jesús Herrero, José Hernán Pérez, Francisco Sánchez
SIMULACIÓN CON SOFTWARE ARENA

Cuarta edición
Prohibida la reproducción total o parcial de esta obra,

por cualquier medio, sin la autorización escrita del editor.
DERECHOS RESERVADOS © 2008 respecto a la cuarta edición en español por

McGRAW-HILL/INTERAMERICANA EDITORES, S.A. DE C.V.
A Subsidiary of The McGraw-Hill Companies, Inc.
Edificio Punta Santa Fe
Prolongación Paseo de la Reforma 1015, Torre A
Piso 17, Colonia Desarrollo Santa Fe,
Delegación Álvaro Obregón
C.P. 01376, México, D. F.
Miembro de la Cámara Nacional de la Industria Editorial Mexicana, Reg. Núm. 736
ISBN-13: 978-970-10-6515-0
ISBN-10: 970-10-6515-8
Traducido de la cuarta edición de: Simulation with Arena.

Copyright © MMVII by The McGraw-Hill Companies, Inc. All rights reserved.
ISBN: 0-07-352341-0
1234567890 09765432108
Impreso en México Printed in Mexico

Para aquellos verdaderamente importantes en “la arena” de nuestras vidas:
Albert, Anna, Anne, Christie y Molly
Aidan, Charity, Emma, Jenny, Michael, Noah, Sammy, Sean, Shelley y Tierney
Diana, Kathy, Melanie y Victoria

Contenido
Capítulo 1: ¿Qué es la simulación?....................................................................................... 1
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
Capítulo 2: Conceptos principales de simulación............................................................... 15
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
2.3.3 Variables (globales)........................................................................ 21

2.3.4 Recursos......................................................................................... 22
2.3.5 Colas.............................................................................................. 22
2.3.6 Acumuladores estadísticos............................................................. 23
2.3.7 Eventos.......................................................................................... 23
2.3.8 Reloj de simulación........................................................................ 24
2.3.9 Empezar y parar............................................................................. 24
2.4 Simulación manual dirigida por eventos.............................................................. 25
2.4.1 Esbozo de la acción........................................................................ 25
2.4.2 Mantenimiento del rastro de las cosas............................................ 26
2.4.3 Llevarla a cabo............................................................................... 28
2.4.4 Resumen......................................................................................... 32
2.5 Simulación orientada a eventos y procesos.......................................................... 32
2.6 Aleatoriedad en la simulación.............................................................................. 34
2.6.1 Entrada y salida aleatoria............................................................... 34
2.6.2 Repetición del ejemplo................................................................... 34
2.6.3 Comparación de alternativas.......................................................... 36
2.7 Simulación con hojas de cálculo.......................................................................... 38
2.7.1 El problema del voceador............................................................... 38
2.7.2 Una cola de servicio sencilla........................................................... 43
2.7.3 Extensiones y limitaciones.............................................................. 47
2.8 Visión general de un estudio de simulación.......................................................... 47
2.9 Ejercicios............................................................................................................. 48
Capítulo 3: Un recorrido guiado a través de Arena............................................................. 53
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
Capítulo 4: Modelación de operaciones y entradas básicas.............................................. 115
4.1 Modelo 4-1: montaje electrónico y sistema de prueba.......................................... 115

4.1.1 Desarrollo de un enfoque de modelado.......................................... 116
4.1.2 Construcción del modelo................................................................ 117
4.1.3 Ejecución del modelo..................................................................... 127
4.1.4 Ver los resultados........................................................................... 130
4.2 Modelo 4-2: montaje electrónico mejorado y sistema de prueba.......................... 132
4.2.1 Expansión de la representación de recursos: Programas y Estados 133
4.2.2 Programas del recurso.................................................................... 134
4.2.3 Fallas del recurso............................................................................ 138
4.2.4 Frecuencias..................................................................................... 140
4.2.5 Resultados del modelo 4-2.............................................................. 144
Contenido
4.3 Modelo 4-3: mejora de la animación.................................................................... 147

4.3.1 Cambio de las colas de animación ................................................. 148
4.3.2 Cambio de las imágenes de entidad................................................ 150
4.3.3 Agregar imágenes de recurso.......................................................... 152
4.3.4 Agregar variables y gráficas............................................................ 154
4.4 Modelo 4-4: montaje electrónico y sistema de prueba con movimientos de
piezas................................................................................................................... 156
4.4.1 Algunos conceptos nuevos de Arena: Estaciones y Transferencias.. 156
4.4.2 Añadir la lógica de ruta ................................................................. 158
4.4.3 Alterar la animación....................................................................... 162
4.5 Encontrar y corregir errores................................................................................. 165
4.6 Análisis de entradas: especificación de parámetros y distribuciones del modelo.. 172
4.6.1 Entradas deterministas contra aleatorias........................................ 173
4.6.2 Recopilación de datos..................................................................... 174
4.6.3 Uso de datos................................................................................... 175
4.6.4 Ajuste de distribuciones de entradas vía el analizador de datos
de entrada (Input Analyzer)........................................................... 176
4.6.5 ¿Sin datos?...................................................................................... 183
4.6.6 Procesos de llegada no estacionarios.............................................. 186
4.6.7 Datos de entrada multivariados y correlacionados......................... 187
4.8 Ejercicios............................................................................................................. 188
Capítulo 5: Modelado de operaciones detalladas................................................................ 195
5.1 Modelo 5-1: un sistema de centro de atención telefónica sencillo......................... 196

5.2 Nuevos temas de modelado................................................................................. 197
5.2.1 Rechazos (Rejections) y cuando el cliente renuncia (Balking)......... 197
5.2.2 Decisiones de tres caminos............................................................. 198
5.2.3 Variables y expresiones................................................................... 198
5.2.4 Almacenamientos (Storages).......................................................... 199
5.2.5 Simulaciones terminantes o de estado estable................................. 199
5.3 Enfoque del modelado......................................................................................... 200
5.4 Construcción del modelo..................................................................................... 202
5.4.1 Crear llegadas y dirigir al servicio................................................... 202
5.4.2 Lógica de corte de llegada (cutoff).................................................. 208
5.4.3 Llamadas de soporte técnico.......................................................... 210
5.4.4 Llamadas de ventas........................................................................ 213
5.4.5 Llamadas de estado del pedido....................................................... 214
5.4.6 Salida del sistema y configuración de ejecución.............................. 220
5.4.7 Animación...................................................................................... 222
5.5 Modelo 5-2: sistema mejorado del centro de atención telefónica.......................... 225
5.5.1 Descripción del nuevo problema..................................................... 225
5.5.2 Conceptos nuevos........................................................................... 227
5.5.3 Definición de datos......................................................................... 229
5.5.4 Modificación del modelo................................................................ 232
Contenido xi
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.9 Ejercicios............................................................................................................. 258
Capítulo 6: Análisis estadístico de resultados de las simulaciones terminadas.............. 265
6.1 Marco de tiempo de las simulaciones................................................................... 266

6.2 Estrategia para recopilación y análisis de datos................................................... 266
6.3 Intervalos de confianza para sistemas terminados............................................... 268
6.4 Comparación de dos escenarios........................................................................... 273
6.5 Evaluación de varios escenarios con el Process Analyzer (PAN) (Analizador de
procesos).............................................................................................................. 277
6.6 Búsqueda de un escenario óptimo con OptQuest................................................. 282
6.8 Ejercicios............................................................................................................. 288
Capítulo 7: Modelado intermedio y análisis estadístico de estado estable ..................... 293
7.1 Modelo 7-1: un sistema pequeño de fabricación.................................................. 293

7.1.1 Nuevos conceptos de Arena........................................................... 294
7.1.2 El enfoque de modelado................................................................. 296
7.1.3 Los módulos de datos..................................................................... 297
7.1.4 Los módulos de lógica.................................................................... 299
7.1.5 Animación...................................................................................... 306
7.1.6 Verificación.................................................................................... 308
7.2 Análisis estadístico de resultados de las simulaciones de estado constante........... 312
7.2.1 Calentamiento y longitud de ejecución........................................... 312
7.2.2 Réplicas truncadas......................................................................... 316
7.2.3 Agrupar en una sola ejecución....................................................... 317
7.2.4 ¿Qué hacer?.................................................................................... 320
7.2.5 Otros métodos y objetivos para el análisis estadístico de estado
estable............................................................................................ 321
7.4 Ejercicios............................................................................................................. 321
Capítulo 8: Transferencia de entidades................................................................................ 327
8.1 Tipos de transferencias de entidades.................................................................... 327

8.2 Modelo 8-1: el pequeño sistema de fabricación con transferencias restringidas
por los recursos.................................................................................................... 329
8.3 El pequeño sistema de fabricación con transportadores....................................... 333
xii Contenido
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
transportadores acumuladores....................................................... 355
8.6 Ejercicios............................................................................................................. 356
Capítulo 9: Un muestrario de aspectos y técnicas adicionales de modelado.................. 359
9.1 Modelado de transportadores continuos usando el panel Transferencia

Avanzada............................................................................................................. 359
9.1.1 Modelo 9-1: almacenamientos intermedios finitos en las estaciones 360
9.1.2 Modelo 9-2: piezas que permanecen sobre el transportador
durante el procesamiento................................................................ 364
9.2 Más acerca de los transportadores (discretos)...................................................... 365
9.3 Abandono por parte de la entidad....................................................................... 366
9.3.1 Renuncia y abandono por parte de la entidad................................ 366
9.3.2 Modelo 9-3: un modelo de servicio con renuncia y abandono........ 367
9.4 Retención de entidades y formación de lotes con ellas......................................... 375
9.4.1 Opciones de modelado................................................................... 375
9.4.2 Modelo 9-4: un ejemplo del proceso de formación de lotes............. 376
9.5 Traslape de recursos............................................................................................. 382
9.5.2 Modelo 9-5: un sistema de producción estrechamente acoplado.... 384
9.5.3 Modelo 9-6: adición de estadísticas de los estados de las piezas..... 390
9.6 Unos cuantos aspectos diversos del modelado..................................................... 394
9.6.1 Transportadores guiados................................................................ 394
9.6.2 Colas paralelas............................................................................... 394
9.6.3 Lógica de decisión.......................................................................... 396
9.7 Ejercicios............................................................................................................. 396
Capítulo 10: Integración y personalización de Arena............................................................ 403
10.1 Modelo 10-1: lectura y escritura de archivos de datos.......................................... 403

10.1.1 Modelo 10-2: lectura de llegadas de entidades desde un archivo
de texto........................................................................................... 405
10.1.2 Modelo 10-3 y modelo 10-4: lectura y escritura de archivos
Access y de Excel............................................................................ 409
10.1.3 Lectura y escritura avanzadas......................................................... 416
10.2 VBA en Arena..................................................................................................... 419
10.2.1 Panorama general de ActiveX Automation y VBA......................... 420
10.2.2 Eventos VBA integrados en Arena................................................. 421
Contenido xiii
10.2.3 Modelo de objetos de Arena........................................................... 425

10.2.4 Grabador de macros de Arena........................................................ 428
10.3 Modelo 10-5: presentación de las opciones de llegadas al usuario....................... 431
10.3.1 Modificación de la lógica de creación............................................. 432
10.3.2 Diseño de la UserForm de VBA..................................................... 434
10.3.3 Visualización de la forma y establecimiento de los datos
del modelo...................................................................................... 435
10.4 Modelo 10-6: registro y construcción del gráfico de los resultados del
modelo en Microsoft Excel.................................................................................. 442
10.4.1 Montaje de Excel al principio de la ejecución................................. 443
10.4.2 Almacenamiento de los datos de las llamadas por separado
usando el módulo VBA.................................................................. 446
10.4.3 Construcción del gráfico de los resultados y limpieza al final
de la ejecución................................................................................ 448
10.5 Creación de módulos usando la edición profesional de Arena: plantilla 10-1...... 449
10.5.1 Crear a partir del módulo File........................................................ 450
10.5.2 El archivo fuente de plantilla: Template 10-01.tpl........................... 451
10.5.3 Ícono del panel y vista del usuario.................................................. 451
10.5.4 La lógica del módulo y los operandos............................................ 452
10.5.5 Usos de las plantillas...................................................................... 456
10.6 Integración en tiempo real................................................................................... 457
10.8 Ejercicios............................................................................................................. 462
Capítulo 11: Modelos continuos y discretos/continuos combinados.................................. 465
11.1 Modelado de sistemas simples discretos y continuos........................................... 466

11.1.1 Modelo 11-1: un sistema continuo simple....................................... 466
11.1.2 Modelo 11-2: interconexión de la lógica continua y discreta........... 469
11.2 Operación de carga de carbón............................................................................. 473
11.2.2 Método de modelado..................................................................... 474
11.2.3 Modelo 11-3: carga de carbón con el método continuo.................. 477
11.2.4 Modelo 11-4: carga de carbón con proceso de flujo........................ 487
11.3 Sistemas de cambio de estado continuo............................................................... 491
11.3.1 Modelo 11-5: un horno de termodifusión....................................... 491
11.3.2 Modelado de las tasas que cambian en forma continua.................. 492
11.3.3 Método de Arena para resolver ecuaciones diferenciales................ 493
11.3.4 Construcción del modelo................................................................ 494
11.3.5 Definición de las ecuaciones diferenciales con VBA....................... 498
11.4 Resumen y pronóstico......................................................................................... 500
11.5 Ejercicios............................................................................................................. 501
Capítulo 12: Cuestiones estadísticas adicionales................................................................. 505
12.1 Generación de números aleatorios....................................................................... 505

xiv Contenido
12.2 Generación de variables aleatorias....................................................................... 511

12.2.1 Discretas........................................................................................ 511
12.2.2 Continuas....................................................................................... 512
12.3 Procesos de Poisson no estacionarios................................................................... 514
12.4 Reducción de varianza......................................................................................... 516
12.4.1 Números aleatorios comunes.......................................................... 516
12.4.2 Otros métodos................................................................................ 523
12.5 Muestreo secuencial............................................................................................. 524
12.5.1 Modelos de terminación................................................................. 524
12.5.2 Modelos de estado estable.............................................................. 529
12.6 Diseño y ejecución de experimentos de simulación.............................................. 530
12.7 Ejercicios............................................................................................................. 532
Capítulo 13: Realización de estudios de simulación............................................................. 535
13.1 Un estudio exitoso de simulación . ...................................................................... 535

13.2 Formulación del problema................................................................................... 538
13.3 Metodología de solución..................................................................................... 539
13.4 Especificación del sistema y la simulación............................................................ 540
13.5 Formulación y construcción del modelo.............................................................. 544
13.6 Verificación y validación...................................................................................... 546
13.7 Experimentación y análisis.................................................................................. 548
13.8 Presentación y conservación de resultados........................................................... 550
13.9 Difusión del modelo............................................................................................ 551
Apéndice A: Una especificación funcional para The Washington Post................................ 553
A.1 Introducción........................................................................................................ 553

A.1.1 Organización del documento.......................................................... 553
A.1.2 Objetivos de la simulación.............................................................. 553
A.1.3 Propósito de la especificación funcional......................................... 554
A.1.4 Uso del modelo.............................................................................. 554
A.1.5 Requerimientos de hardware y software......................................... 555
A.2 Descripción del sistema y enfoque de modelado.................................................. 555
A.2.1 Cronología del modelo................................................................... 555
A.2.2 Rotativas........................................................................................ 555
A.2.3 Tipos de producto.......................................................................... 557
A.2.4 Líneas de empaque de las rotativas................................................. 557
A.2.5 Sistema de bandejas........................................................................ 557
A.2.6 Llegadas de los camiones............................................................... 559
A.2.7 Puertos........................................................................................... 559
A.2.8 Entarimadores................................................................................ 560
A.2.9 Proceso de inserción manual........................................................... 560
A.3 Animación........................................................................................................... 562
A.4 Resumen de entradas y salidas............................................................................. 562
Contenido xv
A.4.1 Entrada del modelo........................................................................ 562

A.4.2 Resultados del modelo................................................................... 563
A.5 Entregables del proyecto...................................................................................... 564
A.5.1 Documentación del modelo de simulación..................................... 564
A.5.2 Manual del usuario........................................................................ 564
A.5.3 Validación del modelo.................................................................... 564
A.5.4 Animación...................................................................................... 565
A.6 Aceptación.......................................................................................................... 565
Apéndice B: IIE/RA Problemas de concurso.......................................................................... 567
Apéndice C: Una actualización en probabilidad y estadística.............................................. 569
C.1 Fundamentos de probabilidad............................................................................. 569

C.2 Variables aleatorias............................................................................................. 571
C.2.1 Bases.............................................................................................. 571
C.2.2 Discretas........................................................................................ 572
C.2.3 Continuas....................................................................................... 574
C.2.4 Distribuciones conjuntas, covariancia, correlación e
independencia................................................................................ 575
C.3 Muestreo y distribuciones de muestreo................................................................ 579
C.4 Estimación puntual . ........................................................................................... 580
C.5 Intervalos de confianza........................................................................................ 581
C.6 Pruebas de hipótesis............................................................................................. 583
C.7 Ejercicios............................................................................................................. 584
Apéndice D: Distribuciones de probabilidad de Arena.......................................................... 587
Apéndice E: Instrucciones de instalación del software académico..................................... 603
E.1 Autorización para copiar el software................................................................... 603

E.2 Instalación del software de Arena........................................................................ 603
E.3 Requisitos del sistema.......................................................................................... 604
Referencias . ............................................................................................................................. 605
Índice analítico............................................................................................................................ 609

Acerca de los autores
W. David Kelton es profesor en el Departamento de Análisis Cuantitativo y Gerencia de Ope-

raciones en la University of Cincinnati. Cuenta con títulos en matemáticas de University of
Wisconsin-Madisson y Ohio University, además de doctorados en ingeniería industrial.
Sus intereses en investigación así como sus publicaciones giran en torno a la probabilidad y
la estadística en la simulación, sus aplicaciones y los modelos estocásticos. El autor ha publica-
do ensayos en diversas revistas especializadas.
Actualmente, Kelton es editor de INFORMS Journal on Computing y editor del área de
simulación para Operations Research e IIE Transactions. Además ha participado en la edición
de publicaciones como: Journal of Manufacturing Systems y Simulation.
Este autor ha sido galardonado con el premio del TIMS College on Simulation por el mejor
ensayo sobre simulación; el premio de la división de investigación en operaciones del Institute
of Industrial Engineers (Instituto de Ingenieros Industriales, IIE, por sus siglas en inglés), ade-
más de otros reconocimientos de instituciones del campo de la simulación.
Randall P. Sadowski se desempeña actualmente como gerente de producto en Rockwell Auto-

mation. Antes había laborado en Systems Modeling Corporation en diversos cargos, como di-
rector de relaciones con universidades y vicepresidente de servicios de consultoría, entre otros.
Estudió en Purdue University, en la Escuela de Ingeniería Industrial y en University of Mas-
sachussets. Obtuvo la licenciatura y la maestría en ingeniería industrial de la Ohio University y
el grado de doctor en ingeniería industrial de la Purdue University.
Es autor de más de cincuenta ensayos y artículos técnicos. Además fue presidente de la terce-
ra conferencia internacional sobre investigación en producción y en 1990 presidente general de
la Winter Simulation Conference (Conferencia Invernal sobre Simulación; WSC, por sus siglas
en inglés). El autor forma parte del comité de visitadores para los departamentos de Ingeniería
Industrial en Lehigh University, University of Pittsburg y Ohio University.
Es miembro del Instituto de Ingenieros Industriales IIE y editor de una serie bienal para IE
Magazine, que recibió en 1987 el premio de la IIE, como la publicación más sobresaliente del
campo. Asimismo, ha ocupado múltiples cargos en el IIE.
David T. Sturrock es gerente de producto de simulación en Rockwell Automation. Es respon-

sable del éxito de los productos de simulación en mercados variables como los de alta veloci-
dad, centros de contacto, procesos de negocios, así como pruebas y controles de tiempo real.
El autor ha aplicado técnicas de simulación en áreas de sistemas de transportación, agendas,
centros de contacto, análisis de capacidad, diseño de procesos, cuidado de la salud y controles
de tiempo real.
xviii Acerca de los autores
Obtuvo su licenciatura en ingeniería industrial por The Pennsylvania State University,

con especialización en manufactura y automatización. Durante diez años, trabajó en Inland
Steel Company, donde se desempeñó como ingeniero de la planta. Comenzó a utilizar SIMAN
después de su lanzamiento en 1983. Posteriormente se incorporó a Systems Modeling como
consultor en 1988 y su primera actividad fue “ayudar con el siguiente lanzamiento” y eso ha
hecho desde entonces.
Fue presidente de la WSC en 1999 y ha participado en numerosos proyectos de investiga-
ción. Asimismo, ha escrito una gran cantidad de ensayos y es miembro activo del IIE, AMA,
SEM e INFORMS. Constantemente participa en conferencias alrededor del mundo, que lo
han llevado a aproximadamente 40 países.
Prefacio
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
Rockwell Automation proporcionó tiempo, software, hardware, asistencia técnica y estímulo

moral; los autores, en particular, agradecen al equipo de desarrollo de Arena: Norene Collins,
Cory Crooks, Glenn Drake, Tim Haston, Cynthia Kasales, Judy Kirby, Frank Palmieri, Dave
Takus, Christine Watson y Vytas Urbonavicius, así como a Steve Frank, Judy Jordan, Gavan
Hood, Scott Miller, Dennis Pegden, Jon Phillips, Darryl Starks y Nancy Swets. También agra-
decen a Deb Sadowski por sus textos y por haber sido coautora de las dos primeras ediciones.
También al Department of Quantitative Analysis and Operations Management de la Universi-
ty of Cincinnati, que fue de gran apoyo.
Asimismo, manifiestan su agradecimiento a Gary Lucke y Olivier Girod de The Washington
Post por permitir incluir una especificación de simulación desarrollada para ellos por Roc-
kwell Automation como parte de un proyecto más grande. De igual forma a Pete Kauffman,
Jim McClure, Christos Alexopoulos, Ken Bauer, Diane Bischak, Sherri Blaszkiewicz, Eberhard
Blümel, Mike Branson, Jeff Camm, Colin Campbell, John Charnes, Chun-Hung Chen, Jack
Chen, Russell Cheng, Christopher Chung, Frank Ciarallo, John J. Clifford, Mary Court, Tom
Crowe, Halim Damerdji, Pat Delaney, Mike Dellinger, Darrel Donahue, Ken Ebeling, Neil
Eisner, Gerald Evans, Steve Fisk, Michael Fu, Shannon Funk, Fred Glover, Dave Goldsman,
Byron Gottfried, Frank Grange, Don Gross, John Gum, Tom Gurgiolo, Jorge Haddock, Bill
Harper, Joe Heim, Michael Horward, Arthur Hsu, Eric Johnson, Elena Joshi, Keebom Kang,
Elena Katok, Jim Jelly, Teri King, Gary Kochenberger, Patrick Koelling, David Kohler, Wen-
dy Krah, Bradley Kramer, Michael Kwinn, Jr., Averill Law, Larry Leemis, Marty Levy, Bob
Lipset, Gerald Mackulak, Nancy Markovitch, Deb Mederios, Brian Melloy, Manssorech Mo-
llaghasemi, Ed Mooney, Jack Morris, Jim Morris, Charles Mosier, Marvin Nakayama, Dick
Nance, Barry Nelson, James Patell, Cecil Peterson, Dave Pratt, Mike Proctor, Madhu Rao,
James Reeve, Steve Roberts, Paul Rogers, Ralph Rogers, Tom Rohleder, Jerzy Rozenblit, Salim
Salloum, G. Sathyanarayanan, Bruce Schmeiser, Carl Schultz, Tomas Schulze, Marv Seppanen,
Michael Setzer, David Sieger, Robert Signorile, Julie Ann Stuart, Jim Swain, Mike Taaffe, Lau-
rie Travis, Reha Tutuncu, Wayne Wakeland, Ed Watson, Michael Weng, King Preston White
Jr., Jim Wilson, Irv Winters, Chin-Hang (John) Wu, James Wynne y Stefanos Zenios.
W. David Kelton
University of Cincinnati
david.kelton@uc.edu
Randall P. Sadowski
Rockwell Automation
rpsadowski@ra.rockwell.com
David T. Sturrock
Rockwell Automation
dtsturrock@ra.rockwell.com
La presente edición en español fue posible gracias al apoyo de:

César Acosta Mejía Instituto Tecnológico Autónomo de México
Marco Antonio Montúfar Benítez Universidad Autónoma del Estado de Hidalgo,
Universidad La Salle, Pachuca
José Francisco Tamborero Arnal Universidad de las Américas, Puebla
CAPÍTULO 1
¿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
1.1.1 ¿Qué se está modelando?

La simulación por computadora trata con modelos de sistemas. Un sistema es una instalación
o un proceso real o planeado, como:
< Una planta de manufactura con máquinas, personas, métodos de transporte, bandas
transportadoras y espacio de almacenamiento.
< Un banco con diferentes tipos de clientes, servidores e instalaciones como ventanillas de
cajeros, cajeros automáticos (ATM, por sus siglas en inglés), mesas de préstamos y cajas
de seguridad para depósitos.
< Un aeropuerto con pasajeros que facturan, que pasan por seguridad y que van a la
puerta de embarque y embarcan; vuelos de salida que compiten por los remolcadores
de empuje y de retorno y por la asignación de franjas horarias en las pistas de aterrizaje
y despegue; vuelos de llegada que compiten por pistas, puertas y personal de llegada;
pasajeros que acaban de aterrizar y se dirigen a las bandas de entrega de equipaje para
esperar sus maletas; y el sistema de manejo de equipajes que trata con retrasos, seguri-
dad y fallas.
< Una red de distribución de plantas, almacenes y enlaces de transporte.
< Las instalaciones de urgencias de un hospital, incluido el personal, las habitaciones, el
equipo, los suministros y el transporte de los pacientes.
< Una operación de servicio para electrodomésticos o equipo de oficina, con clientes po-
tenciales dispersos por toda una zona geográfica, técnicos de servicio con diferentes
calificaciones, camiones con diferentes partes y herramientas, un almacén central y un
centro de consignación de mercancías.
< Una red de computadoras con servidores, clientes, unidades de disco, unidades de cintas
magnéticas, impresoras, redes y operadores.
< Un sistema de autopistas de segmentos de carreteras, cruces, controles y tráfico.
< Una oficina central de reclamaciones de seguros donde las personas y las máquinas reci-
ben, revisan, copian, archivan y envían por correo una gran cantidad de papeles.
< Un sistema de justicia de tribunales, jueces, personal de apoyo, funcionarios de libertad
probatoria, agentes de libertad condicional, abogados, demandantes, delincuentes decla-
rados culpables y horarios.
< Una planta de productos químicos con tanques de almacenamiento, tuberías, reactores
y carros tanque ferroviarios para enviar el producto terminado.
< Un restaurante de comida rápida con diferentes tipos de personal, clientes y equipo.
< Un supermercado con control de inventarios, cajas y servicio al cliente.
< Un parque temático con atracciones, tiendas, restaurantes, trabajadores, visitantes y es-
tacionamientos.
< La respuesta del personal de emergencia cuando ocurre una catástrofe.
Las personas a menudo estudian un sistema para medir su desempeño o mejorar su opera-
ción, o diseñarlo si es que no existe. A los gerentes o controladores de un sistema también les
gustaría tener ayuda disponible para las operaciones cotidianas, como decidir qué hacer en una
fábrica si una máquina importante se avería.
También existen gerentes que solicitan la construcción de simulaciones, aunque en realidad
no les importan los resultados finales; su objetivo principal fue enfocarse en entender cómo
funcionaba su sistema. Muchas veces los analistas de simulación encuentran que el proceso
para definir el funcionamiento del sistema (lo cual debe hacerse antes de que se pueda empezar
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.
1.1.2 ¿Y si sólo se juega con el sistema?

Podría ser posible experimentar con el sistema físico actual; por ejemplo:
< Algunas ciudades instalaron semáforos en las rampas de acceso en sus sistemas de au-
topistas para experimentar con secuencias diferentes y encontrar los ajustes que hagan
tranquila y segura la hora de más tráfico.
< Un administrador de supermercado puede probar diferentes políticas para un control de
inventarios y de tareas de los cajeros para ver qué combinaciones son las más rentables
y las que proporcionan el mejor servicio.
< Una línea aérea puede examinar el uso extendido de los módulos de facturación y che-
queo automático (y que los empleados instaran a los pasajeros a usarlos) para ver si ello
acelera la facturación.
< Una instalación de computadoras puede experimentar con diferentes diseños de redes
y prioridades de trabajo para ver cómo éstos afectan el uso y tiempo de respuesta de la
máquina.
Este enfoque tiene sus ventajas. Si se puede experimentar de manera directa con el sistema y
saber que nada más con respecto a él cambiará significativamente, sin duda se está analizando
lo correcto y no hay que preocuparse de que un modelo o aproximación del sistema lo imite con
exactitud para sus propósitos.
1.1.3 A veces no se puede (o no se debe) jugar con el sistema

En muchos casos es simplemente muy difícil, costoso o casi imposible hacer estudios físicos del
mismo sistema.
< Obviamente, no se puede experimentar con diseños alternativos de una fábrica si ésta
aún no se construye.
< Incluso en una fábrica ya existente, puede ser muy costoso cambiar a un diseño experi-
mental que quizá no funcione.
< Sería difícil atender al doble de clientes de un banco para ver el efecto que puede causar
el cierre de una sucursal cercana.
< Probar un nuevo proceso de facturación en un aeropuerto puede causar que muchas
personas pierdan su vuelo si existen problemas imprevistos con el nuevo proceso.
< En un hospital, está claro que no se perderá el tiempo con el personal de una sala de
emergencias.
En estas situaciones se debe construir un modelo que sirva como suplente para estudiar el
sistema y hacer preguntas pertinentes acerca de qué es lo que pasaría en el sistema si se hiciera
una u otra cosa o si se diera una situación que estuviera más allá de su control. Nadie resulta
Capítulo 1
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.1.4 Modelos físicos

Hay muchos tipos de modelos. Quizá lo primero que evoca la palabra “físicos” es una réplica
física o un modelo a escala del sistema, a veces llamado modelo icónico. Por ejemplo:
< Las personas han construido modelos de escritorio de sistemas de manejo de materiales
que son versiones miniatura de la instalación, como los aparatos de trenes eléctricos,
para considerar el efecto de los diseños alternativos, las rutas vehiculares y el equipo de
transporte en el desempeño.
< En Swart y Donno (1981) se describió una versión de tamaño real de un restaurante de
comida rápida colocado dentro de un almacén para experimentar con diferentes proce-
dimientos de servicio. De hecho, la mayoría de las grandes cadenas de comida rápida
ahora tienen restaurantes de tamaño real en sus edificios de oficinas corporativas para
experimentar con nuevos productos y servicios.
< Los cuartos de control simulado han sido desarrollados para capacitar a los operadores
de las plantas de energía nuclear.
< Los simuladores físicos de vuelo se usan extensivamente para entrenar pilotos. También
hay programas de computadora para simulación de vuelos (con los que usted puede es-
tar familiarizado en su versión de juegos), que representan modelos lógicos puros que se
ejecutan dentro de una computadora. Más aún, los simuladores físicos de vuelo pueden
tener pantallas de computadora para imitar acercamientos al aeropuerto, de modo que
tengan elementos tanto de modelos físicos como de simulación por computadora.
Aunque los modelos icónicos han demostrado ser útiles en muchas áreas, no se considerarán
aquí.
1.1.5 Modelos lógicos (o matemáticos)

En lugar de los modelos icónicos se considerarán los modelos de sistemas lógicos (o matemáti-
cos). Este tipo de modelo es sólo un conjunto de aproximaciones y suposiciones estructurales y
cuantitativas, acerca de la forma en que funciona o funcionará el sistema.
Por lo general, un modelo lógico se representa en un programa por computadora que se ejecu-
ta para plantear preguntas acerca del comportamiento del modelo; si el modelo es una represen-
tación válida del sistema, también se deseará saber sobre el comportamiento del mismo. Puesto
que se está tratando con un simple programa de computadora más que con el sistema real, por
lo general es fácil, barato y rápido obtener respuestas a muchas preguntas acerca del modelo y
del sistema mediante el simple manejo de las entradas y la forma del programa. Por lo tanto,
se pueden cometer errores en la computadora, en donde no cuentan, más que en la realidad en
donde sí tienen repercusiones. Como en muchos otros campos, los recientes y drásticos aumentos
de potencia de las computadoras (y la disminución en sus costos) han desarrollado de un modo
impresionante su habilidad para llevar a cabo análisis computacionales de modelos lógicos.
1
Bueno, casi nunca.
1.1.6 ¿Qué es lo que se hace con un modelo lógico?

Después de hacer las aproximaciones y de señalar las suposiciones para un modelo lógico y válido
del sistema objetivo hay que encontrar una manera de tratar con el modelo y analizar su compor-
tamiento.
Si el modelo es lo bastante simple, se debe poder usar herramientas matemáticas tradicionales
como la teoría de colas, métodos de ecuaciones diferenciales o algo como la programación lineal
para obtener las respuestas que se necesitan. Ésta es una situación agradable puesto que se deberían
obtener fórmulas lo suficientemente sencillas para responder a las preguntas, lo cual puede eva-
luarse con facilidad de forma numérica; trabajar con la fórmula (por ejemplo, tomar derivadas
parciales de ella en relación a parámetros controlables de entrada) podría proporcionar un
entendimiento en sí misma. Aun cuando no se obtenga una fórmula sencilla de forma cerrada,
sino un algoritmo para generar respuestas numéricas, se tendrán respuestas exactas (hasta re-
dondeo, de cualquier forma) más que estimados, que están sujetos a la incertidumbre.
Sin embargo, la mayoría de los sistemas que las personas modelan y estudian son bastante
complicados, así que sus modelos válidos2 también son bastante complicados. Es posible que
para esos modelos no haya soluciones matemáticas exactas resueltas, y es ahí donde entra la
simulación.
1.2 Simulación por computadora

La simulación por computadora se refiere a los métodos para estudiar una gran variedad de mo-
delos de sistemas del mundo real mediante la evaluación numérica al usar un software diseñado
para imitar las operaciones o características del sistema, a menudo en el transcurso del tiempo.
Desde un punto de vista práctico, la simulación es el proceso de diseñar y crear un modelo
computarizado de un sistema real o propuesto con la finalidad de llevar a cabo experimentos
numéricos que den un mejor entendimiento del comportamiento de dicho sistema en un con-
junto dado de condiciones. Aunque se puede usar para estudiar sistemas sencillos, el poder real
de esta técnica surge cuando se usa para estudiar sistemas complejos.
Mientras que la simulación quizá no sea la única herramienta a usar para estudiar el mo-
delo, con frecuencia es el método elegido. La razón es que el modelo de simulación puede
permitirse una gran complejidad si se necesita para representar al sistema con exactitud, e in-
cluso seguir haciendo análisis de la simulación. Otros métodos llegan a requerir suposiciones de
simplificación mucho más robustas acerca del sistema, para permitir un análisis, lo cual puede
cuestionar la validez del modelo.
1.2.1 Popularidad y ventajas

Durante las últimas dos o tres décadas se ha reportado consistentemente que la simulación es
la herramienta de investigación de operaciones más popular:
< Rasmussen y George (1978) cuestionaron a los graduados de ciencias del Departamento
de investigación de operaciones de la Universidad Case Western Reserve (de los cuales
hay muchos ya que el departamento ha estado ahí durante largo tiempo) acerca del valor
de los métodos después de su graduación. Los primeros cuatro métodos fueron análisis
estadístico, pronósticos, análisis de sistemas y sistemas de información, los cuales son cate-
gorías muy amplias y generales. La simulación fue el siguiente método y se clasificó más
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
arriba que otras herramientas de investigación de operaciones más tradicionales como

la programación lineal y la teoría de colas.
< Thomas y DaCosta (1979) les entregaron a analistas de 137 grandes empresas una lista
de herramientas y les pidieron mencionar las que usaban. El análisis estadístico ocupó el
primer lugar con 93% de las empresas que reportaron su uso (es difícil imaginar una gran
empresa que no lo haga) seguido por la simulación (84%). De nuevo, la simulación estu-
vo en una posición más alta que herramientas como programación lineal, PERT/CPM,
teoría de inventarios y programación no lineal.
< Shannon, Long y Buckles (1980) encuestaron a miembros de la División de investigación
de operaciones del Instituto Estadounidense de Ingenieros Industriales (ahora el Insti-
tuto de Ingenieros Industriales) y encontraron que entre las herramientas listadas, la si-
mulación se posicionó en primer lugar tanto en utilidad como en interés y fue la segunda
en cuanto a familiaridad, detrás de la programación lineal, lo cual puede indicar que la
simulación debiera recibir mayor énfasis en el currículo académico.
< Forgionne (1983); Harpell, Lane y Mansour (1989) y Lane, Mansour y Harpell (1993)
reportan que el análisis estadístico fue el primero y la simulación el segundo en térmi-
nos del uso de métodos por profesionales en grandes empresas. Sin embargo, una vez
más los currículos académicos parecían ir a la zaga dado que la programación lineal se
enseñaba con mayor frecuencia que la simulación, aunque ésta era más usada por los
profesionales.
< Morgan (1989) estudió muchos de los tipos de las encuestas mencionadas y reportó que
con frecuencia se encontraba el uso “pesado” de la simulación. Aun en una industria con
el uso más bajo de herramientas de investigación de operaciones (autotransportes), la
simulación se posicionó en el primer lugar de uso.
La principal razón de la popularidad de la simulación es su capacidad para tratar con mo-
delos muy complicados de los sistemas complicados correspondientes. Esto la hace una herra-
mienta versátil y poderosa. Otra razón de la creciente popularidad de la simulación es el mejo-
ramiento obvio en la proporción desempeño/precio del hardware, al hacerla más rentable para
lograr lo que hasta hace pocos años era cómputo de costo prohibitivo. Por último, los avances
en el poder, la flexibilidad y la facilidad de uso del software de simulación han trasladado el en-
foque desde la esfera de la programación tediosa, proclive a errores y de bajo nivel a un campo
de toma de decisiones rápidas y válidas.
La conjetura es que actualmente la popularidad y la efectividad de la simulación son aún
mayores que las reportadas en las encuestas descritas arriba, debido precisamente a dichos
avances en hardware y software.
1.2.2 Las malas noticias

Con todo, la simulación tampoco es totalmente el paraíso.
Puesto que muchos sistemas reales están afectados por entradas aleatorias e incontrolables,
muchos modelos de simulación involucran componentes de entrada aleatorios o estocásticos,
ocasionando que sus salidas también sean aleatorias. Por ejemplo, un modelo de un centro de
distribución podría tener llegadas, salidas y tamaños de lotes surgiendo de manera aleatoria
de acuerdo con distribuciones particulares de probabilidad, lo cual se propagará a través de
la lógica del modelo causando que las mediciones del desempeño de salida, como la razón
de procesamiento de trabajos (Throughput) y tiempos de ciclo, también sean aleatorias. Así
que, ejecutar una simulación estocástica una vez es como desarrollar un experimento físico al
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?).
1.2.3 Diferentes tipos de simulaciones

Hay muchas maneras de clasificar modelos de simulación, pero una forma útil es a través de
estas tres dimensiones:
< Estático contra dinámico: El tiempo no desempeña un papel natural en los modelos está-
ticos pero sí en los dinámicos. El problema de la aguja de Buffon, descrito al principio de
la sección 1.3.1, es una simulación estática. El pequeño modelo de manufactura descrito
en los capítulos 2 y 3 es un modelo dinámico. La mayoría de los modelos operativos son
dinámicos y Arena se diseñó con ellos en mente, así que la atención principal se centrará
en ellos (en la sección 2.7.1 se desarrolla un modelo estático).
< Continuo contra discreto: En un modelo continuo el estado del sistema puede cambiar
continuamente en el tiempo; un ejemplo es el nivel de una presa conforme entra y sale el
agua, y conforme suceden la precipitación y la evaporación. Sin embargo, en un modelo
discreto el cambio puede ocurrir sólo en puntos separados en el tiempo, tal como un
sistema de fabricación con partes que llegan y se van en tiempos específicos, máquinas
que se apagan y encienden en momentos específicos y descansos para los trabajadores.
Usted puede tener elementos tanto del cambio continuo como del discreto en el mismo
modelo, el cual recibe el nombre de modelo combinado continuo-discreto; un ejemplo es
una refinería cuya presión cambia continuamente dentro de los recipientes y tiene cierres
de ocurrencia discreta. Arena puede manejar modelos continuos, discretos y combina-
dos; en la mayor parte del libro se centra la atención en modelos discretos, aunque en el
capítulo 11 se analizan modelos continuos y combinados.
< Determinista contra estocástico: Los modelos que no tienen entradas aleatorias son de-
terministas; la operación estricta de una agenda de citas con tiempos de servicio fijos
es un ejemplo. Por otra parte los modelos estocásticos, operan con al menos algunas
Capítulo 1
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 Cómo se hace la simulación

Si ya se determinó que es apropiada determinada simulación, después se debe decidir cómo
llevarla a cabo. En esta sección se analizan las opciones para ejecutar una simulación, incluido
el software.
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
Figura 1-1. El problema de la aguja de Buffon

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
1.3.2 Programación en lenguajes con un propósito general

Cuando aparecieron las computadoras digitales en las décadas de 1950 y 1960, las personas
comenzaron a escribir programas de computadora en lenguajes de procesamiento de propósito
general, como FORTRAN, para hacer simulaciones de sistemas más complicados. Los paque-
tes de apoyo fueron escritos para ayudar con las tareas de rutina, como el procesamiento de
listas, el mantenimiento del rastro de eventos simulados y la contabilidad de estadísticas.
Este enfoque fue muy adaptable y flexible (en términos de los tipos de modelos y manipu-
laciones posibles), pero también tedioso y propenso a errores, ya que los modelos debían ser
codificados desde el principio cada vez. (Además, si usted deja caer su mazo de cartas, le llevará
algún tiempo reconstruir su “modelo”.) Para una historia más detallada de los lenguajes de
simulación de eventos discretos, consulte Nance (1996) y Nance y Sargent (2003).
Como un tipo de descendiente de la simulación con lenguajes de programación de uso
general, a veces las personas usan software de hojas de cálculo para algunos tipos de simu-
lación. Ello ha sido popular en modelos estáticos, quizá con añadiduras para facilitar las
operaciones comunes y para proporcionar herramientas de mayor calidad (como generadores
de números aleatorios) que lo habitual en las hojas de cálculo. Pero para todos, excepto para
los modelos dinámicos más sencillos, las limitantes inherentes a las hojas de cálculo las hacen
difíciles (en el mejor de los casos) y, por lo general, prácticamente imposibles para usarlas en
simulaciones de modelos grandes, reales y dinámicos. La sección 2.7 ilustra brevemente dos
ejemplos de simulación con hojas de cálculo.
1.3.3 Lenguajes de simulación

Los lenguajes de simulación de propósito especial como GPSS, Simscript, SLAM y SIMAN
aparecieron en escena hace algún tiempo y proporcionaron un mejor marco para los tipos de
simulaciones que las personas hacen. Los lenguajes de simulación se hicieron muy populares
y todavía se usan.
No obstante, hay que invertir un tiempo para aprender sobre sus características y su uso
eficaz. De acuerdo con la interfaz del usuario que se proporcione, puede haber idiosincrasias
delicadas, aparentemente arbitrarias y ciertamente frustrantes, que perjudican incluso a las ma-
nos expertas.
1.3.4 Simuladores de alto nivel

Así surgieron varios productos de “simuladores” de alto nivel que son muy fáciles de usar.
Por lo general operan mediante interfases intuitivas del usuario, gráficas, menús y diálogos. Se
seleccionan a partir de construcciones disponibles de modelación de simulación, se conectan y
ejecutan el modelo junto con una animación gráfica dinámica de los componentes del sistema
conforme se mueven alrededor y cambian.
Sin embargo, los dominios de muchos simuladores están bastante restringidos (como fa-
bricación o comunicaciones) y por lo general no son tan flexibles para desarrollar modelos
válidos de sus sistemas. Algunas personas sienten que estos paquetes han llegado muy lejos en
la cadena alimentaria de la jerarquía del software y han dejado de lado mucha flexibilidad en
pos de conseguir un uso fácil.
1.3.5 En dónde encaja Arena

Arena combina la facilidad de uso de los simuladores de alto nivel con la flexibilidad de los
lenguajes de simulación y recorre todo el camino hacia abajo de los lenguajes de procesa-
miento de propósito general como el sistema de programación Microsoft® Visual Basic® o C
¿Qué es la simulación? 11
si realmente lo quiere. Lo hace así al proporcionar plantillas alternativas e intercambiables

de modelación de simulación gráfica y módulos de análisis que se pueden combinar para
desarrollar una amplia variedad de modelos de simulación. Para una mayor visualización
y organización, los módulos están por lo general agrupados en paneles para componer una
plantilla. Al cambiar los paneles se obtiene acceso a un conjunto completamente diferente
de construcciones y capacidades de modelado de simulación. En la mayoría de los casos, los
módulos de diferentes paneles pueden mezclarse en el mismo modelo.
Arena mantiene su flexibilidad de modelación al ser totalmente jerárquico, como se demues-
tra en la figura 1-2. En cualquier momento puede utilizar los módulos de bajo nivel del panel
Bloques y elementos, y tener acceso a la flexibilidad del lenguaje de simulación y mezclar las
construcciones de SIMAN con módulos de más alto nivel de otras plantillas (Arena se basa en
el lenguaje de simulación SIMAN y lo incluye; consulte Pedgen, Shannon y Sadowski, 1995,
para un análisis completo de SIMAN). Para necesidades especializadas, como algoritmos com-
Más alto Plantillas creadas por el usuario

Construcciones usadas comúnmente,
procesos específicos para la empresa,
plantillas específicas para la empresa, Una sola
etc. interfaz gráfica
consistente
del usuario en
Plantillas de solución de aplicaciones cualquier nivel
Centros de contacto, de modelación
líneas de empaque,
cuidado de la salud,
aeropuertos,
etc.
Panel de procesos básicos

Muchas construcciones comunes de mode-
lación
Muy accesible, fácil de usar,
Nivel de
flexibilidad razonable
modelación
Proceso avanzado, paneles de transfe-

rencia avanzada
Acceso a una modelación más detallada
para una mayor flexibilidad
Bloques, paneles de elementos

Toda la flexibilidad del lenguaje de simu-
lación SIMAN
Visual Basic escrito por el usuario, código

C/C++
Lo último en flexibilidad
Más bajo VBA incluido
C/C++ requiere un compilador
Figura 1-2. Estructura jerárquica de Arena

12 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.
1.4 Cuándo se usan las simulaciones

A medida que las capacidades y sofisticación de los lenguajes y paquetes de simulación han
aumentado dramáticamente durante los últimos 40 a 50 años, ha cambiado el concepto de
cómo y cuándo usar la simulación. Para un relato minucioso del desarrollo de la simulación por
computadora en general, consulte Nance y Sargent (2003).
1.4.1 Los primeros años

A finales de las décadas de 1950 y 1960, la simulación era una herramienta muy costosa y espe-
cializada que por lo general se usaba sólo en las grandes corporaciones que requerían sustan-
ciales inversiones de capital. Los usuarios de simulación típicos se encontraban en las empresas
de acero y aeroespaciales. Estas organizaciones formaron grupos de personas, en su mayoría
con doctorado, que desarrollaron los grandes y complejos modelos de simulación al usar los
lenguajes disponibles, tales como FORTRAN. Estos modelos se ejecutaron luego en enormes
unidades de cómputo que costaban de 600 a 1 000 dólares por hora. Es interesante destacar que
las computadoras personales que están sobre los escritorios de la mayoría de los ingenieros hoy
en día son mucho más poderosas y rápidas que las unidades principales de la década de 1960.
1.4.2 Los años de formación

El uso de la simulación tal y como se conoce ahora comenzó durante la década de 1970 y princi-
pios de la de 1980. Las computadoras se hicieron más rápidas y baratas, y el valor de la simulación
empezó a ser descubierto por otras industrias, aunque la mayoría de las empresas eran todavía
bastante grandes. Sin embargo, rara vez se consideró la simulación hasta que hubo un desastre y
se convirtió en la herramienta elegida por muchas empresas, sobre todo en las industrias automo-
triz y pesada, para determinar por qué ocurrió el desastre y, a veces, para ver a quién culpar.
Se recuerda el inicio de una línea de ensamble automotriz (una inversión de más de 100
millones de dólares) que no conseguía mucho de su potencial. La línea producía un vehículo
de reciente diseño que tenía una gran demanda: mucho más grande de la que pudiera satisfa-
cerse con la producción existente de la línea. La administración designó a un equipo FODA
para analizar el problema, el cual rápidamente estimó que la ganancia potencial perdida era de
¿Qué es la simulación? 13
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.3 El pasado reciente

A finales de la década de 1980, la simulación comenzó a establecer sus raíces reales en los ne-
gocios, en gran parte gracias a la introducción de la computadora personal y de la animación.
Aunque la simulación aún se utilizaba para analizar sistemas fallidos, muchas personas la soli-
citaban antes de que comenzara la producción. (Sin embargo, en la mayoría de los casos ya era
muy tarde para afectar el diseño del sistema, pero sí ofrecía al administrador de la planta y al
diseñador del sistema la oportunidad de arreglar su historial laboral.) Al final de la década de
1980, el valor de la simulación comenzó a reconocerse en muchas empresas grandes, varias de
las cuales hicieron de la simulación un requisito antes de aprobar cualquier inversión de capital
importante. No obstante, la simulación no tenía un uso extendido y rara vez se usaba en em-
presas más pequeñas.
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
Conceptos principales de simulación
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
Figura 2-1. Un sistema de procesamiento sencillo

16 Capítulo 2
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).
Número de parte Tiempo de llegada Tiempo entre llegadas Tiempo de servicio

1 0.00 1.73 2.90
2 1.73 1.35 1.76
3 3.08 0.71 3.39
4 3.79 0.62 4.52
5 4.41 14.28 4.46
6 18.69 0.70 4.36
7 19.39 15.52 2.07
8 34.91 3.15 3.36
9 38.06 1.76 2.37
10 39.82 1.00 5.38
11 40.82 • •
• • • •
• • • •
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
Se decidió que la simulación se detenga en un tiempo exacto de 20 minutos. Si existen

partes presentes en ese momento (en servicio en la perforadora o en espera en cola), nunca se
terminan.
2.1.2 Metas del estudio

Dado un modelo lógico/numérico como éste, se debe decidir después qué medidas de desempe-
ño de los resultados se desean recopilar. Esto es lo que se calcula aquí:
< La producción total (número de partes que completan su servicio en la perforadora y se
van) durante los 20 minutos de operación. Se supone que más es mejor.
< El tiempo promedio de espera en la cola de las partes que entran en la perforadora duran-
te la simulación. Este tiempo en la cola registra sólo el tiempo que una parte espera en
la cola y no el tiempo que invierte en el servicio de la perforadora. Si WQi es el tiempo
de espera en la cola de la i-ésima parte y resulta que N partes dejan la cola durante la
ejecución de 20 minutos, este promedio es
N

∑ 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) = ∙ 01 sisi lala perforadora

perforadora está ocupada en el tiempo t
está desocupada en el tiempo
El uso es el área debajo de B(t), dividida entre la longitud de la ejecución:

20
∫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.
2.2 Opciones de análisis

Con el modelo, sus entradas y sus resultados definidos se debe explicar cómo obtener los re-
sultados al transformar las entradas de acuerdo con la lógica del modelo. En esta sección se
exploran brevemente algunas opciones para hacerlo.
2.2.1 Conjetura educada

Aunque los autores no son muy fanáticos de la conjetura, un cálculo escueto “a grandes rasgos”
a veces puede llevar al menos a una perspectiva cualitativa (y a veces no). La manera en que
ocurre esto depende, por supuesto, de la situación (y de cuán bueno se sea en la conjetura).
Un posible primer corte en nuestro ejemplo es observar la afluencia promedio y las tasas
de procesamiento. De la tabla 2-1 resulta que el promedio de 10 tiempos entre llegadas es de
4.08 minutos y el promedio de los 10 requisitos de servicio es de 3.46 minutos. Esto parece
alentador, puesto que las partes reciben el servicio más rápido que conforme llegan, por lo
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.
2.2.2 Teoría de colas

Ya que existe una cola, ¿por qué no usar una teoría de colas? Ha estado a nuestro alrededor
durante casi un siglo y muchas personas muy brillantes han trabajado duro para desarrollarla.
En algunas situaciones puede resultar en fórmulas sencillas que usted puede entender.
Tal vez el objeto más simple y popular de la teoría de colas es la cola M/M/1. La primera
“M” señala que el proceso de llegada es Markoviano; esto es, los tiempos entre llegadas son
independientes y algo como “dibujos” distribuidos de forma idéntica de una distribución de
probabilidad exponencial (véanse apéndices C y D para una breve actualización en probabi-
lidad y distribuciones). La segunda “M” representa la distribución del tiempo del servicio,
la cual también es exponencial. El “1” indica que hay un único servidor. Así que al menos
superficialmente le queda bastante bien a este modelo.
Mejor aún, la mayoría de las mediciones de desempeño de los resultados se pueden expresar
como fórmulas sencillas. Por ejemplo, el tiempo de espera promedio en la cola (esperado de una
ejecución larga) es
μS2
μA − μS
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.2.3 Simulación mecánica

Todo esto nos trae de vuelta a la simulación. Por “mecánica” se entiende que las operaciones
individuales (llegadas, servicio en la perforadora, etc.) ocurrirán como lo harían en la realidad.
Los movimientos y cambios de las cosas en el modelo de simulación ocurren en el “momento”
adecuado y en el orden correcto, y tienen los efectos indicados en cada uno y en las variables de
acumuladores estadísticos.
Así, la simulación proporciona una forma concreta, “fuerza bruta” de tratar directamente
con el modelo. No hay nada misterioso acerca de cómo funciona, sólo unas cuantas ideas bási-
cas y muchos detalles y contabilidad que un software como Arena maneja por usted.
2.3 Piezas de un modelo de simulación

En esta sección se hablará de varias partes de un modelo de simulación, con referencia al ejem-
plo.
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-
Figura 2-2. Un demonio de falla victorioso
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.3 Variables (globales)

Una variable (o variable global) es información que refleja alguna característica de su siste-
ma, sin importar cuántos o qué tipos de entidades haya alrededor. Usted puede tener muchas
variables diferentes en un modelo, pero cada una es única. Existen dos tipos de variables: las
22 Capítulo 2
incorporadas en Arena (número en la cola, número de servidores ocupados, tiempo en el reloj

de la simulación actual, etc.) y las definidas por el usuario (tiempo de servicio medio, tiempo
de traslado, turno actual, etc.). Al contrario que los atributos, las variables no están unidas a
ninguna entidad específica, sino más bien pertenecen al sistema en su conjunto. Tienen acceso
para todas las entidades y muchas se pueden cambiar por cualquier entidad. Si usted piensa en
los atributos como etiquetas añadidas a las entidades que flotan en la actualidad por el cuarto,
entonces piense en las variables como escritura (capaz de rescribirse) en la pared.
Las variables se usan para muchos propósitos. Por ejemplo, el tiempo para moverse entre
dos estaciones de un modelo podría ser el mismo en todo el modelo, y una variable llamada
Tiempo de transferencia podría definirse y fijarse a un valor apropiado y después usarse
en donde sea que se necesite; en un modelo modificado en donde este tiempo se fija a una cons-
tante diferente, usted sólo necesitaría cambiar la definición de Tiempo de transferencia
para cambiar su valor en todo el modelo. Las variables también pueden representar algo que
cambia durante la simulación, como el número de partes en cierta área de subensamble en un
modelo más grande que se incrementa en una unidad cuando una entidad entra en el área y
que disminuye una unidad cuando deja la misma. Las variables de Arena pueden ser vectores
o matrices si es conveniente organizar la información como listas o tablas de dos dimensiones
de valores individuales.
Algunas variables incorporadas en Arena para nuestro modelo incluyen el estado de la per-
foradora (ocupada o no), el tiempo (reloj de la simulación) y la longitud actual de la cola.
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.
2.3.6 Acumuladores estadísticos

Para que usted obtenga las mediciones de desempeño de resultados, debe mantener la pista de
algunas variables intermedias de acumuladores estadísticos conforme progrese la simulación. En
el ejemplo se observarán:
< El número de partes producidas hasta el momento.
< El total de los tiempos de espera en la cola hasta el momento.
< El número de partes que pasaron a través de la cola hasta el momento (esto se necesita
como denominador en el promedio de medidas de los resultados de tiempo de espera).
< El mayor tiempo gastado en la cola que se haya observado hasta el momento.
< El total del tiempo gastado en el sistema por todas las partes que han salido hasta el
momento.
< El tiempo más largo en el sistema que se haya observado hasta el momento.
< El área hasta el momento bajo la curva de longitud de la cola Q(t).
< El nivel más alto que Q(t) haya logrado hasta el momento.
< El área hasta el momento debajo de la función de la ocupación del servidor B(t).
Todos estos acumuladores deberían inicializarse en 0. Cuando algo sucede en la simulación,
los acumuladores afectados se deben actualizar de la forma apropiada.
Arena cuida la mayor parte (pero a veces no toda) de la acumulación estadística que es pro-
bable que no se quiera, así que la mayoría de esto será invisible para usted a menos que lo pida
en algunas situaciones. Pero en esta simulación todo se hará de forma manual, para que usted
vea cómo se hace y lo haga en Arena si lo requiere.
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.
2.3.8 Reloj de simulación

El valor actual del tiempo en la simulación se mantiene en una variable llamada reloj de simu-
lación. A diferencia del tiempo real, el reloj de simulación no se encarga de todos los valores ni
fluye de manera continua; más bien va del tiempo de un evento al tiempo del siguiente evento
programado. Puesto que nada cambia entre los eventos, no hay necesidad de desperdiciar tiem-
po (real) analizando el tiempo (simulado) que no importa.
El reloj de simulación interactúa de forma cercana con el calendario de eventos. Al ini-
cio de la simulación, y después de ejecutar cada evento, el registro de la parte alta del calendario
de eventos (siempre el único para el siguiente evento) se retira del calendario. El reloj de simu-
lación oscila hacia adelante al tiempo de ese evento (uno de los campos de datos en el registro
de eventos) y la información del registro de eventos retirado (identificación de entidad, tiempo
del evento y tipo de evento) se usa para ejecutar el evento en ese instante de tiempo simulado.
Cómo se ejecuta el evento depende de qué tipo de evento se trate así como del estado del mo-
delo en ese tiempo, pero en general podría incluir la actualización de variables y acumuladores
estadísticos, la alteración de los atributos de la entidad y la colocación de nuevos registros de
eventos en el calendario.
El reloj de simulación y el calendario de eventos en la simulación manual son piezas im-
portantes de cualquier simulación dinámica, así que Arena mantiene su rastro (el reloj es una
variable llamada TNOW en Arena).
2.3.9 Empezar y parar

Es muy importante cómo empezará y se detendrá la simulación, aunque a veces esto se pasa
por alto. Para este ejemplo se han hecho suposiciones específicas, así que será fácil entender
cómo traducirlas a valores para los atributos, las variables, los acumuladores, el calendario
de eventos y el reloj.
Arena hace muchas cosas de forma automática, pero no puede decidir el modelado de
temas como las reglas de inicio y detención. Usted debe determinar las condiciones de inicio
apropiadas, cuánto debe durar una ejecución y si debe detenerla en un tiempo determinado
(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).
2.4 Simulación manual dirigida por eventos

Se le permitirá a usted tener los detalles rudos de la simulación manual en esta sección, después
de esbozar la acción y de definir cómo seguirle el rastro a las cosas.
2.4.1 Esbozo de la acción

Aquí está cómo van aproximadamente las cosas para cada evento:
< Llegada: Aparece una parte nueva.
w Programe la siguiente parte nueva para que llegue después, en el siguiente tiempo de
llegada, al colocar un nuevo registro de evento para ella en el calendario de eventos.
w Actualice las estadísticas de tiempo continuo (entre el último evento y el nuevo).
w Almacene el tiempo de llegada de la parte que llega (el valor actual del reloj) en un
atributo, el cual se necesitará después para calcular su tiempo total en el sistema y
quizá el tiempo que tarda esperando en la cola.
w Si la perforadora está desocupada, la parte que llega va directa al servicio (experimen-
tando un tiempo en cola igual a cero), así que la perforadora se ocupa y el final del
servicio de esta parte se programa. Haga coincidir el tiempo de esta parte en la cola
(cero).
w Por otro lado, si la perforadora ya está ocupada con otra parte, la que llega se pone al
final de la cola y la variable de longitud de cola se incrementa.
< Salida: La parte con la que trabaja la perforadora está terminada y lista para partir.
w Aumente el acumulador estadístico de producción de números.
w Calcule y haga coincidir el tiempo total en el sistema de la parte que se va al tomar el
valor actual del reloj menos el tiempo de llegada de la parte (almacenado en un atri-
buto durante el evento de llegada).
w Actualice las estadísticas de tiempo continuo.
w Si existe cualquier parte en la cola, saque la primera, calcule y haga coincidir su tiem-
po en la cola (que ahora termina), y comience su servicio en la perforadora al progra-
mar su evento de partida (esto es, colóquelo en el calendario de eventos).
w Por otra parte, si la cola está vacía, entonces desocupe la perforadora. Observe que en
este caso no existe ningún evento programado de partida en el calendario de eventos.
< Fin: Termina la simulación.
w Actualice las estadísticas de tiempo continuo al final de la simulación.
w Calcule y reporte el resumen final de las mediciones de desempeño de los resultados.
26 Capítulo 2
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.
2.4.2 Mantenimiento del rastro de las cosas

Todos los cálculos para la simulación manual se detallan en la tabla 2-2. Los rastros de Q(t) y
B(t) sobre la simulación completa están en la figura 2-3. Cada línea de la tabla 2-2 representa
un evento concerniente a una parte específica (en la primera columna) en un tiempo t (en la
segunda columna) y la situación después de completar la lógica para ese evento (en las otras
columnas). Los otros grupos de columnas son:
< Evento: Describe lo que acaba de pasar; Lleg y Sal significan llegada y salida, respecti-
vamente.
< Variables: Son los valores del número Q(t) de partes en la cola y la función B(t) de la
ocupación del servidor.
< Atributos: Cada tiempo de llegada de la entidad que llega se asigna cuando llega y se
arrastra. Si una parte está en servicio en la perforadora, su tiempo de llegada está en la
orilla derecha de la columna y no entre paréntesis. Los tiempos de llegada de cualquier
parte de la cola, ordenados de derecha a izquierda (para corresponder con la figura 2-1),
se extienden hacia atrás a la izquierda y están entre paréntesis. Por ejemplo, al final de la
ejecución, la parte en servicio llegó en un tiempo de 18.69, y la primera parte (y única)
de la cola llegó en un tiempo de 19.39. Se debe mantener el rastro de esos tiempos para
calcular el tiempo en la cola de una parte cuando entra en la perforadora después de
haber esperado en la cola, así como el tiempo total en el sistema de una parte cuando
ésta se va.
< Acumuladores estadísticos: Debemos iniciarlos y después actualizarlos conforme se avan-
za, para observar lo que sucede. Ellos son:
P = el número total de partes producidas hasta el momento.
N = el número de entidades que han pasado a través de la cola hasta el momento.
∑WQ = la suma de los tiempos de la cola que se han observado hasta el momento.
WQ* = el tiempo máximo en la cola observado hasta el momento.
∑TS = la suma de los tiempos totales en el sistema observados hasta el momento.
TS* = el tiempo total máximo en el sistema observado hasta el momento.
∫Q = el área debajo de la curva Q(t) hasta el momento.
Q* = el máximo valor de Q(t) hasta el momento.
∫B = el área bajo la curva B(t) hasta el momento.
< Calendario de eventos: Registro de eventos como se describió antes. Note que en cada
tiempo del evento el registro de hasta arriba en el calendario de eventos se convierte en
las tres primeras entradas debajo del “evento recién terminado” en la orilla izquierda de
la tabla completa en la siguiente fila, en el siguiente tiempo de evento.
Tabla 2-2. Registro de la simulación manual
Evento finalizado recientemente Variables Atributos Acumuladores estadísticos Calendario de eventos
Entidad Tiempo Tipo de Tiempos de llegada
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]
28 Capítulo 2
Cola de la estación de perforación:

4
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)
Figura 2-3. Curvas de tiempo continuo para la simulación manual
2.4.3 Llevarla a cabo

Éste es un breve relato de la acción:
< t = 0.00, Inic: Se inicia el modelo con todas las variables y acumuladores en 0, la cola
vacía, la perforadora desocupada y el calendario de eventos preparado con la primera
llegada que sucede en el tiempo 0.00 y el fin de la simulación programado para que se
dé en el tiempo 20.00. Para ver lo que sucede después, sólo saque el registro del primer
evento del calendario de evento: la llegada de la entidad 1 en el tiempo 0.00.
< Entidad 1, t = 0.00, Lleg: La llegada de la siguiente (segunda) parte se programa al
crear una entidad parte 2, fijando su tiempo de llegada en el tiempo actual (0) más su
tiempo entre llegadas (1.73, de la tabla 2-1) y colocándola en el calendario de eventos.
Mientras tanto, la parte que llega en este momento (parte 1) ocupa la perforadora y el
tiempo de llegada, 0.00 de esta parte se almacena en su atributo (no entre paréntesis).
La cola aún está vacía porque esta parte encuentra desocupada la perforadora y co-
mienza su servicio de forma inmediata (así que el paréntesis a contener los tiempos de
llegada de las partes en la cola no tiene nada entre ellos). Puesto que la entidad pasó a
través de la cola (con tiempo 0 en la cola), aumenta N y aumenta ∑WQ con el tiempo
de espera en la cola (0), y se revisa para ver si ocurre un tiempo máximo de espera en la
cola (no). No ha habido aún producción, así que P permanece en 0. No se ha observado
todavía ningún tiempo total en el sistema, así que ∑TS y TS* permanecen sin cambios.
Las estadísticas de tiempo continuo ∫Q, Q*, y ∫B permanecen en 0 puesto que no ha
pasado el tiempo. Con referencia a la tabla 2-1, el tiempo de servicio para la parte 1 se
establece en 2.90 minutos y la entidad de la parte 1 se regresa al calendario de eventos.
Al quitar el registro de la parte alta del calendario de eventos, el siguiente evento será la
llegada de la entidad 2 en el tiempo 1.73.
< 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
siguen sin cambios. ∫Q se aumenta por 0 × (3.08 − 2.90) = 0 y ∫B se aumenta por 1

× (3.08 − 2.90) = 0.18. El nuevo valor de Q(t) es 1, que no es mayor que el anterior
Q* = 1, así que se deja Q* = 1 sin cambio. Nosotros no actualizamos el tiempo de la
siguiente salida puesto que aún está (correctamente) programada como el tiempo de
salida de la parte 2, que llegó antes y ahora está parcialmente procesada. El siguiente
evento será la llegada de la parte 4 en el tiempo 3.79.
< Entidad 4, t = 3.79, Lleg: La llegada de la siguiente parte (quinta) se programó para el
tiempo 3.79 + 0.62 = 4.41. La parte que llega ahora (parte 4) se forma en la cola dado
que la perforadora está ocupada; B(t) se mantiene en 1 y la longitud de la cola Q(t) se
incrementó a 2. El tiempo de llegada (3.79) de la parte 4, que está llegando, se almacena
como una característica de esa parte y se coloca al final de la cola (la cola es FIFO); la
parte 2, que llegó en el tiempo 1.73, aún está en servicio. No se está experimentando nin-
guna nueva producción u observación de tiempo en la cola, así que P, N, ∑WQ, WQ*,
∑TS y TS* siguen sin cambios. ∫Q se aumenta por 1 × (3.79 − 3.08) = 0.71 y ∫B se
aumenta por 1 × (3.79 − 3.08) = 0.71. El nuevo valor de Q(t) es 2, que es mayor que el
anterior Q* = 1, así que ahora Q* = 2. No actualizamos el tiempo de la siguiente salida,
dado que está programado (correctamente) como el tiempo de salida de la parte 2. El
siguiente evento será la llegada de la parte 5 en el tiempo 4.41.
< Entidad 5, t = 4.41, Lleg: La llegada de la siguiente parte (sexta) se programa para un
tiempo de 4.41 + 14.28 = 18.69. La parte que llega ahora (parte 5) se une al final de la
cola; B(t) se mantiene en 1, la longitud de la cola Q(t) se incrementa a 3 y la parte 2 con-
tinúa en servicio. Igual que en el evento anterior P, N, ∑WQ, WQ*, ∑TS y TS* siguen
sin cambios. ∫Q se aumenta por 2 × (4.41 − 3.79) = 1.24 y ∫B se aumenta por 1 × (4.41
− 3.79) = 0.62. Q(t) aumentó a 3, un nuevo máximo, así que Q* = 3. El tiempo de la si-
guiente salida aún está programado (correctamente) como el tiempo de salida de la parte
2 en el tiempo 4.66, que ahora flota hacia arriba del calendario de eventos y será el
siguiente evento a ocurrir.
< Entidad 2, t = 4.66, Sal: La parte 2 está hecha y lista para salir. Dado que hay una cola,
la perforadora estará ocupada así que B(t) se mantiene en 1, pero Q(t) disminuyó a 2.
La cola avanza y la primera parte de ella (la parte 3, que llegó en el tiempo 3.08) entrará
en servicio. Ahora se ha completado un tiempo de espera en la cola de duración 4.66 −
3.08 = 1.58 para la parte 3, que se suma a ∑WQ, y N aumenta; éste es un nuevo tiempo
de espera máximo en la cola, así WQ* cambia a 1. Se produce una nueva parte por lo
que P aumenta a 2 y el tiempo total del sistema de la parte 2 se calcula como 4.66 − 1.73
= 2.93, que se aumenta en ∑TS; éste es un nuevo tiempo total máximo del sistema, así
que TS* cambia a 2.93. ∫Q se aumenta en 3 × (4.66 − 4.41) = 0.75 y ∫B se aumenta en
1 × (4.66 − 4.41) = 0.25. No se ha realizado un nuevo máximo para Q(t), así que Q*
no tiene cambios. La siguiente salida (de la parte 3, que ahora está entrando en servicio)
se programa para el tiempo 4.66 + 3.39 = 8.05; no se necesita actualizar el tiempo de la
siguiente llegada. El siguiente evento es la salida de la entidad 3 en el tiempo 8.05.
< Entidad 3, t = 8.05, Sal: La parte 3 sale. La parte 4, primera en la cola, entra en servicio y
agrega su tiempo de espera en la cola 8.05 − 3.79 = 4.26 (un nuevo máximo) a ∑WQ y N
aumenta; B(t) se mantiene en 1 y Q(t) disminuye a 1. El tiempo total en el sistema de la parte
3 es 8.05 −3.08 = 4.97 (un nuevo máximo), que se suma a ∑TS; P aumenta. ∫Q se aumenta
2 × (8.05 − 4.66) = 6.78 y ∫B se aumenta 1 × (8.05 − 4.66) = 3.39; Q* no tiene cambios.
La siguiente salida (de la parte 4, que está entrando en servicio) está programada para el
tiempo 8.05 + 4.52 = 12.57; no se necesita actualizar el tiempo de la siguiente llegada.

El siguiente evento es la salida de la entidad 4 en el tiempo 12.57.
< Entidad 4, t = 12.57, Sal: La parte 4 sale. La parte 5 entra en servicio, suma su tiempo
de espera en la cola 12.57 − 4.41 = 8.16 (un nuevo máximo) a ∑WQ y N aumenta; B(t)
se mantiene en 1 y Q(t) disminuye a 0 (así que la cola se vacía, aunque una parte esté en
servicio). El tiempo total en el sistema de la parte 4 es 12.57 − 3.79 = 8.78 (un nuevo
máximo), que se suma a ∑TS, y P aumenta. ∫Q aumenta 1 × (12.57 − 8.05) = 4.52 y
∫B aumenta la misma cantidad; Q* no tiene cambios. La siguiente salida (de la parte
5, que ahora está entrando en servicio) está programada para el tiempo 12.57 + 4.46
= 17.03; no se necesita actualizar el tiempo de la siguiente llegada. El siguiente evento
es la salida de la entidad 5 en el tiempo 17.03.
< Entidad 5, t = 17.03, Sal: La parte 5 sale. Puesto que la cola está vacía, la perforadora
se desocupa —B(t) se fija en 0— y no se observa un nuevo tiempo de espera en la cola,
así que ∑WQ, WQ* y N se mantienen sin cambios. El tiempo total en el sistema de la
parte 5 es 17.03 − 4.41 = 12.62 (un nuevo máximo), que se suma a ∑TS y P aumenta.
∫Q se aumenta 0 × (17.03 − 12.57) = 0 y ∫B se aumenta 1 × (17.03 − 12.57) = 4.46;
Q* no tiene cambios. Puesto que no hay una nueva parte en servicio en la perforadora,
el calendario de eventos se mantiene sin un evento de salida programado; no se nece-
sita actualizar el tiempo de la siguiente llegada. El siguiente evento es la llegada de la
entidad 6 en el tiempo 18.69.
< Entidad 6, t = 18.69, Lleg: Este evento procesa la llegada de la parte 7 al sistema, que
ahora está vacío de partes y la perforadora está desocupada, así que este es el mismo
escenario que en la llegada de la parte 1 en el tiempo 0; la “experiencia” de la parte 7 es
(probabilísticamente) idéntica a la de la parte 1. La llegada de la siguiente parte (sép-
tima) está programada para el tiempo 18.69 + 0.70 = 19.39. Mientras tanto, la parte
6 que llega ocupa la perforadora, pero la cola sigue vacía porque esta parte encuentra
la perforadora desocupada y comienza el servicio de inmediato. El tiempo de espera en
la cola de la parte 6 es 0, así que N se incrementa a 6, y ∑WQ se “aumenta” en 0, que
ciertamente no es un nuevo tiempo de espera máximo en la cola. Ninguna parte está sa-
liendo, así que no hay cambios en P, ∑TS o TS*. Puesto que Q(t) y B(t) están en 0 desde
el evento anterior, no hay un cambio numérico en ∫Q, ∫B o Q*. La salida de la parte 6
está programada para el tiempo 18.69 + 4.36 = 23.05 (así que no ocurrirá ya que esto
es después de que la simulación termine, como se refleja en el orden del calendario de
eventos actualizado). El siguiente evento es la llegada de la parte 7 en el tiempo 19.39.
< Entidad 7, t = 19.39, Lleg: La llegada de la siguiente parte (octava) está programada
para el tiempo 19.39 + 15.52 = 34.91, que es más allá del tiempo de terminación (20),
así que no sucederá. La parte 8 se forma en la cola, B(t) se mantiene en 1, y Q(t) se incre-
menta a 1 (ningún nuevo máximo). Puesto que no se observa un nuevo tiempo de espera
en la cola, N, ∑WQ y WQ* están sin cambios; ya que ninguna parte sale, P, ∑TS y TS*
no tienen cambios. ∫Q se aumenta en 0 × (19.39 − 18.69) = 0 y ∫B se aumenta en 1 ×
(19.39 − 18.69) = 0.70. La siguiente salida ya está programada de forma adecuada. El
siguiente evento será el final de la simulación en el tiempo 20.
32 Capítulo 2
Tabla 2-3. Medidas de desempeño de resultados finales de la simulación manual
Medidas de desempeño Valores

Producción total 5 partes
Tiempo de espera promedio en la cola 2.53 minutos por parte (6 partes)
Tiempo de espera máximo en la cola 8.16 minutos
Tiempo total promedio en el sistema 6.44 minutos por parte (5 partes)
Tiempo total máximo en el sistema 12.62 minutos
Tiempo promedio del número de partes en la cola 0.79 partes
Número máximo de partes en la cola 3 partes
Uso de la perforadora 0.92 (proporción adimensional)
< 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).
2.5 Simulación orientada a eventos y procesos

La simulación manual con la que lidiamos en la sección 2.4 usa la orientación de eventos ya
que el trabajo de modelado y de cómputo se centra en cuándo ocurren los eventos y qué
sucede cuando ocurren. Esto permite tener el control de cualquier cosa, tener completa fle-
xibilidad respecto a los atributos, las variables y el flujo lógico, y saber el estado completo de
cualquier cosa en cualquier momento. Se observa fácilmente cómo esto podría ser codificado
en cualquier lenguaje de programación o quizá con macros en una hoja de cálculo (sólo para
modelos muy simples), lo cual se ha hecho muchas veces. Para una cosa la computación es
bastante rápida con un código orientado por eventos y escrito a la medida. Mientras que la
orientación de eventos parece muy simple en principio (aunque no muy divertida si es ma-
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
2.6 Aleatoriedad en la simulación

En esta sección analizaremos cómo (y por qué) se modela la aleatoriedad en la entrada del
modelo de simulación y el efecto que puede tener esto en sus resultados. Necesitaremos algo de
probabilidad y estadística, así que este podría ser un buen momento para echarle una mirada
rápida (o una revisión meticulosa) al apéndice C y revisar algunas ideas básicas, terminología
y anotaciones.
2.6.1 Entrada y salida aleatoria

La simulación en la sección 2.4 usó los datos de entrada de la tabla 2-1 para dirigir la simu-
lación registrada en la tabla 2-2, dando como resultado las medidas de desempeño numéricas
de salida reportadas en la tabla 2-3. Quizá esto sucedió de las 8:00 a las 8:20 en una particular
mañana de lunes y si es en lo que usted está interesado, entonces está listo.
Pero tal vez usted esté interesado en más, como qué esperaría ver una mañana “típica”
y cómo los resultados pueden diferir día con día. Puesto que es probable que los tiempos
de llegada y servicio de las partes en otros días difieran de los de la tabla 2-1, el rastro de
la acción en la tabla 2-2 quizá cambiará, así que las medidas de desempeño numéricas de
salida tal vez serán diferentes de las que se obtuvieron en la tabla 2-3. Por lo tanto, una co-
rrida sencilla del ejemplo simplemente no lo hará, dado que no tenemos idea realmente de
cuán “típicos” son nuestros resultados o cuánta variabilidad puede estar asociada con ellos.
En términos estadísticos, lo que se obtiene de una corrida simple de una simulación es una
muestra de tamaño uno, que no sirve de mucho. Podría ser muy imprudente poner mucha fe
en él, y más tomar decisiones importantes basadas sólo en ello. Si usted lanza un dado y sale
un cuatro, ¿concluiría que las demás caras también son cuatro?
Así que la entrada aleatoria parece una maldición. Pero usted debería permitirla a menu-
do para hacer de su modelo una representación válida de la realidad, donde también debe
ser considerablemente incierto. La forma en que por lo general las personas modelan esto, en
lugar de usar una tabla de valores de entrada numéricos, es para especificar distribuciones de
probabilidad a partir de las cuales se generan (o plasman o muestran) las observaciones y dirigen
la simulación con ellas. Hablaremos en la sección 4.4 acerca de cómo usted puede determinar
estas distribuciones de probabilidad de entrada usando el Arena Input Analyzer (analizador
de entrada de Arena). Arena maneja internamente la generación de observaciones a partir de
las distribuciones que usted especifique. No sólo esto hace su modelo más realista, sino que
también le da la libertad de hacer más simulaciones de las que usted pudiera tener con datos
observados y explorar simulaciones que usted no observó. Como es tediosa la generación de
observaciones de entrada y hacer la simulación lógica, Arena (y las computadoras) lo hará por
usted.
Pero la entrada aleatoria también induce la aleatoriedad en la salida. Exploraremos esto
más en el resto de este capítulo, pero se abordará con mayor detalle en el capítulo 6, en la
sección 7.2 y en el capítulo 12, y se mostrará cómo usar el analizador de salida de Arena, el
analizador de proceso y el OptQuest®, de OptTek Systems, para ayudar a interpretar y en-
frentar la aleatoriedad en la salida.
2.6.2 Repetición del ejemplo

Es tiempo de decir verdades: generamos los valores de entrada de la tabla 2-1 a partir de distri-
buciones de probabilidad en Arena. Los tiempos entre llegadas provienen de una distribución
exponencial con una media de 5 minutos y los tiempos de servicio 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 (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
Repetición Muestra 95%

Medidas de desempeño 1 2 3 4 5 Prom. D. est. Mitad de ancho
Producción total 5 3 6 2 3 3.80 1.64 2.04
Tiempo promedio de espera en la cola 2.53 1.19 1.03 1.62 0.00 1.27 0.92 1.14
Tiempo máximo de espera en la cola 8.16 3.56 2.97 3.24 0.00 3.59* 2.93* 3.63*
Promedio de tiempo total en el 6.44 5.10 4.16 6.71 4.26 5.33 1.19 1.48
sistema
Tiempo máximo total en el sistema 12.62 6.63 6.27 7.71 4.96 7.64* 2.95* 3.67*
Tiempo promedio del número de 0.79 0.18 0.36 0.16 0.05 0.31 0.29 0.36
partes en la cola
Número máximo de partes en la cola 3 1 2 1 1 1.60* 0.89* 1.11*
Uso de la perforadora 0.92 0.59 0.90 0.51 0.70 0.72 0.18 0.23
*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
funciona para un intervalo 1.64 de confianza de 95% (α = 0.05) para

3.80 ï2 .776
.64 5Si à E Si
2
1Var
3E.80
WQï2 .776 âħ
ƈ
52 1 Ź ħ ES
i 2
o 3.80 ± 2.04; la mitad Vardel à E S
Si ancho los intervalos de confianza de 95% en las expectativas de
para
i

E WQƈ âħ
todas las medidas Varde S desempeño
2i 1àŹħEESSestán en la última columna de la tabla 2-4. La interpretación
2
i i
E WQ
correcta aquí
ƈ
â ħ
es que al hacer cinco repeticiones de la simulación como lo hicimos, en cerca
de 95% de los casos ħ ESi formado como éste contendrá o “cubrirá” el verdadero (pero
2 1elŹintervalo
desconocido) valor esperado de la producción total. Dicho intervalo de confianza supone que
los resultados de producción totales de las repeticiones son de distribución normal, lo cual no
se justifica realmente aquí, pero se usa esta forma de cualquier modo (véase la sección 6.3 para
más información sobre robustez estadística). Usted debería observar que la mitad del ancho de
este intervalo (2.04) es bastante grande comparado con el valor en su centro (3.80); así que la
precisión no es tan buena. Esto se remedia al hacer más de las cinco repeticiones que hicimos,
que al parecer no fueron suficientes para aprender algo preciso acerca del valor esperado de esta
medida de desempeño de salida. Lo bueno de recopilar datos mediante la simulación es que
siempre2 se puede obtener más con sólo hacer más repeticiones.
2.6.3 Comparación de alternativas

La mayoría de los estudios de simulación incluyen más que una simple construcción o confi-
guración del sistema. Las personas quieren ver con frecuencia cómo los cambios en el diseño,
los parámetros (controlables en la realidad o no) o la operación pueden afectar el desempeño.
Para ver cómo la aleatoriedad en la simulación desempeña un papel en estas comparaciones, le
hicimos un cambio simple al modelo del ejemplo y lo volvimos a simular (cinco repeticiones).
El cambio consistió en duplicar el índice de llegada —en otras palabras, el tiempo medio en-
tre llegadas es ahora de 2.5 minutos en lugar de 5 minutos—. La distribución exponencial aún
se usa para generar tiempos entre llegadas y todo lo demás en la simulación se mantiene igual.
Por ejemplo, esto podría implicar la adquisición de otro cliente para la instalación, cuyas de-
mandas de procesamiento de partes podrían entremezclarse con la base de clientes existente.
2
Bueno, casi siempre.
1SPEVDDJÓOUPUBM
0 5 10
1SPNFEJPEFUJFNQPEFFTQFSBFOMBDPMB
0 5 10
1SPNFEJPEFUJFNQPUPUBMFOFMTJTUFNB
0 5 10
5JFNQPQSPNFEJPEFOÙNFSPEFQBSUFTFOMBDPMB
0 5 10
6TPEFMBQFSGPSBEPSB
0.0 0.5 1.0
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.
2.7 Simulación con hojas de cálculo

Estará de acuerdo con que la simulación manual no tiene mucho futuro. Las personas usan
hojas de cálculo para muchas cosas, pero ¿qué hay de la simulación? Bueno, quizá dependa del
tipo y complejidad del modelo y del software que debería tener usted para ello. En esta sección
analizaremos dos ejemplos: primero un modelo estático y después uno dinámico (recuerde la
sección 1.2.3), aunque ambos son muy sencillos.
2.7.1 El problema del voceador

Rupert vende periódicos todos los días en una esquina. Cada mañana debe comprar el mismo
número fijo q de copias de la imprenta a c = 55¢ cada uno y venderlos a r = $1.00 durante el día.
Él ha notado que la demanda D durante un día está cercana a ser una variable aleatoria X que por
lo general se distribuye con la media μ= 135.7 y una desviación estándar σ = 27.1, salvo que D no
debe ser un número entero negativo para tener sentido; así, D = máx (⎣X⎤, 0) donde ⎣.⎤ redondea
al entero más próximo (Rupert no es el vendedor promedio). Además, las demandas diarias son
distintas. Si la demanda D en un día no es mayor que q, él puede abastecer a todos los clientes y ten-
drá q − D ≥ 0 periódicos sin vender, que él vende como desechos a quien recicla al final del día por
s = 3¢ cada uno (después de todo, son noticias viejas en ese momento). Pero si D > q, él vende
toda su mercancía de q y sólo pierde esas otras ventas D − q > 0. Cada día comienza de nuevo,
así que éste es un problema de todos los días sin excepción y un día dado tiene un modelo está-
tico, ya que no importa cuándo los clientes individuales aparecen durante el día.
¿Cuántos periódicos q debe comprar Rupert cada mañana para maximizar sus ganancias?
Si compra muy pocos, vendería todo y dejaría de ganar los 45¢ de cada venta que no se reali-
ce, pero si compra demasiados debería perder como desecho 52¢ por cada uno. Si tuviera una
bola de cristal y supiera cada mañana la demanda de ese día, por supuesto que compraría
sólo esa cantidad. Rupert es bueno, pero no tan bueno, así que necesita decidirse por un valor
fijo de q que se aplique para cada día.
Éste es un clásico genuino en investigación de operaciones, un problema de inventario pere-

cedero de un solo periodo, con aplicaciones más complejas, como reservas de comida y bancos
de sangre. Tiene muchas versiones, variantes y extensiones y se le ha puesto mucha atención
para obtener soluciones analíticas exactas. Pero es sencillo simularlo; tan simple que se puede
hacer con una hoja de cálculo.
Primero se debe imaginar una expresión de la ganancia de Rupert en un día típico. Es obvio
que su costo diario es cq (no se impone ningún costo enigmático de buen deseo negativo por
ventas perdidas si D > q y él se queda sin inventario). Si resulta que D ≤ q entonces él vende D
y cubre la demanda de todos los clientes, obtiene un ingreso rD de ellos y queda q − D de los
desechos, y obtiene s (q − D) más ingreso, por reciclar. Por otra parte, si D > q él vende q, ob-
tiene ingresos rq de los clientes, pero no obtiene ingresos por el desecho. Por lo tanto, el ingreso
diario total de Rupert es r mín (D, q) + s máx (q − D, 0); para observar esto, agotaremos los
dos casos: D ≤ q y D > q. Así que su ganancia diaria en dólares es
W(q) = r mín (D, q) + s máx (q −D, 0) − cq.
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
numérica, lo cual se desarrolla en programas de hoja de cálculo y seguramente en programas

de simulación.
Para crear el archivo Newsvendor.xls se usa la hoja de cálculo de Microsoft® Excel
(en la figura 2-5). Dicho archivo se puede encontrar en la carpeta de ejemplos del libro, que
a su vez viene en la carpeta Arena 10.0 si se siguen las instrucciones del apéndice E para la
instalación de Arena del CD que se proporciona con este libro; un camino completo a esta
carpeta puede ser C:\ProgramFiles\RockwellSoftware\Arena10.0\BookExam-
ples. En las celdas B4 a B8 (sombreadas con azul en el archivo) están los parámetros de
entrada y en la fila 2 (marcada con rosa) están algunos valores de prueba para la variable de
decisión q (celdas H2, K2, N2, Q2 y T2). La columna D sólo proporciona el número de día
para referencia. Se simulan 30 días aunque, como se mencionó, cada día es independiente, así
que se trata realmente de una simulación independiente estática.
La columna E tiene la demanda de cada día; en la forma de fórmula de Excel
MÁX(REDONDEAR(DISTR.NORM.INV(ALEATORIO(), $B$7, $B$8), 0), 0)
es lo mismo en toda la columna. Diseccionemos esta fórmula desde adentro:

< RAND()[ALEATORIO()] es el generador de número aleatorio insertado en Excel,
que devuelve un número entre 0 y 1 que se supone que es independiente y distribuido
de forma uniforme entre los sorteos. Es necesario ver la sección 12.1 para un análisis
de generadores de números aleatorios, que son más sutiles de lo que uno piensa, pero
claramente esenciales para la simulación estocástica. Por desgracia, no todos los ge-
neradores de números aleatorios proporcionados con algunos programas de software
son de gran calidad (sin embargo, el desarrollado en Arena es excelente). La función
RAND()[ALEATORIO()] de Excel es “volátil” por defecto, esto es, que en cada ejem-
plo él vuelve a sortear un número aleatorio “nuevo” sobre cada nuevo cálculo de la
hoja de cálculo, lo cual se puede forzar al oprimir la tecla F9, al salvar el archivo o al
editar cualquier cosa en cualquier lugar de la hoja.
< NORMINV [DISTR.NORM.INV](u,
−1
μ, σ) es la aproximación numérica insertada en
Excel para Φμ,σ ; así, cuando se usa con u = RAND()[ALEATORIO()] devuelve una
variación aleatoria distribuida de forma normal con la media μ y la desviación estándar
σ. Se tiene a μ en la celda B7 y σ en la celda B8; el $ en las referencias de las celdas de
fórmulas de Excel obliga a lo que le sigue de manera inmediata (letra de columna o nu-
mero de fila) a no cambiar cuando se copia la fórmula en otras celdas y en este ejemplo se
desea que se mantengan igual tanto la columna como la fila cuando la fórmula se copie
en otra celda dado que μ y σ están en estas celdas fijas.
< ROUND [REDONDEAR](x, 0) en Excel devuelve x redondeada al entero más próximo. El
segundo argumento es 0 y asegura que el redondeo sea al entero más próximo en contra-
posición a otras formas de redondeo (véase ayuda de Excel).
< MÁX(a, b, ...), como se puede adivinar, devuelve el máximo de sus argumentos.
Figura 2-5. Simulación en hoja de cálculo del problema del voceador
Esta fórmula se introdujo originalmente en la celda E4 y después se copió en las 29 co-

lumnas siguientes para obtener demandas independientes en 30 días, como RAND() arroja un
número aleatorio nuevo cada vez que aparece. Si se oprime la tecla F9 o cualquier otra la hoja
recalcula, se obtiene una nueva columna de números de demanda y la mayoría de las otras cosas
en la hoja también cambian en concordancia.
Para el caso donde q = 100, las columnas F, G y H en las filas 4 a 33 contienen el número de
periódicos vendidos, desechados y la ganancia diaria para cada día del 1 al 30:
< La celda F4 es el número de ventas en el día 1 si q = 100. La fórmula de Excel es
= MÍN($E4, H$2). $E4 es la demanda del día 1. Se coloca $ en la columna E debido
a que se desea copiar posteriormente esta fórmula para otros valores de q en las colum-
nas I, L, O y R, pero mantener como referencia la columna E; no se pone $ en la fila 4
debido a que se desea cambiar de la fila 5 a la 33 para recoger las demandas de los días
siguientes. H$2 es q = 100. No se coloca $ en la columna H debido a que posteriormente
se desea cambiar por otros valores de q en las columnas I, L, O y R, pero se aplica un $
42 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,
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).
2.7.2 Una cola de servicio sencilla

Las hojas de cálculo también pueden usarse para simular algunos modelos dinámicos, pero sólo
los muy sencillos. Considere la cola de un único servidor que es lógicamente la misma que con
la que se trabajó con dificultad a mano en la sección 2.4, pero con algunas especificaciones di-
ferentes. Como antes, los clientes llegan uno a la vez (el primer cliente llega en el tiempo 0 para
encontrar el sistema vacío y desocupado), esperan en una cola FIFO si hace falta, son atendi-
dos uno a la vez por un servidor sencillo y después salen. Pero se harán los siguientes cambios
a partir del modelo de simulación manual:
44 Capítulo 2
< 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
WQ1 = máx (WQi − 1 + Si − 1 − Ai, 0) para i = 2, 3, ...
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.
Figura 2-6. Simulación en hoja de cálculo de la cola M/U/1
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.
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.
2.7.3 Extensiones y limitaciones

La simulación con hojas de cálculo es popular para los modelos estadísticos, muchos de los cuales
involucran análisis financiero o de riesgo. Los paquetes comerciales insertados en Excel, como
@RISK (Palisade Corporation, 2006) y Crystal Ball® (Decisioneering Inc., 2006), facilitan las
operaciones comunes, proporcionan mejores generadores de números aleatorios, hacen fácil la
generación de variaciones desde muchas distribuciones e incluyen herramientas para el análisis
de resultados.
Sin embargo, las hojas de cálculo no son muy apropiadas para la simulación de modelos di-
námicos. Sin contar con algo como la recursión de Lindley para casos muy especiales y sencillos
como la cola FIFO de servidor único de la sección 2.7.2, las hojas de cálculo no son herramien-
tas muy buenas para los modelos dinámicos. Nuestro enfoque en el resto del libro está en los
modelos dinámicos, para los cuales se diseñó específicamente Arena.
2.8 Visión general de un estudio de simulación

Al decidir cómo modelar un sistema, se encontrará que los temas relacionados con el diseño,
el análisis y la representación de modelos en el software son esenciales para un estudio de si-
mulación exitoso, pero no son los únicos ingredientes. Todo esto se abordará con detalle en el
capítulo 13, aunque queremos mencionar brevemente los temas involucrados.
Ningún estudio de simulación seguirá una “fórmula” preestablecida, pero hay varios aspec-
tos que tienden a aparecer con frecuencia:
< Entender el sistema: Si el sistema existe o no, usted debe tener un sentimiento intuitivo y
realista de lo que sucede. Esto conllevará visitas al lugar donde lo hacen y la participa-
ción de personas que trabajen en el sistema día a día.
< Ser claro en los objetivos: La realidad aquí es el santo y la seña; no hay que prometer
el Sol, la Luna y las estrellas. Hay que entender lo que se puede aprender del estudio y
no esperar más. Es esencial especificar acerca de lo que se observa, manipula, cambia y
entrega. Es necesario regresar a estos objetivos a través del estudio de simulación para
mantener la atención enfocada en lo que es importante, a saber: al tomar decisiones
acerca de la mejor manera de (o por lo menos mejorar) operar el sistema.
< Formular la representación del modelo: ¿Cuántos detalles son adecuados? ¿Qué necesita
modelarse con cuidado y qué puede hacerse de una forma primitiva? Convencer a la
administración y a los encargados de tomar decisiones para las suposiciones del mode-
lado.
< Traducir a un software de modelación: Una vez que las suposiciones del modelo se
acepten, hay que representarlas fielmente en el software de simulación. Si hay dificul-
tades, hay que asegurarse de plasmarlas de una forma abierta y honesta en lugar de
esconderlas. Involucre a los que en verdad saben qué está pasando (la animación puede
ser de gran ayuda).
< Verificar que la representación en la computadora caracterice fielmente el modelo con-
ceptual: Investigue las regiones extremas de los parámetros de entrada, verifique que
sucedan las cosas correctas con entradas “obvias” y siga la lógica con las personas fami-
liarizadas con el sistema.
48 Capítulo 2
< 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?
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.
b) Se llevó a cabo la simulación durante un millón de minutos (preferible a 20 minutos),

usando las mismas fuentes de tiempos entre llegadas y de servicio que en la tabla 2-1 y
se obtuvo un valor de 3.60 para el tiempo de espera promedio en la cola (como puede
imaginar, nos tomó un buen tiempo hacerlo a mano, pero lo disfrutamos). ¿Por qué
esto es diferente de los valores 19.31 y 2.53 comparados en la parte a)?
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:
1. ocupada trabajando en una parte y sin desmontar,

2. detenida y sin desmontar, y
3. desmontada, con o sin una parte atascada en la máquina en el tiempo de desinstala-
ción.
Dé las medidas de desempeño de salida de esta simulación bajo la definición depurada del es-
tado de la perforadora.
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
Un recorrido guiado a través de Arena

Así como fuimos lo bastante honestos como para admitir en el capítulo 2 que en realidad usa-
mos Arena para llevar a cabo la simulación “a mano” de la sección 2.4, además de las múltiples
réplicas y el modelo modificado con las llegadas de doble tiempo de la sección 2.6, en este
capítulo lo llevaremos por un recorrido a través de Arena, al hacer que usted lo arranque, eche
un vistazo al modelo existente que construimos para la simulación a mano, lo ejecute y, luego,
lo desarrolle a partir de cero. Después usaremos sólo estos paquetes básicos de desarrollo en
un estudio de caso al explorar una pregunta de interés real: si es mejor tener un procesamiento
serial especializado o uno paralelo generalizado, y el efecto de la variabilidad en tal decisión.
También exploraremos la interfaz del usuario de Arena, lo adentraremos en los sistemas de
ayuda y documentación, analizaremos diferentes formas de ejecutar su simulación e ilustrare-
mos algunas de las herramientas de dibujo y graficado.
La sección 3.1 le muestra cómo instalar Arena en su computadora y en la sección 3.2 podrá
abrir un modelo existente y darse una idea al respecto. En la sección 3.3 conocerá el modelo en
cierto detalle, al echarle un vistazo a los cuadros de diálogo y animación, ejecutar el modelo
y observar los resultados; en la sección 3.4 construirá este modelo desde el principio. La sec-
ción 3.5 contiene el estudio de caso mencionado anteriormente. En la sección 3.6 pasaremos
brevemente a través de muchas de las partes y capacidades de Arena, incluyendo las que están
disponibles en los menús y las barras de herramientas así como las posibilidades de dibujo e
impresión. Existe un sistema de ayuda amplio y profundo en Arena, con toda la documenta-
ción técnica detallada, que es el asunto de la sección 3.7. También hay muchas opciones para
ejecutar y controlar simulaciones, las cuales se analizan en la sección 3.8.
Al final de este capítulo logrará una buena percepción de cómo funciona Arena y una idea
de las cosas que puede hacer con él. Podrá trabajar de forma eficaz con Arena en el desarrollo
de modelos sencillos y quizá intentar hacer algunas cosas no tan simples, además de navegar
por los menús y diálogos por su cuenta, con el apoyo de los sistemas de ayuda y de documen-
tación. Aunque probablemente usted pueda entender algunas cosas con sólo leer este capítulo,
será mejor si da seguimiento a Arena en su computadora. En el capítulo 4 y posteriores se ana-
lizará más información sobre el desarrollo de sus propios modelos con Arena.
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
< Discos, archivos, carpetas y trayectorias.

< Uso del ratón y el teclado, incluso dar un clic, un doble clic y un clic con el botón derecho.
< Operaciones en Windows, como moverse, reajustar, maximizar, minimizar y cerrar.
< Acceder a elementos a través de los menús. Usaremos la notación como “M > C > S >
T ” para decir: abrir menú M, elegir C, después escoger S del submenú (si es que hay), a
continuación elegir la página tabulada etiquetada con una T (si es que la hay), etcétera.
< Usar las teclas Control, Alt y Shift (mayúsculas). Al señalar “Ctrl + cualquiera”, quere-
mos decir que mantenga presionada la tecla Ctrl y que presione “cualquiera” (ello tam-
bién aplicará para Alt + cualquiera y Shift + cualquiera). Si “cualquiera” es una tecla del
teclado, no es sensible a mayúsculas/minúsculas. “Cualquiera” también podría ser un clic
del ratón, como Ctrl + Clic para ampliar una selección e incluir artículos adicionales.
< Cortar (o el comando del menú Edit > Cut (Editar > Cortar) o la combinación de las
teclas activas Ctrl + X, Copy (Copiar) (o Edit > Copy [Editar + Copiar] o Ctrl + C) y
Paste (Pegar) (o Edit > Paste o Ctrl + V ) (Editar > Pegar) del texto y otros artículos.
< Completar los cuadros de diálogo introduciendo y editando entradas de texto, presionar
botones, seleccionar y desocupar (es decir, no marcar) cuadros de verificación al hacer
clic exactamente sobre un botón de una lista de botones de opción (también llamados
botones de radio) y al seleccionar artículos de los cuadros de listas de sugerencias.
Si alguna de estas cosas no le es familiar, probablemente sería una buena idea que consiguie-
ra un tutorial de Windows antes de seguir adelante.
Vaya a su computadora, en la que ya se ha instalado Arena siguiendo las instrucciones que
vienen con él (véase el apéndice E para las instrucciones relativas a la instalación de la versión
académica de Arena, que es la que se halla en el CD que se incluye con este libro). Acérquese a
la computadora con cuidado pero también con confianza (si ella siente que usted tiene miedo,
podría atacarlo). Localice el ícono de Arena o un atajo hacia él y haga doble clic (o despliegue
Arena al iniciar Windows y hacer clic en el botón Start (Inicio), después Programs > Rockwell
Software + Arena 10.0 y finalmente en el ícono de Arena 10.0 (Programas + software Rockwell
+ Arena 10.0). En un momento, la ventana de derechos de autor de Arena aparecerá; si usted
está ejecutando una versión académica (que es lo que se encuentra en el CD de este libro), o
una versión de evaluación, tendrá un cuadro de mensaje especial relativo a ello que debería leer,
para después hacer clic en OK (o sólo pulsar la tecla Enter en su teclado, ya que el botón OK ya
está seleccionado de forma predeterminada).
En el extremo superior izquierdo de la ventana de Arena se encuentran los menús File, View,
Tools y Help (Archivo, Ver, Herramientas y Ayuda) (además de otros menús, si se abrió de forma
automática el archivo de un modelo en blanco cuando inició Arena). También verá barras de
herramientas con varios botones, de los cuales sólo unos pocos están disponibles a menos que
tenga abierto un archivo modelo:
Crea un archivo de modelo en blanco Nuevo. Esto es equivalente al comando del menú
File + New (Archivo > Nuevo) y a la operación del teclado Ctrl + N.
Despliega un cuadro de diálogo para abrir un modelo guardado con anterioridad; de
manera equivalente a File + Open (Archivo > Abrir) o Ctrl + O. Puede ser que tenga
que navegar a otras carpetas o discos para encontrar lo que desea.
Template attach (Adjuntar plantilla) (las plantillas, de las que hay varias, contienen los
elementos de modelado); de forma equivalente File > Template Panel > Attach (Ar-
Un recorrido guiado a través de Arena 55
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.
3.2 Exploración de la ventana de Arena

En esta sección abriremos un modelo existente, lo usaremos para echarle un vistazo a la venta-
na de Arena, con el fin de que se familiarice con la posición de los elementos, y le presentaremos
la terminología básica de Arena.
3.2.1 Abrir un modelo

El modelo ya instalado para la simulación que se hizo a mano se puede encontrar mediante File >
Open (o sólo con un clic en para abrir el cuadro de diálogo Open). Los nombres de los archivos
aparecen en un cuadro de desplazamiento y usted también puede navegar hacia otras carpetas
o unidades. Busque el archivo con el nombre Model 0301.doe; la extensión de nombre del
archivo .doe1 ya aparece de forma predeterminada en los archivos de Arena. En una instalación
habitual que usa el CD que viene en este libro, estará en la carpeta de Book Examples (Ejemplos
del libro), que a su vez se encuentra en la carpeta Arena 10.0. Haga clic en el nombre del archivo
(destacándolo) y después en el botón Open (o sólo haga doble clic en el nombre del archivo).
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)
Model Window Spread-

sheet View
Status Bar (Vista de la hoja de
(Barra de estado) cálculo 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.
3.2.2 Interacción básica y partes de la ventana de Arena

Como se muestra en la figura 3-1, la ventana de Arena con este modelo abierto se encuentra
dividida en varias partes.
A la derecha, ocupando la mayor parte de la pantalla, se halla la ventana del modelo, que de
hecho está dentro de la ventana de Arena. Si usted tuviera varios modelos en Arena abiertos al
mismo tiempo tendría una ventana del modelo separada para cada uno de ellos, todos conteni-
dos en la ventana de Arena, así como sucede en un software de procesador de textos o de hoja de
cálculo. Pase de una ventana a otra de los modelos con sólo hacer clic en ellos (si el que desea está
visible) o use el menú de la ventana de Arena para seleccionar de entre toda la lista. Si usted tiene
muchos modelos abiertos, puede circular entre ellos mediante Ctrl + Tab o puede ser que desee
minimizar algunos en íconos con el botón _ que aparece en cada uno de ellos. El menú de la ven-
tana también tiene comandos (Cascade, Tile, etc.) (cascada, mosaico, etc. ) para la forma en cómo
desea acomodar los modelos abiertos en sus íconos minimizados. Cree una ventana de modelo
nueva (en blanco) a través de (o File > New o Ctrl + N) (Archivo > Nuevo), guarde la ventana
del modelo activo mediante (o File > Save o Ctrl + S) (Archivo > Guardar) o File > Save As
(Archivo > Guardar como) y abra una ventana del modelo guardado con anterioridad mediante
(o File > Open o Ctrl + O). Restaurar o reposicionar la ventana de un modelo se hace igual
que en cualquier aplicación del sistema operativo de Microsoft® Windows®.
Las operaciones familiares de cortar, copiar y pegar funcionan en Arena igual que entre Arena
y otras aplicaciones. Por ejemplo, usted puede tener varias ventanas de modelos abiertos en Arena
y puede copiar algunos de los objetos de uno a otro modelo. Sólo seleccione los objetos con el ratón
(Ctrl + Clic para ampliar la selección, o arrastrar un cuadro a través de ellos si es que están colo-
cados así), cópielos en el portapapeles (Ctrl + C o o Edit > Copy), cámbiese a la otra ventana y
péguelos (Ctrl + V o o Edit > Paste). Después de elegir la operación de pegado, el apuntador del
ratón cambia a una cruz de líneas delgadas en la que le dará un clic donde usted desee posicionar
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.
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
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).
3.2.5 Documentación interna del modelo

Si usted coloca el cursor de su ratón en un símbolo del módulo u otro objeto, verá un Data Tips
(Consejo de datos). Los Data Tips tienen dos partes, una descripción por defecto y una descrip-
ción definida por el usuario. El consejo por defecto le describirá alguna información genérica
acerca del objeto, así como su nombre y tipo. La parte definida por el usuario desplegará exac-
tamente lo que esté metido en el campo de Object Properties Description (Descripción de pro-
piedades del objeto). Usted puede meter texto en este campo al hacer clic con el botón derecho
en un objeto y seleccionar Properties (Propiedades). Un desplegado de estos Data Tips se puede
activar a través de View > Data Tips (Ver > Consejo de datos). Ambos se pueden habilitar de
forma predeterminada, pero es posible que uno de ellos tenga que deshabilitarse.
62 Capítulo 3
Figura 3-2. La propiedad de crear un cuadro de diálogo para el modelo 3-1
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.
3.3 Navegar por un modelo existente: modelo 3-1

Para ver cómo se configura el modelo 3-1, ahora lo llevaremos por los módulos de diagrama de
flujo y de datos en la ventana del modelo y le indicaremos cómo se relacionan entre sí. Después
ejecutaremos este modelo y veremos sus resultados. Luego, en la sección 3.4, le mostraremos
cómo desarrollar este modelo desde el principio.
3.3.1 El módulo Create en diagrama de flujo

Comenzaremos con el módulo Create (Crear) al que llamamos Part Arrives to System
(La parte llega al sistema), a la izquierda de la vista del diagrama de flujo de la ventana
del modelo. Note que este módulo es un ejemplo general del módulo Create que hemos especia-
lizado para nuestras necesidades en este modelo en particular.
El módulo Create es el nudo “de nacimiento” para la llegada de las entidades a la frontera
de nuestro modelo que en este caso representan partes, de afuera y hacia el modelo. Haga doble
clic para abrir el cuadro de diálogo como el de la figura 3-2.
En el cuadro de Name, escribimos Part Arrives to System como el nombre de este
módulo Create en particular (más que aceptar el nombre predeterminado), que es el que aparece
dentro de su forma en la vista del diagrama de flujo y en sus Data Tips. Introducimos Part (Par-
te) como el nombre del Entity Type; sólo hay un tipo de entidad en este modelo pero en general
podría haber muchos y el nombrarlos de forma separada los mantiene correctos y le permite per-
sonalizarlos de formas útiles (como separar tiempos o números en sistemas por tipo de entidad).
En el centro del cuadro de diálogo hay un área limitada llamada Time Between Arrivals
(Tiempo entre llegadas), en donde especificamos la naturaleza del tiempo que separa las llega-
das consecutivas de las entidades Part que se originan en este módulo. En el cuadro de Type,
Figura 3-3. La hoja de cálculo Create para el modelo 3-1
seleccionamos Random (Expo) (Aleatorio) (al usar la flecha en el cuadro de lista ) de

tal forma que los tiempos entre llegadas se generarán como trazos en una variable aleatoria; en
particular, de la distribución exponencial (véase apéndice C si necesita recordar probabilidad y
el apéndice D para la definición de exponencial y otras distribuciones de probabilidad). En el
cuadro Value (Valor), escribimos 5 y en el cuadro Units (Unidades) seleccionamos Minutes
(Minutos) para decirle a Arena que quisimos decir 5 minutos y no 5 segundos, 5 horas o 5 días.
Mientras que el número que escribimos fue “5”, pudimos haber escrito “5.” O “5.0” puesto que
Arena es por lo general bastante fuerte y perdona que se mezclen enteros con número reales.
En la fila inferior de los cuadros, dijimos que el número de entidades por llegada es 1 (pre-
determinado, de tal forma que las partes llegan una cada vez en lugar de hacerlo en un grupo
de varias), que no queremos poner un límite en el número máximo de llegadas (si lo hiciéramos,
este módulo Create se “apagaría” después de ello) y que la primera parte debería llegar en se-
guida, en el tiempo 0 (en lugar de hacerlo después de un periodo de tiempo inicial que pudiera
o no tener la misma definición y tiempos entre las llegadas sucesivas).
Para cerrar este cuadro de diálogo de Create, haga clic en Cancel o en ∙ en el extremo supe-
rior derecho; en cambio, si hizo algún cambio que quiera guardar, haga clic en OK.
Una manera alternativa de editar el módulo Create del diagrama de flujo es a través de la
vista de la hoja de cálculo en la ventana del modelo. Si hace clic en el módulo Create en la vista
del diagrama de flujo de la ventana del modelo (o en cualquier ejemplo del módulo Create, si es
que hubiera varios de ellos en su modelo) o en la forma del módulo general Create en la barra de
proyectos, se muestra una hoja de cálculo para el (los) módulo(s) Create en la vista de la hoja de
cálculo de la ventana del modelo, como en la figura 3-3. Al hacer clic o doble clic en cada uno de
los campos de esta hoja de datos puede editar la entrada o seleccionarla de las opciones; la figura
3-3 muestra la lista de las opciones para el Type (Tipo) a las que tiene acceso a través de la lista
de sugerencias (las listas de sugerencias se ofrecen en donde quiera que tengan sentido). Si usted
tiene múltiples módulos Create en su modelo, cada uno representando una fuente por separado
de las entidades entrantes, habrá una fila separada en la hoja de cálculo Create para cada uno.
Esto es muy conveniente en modelos grandes para editar muchas cosas de forma rápida o sólo
para tener una idea general de todos los módulos Create de una vez. Escoger un módulo Create en
particular en cualquiera de las vistas, ya sea del diagrama de flujo o de hoja de cálculo, selecciona
ese módulo en la otra vista. Cuando se hace clic con el botón derecho del ratón en una fila de la
hoja de cálculo, aparece la opción de editar ese módulo mediante el cuadro de diálogo de la figura
3-2. Si hace clic con el botón derecho del ratón en un campo numérico (aquí o prácticamente en
todo Arena), también puede elegir Expression Builder (Constructor de expresiones) para obtener
una asistencia bastante útil al poner juntas expresiones algebraicas, quizá complicadas, que pudie-
ran usar muchas variables, distribuciones de probabilidad, funciones matemáticas y operaciones
aritméticas de Arena diferentes (se analizará el Constructor de expresiones en las secciones 3.4.10
y 4.2.4). Se pueden cambiar las dimensiones del campo en una hoja de cálculo al arrastrar hacia
derecha e izquierda las barras sólidas verticales que los separan.
64 Capítulo 3
Figura 3-4. La hoja de cálculo de la entidad para el modelo 3-1
3.3.2 El módulo de Entity Data (Datos de la Entidad)

Una de las cosas que hicimos en nuestro módulo Create fue definir un Entity Type que llamamos
Part. Al seleccionar el módulo Entity Data (Datos de la entidad) en la barra de proyecto, se mues-
tra la hoja de cálculo de la entidad para su modelo en la vista de la hoja de cálculo de la ventana del
modelo, así como en la figura 3-4. Aquí se pueden ver y editar aspectos de los tipos de entidades de
su modelo. En la figura 3-4, se muestra la lista de sugerencias para el campo Inicial Picture (Imagen
inicial), indicando que decidimos que nuestras entidades de Part serán animadas como pelotas
azules cuando se corra la simulación. Existen varios campos para definir los datos de costo para
los tipos de entidad. Un cuadro de verificación al final le permite pedir Report Statistics (Reportar
estadísticas) en este tipo de entidad, incluso el tiempo promedio y máximo en el sistema que se ob-
servó para estos tipos de entidades durante la ejecución. Sólo tenemos un tipo de entidad en nuestro
modelo, pero si hubiera varios, cada uno tendría su propia fila en la hoja de cálculo de la entidad.
3.3.3 El módulo diagrama de flujo de proceso
Nuestro módulo de Process (Proceso), al que llamamos Drilling Center (Centro de
perforación) representa a la máquina, incluyendo el recurso, su cola y el tiempo de demora
de la entidad ahí (procesamiento de las partes, en nuestro caso). Puede abrirlo con un doble clic
en su nombre y verá el cuadro de diálogo en la figura 3-5.
Después de meter el nombre Drilling Center, seleccionamos Standard (Normal)
como el tipo, es decir, que la lógica para esta operación se definirá aquí en este módulo de Pro-
cess más que en un submodelo jerárquico. Pasando directamente al final del cuadro de diálogo,
el cuadro de verificación Report Statistics le permite elegir si quiere estadísticas de resultados
tales como usos, longitudes de la cola y tiempos de espera en ella.
Los cuadros de área de Logic (Lógica) ocupan la mayor parte del diálogo y determinan lo
que sucede con las entidades en este módulo.
La Action (Acción) que elegimos, Seize Delay Release (Tomar Demorar Li-
berar), indica que deseamos que este módulo se encargue de la posesión de la entidad de
algunos números de unidades de un Resource (Recurso) (después de una posible espera en la
cola), después Delay (Demora) para un tiempo que representa el tiempo de servicio y luego Re-
lease (Liberar) unidad(es) del recurso de tal forma que otras entidades puedan poseerlo. Otras
acciones posibles son simplemente demorar la entidad aquí durante algún tiempo (piense en
ello como en un semáforo con la luz roja, después de la cual la entidad procede), tomar el recur-
so y después demorar (pero no liberar el recurso) o retrasar el recurso que previamente había
sido tomado; algunos módulos de Procesos se podrían unir para representar un amplio rango
de actividades de procesamiento.
Se pueden especificar diferentes Priorities (Prioridades) en entidades para Seize the Resour-
ce (Tomar el recurso). Aquí y en cualquier parte de Arena, los números más bajos significan
una prioridad más alta.
Defina el(los) Recurso(s) que se van a Tomar o Soltar en el cuadro Recursos; haga clic en Add
(Añadir) para añadir un recurso a esta lista. Usted puede definir o editar una línea particular de
Figura 3-5. El cuadro de diálogo de propiedades del proceso para el modelo 3 1
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
Figura 3-6. El cuadro de Diálogo de Recursos para el modelo 3-1

66 Capítulo 3
Figura 3-7. La hoja de cálculo del Proceso para el modelo 3-1
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).
3.3.4 El módulo Data del recurso

Una vez que haya definido un Resource así como lo hicimos nosotros en el módulo Process (en
nuestro caso, llamamos al recurso Drill Press [Prensa de perforación], se hace
una entrada para él de forma automática en el módulo de datos del Recurso; haga clic en él en la
Figura 3-8. La segunda hoja de cálculo de Resources en la hoja

de cálculo del Process para el modelo 3-1
Figura 3-9. La hoja de cálculo del módulo Data del recurso para el modelo 3-1
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.
3.3.5 El módulo Queue Data

Si el recurso Drill Press está ocupado cuando una entidad entra al módulo Process, la enti-
dad deberá hacer cola. La hoja de cálculo Queue, vista en la figura 3-10, aparece en la vista de la
hoja de cálculo si usted selecciona el módulo de datos Queue en la barra de proyectos. Aquí usted
puede controlar aspectos de las colas de su modelo (nosotros sólo tenemos una, llamada Dri-
lling Center.Queue [Centro de perforación.Cola]), así como la disciplina que se
usó para operarla, como se muestra en la lista Type (Tipo) de la figura 3-10 (First In First
Out [Primeras entradas primeras salidas]) está predeterminada y seleccionada).
Usted podría, por ejemplo, ordenar la cola de acuerdo con algún atributo de las entidades que
residen en ella; si usted elige Lowest Attribute Value (Valor mínimo de atributo), la cola estaría
ordenada de forma ascendente de algún atributo y se mostraría un campo adicional en la línea
para esta Queue en la que usted debería especificar el Atributo que se usaría para clasificarlo.
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
3.3.6 Animar recursos y colas

Hablando de colas, usted debe haber notado el justo encima del módulo Process en
la vista del diagrama de flujo. Aquí es donde se animará la cola y el módulo Process adquirió
esta gráfica cuando especificamos que queríamos que las entidades tomaran un recurso ahí.
Y mientras estamos con la materia de animación, sin duda usted ya notó el en la parte
superior derecha del módulo Process, posicionado en lo que será la cabeza de la animación de
la cola. Ésta es una animación del Recurso y cambiará la apariencia durante la simulación de-
pendiendo de si el Recurso Drill Press está desocupado o no. Esto no vino “gratis” con la
especificación del Recurso en el módulo Process; en lugar de eso, nosotros lo añadimos a nues-
tro modelo a través del botón Resource ( ) en la barra de herramientas Animate (Animar).
Haga doble clic en el ícono para tener el diálogo Resource Picture Placement (Localización
de imagen del recurso), así como en la figura 3-11. Esto nos permite elegir imágenes de las
bibliotecas (los archivos con la extensión .plb a su nombre, por lo general se encuentran en la
carpeta Arena 10.0) para hacer que el Recurso esté animado de forma diferente dependiendo
de su estado. Mientras se da una idea de cómo funciona esto en tal punto, analizaremos la ani-
mación del recurso en las secciones 3.4.8 y 4.3.3.
3.3.7 El módulo Dispose de diagrama de flujo

El módulo Dispose (Disposición) representa a las entidades que dejan las fronteras del mode-
lo; haga doble clic en su nombre para atraer el cuadro de diálogo de la figura 3-12; la hoja de
cálculo Dispose aparece en la figura 3-13. No hay mucho qué hacer aquí: sólo dar al módulo
un nombre descriptivo y decidir si usted desea el resultado en Entity Statistics (Estadísticas de
la entidad), que incluye cosas como tiempos promedio y máximo en el sistema de las entidades
que salen a través de este módulo e información de costo de tales entidades.
3.3.8 Conexión de los módulos del diagrama de flujo

Los módulos Create, Process y Dispose están conectados (en ese orden, de derecha a izquierda)
por líneas llamadas Connections (Conectoras). Éstas establecen la secuencia que todas las partes
seguirán conforme progresan de un módulo del diagrama de flujo a otro. Para hacer las Con-
nections, haga clic en Connect ( ) o de forma equivalente seleccione Object > Connect (Objeto
> Conectar), lo que cambia el cursor del ratón a una cruz de líneas delgadas. Haga clic en el
punto de salida ( ) del módulo fuente y finalmente en el punto de entrada ( ) en el módulo de
destino (puede hacer clics intermedios si usted desea que esta conexión sea una serie de seg-
Figura 3-12. El cuadro de diálogo de Dispose Property para el modelo 3-1
Figura 3-13. La hoja de cálculo de Dispose para el modelo 3-1

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.
3.3.9 Gráficos dinámicos

Los dos gráficos se crearon a través del botón Plot (Graficar) ( ) de la barra de herramientas
Animate. Ellos se trazan a sí mismos de forma dinámica conforme se ejecuta la simulación, pero
después desaparecen cuando ésta termina (le mostraremos, en la sección 7.2.1, cómo hacer grá-
ficos más detallados que también se quedan ahí después de que termina la ejecución).
Haga doble clic en la parte superior del gráfico (el de la longitud de la cola) para poner el
cuadro de diálogo Plot (Graficar) en el lado izquierdo de la figura 3-14. En la ventana Expre-
ssions únicamente tenemos una entrada, así que sólo obtendremos una curva en este gráfico.
Esta entrada llegó ahí al hacer clic en Add en el cuadro de diálogo Plot para traer el cuadro
de diálogo Plot Expression (Expresión del gráfico) (que se parece al lado derecho de la figura
4-14 después de que se llenó), en donde metimos en el cuadro Expression NQ (Drilling
Center.Queue), el número de entidades en esta cola, que Arena actualizará de forma auto-
70 Capítulo 3
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
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.
3.3.10 Arreglando las cosas

Las diferentes etiquetas en la ventana del modelo, como el título en la parte superior izquierda
y las etiquetas de los ejes para el gráfico, se hicieron a través del botón Text (Texto) ( ) en la ba-
rra de herramientas Draw (Dibujo). Desde ahí se pueden controlar los elementos usuales como
fuente, tamaño y estilo. Para ir a una nueva línea en el texto use Ctrl + Enter. Para cambiar el
color del texto, seleccione el texto (un solo clic en él) y use el botón Text Color (Color del texto)
( ) para seleccionar cualquier color en el subrayado (en este caso, haga clic en ) o para
elegir un color diferente (en este caso, haga clic en ) que será el nuevo color subrayado para un
texto posterior. Usted también puede darle un tamaño diferente o rotar el texto al seleccionarlo
y arrastrar la barra de subrayado.
La barra de herramientas Draw también tiene elementos como cuadros, elipses, polígonos y
líneas, así como los medios para controlar sus colores y estilos, que se pueden usar para decorar
72 Capítulo 3
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.
3.3.11 Preparando las condiciones para la ejecución

Cosas como la duración de la ejecución y el número de réplicas se configuran a través de Run
+ Setup (Ejecutar > Configurar), lo que trae un cuadro de diálogo con cinco páginas lengüe-
tadas. La Figura 3-15 muestra la lengüeta para Project Parameters, en donde especificamos un
Project Title, Analyst Name y Project Description (Título del proyecto, Nombre del analista y
Descripción del proyecto), así como seleccionamos qué tipo de medidas del desempeño de los
resultados queremos que se definan después. También elegimos documentar nuestro modelo de
forma interna a través de una breve Project Description (Descripción del proyecto).
La figura 3-16 muestra la lengüeta Replication Parameters (Parámetros de réplica) de la Run
Setup (Configuración de la ejecución), que controla varios aspectos acerca de la(s) ejecución(es).
Ya predeterminado, dejamos el campo de Number of Replications (Número de réplicas) con
1 (que aceptaremos por ahora pues sólo nos interesa el modelado en este momento, aunque
ya sabe más al respecto por la sección 2.6.2). Ya predeterminamos (esto es, no marcamos) el
campo Start Date and Time (Fecha de inicio y tiempo) para asociar una fecha y un tiempo
del calendario específicos con un tiempo de simulación de cero. También se puede especificar
un Warm-up Period (Periodo de calentamiento) al inicio de cada réplica, después del cual los
acumuladores estadísticos se limpian para permitir que desaparezca el efecto de posibles condi-
ciones iniciales atípicas. Especificamos la Length of Replication (Duración de la réplica) en 20
y seleccionamos que la unidad de tiempo para ese número sea de Minutes (Minutos). El cuadro
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
Figura 3-17. Estado de animación final en el modelo 3-1
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.
3.3.13 Ver los reportes

Si quisiera ver los resultados numéricos ahora, haga clic en Yes (Sí) en el cuadro de Arena que
aparece al final de su simulación, como se muestra cerca del extremo superior derecho de la
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).
< 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
Project: Simple Processing (Proyecto: Proceso sencillo)

Analyst: Delbert McClinton (Analista: Delberto McClinton)
Replication ended at time: 20 minutes (Réplica termina en el tiempo: 20 minutos)
Base Time Units: Minutes (Unidades base de tiempo: Minutos)
TALLY VARIABLES (VARIABLES DE CUENTA)
Identifier (Identificador) Average Half Width Minimum Maximum Observations
(Promedio) (Mitad del (Mínimo) (Máximo) (Observacio-
Intervalo) nes)
Drilling Center.WaitTi (Centro de perforación.Tiempo de es- 3.0340 (Insuf) .00000 8.1598 5
pera)
Drilling Center.TotalT (Centro de perforación.Tiempo 6.4396 (Insuf) 2.8955 12.618 5
total)
Drilling Center.VATime (Centro de perforación.Tiempo VA) 3.4056 (Insuf) 1.7641 4.5167 5
Part.VATime (Parte.Tiempo VA) 3.4056 (Insuf) 1.7641 4.5167 5
Part.NVATime (Parte.Tiempo NVA) .00000 (Insuf) .00000 .00000 5
Part.WaitTime (Parte.Tiempo de espera) 3.0340 (Insuf) .00000 8.1598 5
Part.TranTime (Parte.Tiempo entre llegadas) .00000 (Insuf) .00000 .00000 5
Part.OtherTime (Parte.Otros tiempos) .00000 (Insuf) .00000 .00000 5
Part.TotalTime (Parte.Tiempo total) 6.4396 (Insuf) 2.8955 12.618 5
Drilling Center.Queue.Wa (Centro de perforación.Cola. 2.5283 (Insuf) .00000 8.1598 6
Es)
DISCRETE-CHANGE VARIABLES (VARIABLES DE CAMBIO DISCRETAS)
Identifier (Identificador) Average Half Width Minimum Maximum Final Value
(Promedio) (Mitad del (Mínimo) (Máximo) (Valor
Intervalo) final)
Part.WIP (Parte.WIP) 1.7059 (Insuf) .00000 4.0000 2.0000
Drill Press.NumberBusy (Perforadora.Número ocupada) .91709 (Insuf) .00000 1.0000 1.0000
Drill Press.NumberSchedu (Perforadora.Número programada) 1.0000 (Insuf) 1.0000 1.0000 1.0000
Drill Press.Utilization (Perforadora.Uso) .91709 (Insuf) .00000 1.0000 1.0000
Drilling Center.Queue.Num (Centro de perforación.Cola. .78890 (Insuf) .000000 3.0000 1.0000
Número)
OUTPUTS (RESULTADOS)
Identifier (Identificador) Value
(Valor)
Drilling Center Number Out (Centro de perforación Número 5.0000
Fuera)
Drilling Center Accum VA Time (Centro de perforación Acum. VA 17.028
Tiempo)
Drilling Center Number In (Centro de perforación Número 7.0000
Adentro)
Drilling Center Accum Wait Time (Centro de perforación 15.170
Accum Tiempo de espera)
Part.NumberIn (Parte. Número Adentro) 7.0000
Part.NumberOut (Parte. Número Afuera) 5.0000
Drilling Press.NumberSeized (Centro de perforación 6.0000
Número de Recursos Tomados)
Drilling Press.ScheduledUtilization (Centro de per- .91709
foración Programa Uso)
System.NumberOut (Número saliendo del sistema) 5.0000
Simulation run time: 0.02 minutes. (Tiempo de ejecución de la simulación: 0.02 minutos.)
Simulation run complete. (Ejecución de la simulación completa.)
Figura 3-19. Archivo del reporte resumido de SIMAN (Modelo 03-01.out) para el modelo 3-1
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.
3.4 Construya el modelo 3-1 usted mismo

En esta sección lo llevaremos a través de la construcción del modelo 3-1 desde el principio. Lo
que consiga al final puede no verse exactamente igual por fuera que nuestro modelo 3-1, pero
puede ser funcionalmente equivalente y darle los mismos resultados.
80 Capítulo 3
Antes de embarcarse en esto, debemos mencionar un par de pequeñas funciones de interfaz

para el usuario que con frecuencia son convenientes:
< Al hacer clic con el botón derecho del ratón en un punto vacío de la vista del diagrama
de flujo en la ventana del modelo aparece un pequeño cuadro de opciones, una de las
cuales es repetir la última acción (como colocar un módulo en su modelo, del que puede
necesitar múltiples ejemplos). Obviamente esto le puede ahorrar tiempo cuando tenga
acciones repetitivas (aunque esto no las hará más interesantes). Otras opciones aquí
incluyen varias vistas, así como ejecutar o verificar el modelo.
< Ctrl + D o presionar la tecla Ins duplica lo que haya seleccionado en la vista del diagra-
ma de flujo de la ventana del modelo, comparando la copia un poco. Entonces probable-
mente usted quiera arrastrarla a algún otro sitio y hacer algo con ella.
3.4.1 Nueva ventana del modelo y panel básico del proceso

Abra una nueva ventana del modelo con (o File > New o Ctrl + N), que de manera automá-
tica dará el nombre Model1, con la extensión predeterminada .doe cuando lo guarde. Usted
puede cambiar este nombre cuando decida grabar los contenidos de la ventana del modelo. Las
ventanas subsecuentes del nuevo modelo durante esta sesión de Arena recibirán los nombres
predeterminados de Model2, Model3, sucesivamente. Puede que desee maximizar su nueva
ventana del modelo dentro de la ventana de Arena al hacer clic cerca de la esquina superior
derecha de la ventana del modelo (si es que aún no está maximizada).
A continuación, adjunte los paneles que necesitará si es que no están todavía en la barra de
proyectos. Para este modelo, sólo necesitamos el panel Process básico, que es un archivo llamado
BasicProcess.tpo, que por lo común se encuentra en la carpeta Template (Plantilla) debajo
de la carpeta Arena 10.0. Haga clic en (o File > Template Panel > Attach o con un clic en el
botón derecho del ratón en la barra de proyectos y seleccione Attach) para abrir el diálogo Attach
Template Panel que aparece en la figura 3-20, en donde abre el panel Proceso básico BasicPro-
cess.tpo (haga clic en él, luego otro clic en el botón Open [Abrir], o sólo dos clicks). Puede
pedirle a Arena que adjunte ciertos paneles de forma automática en la barra de proyectos de la
nueva ventana del modelo a través de Tools > Options > Settings al escribir los nombres de los
archivos de los paneles (incluyendo la extensión .tpo) en la caja Auto Attach Panels.
Figura 3-20. El diálogo Attach Template Panel

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.
3.4.2 Colocar y conectar los módulos del diagrama de flujo

Este modelo requiere un ejemplo de cada uno de los tres módulos del diagrama de flujo: Create,
Process y Dispose. Para añadir un ejemplo de un módulo del diagrama de flujo a su modelo,
arrastre su ícono de la barra de proyectos a la vista del diagrama de flujo de la ventana del
modelo y déjelo en donde desee (usted siempre puede arrastrar cosas después). Para ayudarlo a
alinear las cosas, recuerde Grid , Snap , Snap to Grid , Rulers , Guides , Glue ,
Arrange > Align y Arrange > Distribute de la sección 3.2.3.
Si usted ha marcado Object > Auto-Connect y arrastró los módulos a su modelo en el orden
mencionado anteriormente (sin dejar de seleccionar un módulo después de colocarlo) Arena
conectará sus módulos en el orden correcto; si usted ha marcado Object > Smart Connect, esas
conexiones se orientarán de forma horizontal y vertical.
La figura 3-21 muestra cómo se ven estos módulos en la vista del diagrama de flujo de la
ventana del modelo justo después de que los colocamos (se marcaron ambas herramientas Con-
nect), con el modelo Dispose seleccionado ya que éste fue el último que arrastramos dentro.
Si usted no marcó Object > Auto-Connect, necesitará conectar los módulos usted mismo; para
hacerlo, use Connect ( ) en los puntos de salida ( ) y entrada ( ) de los módulos, como se
describió en la sección 3.3.8. También recuerde de la sección 3.3.8 que, durante la animación,
verá a las entidades correr a lo largo de las conexiones si el botón Animate Connectors ( ) está
presionado (o, igualmente, si Object > Animate Connectors está marcado) sólo para hacerle
saber que se están moviendo de un módulo de diagrama de flujo al siguiente. Sin embargo, este
movimiento sucede en el tiempo de simulación cero; la sección 4.4 describe cómo representar
tiempos de viaje positivos en su modelo.
3.4.3 El módulo Create de diagrama de flujo

Abra el módulo Create haciendo doble clic en él para obtener el cuadro de diálogo de la figu-
ra 3-22, en donde hay que editar varias cosas. Primero cambiamos el nombre (Name) de este
ejemplo del módulo Create dado de forma predeterminada, Create 1, a Part Arrives to
System y cambiamos el Entity Type dado de forma predeterminada a Part. En el área Time
Between Arrivals del cuadro de diálogo, aceptamos Random (Expo) ya predeterminada para
Process I
Create I
Dispose I
Figura 3-21. Colocación inicial de los módulos del diagrama de flujo

82 Capítulo 3
Figura 3-22. El cuadro de diálogo Create
Type, cambiamos el valor predeterminado de 1 a 5 y seleccionamos Minutos como las unidades

de la lista de sugerencias (note que está en Horas de forma predeterminada). Aceptamos las
predeterminadas para los tres cuadros en la fila inferior del cuadro de diálogo e hicimos clic en
OK para guardar nuestros cambios; en este punto, el cuadro de diálogo Create debería verse
como el de la figura 3-2. Recuerde que también podemos ver y editar los módulos del diagrama
de flujo a través de la vista de su hoja de cálculo, como se detalló en la sección 3-3. La hoja de
cálculo completada para este módulo Create se mostró antes en la figura 3.3. Note que el nom-
bre nuevo de este módulo Create ahora aparece en su forma en la vista del diagrama de flujo de
la ventana del modelo.
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.
Part Arrives
to System
Name (Nombre) Part Arrives to System (Partes

que llegan al sistema)
Entity Type (Tipo de entidad) Part (Parte)
Time Between Arrivals area (Área de tiempos
entre llegadas)
Type (Tipo) Random (Expo) Aleatorio (Expo)
Value (Valor) 5
Units (Unidades) Minutes (Minutos)
Pantalla 3-1. El cuadro de diálogo Create completado
É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.
3.4.5 El módulo Entity Date

Ahora que ya definió la Parte de su Entity Date de la parte en su módulo Create, puede que
quiera decir algunas cosas al respecto. Lo único que hicimos fue cambiar su imagen de ani-
mación inicial predeterminada “Report” ( ) a “Blue Ball” ( ). Para hacer esto, haga clic en
el módulo de datos de Entity en la barra de proyectos para desplegarlo en la vista de la hoja
de cálculo de la ventana del modelo (véase la figura 3-4 en la sección 3.3.2). En la lista Initial
Picture (Imagen inicial), haga clic en Picture.Blue Ball (hacer clic en la flecha abre la lista
de sugerencias).
3.4.6 El módulo de diagrama de flujo Process

La pantalla 3-2 indica qué es lo que se necesita para editar el módulo de diagrama de flujo
Process. Puesto que la Action que especifica incluye Seize a Resource (Tomar un recurso), debe
presionar el botón Add para definir qué recurso se tomará; esto abrirá el cuadro de diálogo
secundario Resources, que también se muestra en la pantalla. Si desea hacer más grande el área
para la animación de la fila, haga clic en la animación de la fila ( ), después arrastre
su límite izquierdo hacia la izquierda (mantenga presionada la tecla Shift [mayúsculas] para
mantener su ángulo horizontal, vertical o diagonal a 45°).
84 Capítulo 3
Drilling
Center
Name (Nombre) Drilling center (Centro de perforación)

Action (Acción) Seize Delay Release (Tomar Demorar Liberar)
Resources (Recursos) (diálogo secundario
a través del botón Add [agregar])
Type (Tipo) Resource (Recurso)
Resource name (Nombre del recurso) Drill press (Perforadora)
Quantity (Cantidad) 1
Delay type (Tipo de retraso) Triangular
Minimum (Mínimo) 1
Value (Valor) 3
Maximum (Máximo) 6
Pantalla 3-2. El módulo Process completo
3.4.7 Los módulos Resource y Queue data

Una vez que se define este módulo Process (Proceso), su modelo tiene tanto un Resource (Re-
curso) como una Queue (Cola), con nombres que usted especificó (el nombre de una fila es
whatever.Queue [cualquiera.cola], donde cualquiera es el nombre que le dio al
módulo Process para esta Cola). Si necesita especificar artículos no predeterminados para un
Resource o una Cola (lo cual no hacemos en este modelo), debería usar los módulos Resource
y datos de Cola, como se describieron en las secciones 3.3.4 y 3.3.5.
3.4.8 Animation Resource (Animación)

Aunque no es necesario para que la simulación funcione, por lo general es agradable animar sus
recursos. Esto le permite mostrar su estado (sólo desocupado contra ocupado para este mode-
lo), así como mostrar las entidades “que radican” en ellas durante el proceso.
Oprima el botón Resource ( ) en la barra de herramientas Animate (Animación) para que
aparezca el cuadro de diálogo Resource Picture Placement (Localización de imagen del recur-
so). Para asociar esta imagen al recurso, haga clic en la flecha Identifier (identificadora) para
escoger el Resource Name (Nombre del recurso), que ahora será Drill Press (perfora-
dora). En la lista de imágenes del lado izquierdo del cuadro de diálogo, seleccione Inactive
(Inactivo) y después presione el botón Delete (borrar) a su izquierda; haga lo mismo para
Failed (Falla).
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.
3.4.9 El módulo Dispose del diagrama de flujo

El módulo final del diagrama de flujo es el Dispose (Despliegue); la pantalla 3-3 muestra cómo
editarlo para este modelo (la única cosa por hacer es mejorar el Name [Nombre] predetermi-
nado).
3.4.10 Gráficos dinámicos

Se describieron la mayoría de las entradas y propiedades de los dos gráficos animados ante-
riormente, en la sección 3.3.9. Para hacer tal gráfico partiendo desde cero, presione el botón
Plot (Graficar) ( ) en la barra de herramientas Animate para obtener un cuadro de diálogo
Plot en blanco, y después proceda como se indica en la pantalla 3-4. Recuerde que inicial-
mente usted debe suponer el valor máximo del eje y en el cuadro de diálogo Plot Expression
y quizá ajustarlo después de tener alguna idea de los resultados. También, cuando haya aca-
bado de completar el diálogo y haga clic en OK (Aceptar), el cursor de su ratón se vuelve de
líneas cruzadas; haga clic para determinar la ubicación de una esquina de la gráfica, después
Part Leaves
System
Name (Nombre) Part leaves System (Parte que deja el sistema)
Pantalla 3-3. El módulo Dispose completo

86 Capítulo 3
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,
Figura 3-23. El Expression Builder de una expresión de longitud de la fila
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
Figura 3-24. El cuadro de diálogo Text String
3.4.11 Fachada (apariencia)

El modelo 3-1 tiene varias etiquetas de texto en la vista del diagrama de flujo de la ventana del
modelo para ayudar a documentar cosas, así como para indicar qué es qué durante la anima-
ción. Éstas fueron producidas a través del botón Text ( ) en la barra de herramientas Draw,
que abre un cuadro de diálogo Text String (Cadena de texto) como el de la figura 3-24. Escriba
su texto (use Ctrl + Enter para ir a una nueva línea), quizá cambie su fuente (Times Roman,
Arial, etc), estilo de fuente (Italics [Cursiva], Bold [Negrita], etc.) y tamaño a través del botón
Font (Fuente), y después haga clic en OK (Aceptar). El cursor de su ratón se volverá una cruz
de líneas delgadas, con la cual puede hacer clic para colocar la esquina superior izquierda de la
entrada del texto en la vista del diagrama de flujo de la ventana de su modelo. Después puede
arrastrarlo alrededor, así como cambiar el tamaño y la orientación usando el subrayado que
aparece debajo de él cuando se selecciona (mantenga presionada la tecla de mayúsculas mien-
tras lo reorienta para obligarlo a ser horizontal o vertical o en una línea de 45°). Para cambiar
el color del texto, seleccione el texto y use el botón Text Color (Color de fuente) ( ) para
seleccionar tanto el color del subrayado en él (hacer clic en en este caso) como para escoger
un color diferente (haga clic en en este caso y seleccione un color de la paleta de colores), que
también será el nuevo color del subrayado.
El cuadro de fondo amarillo detrás de la etiqueta del modelo y su sombra se hicieron con el
botón Box (Cuadro) ( en la barra de herramientas) Draw (Dibujar); al presionar este botón
el cursor del ratón se vuelve una cruz de líneas delgadas, después de lo cual se hace clic una vez
para determinar una esquina del cuadro y de nuevo para determinar la esquina opuesta. Puede
cambiar el color de relleno al seleccionar primero el cuadro y después hacer clic en el botón Fill
Color (Color de relleno) ( ); cambiar el color del borde con el botón Line color (Color de
línea) ( ). Para crear efectos falsos de tres dimensiones como sombras, usted puede “apilar”
y compensar objetos de forma hábil (como un cuadro amarillo sobre uno negro ligeramente
movido) usando opciones como Send to Back (Mandar objeto al fondo) de la barra de herra-
mientas y del menú Arrange (Ordenar).
Si usted quisiera traer un archivo de gráficos (.gif, .jpg, etc.) dentro de la vista del diagrama
de flujo de la ventana de su modelo, use Edit > Insert New Object (Insertar objeto nuevo), selec-
cione Create from file (Crear desde archivo), después Browse (Navegar) para escoger el archivo
que usted quiere, presione Open, a continuación OK y, por último, déjela con la cruz de líneas
delgadas.
Está claro que se puede desperdiciar una buena cantidad de tiempo en este tipo de detalles.
Sin implicar nada acerca de nadie, se lo ofrecemos como una simple observación empírica de
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.4.13 Establecer Named Views

Para configurar Named View (Vistas nombradas) para su modelo, primero desplácese y acér-
quese a la escena que quiera recordar, después View + Named Views (el botón o teclee ?),
presione Add (Agregar), luego elija un nombre y quizá una combinación de teclas activas (sen-
sibilidad al caso). Si usted quiere cambiar después esta definición de la vista, presione Edit en su
lugar una vez que se haya desplazado y aumentado hacia la nueva vista que quiera asociar con
este nombre y una posible combinación de teclas activas; para borrarlo de la lista, selecciónelo
ahí y presione Delete. Se analizó el uso de Named Views en la sección 3.2.3.
A primera vista, configurar Named Views puede parecer un adorno, pero créanos: usted
querrá usar algo de esto cuando sus modelos crezcan.
3.5 Estudio de caso: procesamiento serial especializado frente

a procesamiento paralelo generalizado
Una pregunta operacional clásica es si tener trabajadores especializados o generales cuando el
procesamiento involucra múltiples tareas diferentes; una cuestión relacionada es cómo la varia-
ción del tiempo del procesamiento afecta la decisión. Con base en un documento de Harrison
y Loch (1995)3 podemos investigar esto usando sólo los módulos de Arena presentados en el
modelo 3-1. Los argumentos pueden hacerse para ambos trabajos, especializado y general, de-
pendiendo del entorno y de los experimentos llevados a cabo en sistemas reales, algunas veces
con resultados decepcionantes.
Un estudio de simulación cuidadoso podría ayudar a evitar tales decepciones. Considere
una oficina de solicitud de préstamos (como lo hicieron Harrison y Loch), en donde lleguen las
solicitudes con tiempos entre llegadas de distribución exponencial con una media de 1.25 ho-
ras; la primera solicitud llega en el tiempo cero. Procesar cada solicitud requiere cuatro pasos:
primero revisar el crédito (esto toma tiempo pero todos pasan), después preparar el convenio
de préstamo, luego ponerle precio al préstamo y, por último, el desembolso de los fondos. Para
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
Figura 3-25. Procesamiento serial especializado
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.
3.5.1 Modelo 3-2: Procesamiento serial. Trabajo especializado separado

Un primer pensamiento sería especializar a los trabajadores y asignarlos, digamos, Alfie a re-
visar el crédito de todas las solicitudes, Betty a preparar todos los convenios, Chuck a ponerle
precio a todos los préstamos y Doris a desembolsar todos los fondos. Así cada solicitud pri-
mero tendría que pasar por Alfie, después por Betty, luego por Chuck y por último Doris.
Un diseño puede ser como la figura 3-25, donde hay actualmente 12 solicitudes (los círculos
rellenos), Alfie está ocupado pero sin más solicitudes en la fila, Betty se encuentra desocupada
(por lo tanto sin ninguna fila), Chuck se halla ocupado con cinco más en la fila y Doris está
ocupada con cuatro más en la fila. Todas las filas son FIFO. Aunque Betty esté en desacuerdo,
es muy malo que, bajo estas reglas de operación, ella no pueda echarle una mano a Chuck o a
Doris en este momento.
Una simulación en Arena de esto, modelo 3-2, es bastante sencilla y esencialmente sólo
involucra agregar tres módulos Process al modelo 3-1, junto con tres Resources más. El mo-
delo completo aparece en la figura 3-26, con el primer módulo Process y su dialogo Resources
abierto.
Puesto que los módulos son tan similares a los del modelo 3-1, sólo destacaremos las dife-
rencias y confiaremos en usted para navegar por el modelo:
< El módulo Create es el mismo que en el modelo 3-1, excepto por el nombre del módulo
(Name), el nombre del Entity Type (Tipo de entidad), el Value (Valor) de la media de los
tiempos exponenciales entre llegadas y las unidades de tiempo (Units), ahora en horas.
< Los cuatro módulos Process tienen, como antes, la Action (Acción) de Seize Delay
Release, pero por supuesto ostentan nombres diferentes para los módulos y Resources.
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.
Alfie (los
4 pasos)
Betty (los
Solicitudes 4 pasos)
Solicitudes
que llegan completas
Chuck (los
4 pasos)
Doris (los
4 pasos)
Figura 3-27. Procesamiento paralelo generalizado
3.5.2 Modelo 3-3: Procesamiento paralelo. Trabajo integrado generalizado

¿Sería mejor “generalizar” o “integrar” el trabajo de forma que cada empleado procese por com-
pleto los cuatro pasos de una solicitud a la vez, y con una sola fila de solicitudes “abasteciendo”
al grupo? Desde el punto de vista de las solicitudes, esto podría presentar sólo una oportunidad
de pasar tiempo de espera en la cola, pero entonces de nuevo el procesamiento sería más largo.
La figura 3-27 muestra cómo funcionaría esto, donde cada empleado procesa los cuatro pasos
antes de pasar a la siguiente solicitud en la fila. Como en la imagen de procesamiento serial
especializada de la figura 3-25, hay 12 solicitudes en proceso actualmente, pero observe que el
número total en la fila ahora es ocho en lugar de nueve, ya que Betty está ocupada (no sabemos
cómo se siente ella al respecto, pero esto parece un mejor servicio).
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
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).
3.5.3 Modelos 3-4 y 3-5: El efecto de la variabilidad de tiempo de tarea

Harrison y Loch (1995) plantearon una pregunta que rebasa la comparación entre los dos
despliegues anteriores: ¿será siempre mucho mejor el segundo que el primero, como parece que
sucede? Aunque muchos otros aspectos de la situación podrían contestar esta cuestión, ellos
observaron la variabilidad de los tiempos de tarea.
Cada una de las cuatro tareas para una solicitud tiene una duración promedio de una hora,
pero estas duraciones poseen una distribución de probabilidad exponencial cercana a esa me-
dia, así que hay una variabilidad en el tiempo de tareas; tengamos una idea de qué tanta varia-
bilidad. Por ejemplo, la probabilidad de que una tarea se haga en menos de diez minutos (1/6
horas) es F (1/6) = 1−e−1/6 ≅ 0.15, donde F indica la función de distribución acumulada para
una variable exponencial aleatoria con media de una hora (véanse el apéndice C para un repaso
de probabilidad y estadística, y el apéndice D para la definición de las distribuciones de pro-
babilidad exponencial y otras). Pero algunas tareas demandarán más tiempo; la probabilidad
de que una tarea tome más de dos horas es 1 − F (2) = e−2 ≅ 0.14, similar a la probabilidad de
0.15 de hacer una tarea en menos de diez minutos. Dicho de otra forma, alrededor de 15% de
las tareas son muy rápidas (menos de diez minutos), pero casi el mismo número (14%) requie-
ren un tiempo muy largo (más de dos horas). Así que hay mucha variación en los tiempos de
tarea con su distribución exponencial y, en particular, los tiempos de tarea largos contribuyen
significativamente a congestionar y retrasar las colas y, por lo tanto, a la ineficiencia. En la con-
figuración de serie del modelo 3-2, cuando sólo aparece uno de estos tiempos de tarea largos,
se crea una gran reserva en esa estación (quizá eso es lo que le pasa a Chuck en la figura 3-25).
En la configuración paralela del modelo 3-2, un tiempo de tarea largo también aumentará el
tráfico, pero probablemente no tanto como en la configuración de serie, pues no es probable
que esté acompañado de tiempos largos similares para las otras tres tareas en esa solicitud,
lo que disminuye en algo su efecto.
Pero, ¿qué pasaría si hubiera menos variabilidad entre los tiempos de tarea, aún mientras se
mantuviera el tiempo de tarea medio en la misma de una hora? Llevémoslo al extremo y vea-
96 Capítulo 3
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
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 Más de menús, barras de herramientas, dibujo e impresión

En esta sección, mencionaremos brevemente alguna información general de los menús y barras
de herramientas de Arena y otros pocos puntos acerca de sus habilidades de dibujo e impresión
que no hemos cubierto. Conforme vayamos pasando por los ejemplos en capítulos posteriores,
daremos más detalle de estas situaciones conforme se necesiten.
Tabla 3-1. Resumen de resultados de los cuatro escenarios del modelo

de procesamiento de préstamos
Tiempo total Tiempo total Número de Uso

Modelo WIP total en el sistema de espera procesadas promedio
Promedio Máximo Promedio Máximo Promedio Máximo
Servicio expo- 3-2 En serie 12.39 21 16.08 27.21 11.98 22.27 117 0.78
nencial
3-3 Paralelo 4.61 10 5.38 13.73 1.33 6.82 135 0.87
Servicio 3-4 En serie 3.49 12 5.32 11.38 1.32 7.38 102 0.65
constante
3-5 Paralelo 3.17 11 4.81 10.05 0.81 6.05 102 0.66
98 Capítulo 3
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
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
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ú Run (de ejecución). Este menú contiene los cuadros de

diálogo Run > Setup, analizados en las secciónes 3.3.11 y
3.4.12, que controlan la forma en que se correrá el modelo ac-
tual (incluye posiblemente la duración de su ejecución). Tam-
bién contiene entradas para correr la simulación de diferentes
formas, así como varias opciones para observar la ejecución,
revisarla (véase cualquier error), configurar y controlar cómo
va la corrida y desplegarla en su pantalla. Describiremos estas
características más adelante, en la sección 3.8. Usted también
puede ingresar el código que actualmente genera Arena en el
lenguaje de simulación SIMAN subyacente.
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.
3.6.2 Barras de herramientas

Arena tiene varias toolbars (barras de herramientas) con grupos de botones y cuadros de lista
de sugerencias para facilitar el acceso rápido a actividades comunes. Algunos de estos botones
son sólo formas más rápidas para obtener un elemento del menú (analizados anteriormente), y
algunos representan la única forma de hacer algo.
Seleccione la opción del menú View + Toolbars (o presione el botón derecho del ratón en
una barra de herramientas) para escoger qué barras se desplegarán. Como en muchas aplicacio-
nes, usted puede quitar las barras de herramientas y hacerlas flotar dentro de la ventana de Are-
na como paletas, o fijarlas a una orilla (si la quiere cerca de la orilla pero no inmóvil, mantenga
presionada la tecla Ctrl mientras se acerca al borde). No necesitará colocar su configuración de
barra de herramientas cada vez que use Arena, ya que ésta recordará su última configuración.
También puede tener configuraciones diferentes para cuando está editando su modelo, ejecu-
tando la simulación y cuando varios tipos de ventanas de Arena estén activas (como Picture
Editor [Editor de imágenes]), y de nuevo, Arena recordará cómo era cada una.
Personalice cómo se despliegan las barras de herramientas vía View > Toolbars > Customize
(Personalizar) o al hacer clic con el botón derecho del ratón en una barra de herramientas, des-
pués seleccione Customize (Personalizar) y de nuevo Customize (Personalizar). Mencionaremos
cada una de las barras de herramientas más adelante, pero usted tiene la opción de reordenar qué
botones hay en qué barras de herramientas a través de esta característica de personalizació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
< La barra de herramientas Animate (Animación) contiene características que le permiten

animar su modelo o resaltar la animación que es inherente en algunos módulos de Are-
na:
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]):
En el capítulo 10 se analizará el uso de VBA, que aumenta las características de modelado

estándar de Arena con una interfaz completa de programación de Visual Basic.
< La barra de herramientas View tiene botones para controlar cómo luce la vista del
diagrama de flujo de la ventana del modelo:
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
(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):
< La barra de herramientas Animate Transfer (Animar Transferencia) proporciona los

utensilios para agregar objetos de animación a su modelo:
Éstos incluyen Storage (Almacenamiento), Seize (Tomar), Parking (Estacionamiento),

Transporter (Transportador), Station (Estación), Intersection (Intersección), Route (Ruta),
Segment (Segmento), Distance (Distancia), Network (Red) y Promote Path (Promover
Trayectoria. Analizaremos estas características en capítulos subsecuentes, a medida que
vayamos desarrollando modelos cuyas animaciones puedan beneficiarse de ellas.
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.
< 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.
3.8 Más de ejecutar modelos

Por lo general usted sólo querrá ejecutar su modelo hasta el final ya que lo haya conFigurado,
pero hay momentos donde quizás desee controlar cómo se hace la corrida. Las entradas desde
el menú Run (Ejecutar), así como de los botones correspondientes de las barras de herramientas
Standard (Estándar) y Run Interaction (Ejecutar interacción) le permiten hacer esto. (véase la
sección 4.5 para detalles y ejemplos del uso de estas características.)
< Run > Setup (Ejecutar > Configuración) le brinda acceso a muchas opciones para las
que están hechas las ejecuciones para el modelo actual, como decidir si ver la animación
y quizá correr en el modo de pantalla completa. Estas selecciones y especificaciones se
guardan con el modelo actual más que ir en efecto global. Haga clic en el botón Help
dentro de cualquier cuadro de diálogo Run + Setup y navegue por los temas con hiper-
vínculos para familiarizarse con cuáles son las (numerosas) posibilidades.
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.
< 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.9 Resumen y pronóstico

Después de este viaje a través de Arena, usted debería ser un turista bastante erudito (y can-
sado). Del capítulo 4 al 9, lo pondremos en camino para explorar por su propia cuenta, pero
con una hoja de ruta bastante detallada de nuestra parte. En esos capítulos, usted desarrollará
una secuencia de modelos cada vez más complejos que ilustran muchas de las capacidades de
modelado de Arena y que a veces le requerirán llevar a cabo algunos trucos creativos. También
integraremos al final del capítulo 4, a lo largo del 6, al final del 7 y en el 12 alguna información
de aspectos estadísticos de estudios de simulación con Arena, tanto del lado de las entradas
como de los resultados.
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-
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
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.
4.1 Modelo 4-1: montaje electrónico y sistema de prueba

Este sistema representa las operaciones finales de la producción de dos diferentes unidades
electrónicas selladas, que se muestran en la figura 4-1. Las partes que llegan son cajas de metal
moldeado que ya han sido mecanizadas y trabajadas para aceptar las partes electrónicas.
Las primeras unidades, llamadas Parte A, se producen en un departamento contiguo, fuera
de los límites de este modelo, con tiempos entre llegadas que están exponencialmente distri-
buidas con una media de 5 (todos los tiempos están en minutos) para nuestro modelo. A la
llegada, se transfieren (de forma instantánea) al área de preparación de la Parte A, en donde
las superficies de unión de las cajas se mecanizan y se trabajan para asegurar un buen sellado
y después a la parte se le quita la rebaba, se desbarba y limpia; el tiempo de proceso para esta
operación combinada en el área de preparación de la Parte A sigue una distribución TRIA(1,
4, 8). Después se transfiere la parte (otra vez, de forma instantánea) al sellador.
Las segundas unidades, llamadas Parte B, se producen en un edificio diferente, también fuera
de los límites de este modelo, en donde se les retiene hasta que esté listo un lote de cuatro unidades;
116 Capítulo 4
Preparación de la Parte A Reprocesar Descartados
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)
Figura 4-1. Montaje electrónico y prueba del sistema
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.
4.1.1 Desarrollo de un enfoque de modelado

La construcción de un modelo de simulación es sólo un componente de un proyecto de simula-
ción completo. Analizaremos el proyecto de simulación completo en el capítulo 13. Supóngase
por ahora que las primeras dos actividades son plantear el objetivo del estudio y definir el sistema
a estudiar. En este caso, nuestro objetivo es enseñarle a desarrollar un modelo de simulación
utilizando Arena. La definición del sistema se dio con anterioridad. En el mundo real, el lector
debería desarrollar esa definición y puede ser que también deba recopilar y analizar los datos
que vaya a usar para especificar los parámetros y distribuciones de entrada (véase la sección 4.5).
Recomendamos que la siguiente actividad sea el desarrollo de un enfoque de modelado. Para un
Modelación de operaciones y entradas básicas 117
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).
4.1.2 Construcción del modelo

Para construir el modelo, hay que abrir una nueva ventana del modelo y colocar los módulos
que se requieren en la pantalla: dos Crear (Create), dos Asignar (Assign), cuatro Proceso (Pro-
cess), dos Decidir (Decide), tres Grabar, Registrar (Record) y tres de Disposición (Dispose).
La ventana de su modelo debería verse ahora parecida a la figura 4-2, suponiendo que hizo
las Conexiones (Connections) o que usó la característica Auto-conectar (Auto-Connect) menú
Objeto (Object menu) mientras colocó los módulos en una secuencia apropiada (los números
dentro de sus formas del módulo deberían ser diferentes si es que colocó sus módulos en un or-
den diferente, pero eso no importa ya que todos están “en blanco” en este punto). Puede ser que
ahora el lector desee usar la función Archivo > Guardar (File > Save) para guardar su modelo
bajo el nombre de su elección.
Ahora abramos cada módulo e introduzcamos la información que se requiere para comple-
tar el modelo. Comience con el módulo 1 Crear (Create) que creará las entidades que llegan de
la Parte A. La pantalla 4-1 (el dispositivo “Pantalla” se describió en la sección 3.4.4) proporcio-
na la información requerida para completar este módulo. Note que es muy similar al módulo
Crear (Create) que se usó en el modelo 3-1. Le dimos al módulo un Nombre (Name) diferente
118 Capítulo 4
Crear Asignar Proceso

(Create) 1 (Assign) 1 (Process) 1
Proceso
(Process) 3
Crear Asignar Proceso

(Create) 2 (Assign) 2 (Process) 2
Verdadero
Verdadero
Decidir Proceso Decidir Grabar, Dispose
(Decide) 1 (Process) 4 (Decide) 2 Registrar (Disponer) 1
(Record) 1
Falso Falso Grabar, Dispose

Registrar (Disponer) 2
(Record) 2
Grabar, Dispose
Registrar (Disponer) 3
(Record) 3
Figura 4-2. Ventana del modelo de módulos colocados
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
Nombre (Name) Llega Parte A (Part A Arrive)

Entity Type (Tipo de entidad) Parte A (Part A)
Type (Tipo) Random (Aleatorio) (Expo)
Value (Valor) 5
Pantalla 4-1. Cuadro de diálogo Crear (Create) completo de la Parte A

Name (Nombre) Llega Parte B

Entity Type (Tipo de entidad) Parte B
Type (Tipo) Random (Aleatorio) (Expo)
Value (Valor) 30
Entities per Arrival (Entidades por llegada) 4
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
Name (Nombre) Assign Part A Sealer and Arrive Time

(Asignar Sellador y Tiempo de llegada de
la Parte A)
Type (Tipo) Attribute (Atributo)
Attribute Name (Nombre del atributo) Sealer Time (Tiempo del sellador)
New Value (Valor nuevo) TRIA(1, 3, 4)
Type (Tipo) Atribute (Atributo)
Attribute Name (Nombre del atributo) Arrive Time (Tiempo de llegada)
New Value (Valor nuevo) TNOW
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
Name (Nombre) Assign Part B Sealer and Arrive Time

(Asignar Sellador y Tiempo de llegada de
la Parte B)
Attribute Name (Nombre del atributo) Sealer Time (Tiempo del sellador)
New Value (Valor nuevo) WEIB(2.5, 5.3)
Type (Tipo) Atribute (Atributo)
New Value (Valor nuevo) TNOW
Pantalla 4-4. Asignación del Tiempo de sellado (Sealer Time) y del Tiempo de llegada
(Arrival Time) a la Parte B
de la entidad. La variable de Arena TNOW proporciona el tiempo de simulación actual, que en

este caso es el tiempo en el que la parte llegó o se creó (una buena manera de descubrir TNOW
es hacer clic con el botón derecho en el campo Valor nuevo [New Value] del cuadro de diálo-
go Asignaciones [Assignments] del módulo Asignar [Assign], seleccionar Construir expresión
[Build Expression], suponer las funciones Fecha y Hora [Date and Time Functions] que son
primeras en la lista, descritas como Tiempo de simulación actual [Current Simulation Time]).
La asignación para los atributos Tiempo del sellador (Sealer Time) y Tiempo de llegada
(Arrive Time) para la Parte B se indica en la pantalla 4-4. Aunque se crearon cuatro entidades
en el módulo anterior para cada llegada, a cada una se le asignará un valor diferente (indepen-
diente) de la distribución de tiempo del sellador en el siguiente módulo Asignar (Assign).
Habiendo completado los dos módulos de llegada de las partes y la asignación para los tiem-
pos del sellador, ahora nos podemos mover hacia las dos áreas de preparación que se modelarán
al usar dos módulos Proceso (Process) colocados con anterioridad. El cuadro de diálogo completo
para el área Proceso de la preparación A (Prep A Process) se indica en la pantalla 4-5.
El módulo Proceso (Process) tiene cuatro acciones posibles: Delay (Demorar), Seize Delay
(Tomar Demorar), Seize Delay Release (Tomar Demorar Liberar) y Delay Release (Liberar De-
morar). La acción Delay (Demorar) ocasionará que una entidad experimente un tiempo específico
de demora. Esta acción no requiere de un Recurso (Resource). Ello implica que hará una espera y
que entidades múltiples podrían experimentar Demora (Delay) de forma simultánea. Puesto que
nuestra área de preparación requiere el uso de una máquina o Recurso (Resource), necesitamos
una acción que permita una espera, hacer cola hasta que el recurso de preparación esté disponible
y demore el tiempo de proceso. La acción Seize Delay (Tomar Demorar) proporciona la espera y
la demora, pero no libera el Recurso (Resource) al final del proceso para que esté disponible para
la siguiente entidad. Si usted lector utiliza esta acción, se supone que el Recurso (Resource) será
Released (Liberado) hacia abajo en otro módulo. La opción Seize Delay Release (Tomar Demo-
rar Liberar) proporciona un conjunto de acciones que se requieren para modelar nuestra área de
preparación de forma adecuada. La última acción, Delay Release (Demorar Liberar), asume que
la entidad previamente Seized (Tomó) un Recurso (Resource) y experimentará aquí una Delay
(Demora), seguida por la Release (Liberación) del Recurso (Resource).
Podrá notar que cuando usted selecciona una de las tres últimas opciones, aparece un cua-
dro de lista en el espacio vacío que está abajo del cuadro de selección de la acción. Haga clic en
Add (Añadir) para introducir la información del Recurso (Resource).
En los datos que se introducen, lo exhortamos mucho a hacer uso de las listas de sugerencias
siempre que sea posible. La razón de esta precaución es que una vez que teclee un nombre, siem-
Preparación
del proceso
A
Name (Nombre) Prep A Process (Preparación del proceso A)

Resources (Recursos)
Resource Name (Nombre del recurso) Prep A (Preparación de A)
Delay Type (Tipo de demora) Triangular (Triangular)
Minimum (Mínimo) 1
Value (Valor) (Most Likely [el más 4
frecuente])
Maximum (Máximo) 8
Pantalla 4-5. Cuadro de diálogo Preparación del proceso A (Prep A Process)
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
Name (Nombre) Sealer Process (Proceso de sellado)

Resource Name (Nombre del recurso) Sealer (Sellado)
Delay Type (Tipo de demora) Expression (Expresión)
Expression (Expresión) Sealer Time (Tiempo de sellado)
Pantalla 4-6. Cuadro de diálogo Sellado (Sealer)
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]).
Inspección
de sellado
fallida
Name (Nombre) Failed Sealer Inspection (Inspección de

sellado fallida)
Percent True (Porcentaje verdadero) 9
Pantalla 4-7. Cuadro de diálogo de Inspección de sellado (Sealer Inspection)
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.
Name (Nombre) Rework Process (Proceso de Retrabajo)

Resource Name (Nombre del recurso) Rework (Retrabajo)
Expression (Expresión) EXPO (45)
Pantalla 4-8. Cuadro de diálogo de Proceso de retrabajo (Rework process)
Name (Nombre) Failed Rework Inspection (Inspección de re-

trabajo fallida)
Percent True (Porcentaje verdadero) 20
Pantalla 4-9. Cuadro de diálogo de Inspección del retrabajo, (Rework inspection)

124 Capítulo 4
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
Name (Nombre) Record Scrapped Parts (Grabar Partes

descartadas)
Type (Tipo) Time Interval (Intervalo de tiempo)
Tally Name (Nombre de cuenta) Record Scrapped Parts (Grabar Partes
descartadas)
Pantalla 4-10. Cuadro de diálogo Grabar Partes descartadas (Record Scrapped Parts)
Descartadas
Name (Nombre) Scrapped (Descartadas)
Pantalla 4-11. Cuadro de diálogo Scrapped dispose (Disponer 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
Project Title (Título del proyecto) Electronic Assembly and Test

Ensamblado electrónico y Prueba)
Analyst Name (Nombre del analista) Mr. Munchkin (Sr. Munchkin)
Project Description (Descripción del La primera versión del ensamblado elec-
proyecto) trónico y prueba del modelo,como se
describió en la sección 4.1.
Statistics Collection (Recopilación de
estadísticas)
Entities (Entidades) clear (despejar)
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.
Replication Length (Duración de la réplica) 32

Base Time Units (Unidades de tiempo base) Minutes (Minutos)
Pantalla 4-13. Parámetros de réplica al ejecutar configuración (Run Setup Replication Parameters)
4.1.3 Ejecución del modelo

Antes de ejecutar su modelo debe revisarlo en busca de errores. Para ello haga clic en el botón
Check (Revisar) ( ) en la barra de herramientas Run Interaction (Interacción de ejecución), el
comando Run > Check Model (Ejecutar > Revisar modelo) o la tecla F4. Con un poco de suerte, la
respuesta será una pequeña ventana con el mensaje: “ningún error o advertencia en el modelo”. Si
el lector no es tan afortunado, se abrirá una ventana de error con un mensaje en el que se describe
la falla. Si esto ocurre, seleccione la opción Find (Encontrar), si el botón está permitido. Esta carac-
terística intenta indicarle el lugar en donde Arena cree que pueda localizarse el error. Le sugerimos
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)
Pantalla 4-14. Módulo de datos de entity (entidad)

128 Capítulo 4
Asignar sellador Proceso de pre-

Llega Parte A de la Parte A paración de A
y el tiempo de
llegada
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
Figura 4-3. Modelo 4-1 final
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-
dad de animación (Animation Speed Factor ) se desplegará en la orilla izquierda de la barra de

estatus. También puede aumentar o disminuir el factor de velocidad de animación de la etiqueta
Run Speed (Velocidad de ejecución) del cuadro de diálogo Configuración de la ejecución (Run
Setup). Esta opción también se puede emplear para introducir un factor de velocidad exacto.
Durante la ejecución de la simulación, también puede pausarla al usar el botón Pause (Pau-
sa) ( ) en la barra de herramientas Estándar (Standard), Run > Pause (Ejecutar > Pausa) o
la tecla Esc. Lo anterior suspende temporalmente la simulación y aparecerá el mensaje “User
Interrumped” (Interrumpida por el usuario) en la barra de estado (status bar).
Mientras se encuentra en el modo de Pausa, tal vez quiera dar doble clic en una de las entida-
des que se encuentre visible en la animación. Un cuadro de diálogo Entity Summary (Sumario de
Entidad) lista los valores de cada uno de los atributos de las entidades. Ésta puede ser una ayuda
muy util al tratar de depurar el modelo. Puede utilizar de igual forma el botón Step (Paso) ( ) de
la barra de herramientas Run (Ejecutar) a fin de mover las entidades a través del sistema un paso
a la vez. Puede continuar con la ejecución “normal” en cualquier momento con el botón Go (Ir).
Este método de ejecutar una simulación proporciona la mayor cantidad de información,
pero puede tomar mucho tiempo terminarlo. En este caso, el tiempo requerido para completar
la ejecución depende del factor de velocidad de animación (Animation Speed Factor). Puede
adelantarse en el tiempo al seleccionar el botón Avance rápido (Fast-Forward) ( ) en la barra
de herramientas Run (Ejecutar), o Run > Fast-Forward (Ejecutar > Avance rápido). Esto oca-
sionará que la simulación se ejecute a una velocidad mucho mayor al no actualizar las gráficas
de animación. En cualquier momento durante la ejecución de avance rápido, puede seleccio-
nar de nuevo el botón Go (Ir) para regresar al modo de animación. Durante la ejecución en el
modo de animación, usted puede acercar (Zoom In) (+), alejar (Zoom Out) (−) o desplazarse
en la ventana de la simulación (teclas de flechas o barras de desplazamiento).
Al usar el Avance rápido ejecutará la simulación en mucho menos tiempo, pero si está inte-
resado sólo en los resultados numéricos de la simulación, querrá inutilizar toda la animación
(actualización de cálculo y gráficas). Puede hacerlo con la opción Run > Run Control > Batch
Run (No animation) (Ejecutar >Control de ejecución > Ejecución de grupo sin animación).
La opción Run > Run Control (Ejecutar > Control de ejecución) también le permite confi-
gurar una cantidad de otras opciones de tiempos de ejecución. Por ahora, seleccione la opción
Batch Run (No animation) (Ejecución de grupo sin animación). Note que si usted vuelve de nuevo
a esta opción, hay una revisión a la izquierda. Acepte esta opción y haga clic en el botón Run
(Ejecutar). Note cuánto más rápido se ejecuta la animación. La única desventaja es que debe
terminar la ejecución y restaurar las configuraciones de la animación para recuperarla. Si tiene
modelos grandes o ejecuciones largas y está interesado sólo en los resultados numéricos, ésta es
la opción a elegir puesto que es aun más veloz que el Avance rápido.
Mientras el lector construye un modelo, con probabilidad tiene visibles y accesibles la mayo-
ría de las barras de herramientas. Sin embargo, cuando ejecuta un modelo, muchas de la barras
de herramientas simplemente consumen espacio puesto que no están activas durante el tiem-
po de la ejecución. Arena reconoce esto y guardará las configuraciones de sus barras de herra-
mientas para cada modelo. Para aprovechar tal situación, haga una pausa durante la ejecución
y retire las barras de herramientas que quiera desactivar mientras corre la simulación. Cuando
termine la ejecución, estas barras de herramientas reaparecerán. También puede ir a Run >
Setup > Run Control (Ejecutar > Configuración > Control de ejecución) antes de la ejecución y
revisar el cuadro Run (Ejecutar) en el Full-Screen Mode (Modo de pantalla completa) (puesto
130 Capítulo 4
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]).
4.1.4 Ver los resultados

Si seleccionó la opción del menú Run > Go (Ejecutar > Ir) (o el botón Ir ) habrá notado que,
además de las bolas azules y de las rojas (nuestras entidades de las partes A y B) moviéndose
a través del sistema, hay varios contadores animados que aumentan durante la ejecución de la
simulación. Existe un único contador para cada módulo Crear (Create), Proceso (Process) y de
Disposición (Dispose) y dos contadores para cada módulo Decidir (Decide). Los contadores
para los módulos Crear (Create), Dispose (Disposición) y Decidir (Decide) aumentan cada vez
que una entidad abandona el módulo. En el caso de los módulos Proceso (Process), el contador
es el número de entidades que actualmente se encuentran en ese módulo, incluyendo cualquier
entidad en la cola esperando el recurso, además de toda entidad que esté en proceso en la ac-
tualidad. Si seleccionó la opción del menú Run > Fast-Forward (Ejecutar > Avance rápido) (o
el botón Fast-Forward [Avance rápido], ), estos contadores (y las entidades de las colas) se ac-
tualizarán al final de la ejecución y siempre que haga una pausa o cambie las vistas del modelo.
Los números finales que resultan de nuestra simulación se muestran en la figura 4-4.
Si corre el modelo hasta que se complete, Arena le preguntará si desea ver los resultados. Si
selecciona Yes (Sí), obtendrá una ventana que muestra el Reporte general de categorías (Ca-
tegory Overview Report) (el reporte predeterminado). Cuando aparece la primera página del
reporte, le puede parecer extraño que se despliegue el mensaje “No hay ninguna estadística de
resumen disponible”. Las estadísticas de resumen del sistema son las estadísticas de entidades
Asignar sella-
Proceso de
dor de la Parte
Llega Parte A preparación
A y el tiempo
de llegada de A
Proceso de
sellado
Asignar sella- Proceso de

Llega Parte B dor de la Parte
preparación
B y el tiempo
de llegada de B
Inspección Inspección Registro de

Proceso de
de sellado de retrabajo partes des- Descartadas
Retrabajo
fallida fallida cartadas
Registro de
partes recu- Recuperadas
peradas
Registro
de partes Enviadas
enviadas
Figura 4-4. Resultados animados del modelo 4-1

y de costo que elegimos no recopilar cuando despejamos la selección Entidades (Entities) en la

etiqueta Parámetros del proyecto (Project Parameters) del cuadro de diálogo Run > Setup (Eje-
cutar > Configuración) (véase la pantalla 4-12). En algún punto puede cambiar estas selecciones
y ver la diferencia en los reportes.
Recuerde que puede navegar a través del reporte al usar las tres listas debajo de la etiqueta
Preview (Vista previa) que se encuentra en el lado izquierdo de la ventana del reporte o al usar
los botones de las flechas de la esquina superior izquierda de la ventana del reporte. Este repor-
te proporcionará estadísticas por categorías, seleccionadas en el cuadro de diálogo Run Setup
(Configuración de la ejecución) (etiqueta Project Parameters [Parámetros del proyecto], área
Statistics Collection [Recolección de estadísticas]). Para nuestro modelo, encontrará secciones
en Proceso (Process), Queue (Cola), Recurso (Resource) y User Specified (Especificadas por
Usuario). La elección User Specified (Especificadas por Usuario) está ahí porque incluimos
módulos Grabar, Registrar (Record) para recopilar estadísticas en los tiempos del ciclo clasifi-
cados por tipo de salida.
Al igual que en el capítulo 3, encontrará tres tipos de estadísticas en nuestro reporte: tally
(cuenta), time persistent (persistente en el tiempo) y counter (contador). Hay disponible una cuarta
estadística outputs (resultados) cuando se hacen réplicas múltiples (hablaremos al respecto en el
capítulo 6, cuando hagamos réplicas múltiples). Aquí las estadísticas tally (cuenta) incluyen varios
tiempos de proceso, tiempos de colas y los tiempos de intervalo recopilados por nuestros módulos
Grabar, Registrar (Record). Las estadísticas persistentes en el tiempo incluyen números de espera
en la cola y uso y utilización del recurso. Los contadores incluyen tiempo acumulado, números
dentro, números fuera y el número total de tomados.
Las estadísticas tally (cuenta) y persistentes en el tiempo proporcionan el promedio, (Half
Width) (mitad del intervalo de confianza de 95%) y los valores mínimo y máximo observados.
Con la excepción de la columna de mitad del intervalo de confianza de 95%, estas entradas se
describen en los capítulos 2 y 3 y deberían explicarse por sí mismas.
Al final de una ejecución de simulación de una sola réplica, Arena intenta calcular la mitad del
intervalo de confianza de 95% para un valor esperado de estado constante (larga duración) de cada
estadística observada, al usar un método llamado medias por intervalos o lotes de datos (véase la
sección 7.2.3). Arena primero revisa si se recopilaron suficientes datos para probar las suposiciones
estadísticas críticas (lotes no correlacionados) que se requieren en el método medias por intervalos o
lotes de datos. Si no es así, en el reporte aparece la anotación “Insuficiente” y no se produce la mitad
del intervalo de confianza, como se puede ver para varios de los resultados. Si existen suficientes
datos para probar los lotes no correlacionados, pero falla la prueba, aparece la anotación “Corre-
lacionado” y otra vez no hay mitad del intervalo, que es el caso para varios de los resultados. Si
hubo suficientes datos para efectuar la prueba para lotes no correlacionados y ésta se pasó, se dará
la estadística de la mitad (la cantidad “mayor o menor”) de un intervalo de confianza de 95% en un
valor esperado de larga duración (estado constante) (esto sucede para pocos de los resultados en
esta ejecución). De tal forma, Arena se rehúsa a reportar valores de mitad del intervalo de poca con-
fianza aun cuando podría hacerlo desde un punto de vista meramente computacional. Los detalles
e importancia de estas pruebas se analizarán con mayor detalle en la sección 7.2.3.
Intentar esbozar conclusiones de esta sola ejecución de corta duración sería erróneo, porque
aún no hemos señalado temas como duración de la ejecución, número de repeticiones e incluso
si los resultados de una ejecución de larga duración en estado constante son apropiados (pero lo
haremos, en la sección 7.2). Sin embargo, si se fija en los resultados para el tiempo de espera en
la cola y el número de espera en la cola (figura 4-5), puede ver que la estación de retrabajo se en-
132 Capítulo 4
Figura 4-5. Sección de la cola del Reporte general de categorías

(Category Overview report): modelo 4-1
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.)
4.2 Modelo 4-2: montaje electrónico mejorado y sistema de prueba

Habiendo construido y ejecutado nuestro modelo, la siguiente actividad sería verificar que el
“código” (archivo de Arena) esté libre de Bugs (Bichos)2 y también validar que el modelo con-
ceptual en verdad represente el sistema que se estudia (véanse las secciones 2.8 y 13.6). Para
este ejemplo es bastante fácil. Podemos examinar las construcciones lógicas que seleccionamos
de los módulos que usamos y compararlas con la definición del problema. Con sistemas más
largos y complejos, esto puede convertirse en una tarea bastante desafiante. A menudo es útil
una animación durante las fases de verificación y validación porque permite observar el sistema
completo que está siendo modelado conforme opera. Si ejecutó el modelo que desarrollamos y
vio su animación, debería haber notado que parecía operar de forma bastante similar a la que
describimos en el sistema. Si la verificación es muy difícil, la validación completa (la siguiente
actividad) puede ser casi imposible. Esto se debe a que la validación implica que la simulación
se comporta como el sistema del mundo real, que quizá ni siquiera exista, así que imagíneselo.
Y aun si el sistema existiera, debe tener datos de desempeño de su resultado, así como conven-
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.
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.
4.2.1 Expansión de la representación de recursos: Programas y Estados

Hasta ahora hemos modelado cada uno de nuestros recursos (área de preparación, sellado y re-
trabajo) como uno solo con una capacidad fija de 1. Debe recordarse que predeterminamos toda
esta información en el módulo Datos del recurso (Resource data). Para modelar el operador de
134 Capítulo 4
revisión adicional, podríamos simplemente cambiar la capacidad del recurso de retrabajo a 2,

pero ello significaría que siempre tendríamos dos operadores disponibles. Lo que necesitamos
hacer es programar un operador de retrabajo para el primer turno (supongamos que cada tur-
no es de 8 horas) y dos operadores de retrabajo para el segundo turno. Arena tiene una cons-
trucción ya incluida para modelar esto, llamada Schedule (Programa), que le permite variar la
capacidad de un recurso en el tiempo de acuerdo con un patrón fijo. Un Programa de recurso se
define por una secuencia de cambios dependientes del tiempo en la capacidad del recurso.
También hay que captar en nuestro modelo las interrupciones (fallas) aleatorias periódicas
de la máquina de sellado. Esto podría modelarse usando un Programa (Schedule), que definiría
una capacidad de recurso disponible de 1 para los tiempos de funcionamiento y una capacidad
de 0 para el tiempo de reparación. Sin embargo, existe una construcción ya incluida diseñada
específicamente para modelar las fallas. Primero, introduciremos el concepto de Resource Sta-
tes (Estados del recurso).
De forma automática, Arena tiene cuatro Estados del recurso: Ocioso (Idle), Ocupado
(Busy), Inactivo (Inactive) y Descompuesto (Failed). Para el reporte estadístico, Arena mantiene
el rastro del tiempo que el recurso estuvo en cada uno de los cuatro estados. Se dice que el re-
curso está Ocioso (Idle) si ninguna entidad lo ha tomado. Tan pronto como una entidad toma
el recurso, el estado se cambia a Ocupado (Busy). El estado cambiará a Inactivo (Inactive) si
Arena ya hizo que el recurso no esté disponible para asignación; esto se podría conseguir con
el cambio del Programa en el estado Failed (Descompuesto), que también implica que no está
disponible para asignación.
Cuando ocurre una falla, Arena hace que todo el recurso no esté disponible. Si la capacidad
es 2, por ejemplo, ambas unidades del recurso se colocarán en el estado Descompuesto (Failed)
durante el tiempo de reparación.
4.2.2 Programas del recurso

Antes de añadir nuestro programa del recurso para la operación de retrabajo, primero defina-
mos nuestro nuevo día de 16 horas. Hagamos esto en la etiqueta Parámetros de réplica (Repli-
cation Parameters) en la opción Run > Setup (Ejecutar > Configuración), al cambiar las horas
por día de 24 a 16 (ignore la advertencia acerca de Calendarios que pueda aparecer). Mien-
tras estamos en el cuadro de diálogo, cambiemos también nuestras Unidades de tiempo (Time
Units) para la Duración de la réplica (Replication Length) a Días (Days) y la Duración de
la réplica (Replication Length) por sí misma a 10 días.
Puede comenzarse la definición de un programa de recurso ya sea en el módulo de datos
Recurso (Resource) o Schedule (Programa). Iniciaremos con el módulo de datos Recurso (Re-
source). Cuando hace clic en este módulo desde el Panel de procesos básicos (Basic Process
panel), la información de los recursos actuales en el modelo se desplegará en la vista de la hoja
de cálculo de la ventana del modelo en la parte inferior de su pantalla. Ahora haga clic en la
columna Tipo (Type) para la cola del recurso Revisión y seleccione Based on Schedule
(con base en el programa) de la lista. Cuando seleccione esta opción, Arena añadirá
dos nuevas columnas a la vista de la hoja de datos (Nombre del programa y Regla del progra-
ma). Note que la celda Capacidad para el recurso Retrabajo se ha oscurecido porque aún tiene
una capacidad fija. Después debería escribir el nombre del programa (por ejemplo, Rework
Schedule) en la celda del Nombre del programa para el recurso Retrabajo.
Por último, necesita seleccionar la Regla del programa (Schedule Rule), que puede afectar el
tiempo específico en que de hecho cambiará la capacidad definida por el programa. Existen tres
Comienza Termina
interrupción interrupción
programada programada
Dejar inconcluso Línea de tiempo
Nuevo fin de
interrupción en 1:15
Línea de tiempo
Esperar
Duración de
interrupción
reducida
Ignorar Línea de tiempo
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)
Rework Resource (Recurso Retrabajo)

Type (Tipo) Based on Schedule (con base en el
programa)
Schedule Name (Nombre del programa) Rework Schedule (Revisar Programa)
Schedule Rule (Nombre de la regla) Ignore (Ignorar)
Pantalla 4-15. El módulo de datos Recurso (Resource): selección de un programa de 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
Figura 4-7. El editor de programa gráfico: el Rework Schedule (Programa de Retrabajo)
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)
Name (Nombre) Rework Schedule (Programa Revisión)

Value (Valor) 1
Duration (Duración) 8
Value (Valor) 2
Pantalla 4-16. Cuadro de diálogo del módulo de datos 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).
4.2.3 Fallas del recurso

Los programas tienen la intención de modelar la variación planeada en la disponibilidad de
recursos debida a cambios de turno, interrupciones, vacaciones, reuniones, etc. Las fallas tie-
nen primeramente la intención de modelar eventos aleatorios que causan que el recurso esté no
disponible. El lector puede comenzar su definición de falla tanto en el módulo de datos Recurso
(Resource) como en el de Falla (Failure). El módulo de datos Failure se puede encontrar en el
Advanced Process Panel (Panel de procesos avanzados) (que es posible que tenga que adjuntar
en este punto vía el botón o File > Template Panel > Attach [Archivo > Panel de plantilla >
Adjuntar] si no está aún disponible en la Project Bar [Barra de Proyecto]). Ya que comenzamos
con el módulo Resource al desarrollar nuestro programa, iniciemos con el modelo de datos
Failure para nuestra falla de sellado (Sealer).
Si se necesita hacer visible el Panel de proceso avanzado (Advanced Process panel) en la barra
de proyectos, hágase clic en su nombre y después en el módulo de datos Failure. La vista de hoja de
cálculo para este módulo no mostrará las entradas actuales. Haga doble clic donde se indica para
añadir un nuevo renglón. Después seleccione el nombre predeterminado en la columna Name y
reemplácelo con un nombre de falla significa tivo, como Sealer Failure (Falla de se-
llado). Luego seleccione si la falla es Count-based (con base en el conteo) o Time-based (con
base en el tiempo) usando la lista en la celda Tipo (Type). Una falla con base en el conteo ocasiona
que el recurso falle después de que un número específico de entidades haya usado el recurso. Este
Failure
(Falla)
Name (Nombre) Sealer Failure (Falla de sellado)

Type (Tipo) Time (Tiempo)
Up Time (Tiempo de funcionamiento) EXPO(120)
Up Time Units (Unidades de tiempo de Minutes (Minutos)
funcionamiento)
Down Time (Tiempo fuera de funcionamiento) EXPO(4)
Down Time Units (Unidades de tiempo fuera de Minutes (Minutos)
funcionamiento)
Pantalla 4-17. Vista de la hoja de cálculo de la Sealer Failure (falla de sellado)
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)
Sealer Resource Failure (Falla de recurso de sellado)

Failure Name (Nombre de falla) Sealer Failure (Falla de sellado)
Failure Rule (Regla de falla) Wait (Esperar)
Pantalla 4-18. El módulo de datos Sealer Resource (Recurso de sellado):

vista de la hoja de cálculo Failures (Fallas)
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
Pantalla 4-19. Cuadro de diálogo Expression Builder (Construir expresión)
introducir es NQ (Rework Process.Queue). En este punto, el lector se debe estar preguntan-

do: “¿Acaso se espera que yo sepa todo eso?” Para un experimentado (y viejo) usuario SIMAN,
esto es obvio. Sin embargo, claramente no es obvio para un usuario nuevo. Afortunadamente,
Arena proporciona una forma fácil de desarrollar estos tipos de expresiones sin la necesidad
de saber todas las palabras secretas (por ejemplo, NQ). Coloque su puntero en la celda vacía
Expression, haga clic en el botón derecho y seleccione Build Expression (Construir expresión).
Esto abrirá la ventana Arena Expression Builder (Construir expresión de Arena) presentada en
la pantalla 4-19. Debajo de la categoría Basic Process Variables (Variables de procesos básicos)
de Expression Type (Tipo de expresión), encontrará la subcategoría Queue (Cola). Haga clic en
el signo + para expandir las opciones y luego seleccione Current Number in Queue (Número
actual en la cola). Cuando haga esto, sucederán dos cosas: el campo Queue Name (Nombre de
la cola) aparecerá a la derecha y Current Expression (Expresión actual) abajo se llenará con
el nombre de cola mostrado. En nuestro caso, la Current Expression era NQ (Prep A Pro-
cess.Queue), que aún no es lo que queremos (es la cola equivocada). Ahora use la flecha de
la lista de sugerencias de Queue Name para ver y seleccionar el Rework Process.Queue.
Statistic
(Estadística)
Name (Nombre) Rework Queue Stats (Estadísticas de la cola

de retrabajo)
Type (Tipo) Frequency (Frecuencia)
Frequency Type (Tipo de frecuencia) Value (Valor)
Expresión (Expresión) NQ (Rework Process. Queue)
Pantalla 4-20. Entrada parcial de frecuencias en el módulo de datos Statistic (Estadística)

142 Capítulo 4
Constant or Range (Constante o rango) Constant (Constante)

Value (Valor) 0
Category Name (Nombre de la categoría) 0 Racks (Estantes)
Constant or Range (Constante o rango) Range (Rango)
Value (Valor) 0
High Value (Valor alto) 10
Category Name (Nombre de la categoría) 1 Rack (Estante)
Constant or Range (Constante o rango) Range (Rango)
Value (Valor) 10
High Value (Valor alto) 20
Category Name (Nombre de la categoría) 2 Racks (Estantes)
Pantalla 4-21. Categorías para estadísticas de frecuencia estadística de la cola de retrabajo
Entonces, cuando haga clic en OK (Aceptar), esa expresión automáticamente se introducirá en

el campo desde el que abrimos el Expression Builder.
Puede hacer clic con el botón derecho en cualquier campo en que se pueda introducir una
expresión para abrir el Expression Builder. Por ejemplo, pudimos haber usado el Expression
Builder para encontrar la expresión para el tiempo de simulación actual (TNOW). También pue-
de construir expresiones complejas usando los botones de función en el Expression Builder, así
como teclear caracteres (la forma antigua, suponiendo que usted sabe qué escribir) en el campo
Current Expression en la parte inferior.
La vista de hoja de cálculo para este punto (todavía no la hemos hecho) se presenta en la
Pantalla 4-20.
El último paso en la configuración de las estadísticas de la cola de revisión es construir las ca-
tegorías que definen cómo queremos que se muestren los valores, hecho en la columna Categories
(Categorías) en el extremo derecho (hacer clic en el botón “0 Rows [Renglones]” para abrir una
hoja de cálculo a la que se añadirá un renglón para cada categoría). La pantalla 4-21 presenta las
entradas para las primeras tres categorías. La primera entrada es para un tamaño de cola de una
Constante (Constant) 0 (en cuyo caso, necesitaríamos 0 estantes); las entradas siguientes son para
un estante, dos estantes, etc. Por ahora, sólo solicitaremos esta información hasta cuatro estantes.
Si la cola siempre supera 40 partes, Arena creará una categoría fuera de rango en el reporte de
resultados. En el caso de un Rango (Range), note que el Valor (Value) no se incluye en el rango,
pero sí el Valor Alto (High Value). Así, por ejemplo, Value = 10 y High Value = 20 define un
rango de números (10, 20]; esto es, (estrictamente) mayor que 10 y menor o igual a 20.
Antes de abandonar el módulo de datos Statistic, también queremos solicitar información
adicional en el recurso sellador (Sealer). Si nosotros ejecutamos nuestro modelo actual, la in-
formación en el empleo del recurso Sealer se incluirá en nuestros reportes como antes. Sin
Statistic
(Estadística)
Name (Nombre) Sealer States (Estados de sellado)

Type (Tipo) Frequency (Frecuencia)
Frequency Type (Tipo de frecuencia) State (Estado)
Resource Name (Nombre de recurso) Sealer (Sellado)
Pantalla 4-22. Módulo de datos Estadística (Statistic) para los Estados de sellado (Sealer States)
embargo, no reportará específicamente la cantidad de tiempo que el recurso se encuentra en

estado descompuesto. Podemos solicitar esta estadística al añadir un nuevo renglón en nuestro
módulo de datos Statistic como se presenta en la pantalla 4-22. Para esta estadística, introdu-
cimos el Name y Type, Sealer States (Estados de sellado) y Frequency, y selec-
cionamos State (Estado) para el Tipo de frecuencia (Frequency Type). Por último,
Tabla 4-1. Resultados seleccionados de los modelos 4-1 y 4-2
Resultado Modelo 4-1 Modelo 4-2

Tiempo de espera promedio en la cola
Prep A 14.62 19.20
Prep B 26.90 51.42
Sellado 2.52 7.83
Retrabajo 456.35 116.25
Número promedio esperando en la cola
Prep A 3.17 3.89
Prep B 3.50 6.89
Sellado 0.86 2.63
Retrabajo 12.95 3.63
Tiempo promedio en el sistema
Partes enviadas 28.76 47.36
Partes recuperadas 503.85 203.83
Partes descartadas 737.19 211.96
Utilización instantánea del recurso
Prep A 0.9038 0.8869
Prep B 0.7575 0.8011
Sellado 0.8595 0.8425
Retrabajo 0.9495 0.8641
Utilización programada del recurso
Prep A 0.9038 0.8869
Prep B 0.7575 0.8011
Sellado 0.8595 0.8425
Retrabajo 0.9495 0.8567
144 Capítulo 4
seleccionamos el recurso Sealer de la lista en la celda Resource Name (Nombre de recurso).

Esto nos dará estadísticas con base en todos los estados del recurso Sealer, Busy (Ocupado),
Idle (Ocioso) y Failed (Descompuesto).
Antes de que ejecute este modelo, recomendamos al lector que revise la opción Run > Run
Control > Batch Run (No Animation) [Ejecutar > Control de ejecución > Ejecución de grupo
(Sin animación)], que reducirá considerablemente la cantidad de tiempo requerido para ejecutar
el modelo. Aunque más despacio, una alternativa es seleccionar Run > Fast-Forward (Ejecutar
> Avance Rápido) ( ). Ahora también sería un buen momento para guardar su trabajo. Note
que puede hacer pausa en la ejecución en cualquier momento para determinar qué tanto ha
progresado.
4.2.5 Resultados del modelo 4-2

La tabla 4-1 proporciona algunos resultados seleccionados de los Reportes (Reports) de este
modelo (columna más a la derecha), así como del modelo 4-1 para compararlos. Redondeamos
todo a dos decimales excepto para los dos tipos de resultados de utilización, que se dan en cua-
tro decimales (con la finalidad de hacer un punto particular de ellos).
Los resultados de este modelo difieren de los producidos por el modelo 4-1 por varias razo-
nes. Ahora estamos ejecutando la simulación por diez días de 16 horas (160 horas) en lugar de
las 32 horas del modelo 4-1. Y, por supuesto, tenemos diferentes suposiciones de modelación en
los Resources Sealer y Rework. Por último, todos estos hechos se combinan para hacer que el
flujo del número aleatorio subyacente se use de forma diferente (se abundará más en tal asunto
en el capítulo 12).
Pasar del modelo 4-1 al 4-2 no involucró ningún cambio en las partes Prep A o Prep B del
modelo, así que las diferencias que vemos se deben sólo a las diferencias en la longitud de eje-
cución o a brincos aleatorios. La diferencia para los resultados de la cola Prep B son bastante
notables, ya sea que esta área se congestione más a medida que el tiempo avanza, o que los
resultados estén sujetos a mucha incertidumbre; no sabemos cuál, (mayor razón para hacer
análisis estadísticos de los resultados, que no estamos haciendo aquí).
Para el Sellador (Sealer), las estadísticas de la cola (tanto tiempo de espera promedio como
longitud promedio) muestran considerablemente más congestión para el modelo 4-2. Esto tiene
sentido, ya que en tal modelo agregamos las fallas al sellador, poniéndolo fuera de acción ahora
y entonces, durante el tiempo que se desarrolló la cola. Las estadísticas de utilización para el
sellador no son tan diferentes entre los dos modelos, aunque, puesto que se encuentra en estado
de fallas el sellador no está disponible, así que estos periodos no cuentan “en contra” de las
utilizaciones del sellador.
A diferencia del sellador (Sealer), la operación Rework (Retrabajo) parece volverse mucho
más suave en el modelo 4-2. Por supuesto, la razón para esto es que añadimos una segunda
unidad del recurso Rework durante el segundo turno de ocho horas en cada día de 16 horas.
Esto incrementa la capacidad de operación Rework en 50% en el tiempo, así que ahora tiene
una capacidad de tiempo promedio de 1.5 en lugar de 1. Y, por consiguiente, las estadísticas
de utilización de la operación Rework parecen disminuir sustancialmente (más de estos tipos
diferentes de utilización se verán a continuación).
Viendo el tiempo promedio en el sistema de los tres tipos de partes que salen, parece claro
que los cambios en las operaciones Sealer y Rework tienen su efecto. Todas las partes tienen que
soportar que la operación Sealer sea ahora más lenta, llevando la cuenta del aumento en el tiempo
promedio en el sistema de las partes enviadas. Las partes recuperadas y descartadas, sin embargo,
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
Figura 4-8. El reporte de frecuencias de Arena: modelo 4-2
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
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.
4.3 Modelo 4-3: mejora de la animación

Hasta ahora en este capítulo simplemente hemos aceptado la animación predeterminada pro-
porcionada con los módulos que usamos. Aunque esta animación base a menudo es suficiente
para determinar si su modelo está trabajando de forma correcta, se puede querer que la ani-
mación se vea más como el sistema real antes de permitir que los que toman las decisiones
observen el modelo. Hacer la animación más realista es verdaderamente muy fácil y pocas
veces requiere mucho tiempo. Para una extensión larga, la cantidad de tiempo que usted decida
invertir depende del nivel de detalle que quiera añadir y la naturaleza de la audiencia para sus
esfuerzos. Una observación general es que, para propósitos de presentación, a mayor nivel en
la organización, mayor será el tiempo que probablemente se pase en la animación. También
encontrará que embellecer la animación puede ser muy divertido y hasta volverse una obsesión.
Así que con esa idea en la mente, exploremos algo de lo que se puede realizar al respecto.
Modificaremos el modelo 4-2 en lo que llamaremos el modelo 4-3, y comenzaremos viendo
la animación existente. La animación actual tiene tres componentes: entidades, colas y variables.
Las entidades que seleccionamos usando el módulo de datos Entidad (Entity) se pueden ver cuan-
do viajan de un módulo a otro o cuando están esperando en la cola. Para cada módulo Proceso
(Process) que colocamos, Arena automáticamente añadió una cola de animación, que muestra las
148 Capítulo 4
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.
4.3.1 Cambio de las colas de animación

Si observó la animación de cerca, se pudo dar cuenta que nunca hubo más de 14 entidades
visibles en cualquiera de las colas, aun cuando nuestras variables indicaran otra cosa. Esto es
porque Arena restringe el número de entidades animadas que se muestran en cualquier cola
al número que se ajuste al espacio dibujado para la cola de animación. La simulación puede
7JTUB
3FXPSL1SPDFTT2VFVF
7JTUB
3FXPSL1SPDFTT2VFVF
7JTUB 3FXPSL1SPDFTT2VFVF
7JTUB
3FXPSL1SPDFTT2VFVF
Figura 4-9. Formas alternas para mostrar una cola
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
Pantalla 4-23. Cuadro de diálogo Queue (Cola)

150 Capítulo 4
3FXPSL1SPDFTT2VFVF
Figura 4-10. La cola de Retrabajo con 40 puntos
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).
4.3.2 Cambio de las imágenes de entidad

Ahora enfoquemos nuestra atención en las entidades de animación. En nuestra animación actual,
arbitrariamente seleccionamos bolas azules y rojas para los dos tipos de entidades. Supongamos
que queremos que nuestras entidades sean similares a las bolas pero que tengan escrita la letra “A”
o “B” dentro de cada una. El lector crea imágenes nuevas en la ventana Localización de imagen
de la entidad (Entitiy Picture Placement), como se muestra en la figura 4-11, que se abre usando
Edit > Entity Pictures (Editar > Imágenes de la entidad ). El lado izquierdo de esta ventana con-
tiene las imágenes de entidad actualmente disponibles en su modelo, mostradas como una lista de
botones con imágenes y nombres asociados a ellas. El lado derecho de esta ventana se usa para
entrar a bibliotecas de imagen, que son simplemente colecciones de imágenes almacenadas en un
archivo. Arena proporciona varias de estas bibliotecas con una selección inicial de íconos; ábralos
y examínelos antes de animar su siguiente modelo (sus nombres de archivo terminan con .plb).
Hay varias formas de añadir una imagen nueva a su animación. Puede usar el botón Add
(Añadir) (a la izquierda) para dibujar una nueva imagen para la lista actual, o puede usar el
botón Copy (Copiar) (a la izquierda) para copiar una imagen existente en la lista actual. Si usted
usa la función Add, su nueva entrada no tendrá una imagen o un nombre asociado con ella hasta
que la dibuje y le dé un nombre en el campo Value (Valor) de la lista. Si usa la función Copy, la
nueva imagen y nombre serán los mismos que los de la imagen seleccionada cuando la copió.
Para añadir una imagen de una biblioteca a su lista de imágenes de entidad actual, resalte
la imagen que quiere cambiar a la izquierda, destaque la nueva selección de una biblioteca a la
derecha, y haga clic en el botón de la flecha izquierda ( ) para copiarla en su lista de imágenes.
También puede desarrollar y mantener sus propias bibliotecas de imágenes al escoger el botón
Figura 4-11. Ventana de Localización de la imagen de la entidad (Entity Picture Placement)
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
Figura 4-12. Imágenes de entidad finales

152 Capítulo 4
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.
4.3.3 Agregar imágenes de recurso

Ahora que hemos completado nuestras colas y entidades animadas, añadamos imágenes de re-
curso a nuestra animación. Se añade una imagen de recurso al hacer clic en el botón Recurso
(Resource) ( ) que se encuentra en la barra de herramientas Animar (Animate). Esto abrirá la
ventana Resource Picture Placement, que se ve muy similar a la ventana Entity Picture Placement.
Hay muy poca diferencia entre una imagen de entidad y una de recurso más allá que la forma en
que nos referimos a ellas. Las entidades adquieren imágenes al asignar un nombre de imagen en
cualquier parte del modelo. Los recursos adquieren imágenes dependiendo de su estado. En la sec-
ción 4.2.1 analizamos los cuatro estados automáticos del recurso (Idle [Ocioso], Busy [Ocupado],
Falied [Descompuesto] e Inactive [Inactivo]). Cuando el lector abre una ventana Resource Picture
Placement, debería notar que hay una imagen predeterminada para cada uno de los cuatro estados
predeterminados. Sin embargo se pueden cambiar los dibujos usados para representar el recurso
en sus diversos estados, de la misma manera que se cambiaron nuestras imágenes de entidad.
Primero hay que identificar qué imagen de recurso estamos creando. Para ello se usa la
lista de sugerencias en el cuadro Identificador (Identifier) y se selecciona uno de nuestros re-
cursos (por ejemplo, Prep A). Ahora reemplacemos estas imágenes como lo hicimos para las
de entidad. Haga doble clic en la imagen Idle (Ocioso) para abrir la ventana Picture Editor.
Use el color de fondo para el relleno, haga que el ancho de línea sea de 3 puntos (de la barra
de herramientas Draw [Dibujar]), y cámbiele el color. Note que el cuadro debe resaltarse para
hacer estos cambios. El círculo pequeño con la cruz es el punto de referencia para el recurso,
indicando cómo se alinean otros objetos (como imágenes de entidad) a su imagen; arrástrelo
hacia el centro de su caja. Acepte este ícono (al cerrar la ventana Picture Editor) y regrese a la
ventana Resource Picture Placement. Ahora desarrollemos nuestra propia biblioteca de imá-
genes. Al escoger el botón New (Nuevo) de la ventana Resource Picture Placement, se abre una
nueva biblioteca de archivos vacía. Ahora seleccione su ícono creado recientemente, haga clic
en Add (Añadir) debajo del área de biblioteca y después haga clic en el botón de flecha hacia la
derecha. Haga clic en el botón Guardar (Save) para nombrar y guardar su nueva biblioteca de
archivo (por ejemplo, Book.plb).
Ahora usaremos esta imagen para crear el resto de nuestras imágenes de recurso. Resalte la
imagen Busy a la izquierda y la nueva biblioteca de imagen a la derecha y use el botón de la flecha
izquierda para hacer que su imagen de ocupado se vea como su imagen de ocioso. Cuando la
animación se encuentra ejecutándose, la imagen de entidad se colocará en el centro de esta caja,
así que sabremos que se halla ocupada. Sin embargo, el lector necesita marcar la Seize Area (Área
tomada) en la parte inferior de la ventana para que esto suceda. Ahora copie la misma biblioteca
de imágenes a los estados inactivo y descompuesto. Abra cada una de estas imágenes y llene la
caja con un color que denote si el recurso se encuentra en el estado descompuesto o inactivo (por
ejemplo, rojo para descompuesto y gris para inactivo). Ahora copie estas dos nuevas imágenes
Figura 4-13. Imágenes de recurso
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”.
4.3.4 Agregar variables y gráficas

La última cosa que haremos es añadir variables adicionales y una gráfica a nuestra animación.
Las variables de interés son el número de partes en cada proceso (en servicio, además de estar
en la cola) y el número de partes completas (vía cada una de las tres posibilidades de salida).
Se pueden sólo copiar y pegar las variables que vienen con los módulos de diagrama de flujo.
Primero copie y pegue las cuatro variables anexas a nuestros módulos de proceso; colóquelas
justo debajo de la imagen de recurso que acabamos de crear. Luego cambie su tamaño al resal-
tar la variable y arrastrar una de las asas para hacer más grande o más pequeña la imagen de la
variable. También puede volver a dar formato, cambiar el tipo de letra, el color, etc., haciendo
doble clic en la variable para abrir la ventana Variable que se muestra en la figura 4-14. Después
repetimos este proceso para las tres variables que vienen con nuestros módulos Dispose (Dis-
Figura 4-14. Ventana Variable

Plot Expression (Expresión de gráfico)

Expression (Expresión) NQ (Rework Process.Queue)
Maximum (Máximo) 40
Plot (Graficar)
Time Range (Rango de tiempo) 9600
Refresh-None (Actualizar-Ninguno) select (seleccionar)
X-Labels (Etiquetas X) check (revisar)
Use Title (Utilizar título) check (revisar)
Title Text (Texto del título) Number in Rework Queue (Número en cola de
reproceso)
Pantalla 4-24. La ventana Graficar (Plot)
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
Number in Rework Queue

Model 4.4
The Enhaced Electronic Assembly and Test System witn Enhaced Animation
" " " # #

Rework
" "
"
Prep A #
3 4 Scrapped
" " " " " " "
" 9
8 Sealer
#
1 2 2 Salvaged
" # " # " # " # " "
11
Prep B 1 6 6 7 Shipped
#
# # # # # # # # # # #
12
Figura 4-15. La animación en el tiempo 5469.0640 minutos: modelo 4-3
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.
4.4.1 Algunos conceptos nuevos de Arena: Estaciones y Transferencias

Con la finalidad de modelar los tiempos de transferencia de dos minutos para mostrar el movi-
miento de las partes, necesitamos entender dos nuevos conceptos de Arena: Estaciones (Statio-
ns) y Transferencia de estación (Station Tranfers). Arena aborda la modelación de sistemas físi-
cos al identificar ubicaciones llamadas Estaciones (Stations). Se puede pensar en las Estaciones
(Stations) como un lugar en donde ocurren algunos procesos. En nuestro ejemplo, las estacio
nes representarán los lugares para las llegadas de las partes, las cuatro celdas de fabricación y
las salidas de las partes. A cada estación se le asigna un nombre único. En el modelo, las estacio-
nes también aparecen como puntos de entrada a secciones de la lógica del modelo, al trabajar
junto con nuestro otro tema nuevo, la Transferencia de estaciones (Stations Transfers).
La Transferencia de estaciones (Stations Transfers) nos permite enviar una entidad de una
estación a otra sin una conexión directa. Arena proporciona diferentes tipos de transferencia
de estaciones que permiten tiempos de transferencia positivos, movimiento obligado al usar
mecanismos de manejo de material y rutas flexibles que dependen del tipo de entidad. La trans-
ferencia de estaciones que usaremos aquí se llama Ruta (Route) y permite el movimiento de
entidades de una estación a otra. Las Rutas asumen que se requiere tiempo para el movimiento
entre estaciones, pero que no se incurre en un retraso adicional debido a otras obligaciones, ta-
les como pasillos obstruidos o la no disponibilidad de equipo de manejo de material. El tiempo
de ruta se puede expresar como una constante, una muestra de una distribución o, para esta
cuestión, cualquier expresión válida.
A menudo pensamos en las estaciones como representaciones de una ubicación física en el
sistema; sin embargo, no existe un requisito estricto de que esto sea así y, de hecho, se pueden
usar las estaciones de forma eficaz para que sirvan a otros muchos objetivos de modelación.
Alejándonos por un momento de su uso pretendido en representación de un sistema, examine-
mos lo que sucede en Arena cuando una entidad se transfiere (esto es, se rutea) a una estación.
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 Estación de Ruta para

Llega la
A Sellador y llegada de prepara-
Parte A
Tiempo de la Parte A ción A
llegada
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
Figura 4-16. Los módulos lógicos de la llegada de partes
de la entidad finaliza su movimiento de animación en la ruta y sale del calendario de eventos

para continuar a través de la lógica del modelo, lo que da como resultado un desplegado de la
animación que es representativo de la lógica del modelo en cualquier punto del tiempo.
4.4.2 Añadir la lógica de ruta

Puesto que la adición de estaciones y transferencias afecta no sólo el modelo, sino también
a la animación, comencemos con nuestro último modelo (modelo 4-2). Ábralo y use Archivo
> Guardar Como (File > Save As) para guardarlo como Model 04-04.doe. Comencemos
con las llegadas de las partes. Borre las conexiones entre los dos módulos Asignar (Assign) y
los módulos Proceso (Process) de Part A Prep y Part B Prep. Ahora mueva los dos pares de
módulos Crear/Asignar (Create/Assign) a la izquierda para permitir espacio para los módulos
adicionales que añadiremos a nuestra lógica de ruta. Para tener una vista previa de hacia dónde
nos dirigimos aquí, nuestra modificación final a esta sección de nuestro modelo, con los nuevos
módulos, se indica en la figura 4-16.
Los módulos Crear (Create) y Asignar (Assign) existentes para las llegadas de la Parte A y
la Parte B permanecen igual al modelo original. Con la finalidad de añadir nuestras estaciones
y transferencias, primero necesitamos definir la estación en donde reside la entidad actualmen-
te y después enrutar la entidad a esa estación de destino. Comencemos con la Parte A. Colocamos
el módulo Estación (Station) (del Panel avanzado de transferencia [Advanced Transfer panel], que
tiene que adjuntar a su modelo) para definir la ubicación de la Parte A, como se ve en la panta-
lla 4-25. Introdujimos un Nombre (Name) (Estación de llegada de la Parte A [Part
A Arrival Station]), predeterminamos el Tipo de estación (Station Type) en Estación
(Station) y definimos nuestra primera estación (Estación de la Parte A [Part A Sta-
tion]). Este módulo define la nueva estación (o localización) y asigna la ubicación a la parte que
llega. Note que el cuadro Nombre (Name) en el módulo Estación (Station) simplemente propor-
ciona el texto a aparecer en la ventana del modelo y no define el nombre de la estación. El cuadro
Nombre de la estación (Station Name) define el nombre de la estación real que se va a usar en la
lógica del modelo: Estación de la Parte A (Part A Station).
Después añadiremos el módulo Ruta (Route) (del Panel avanzado de transferencia [Advan-
ced Transfer panel]), que enviará con un tiempo de transferencia de dos minutos a la parte que
llega al área A de preparación. Proporcionaremos un nombre del módulo, introduciremos un
Tiempo de ruta (Route Time) de 2, en unidades de Minutos (Minutes), predeterminaremos
el Tipo de destino (Destination Type) (Estación [Station]) e introduciremos el Nombre
de la estación (Station Name) como Estación A de preparación (Prep A Station),
como se indica en la pantalla 4-26. Esto hará que cualquier llegada proveniente de la Parte A
sea enviada a Estación A de preparación (Prep A Station) próxima a establecerse (aunque sólo
definimos su nombre aquí).
Name (Nombre) Part A Arrival Station (Estación de llegada

de la Parte A)
Station Name (Nombre de la Part A Station (Estación de la Parte A)
estación)
Pantalla 4-25. El módulo Estación (Station)
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
Name (Nombre) Route to Prep A (Ruta hacia Prep A)

Route Time (Tiempo de la ruta) 2
Station Name (Nombre de la estación) Prep A Station (Estación Prep A)
Pantalla 4-26. El módulo Ruta (Route)

160 Capítulo 4
Estación de lle- Proceso de

gada de Prep A Prep A (Prep
(Prep A Arrival A Process)
Station)
Ruta al sellado
(Route to Sealer)
Estación de
Proceso de
llegada de Prep
Prep B (Prep
B (Prep B Arrival
B Process)
Station)
Figura 4-17. Los módulos lógicos de las áreas Prep (Casi...)
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.
Estación de Proceso de Inspección de Ruta a retrabajo

llegada de sellado sellado (Sealer sellado fallida
Verdadero (Route to Rework)
(Sealer Arrival Process) (Failed Sealer In-
Station) spection)
Falso Ruta a partes

enviadas (Route
to Shipped Parts)
Estación de lle- Proceso de Inspección de Ruta a partes des-

gada de retrabajo Retrabajo (Rework retrabajo fallida cartadas (Route to
(Rework Arrival Process) (Failed Rework Verdadero Scrapped Parts)
Station) Inspection)
Falso Ruta a partes recu-

peradas (Route de
Salvaged Parts)
Figura 4-18. Los módulos lógicos de las áreas Sellado (Sealer) y Retrabajo (Rework)
Estación de llegada
de partes descartadas Registro de partes
Descartadas
(Scrapped Parts Arrival descartadas (Record
(Scrapped)
Station) Scrapped Parts)
de partes recuperadas Registro de partes Recuperadas
(Salvaged Parts Arrival recuperadas (Record (Salvaged)
Station) Salvaged Parts)
de partes enviadas Registro de partes Enviadas
(Shipped Parts Arrival enviadas (Record (Shipped)
Station) Shipped Parts)
Figura 4-19. Los módulos lógicos Descartadas (Scrapped), Recuperadas

(Salvaged) y Enviadas (Shipped)
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.
Identifier (Identificador) Part A Station (Estación de la Parte A)
Pantalla 4-27. El cuado de diálogo Estación (Station)

162 Capítulo 4
Pantalla 4-28. El cuadro de diálogo Ruta (Route)
4.4.3 Alterar la animación

En el proceso de modificación de la animación movimos muchos de los objetos existentes. Si
quiere que su animación se vea como la nuestra, primero eche un vistazo a la figura 4-20. (Por
supuesto, siempre podría sólo abrir el modelo 04-04.doe.)
Ahora le mostraremos cómo agregar estaciones y rutas a su animación. Comencemos con
añadir las primeras marcas de estación de animación. Haga clic en el botón Estación (Station)
( ) que se encuentra en la barra de herramientas Animar transferencia (Animate Transfer)
para abrir el cuadro de diálogo Estación (Station) que se indica en la pantalla 4-27 (fíjese en el
pequeño símbolo de marca de estación afuera a su izquierda). Si no tiene abierta la barra de he-
rramientas Animar transferencia, puede usar Ver > Barras de herramientas (View > Toolbars)
(o haga clic en el botón derecho en cualquier área de la barra de herramientas) para elegir des-
plegarla. Ahora use la lista de sugerencias para seleccionar, de las estaciones ya definidas, nues-
tra primera estación, Part A Station. Cuando cierre este cuadro de diálogo, su cursor debe
haber cambiado a una cruz de líneas delgadas con un símbolo de marca de estación adjunto.
Coloque este nuevo cursor a la izquierda de la cola Prep A y haga clic para añadir la marca de
estación. De forma alternada, no necesita cerrar el cuadro de diálogo, sino sólo mover el cursor
(que será una cruz de líneas delgadas con un símbolo de marca de estación adjunto) a donde se
encuentre la marca de estación y hacer clic (el cuadro de diálogo se cerrará solo).
Repita el mismo conjunto de pasos para colocar la marca Prep A Station justo encima
de la cola Prep A. Ahora que tenemos nuestras primeras dos estaciones colocadas, añadamos
el camino de ruta. Haga clic en el botón Ruta (Route) ( ) en la barra de herramientas Animar
transferencia. Eso abrirá el cuadro de diálogo Ruta (Route) que se indica en la pantalla 4-28.
Para nuestra animación, simplemente aceptamos los valores predeterminados, aun ignorando
los nombres de estación “Desde” (“From”) y “Hacia” (“To”) predeterminados (e incorrectos).
Después de cerrar el cuadro de diálogo Ruta (o aun si no lo cierra), el cursor cambia a una cruz
de líneas delgadas. Colóquela dentro de la marca de estación (Part A Station) al inicio de
un camino y haga clic; ello comenzará el camino de ruta. Mueva el puntero y construya el resto
del camino al hacer clic en donde desee las “esquinas”, de la misma manera en la que se dibuja
una polilínea. El camino de ruta terminará de forma automática cuando haga clic dentro de la
marca de estación (Prep A Station).
El proceso de dos pasos anterior (primero colocar las marcas de estación y después colocar
las animaciones de ruta) podría reemplazarse por uno de un solo paso que involucre únicamen-
te la herramienta de animación Ruta. Intente haciendo clic en la barra de herramientas, después
otro clic en la cruz de líneas delgadas en la vista del diagrama de flujo de su modelo, haga otros
pocos clics más para las esquinas y, finalmente, doble clic. Notará que obtuvo una marca de es-
Figura 4-20. La animación completa para el modelo 4-4
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.
4.5 Encontrar y corregir errores

Si desarrolla suficientes modelos, en particular grandes, antes o después encontrará que su mo-
delo o no se ejecutará o lo hará de forma incorrecta. Nos sucede a todos. Si está construyendo
un modelo y cometió un error que Arena puede detectar e impide que el modelo corra, Arena
mismo intentará ayudarlo a encontrar ese error fácil y rápido. Sospechamos que esto ya le su-
cedió al lector, así que considérese afortunado si éste no es su caso.
Los errores típicos que impiden que un modelo corra pueden incluir: variables no defini-
das, atributos, recursos, módulos desconectados, uso duplicado de nombres de módulos, mal
deletreado de nombres (o, peor aún, ortografía inconsistente incluso cuando es o no correcta),
etc. Aunque Arena intenta impedir que el usuario cometa estos tipos de errores, no puede darle
una flexibilidad de modelación máxima sin la posibilidad de que ocurra un error ocasional.
Arena encontrará la mayoría de estos errores cuando el usuario intente revisar o ejecutar un
modelo creado completamente nuevo. Para ilustrar esta capacidad, insertemos intencionalmen-
te algunos errores en el modelo que acabamos de desarrollar, el 4-4. A menos que el lector sea
en verdad muy diestro, le sugerimos que guarde su modelo con un nombre diferente antes de
comenzar a hacer estos cambios.
Introduciremos dos errores. Primero, borre el conector entre el primer módulo Crear (Crea-
te), Part A Arrive y el siguiente módulo Asignar. Después, abra el cuadro de diálogo para
el módulo Asignar, Assign Part B Sealer and Arrive Time y cambie el Nuevo valor
(New Value) de la segunda tarea de TNOW a TNO. Estos dos errores son típicos de los tipos de
errores que los nuevos modeladores (y a veces los experimentados) cometen. Después de hacer
tales dos cambios, use la opción Ejecutar > Revisar (Run > Check) o el botón Revisar (Check)
( ) en la barra de herramientas Interacción de ejecución (Run Interaction) para revisar su mo-
delo. Una ventana Avisos de error (Errors/Warnings) debería abrirse con el mensaje
ERROR:
Unconected exit point (Punto de salida desconectado)
Este mensaje le dice que existe un conector que no aparece (el que acabamos de borrar). Aho-
ra busque los botones Encontrar (Find) y Editar (Edit) en la parte inferior de la ventana. Si hace
clic en el botón Encontrar (Find), Arena lo llevará a y destacará el módulo ofendido. Así, Arena
intenta ayudarlo a encontrar y corregir el error descubierto. Entonces, haga clic en Find y añada el
conector que borramos.
Habiendo solucionado este problema, una nueva revisión del modelo expondrá el segundo
error:
ERROR:
A linker error was detected at the following block (Se detectó un
error de conexión en el siguiente bloque):
* 3 0$ ASSIGN (ASIGNAR):
Sealer Time=TRIA (1,3,4):
Arrive Time=TNO:
NEXT(14$);
Undefined symbol (Símbolo sin definir): TNO
Possible cause: A variable or other symbol was used without first
being defined (Causa posible: se usó una variable u
otro símbolo sin definirse primero).
Possible cause: A statistic was animated, but statistics
collection was turned off (Causa posible: se
166 Capítulo 4
Figura 4-22. El cuadro de diálogo Capas (Layers)
animó una estadística, pero la recopilación de

estadísticas se cerró).
To find the problem, search for the above symbol name using Edit-Find
from the menu (Para encontrar el problema, busque el símbolo de arri-
ba al usar Editar-Encontrar del menú).
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).
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
Break On (Pausa en módulo) Time (Tiempo)

Time (Tiempo) 29
Units (Unidades) Base Time Units (Unidades de tiempo base)
Pantalla 4-29. La opción Puntos de pausa (Breakpoints)
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
Figura 4-23. La ventana Puntos de pausa (Breakpoints)

Figura 4-24. La ventana Calendario (Calendar)
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
Figura 4-25. La ventana Colas (Queues)
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.
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-
Figura 4-26. La ventana Comando de control de ejecución (Run Control Command)

172 Capítulo 4
do (Insert Command ) ( ) para introducir el comando MOSTRAR (SHOW) en la ventana.

Ahora teclee MR (Sealer) y presione la tecla Enter. La respuesta será:
MR(Sealer) = 1
Esto le dice que el recurso Sellado actualmente tiene la capacidad de uno. Ahora repita el pro-
ceso para NR (Sealer). La respuesta será:
NR(Sealer) = 1
Esto le dice que una unidad del recurso Sellado está ocupada, lo que debería ser obvio en la
animación puesto que muestra al avión estacionado en ese recurso. Ahora aumentemos la capa-
cidad del recurso Sellado a 3. Use el comando ASIGNAR para introducir lo siguiente:
ASSIGN MR(Sealer) = 3
y presione la tecla Enter. El recurso Sellado ahora tiene una capacidad de 3. Ahora presione Ir
(Go) y observe la animación para ver la cola de sellado disminuir hasta cero en 20 minutos de
tiempo de simulación.
Por último, durante una ejecución, puede ver los reportes en el estado del modelo en cualquier
momento durante una ejecución. Simplemente vaya a la barra de proyectos y haga clic en el pa-
nel Reportes (Reports). Puede solicitar un reporte cuando el modelo esté ejecutándose o cuando
el modelo se encuentre en modo Pausa (Pause). Justo como la ventana Observar (Watch), puede
tener una ejecución de animación y de forma periódica requerir un reporte y nunca detener la
ejecución. Sólo recuerde cerrar las ventanas del reporte cuando haya terminado de verlas.
Aunque no use el Controlador de ejecución (Run Controller), las opciones disponibles en
la barra de herramientas Ejecutar interacción (Run Interaction) proporcionan la capacidad
de detectar errores lógicos del modelo sin necesidad de convertirse en un experto en SIMAN.
Ya que entienda cómo funcionan, le recomendamos que tome un modelo animado sencillo y
practique el uso de estas herramientas. Podría pasar tiempo hasta necesitarlas, pero entonces
no estaría sólo intentando encontrar un error, ¡sino que también tratando de aprender varias
herramientas nuevas!
4.6 Análisis de entradas: especificación de parámetros y distribuciones del modelo

Como sin duda ha notado, existen muchos detalles que debe especificar por completo con la
finalidad de definir un modelo de simulación que funcione. Probablemente piense primero en
los aspectos lógicos del modelo, como qué entidades y recursos son, cómo entran las entidades
y quizá cómo dejan el modelo, los recursos que se requieren, los caminos que siguen, etc. Estas
clases de actividades podrían llamarse modelación estructural puesto que preparan la lógica
fundamental de cómo quiere que se vea y qué haga su modelo.
También debe haber notado que existen otros elementos a la hora de especificar un modelo
que son más numéricos o matemáticos por naturaleza (y quizá por lo tanto más mundanos).
Por ejemplo, al especificar el modelo 4-2, declaramos que los tiempos entre llegadas para la
Parte A estaban distribuidos de forma exponencial con una media de 5 minutos, tiempos de
proceso total para Part B Prep seguidos por una distribución triangular (3, 5, 10), los tiempos
“de funcionamiento” para el sellador eran dibujos de una distribución exponencial (120) y con-
figuramos un calendario para el número de operadores de retrabajo en tiempos diferentes. Tam-
bién debe hacer estos tipos de especificaciones, que podrían llamarse modelación cuantitativa,
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.
4.6.1 Entradas deterministas contra aleatorias

Un tema fundamental en la modelación cuantitativa es si va a modelar una cantidad de entra-
das como una cantidad determinista (no aleatoria), o si va a modelarla como variable aleatoria
siguiendo alguna distribución de probabilidad. A veces está claro que algo debiera ser determi-
nista, como el número de operadores de revisión, aunque puede ser que quiera variar los valores
de ejecución a ejecución para ver qué efecto tienen en el desempeño.
Pero a veces no hay tal claridad y sólo podemos ofrecerle el consejo (obvio) de que debe ha-
cer lo que parezca más realista y válido posible. En la sección 4.6.2 hablaremos un poco acerca
del uso del modelo de lo que se conoce como análisis sensitivo para medir qué tan importante
es una entrada en particular para su resultado, lo que podría indicar qué tanto necesita preocu-
parse por si debe modelarlo como determinista o aleatorio.
Puede verse tentado a desestimar la aleatoriedad de sus entradas, ya que esto parece ser
más sencillo y tiene la ventaja de que los resultados del modelo no son aleatorios. Sin embargo,
esto puede ser bastante peligroso desde el punto de vista de la validez del modelo, porque con
frecuencia es la aleatoriedad en sí misma la que conduce a un comportamiento importante del
sistema que con certeza usted debería captar en su modelo de simulación. Por ejemplo, en una
cola sencilla de un solo servidor, podríamos suponer que todos los tiempos entre llegadas son
exactamente de 1 minuto y que todos los tiempos de proceso son exactamente de 59 segundos;
ambas figuras podrían estar de acuerdo con los valores promedio de los datos observados en
llegadas y servicio. Si el modelo comienza vacío con el servidor desocupado y la primera llegada
es en el tiempo 0, entonces nunca habrá una cola, puesto que cada cliente terminará el servicio
y se irá 1 segundo antes de que llegue el siguiente cliente. Sin embargo, si la realidad es que los
tiempos entre llegadas y de servicio son variables aleatorias exponenciales con medias de 1 mi-
nuto y 59 segundos respectivamente (más que constantes en esos valores), obtiene una historia
muy diferente en términos de longitud de cola (adelante y construya un pequeño modelo de
174 Capítulo 4
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).
4.6.2 Recopilación de datos

Uno de los pasos bastante claros en la planeación de su proyecto de simulación debería ser
identificar qué datos necesita para apoyar el modelo. Encontrar los datos y prepararlos para
usarlos en su modelo puede requerir mucho tiempo, ser costoso y con frecuencia, frustrante; y
la disponibilidad y calidad de los datos pueden influir en el enfoque que tome de la modelación
y en el nivel de detalle que capte en el modelo.
Existen muchos tipos de datos que puede necesitar recopilar. La mayoría de los modelos
requieren una buena dosis de información que incluya demoras en el tiempo: tiempos entre
llegadas, tiempos de proceso, tiempos de recorrido, programas de trabajo del operador, etc. En
muchos casos también necesitará estimar probabilidades, tales como el porcentaje producido
de una operación, las proporciones de cada tipo de cliente o la probabilidad de que un cliente
tenga un teléfono de tonos. Si usted modela un sistema en donde el movimiento físico de las en-
tidades entre estaciones será representado en el modelo, también se requerirán los parámetros
de operación y el bosquejo físico del sistema de manejo de material.
Puede acudir a muchas fuentes para buscar los datos, desde bases de datos electrónicas
hasta entrevistas a personas que trabajen en el sistema a estudiar. Parece que cuando se trata
de encontrar datos para un estudio de simulación, tal búsqueda resulta ser “un banquete o una
hambruna”, cada uno presentando sus propios retos únicos.
Si el sistema que modela existe (o es similar a un sistema real en algún otro lado), puede
pensar que su trabajo es más fácil, puesto que debería haber muchos datos disponibles. Sin em-
bargo, lo que probablemente encontrará es que los datos que obtenga no serán los que necesite.
Por ejemplo, es común recopilar datos de tiempo de proceso en máquinas (esto es, un espacio de
tiempo de las partes desde su llegada a la máquina hasta que termina el proceso), que a primera
vista podría verse como una buena fuente de tiempos de proceso en el modelo de simulación.
Pero, si los datos observados de tiempos de proceso incluyen el tiempo en la cola o los tiempos
de falla de la máquina, pueden no ajustarse en la lógica del modelo, lo que de forma explícita
modela la lógica de la cola y las fallas de la máquina por separado del tiempo de fabricación.
Por otra parte, si está por modelar un nuevo sistema de marca o una modificación significati-
va de uno ya existente, se encontrará a sí mismo en el otro lado del espectro, con pocos o ningún
dato. En este caso, su modelo se hallará a merced de aproximaciones desiguales de diseñadores,
vendedores de equipo, etc. Tendremos algunas sugerencias (en oposición a soluciones) al res-
pecto en la sección 4.6.5.
En cualquier caso, conforme decida qué y cuántos datos recopilar, es importante mantener
en mente las siguientes pistas de ayuda:
< Análisis de sensibilidad: Un aspecto ignorado a menudo al desempeñar estudios de si-
mulación es desarrollar un entendimiento de qué es importante y qué no. El análisis de
sensibilidad puede usarse incluso muy temprano en un proyecto, para evaluar el impacto
de los cambios de los datos en los resultados del modelo. Si no puede obtener de forma
fácil datos buenos acerca de algún aspecto de su sistema, ejecute el modelo con un rango
de valores para ver si el desempeño del sistema cambia de forma significativa. Si no es

así, no necesitará invertir en recopilar datos y puede seguir teniendo confianza en sus
conclusiones. Si es así, entonces tendrá que encontrar una forma de obtener datos con-
fiables o sus resultados y recomendaciones serán toscos.
< Hacer corresponder el detalle del modelo con la calidad de los datos: Un beneficio de
entender pronto la calidad de sus datos de entrada es que esto puede ayudarle a decidir
qué tanto detalle incorporar en la lógica del modelo. Por lo general, no tiene ningún caso
modelar con cuidado la lógica detallada de una parte de su sistema para la que tiene
valores no confiables de los datos asociados, a menos que piense que, en un momento
posterior, podrá obtener datos mejores.
< Costo: Debido a que puede ser caro recopilar y preparar datos para usarlos en un mode-
lo, puede decidir usar estimados peores para algunos datos. Al hacer esta evaluación, el
análisis de sensibilidad puede ser útil de tal manera que tenga una idea del valor de los
datos que afecta sus recomendaciones.
< Basura que entra, basura que sale: Recuerde que los resultados y recomendaciones que
presente de su estudio de simulación son sólo tan confiables como el modelo y sus en-
tradas. Si no puede meter datos adecuados concernientes a elementos críticos del mo-
delo, no podrá dar un gran voto de confianza en la confiabilidad de sus conclusiones.
Esto no significa que desempeñar un estudio de simulación no tenga valor si no se pue-
den obtener “buenos” datos. Se puede seguir desarrollando tremendos entendimientos
en la operación de un sistema complejo, las interacciones entre sus elementos, y conside-
rando algún nivel de predicción de cómo se desempeñará. Pero tenga cuidado de articu-
lar la confianza de sus predicciones con base en la calidad de los datos de entrada.
Un consejo final que debemos ofrecer es que la recopilación de datos (y algunos de sus análi-
sis) son identificados a menudo como la parte más difícil, costosa, tardada y tediosa del estudio
de simulación. Esto se debe en parte a varios problemas que se pueden encontrar al recopilar
y analizar datos, y en parte también a los hechos innegables de que no es tan divertido como
construir el modelo lógico y jugar con él. Así que, manténgase de buen ánimo en esta actividad
y siga recordándose que es una parte importante (si no placentera o emocionante) de por qué
está utilizando la simulación.
4.6.3 Uso de datos

Si se tienen datos históricos (por ejemplo, un registro de interrupciones y tiempos de reparación
para una máquina), o si se sabe qué parte del sistema trabajará (por ejemplo, programas de ope-
radores planeados), hay que seguir enfrentando decisiones que conciernen cómo incorporar los
datos en el modelo. La elección fundamental está en si se pueden usar los datos directamente
o si hay que ajustar una distribución de probabilidad a los datos existentes. La decisión de qué
acercamiento usar se puede orientar con base tanto en temas teóricos como en consideraciones
prácticas.
Desde un punto de vista teórico, sus datos recopilados representan lo que sucedió en el
pasado, que puede ser o no una predicción imparcial de lo que puede acontecer en el futuro.
Si las condiciones que rodean la generación de estos datos históricos no aplican más (o si
cambiaron durante el tiempo en que se registraron tales datos), entonces los datos históricos
pueden ser parciales o simplemente se olvidan de algunos aspectos importantes del proceso.
Por ejemplo, si los datos históricos son de una base de datos de órdenes de productos coloca-
dos en los últimos 12 meses, pero hace cuatro que se introdujo una nueva opción de produc-
176 Capítulo 4
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.
4.6.4 Ajuste de distribuciones de entradas vía el analizador

de datos de entrada (Input Analyzer)
Si decide incorporar sus valores de datos existentes al ajustarlos a una distribución de pro-
babilidad, puede seleccionar la distribución por sí mismo y usar el Analizador de datos de
entrada (Input Analyzer) para proporcionar estimados numéricos de los parámetros apro-
piados, o puede ajustar a los datos un número de distribuciones y seleccionar el más apropia-
do. En cualquier caso, el Analizador de datos de entrada lo provee con estimados de valores
de parámetros (con base en los datos que proporcionó) y una expresión ya hecha y lista que
simplemente puede copiar y pegar en su modelo.
Cuando el Analizador de datos de entrada ajusta una distribución a sus datos, éste estima
los parámetros de distribución (incluyendo cualquier cambio o compensación que se requiera
para formular una expresión válida) y calcula un número de medidas de qué tan bien se ajusta
la distribución a sus datos. Se puede usar esta información para seleccionar qué distribución se
quiere emplear en el modelo, lo que analizamos antes.
Puede pensarse que las distribuciones de probabilidad caen dentro de dos tipos: teóricas y
empíricas. Las distribuciones teóricas, como la exponencial y gamma, generan muestras con
base en la formulación matemática. Las distribuciones empíricas simplemente dividen los datos
reales en grupos y calculan la proporción de valores en cada grupo, posiblemente interpolando
entre puntos para conseguir mayor precisión.
Cada tipo de distribución se subdivide en continua y discreta. Las distribuciones teóricas
continuas que Arena usa en su modelo son la exponencial, triangular y de Weibull menciona-
das anteriormente, así como la beta, Erlang, gamma, lognormal, uniforme y normal. Estas
distribuciones se denominan distribuciones continuas porque pueden regresar cualquier can-
tidad de valor real (dentro de un rango para los tipos con límites). Por lo general se usan para
representar duraciones de tiempo en un modelo de simulación. La distribución de Poisson es
una distribución discreta; sólo puede regresar cantidades de valores enteros. A menudo se usa
para describir el número de eventos que ocurren en un intervalo de tiempo o la distribución

de variar aleatoriamente el tamaño de los lotes.
También puede usar una o dos distribuciones empíricas: las distribuciones de probabilidad
discreta y continua. Cada una se define al usar una serie de pares probabilidad/valor que re-
presentan un histograma de los valores de datos que pueden regresar. La distribución empírica
discreta regresa sólo los valores de datos de ellos mismos, al usar las probabilidades de escoger
de entre los valores individuales. Se usa comúnmente para tipos de entidad probabilísticamen-
te asignados. La distribución empírica continua usa las probabilidades y valores para regresar
una cantidad realmente evaluada. Se puede usar en lugar de una distribución teórica en casos
donde los datos tengan características inusuales o donde ninguna de las distribuciones teóricas
proporcione un buen ajuste.
El Analizador de datos de entrada puede ajustar sus datos con cualquiera de las distribucio-
nes anteriores. Sin embargo, hay que decidir si usar una distribución teórica o empírica, y des-
afortunadamente, no hay ninguna regla estándar para hacer esta elección. Por lo general, si un
histograma de sus datos (mostrado de forma automática por el Analizador de datos de entrada)
parece ser bastante uniforme o tiene una sola “cresta”, y si no posee ninguna distancia larga
donde no hay ningún valor, entonces parece que se obtiene un buen ajuste de una de las dis-
tribuciones teóricas. Sin embargo, si hay un número de valores agrupados que tengan muchas
observaciones (multimodal), o hay un número de puntos de datos que tengan un valor que sea
significativamente diferente del conjunto principal de observaciones, una distribución empírica
puede proporcionar una mejor representación de los datos; una alternativa a una distribución
empírica es dividir los datos de algún modo, lo cual describiremos al final de esta sección.
El Analizador de datos de entrada es una herramienta estándar que acompaña a Arena y
está diseñada específicamente para ajustar distribuciones para datos observados, proporcionar
estimados de sus parámetros, y medir qué tan bien se ajustan a los datos. Se requieren cuatro
pasos para usar el Analizador de datos de entrada para ajustar una distribución de probabili-
dad a sus datos para usarlos como una entrada en su modelo:
< Crear un archivo de texto que contenga los valores de los datos.
< Ajustar una o más distribuciones a los datos.
< Seleccionar qué distribución quiere usar.
< Copiar la expresión generada por el Analizador de datos de entrada en el campo apro-
piado en su modelo de Arena.
Para preparar el archivo de datos, sólo se crea un archivo de texto ASCII ordinario que con-
tenga los datos en formato libre. Se puede usar cualquier programa editor de textos, procesador
de textos u hoja de cálculo. Los valores de los datos individuales se deben separar por uno o
más “caracteres de espacio en blanco” (espacio en blanco, tabulador o línea de alimentación).
No hay otros requisitos de formato; en particular, se pueden tener tantos valores de datos en
una línea cualquiera, y el número de valores por línea puede variar de una línea a otra. Cuando
use un programa de procesador de palabras o de hoja de cálculo, asegúrese de guardar el archi-
vo en un formato “sólo texto”. Esto elimina cualquier formato de caracteres o párrafos que de
otra forma estaría incluido. Por ejemplo, la figura 4-27 muestra los contenidos de un archivo
ASCII llamado partbprp.dst (la extensión de archivo predeterminada para los archivos de
datos del Analizador de datos de entrada es .dst) que contiene observaciones en 187 tiempos
Prep de la parte B; note que los valores están separados por espacios en blanco o líneas de
alimentación, hay diferentes números de observación por línea, y no hay un orden particular o
disposición de los datos.
178 Capítulo 4
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
Figura 4-27. Lista del archivo en código ASCII partbprp.dst

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
Para ajustar
6.5 una5.4 distribución
5.9 9.3 5.4 a estos
6.5datos,
7.4 ejecute el Analizador de datos de entrada (por
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
ejemplo, seleccione Herramientas >
7.7 6.9 5.4 6.3 8.1 4.9 5.3 de
Analizador 5.0datos 5.7 4.9[Tools
4.7de entrada 5.3 >6.4
Input7.5Analyzer] de
Arena). En4.4 el Analizador
4.9 7.6 de 3.6datos
8.3 de5.6
entrada,
6.2 cargue
5.0 el archivo de datos en una ventana de
7.4 5.2 5.0 6.5 8.0 6.2 5.0 4.8 6.2 4.9
ajuste de datos
7.0 creando
7.7 4.7 una5.0
nueva
6.0ventana 7.1 >5.0
(Archivo
9.0 5.7 Nuevo5.6[File > New ] o el botón ) para
su sesión de4.9
ajuste (no
7.8 para
7.1 un
7.1 archivo
11.5 5.4
6.1 6.8 5.4 3.5 7.1 5.7 5.4
de datos),
5.2 y después adjunte su archivo de datos usando
5.7 >6.1
ya sea Archivo Archivo
4.2 de8.8 > Usar
datos7.4 5.5 existente [File >Data File > Use Existing] o el botón
5.3 5.9 5.2 6.4 4.5 5.1 5.6 6.1
). El Analizador de datos de
8.1 8.1 5.1 8.3 7.5 7.6 entrada despliega
10.9 6.5un histograma
9.0 5.9 6.8 de los9.0
datos
6.5en 6.0
la parte supe-
rior de la ventana
5.8 5.0 y un6.4
resumen
4.7 de4.5las6.2
características
5.2 7.9 de 5.5los4.9
datos7.2
en la4.9
parte
4.5inferior,
6.0 como se
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
muestra en 6.4
la figura
3.3 4-28.
7.0 7.7 6.7 7.6 7.6 7.1 5.6 5.9 4.1 7.5 7.7 5.4
Se puede4.8ajustar
5.5 el8.8
tamaño
7.0 7.8 6.3 6.1 8.4
7.2 relativo de las
6.3 10.0 ventanas
4.3 4.9 5.7al arrastrar
5.1 6.7 la barra
6.0 separadora
5.6 7.2 de filtro
al centro de la ventana. O, para ver más del resumen de los datos, puede desplazarse hacia abajo
Data Summary (Resumen de los datos)

Number of Data Points (Número de puntos de datos) = 187
Min Data Value (Valor de datos mínimo) = 3.2
Max Data Value (Valor de datos máximo) = 12.6
Sample Mean (Media de la muestra) = 6.33
Sample Std Dev (Desviación estándar de la muestra) = 1.51
Histogram Summary (Resumen del histograma)
Histogram Range (Rango del histograma) = 3 a 13
Number of Intervals (Número de intervalos) = 13
Figura 4-28. Histograma y resumen del archivo partbprp.dst

Distribution Summary (Resumen de la distribución)

Distribution: (Distribución) Triangular:Triangular)
Expression: (Expresión:) TRIA(3, 5.69, 13)
Square Error: (Error Cuadrático:) 0.24551
Chi-Square Test (Prueba de chi cuadrada)

Degrees of Freedom (Grados de libertad) = 8
Test Statistic (Estadística de prueba) = 60.6
Corresponding p-value (Correspondencia de valor p) < 0.005
Kolmogoro-Smirnov Test (Prueba de Kolmogoro-Smirnov)

Test Statistic (Estadística prueba) = 0.222
Corresponding p-value (Correspondencia de valor p) < 0.01
Figura 4-29. Ajuste de una distribución triangular al archivo partbprp.dst
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
Distribution Summary (Resumen de la distribución)

Distribution: (Distribución:)
Expression: (Expresión:) 3 + GAMM(0.775, 4.29)
Square Error: (Error cuadrático:) 0.003873
Chi-Square Test (Prueba de chi cuadrada)

Degrees of Freedom (Grados de libertad) = 4
Test Statistic (Estadística de prueba) = 4.68
Corresponding p-value (Correspondencia de valor p) = 0.337
Kolmogoro-Smirnov Test (Prueba de Kolmogoro-Smirnov)

Test Statistic (Estadística prueba) = 0.027
Corresponding p-value (Correspondencia de valor p) > 0.15
Figura 4-30. Opción ajustar todos para el archivo partbprp.dst
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.
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
Figura 4-31. Resumen Ajustar todo para el archivo pathbprp.dst
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.
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.
4.6.5 ¿Sin datos?

Tanto si le gusta como si no, hay tiempos en los que simplemente no puede obtener datos con-
fiables sobre lo que necesita para modelar la entrada. Esto puede surgir de varias situaciones,
como que (obviamente) el sistema no existe, la recopilación de datos es muy cara o perturbado-
ra, o que quizá no consigue la cooperación o autorización que necesita. En este caso, usted de-
penderá de algunas suposiciones o adivinanzas bastante arbitrarias, que dignificaremos como
datos adecuados. No pretendemos tener una gran solución ahora, pero tenemos unas cuantas
sugerencias que las personas han encontrado útiles. Sin embargo, no importa lo que haga, real-
mente puede tomar en cuenta algún tipo de análisis de sensibilidad de los resultados para estas
184 Capítulo 4
Tabla 4-2. Posibles distribuciones sin datos
Distribución Parámetros Características Ejemplo de uso

Exponencial Media Varianza alta Tiempo entre llegadas
Límite a la izquierda Tiempo para la falla de la
Sin límite a la derecha máquina
(índice de falla constante)
Triangular Mínimo, Moda, Máximo Simétrica o sin simetría Tiempos de actividad
Límite en ambos lados
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
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)
Crear Asignar atributo ¿Observa-

entidad Observación ción normal Disponer
normal positiva? Verdadero
Falso
Contar una
Observación
negativa
Figura 4-32. Modelo 4-5 para contar observaciones normales negativas

186 Capítulo 4
Tabla 4-3. Obtención de valores negativos de una distribución normal con desviación estándar σ = 1
Probabilidad exacta “Una de muchas”

Número de tiradas de que una observa- será negativa (en
Media µ Número de tiradas negativas ción será negativa promedio)
3.0 Un millón 1 409 0.001350 741
3.5 Un millón 246 0.000233 4 298
4.0 Un millón 37 0.000032 31 560
4.5 Un millón 3 0.000003 294 048
4.753672 Diez millones 7 0.000001 1 000 000
segundos completar la ejecución de diez millones de tiradas). Se seleccionó el último valor de

μ en la tabla ya que se dio una probabilidad de exactamente una en un millón de obtener una
observación negativa (el primer millón que pasó sin producir ningún negativo, pero siete en diez
millones es muy cercano a uno en un millón). Ahora respetamos y admiramos a Gauss como
un gran matemático, pero no somos tan fanáticos de usar la normal como una distribución de
entrada de simulación para representar lógicamente situaciones no negativas como tiempos
de proceso, aun cuando Arena lo permite. Para conjuntos de datos que parecen que están bien
ajustados (o incluso los más ajustados) por una distribución normal, una distribución diferente
que evite completamente los valores negativos (como la Weibull, gamma, lognormal, Erlang,
beta, o quizás empírica) probablemente se ajustará casi tan bien y no lo expondrá al riesgo de
generar ningún tipo de valor negativo desagradable.
Por último, si realmente no sabe mucho acerca del proceso pero puede adivinar cuáles serán
los valores mínimo y máximo, puede usar la distribución uniforme. Ésta regresa todos los valo-
res entre un mínimo y un máximo con igual probabilidad.
4.6.6 Procesos de llegada no estacionarios

Este tema de cierta especialización merece ser mencionado ya que parece surgir a menudo
y puede ser muy importante en términos de representar de forma válida el comportamiento
del sistema. Muchos sistemas sujetos a llegadas externas, como los sistemas de servicio para
personas, centros de llamadas telefónicas y sistemas de fabricación con demandas externas
del cliente, experimentan muchas llegadas que pueden variar de forma dramática en el marco
de tiempo de la simulación. Los ejemplos incluyen un apuro de mediodía por hamburguesas,
muchas llamadas a una línea de soporte técnico a media tarde, y una fuerte demanda de un
sistema de fabricación durante ciertas temporadas. Un modelo de probabilidad específico
para eso, el proceso Poisson no estacionario, es muy útil y a menudo proporciona una forma
precisa de reflejar patrones de llegada de tiempo variable. Hay que tratar estos dos temas:
cómo estimar o especificar la función de razón de llegadas y, luego, cómo generar el patrón
de llegada en la simulación.
Hay muchas formas de estimar o especificar una función de razón de los datos, algunas de
las cuales pueden ser muy complicadas. Aquí nos aferraremos a un método bastante simple que
se llama la función de razón de llegadas constante por segmentos, que parece funcionar bien en
muchas aplicaciones. Primero identifique las longitudes de tiempo dentro de las que la razón de
llegada parece ser demasiado plana; por ejemplo, las llegadas de un centro de llamadas pueden
ser bastante constantes en periodos de media hora pero pueden ser muy diferentes en diversos
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.6.7 Datos de entrada multivariados y correlacionados

La mayoría del tiempo asumimos que todas las variables aleatorias que impulsan una simula-
ción son generadas independiente entre ellas, a partir de cualquier distribución que decidamos
que las represente. Sin embargo, algunas veces, esto puede no ser la mejor suposición por ra-
zones puramente físicas. Por ejemplo, en el modelo 4-2 el lector puede imaginarse que ciertas
partes son “difíciles”, tal vez se detectaría esto al notar que un tiempo de preparación grande
para una parte en específico tiende a ser seguido por un tiempo de sellado largo para esa parte;
es decir, estos dos tiempos están correlacionados de forma positiva. Ignorar esta correlación
puede originar un modelo no válido y resultados sesgados.
Hay una gran cantidad de formas para modelar situaciones como ésta, para estimar los
parámetros requeridos (incluyendo la fuerza de las correlaciones), y para generar las observa-
ciones requeridas en las variables aleatorias durante la simulación. Algunos de estos métodos
conllevan ver a las variables aleatorias asociadas como coordenadas de un vector aleatorio que
tiene alguna unión de distribución multivariada que ajustar y de la cual generar. También debe
poder especificar algún tipo de asociación basada en fórmulas entre las cantidades de entrada
relacionadas. Pero, francamente, esto es un tema muy difícil en términos de estimar el compor-
tamiento y de generarlo durante la simulación. Para más de estos y otros temas relacionados,
véase Law y Kelton (2000) o Devroye (1986).

Si leyó y entendió el material en este capítulo, se estará volviendo peligroso en el uso de Arena.
Lo animamos a presionar otros botones en los módulos que hemos usado e incluso a probar
módulos que no hemos usado. Si se atasca, pruebe la característica de Ayuda en línea, que pue-
de no responder su pregunta, pero resolverá las preguntas que debe estarse haciendo. También
puede probar otras características de animación o proporcionar imágenes más agradables. En
este punto, el mejor consejo que le podemos dar es que use Arena. Los capítulos 5 al 12 cubrirán
la mayoría de las capacidades de modelación (y algunas de las capacidades de análisis estadís-
tico) de Arena más a profundidad.
188 Capítulo 4
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):
Ejecución 1: tiempos entre llegadas y tiempos de servicio exponenciales.

Ejecución 2: tiempos entre llegadas constantes y tiempos de servicio exponenciales.
Ejecución 3: tiempos entre llegadas exponenciales y tiempos de servicio constantes.
Ejecución 4: tiempos entre llegadas y tiempos de servicio constantes.
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
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.
4-7 Un sistema de producción propuesto consiste en cinco estaciones de trabajo automáticas

seriales. Los tiempos de proceso en cada estación de trabajo son constantes: 11, 10, 11, 11 y 12
(todos los tiempos dados en este problema se encuentran en minutos). Los tiempos entre llegadas
de las partes son UNIF(13, 15). Hay un tope ilimitado al frente de todas las estaciones de trabajo,
y asumiremos que todos los tiempos de transferencia son insignificantes o cero. El aspecto único
de este sistema es que en las estaciones de trabajo 2 hasta la 5 hay una oportunidad de que la parte
necesitará reprocesarse por la estación de trabajo que la precede. Por ejemplo, después de termi-
nar en la estación de trabajo 2, la parte se puede mandar de nuevo a la cola al frente de la estación
de trabajo 1. La probabilidad de volver a visitar una estación de trabajo es independiente de que
la misma parte se pueda regresar muchas veces sin cambio en la probabilidad. En este momento,
190 Capítulo 4
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-8 Un sistema de producción consiste en cuatro estaciones de trabajo automáticas seriales.

La primera parte llega en el tiempo 0, y entonces (exactamente) cada 9.8 minutos después. To-
dos los tiempos de transferencia se asumen que sean cero y todos los tiempos de proceso son
constantes. Hay dos tipos de fallas: mayores y atascos. Los datos para este sistema se dan en la
tabla de abajo (todos los tiempos están en minutos). Use las distribuciones exponenciales para
los tiempos de funcionamiento y las distribuciones uniformes para los tiempos de reparación
(por ejemplo, reparar los atascos en la estación de trabajo 3 es UNIF(2.8, 4.2)). Ejecute su si-
mulación por 10 000 minutos para determinar el porcentaje de tiempo que cada recurso pasa
en estado de falla y el estado de término de cada una de las colas de cada estación de trabajo.
Medias de fallas mayores Medias de atascos

Número de la Tiempo de Tiempo de Tiempo de
estación de trabajo proceso funcionamiento Reparación funcionamiento Reparación
1 8.5 475 20, 30 47.5 2, 3
2 8.3 570 24, 36 57 2.4, 3.6
3 8.6 665 28, 42 66.5 2.8, 4.2
4 8.6 475 20, 30 47.5 2, 3
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-
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-
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.
4-22 La administración quiere estudiar la terminal 3 de una central aeroportuaria con la

finalidad de mejorar. El primer paso es modelarla tal cual está durante las ocho horas de la
parte más ocupada de un día laboral típico. Modelaremos sólo las operaciones de facturación
y seguridad, esto es, una vez que los pasajeros pasan la seguridad se encuentran en su camino
hacia su puerta y salen de nuestro modelo. Los pasajeros llegan uno a la vez a través de la puer-
ta del frente del transporte de tierra con tiempos entre llegadas distribuidos exponencialmente
con media de 0.5 minutos (todos los tiempos son en minutos a menos que se indique otra
cosa). De estos pasajeros, 35% van hacia la izquierda a un mostrador de facturación manual
obsoleto, 50% van a la derecha hacia un mostrador de facturación automatizado novedoso, y
15% restante no necesita facturar nada y se dirigen directamente de la puerta del frente hacia
el área de seguridad (esto le toma a este último tipo de pasajeros entre 3 y 5 minutos, distri-
buidos uniformemente, para hacer el recorrido de la puerta de entrada a la entrada del área
de seguridad; los otros dos tipos de pasajeros se mueven instantáneamente de su llegada al
mostrador de facturación manual o automático según sea el caso). Hay dos agentes en la esta-
ción de facturación manual, abastecidos por una sola cola FIFO; los tiempos de facturación
manual siguen una distribución triangular entre 1 y 5 minutos con una moda de 2 minutos.
Después de la facturación manual, los pasajeros caminan al área de seguridad, un paseo que
les toma entre 2 y 6 minutos, distribuidos uniformemente. La facturación automática tiene dos
estaciones (una estación consiste de un módulo de pantalla táctil y un empleado para tomar
las bolsas registradas; vea al par de empleado/kiosco como una unidad unificada, es decir, el
kiosco y su empleado no se pueden separar), alimentados por una sola cola FIFO, y los tiempos
de facturación tienen una distribución triangular entre 0.5 y 1.5 con una moda de 1. Después
de la facturación automática, los pasajeros caminan al área de seguridad, y tardan entre 1 y 3
minutos, distribuidos uniformemente, en llegar ahí (los pasajeros de la facturación automática
son un poco más rápidos que los pasajeros de registro manual en todo). Finalmente todos los
pasajeros llegan al área de seguridad, donde hay seis estaciones alimentadas por una sola cola
FIFO; los tiempos de revisión de seguridad son de distribución triangular entre 1 y 6 con una
moda de 2 (esta distribución captura todas las posibilidades ahí, como los rayos X del equipaje
de mano, caminar a través del detector de metales, búsqueda de bolsos, detector de metales de
mano, quitarse los zapatos, revisión de computadoras portátiles, etc.). Una vez que aprueban
la revisión de seguridad (todos pasan, aunque a algunos les toma más tiempo que a otros), los
pasajeros se dirigen a sus puertas y ya no se encuentran en nuestro modelo. Simule este sistema
por un periodo de 8 horas y observe las longitudes promedio de las colas, tiempos promedio en
la cola, utilizaciones de los recursos y el tiempo total promedio en el sistema de los pasajeros
(para los tipos de pasajeros combinados). Anime su modelo, incluyendo colas, recursos y pasa-
jeros que caminen hacia el área de seguridad. Ponga gráficas que rastreen la longitud de cada
una de las tres colas durante la simulación de ocho horas (ya sean tres gráficas por separado o
tres curvas en una única gráfica).
CAPÍTULO 5
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
5.1 Modelo 5-1: un sistema de centro de atención telefónica sencillo

Nuestro sistema de centro de atención telefónica genérico proporciona un número central en
una organización al que los clientes llaman para encontrar soporte técnico, información de
ventas y estado de los pedidos. Las llamadas entrantes llegan con tiempos entre llegadas distri-
buidas exponencialmente con una media de 0.857 minutos. Este número central alimenta 26 lí-
neas troncales. Si las 26 líneas están en uso, la persona que llama obtiene una señal de ocupado;
con un poco de suerte, quien llame lo intentará de nuevo más tarde, pero para nuestro modelo,
sólo se va. Alguien que llame y le contesten escucha una grabación que describe tres opciones:
transferencia al soporte técnico, información de ventas o petición de información del estado de
un pedido (76, 16 y 8% respectivamente). El tiempo estimado para esta actividad es UNIF(0.1,
0.6); todos los tiempos están en minutos.
Si quien llama elige el soporte técnico, una segunda grabación pregunta cuál de los tres
tipos de producto usa el cliente, lo que requiere UNIF(0.1, 0.5) minutos. El porcentaje de pe-
ticiones para los tipos de producto 1, 2 y 3 son 25, 34 y 41%, respectivamente. Si una persona
calificada de soporte técnico está disponible para el tipo de producto seleccionado, la llamada
se enruta de forma automática a esa persona. Si no hay nadie disponible en ese momento,
se coloca al cliente en una cola electrónica en donde está sujeto a música rock molesta hasta
que la persona de soporte esté disponible. Se estima que el tiempo para todas las llamadas de
soporte técnico sea TRIA(3, 6, 18) minutos sin importar el tipo de producto. Una vez com-
pletada la llamada, el cliente sale del sistema.
Las llamadas de ventas se enrutan de forma automática al personal de ventas. Si no hay
vendedores disponibles, la persona que llama recibe música espacial new-age tranquilizante
(después de todo, esperamos una venta). Se estima que las llamadas de venta sean TRIA(4, 15,
45): ¡el personal de ventas tiende a hablar mucho más que el de soporte técnico! Una vez com-
pletada la llamada, el feliz cliente sale del sistema.
Quienes llaman y solicitan información sobre el estado de un pedido son manejados de
forma automática por el sistema telefónico y no hay un límite en el número que maneja el siste-
ma (excepto que existen sólo 26 líneas principales, lo que en sí mismo es un límite, puesto que
una llamada del estado de un pedido en curso ocupa una de esas líneas). El tiempo estimado
para estas transacciones es TRIA(2, 3, 4) minutos, con 15% de esos clientes que optan por ha-
blar con un operador telefónico después de haber recibido el estado de su orden.
Estas llamadas se enrutan al personal de ventas en donde esperan con una prioridad menor que
las llamadas de ventas. Ello significa que si una llamada del estado de una orden está en la cola, en
espera de un vendedor, y entra una nueva llamada que llega a ventas, se le dará prioridad a esta últi-
ma sobre la anterior y se atenderá primero. Se estima que estas llamadas de seguimiento del estado
de una orden duren TRIA(3, 5, 10) minutos. Estas personas que llaman después dejan el sistema.
El horario del centro de atención es de 8 a.m. a 6 p.m., con una pequeña proporción del
personal en servicio hasta las 7 p.m. Aunque el sistema se cierra a nueva llamadas a las 6 p.m,
todas las llamadas que entran al sistema a esa hora se contestan y atienden.
En el curso de un día hay ocho empleados de soporte técnico para responder llamadas de este
tipo. Dos se dedican a llamadas para el tipo de producto 1; tres, a llamadas para el tipo de pro-
ducto 2 y otros tres a llamadas para el tipo de producto 3. Hay cuatro empleados de ventas para
responder tales llamadas y aquéllas sobre el estado de una orden realizadas por quienes opten por
hablar con un operador telefónico.
Como punto de interés, contaremos el número de llamadas de clientes que no pueden llegar
a una línea principal y que por lo tanto son rechazados para entrar al sistema (algo similar al
Modelado de operaciones detalladas 197
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.
5.2 Nuevos temas de modelado

Desde el punto de vista de la simulación, este problema es bastante diferente de los que cu-
brimos en los capítulos 3 y 4. La diferencia más obvia es que los sistemas anteriores estaban
orientados a la fabricación y éste es de una naturaleza de servicio. Aunque la versión original
de SIMAN (el lenguaje de simulación en el que está basado Arena) se desarrolló para aplica-
ciones de fabricación, las capacidades actuales de Arena también permiten el modelado ade-
cuado de sistemas de servicio. Las aplicaciones en esta área incluyen restaurantes de comida
rápida, bancos, empresas de seguros, centros de servicio y muchos más. Aunque tales sistemas
tienen algunas características especiales, los requisitos básicos de modelado son en gran parte
los mismos que en los sistemas de fabricación.
Ahora echemos un vistazo a nuestro centro de llamadas y exploremos los nuevos requisitos.
5.2.1 Rechazos (Rejections) y cuando el cliente renuncia (Balking)

Una llamada generada por nuestro proceso de llegada es en realidad un cliente que intenta
tener acceso a una de nuestras 26 líneas principales. Si las 26 líneas se encuentran en uso en ese
momento, se recibe una señal de ocupado y se rechaza (reject) al cliente, quien deja el sistema.
El término para esto es balking (renuncia), si es que el cliente lo hace de forma voluntaria, aun-
que en nuestro centro de atención es involuntario, así que lo llamaremos rejection (rechazo); el
modelado y el manejo del balking y del rejection es, no obstante, similar entre ellos.
Considere un mostrador de autoservicio en un restaurante de comida rápida que tiene una
sola ventanilla con espacio para que sólo cinco autos esperen por el servicio. Las entidades que
llegan serían los autos que entran a una cola para esperar a tomar el recurso que se llama “ser-
vicio de ventanilla”. Necesitaríamos configurar la capacidad de la cola en 5. Esto permitiría a
un auto estar en servicio y a un máximo de cinco autos a esperar. Si un sexto auto intenta entrar
a la cola, renunciaría (balk) o sería rechazado (rejected). Decida el lector entonces, como parte
de sus supuestos de modelado, qué sucede con estos autos o entidades balked/rejected (que
renunciaron /fueron rechazadas). Deberían ser dispuestas (Disposed) o podríamos suponer que
manejarían alrededor de la cuadra e intentarían volver a entrar a la cola un poco después.
Existen dos métodos para modelar el (balking/rejection) en Arena. El primer método
es emplear un módulo Queue (Cola) del Block panel (panel de bloques) y definir la capaci-
dad de la cola como 0. Una entidad que llega (una llamada que ingresa en nuestro modelo) entra
en la cola con capacidad cero y de inmediato intenta tomar una unidad del recurso que se llama
“línea principal”. Si alguna unidad está disponible, se le asigna a una llamada y ésta entra al sis-
tema. Si no hay ninguna unidad del recurso disponible, la entidad intenta quedarse en la cola.
Pero puesto que la cola tiene una capacidad de 0, la llamada tendría que renunciar (balked) de
entrar en la cola y se desharía de ella. El segundo método dejaría que la entidad que llega usara
198 Capítulo 5
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.
5.2.2 Decisiones de tres caminos

Una vez que a una llamada se le asigna una línea principal y entra al sistema, entonces debemos
determinar el tipo de llamada de manera que la podamos dirigir a la parte correcta del sistema
para servicio. Para hacerlo, necesitamos la habilidad de enviar entidades o llamadas a tres di-
ferentes partes del sistema según las probabilidades dadas. El mismo requisito aplica para las
llamadas técnicas, puesto que hay tres diferentes tipos de productos.
Podríamos sacar nuestra calculadora y quitarle el polvo a nuestros conceptos de probabi-
lidad para calcular la probabilidad de cada tipo de llamada (hay un total de cinco). Entonces
podríamos definir las Sequences [secuencias] (véase la sección 7.1) para cada uno de estos tipos
de llamadas y enrutarlas a través del sistema. Aunque esto pudiera funcionar, tendría que volver
a calcular las probabilidades cada vez que cambie la distribución de los tipos de llamada, lo que
habrá que hacer para probar la flexibilidad o fortaleza del sistema.
Puede no haber considerado esto, pero la capacidad se proporciona para bifurcarse en tres o
más direcciones en el mismo módulo Decide (Decidir) que usamos en los modelos del capítulo 4.
5.2.3 Variables y expresiones

En muchos modelos es posible que queramos usar de nuevo los datos en varios lugares diferen-
tes. Por ejemplo, en nuestro centro de llamadas, habrá varios lugares en donde necesitaremos
introducir las distribuciones del tiempo para manejar las llamadas de soporte técnico. Si deci-
dimos cambiar este valor durante nuestra experimentación, tendremos que abrir cada diálogo
que incluya un tiempo de llamada y cambiar el valor. Hay otras situaciones en donde nos gusta-
ría mantener el rastro del número total de entidades en el sistema o en una parte del mismo. En
otros casos, puede ser que queramos usar expresiones complejas durante todo el modelo. Por
ejemplo, podríamos basar el tiempo de proceso en el tipo de parte. Las variables y expresiones
de Arena nos permiten satisfacer estas clases de necesidades con facilidad.
El módulo Variables permite definir variables globales propias y sus valores iniciales. Luego,
las variables se pueden referenciar en el modelo por sus nombres. También se les puede especi-
ficar como arreglos de una o dos dimensiones. El módulo Expressions (Expresiones) le permite
definir expresiones y sus valores asociados. Igual que las variables, las expresiones se señalan
en el modelo por sus nombres y también pueden especificarse como arreglos de una o dos
dimensiones. Aunque las variables y las expresiones pueden parecer bastante similares, sirven
claramente a funciones diferentes.
Las variables definidas por el usuario almacenan alguna cantidad de valor real que puede
reasignarse durante la ejecución de la simulación. Por ejemplo, podríamos definir una variable
llamada Wait Time (Tiempo de espera) con un valor inicial de 2 e introducir el nombre
de la variable dondequiera que se requiera un tiempo de espera. También podríamos definir
una variable llamada Numer in System (Número en el sistema) con un valor inicial
de 0, añadir 1 a esta variable cada vez que una nueva parte entra al sistema y restar 1 cada vez
que una parte salga del sistema. Para nuestro centro de llamadas, emplearemos dos variables.
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.
5.2.4 Almacenamientos (Storages)

Los almacenamientos son un concepto de Arena que permiten al usuario animar la presencia
de entidades que caen fuera de las características de animación normales que conoce hasta
ahora. Todos nuestros modelos previos mostraron una entidad animada en una cola, en un
recurso o moviéndose a lo largo de la ruta. Considérese un ejemplo en donde se tiene la llegada
de una entidad que desde el inicio encuentra una demora antes de que se le permita proceder al
siguiente módulo. Si la demora representa un tiempo de viaje de un área del sistema hacia otra,
se debería usar el concepto de estaciones y rutas. Esto permitirá animar el movimiento de una
entidad a través del sistema, como se hizo en el modelo 4-4. Pero si durante la demora la entidad
no se mueve, para animarla necesitaremos el concepto de almacenamientos.
Un almacenamiento (storage) mantiene un conjunto no ordenado de entidades que esperan
que suceda un evento; es decir, la conclusión de un tiempo de demora predefinido, la llegada de
un transportador requerido que está en ruta, una eliminación del almacén, etc. Puede pensar en
un almacenamiento como en una variable que podemos aumentar o disminuir con la característi-
ca añadida de que podemos animar las entidades que se encuentran en el almacenamiento. Colo-
car una entidad en un almacenamiento no impide que la entidad progrese a través de la lógica del
modelo. Por ejemplo, podríamos colocar una entidad en un almacenamiento y después mostrarla
en la animación, conforme entró en una demora y después continuar a través de la lógica del mo-
delo hasta que decidamos quitarla del almacenamiento en un punto más adelante en el modelo.
Durante todo el tiempo, la entidad se mostraría en un almacenamiento animado.
Existen dos formas de colocar una entidad en un almacenamiento y después quitarla. La
primera usa los módulos Store (Almacenar) y Unstore (Desalmacenar) que se encuentran en el
Advanced Process panel (panel de procesos avanzados). La segunda forma es emplear un mo-
delo que tenga un campo para introducir la Storage ID (Identificación de Almacenamiento).
Un ejemplo es el módulo Delay (Demora) del panel de bloques (Blocks panel). Le mostraremos
cómo usar ambos métodos durante el desarrollo de nuestro modelo.
5.2.5 Simulaciones terminantes o de estado estable

La mayoría de las simulaciones (no todas) se pueden clasificar ya sea como terminantes o de
estado estable. Éste es principalmente un tema de intención o el objetivo del estudio, más que
tener mucho que ver con la lógica o construcción interna del modelo.
200 Capítulo 5
Una simulación terminante es en la que el modelo dicta condiciones específicas de comienzo

y fin, como un reflejo natural de cómo el sistema objetivo opera realmente. Como lo sugiere
el nombre, la simulación terminará de acuerdo con alguna regla o condición especificada por
el modelo. Por ejemplo, una tienda abre a las 9 a.m. sin clientes presentes, cierra sus puertas a
las 9 p.m. y después continúa en operación hasta que todos los clientes se hayan ido. Otro ejem-
plo es la configuración de un taller, que opera el tiempo que le lleve producir una “ejecución” de
500 ensambles completos especificados en una orden. La noción clave es que la característica
“tiempo” de la simulación tiene un fin bien definido (aunque posiblemente desconocido al ini-
cio) y natural, así como una forma para empezar claramente definida.
Una simulación de estado estable, por otra parte, es una en la que las cantidades a estimar
están definidas a largo plazo; es decir, sobre un marco de tiempo teóricamente infinito. En prin-
cipio (aunque por lo general no en la práctica), las condiciones iniciales para la simulación no
importan. Por supuesto, una simulación de estado estable debe detenerse en algún momento, y
como puede suponer, estas ejecuciones pueden hacerse bastante largas, así que tiene que hacer
algo para asegurarse que la ejecuta lo suficiente. Éste es un tema que tocaremos en la sección
7.2. Por ejemplo, una sala de emergencias pediátricas nunca se detiene o comienza de nuevo
en realidad, así que sería apropiada una simulación de estado estable. A veces las personas ha-
cen una simulación de estado estable de un sistema que, de hecho, termina con la finalidad de
diseñar algún tipo de situación del peor de los casos o situación pico.
Ahora debemos decidir cuál realizar para este modelo de centro de llamadas. Aunque lo
guiaremos para hacerle pensar que la distinción es muy clara entre los sistemas terminantes y
no terminantes, rara vez se da el caso. Al principio algunos sistemas parecen ser de un solo tipo,
pero en un examen más detallado resultan ser del otro. Este tema es mucho más complicado,
debido al hecho de que algunos sistemas tienen elementos de ambos tipos y la clasificación
del sistema puede depender de los tipos de preguntas que el analista desee hacer. Por ejemplo,
considere que un restaurante de comida rápida abre a las 11 a.m. y cierra a las 11 p.m. Si estu-
viéramos interesados en los temas de la operación diaria de este restaurante, analizaríamos el
sistema como uno terminante. Si nos interesara sólo en la operación durante la demanda que
ocurre durante las dos horas del almuerzo, podríamos asumir un proceso de llegada estaciona-
rio en el rango pico de llegadas y analizar el sistema como uno de estado estable.
Nuestro centro de llamadas definitivamente parece ser un sistema terminante. El sistema
podría parecer que empieza y termina vacío y desocupado, así que procederemos a analizar
nuestro sistema de centro de llamadas como uno terminante.
5.3 Enfoque del modelado

En la figura 1-2 del capítulo 1 se analizó brevemente la estructura jerárquica de Arena. Esta estruc-
tura le permite combinar libremente las construcciones de modelado desde cualquier nivel dentro
de un solo modelo de simulación. En los capítulos 3 y 4 pudimos desarrollar nuestros modelos al
usar en su mayoría sólo las construcciones que se encuentran en el Basic Process panel [panel de
procesos básicos] (sí, lo planeamos de esa forma), aunque sí requerimos del Advanced Process pa-
nel (panel de procesos avanzados) para nuestra falla y para estadísticas especiales y el Advanced
Transfer panel (panel avanzado de transferencia) para algún movimiento de la entidad.
El enfoque general que le recomendamos cuando cree sus modelos es que permanezca en el
nivel más alto posible durante todo el tiempo que pueda. Sin embargo, tan pronto como note
que estas construcciones de alto nivel no le permiten captar el detalle necesario, le sugerimos
bajar al siguiente nivel para ver algunas partes de su modelo en lugar de sacrificar la precisión
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.
5.4 Construcción del modelo

En este punto vamos a dividir nuestro modelo en secciones y a ir directamente a su desarrollo
en donde podamos mostrarle de forma instantánea las capacidades disponibles. Las siete sec-
ciones, en el orden en que se presentarán, son:
Sección 5.4.1: Crear llegadas y dirigir al servicio,
Sección 5.4.2: Lógica de corte de llegada,
Sección 5.4.3: Llamadas de soporte técnico,
Sección 5.4.4: Llamadas de ventas,
Sección 5.4.5: Llamadas de estado del pedido
Sección 5.4.6: Salida del sistema y configuración de ejecución, y
Sección 5.4.7: Animación.
A medida que lee las siguientes siete secciones sobre la construcción del modelo, puede tener la
impresión que es exactamente así como desarrollamos el modelo. De forma ideal, uno querría ser
capaz de planear la construcción del modelo de forma que fuera fácil. En realidad, sin embargo, a
menudo uno termina volviendo a una sección previamente desarrollada y añadiendo, borrando o
cambiando módulos o datos. Así que cuando comience a desarrollar modelos más complejos, no
asuma que siempre lo hará bien al primer intento (ciertamente nosotros no lo hicimos así).
5.4.1 Crear llegadas y dirigir al servicio

Conforme aprenda más acerca de las capacidades de Arena y desarrolle modelos más comple-
jos, verá que es necesario planear su lógica antes de construir su modelo. De otra forma, puede
encontrarse a sí mismo cambiando constantemente de módulos o borrando los que fueron
seleccionados por equivocación. Cualquier método que adopte para planear sus modelos con
normalidad se sucederán de forma natural, pero tal vez el lector quiera meditar sobre ellos an-
7FSEBEFSP "VNFOUBS "MNBDFOBS

y-ÎOFB %FNPSBEF (SBCBS
(SBCBS 0 5PNBSMÎOFB DPOUBEPSEF QBSBEFNPSB
$SFBSMMFHBEBT USPODBM HSBCBDJÓO MMBNBEB
MMBNBEBEF USPODBM MMBNBEB EFHSBCBDJÓO
EFMMBNBEBT EJTQPOJCMF JOJDJBM SFDIB[BEB
JOUFOUP BDUJWB JOJDJBM
0
0 %JTQPOFSEF
'BMTP %FTBMNBDFOBS
EFMBEFNPSBEF MBMMBNBEB
0
HSBCBDJÓOJOJDJBM SFDIB[BEB
%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.
Name (Nombre) reate Call Arrivals (Crear llegadas de

C
llamadas)
Entity Type (Tipo de entidad) Incoming Call (Llamada entrante)
Time Between Arrivals (Tiempo entre llegadas)
Type (Tipo) Random (Expo) [Aleatorio (Expo)]
Value (Valor) 0.857
Max Arrivals (Llegadas máximas) MaxCalls (Máximo de llamadas)
Pantalla 5-1. Creación de las llegadas de las llamadas

204 Capítulo 5
Figura 5-2. El módulo de datos variable
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-
Name (Nombre) Record Attempted Call (Grabar llamada

intentada)
Type (Tipo) Count (Contar)
Value (Valor) 1
Counter Name (Nombre del Contador) Attempted Calls (Llamadas intentadas)
Pantalla 5-2. Conteo de las llamadas de intención

Name (Nombre) Trunk Line Available? (¿Está disponible una línea

principal?)
Type (Tipo) 2-way by Condition (2 vías por condición)
If (Si) Expression (Expresión)
Value (Valor) NR (Trunk Line) < MR (Trunk Line) [NR (Línea
principal) < MR (Línea principal)]
Pantalla 5-3. Determinar si hay disponible alguna línea principal
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
Tabla 5-1. La notación de condición del módulo Decidir
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
Name (Nombre) Seize Trunk Line (Tomar la línea

principal)
Resource Name (Nombre del recurso) Trunk Line (Línea principal)
Pantalla 5-4. El módulo Tomar
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
Name (Nombre) Store for Initial Recording Delay (Almacenar para

una demora de grabación inicial)
Type (Tipo) Storage (Almacenamiento)
Storage Name (Nombre del Initial Recording Delay Storage (Almacenamiento
almacenamiento) de una demora de grabación inicial)
Pantalla 5-6. Colocación de la entidad en un almacenamiento
Una vez completada la demora, entra a un módulo Unstore (Desalmacenar) en donde la

entidad se retira del almacenamiento en donde se colocó con anterioridad. Debería notar que
predeterminamos la entrada Type, en la pantalla 5-8. La opción predeterminada quitará una
entidad del último almacenamiento en el que entró, que fue Initial Recording Delay
Storage (Almacenamiento de una demora de grabación inicial).
Entonces se envía la llamada al módulo Decide (Decidir), descrito en la pantalla 5-9, en
donde el tipo de llamada se determina según las probabilidades señaladas originalmente. Selec-
cionamos el tipo N-way by Chance y especificamos los porcentajes en 76 y 16, que repre-
Name (Nombre) Initial Recording Delay (Demora de

grabación inicial)
Delay Type (Tipo de demora) UNIF(0.1, 0.6)
Pantalla 5-7. Demora de grabación inicial
Name (Nombre) Unstore form Initial Recording Delay (Desalmacenar

de la demora de grabación inicial)
Pantalla 5-8. Remoción de la entidad del almacenamiento

208 Capítulo 5
Determine Call Type (Determinar el tipo de

Name (Nombre)
llamada)
Type (Tipo) N-ways by chance (N-vías por probabilidad)
Percentages (Porcentajes) 76
16
Pantalla 5-9. Determinación del tipo de llamada
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.
5.4.2 Lógica de corte de llegada (cutoff)

En la descripción del problema de la sección 5.1, indicamos que el sistema se cierra a nuevas
llamadas después de las 6 p.m., pero que todas las llamadas que entraron al sistema antes de ese
tiempo se responden. Esto significa que permitimos a las llamadas entrar al sistema de 8 a.m.
a 6 p.m., un total de 600 minutos, pero hay que cortar las llegadas después de los 600 minutos.
Normalmente terminaríamos la ejecución de la simulación en el tiempo 600. Sin embargo, an-
tes de terminar la ejecución de la simulación, se tiene que manejar cualquier llamada que haya
llegado previa al tiempo 600. Le mostraremos cómo determinar cuándo se han atendido todas
las llamadas y cómo terminar con la ejecución después.
Una forma obvia para cortar las llegadas después de los 600 minutos sería insertar un mó-
dulo Decide (Decidir), en el que las llamadas que llegan entrarían de forma inmediata después
del módulo Create (Crear) que crea las llamadas que llegan. El módulo Decide (Decidir) com-
probaría si el tiempo de simulación actual fue menor a 600. Si es así, se le permitiría a la entidad
continuar; de otra forma, se enviaría a la entidad al módulo Dispose (Disponer). Aunque este
Name (Nombre) Record Rejected Call (Grabar las

llamadas rechazadas)
Value (Valor) 1
Counter Name (Nombre del contador) Rejected Calls (Llamadas rechazadas)
Pantalla 5-10. El módulo Record (Grabar): conteo de llamadas rechazadas

$SFBSFOUJEBE %JTQPTJDJÓOEFMB
EFDPSUFEF $PSUBSMMBNBEBT
FOUJEBEEFDPSUF
MMFHBEB FOUSBOUFT
EFMMFHBEB
Figura 5-3. Lógica de corte de llegada (cutoff)
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.
Name (Nombre) Create Arrival Cutoff Entity (Crear entidad

de corte de llegada)
Entity Type (Tipo de entidad) Arrival Cutoff (Corte de llegadas)
Time Between Arrivals (Tiempo entre
llegadas)
Type (Tipo) Constant (Constante)
Value (Valor) 999999
Units (unidades) Minutes (Minutos)
Max Arrivals (Llegadas máximas) 1
First Creation (Primera creación) 600
Pantalla 5-11. Creación de la entidad lógica

210 Capítulo 5
Name (Nombre) Cutoff Incoming Calls (Cortar

llamadas entrantes)
Variable Name (Nombre de la variable) MaxCalls (Máximo de llamadas)
New Value (Nuevo valor) 1
Pantalla 5-12. Asignación de la variable de corte
Al configurar el valor de la variable MaxCalls en 1, detuvimos la creación de llamadas que

llegan. Nos imaginamos que ya se confundió en este punto (o si no, debería estarlo). Ahonde-
mos en los detalles de forma que entienda cómo funciona. Al principio, cuando poblamos el
módulo Create que crea las llamadas que llegan, en la pantalla 5-1, introdujimos la variable
MaxCalls en el campo Max Arrivals. También asignamos a esa variable un valor inicial de
999999 en el módulo de datos Variable. Puesto que estamos en el tiempo 600 de nuestra ejecu-
ción de simulación, podemos estar seguros de que hemos tenido más de una sola llegada, ya que
la primera creación (First Creation) fue en el tiempo 0. Ahora (en el tiempo 600) al configurar
el valor de MaxCalls en 1 estamos cortando el flujo de llamadas que llegan.
Habiendo logrado su única tarea en la vida, nuestra entidad lógica se envía ahora al módulo
Dispose (Disponer) que destruye entidades, por lo tanto termina nuestra sección de modelado
de la lógica.
5.4.3 Llamadas de soporte técnico

En la sección 5.4.1, usamos un módulo Decide (Decidir) para determinar el tipo de llamada. Las
llamadas que llegan que sean de soporte técnico podrían haber tomado la primera ramificación y
haber sido enviadas a esta parte del modelo. Las actividades para revisar las llamadas de soporte
técnico se enlistan aquí y los módulos de diagrama de flujo se muestran en la figura 5-4:
Asignar el tipo e imagen de la entidad
Demorar para grabar
Determinar el tipo y dirección de la llamada
Tomar el recurso del soporte técnico
Demorar para el servicio
Liberar el recurso de soporte técnico
Enviar a la salida del sistema
Si alguien que llama selecciona la opción de soporte técnico, las entidades se enviarán a esta
porción de nuestro modelo, en donde primero asignamos que el Entity Type (Tipo de entidad)
sea Tech Call y la Entity Picture (Imagen de entidad) sea Picture.Red Ball, como en
la pantalla 5-13.
"TJHOBSUJQPF "MNBDFOBS %FTBMNBDFOBS

%FNPSBEF
JNBHFOEF EFNPSBEF EFNPSBEF
HSBCBDJÓOFO
FOUJEBEDPNP HSBCBDJÓOQBSB HSBCBDJÓOQBSB
MMBNBEBUÊDOJDB
MMBNBEBUÊDOJDB MMBNBEBUÊDOJDB MMBNBEBUÊDOJDB
1SPDFTBSUJQPEF
QSPEVDUP
MMBNBEBUÊDOJDB
%FUFSNJOBSUJQP
EFQSPEVDUP

1SPDFTBSUJQPEF
0USP QSPEVDUP
MMBNBEBUÊDOJDB
1SPDFTBSUJQPEF
QSPEVDUP
MMBNBEBUÊDOJDB
Figura 5-4. Lógica de llamada de soporte técnico
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
Name (Nombre) Assign Tech Call Entity Type and Picture

(Asignar tipo e imagen de entidad como
llamada técnica)
Type (Tipo) Entity Type (Tipo de entidad)
Entity Type (Tipo de entidad) Tech Call (llamada técnica)
Type (Tipo) Entity Picture (Imagen de entidad)
Entity Picture (Imagen de entidad) Picture.Red Ball
Pantalla 5-13. Asignación de la llamada técnica de tipo de entidad e imagen
Name (Nombre) Store for Tech Call Recording Delay (Almacenar

demora de grabación para llamada técnica)
Type (Tipo) Storage (Almacenamiento)
Storage Name (Nombre del Tech Call Recording Delay Storage (Almacenamiento
almacenamiento) de demora de grabación de llamada técnica)
Pantalla 5-14. Almacén de llamada de soporte técnico

212 Capítulo 5
Name (Nombre) Tech Call Recording Delay (Demora de

grabación de llamada técnica)
Delay Time (Tiempo de demora) UNIF(0.1, 0.5)
Pantalla 5-15. Demora de grabación de soporte técnico
Cuando la entidad se ha colocado en Almacenamiento, entra el siguiente módulo Delay

(Demora) donde incurre en una demora UNIF (0.1, 0.5), que representa el tiempo de grabación
y de selección de opción, como se presenta en la pantalla 5-15.
Una vez terminada la demora, entra a un módulo Unstore (Desalmacenar), en el que la entidad
se retira del almacenamiento donde se había colocado, como se indica en la pantalla 5-16. De nue-
vo, la opción predeterminada removerá a la entidad del último almacenamiento en el que entró.
La llamada se envía al siguiente módulo Decide (Decidir), como se describe en la pantalla
5-17, donde el tipo de producto se determina de acuerdo a las probabilidades señaladas origi-
nalmente. Seleccionamos tipo N-way by Chance (N vías por probabilidad) y especi-
ficamos los porcentajes de 25 y 34, que representan las llamadas de soporte técnico de Tipo 1
y Tipo 2. El punto de salida Else (Otro) se usará para dirigir las llamadas del producto Tipo 3
(41% restante).
Cada una de las tres ramificaciones de este módulo Decide (Decidir) se conectan al módulo
Process (Proceso) para atender este tipo de llamadas de soporte técnico. Las entradas para cada
uno de estos tres módulos son muy similares, así que sólo guiaremos al lector por el primero,
para el producto del Tipo 1 de soporte técnico, en la pantalla 5-18. Hemos seleccionado la
acción Seize Delay Release (Tomar Demorar Liberar) y hemos solicitado tomar 1 unidad del
recurso Tech 1. Como con el recurso Trunk Line (Línea principal), también hay que
abrir el módulo de datos Resource (Recurso) y cambiar la capacidad predeterminada (1) a 2.
Entonces demoramos un tiempo que se encuentra en la expresión Tech Time, que no hemos
definido. Después de la demora, el recurso Tech 1 se libera y la llamada completa se envía a
la parte de salida de nuestro modelo.
Name (Nombre) Unstore from Tech Call (Desalmacenar la llamada técnica)

Recording Delay (Demora de grabación)
Pantalla 5-16. Remoción de la entidad del almacenamiento
Name (Nombre) Determine Product Type (Determinar el tipo de

producto)
Type (Tipo) N-way by Chance (N vías por probabilidad)
Percentages (Porcentajes) 25
34
Pantalla 5-17. Determinación del tipo de producto de soporte técnico

Name (Nombre) Process Product Type 1 (Proceso

del tipo de producto 1)
Tech Call (Llamada técnica)
Action (Acción) Seize Delay Release (Tomar Demorar
Liberar)
Resource Name (Nombre del recurso) Tech 1
Expression (Expresión) Tech Time (Tiempo técnico)
Pantalla 5-18. Módulo proceso de llamada de soporte técnico para el tipo de producto 1
Figura 5-5. El módulo de datos Expression (Expresión)
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.
5.4.4 Llamadas de ventas

Las llamadas de ventas de nuestro módulo Decide (Decidir), de la sección 5.4.1, se envían a esta
sección de nuestro modelo. La lógica para las llamadas de ventas es muy similar a la descrita
para las llamadas de soporte técnico. Sin embargo, se requieren mucho menos módulos (de he-
cho sólo dos) ya que no tenemos las complejidades de tipos de productos múltiples y diferentes
recursos. Los pasos lógicos que se necesitan para las llamadas de ventas se muestran aquí y los
módulos de diagrama de flujo en la figura 5-6.
Assign entity type and picture (Asignar tipo e imagen de la entidad)
Seize sales call resource (Tomar el recurso de llamada de ventas)
Delay for service (Demora por servicio)
Release sales call resource (Liberar el recurso de llamada de ventas)
214 Capítulo 5
"TJHOBSUJQPFJNBHFO --BNBEBEF
EFMBFOUJEBEEF WFOUBTFO
MMBNBEBEFWFOUBT QSPDFTP
Figura 5-6. Lógica de llamada de ventas
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.
5.4.5 Llamadas de estado del pedido

Las llamadas de estado del pedido se manejan de forma automática, por lo menos al principio;
no requieren otro recurso que una unidad de Trunk Line (Línea Troncal). Los pasos
lógicos para las llamadas de estado del pedido son:
Name (Nombre) Assign Sales Call Entity Type and Picture

(Asignar tipo e imagen de entidad a la
llamada de ventas)
Assignments (Asignaciones)
Entity Type (Tipo de entidad) Sales Call (Llamada de ventas)
Type (Tipo) Entity Picture (Imagen de la entidad)
Entity Picture (Imagen de entidad) Picture.Green Ball (Imagen.Bola verde)
Pantalla 5-19. Asignar tipo e imagen de entidad a la llamada de ventas
Name (Nombre) Process Sales Call (Proceso llamada de

ventas)
Action (Acción) Seize Delay Release (Tomar Demorar
Liberar)
Resource Name (Nombre del recurso) Sales (Ventas)
Delay Type (Tipo de demora) Triangular
Minimum (Mínimo) 4
Most likely (Más parecido) 15
Pantalla 5-20. El módulo Process (proceso) llamada de ventas

Assign entity type and picture (Asignar tipo e imagen de entidad)

Delay for automated call (Demora para llamada automática)
If customer wants to speak to a real person (Si el cliente quiere
hablar con un operador telefónico)
Set customer priority (Configurar prioridad del cliente)
Seize sales person (Tomar empleado de ventas)
Delay for call (Demora para llamada)
Release sales person (Liberar empleado de ventas)
La lógica de Arena se muestra en la figura 5-7.

La llamada entrante de estado del pedido se envía a un módulo Assign (Asignar) (pantalla
5-21) donde le asignamos el Type (Tipo) de entidad a Order Status Call (Llamada de
estado del pedido), y la Entity Picture (Imagen de entidad) a Picture.Blue Ball
(Imagen.Bola azul).
Las llamadas de estado del pedido se manejan de forma automática por el sistema de teléfono,
lo que significa que inicialmente incurren en una demora como las llamadas que llegan y las de
soporte técnico. Como con las primeras dos demoras, queremos mostrar la llamada en la anima-
ción así que podríamos usar una combinación de módulos Store-Delay-Unstore (Almacenar-De-
morar-Desalmacenar) como hicimos para las primeras dos demoras. Pero esta vez tomemos un
enfoque diferente y usemos un módulo Delay (Demorar) del panel Blocks (Bloques). Al usar este
módulo, podemos capturar la misma funcionalidad que con la combinación de módulos previa ya
7FSEBEFSP
"TJHOBSUJQPF
y/PTFSFRVJFSFB
JNBHFOEFFOUJEBE %FNPSB
OJOHÙOFNQMFBEP
EFFTUBEPEFPSEFO
EFWFOUBT
53*"
'BMTP
$POGJHVSBS 5PNBSFNQMFBEPEF %FNPSBEFMB -BMMBNBEBEF

WFOUBTQBSBMB DPOWFSTJÓOEVSBOUF FTUBEPEFQFEJEP
QSJPSJEBEEFMB
MBMMBNBEBEF MJCFSBBMFNQMFBEP
MMBNBEBEFFTUBEP MMBNBEBEFFTUBEP
FTUBEPEFQFEJEP
EFMQFEJEP EFMQFEJEP EFWFOUBT
DPOFMFNQMFBEPEF
WFOUBT
Figura 5-7. La lógica del proceso de llamadas de estado del pedido
Name (Nombre) Assign Order Status Entity Type and Picture

(Asignar tipo e imagen de la entidad al
estado del pedido
Entity Type (Tipo de entidad) Order Status Call (Llamada de estado del
pedido)
Type (Tipo) Entity Picture (Imagen de entidad)
Entity Picture (Imagen de entidad) Picture.Blue Ball (Imagen.Bola azul)
Pantalla 5-21. Asignar tipo e imagen de entidad a la llamada de estado del pedido
216 Capítulo 5
Label (Etiqueta) Order Status Delay (Demora de estado del pedido)

Duration (Duración) TRIA(2, 3, 4)
Storage ID (Identificación Order Status Delay Storage (Almacenamiento de la
de Almacenamiento) demora del estado del pedido)
Pantalla 5-22. El módulo Delay (Demorar) del panel Blocks (bloques)
que contiene implícita la lógica Store/Unstore (Almacenar/Desalmacenar). La entidad se coloca-

rá en Almacenamiento definido, incurrirá en una demora y luego se retirará del Almacenamiento.
Hicimos entradas para Label [Etiqueta] (igual que para Name [Nombre]), Duration (Duración),
y Storage ID (Identificación de Almacenamiento), como se presenta en la pantalla 5-22.
Note que cuando hace clic en el módulo Delay (Demorar) no se asocia con la vista de hoja
de cálculo; éste será el caso para cualquier módulo de los paneles Blocks (Bloques) o Elements
(Elementos). Cuando use módulos del panel Blocks (Bloques), también debe estar consciente
de qué unidades de tiempo base (Base Time Units) especificó en el diálogo Run > Setup > Re-
plication Parameters (Ejecutar > Configurar > Parámetros de réplica), y asegurarse de que las
unidades de cualquier valor de tiempo (por ejemplo, la Duration [Duración] en nuestro módulo
Delay [Demorar]) sean las mismas. En nuestro modelo, hemos especificado minutos, así que
somos consistentes. Si ha elegido usar el módulo Delay (Demorar) del panel Advanced Process
(Proceso avanzado), debería haber incluido una entrada para las unidades de tiempo. Cuando
empleamos el módulo Store (Almacenar) para colocar una entidad en un Almacenamiento,
Arena de forma automática introdujo el nombre del Almacenamiento en el módulo de datos
Storage (Almacenamiento) (panel Advanced Process [Proceso avanzado]). Ése no es el caso de
un módulo Delay (Demorar) del panel Blocks (Bloques). Así que ahora tendrá que hacer clic
en el módulo de datos Storage (Almacenamiento) e introducir su nombre, Order Status
Delay Storage (Almacenamiento de demora de estado del pedido).
Name (Nombre) No Sales Person Required? (¿No se

requiere un empleado de ventas?)
Type (Tipo) 2-way by Chance (2 vías por probabilidad)
Percentage True (Porcentaje verdadero) 85
Pantalla 5-23. Determinación de si se requiere un empleado de ventas para

una llamada de estado del pedido
Habiendo completado la demora, la entidad entra a un módulo Decide (Decidir), en la

pantalla 5-23, donde se decide si es necesario conectar a un operador telefónico de ventas. Si no
hace falta, la entidad se envía a la salida del sistema; de otro modo, hay que tomar a un emplea-
do de ventas para completar la llamada. Nosotros de forma arbitraria decidimos que “Verdade-
ro” significa que en verdad es el caso en que no se requiere un empleado de ventas (por lo tanto
el módulo Name [Nombre] y la entrada 85 para Percent True [Porcentaje verdadero]).
En la descripción de nuestro problema inicial, indicamos que las llamadas de estado del
pedido se enrutan al personal de llamadas donde esperarán con una prioridad más baja que
las llamadas de ventas. Esto significa que si una llamada de estado del pedido se encuentra en
una cola esperando a un empleado de ventas y entra una llamada nueva de ventas, a ésta se le
dará prioridad sobre la llamada de estado del pedido y será contestada primero (aunque la nue-
va llamada de ventas no se haya adelantado a una llamada de estado del pedido que ya pueda
estar en progreso). En este punto, para encontrar una solución a nuestro problema, necesitamos
desviarnos del tema y explicar de qué manera Arena asigna recursos a entidades en espera.
Esperamos que por ahora este proceso de asignación sea bastante claro cuando todas las en-
tidades que quieran un recurso están ubicadas en una misma cola y tienen la misma prioridad.
Sin embargo, si hay varios lugares dentro de un modelo (combinaciones diferentes de Cola-
Tomar) donde puede asignarse el mismo recurso, se aplican algunas reglas especiales. Primero
consideremos varias circunstancias bajo las cuales puede asignarse un recurso a una entidad:
< una entidad pide un recurso y el recurso está disponible,
< un recurso queda disponible y hay entidades que lo piden en sólo una de las colas, o
< un recurso queda disponible y hay entidades que piden el recurso en más de una cola.
Esto puede ser más obvio que lo que ocurre bajo los primeros dos escenarios, pero aún así
lo trataremos.
Si una entidad pide un recurso y éste se encuentra disponible, espera a ver si el recurso se asig-
na a la entidad. En nuestro segundo caso, cuando un recurso queda disponible y hay entidades
en sólo una de las colas, entonces el recurso es asignado a una entidad de esa cola. Aquí el factor
determinante para qué entidad en la cola obtiene el recurso es la regla de clasificación de cola que
se usa para ordenar las entidades. Arena proporciona cuatro opciones de clasificación: Primeras
llegadas Primeras salidas (FIFO, por sus siglas en inglés), Últimas llegadas Primeras salidas
(LIFO, por sus siglas en inglés), Primero el valor más bajo (Low Value First), y Primero el valor
más alto (High Value First). El determinado, FIFO, clasifica las entidades en el orden en que
entran a la cola, así la entidad que lleva en la cola más tiempo obtendría el recurso. LIFO coloca
la llegada más reciente al frente de la cola (como un montón empujar/meter [push/pop]), así la
entidad que se unió más recientemente a la cola obtendría el recurso. Las últimas dos reglas cla-
sifican la cola con base en el valor de un atributo de las entidades que hay en ella; le corresponde
a cada quien definir una expresión para tal atributo. Por ejemplo, conforme cada entidad llega al
sistema, se debe asignar un dato apropiado a un atributo de esa entidad. Si seleccionó “Primero
el valor más bajo”, con base en este atributo de datos apropiados, tendría el equivalente de una
regla de clasificación de colas de primeros datos apropiados. Conforme llega cada entidad a la
cola, ésta se coloca en posición con base en incrementar los datos adecuados.
El último caso, donde las entidades en más de una cola piden el recurso, es un poco más
complicado. Arena revisa primero las prioridades de tomar: si una de estas prioridades es un
número más pequeño (mayor prioridad) que el resto, el recurso se asigna a la primera enti-
dad en la cola precediendo a esa toma. Podríamos utilizar este método y regresar al módulo
218 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-
Label (Etiqueta) Set Order Status Call Priority (Configurar

prioridad de llamada de estado del pedido)
Attribute Name (Nombre del Sales Call Priority (Prioridad de llamada de
atributo) ventas)
Pantalla 5-24. Asignación de la prioridad de llamada

Name (Nombre) Order Status Call Seizes Sales Person

(Llamada de estado del pedido toma
persona de ventas)
Resource Name (Nombre del recurso) Sales (Ventas)
Queue Name (Nombre de la cola) Process Sales Call.Queue
Pantalla 5-25. Módulo Seize (Tomar) del estado del pedido
tado del pedido con un valor de 1. A continuación enviaremos la entidad a un módulo

Seize (Tomar). Se podrá preguntar por qué estamos usando un módulo Seize (Tomar) en lugar
de un Process (Proceso). Esto provoca que si usamos un módulo Process (Proceso), el nom-
bre de la cola predeterminado será “nombre de módulo” con una extensión “.cola”, que no
se puede cambiar. Puesto que queremos usar la misma cola que se definió para la toma de las
llamadas de ventas, en su lugar necesitamos usar un módulo Seize (Tomar), que nos permite
cambiar el nombre predeterminado de la cola.
Nosotros hacemos de esta cola una compartida, primero al colocar y llenar el módulo Seize
(Tomar) y luego al seleccionar el nombre de la cola, Process Sales Call.Queue, de la
lista de sugerencias, como se presenta en la pantalla 5-25.
Una vez que se complete, irá al panel Basic Process (Proceso básico) y abrirá el módulo
de datos Queue (Cola). Su cola ya estará en la vista de la hoja de cálculo, y ahora tendrá
que revisar la caja Shared (Compartido) para dejarla disponible como una cola compartida.
Después, haga clic en la celda Type (Tipo) para nuestra cola y seleccione la opción Lowest
Attribute Value (Atributo del menor valor). Esto le permite seleccionar un
atributo de la lista de sugerencias en la celda Attribute Name (Nombre de atributo). Puede
seleccionar el Attribute Name (Nombre de atributo) Sales Call Priority (Priori-
dad de llamada de ventas).
Ahora, tanto las entidades de llamada de ventas como de llamada de estado del pedido se
ubicarán en la misma cola. Puesto que las entidades de llamada de ventas tienen una prioridad 0,
a ellas siempre se les asignará primero un recurso de ventas disponible. A la entidad de la llamada
de orden del pedido sólo se le asignará un recurso disponible si no hay entidades de llamada de
ventas actualmente en la cola. Esto resuelve nuestro problema de asignación del recurso.
Después de tomar un recurso Sales (Ventas), la entidad entra a un módulo Delay (Demo-
rar), como se presenta en la pantalla 5-26, con una demora de TRIA(3, 5, 10) minutos.
Name (Nombre) Delay for Order Status Conversation With Sales

Person (Demora de la conversación del estado del
pedido con la persona de ventas)
Delay Time (Tiempo de TRIA(2, 3, 4)
demora)
Pantalla 5-26. La demora de las ventas de estado del pedido

220 Capítulo 5
Name (Nombre) Order Status Call Releases Sales Person (Llamada de

estado del pedido libera a empleado de ventas)
Resource Name (Nombre Sales (Ventas)
del recurso)
Pantalla 5-27. Liberación del recurso ventas del estado del pedido
A continuación se envía a un módulo Release (Liberar) (Advanced Process panel [panel de

Proceso avanzado]) donde liberamos el recurso de ventas, presentado en la pantalla 5-27.
Después de liberar el recurso de ventas, la entidad se envía a la salida del sistema.
5.4.6 Salida del sistema y configuración de ejecución

Al haber completado su misión de vida, todas las llamadas de las secciones de soporte técnico,
ventas y estado del pedido se envían a esta parte de nuestro modelo. Aquí se muestran los pasos
lógicos y los módulos de diagramas de flujo aparecen en la figura 5-8:
Release Trunk Line (Liberar línea troncal)
Decrement active call counter (Disminuir contador de llamada activa)
Record completed calls (Grabar llamadas completas)
Dispose of entitiy (Disponer de la entidad)
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
-JCFSBSMÎOFB %JTNJOVJS (SBCBS %JTQPOFSEF

QSJODJQBM DPOUBEPSEF MMBNBEBT MBFOUJEBE
MMBNBEBBDUJWB DPNQMFUBT
Figura 5-8. La lógica de salida del sistema

Name (Nombre) Release Trunk Line (Liberar línea

principal)
Resource Name (Nombre del recurso) Trunk Line (Línea troncal)
Pantalla 5-28. Liberación del recurso línea principal
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
Name (Nombre) Decrement Active Call Counter (Disminuir

contador de llamada activa)
Type (Tipo) Variable
Variable (Variable) Total WIP
New Value (Valor nuevo) Total WIP – 1
Pantalla 5-29. Disminución del contador de llamada activa
Name (Nombre) Record Completed Calls (Grabar llamadas

completas)
Counter Name (Nombre del contador) Completed Calls (Llamadas completas)
Pantalla 5-30. Grabar las llamadas completas

222 Capítulo 5
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.
Figura 5-9. Animación sencilla del sistema de un centro de llamadas
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.
Identifier (Identificador) Initial Recording Delay Storage (Almacenamiento de

demora de grabación inicial)
Pantalla 5-31. Animación de Almacenamiento

224 Capítulo 5
Figura 5-10. Adición de puntos de toma múltiples
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
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.
5.5 Modelo 5-2: sistema mejorado del centro de atención telefónica

Al desarrollar modelos para sistemas reales, querrá mantener su modelo tan simple como se
pueda y hasta que ese modelo capte de forma precisa el comportamiento de los sistemas. Nues-
tro objetivo final es usar nuestro modelo para encontrar la forma más rentable con el fin de in-
crementar nuestro nivel de servicio o satisfacción del cliente. Quisiéramos considerar el impacto
de tales cambios así como el de aumentar el número de líneas principales o el de transformar
nuestros niveles de personal. Aunque nuestro modelo actual nos permitiría captar tales cam-
bios, carece de detalle. Así visitemos de nuevo nuestra descripción del problema y determine-
mos dónde necesitamos añadir más detalles.
5.5.1 Descripción del nuevo problema

Comencemos con una evaluación más detallada de las llegadas de llamadas. El índice de
llegada de llamada para este sistema de hecho varía en el transcurso del día de acuerdo con
un proceso Poisson no estacionario (véase la sección 12.3), que es típico de estos tipos de
sistemas. Así que debemos recopilar los datos expresados en llamadas por hora para cada
periodo de 30 minutos mientras el sistema está abierto. Estos índices de llegada de llamada
se dan en la tabla 5-2.
226 Capítulo 5
Tabla 5-2. Razón de llegada de llamadas (llamadas por hora)
Tiempo Razón Tiempo Razón Tiempo Razón Tiempo Razón

8:00-8:30 20 10:30-11:00 75 1:00-1:30 110 3:30-4:00 90
8:30-9:00 35 11:00-11:30 75 1:30-2:00 95 4:00-4:30 70
9:00-9:30 45 11:30-12:00 90 2:00-2:30 105 4:30-5:00 65
9:30-10:00 50 12:00-12:30 95 2:30-3:00 90 5:00-5:30 45
10:00-10:30 70 12:30-1:00 105 3:00-3:30 85 5:30-6:00 30
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-
Tabla 5-3. Programas de soporte técnico
Líneas de Periodo de tiempo (30 minutos)

Nombre
producto 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Charity 1 • • • • • • • • • • • • • • • •
Noah 1 • • • • • • • • • • • • • • • •
Molly 1, 3 • • • • • • • • • • • • • • • •
Anna 1, 2, 3 • • • • • • • • • • • • • • • •
Sammy 1, 2, 3 • • • • • • • • • • • • • • • •
Tierney 2 • • • • • • • • • • • • • • • •
Aidan 2 • • • • • • • • • • • • • • • •
Emma 2 • • • • • • • • • • • • • • • •
Shelley 3 • • • • • • • • • • • • • • • •
Jenny 3 • • • • • • • • • • • • • • • •
Christie 3 • • • • • • • • • • • • • • • •
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.
5.5.2 Conceptos nuevos

Nuestro modelo mejorado requiere dos conceptos nuevos. El primero es el proceso de llegada
cuya razón varía con el tiempo. El segundo concepto muestra que cuando una llamada intenta
tomar una unidad de recurso de personal técnico, está realmente tratando de tomar un recurso
de un fondo común o conjunto de recursos calificados para manejar la llamada. Analicemos
cada uno de estos conceptos nuevos antes de construir nuestro modelo.
Comenzaremos con el proceso de llegada, que tiene una razón que varía con el tiempo.
Este tipo de proceso de llegada es bastante típico en sistemas de servicio y requiere un enfo-
que diferente. Las llegadas en muchos sistemas se modelan como un proceso Poisson estacio-
nario en el que aquéllas ocurren una a la vez, son independientes unas de otras, y la razón
promedio es constante en el tiempo. Para quienes no son grandes aficionados a la probabili-
dad, esto implica que tenemos tiempos entre llegadas que son exponenciales con una media
fija. El lector puede no haberse dado cuenta, pero éste es el proceso que usamos para modelar
llegadas en nuestros modelos anteriores (con la excepción del modelo 4-5, que fue artificial
para ilustrar un punto en particular). Hubo una ligera variación de lo que se usó para las
llegadas de la parte B en los modelos 4-1 al 4-4, donde supusimos que una llegada era un lote
de cuatro; por tanto, nuestras llegadas siguieron ocurriendo en un lote a la vez, de acuerdo
con el proceso Poisson estacionario.
Para este modelo, la razón de llegada media es una función de tiempo. Estos tipos de lle-
gadas usualmente son modelados como un proceso Poisson no estacionario. Un enfoque de
modelación obvio, pero incorrecto, sería introducir una distribución exponencial en el módulo
Create (Crear) para Time Between Arrivals (Tiempo Entre Llegadas), con una variable definida
por el usuario como un Value (Valor) medio, entonces cambiar este valor con base en el índice
para el periodo de tiempo actual. Para nuestro ejemplo, cambiaríamos este Value (Valor) cada
30 minutos. Lo que daría una solución aproximada si el cambio de la razón entre los periodos
fuera aún pequeño. Pero si la razón de cambio es grande, tal método dará resultados muy enga-
ñosos (y erróneos). La forma más fácil de ilustrar el problema potencial es considerar un ejem-
plo extremo. Digamos que tenemos sólo dos periodos, cada uno de 30 minutos de duración.
La razón de llegadas del primer periodo es 3 (llegadas promedio por hora), o una media
de tiempo entre llegadas de 20 minutos, y la razón para el segundo periodo es 60, o una
media de tiempo entre llegadas de 1 minuto. Supongamos que la última llegada en el primer
periodo de tiempo ocurrió en el tiempo 29 minutos. Generaríamos la siguiente llegada al usar
un Value (Valor) medio de tiempo entre llegadas de 20 minutos. Al usar una distribución ex-
228 Capítulo 5
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.
Figura 5-11. El editor gráfico de programas de eventos: el programa de Charity
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.
5.5.3 Definición de datos

En nuestro primer modelo, tuvimos un total de cinco recursos (uno para las 26 líneas troncales,
uno para el personal de ventas, y tres para el personal de soporte técnico). En nuestro nuevo
modelo, tendremos un total de 13 recursos (uno para las 26 líneas principales, uno para el
personal de ventas y los 11 restantes para el personal de soporte técnico individual). Todos,
excepto el de las líneas principales, siguen un programa (analizamos los programas en la sec-
ción 4.2.2). Definimos un programa por separado para cada uno de los recursos; sin embargo,
como varios miembros del personal de soporte técnico siguen el mismo programa (por ejem-
plo, Charity, Tierney y Shelly), simplemente puede volver a usar un solo programa (aunque
hacerlo haría que su modelo fuera menos flexible en términos de posibles cambios futuros). Al
desarrollar los programas para el personal de soporte técnico, empleamos el Graphical Sche-
dule Editor (Editor gráfico de programas de eventos), configuramos las ranuras del número de
tiempo en 22, y la capacidad máxima en el eje y de la gráfica en dos (podemos hacerlo en uno)
en el diálogo Options (Opciones). El programa de Charity se muestra en la figura 5-11.
Si está construyendo este modelo con nosotros, asegúrese que cada programa cubra por com-
pleto los 660 minutos de cada día, de 8 a.m. a 7 p.m. (22 periodos de tiempo de media hora), aun
si debe llenar muchos ceros al principio o final (como hicimos al final con Charity). Aunque el
programa mostrado en la figura 5-11 puede parecer que cubre por completo los 660 minutos, en
realidad sólo cubre los primeros 17 periodos de tiempo (a partir de las 8:30 como se muestra en la
figura 5-11). El editor gráfico de programas de eventos no asume que cada programa cubre un día
(pueden ser de cualquier duración). En este caso, el programa comenzaría desde cero en el perio-
do de tiempo 18, que es sólo 8.5 horas en el día de 11 horas. Nosotros podemos revisar la caja bajo
el botón Options (Opciones) para “Mantenerse en capacidad al final del programa”, y configurar
230 Capítulo 5
Figura 5-12. Ventana de hoja de cálculo Durations (Duraciones)
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:
Value (Valor) 0
Pantalla 5-32. Diálogo Durations (Duraciones)
Producto 1: Charity, Noah, Molly, Anna, Sammy

Producto 2: Tierney, Aidan, Emma, Anna, Sammy
Producto 3: Shelley, Jenny, Christie, Molly, Anna, Sammy
Los contenidos de estos conjuntos corresponden al personal técnico calificado para manejar
las llamadas para cada tipo de producto. Note que Molly, Anna y Sammy están incluidos en
más de un conjunto. También observe que consistentemente enlistamos estos tres miembros
versátiles del personal al final de cada conjunto por una razón deliberada. Por ejemplo, tome el
conjunto del producto 1, que consiste en Charity, Noah, Molly, Anna y Sammy, en ese orden. Si
es posible, quisiéramos asignar a Charity o Noah a una llamada que entra primero porque ellos
sólo pueden manejar llamadas del producto Tipo 1. Usaremos la regla de selección Preferred
Order (Orden preferido) que asigna recursos con base en su orden en el conjunto, comenzando
con el primero (Charity). En nuestro modelo, esto intentará mantener a Molly, Anna y Sammy
disponibles ya que ellos también pueden manejar otros tipos de producto.
Figura 5-13. Ventana de hoja de cálculo Resources (Recursos)

232 Capítulo 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).
5.5.4 Modificación del modelo

Modificaremos el modelo 5-1 que creamos antes para desarrollar nuestro nuevo modelo 5-2.
Ya hemos cubierto casi todos los conceptos necesarios contenidos en estos módulos, así que
Figura 5-15. Ventana de hoja de cálculo Statistic (Estadística) de los contadores
Figura 5-16. Ventana de hoja de cálculo Set (Conjunto)
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)
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)
Pantalla 5-33. Conteo de llamadas rechazadas por periodo de una hora
representa el periodo actual con base en el tiempo de ejecución de la simulación, en la pantalla

5-33; para entender cómo funciona esta expresión, note que TNOW es el valor interno del reloj
de simulación de Arena (en minutos), AINT es una función ya construida en Arena que trunca
su argumento de número real hacia cero y “juega a la computadora” durante algunos valores de
minutos de TNOW.
Ahora procedamos a los cambios que hicimos en la sección Tech Support Calls (Llamadas
de soporte técnico) de nuestro modelo. Los primeros cinco módulos (hasta el módulo Decide
[Decidir] Determine Product Type [Determinar tipo de producto] e incluyéndo-
lo) permanecen igual que en modelo 5-1. Guiaremos al lector por los cambios que se requieren
para el producto tipo 1 de soporte técnico y lo mandaremos al archivo Model 05-02.doe para
las diferencias de los otros dos tipos de llamadas de soporte técnico.
Directamente después del módulo Decide (Decidir) Determine Product Type (De-
terminar tipo de producto), insertamos un módulo Assign (Asignar) en donde hicimos
tres tareas. Primero asignamos un nuevo tipo de entidad y una imagen de entidad de manera
que pudiéramos distinguir la diferencia entre las llamadas para diferentes tipos de producto
tanto en la animación como en los reportes. También definimos un nuevo atributo llamado
Tech Call Type (Tipo de llamada técnica), al que se le asigna un valor integral de 1, 2
o 3, dependiendo del tipo de producto. Pronto verá por qué necesitamos este nuevo atributo.
El siguiente módulo Process (Proceso) es el mismo con la excepción de la información en la
sección Resources (Recursos). Puesto que reemplazamos el único recurso, Tech 1 (Técnico 1),
en el modelo 5-1 con el conjunto de recursos Product 1 (Producto 1), necesitamos modificar
esta sección. Cambiamos el Type a Set (Conjunto) y metemos el Product 1 (Producto 1)
en el Set Name (Nombre del conjunto). Seleccionamos Preferred Order (Orden prefe-
rido) para la Selection Rule (Regla de selección) y definimos un nuevo atributo, Tech Agent
Index (Índice de agente técnico), para el campo Save Attribute (Guardar atributo).
Cuando definimos nuestros conjuntos de recursos, enlistamos consistentemente a los miembros
del personal más versátiles al final de cada conjunto. Recuerde que este conjunto consiste en Cha-
rity, Noah, Molly, Anna y Sammy, en ese orden; note que colocamos a Molly, Anna y Sammy
como los últimos recursos en el conjunto. De esta manera, si es posible, nos gustaría colocar pri-
mero a Charity y Noah en una llamada entrante porque ellos sólo pueden manejar las llamadas
de tipo 1. La regla de selección de Orden preferido coloca recursos según su orden en el conjunto,
si es que hay una elección entre los múltiples recursos desocupados, comenzando con el prime-
ro (Charity). En nuestro modelo, esto intentará mantener a Molly, Anna y Sammy disponibles;
recuerde que ellos también pueden manejar otros tipos de llamadas. También almacenamos el
-JCFSBDJÓOEFMÎOFB
QBSBMBJOWFTUJHBDJÓO
"VNFOUBSMB
%FNPSB WBSJBCMF8*1
FOMPTSFHJTUSPTEF
MBPGJDJOB EFEFWPMVDJÓO
5PNBSBHFOUF -MBNBEB -JCFSBSBHFOUF

y5JQPEF UFDOPMÓHJDPUJQP SFHSFTBEBUJQP UFDOPMÓHJDPUJQP
QSPEVDUP

0USP %JTNJOVJSMB
WBSJBCMF8*1EF
y*OWFTUJHBDJÓOFO 5JQPEFQSPEVDUP5FDI$ UFDOPMÓHJDPUJQP SFHSFTBEBUJQP UFDOPMÓHJDPUJQP MMBNBEBUÊDOJDB
MBPGJDJOBEFBQPZP 5JQPEFQSPEVDUP5FDI$ EFWVFMUB
ZEFWPMVDJPOEF 7FSEBEFSP

MMBNBEB
'BMTP UFDOPMÓHJDPUJQP SFHSFTBEBUJQP UFDOPMÓHJDPUJQP

Figura 5-17. La sección de devolución de llamadas técnicas
í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.
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
Figura 5-18. Animación del modelo 5-2
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:
Todo el personal de ventas: 45 horas al día × 20 dólares la hora × 5 días a la semana

= 4 500 dólares por semana
Personal de soporte técnico:
8 personas × (8 horas al día) / persona × 18 dólares la hora × 5 días a la semana
1 persona × (8 horas al día) / persona × 20 dólares la hora × 5 días a la semana
= 800 dólares por semana
2 personas × (8 horas al día) / persona × 22 dólares la hora × 5 días a la semana
Sumando, obtenemos un costo de nómina semanal actual de 12 820 dólares.
Para intentar mejorar el servicio, ahora generalizamos el modelo para incluir personal adi-
cional. Observando las cuentas por hora de los lotes con señal de ocupado del modelo 5-2,
parece que los déficit de personal más severos acontecen entre mediodía y las 4:00 p.m., así que
crearemos la habilidad en el modelo para añadir tanto ventas como soporte técnico durante ese
periodo de cuatro horas, que corresponde a los periodos de cuatro horas de duración del 5 al 8.
Name (Nombre) Sales Schedule (Programa de ventas)

Type (Tipo) Capacity (Capacidad)
Time Units (Unidades de tiempo) Halfhours (Medias horas)
Value (Capacity), Duration (Valor [Capacidad], Duración) 1, 2
Value (Capacity), Duration (Valor [Capacidad], Duración) 5 + New Sales (Ventas nuevas), 1
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-
Name (Nombre) Larry Schedule (Programa de Larry)

Type (Tipo) Capacity (Capacidad)
Time Units (Unidades de tiempo) Halfhours (Medias horas)
Value (Capacity), Duration (Valor [Capacidad], Duración) New Tech 1,8 (Nuevo técnico 1,8)
Pantalla 5-35. El diálogo Larry Schedule (Programa de Larry) del modelo 5-3
Name (Nombre) New Res Cost (Nuevo costo del recurso)

Expression Value (Valor New Sales (Ventas nuevas)*340
de la expresión) + (New Tech 1 + New Tech 2 + New Tech 3)*320
[+ (Nuevo técnico 1 + Nuevo técnico 2 + Nuevo técnico 3)*320
+ New Tech All*360 [(+ Todos los nuevos técnicos)*360]
+ 98*MR (Trunk Line) (+ 98*MR [Línea principal])
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)
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,
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
Opción 3: Iniciar el sistema (no), Iniciar Statistics (sí)

Esto dará como resultado cinco ejecuciones, la primera comenzando en un tiempo 0, la se-
gunda en el tiempo que se complete la primera (recuerde que estamos usando una regla de
detención para terminar una réplica), la tercera en el tiempo que se complete la segunda, etc.
Puesto que el sistema no se inicia entre las réplicas, el tiempo continúa avanzando y cualquier
llamada de soporte técnico que no se devuelva se aplazará al siguiente día. Los reportes con-
tendrán sólo las estadísticas para una sola réplica o día, en lugar de ser acumulativos.
Opción 4: Iniciar el sistema (no), Iniciar Statistics (no)
Esto dará como resultado cinco ejecuciones, la primera comenzando en un tiempo 0, la
segunda cuando se complete la primera, la tercera cuando se complete la segunda, etc. Pues-
to que el sistema no se inicia entre las réplicas, el tiempo continúa avanzando y cualquier
llamada de soporte técnico que se devuelva se aplazará hasta el siguiente día. Los reportes
serán acumulativos.
Idealmente, nos gustaría seleccionar ya sea la opción 3 o la 4 puesto que quisiéramos aplazar
todas las llamadas técnicas no devueltas hasta el siguiente día. Sin embargo, esto nos requeriría
cambiar nuestra regla de detención y dejar que cada réplica se ejecute por 660 minutos. Así que
por ahora sólo aceptemos la predeterminada (opción 1).
Conforme ha avanzado a través del análisis en esta sección, probablemente habrá pensado
en otras formas de lograr muchas de las cosas que hicimos. Habría sido posible, por ejemplo,
explotar las capacidades de costo ya incluidas en Arena de forma más completa en lugar de
hacerlo por nuestra cuenta, y haber hecho los parámetros del modelo de forma diferente con
sólo los valores de entrada “primitivos” como tasas de sueldos y el número de empleados. O
podríamos haber dejado que Arena realizara de forma interna algunos de los cálculos que
nosotros hicimos por nuestra cuenta en pequeñas calculadoras. Todo eso es cierto, pero tam-
bién nos habría tomado más tiempo y esfuerzo llevarlo a cabo así. Ésta es una forma típica de
llamada de atención que deberá hacer cuando construya un modelo: intercambiar el tiempo
de construcción de su modelo por la generalidad (y quizá elegancia) del mismo, por lo común
siendo guiado por quien usará el modelo y para lo que lo usará. La configuración de este mo-
delo será útil en el siguiente capítulo, en donde le mostramos varias capacidades de Arena en la
importante actividad del análisis estadístico de los datos de salida de la simulación.
Ejecutamos el modelo en lo que podría llamarse el “caso base”, sin empleados o líneas prin-
cipales adicionales (es decir, New Sales, New Tech 1, New Tech 2, New Tech 3 y New
Tech All se establecieron en 0 y el número de líneas adicionales en 26). El Total Cost resulta
ser de 22 500.07 dólares por una semana y 12.9% de las llamadas entrantes obtuvieron un tono de
ocupado. Puesto que este porcentaje de llamadas rechazadas está por encima de nuestro 5% obje-
tivo, hicimos otra ejecución en donde aumentamos en 3 cada una de las seis variables de “control”
del recurso de entrada (esto es, New Sales, New Tech 1, New Tech 2, New Tech 3 y New
Tech All se establecieron en 3 y el número de líneas principales en 29); esto produjo un Total
Cost de 23 668.69 dólares con sólo 1.6049% de llamadas entrantes que obtuvieron un tono de
ocupado; evidentemente, el costo de contratar personal extra y añadir tres líneas principales no es
una inversión inteligente si vemos sólo el Total Cost. Pero sí reduce el porcentaje de llamadas
balked (que renunciaron) a un nivel aceptable. Sin embargo, debería sentirse inseguro con respec-
to a los “análisis” (que hacemos), puesto que cada resultado proviene de sólo cinco réplicas. No
sabemos si los resultados que buscamos sólo son límites aleatorios, si podríamos decir confiada-
mente que la segunda configuración es mejor, cómo elegiríamos confiadamente el ideal de entre
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.
5.7 Modelo 5-4: simulación de inventario (s, S)

Cerramos este capítulo considerando una clase completamente diferente de sistema, un inventa-
rio, para indicar cómo tales operaciones pueden modelarse e ilustrar la amplitud de la simulación
en general y de Arena en particular (no es sólo para los modelos de tipo hacer cola3). Empleare-
mos módulos sólo de los paneles Bloques y Elementos, principalmente para demostrar su uso y
hacerlo consciente de que están ahí por si los necesita (así que, en efecto, usamos el lenguaje de
simulación SIMAN); en el ejercicio 5-17 le pedimos recrear este modelo, al usar construcciones
de modelación de un nivel más alto de los paneles de Procesos básicos y Procesos avanzados. Tal
modelo es esencialmente el mismo que el de la sección 1.5 de Law y Kelton (2000).
5.7.1 Descripción del sistema

Widgets by Bucky, una empresa de participación multinacional, lleva el inventario de una clase
de artículo (por supuesto, llamándose “Widgets” ellos fabrican trastos, que es lo que significa
dicha palabra en inglés). Los trastos son indivisibles, así que el nivel del inventario debe ser
siempre una integral, a la que denotaremos como I(t) en donde t es tiempo (en días) después del
inicio de la simulación. Al inicio, hay 60 trastos a mano: I(0) = 60.
Los clientes arriban con tiempos entre llegadas distribuidos de forma exponencial con una
media de 0.1 día (es una operación de 24 horas), con una primera llegada que ocurre no en el
tiempo cero sino después de que uno de estos tiempos entre llegadas haya pasado aquél. Los
clientes exigen 1, 2, 3 o 4 trastos con sus respectivas probabilidades de 0.167, 0.333, 0.333 y
0.167. Si la demanda del cliente se puede satisfacer de un inventario disponible, el cliente obtie-
ne la demanda completa y se va feliz. Pero si el inventario disponible es menor que la demanda
del cliente, éste se lleva lo que sea que se encuentre a la mano (que podría ser nada), el resto de
la demanda se retrasa y el cliente vuelve después que el inventario haya sido llenado de forma
suficiente; a esto se le sigue un rastro colocando el nivel del inventario I(t) negativo, lo que no
tiene sentido físicamente pero que es un artificio de contabilidad conveniente. Los clientes con
artículos retrasados son infinitamente pacientes y nunca cancelan sus pedidos. Si el nivel de in-
ventario ya es negativo (esto es, ya estamos con un retraso) y llegan más clientes con demandas,
se hace más negativo. Específicamente no se le sigue el rastro a qué trastos que lleguen en el
futuro satisfarán a qué clientes con retrasos (también son infinitamente educados, así que eso
no les importa).
Al principio de cada día (incluyendo el tiempo cero, el principio del día 1), Bucky “hace un
inventario” para decidir si colocar un pedido con el abastecedor de trastos en ese momento. Si
el nivel de inventario (sea positivo o negativo) es (estrictamente) menor a la constante s (usare-
mos s = 20), Bucky ordena “hasta” otra constante S (usaremos S = 40). Lo que esto significa
es que ordena una cantidad de trastos de manera que, si llegan de forma instantánea, el nivel
de inventario aparecería exactamente en S. Así que si t es una integral y por lo tanto I(t) es el
nivel de inventario al inicio del día (podría ser positivo, negativo o cero) e I(t) < s, Bucky ordena
S − I(t) artículos; si I(t) ≥ s, Bucky no hace nada, deja que pase el día y verifica otra vez al inicio
del siguiente día, esto es, en el tiempo t + 1. Debido a la forma de esta política de revisión/lle-
nado, a menudo a los sistemas como éste se les llama modelos de inventario (s, S).
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
∫ 5 × máx (−I(t), 0)dt

0
(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
Modelo 5-4 de
inventario (s, S ) con
retraso
Figura 5-19. El modelo de inventario completo
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).
5.7.2 Modelo de simulación

Como mencionamos antes, construiremos este modelo usando sólo los módulos de los paneles
Blocks y Elements. Hubiera sido mucho más fácil hacer esto con módulos de un nivel más alto
(y menos antiguo) de los paneles de Basic Process y Advanced Process, pero le dejaremos la
alegría como ejercicio 5-17.
La figura 5-19 muestra el modelo completo, incluyendo la animación en el extremo superior
derecho. Los módulos de los paneles Blocks y Elements en la parte inferior se dividen en tres
secciones, como indican los cuadros esbozados detrás de los módulos.
Comencemos con la estructura de datos para el modelo. Los módulos en la sección baja de
la figura 5-19 provienen del panel Elements, así que se llaman a sí mismos elementos. Note que
no se encuentran conectados a nada, puesto que definen varios objetos para el modelo com-
pleto. Conforme pasamos por esto, ya estará familiarizado con muchos de los términos, puesto
que muchas de las construcciones y funciones en los niveles altos de Arena también se hallan
disponibles aquí.
El elemento Variables, que se muestra en su forma completa con la entrada para Inven-
tory Level (Nivel de inventario) visible en la figura 5-20, define e inicia opcionalmente
las variables de Arena (muy parecido al módulo Variable del panel Basic Process). Si no hay un
248 Capítulo 5
Figura 5-20. El elemento Variables (Variables)
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-
Figura 5-21. El elemento Expressions (Expresiones)
Figura 5-22. El elemento Replicate (Replicar)

250 Capítulo 5
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-23. El elemento DStats

Figura 5-24. El elemento Outputs (Resultados)
Unit Holding Cost (Costo de mantener la unidad) * MX (Inventory

Level [Nivel de inventario], 0)
y es el costo instantáneo de mantener que se carga siempre que Inventory Level sea positivo
(recuerde que MX es una función ya incluida en Arena que regresa el máximo de sus argumen-
tos). De forma similar, la otra entrada del elemento DStats, con el Name (Nombre) Shortage
Cost (Costo por faltante), acumula la Expression de SIMAN
Unit Shortage Cost (Costo de escasez de la unidad) * MX
- Inventory Level [Nivel de inventario], 0)
para el costo por escasez. Lo que queremos son los tiempos promedio de estos valores, que es
lo que obtendremos a continuación.
El elemento Outputs de la figura 5-24 hace lo mismo que las entradas del módulo Statistic
del tipo Output y aquí tenemos que realizar dos actividades. Primero (y visible en la figura
5-24), obtendremos el costo promedio de pedido por día al dividir Total Ordering Cost
(Costo total del pedido) entre Days to Run (Días a ejecutarse), la duración
de la ejecución, y almacenar esto en el nombre del resultado Avg Ordering Cost (Costo
promedio de pedido). Segundo, sumamos los tres componentes de la medida de desempe-
ño total de la salida en lo que llamamos Avg Total Cost (Costo total promedio),
a través de la expresión
OVALUE (Avg Ordering Cost) + DAVG (Holding Cost) + DAVG
(Shortage Cost)
La función OVALUE de Arena regresa el último (más reciente) valor de este argumento, que
en el caso presente es lo que definimos en la línea anterior de este módulo (podríamos habernos
evitado esto al introducir aquí en su lugar Total Ordering Cost / Days to Run, pero
hacerlo de esta forma produce un resultado por separado para el componente promedio-pedi-
252 Capítulo 5
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
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-
Figura 5-27. El Create Block (Bloque crear) del evaluador de inventario

254 Capítulo 5
Figura 5-28. El Branch block (bloque de sección)
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
Figura 5-29. El bloque Assign (Asignar) para colocar un pedido
Total Ordering Cost + Setup Cost + Incremental Cost + Order

Quantity
Note que aquí fue importante hacer las tareas en este orden, ya que el resultado de la pri-
mera se usa en la segunda.
Ahora es tiempo de esperar a que llegue el pedido, lo que se logra al enviar a la entidad In-
ventory Evaluator (Evaluador de inventario) al bloque Delay (Demorar) en la
figura 5-30, donde simplemente coloca las unidades de tiempo Delivery Lag (Retraso
Figura 5-30. El bloque Delay (Demora) para el retraso en las entregas

256 Capítulo 5
Figura 5-31. El bloque Assign (Asignar) para la llegada de los pedidos
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.
Figura 5-32. El cuadro de diálogo Plot (Gráfica)
Figura 5-33. El cuadro de diálogo Nivel de animación

258 Capítulo 5
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.

Este capítulo ha profundizado un poco en las capacidades detalladas de modelación de bajo
nivel, al igual que en los temas detallados correspondientes, como la animación de sintonía
fina. Aunque mencionamos cómo puede tener acceso y combinar en el lenguaje de simulación
SIMAN, lo cubrimos sin significados; véase Pegden, Shannon y Sadowski (1995) para el trata-
miento completo de SIMAN. En este punto, ya debe estar armado con un arsenal formidable
de herramientas de modelación que le permiten atacar muchos sistemas, escogiendo construc-
ciones de varios niveles según sean apropiados. En varios de los siguientes capítulos, continua-
remos expandiendo las capacidades de modelación de Arena.
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
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.
Operador Tiempo de ensamblaje

1 TRIA(15, 18, 20)
2 TRIA(16, 19, 22)
3 TRIA(16, 20, 24)
4 TRIA(17, 20, 23)
Una vez completo el proceso de ensamblaje, los ventiladores se inspeccionan encontrando

aproximadamente 7% de ellos como defectuosos. Un ventilador defectuoso se envía de vuelta
para reparación al mismo operador que lo ensambló. Estos ventiladores defectuosos tienen
prioridad sobre los equipos que llegan. Puesto que el ventilador necesita desensamblarse y
luego volverlo a ensamblar, se supone que el tiempo de reparación es 30% mayor que el tiempo
normal de ensamblaje. Ejecute su modelo por 20 000 minutos y recopile estadísticas de utiliza-
ción del operador y el tiempo en el sistema.
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):
Número de máquina Tiempo de montaje Tiempo de proceso Tiempo de remoción

1 8, 11, 16 20, 23, 26 7, 9, 12
2 6, 8, 14 11, 15, 20 4, 6, 8
La duración de la ejecución es de 25 000 minutos. Observe las estadísticas sobre la utili-

zación de la máquina, utilización del operador, tiempos de ciclo para partes por separado en
cuanto a qué máquina usan, tiempos de ciclo generales (esto es, no separados por máquina
usada), y el tiempo que cada máquina pasa esperando la atención de un operador (ambos en
montaje y remoción). Anime el proceso con el uso de almacenamientos para las actividades de
montaje, proceso y remoción.
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
3 × $5.50 + 0 × $6.50 + 5 × $8.00 + 1 × $10.50 = $67.00
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.
5-11 Un aeropuerto de tamaño mediano tiene un número limitado de vuelos internacionales

que llegan y que requieren migración y aduana. Al aeropuerto le gustaría examinar al personal
de aduana y establecer una política del número de pasajeros a quienes se les debe revisar el equi-
paje, así como del personal de la instalación de aduana. Los pasajeros que llegan deben pasar
primero por migración (migración está fuera de los límites de este modelo). Luego reclaman su
262 Capítulo 5
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:
Hora Llegadas por hora Hora Llegadas por hora

1 22 5 35
2 35 6 43
3 40 7 29
4 31 8 22
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
Análisis estadístico de resultados

de las simulaciones terminadas
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.
6.1 Marco de tiempo de las simulaciones

Como en la sección 5.2.5, la mayoría de las simulaciones (no todas) se pueden clasificar ya sea
como terminadas o de estado estable. Para muchos modelos, éste es ante todo un tema de in-
tención o la meta del estudio, en lugar de tener mucho que ver con la lógica o la construcción
internas del modelo.
Una simulación terminada es en la que el modelo dicta condiciones específicas de inicio y de-
tención como un reflejo natural de cómo opera realmente el sistema objetivo. Como lo sugiere
el nombre, la simulación terminará de acuerdo con alguna regla o condición especificada en el
modelo. Por ejemplo, una tienda abre a las 9 a.m. sin clientes presentes, cierra sus puertas a las
9 p.m. pero continúa en operación un poco más de tiempo hasta que todos los clientes hayan
“salido”. Otro ejemplo es una configuración de taller que opera el tiempo que le tome producir
una “ejecución” de 500 montajes completos especificados en el pedido. La noción clave es que el
marco de tiempo de la simulación tiene un final bien definido (aunque posiblemente desconoci-
do para alguien de afuera) y natural, así como una manera claramente definida para iniciar.
Una simulación de estado estable, por otra parte, es en la que las cantidades a estimar se de-
finen a largo plazo, esto es, en un marco de tiempo teóricamente infinito. En principio (aunque
generalmente no en la práctica) las condiciones iniciales para la simulación no importan. Por
supuesto, una simulación de estado estable debe detenerse en algún punto y, como puede adi-
vinar, esas ejecuciones pueden resultar bastante largas; se necesita hacer algo para asegurarse
de que el lector está ejecutándola lo suficiente, un tema que retomaremos en la sección 7.2. Por
ejemplo, una sala de emergencias en realidad nunca se detiene o vuelve a comenzar, así que una
simulación de estado estable podría ser la apropiada. A veces las personas hacen una simula-
ción de estado estable de un sistema que de hecho termina, con la finalidad de diseñar alguna
clase de situación del peor de los casos o situación pico.
En este capítulo, nos adheriremos a un análisis estadístico de término de la tercera versión
del modelo del centro de atención telefónica del capítulo 5 en su encarnación del modelo 5-3, al
verlo como una simulación terminada que inicia y se detiene como se describió en tal capítulo.
Los análisis de estado estable deben hacerse de forma diferente (haremos esto en la sección 7.2,
usando el modelo que desarrollaremos en la sección 7.1).
6.2 Estrategia para recopilación y análisis de datos

Con una simulación terminada, es conceptualmente sencillo recopilar los datos apropiados
para el análisis estadístico (sólo haga algún número n de réplicas independientes).1
Para realizar esto, sólo abra el cuadro de diálogo Run > Setup > Replication Parameters
(Ejecutar > Configuración > Parámetros de réplica) e introduzca el valor de n que desee para el
Number of Replications (Número de réplicas). Asegúrese que los cuadros debajo de Initialize
Between Replications (Inicializar entre réplicas) estén marcados (los predeterminados) para
hacer que se despejen tanto las variables indicadas en el sistema como los acumuladores esta-
dísticos al final de cada réplica. Existen razones para dejar sin marcar uno o ambos de estos
cuadros, pero para obtener verdaderas réplicas estadísticamente independientes e idénticamen-
te distribuidas (IID) para un análisis terminado, hay que asegurarse de que ambos cuadros se
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
Tabla 6-1. Costo total y porcentaje de rechazo de diez réplicas

del modelo 6-1 (igual que el modelo 5-3)
Réplica Costo total ($) Porcentaje de rechazo

1 21 281.24 12.6836
2 20 612.12 11.6059
3 20 023.67 9.2958
4 25 834.40 17.6084
5 24 748.90 13.3240
6 19 667.52 13.0201
7 19 565.40 11.0803
8 23 145.32 12.2655
9 19 931.75 9.6403
10 20 667.84 12.7830
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.
6.3 Intervalos de confianza para sistemas terminados

Tal y como lo hicimos para la simulación a mano de la sección 2.6.2 (y usando las mismas fór-
mulas dadas ahí), podemos resumir nuestros datos de salida de las n = 10 réplicas reportadas
en la tabla 6-1. En la tabla 6-2, damos la media de la muestra, su desviación estándar, la mitad
del ancho del intervalo de confianza en 95% y tanto el mínimo como el máximo de los valores
de salida del resumen en las réplicas.
Arena producirá de forma automática la información de la tabla 6-2 (excepto por la desvia-
ción estándar de la muestra, pero la mitad del intervalo de confianza contiene esencialmente
la misma información) en el reporte Category Overview (Vista general de categorías), si se le
solicita más de una sola réplica en Run > Setup > Replication Parameters (Ejecutar > Configu-
ración > Parámetros de réplica). La figura 6-1 muestra la parte relevante del reporte Category
Overview (General de categorías) para el modelo 6-1 después de que lo ejecutamos durante diez
réplicas; excepto por un pequeño error de redondeo, ésta concuerda con la información de la
tabla 6-2 que calculamos a mano.
Si el lector quiere controlar las condiciones y el reporte de alguna manera, tal como especi-
ficar el nivel de confianza para algo diferente de 95%, produciendo los resultados en grupos u
ordenamientos en particular, puede guardar los datos del resumen en un archivo .dat en el mó-
dulo de datos Statistic (Estadística), como se describió anteriormente, y después usar el Output
Analizer (véase la sección 6.4). También puede obtener muestras gráficas de intervalos de con-
fianza como una de las capacidades del Process Analyzer de Arena (véase la sección 6.5).
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
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.
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
Figura 6-2. Histograma de 1 000 valores de Total Cost
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
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.
6.4 Comparación de dos escenarios

En la mayoría de los estudios de simulación, finalmente las personas se interesan en comparar
diferentes versiones o alternativas o escenarios de algún modelo general. Lo que hace que los es-
cenarios difieran entre ellos podría ser desde un sencillo cambio de parámetro hasta una lógica
fundamentalmente diferente. En cualquier caso, hay que tener cuidado de aplicar los métodos
estadísticos apropiados al resultado de los escenarios para asegurar que se sacan conclusiones
válidas. En esta sección, nos limitaremos al caso de sólo dos escenarios; en la sección 6.5 nos
permitiremos más.
Comenzaremos con modificar el modelo 6-3 en lo que llamaremos el modelo 6-4, simplemente
al bajar de nuevo el Number of Replications en Run > Setup > Replication Parameters a 110;
dejamos la entrada en el módulo de datos Statistic, Output File Column (Columna de archivo
de resultados), la fila Total Cost para guardar el Total Cost de cada réplica en el archivo
Total Cost.dat (se abundará sobre esto después). Consideremos dos versiones. La primera,
que llamaremos caso base, es idéntica a la del modelo 5-3 del capítulo 5, con exactamente los
mismos parámetros de entrada y condiciones de ejecución (excepto que haremos 110 réplicas en
lugar de cinco), es decir, aún tenemos 26 líneas principales y no hemos añadido las de Larry (la
Variable New Tech 1 es 0), Moe (New Tech 2 es 0), Curly (New Tech 3 es 0), Hermann (New
Tech All es 0) ni la del personal de ventas (New Sales es 0) durante las horas 5 a 8. El esce-
nario alternativo, que llamaremos escenario de más recursos, es el caso base con excepción de que
añadiremos tres líneas principales (en la fila Trunk Line [Línea troncal] del módulo de
datos Resource cambia la capacidad de 26 a 29) y contrataremos tres de cada Larry, Moe, Curly,
Hermann y del personal de ventas (en el módulo de datos Variable iniciar cada New Tech 1,
New Tech 2, New Tech 3, New Tech All y New Sales en 3 en lugar de 0). Al añadir
recursos de esta forma, ciertamente aumentaremos el costo de los salarios, pero también dismi-
nuiremos la espera y por ende los costos por exceso en espera. Así que quizá no esté claro cuál será
el impacto del costo total de este cambio, y mucho menos cuál será su magnitud. Y aunque tales
cambios debieran reducir el porcentaje de llamadas entrantes que se rechazan, es difícil saber en
cuánto. Suena como un trabajo (lo adivinó) para la simulación.
Hicimos una ejecución (sólo una réplica) tanto del caso base como del de más recursos y
obtuvimos resultados Total Cost de $21 281.24 y de $23 306.75, respectivamente; los Per-
cent Rejected fueron de 12.6836 y 0.2833, en cada caso. En la superficie, esto parece mez-
clado para el escenario de más recursos ya que el Total Cost parece haber aumentado algo
mientras que el Percent Rejected disminuyó, aparentemente de forma sustancial. Pero si
aprendió algo cuando leyó la sección 6.3 (o la sección 2.6.3), sabrá bastante sobre caer en esta
trampa de concluir mucho acerca de nada a partir de una sola ejecución, sin realizar un análisis
estadístico del resultado. Así que realizaremos esta comparación de tal forma que nos permita
establecer una conclusión estadísticamente válida.
Antes de hacer la comparación convencionalmente, la haremos en una forma razonable
pero no muy correcta. Concentrándonos en la medición del resultado Total Cost, vimos en
274 Capítulo 6
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
22 241.71 ± 413.52 o [21 828.12, 22 655.16]
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
24 560.12 ± 315.93 o [24 244.19, 24 876.05]
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.
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
Title (Título) (Base Case) – (More Resources) [(Caso base) – (Más

recursos)]
Scale Display (Muestra a escala) clear (libre)
Add (Añadir)
Data File A (Archivo de datos A) Total Cost – Base Case.dat (Costo total – Caso
base.dat)
Replication (Réplica) Lumped (Agrupado)
Add (Añadir)
Data File B (Archivo de datos B) Total Cost – More Resources.dat (Costo total
– Más recursos.dat)
Add (Añadir)
Data File A (Archivo de datos A) Percent Rejected – Base Case.dat (Porcentaje de
rechazo – Caso base.dat)
Add (Añadir)
Data File B (Archivo de datos B) Percent Rejected – More Resources.dat (Porcen-
taje de rechazo – Más recursos.dat)
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).
Figura 6-3. Intervalo de confianza y prueba de hipótesis en la diferencia esperada

entre Total Costs y Percents Rejected
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.
Figura 6-4. El proyecto PAN Experiment 06-05.pan después de definir

el primer escenario (Caso base)
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
Figura 6-6. Resultados de la ejecución del proyecto

PAN para todos los escenarios
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
Costo total por escenario Porcentaje de rechazos por escenario

Costo total Porcentaje de rechazos
Mejor escenario Escenario Mejor escenario Escenario
Figura 6-7. Selección de un subconjunto que contenga la mejor alternativa de escenario

(las cajas rojas están circuladas)
282 Capítulo 6
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).
6.6 Búsqueda de un escenario óptimo con OptQuest

Los escenarios evaluados en la sección 6.5 fueron sólo algunas de las numerosas posibilidades
que podríamos explorar en una búsqueda para minimizar el Total Cost, sujeto al reque-
rimiento de que la respuesta del Percent Rejected resulte ser no más de cinco. Suponga
que ahora usted está libre de explorar todas las posibilidades que desee en términos de la
capacidad de Trunk Line (Línea Troncal) (pero que está obligado por contrato a
mantener al menos las 26 líneas que ya tiene, y el armario de cableado tiene espacio para 50
a lo mucho), así como New Tech 1, New Tech 2, New Tech 3, New Tech All y New
Sales (pero se tiene espacio para un máximo de 15 nuevas personas en todas las categorías
combinadas de soporte técnico y ventas). Puesto que usted tiene seis variables de control
de entrada para jugar, puede pensar en ellas como si estuviera vagando en una parte de un
espacio de seis dimensiones buscando uno de seis vectores (de integrales no negativas) que
minimice el Total Cost mientras el Percent Rejected se mantiene en cinco o menos.
Éstas son muchas posibilidades (de hecho 1 356 600), y considerarlas exhaustivamente no es
práctico (con 110 réplicas por escenario que hemos usado, tardarían en ejecutarse más de dos
meses en una máquina de 2.13 Ghz).
¿Por dónde comenzar? Ésta es una pregunta difícil, pero una idea razonable sería el mejor
punto que se conozca hasta el momento. Ninguno de los escenarios en el experimento PAN
de la figura 6-6 reúne el requisito de que Percent Rejected ≤ 5 (aunque un par está
cerca y podríamos empezar con un punto no viable, aunque por supuesto necesitaríamos
alejarnos eventualmente de él, como en el ejercicio 6-24). Sin embargo, el caso de más recur-
sos de la sección 6.4 (el recurso Trunk Line tiene una capacidad de 29, y New Tech 1,
New Tech 2, New Tech 3, New Tech All y New Sales todas están en 3) debe reunir
el requisito de Percent Rejected ≤ 5, así que comenzaremos ahí, aunque su Total
Cost (Costo Total) es bastante alto en comparación con otros escenarios con los que
hemos experimentado por lo que buscaremos reducirlo mientras cumplimos con el requisito
Percent Rejected ≤ 5.
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
Figura 6-8. Ventana OptQuest con controles completos
A continuación haga clic en Responses (Respuestas) en el árbol de la izquierda (o la opción

en el menú View > Responses [Ver > Respuestas]) para seleccionar los resultados de interés.
Aquí, sólo revise las cajas en la columna Included (Incluido) para Total Cost y Percent
Rejected, después quizás haga clic en el encabezado Included para recopilarlos en la parte de
arriba. El resultado aparece en la figura 6-9, esta vez sin el árbol de la izquierda.
Para especificar las restricciones, haga clic en Constraints (Restricciones) en el árbol de la
izquierda (o View > Constraints [Ver > Restricciones]) para mostrar esa ventana. Haga clic en
Add (Añadir) en la parte de abajo, y después sucesivamente haga clic en cada uno de los cinco
primeros Controls (Controles), después un signo + del tablero de la calculadora de la derecha
y, por último < = 15 para especificar esta restricción en el campo debajo de las entradas; quizás
añada un Name (Nombre) y Description (Descripción) y haga clic en OK (Aceptar). Después
haga clic de nuevo en Add (Añadir) abajo y seleccione Percent Rejected debajo de Res-
ponses, luego < =5 para especificar esta restricción en un resultado; note que tal “restricción”
realmente no es como una restricción de programación matemática, dado que se encuentra en
una salida del modelo (difiere del objetivo) en lugar de una elección de entrada o variable de
decisión. La ventana completa Constraints aparece en la figura 6-10.
Para decirle a OptQuest qué es lo que quiere optimizar, haga clic en Objetives (Objetivos)
en el árbol de la izquierda (o View > Objetives [Ver > Objetivos]), después Add (Añadir), luego
haga clic en Total Cost debajo de Responses (Respuestas), después en el botón radio de
Minimize (Minimizar) (y un Name y Description si lo desea). El resultado se encuentra en la
figura 6-11.
Figura 6-9. Respuestas (Responses) completas para OptQuest
Figura 6-10. Restricciones (Constraints) completas para OptQuest

286 Capítulo 6
Figura 6-11. Función objetivo para OptQuest
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).
Figura 6-12. Ventana final Optimization (Optimización) para OptQuest
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.

Ahora debe tener un muy buen sentido de lo que necesitan hacer usted y su computadora
para usar sus modelos de simulación terminados eficientemente con el fin de formar estima-
dos de resultados esperados confiables y precisos, trazar conclusiones válidas acerca de cómo
diferentes alternativas (o escenarios) de su modelo pueden diferir en términos de medidas de
desempeño de resultados clave y buscar eficientemente una configuración de modelo que sea
óptima en algún sentido. Es largo el recorrido para convertirse en un usuario eficaz de sus
modelos (no sólo un modelador diestro, aunque de hecho también es importante). En el capí-
tulo 7 recorreremos más ideas de modelación y después al final volveremos a visitar análisis
de resultados si tiene interés en los resultados de largo plazo (o en estado continuo), en cuyo
caso debe realizar actividades un poco diferentes de las que describimos en este capítulo. En
el capítulo 12 se analizarán más temas estadísticos en simulación, incluyendo cómo se gene-
288 Capítulo 6
ra la aleatoriedad adyacente, cómo reducir la variación de resultados (sin otra herramienta

que un poco más de cómputo), de qué manera lograr que Arena decida por sí mismo cuánto
ejecutar para darle resultados precisos de forma aceptable y un poco más de diseño de expe-
rimentos de simulación.
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.
b) Cambie su modelo de la parte a) para que el agente de voladores frecuentes pueda

servir a clientes regulares cuando no haya voladores frecuentes esperando en la cola.
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-7 En el ejercicio 5-13, haga 30 réplicas y calcule un intervalo de confianza de 95% en el

sistema esperado o tiempo de ciclo para ambos tipos de cliente.
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):
(20, 40) (20, 60) (20, 80) (20, 100)

(40, 60) (40, 80) (40, 100)
(60, 80) (60, 100)
(80, 100)
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.
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
Modelado intermedio y análisis

estadístico de estado estable
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.
7.1 Modelo 7-1: un sistema pequeño de fabricación

Un bosquejo para nuestro pequeño sistema de fabricación se muestra en la figura 7-1. El siste-
ma a modelar consiste en llegadas de partes, cuatro celdas de manufactura y salidas de partes.
Las celdas (Cells) 1, 2 y 4 poseen una sola máquina cada una; la celda (Cell) 3 tiene dos má-
quinas. Las dos máquinas de la celda 3 no son idénticas; una de aquéllas es un modelo más
reciente que puede procesar partes en 80% del tiempo que requiere una máquina más vieja. El
sistema produce tres tipos de partes, cada una visitando una secuencia diferente de estaciones.
Los pasos y tiempos del proceso de las partes (en minutos) están dados en la tabla 7-1. Todos los
tiempos del proceso se hallan distribuidos de forma triangular; los tiempos del proceso dados
en la tabla 7-1 de la celda 3 son para la máquina más vieja (más lenta).
Los tiempos entre llegadas entre los arribos sucesivos de las partes (todos los tipos combina-
dos) están distribuidos de forma exponencial con una media de 13 minutos; la primera parte lle-
ga en el tiempo 0. La distribución por tipo es de 26% en la Parte 1; 48% en la Parte 2 y 26% en la
294 Capítulo 7
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.
7.1.1 Nuevos conceptos de Arena

Existen varias características de este problema que requieren nuevos conceptos de Arena. La
primera característica es que existen tres tipos de partes que siguen diferentes planes de proceso
a través del sistema. En nuestros modelos previos, simplemente enviábamos a todas las entida-
des a través de la misma secuencia de estaciones. Para este tipo de sistema, necesitamos un plan
de proceso con una capacidad de ruta automática.
La segunda característica es que las dos máquinas en la Celda 3 no son iguales (la máquina
más reciente puede procesar partes más rápidamente que la otra). Aquí tenemos que ser capa-
ces de distinguir entre estas dos máquinas.
La tercera característica es la naturaleza del flujo de las entidades a través del sistema. En
nuestros modelos anteriores, aquél se lograba al usar la opción de direct Connect (Conexiones
directas) o direct Route (Ruta directa). Cuando se usa la opción Connect, se envía inmediata-
mente una entrada al siguiente módulo, de acuerdo con la conexión, sin avance de tiempo en
Tabla 7-1. Rutas y tiempos de proceso de partes
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.
7.1.2 El enfoque de modelado

El enfoque de modelado que se use para un modelo específico de simulación dependerá con
frecuencia de la complejidad del sistema y la naturaleza de los datos disponibles. En modelos
sencillos, por lo general es obvio qué módulos se requerirán y el orden en el que se colocarán.
Pero en modelos más complejos, con frecuencia se tendrá que tener mucho cuidado a la hora de
desarrollar el enfoque apropiado. Conforme aprenda más acerca de Arena, el lector encontrará
que a menudo hay varias formas de modelar un sistema o una parte del mismo. Con frecuencia
escuchará a modeladores experimentados decir que no hay sólo una forma correcta de modelar
un sistema. Existen, sin embargo, muchas formas incorrectas, pues fallan al captar adecuada-
mente el detalle requerido del sistema.
A menudo el diseño de modelos complejos está dirigido por los requerimientos de los
datos del modelo y por los datos reales que se encuentran disponibles. Los modeladores
experimentados con frecuencia pierden mucho tiempo en determinar cómo introducirán,
almacenarán y usarán sus datos y después dejan que este diseño determine qué construc-
ciones de modelado se requieren. Conforme los requerimientos de los datos se vuelven más
demandantes, tal enfoque a menudo es el único que le permitirá el desarrollo de un mo-
delo exacto en un corto periodo de tiempo. Esto es particularmente cierto en los modelos
de simulación de sistemas de cadena de abastecimiento, almacenes, redes de distribución y de
servicio. Por ejemplo, un almacén típico puede tener cientos de miles de artículos diferentes,
llamados SKU (Stock-Keeping Units [Unidades de Almacenamiento de Inventarios]). Cada
SKU puede requerir datos que representen su ubicación en el almacén, su tamaño y su peso,
así como reordenar o resurtir datos para este SKU. Además de especificar los datos para los
contenidos del almacén, el lector también posee datos de pedidos de clientes e información
sobre los tipos de mecanismos de almacenamiento o equipamiento que mantengan los SKU.
Si su modelo requiere la capacidad de cambiar las ubicaciones, mecanismos de almacena-
miento, opciones de resurtido, etc., de su SKU durante la experimentación, es esencial la
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.
7.1.3 Los módulos de datos

Comencemos por editar el módulo de datos Sequence del panel Advanced Transfer. Haga doble
clic para añadir una nueva fila e introduzca el nombre de la primera secuencia, Part 1 Pro-
cess Plan. Una vez introducido el nombre de la secuencia, necesita colocar los Steps (Pasos)
del proceso, que son las listas de las estaciones de Arena. Por ejemplo, Part 1 Process
Plan requiere que introduzca las siguientes estaciones de Arena: Cell 1, Cell 2, Cell
3, Cell 4 y Exit System. Dimos los Step Names (Nombres de los pasos) como Part 1
Step 1 hasta Part 1 Step 5. El error más común al introducir las secuencias es olvidarse
del último paso, que por lo general se encuentra en donde la entidad sale del sistema. Si se ol-
vida este paso, el lector obtendrá un error de tiempo de ejecución de Arena cuando la primera
entidad complete su ruta de proceso y no le diga a Arena hacia dónde enviarla después. Con-
forme defina las Sequences (Secuencias) recuerde que después de haber introducido un nombre
de estación una vez, puede elegirlo subsecuentemente de las listas de estaciones de sugerencias
en otro lugar de su modelo. También tendrá que asignar valores de atributos para los tiempos
de proceso de las partes de las Celdas 2, 3 y 4. Recuerde que definiremos una Expression para
los tiempos de proceso de las partes de la Celda 1, así que no necesitaremos hacer una tarea de
atributos para los tiempos de proceso ahí.
La pantalla 7-1 indica el procedimiento para la Sequence Part 1 Process Plan, el
Step Part 1 Step 2 y la Tarea de Process Time. Al usar los datos de la tabla 7-1,
debería ser bastante sencillo introducir los pasos de secuencia restantes. Pronto le mostraremos
cómo referenciar estas secuencias en la lógica del modelo.
298 Capítulo 7
Name (Nombre) Part 1 Process Plan (Parte 1 plan de

proceso)
Steps (Pasos)
Station Name (Nombre de la estación) Cell 2 (Celda 2)
Step Name (Nombre del paso) Part 1 Step 2 (Parte 1 Paso 2)
Assignment Type (Tipo de tarea) Attribute (Atributo)
Attribute Name (Nombre del atributo) Process Time (Tiempo de proceso)
Value (Valor) TRIA(5,8,10)
Pantalla 7-1. El módulo de datos Sequence (Secuencia)
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)
Pantalla 7-2. La expresión tiempos de proceso de las partes para la Celda 1

Name (Nombre) Factor

Rows (Filas) 2
Initial Values (Valores iniciales)
Initial Value (Valor inicial) 0.8
Initial Value (Valor inicial) 1.0
Name (Nombre) Transfer Time (Tiempo de transferencia)
Initial Values (Valores iniciales)
Initial Value (Valor inicial) 2
Pantalla 7-3. Las variables Factor y Tiempo de transferencia
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.
7.1.4 Los módulos de lógica

La principal parte de la operación del modelo consistirá en módulos de lógica que representen
las llegadas de las partes, las Celdas y las salidas de las partes. Las llegadas se modelarán al usar
300 Capítulo 7
Asignar tipo y Estación

Comenzar
Crear partes secuencia de liberar
secuencia
parte orden
0
Figura 7-2. Los módulos de llegada de parte
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
Name (Nombre) Assign Part Type and Sequence (Asignar Tipo

y Secuencia de parte)
Assignaments (Tareas)
Attribute Name (Nombre de atributo) Part Index (Índice de parte)
New Value (Valor nuevo) DISC ( 0.26, 1, 0.74, 2, 1.0, 3 )
Attribute Name (Nombre de atributo) Entity.Sequence
New Value (Valor nuevo) Part Sequences (Part Index) (Secuencias de
partes [Índice de parte])
Attribute Name (Nombre de atributo) Entity.Type
New Value (Valor nuevo) Entity Types (Part Index) (Tipos de entidad
[Índice de parte])
Attribute Name (Nombre de atributo) Entity.Picture
New Value (Valor nuevo) Part Pictures (Part Index) (Imágenes de parte
[Índice de parte])
Pantalla 7-4. El módulo Assign: asignación de atributos de parte

(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.
Name (Nombre) Order Release Station

Station Type (Tipo de estación) Station (Estación)
Station Name (Nombre de estación) Order Release
Pantalla 7-5. El módulo Estación

302 Capítulo 7
Name (Nombre) Start Sequence (Iniciar secuencia)

Route Time (Tiempo de ruta) Transfer Time (Tiempo de transferencia)
Destination Type (Tipo de destino) By Sequence (Por secuencia)
Pantalla 7-6. El módulo Ruta
Estación Proceso Ruta desde la

Celda 1 Celda 1 Celda 1
Figura 7-3. Módulos de lógica de la Celda 1
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.
Name (Nombre) Cell Station (Estación de la Celda)

Station Type (Tipo de estación) Station (Estación)
Station Name (Nombre de la estación) Cell 1 (Celda 1)
Pantalla 7-7. El módulo Station de la Celda 1

Name (Nombre) Cell Process (Proceso de la estación)

Resource Name (Nombre del recurso) Cell 1 Machine (Máquina de la Celda 1)
Expression (Expresión) Cell 1 Times(Part Index) [Tiempos de la
Celda 1]
Pantalla 7-8. Módulo Process de la Celda 1
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
Name (Nombre) Route from Cell 1 (Ruta desde la Celda 1)

Route Time (Tiempo de ruta) Transfer Time (Tiempo de transferencia)
Destination Type (Tipo de destino) By Sequence (Por secuencia)
Pantalla 7-9. Módulo Route de la Celda 1

304 Capítulo 7
Name (Nombre) Cell 3 Process (Proceso de la Celda 3)

Type (Tipo) Set (Conjunto)
Set name (Nombre del conjunto) Cell 3 Machine (Máquina de la Celda 3)
Save Attribute (Guardar atributo) Machine Index (Índice de la máquina)
Expression (Expresión) Process Time * Factor (Machine Index) (Tiempo
de proceso * Factor [Índice de la máquina])
Pantalla 7-10. Módulo Process de la Celda 3
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
Salir de la
Disponer de
estación del
la parte
sistema
0
Figura 7-4. Módulos de la lógica de salida del sistema
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:
Process Time * (((Machine Index = = 1) * 0.8) + (Machine Index = = 2))

o
Process Time * (1 - Machine Index = = 1) * 0.2)).
Dejamos al lector explicarse a sí mismo cómo funcionan estas expresiones. (PISTA: “a = =

b” evalúa a 1 si “a” es igual a “b” y de lo contrario a 0.)
Habiendo definido por completo todos nuestros datos, el proceso de llegada de parte y las
cuatro Celdas, sólo nos queda por definir la salida del sistema de las partes. Los dos módulos
que logran esto se muestran en la figura 7-4.
Como antes, usaremos el módulo Station para definir la ubicación de nuestra Station (Esta-
ción) Exit System (Salida del sistema). El módulo Dispose (Disponer) se usa para
destruir la parte completada. Nuestro modelo completado (aunque no esté animado del todo)
aparece en la figura 7-5.
Asignar tipo Estación de Salir de la

Iniciar Disponer de la
Crear partes de parte y estación del
liberar orden secuencia parte
secuencia sistema
0 0
Estación Proceso Ruta desde la Estación Proceso Ruta desde la

Celda 1 Celda 1 Celda 1 Celda 3 Celda 3 Celda 3
0 0
Estación Proceso Ruta desde la Estación Proceso Ruta desde la

Celda 2 Celda 2 Celda 2 Celda 4 Celda 4 Celda 4
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-
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
Ordenar Salida del

liberación sistema
Celda 4 Celda 3
Figura 7-6. El pequeño sistema de fabricación animado: Modelo 7-1

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
un conjunto diferente de condiciones. Si no (o por lo menos en un aproximado), encuentre los

porqués. Puede ser debido a mala estimación, la falta de comprensión del sistema o un modelo
defectuoso. Algunas veces los resultados no tan obvios (pero reales) son creados por interac-
ciones sorprendentes en el modelo. En general, probablemente puede ejercitar sus modelos de
simulación y estar conforme con los resultados antes de usarlos para tomar decisiones. Y lo
mejor es hacer esto desde el principio de su proyecto (y con frecuencia).
De regreso a la sección 2.8 cuando mencionamos la verificación, sugerimos que verificara
su código. Su respuesta puede ser, “¿qué código?” Bueno, hay un código, y le mostraremos un
poco en las figuras 7-7 y 7-8. Pero se debe seguir preguntando, “¿por qué un código?” Para
explicar la razón de éste se requieren un poco más de antecedentes (sí, otra lección de his-
toria). La formación de Systems Modeling (la empresa que originalmente desarrolló Arena)
y la liberación inicial del lenguaje de simulación SIMAN® (en el que se basa Arena y con el
que el lector puede obtener acceso a través de Arena) ocurrió en 1982. Las computadoras
personales apenas comenzaban a impactar el mercado y SIMAN se diseñó para ejecutarse
en este nuevo tipo de máquinas. De hecho, SIMAN sólo requería 64 Kbytes de memoria, lo
que era mucho en esos días. No había una capacidad de animación (Cinema, la herramienta
de animación que lo acompañaba, se liberó en 1985) y los modelos se creaban usando en edi-
tor de textos, igual que usar un lenguaje de programación. Un modelo completo requería el
desarrollo de dos archivos, un archivo del modelo y un archivo de experimento. El archivo del
modelo, referido a menudo como el archivo .mod, contenía la lógica del modelo. El archivo
del experimento, frecuentemente denominado como el archivo .exp, definía las condiciones
experimentales. Se requería que el usuario enlistara todas las estaciones, atributos, recursos,
etc., que se usarían en el modelo. La creación de estos archivos demandaba que el usuario
siguiera una sintaxis bastante exacta para cada tipo de construcción del modelo o del experi-
mento. En otras palabras, había que comenzar con ciertos enunciados sólo en la columna 10;
tenían que seguirse ciertas entradas con las comas, puntos y comas, o dos puntos requeridos;
todos los recursos y atributos se referenciaban sólo por número, y sólo se podía usar un con-
junto limitado de palabras clave. (Muchos de sus profesores, o quizá los suyos, aprendieron
simulación de esta forma.)
Desde 1982, SIMAN ha seguido mejorando y proporcionando la base para un modelo de
simulación Arena. Cuando ejecuta una simulación de Arena, éste examina cada opción que
seleccionó en sus módulos y los datos que proporcionó y después crea archivos SIMAN .mod y
.exp. Éstos son los archivos que se emplearon para ejecutar sus simulaciones. La implicación es
que todos los módulos que se encuentran en los paneles Basic Process (Proceso básico), Advan-
ced Process (Proceso avanzado) y Advanced Transfer (Transferencia avanzada) se basan en las
construcciones encontradas en el lenguaje de simulación SIMAN. La idea es proporcionar una
herramienta de simulación (Arena) que sea fácil de usar y una que siga basada en el poderoso y
flexible lenguaje SIMAN. Así que ya ve, todavía es posible, y aún a veces deseable, ver el código
SIMAN. De hecho, tales archivos se pueden escribir y editar. Sin embargo, sólo es posible ir
hacia abajo (de Arena al código SIMAN) y no es posible regresar de nuevo hacia arriba (del
código SIMAN a Arena). A medida que se haga más competente con Arena, el lector podrá ver
este código ocasionalmente para estar seguro que el modelo se encuentra haciendo exactamente
lo que se quiere: verificación.
Debemos señalar que el lector puede seguir creando sus modelos en Arena al usar el len-
guaje base SIMAN. Si se construye un modelo usando sólo los módulos que se encuentran en
;
; 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)
los paneles Blocks ATTRIBUTES:

(Bloques) Machine
y Elements Index:
(Elementos), básicamente se está empleando aquel
Part Index:
lenguaje. Recuerde que usamosProcess varios módulos
Time; del panel Blocks (Bloques) cuando construimos
nuestro modelo de QUEUES:
inventario enCell 1 Process.Queue,FIFO,,AUTOSTATS(Yes,,):
la sección 5.7.
Cell 2 Process.Queue,FIFO,,AUTOSTATS(Yes,,):
Puede ver el código SIMAN para nuestro pequeño modelo de fabricación al usar la opción
Run >SIMAN > View (Ejecutar Cell>4SIMAN > Ver). Al seleccionar esta opción se generarán
Process.Queue,FIFO,,AUTOSTATS(Yes,,);
RESOURCES: Cell 2 Machine,Capacity(1),,,COST(0.0,0.0,0.0),
ambos archivos, cada uno en una ventana separada. La figura 7-7 muestra una pequeña por-
CATEGORY(Resources),,AUTOSTATS(Yes,,):
ción del archivo .mod, el código Cell 1 Machine,Capacity(1),,,COST(0.0,0.0,0.0),
escrito para el módulo Process (Proceso) usado en la Celda 3.
El lenguaje SIMAN es más descriptivo, así que es posible seguir la lógica general. Una entidad
Cell 3 Old,Capacity(1),,,COST(0.0,0.0,0.0),
que llega a este módulo aumenta CATEGORY(Resources),,AUTOSTATS(Yes,,):
algunos contadores internos, introduce una cola, Cell 3
Cell 3 New,Capacity(1),,,COST(0.0,0.0,0.0),
Process.Queue
;
Proceso.Cola), espera a tomar un recurso del conjunto
(Celda 3CATEGORY(Resources),,AUTOSTATS(Yes,,):
Cell ; 3 Machines (Celda Cell 3
Model statements for module: 4Máquinas),
Machine,Capacity(1),,,COST(0.0,0.0,0.0),
demora
Process 3 para el tiempo de proceso (ajustado
CATEGORY(Resources),,AUTOSTATS(Yes,,);
por ;10$
nuestro factor), libera el recurso, disminuye los contadores internos y sale del módulo.
ASSIGN: Cell 3 Process.NumberIn=Cell 3 Process.NumberIn + 1:
La figura 7-8 muestraCelluna parte
3 Process.WIP=Cell 3 Process.WIP+1; tres atributos y las colas
del archivo .exp que define nuestros
138$ usadas
y recursos QUEUE,
en Cellmodelo.
nuestro 3 Process.Queue;
137$ SEIZE, 2,VA:
No daremos una explicación detallada
SELECT(Cell de los señalamientos en
3 Machines,CYC,Machine estos archivos; el propósito
Index),1:NEXT(136$);
136$
del presente DELAY: solamente
ejercicio ProcessesTime * Factor(
enterar al lector Machine
de su Index ),,VA;
existencia. Para una explicación más
135$ RELEASE: Cell 3 Machines(Machine Index),1;
amplia,
183$ consulte a Pegden, Shannon y Sadowski (1995).
ASSIGN: Cell 3 Process.NumberOut=Cell 3 Process.NumberOut + 1:
Si está familiarizado conCellSIMAN
3 Process.WIP=Cell 3 Process.WIP-1:NEXT(11$);
o si sólo le gustaría aprender más acerca de cómo funcio-
na este proceso, le sugerimos que coloque unos cuantos módulos, introduzca algunos datos y
ATTRIBUTES: Machine Index:

Part Index:
Process Time;
QUEUES: Cell 1 Process.Queue,FIFO,,AUTOSTATS(Yes,,):
Cell 4 Process.Queue,FIFO,,AUTOSTATS(Yes,,);
RESOURCES: Cell 2 Machine,Capacity(1),,,COST(0.0,0.0,0.0),
Cell 1 Machine,Capacity(1),,,COST(0.0,0.0,0.0),
Cell 3 Old,Capacity(1),,,COST(0.0,0.0,0.0),
Cell 3 New,Capacity(1),,,COST(0.0,0.0,0.0),
Cell 4 Machine,Capacity(1),,,COST(0.0,0.0,0.0),
CATEGORY(Resources),,AUTOSTATS(Yes,,);
Figura 7-8. Archivo de experimento SIMAN para el módulo Process (Proceso)

312 Capítulo 7
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.
7.2 Análisis estadístico de resultados de las simulaciones

de estado constante
En el capítulo 6 describimos la diferencia entre simulaciones terminadas y de estado estable e
indicamos cómo pueden usarse los reportes de Arena, PAN y el Output Analyzer (Analizador
de resultados) para hacer análisis estadísticos en el caso terminante. En esta sección le mostra-
remos cómo hacer inferencia estadística en simulaciones de estado constante.
Antes de proceder, debemos insistirle en que se asegure que una simulación de estado cons-
tante es apropiada para lo que quiere hacer. A veces las personas sólo suponen que tal simula-
ción, de ejecución larga, es lo que hay que hacer, lo que de hecho podría ser cierto. Pero si las
condiciones de inicio y término son parte de la esencia de su modelo, un análisis de terminación
es probablemente el más apropiado; si así es, sólo debe proceder como en el capítulo 6. La
razón para evitar la simulación de estado estable es que, como podrá ver, es mucho más difícil
realizar cualquier acercamiento a un análisis estadístico válido que en el caso terminante, si lo
que quiere es ir más allá de los normales intervalos de confianza de 95% en media de medidas
de desempeño de Arena; así que si no necesita obtener esto, no debería hacerlo así.
Una precaución más antes de que avancemos con este material: como puede imaginar, las
longitudes de ejecución para simulaciones de estado estable necesitan ser más largas. Debido
a esto, hay más oportunidades para que Arena ordene sus operaciones internas de forma un
poco diferente, ocasionando que se usen de forma distinta el número aleatorio estimado (véase
capítulo 12). Esto de ninguna manera hace a su modelo “erróneo” o inadecuado, pero pue-
de afectar los resultados numéricos, en especial para modelos que tienen mucha variabilidad
estadística inherente a ellos. Así que si el lector sólo nos sigue con su computadora y ejecuta
nuestros modelos, hay una oportunidad de que obtenga respuestas numéricas que difieran de
lo que reportamos aquí. No se asuste por ello ya que es, en cierta forma, esperado. Si ocurre
cualquier cosa, esto sólo amplía la necesidad de algún tipo de análisis estadístico de los datos
de la salida de la simulación, ya que la variabilidad puede venir no sólo de la “naturaleza” de las
propiedades del modelo, sino también de los temas computacionales internos.
En la sección 7.2.1 analizaremos la determinación del calentamiento y longitud de ejecu-
ción. La sección 7.2.2 describirá la estrategia de la réplica truncada para el análisis, que es por
mucho el enfoque más sencillo (y, de alguna forma, el mejor). Un enfoque diferente llamado
agrupar se analiza en la sección 7.2.3. Un pequeño resumen se brindará en la sección 7.2.4 y en
la sección 7.2.5 se mencionrán algunos otros temas de análisis de estado constante.
7.2.1 Calentamiento y longitud de ejecución

Como debe haber notado, nuestros ejemplos se caracterizan por un modelo que inicialmente se
halla en un estado vacío y ocioso. Esto significa que el modelo inicia con el vacío de entidades
y todos los recursos se encuentran ociosos. En un sistema terminante, tal puede ser la forma en
que de hecho las cosas inician, así que todo está bien. Pero en una simulación de estado estable
se supone que las condiciones iniciales no importan y que la ejecución avanza para siempre.
De hecho, sin embargo, aún en una simulación de estado estable hay que inicializar y dete-
ner de alguna forma la ejecución. Y puesto que el lector está haciendo una simulación en primer
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
Figura 7-9. La entrada Total WIP completa en el módulo Statistic (Estadística)
(Variables de proceso básico → Entidad → Número en proceso), seleccionamos Part 1

como el Entity Type (Tipo de entidad), y obtuvimos EntitiesWIP(Part 1) para la
Current Expression (Expresión actual), que es parte de lo que queremos. Tecleando un
+ después de eso y seleccionando Part 2 para el Entity Type (Tipo de entidad), otro
+, a continuación Type 3 para el Entity Type (Tipo de entidad) nos da por último
EntitiesWIP(Part 1) + EntitiesWIP (Part 2) + EntitesWIP (Part 3),
que es el WIP total. Esto creará una entrada etiquetada Total WIP en Category Over-
view (Vista general de categoría) (bajo User Specified [Especificado por el usuario]) dando
el promedio del tiempo y el máximo del número total de partes en proceso.
< Sin embargo, también deseamos rastrear la “historia” de la curva Total WIP durante
la simulación más que sólo obtener las estadísticas de resumen después de la ejecución,
ya que queremos “echar un vistazo” cuando parezca que se haya estabilizado esta curva
para especificar un Warm up Period (Periodo de calentamiento) razonable. Podría co-
locar una Plot (Gráfica) animada en su modelo, así como hicimos antes; sin embargo,
esto puede desaparecer tan pronto como presione el botón End (Fin) y también estará
sujeta a variaciones quizá largas, nublando su juicio acerca del punto de estabilización.
Necesitamos guardar la historia de la curva y hacer más gráficas permanentes y también
tenemos que graficar la curva de varias réplicas para mitigar el problema del ruido. Para
realizar eso hicimos una entrada del nombre del archivo, Total WIP History.dat,
en el campo Output File (Archivo de salida) de la entrada Total WIP en el módulo
Statistic (Estadística), que guardará la información necesaria en dicho archivo, la cual se
puede leer en el Output Analyzer (Analizador de salida) de Arena (véase la sección 6.4)
y graficamos después de completar la ejecución. Dependiendo de qué tan larga sea su
ejecución y cuántas réplicas quiera, este archivo puede volverse bastante grande ya que
le está pidiendo mantener muchos detalles, información dentro de la ejecución (nuestra
ejecución, descrita más abajo, resultó en un archivo de cerca de 176 KB). La entrada
completa en el módulo Statistic (Estadística) aparece en la figura 7-9.
< Puesto que en este punto no estamos interesados en la animación, ingresamos en la opción
Run > Run Control (Ejecutar > Control de ejecución) y revisamos Batch Run (No Anima-
tion) (Ejecución de grupo sin animación) para acelerar las cosas. También despejamos todas
las cajas debajo de Statistics Collection (Recolección estadística) en Run > Setup > Project
Parameters para aumentar la velocidad aún más. Para obtener un sentido de la variación,
especificamos 10 para el Number of Replications (Número de réplicas) en Run > Setup >
Replication Parameters; ya que ahora estamos interesados en largas ejecuciones de desem-
peño de estado estable, aumentamos la Replication Length (Longitud de réplica) de 32 ho-
ras (1.33 días) a 5 días. Libremente admitimos que éstas son configuraciones mucho más
arbitrarias y nos basamos en ellas después de alguna prueba y error. Para el registro, tomó
menos de dos segundos ejecutar todo esto en una computadora portátil de 2.13 GHz.
Para hacer una gráfica de WIP frente a tiempo en el Output Analyzer (Analizador de salida)
(véase la sección 6.4 para la base del Output Analyzer), creamos un grupo nuevo de datos y le
Figura 7-10. El cuadro de diálogo Plot (Gráfica) del Output Analyzer
añadimos el archivo Total WIP History.dat. Después seleccionamos Plot (Gráfica) (

o Graph > Plot (Graficar > Gráfica)), añadimos el archivo .dat (al seleccionar All [Todos] en el
campo Replications [Réplicas] del cuadro de diálogo Data File [Archivo de datos]), tecleamos
un Title (Título) y cambiamos las Axis Labels (Etiquetas de los ejes); los cuadros de diálogo que
resultan se muestran en la figura 7-10.
La figura 7-11 muestra la gráfica resultante de WIP entre las simulaciones, con las curvas
para las diez réplicas sobrepuestas. De esta gráfica, parece claro que en lo que concierne a
la salida WIP, la longitud de ejecución de cinco días (7 200 minutos, en las Base Time Units
[Unidades de tiempo base] usadas por la gráfica) es suficiente para que el modelo se asiente
y también resulta bastante claro que el modelo no está “explotando” con las entidades, como
sería el caso si el proceso no pudiera mantenerse con las llegadas. Como para un Warm up Pe-
riod (Periodo de calentamiento), el efecto de las condiciones iniciales de vacío y ocioso para los
primeros varios cientos de minutos en WIP es evidente en el extremo izquierdo de cada curva
y razonablemente consistente entre réplicas, pero parece que las cosas se asientan después de
2 000 minutos; redondeando un poco hacia arriba para ser conservadores, seleccionaremos 2
días (2 880 minutos) como nuestro periodo de calentamiento.
Figura 7-11. Gráficas WIP dentro de la ejecución para el modelo 7-2

316 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.
7.2.2 Réplicas truncadas

Si el lector puede identificar un periodo de calentamiento, y si este periodo es razonablemente
corto con relación a las longitudes de ejecución que planea hacer, entonces la situación es bas-
tante sencilla para el análisis estadístico de estado estable: sólo realice réplicas IID (es decir,
independiente e idénticamente distribuidas, en caso de que lo haya olvidado), como se hizo
para las simulaciones de término en el capítulo 6, excepto que el lector también especifica un
periodo de calentamiento para cada réplica en Run > Setup > Replication Parameters. Con
estos valores específicos apropiados de calentamiento y longitud de ejecución, sólo proceda a
hacer réplicas independientes y lleve a cabo sus análisis estadísticos como en el capítulo 6 con
réplicas independientes calentadas para calcular así el estado estable más que las cantidades
terminadas. La vida es buena.
Esta idea aplica a la comparación o selección de alternativas (secciones 6.4 y 6.5) y a la
búsqueda óptima (sección 6.6), así como al análisis de sistemas sencillos. Sin embargo, podría
haber diferentes periodos de calentamiento y longitud de ejecución necesarios para alternativas
diferentes; en realidad no se tiene la oportunidad de controlar esto entre las diferentes alterna-
tivas que OptQuest puede decidir considerar, así que probablemente se ejecute su modelo antes
de tiempo por un rango de escenarios posibles y se especifique que el calentamiento sea (por lo
menos) el máximo de aquellos que experimentó.
Para las réplicas de cinco días del modelo 7-2, introdujimos en Run > Setup > Replication
Parameters el 2-Day Warm-up Period (Periodo de calentamiento de 2 días) que determinamos en
la sección 7.3.1 y de nuevo pedimos diez réplicas. Puesto que ya no necesitamos guardar la his-
toria dentro de la ejecución, borramos la entrada Output File en el módulo Statistic. Llamamos
al modelo resultante modelo 7-3 (note nuestra práctica de guardar los cambios sucesivos en los
modelos con nombres diferentes de manera que no cubramos nuestras huellas en caso de que ne-
cesitemos regresar a algún punto). El resultado fue un intervalo de confianza de 95% para el WIP
promedio esperado de 16.39 ± 6.51; del modelo 7-2 sin calentamiento, obtuvimos 15.35 ± 4.42,
que ilustra el efecto de desviación descendente del periodo inicial de baja congestión. Para ver esta
diferencia con mayor claridad, ya que estos intervalos de confianza son bastante amplios, hicimos
100 réplicas (en lugar de diez) y obtuvimos 15.45 ± 1.21 para el modelo 7-3 y 14.42 ± 0.88 para
el modelo 7-2. Note que los intervalos de confianza, basados en el mismo número de réplicas, son
más amplios para el modelo 7-3 que para el modelo 7-2; esto es porque cada réplica del modelo
7-3 emplea datos sólo de los últimos tres días mientras que cada réplica del modelo 7-2 usa los
cinco días completos, dándole menor variabilidad (en el precio de una desviación perjudicial de
inicio, que sentimos que es un intercambio deseable a favor de truncar como en el modelo 7-3).
Si se desea mayor precisión en la forma de intervalos de confianza más angostos, podría
lograrlo al simular “algo más”. Sin embargo, ahora tiene una alternativa para decidir si realizar
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.
7.2.3 Agrupar en una sola ejecución

Algunos modelos toman bastante tiempo para el calentamiento de estado estable, y puesto
que cada réplica tendría que pasar a través de esta larga fase de calentamiento, la estrategia de
réplica truncada de la sección 7.2.2 puede volverse ineficiente. En este caso, podría ser mejor
realizar sólo una ejecución realmente larga y por lo tanto tener que “pagar” el calentamiento
sólo una vez. Modificamos el modelo 7-3 para hacer una sola réplica con una longitud de 50
días incluyendo un (único) calentamiento de dos días (llamamos a esto modelo 7-4); éste es el
mismo “esfuerzo” de simulación que hacer las diez réplicas de longitud de cinco días cada una
y toma alrededor de la misma cantidad de tiempo para la computadora. Puesto que queremos
graficar los datos WIP dentro de la ejecución, reestablecimos una entrada de nombre de archivo
en el campo Output File en el módulo de datos Statistic, llamándola Total WIP History
One Long Run.dat (como es una ejecución larga, pensamos que también merecía un nom-
bre de archivo largo). La figura 7-12 grafica el Total WIP en esta ejecución. (Por ahora, ignore
las barras verticales anchas que dibujamos en la gráfica.)
Figura 7-12. Total WIP en una sola ejecución de 50 días

318 Capítulo 7
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).
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.
7.2.4 ¿Qué hacer?

Le hemos mostrado cómo atacar el mismo problema mediante un par de métodos diferentes
y dado a entender que hay muchos más métodos ahí afuera. Así que ¿cuál debe usar? Como
siempre, la respuesta no es obvia (le advertimos que el análisis de salida de estado estable es
difícil). Algunas veces hay intercambios entre resultados científicos y simplicidad conceptual (y
práctica), y precisamente tal es el caso aquí.
En nuestra opinión (y no queremos vender en la calle esto como nada más que una opinión),
deberíamos sugerir la siguiente lista, en orden descendente de importancia:
1. Intente salir de una vez del hecho de hacer una simulación de estado estable al
convencerse a usted mismo (o a su patrón) que las suposiciones apropiadas de
modelado realmente suponen condiciones específicas de inicio y término. Vaya al
capítulo 6 (y no regrese aquí).
2. Si su modelo es tal que el calentamiento es relativamente corto, probablemente el
enfoque más sencillo y directo es la réplica truncada. Esto tiene un atractivo intuitivo
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.2.5 Otros métodos y objetivos para el análisis estadístico de estado estable

Hemos descrito dos estrategias diferentes (réplicas truncadas y medias por intervalos) para ha-
cer análisis estadístico de estado estable; ambos métodos se encuentran disponibles en Arena.
Ésta ha sido un área que recibe mucha atención entre los investigadores, así que hay muchas
otras estrategias para tan difícil problema: modelado econométrico de series de tiempo, análisis
espectral de la ingeniería eléctrica, modelos regenerativos para procesos estocásticos, series de
tiempo estandarizadas, así como variaciones en las medias por intervalos como separación o
peso de los lotes. Si el lector se encuentra interesado en explorar estas ideas, consulte el capítulo
9 de Law y Kelton (2000), un documento de investigación como Sargent, Kang y Goldsman
(1992), o examine con detenimiento un nuevo volumen del anuario Proceedings of the Winter
Simulation Conference, donde por lo general hay seminarios, encuestas y documentos que cu-
bren los últimos desarrollos de tales materias.

Ahora el lector debe de tener un muy buen conjunto de habilidades para llevar a cabo un mode-
lado bastante detallado y comprender temas (y saber qué hacer al respecto) como verificación y
análisis estadísticos de estado estable. En el siguiente capítulo ampliaremos esto para mostrarle
cómo modelar operaciones complicadas y realistas de manejo de material. En los capítulos
siguientes se profundizará en las capacidades de modelado y análisis de Arena para explotar su
estructura jerárquica poderosa y flexible.
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).
Part Type Workstation/Process Time Workstation/Process Time Workstation/Process Time

(Tipo de parte) (Estación de trabajo/Tiem- (Estación de trabajo/Tiem- (Estación de trabajo/Tiem-
po de proceso) po de proceso) po de proceso)
A C
Part 1 (Parte 1) 5.5, 9.5, 13.5 8.5, 14.1, 19.7
A B C
Part 2 (Parte 2) 8.9, 13.5, 18.1 9, 15, 21 4.3, 8.5, 12.7
A B
Part 3 (Parte 3) 8.4, 12, 15.6 5.3, 9.5, 13.7
B C
Part 4 (Parte 4) 9.2, 12.6, 16.0 8.6, 11.4, 14.2
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
llegada es en el tiempo 0. Los registradores de equipaje van directamente al contador de regis-

tro de maletas para registrarlas —el tiempo para lo cual se distribuye TRIA(2, 4, 5)— luego
proceden a rayos X y después van a la puerta. Los compradores de boletos van directamente al
contador para comprar sus boletos —el tiempo para lo cual se distribuye EXPO(7)— proceden
a rayos X y después van a la puerta. Quien continúa va directamente a rayos X, luego al conta-
dor de la puerta para obtener un pase de abordar, el tiempo para lo cual se distribuye TRIA(1,
1.5, 3). Los tres contadores se programan todo el tiempo con un agente cada uno. El tiempo
de rayos X es EXPO(1). Todos los tiempos de viaje son EXPO(2), excepto para el tiempo de
quienes continúan a rayos X, que es EXPO(3). Ejecute su modelo por 920 minutos y recopile
estadísticas de la utilización del recurso, colas y tiempo del sistema desde la entrada hasta la
puerta para todos los clientes combinados.
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).
Part Type % Machine/Process Machine/Process Machine/Process Machine/Process

(Tipo de parte) Time (Máquina/ Time (Máquina/ Time (Máquina/ Time (Máquina/
Tiempo de Tiempo de Tiempo de Tiempo de
proceso) proceso) proceso) proceso)
1 12 1 2 3 4
10.5, 11.9, 13.2 7.1, 8.5, 9.8 6.7, 8.8, 10.1 6, 8.9, 10.3
2 14 1 3 2
7.3, 8.6, 10.1 5.4, 7.2, 11.3 9.6, 11.4, 15.3
3 31 2 4 1 3
8.7, 9.9, 12 8.6, 10.3, 12.8 10.3, 12.4, 14.8 8.4, 9.7, 11
4 24 3 4 3 2
7.9, 9.4, 10.9 7.6, 8.9, 10.3 6.5, 8.3, 9.7 6.7, 7.8, 9.4
5 19 2 1 4
5.6, 7.1, 8.8 8.1, 9.4, 11.7 9.1, 10.7, 12.8
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
From/To Machine 1 Machine 2 Machine 3 Machine 4 Exit System

(Desde/hacia) (Máquina 1) (Máquina 2) (Máquina 3) (Máquina 4) (Salida del
sistema)
Enter System 7, 11, 19 7, 11, 16 8, 12, 19
(Entra al sistema)
Machine 1 9, 13, 20 10, 13, 18 7, 9, 13
(Máquina 1)
Machine 2 8, 10, 15 7, 12, 18 7, 9, 12 8, 9, 14
(Máquina 2)
Machine 3 9, 13, 20 9, 14, 21 6, 8, 11
(Máquina 3)
Machine 4 11, 13, 17 10, 13, 21 6, 10, 12
(Máquina 4)
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.
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).
b) En un esfuerzo para aliviar la congestión añadida que introdujo el nuevo cliente, se

da al lector un presupuesto para comprar una máquina nueva y colocarla ya sea en la
Celda 1, 2 o 4 (no en la 3). ¿Dónde recomendaría colocarla en términos del número
total de partes de promedio de tiempo en las cuatro colas combinadas? Suponga que la
máquina nueva trabajará a la misma tasa que la máquina a la que se una en cualquiera
de las Celdas. Puede consultar la sección 6.5 y especificar sus propias estadísticas de
salida para usar PAN. Vea esto como una simulación terminada y haga 50 réplicas
con el objetivo de seleccionar la mejor ubicación para la máquina nueva; incluya para
su comparación un escenario de caso base en el cual no se añada máquina alguna en
ningún lugar.
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.
8.1 Tipos de transferencias de entidades

Al inicio, para transferir entidades entre módulos se usó la opción Connect (Conectar) (capítu-
lo 3), con el fin de transferir las entidades de manera directa entre los módulos, sin demora. En
el capítulo 4 se introdujo el concepto de Route (Rutear) que le permite transferir las entidades
entre las estaciones, con una demora en la transferencia. En primer lugar, se mostró cómo usar
Routes (Rutas) para la transferencia de entidades hacia una estación específica; a continuación,
en el capítulo 7, se generalizó este concepto mediante el uso de las Sequences (Secuencias).
Aun cuando esto proporciona la habilidad para modelar la mayor parte de las situaciones, a
veces se encuentra necesario limitar o restringir el número de transferencias que ocurren en cual-
quier punto en el tiempo. Por ejemplo, al modelar una red de comunicaciones, las vías tienen una
capacidad limitada. Por lo tanto, se debe contar con un método para limitar el número de mensajes
328 Capítulo 8
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).
Name Start Sequence

Logic
Transfer Out Seize Resource
Resource Name Transfer
Connect Type Route
Move Time Transfer Time
Units Minutes
Station Type By Sequence
Pantalla 8-1. El módulo Leave para los recursos
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
Name Cell 1 Station

Station Name Cell 1
Logic
Transfer In Release Resource
Resource Name Transfer
Pantalla 8-2. El módulo Enter para los recursos
Cell 1 Cell 2
Order Exit
Release System
Cell 4 Cell 3
Figura 8-1. La animación revisada para el pequeño sistema de fabricación

8.3 El pequeño sistema de fabricación con transportadores

Supongamos ahora que todas las transferencias de materiales se realizan con algún tipo de
Transporter, como carros, carretillas o montacargas de horquilla (se les dará el nombre de ca-
rros). Supongamos además que se tienen dos de estos carros, moviéndose cada uno de ellos a
50 pies por minuto, tanto cargados como vacíos. Cada uno de los carros sólo puede transportar
una pieza a la vez y se tienen tiempos de carga y de descarga de 0.25 minuto al principio y al
final de cada transporte. Se proporcionarán las distancias entre las estaciones después de que se
hayan agregado los carros al modelo.
Existen dos tipos de Arena Transporters (Transportadores de Arena): Free-Path (de Vía
Libre) y Guided (Guiados). Los Free-Path Transporters se pueden mover con libertad por el
sistema sin encontrar demoras debidas a la congestión. El tiempo de recorrido de un punto a
otro sólo depende de la velocidad del transportador y de la distancia que se va a recorrer. Los
Guided Transporters están restringidos a moverse dentro de una red predefinida. Sus tiempos de
recorrido dependen de las velocidades de los vehículos, las trayectorias que siguen de la red y
de la congestión potencial a lo largo de esas trayectorias. El tipo más común de vehículo guiado
es un vehículo guiado automatizado (AGV, automated guided vehicle). Los carros para el sistema
que se está tratando caen en la categoría de vía libre.
La transferencia de una pieza con un transportador requiere tres actividades: Request (Pe-
dir) un transportador, Transport (Transportar) la pieza y Free (Liberar) el transportador. Las
palabras claves son Request Transporter, Transport y Free Transporter. La actividad Request
Transporter, la cual es análoga a tomar un recurso, destina un transportador disponible a la en-
tidad solicitante y mueve el transportador destinado hasta la ubicación de esa entidad, si es que
no se encuentra ya allí. La actividad Transport hace que el transportador mueva la entidad has-
ta la estación de destino. Esto es análogo a una ruta pero, en el caso de un Transport, el trans-
portador y la entidad se mueven juntos. La actividad Free Transporter libera el transportador
para la solicitud siguiente, de modo muy semejante a la acción de liberación de un recurso.
Si en el sistema se tienen múltiples transportadores, se encaran dos aspectos referentes a su
repartición en las entidades. En primer lugar, se podría presentar la situación en el curso de la
ejecución en donde una entidad solicita un transportador y se encuentran disponibles más de
uno. En este caso, una Transporter Selection Rule (Regla de selección del transportador) determina
cuál de las unidades transportadoras satisfará con plenitud la solicitud. En la mayor parte de los
sistemas modelados, resulta adecuada la regla de la Smallest Distance (Distancia más corta), se
destina la unidad transportadora que se encuentra más cercana a la entidad solicitante. Otras
reglas incluyen la del Preferred Order (Orden preferido), Cyclical (Cíclica), Random (Aleatoria),
del Specific Member (Miembro específico) y de la Largest Distance (Distancia más larga) (aun-
que requiere una mente creativa para imaginar un caso en donde sería susceptible). El segundo
aspecto referente a la repartición de transportadores surge cuando se libera uno de estos y hay
múltiples entidades esperando y que han solicitado uno. En este caso, Arena aplica una prioridad,
destinando el transportador a la entidad en espera que tiene la prioridad más alta (el número de
prioridad más bajo). Si existe un empate de prioridades entre entidades, el transportador se desti-
nará a la entidad en espera que se encuentre más cercana.
8.3.1 Modelo 8-2: el modelo 8-1 modificado para los transportadores

Con el fin de representar los carros en el modelo del pequeño sistema de fabricación que se está
tratando, empecemos por definir los carros. Esto se hace con el módulo de datos Transporter que
se encuentra en el panel Advanced Transfer. Si el lector está construyendo el modelo conforme
334 Capítulo 8
Name Cart
Number of Units 2
Velocity 50
Pantalla 8-3. El módulo de datos Transporter
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.
Name Start Sequence

Delay 0.25
Units Minutes
Logic
Transfer Out Request Transporter
Transporter Name Cart
Selection Rule Smallest Distance
Save Attribute Cart #
Connect Type Transport
Station Type By Sequence
Pantalla 8-4. El módulo Leave para los transportadores
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.
Name Cell 1 Station

Station Name Cell 1
Logic
Delay 0.25
Units Minutes
Transfer In Free Transporter
Transporter Name Cart
Unit Number Cart #
Pantalla 8-5. El módulo Enter para los transportadores
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
Tabla 8-1. Las distancias de transferencia de la pieza
Hasta
Cell 1 Cell 2 Cell 3 Cell 4 Exit System
Order Release 37 74
Cell 1 45 92
Desde
Cell 2 139 55 147

Cell 3 45 155
Cell 4 92 118
Se introducen las distancias usando el módulo de datos Distance que se encuentra en el

panel Advanced Transfer. En la pantalla 8-6 se muestran las once entradas. En realidad, sólo
se necesita escribir la Distance, ya que las dos primeras entradas se pueden seleccionar de las
listas. También se debe de observar que se implica una dirección, de Order Release hacia
Cell 1, en el caso de la primera fila de la pantalla 8-6. Como fue el caso con el módulo Route,
se puede definir la distancia de Cell 1 hacia Order Release, si la distancia o el camino
son diferentes (pero, en este modelo, ninguna entidad toma jamás esa ruta, de modo que es
innecesario).
Echemos ahora un vistazo a la componente de animación para estas distancias. Ya se definió
la imagen del transportador, pero es necesario agregar las distancias a la animación. Si el lector va
construyendo este modelo conforme se describe en este libro, ahora sería un buen momento para
borrar todos los caminos de la ruta (pero dejar las estaciones), antes de adicionar las distancias.
Agréguense las distancias usando el botón Distance ( ) que se encuentra en la barra de herra-
mientas Animate Transfer. Hágase clic en este botón e incorpórense las distancias de manera muy
semejante a como se agregaron los caminos de la ruta en el modelo 4-4. Cuando se transporte una
pieza, el carro (y la pieza) seguirán estas líneas (o distancias) en la animación. Cuando se hace clic
en el botón Distance, aparece un cuadro de diálogo que permite seleccionar las estaciones From
(Desde) y To (Hasta) y modificar las características del camino, como en la pantalla 8-7. En este
caso, se especificó que la animación de la distancia fuera desde la estación Order Release
hasta la estación Cell 1, y no se pidió que el carro ni la pieza que va sobre éste se hicieran girar
o quitaran de improviso conforme se movieran a lo largo del camino. Estas características no son
necesarias, ya que todas las imágenes son cuadrados y círculos y, para facilitar su identificación,
se colocaron números en las piezas (se dejará como un reto para el lector que se imagine cuáles
números van con qué tipo de pieza).
Pantalla 8-6. Las distancias de transferencia de la pieza

Pantalla 8-7. El cuadro de diálogo Distance
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
Pantalla 8-8. El cuadro de diálogo Parking Area
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
Figura 8-2. Colocación de los objetos de animación Distance y Parking

Tabla 8-2. Movimientos posibles de los carros, incluyendo movimientos en vacío
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
Cell 3 71 92 129 45 155

Cell 4 34 55 92 139 118
Exit System 100 121 158 37 74
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.
8.3.2 Modelo 8-3: refinación de la animación para los transportadores

Si se ejecutó el modelo construido por el lector (o el dado con este texto) y se observó con cui-
dado la animación, se podría haber advertido que las piezas tuvieron tendencia a desaparecer
mientras estaban esperando que las levantara un carro. Esto sólo pasaba de modo temporal,
ya que reaparecían repentinamente en el carro justo antes de que se les separara del punto de
levantamiento. Si se advirtió esto, podría haberse puesto en duda la corrección del modelo.
Resulta que el modelo es exacto y este acto de desaparición sólo se debe a una imperfección en
la animación. Cuando llega una nueva pieza o ésta completa su procesamiento en una celda,
entra a una cola de peticiones para esperar su turno de solicitar un carro. Una vez que se destina
342 Capítulo 8
Cell 1 Cell 2
Order Exit
Release System
Cell 4 Cell 3
Figura 8-3. El pequeño sistema de fabricación con transportadores
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.
Figura 8-4. Los módulos Queue-Request-Delay-Transport: panel Blocks

Pantalla 8-9. El módulo de datos Storage
Enseguida, se necesitará seleccionar el módulo de datos Queue (panel Basic Process) y

agregar las cinco colas en donde las piezas esperan que llegue un carro: Start Sequence.
Queue, Route from Cell 1.Queue, Route from Cell 2.Queue, Route from
Cell 3.Queue y Route from Cell 4.Queue. En este punto, el lector podría estar pen-
sando: “¡ya se agregaron estas colas!” Está en lo correcto, pero se agregaron en los módulos
Leave que se acaban de borrar. Una vez que se haya completado esa tarea, se necesitará agregar
diez almacenamientos al módulo de datos Storage (panel Advanced Process), como se muestra
en la pantalla 8-9.
Como fue el caso con las colas faltantes, el atributo Cart # también se había definido en
los módulos Leave borrados. De modo que empecemos por agregar este atributo al módulo de
asignación (Assign) llamado: Assign Part Type and Sequence (Asignar tipo de
pieza y secuencia). En la pantalla 8-10 se muestra la asignación adicional. Se ha usado
este módulo Assign sólo para definir el atributo, de modo que la asignación de valor no tiene
significado. También se pudo haber usado el módulo Attributes del panel Elements para agre-
gar este atributo.
Por último, se puede editar la combinación de cuatro módulos que se señala en la figura
8-4. Se mostrarán las entradas de datos para las piezas que llegan y se permitirá asomarse por el
modelo con el fin de hallar, mediante el cálculo, las entradas para las cuatro celdas. Empecemos
con el módulo de datos Queue en donde sólo es necesario introducir el nombre de la cola, como
se muestra en la pantalla 8-11. Ésta es la cola en la cual las piezas esperarán hasta que se les
haya destinado un carro. Se le pudo haber omitido y Arena habría usado una cola interna para
contener las entidades en espera. Esto habría dado como resultado un modelo exacto, pero no
se hubiera podido animar la cola o revisar las estadísticas en relación con las piezas que esperan
la transferencia.
Type Attribute
Name Cart #
Value 0
Pantalla 8-10. Módulo Assign para definir el atributo Cart #
Queue ID Start Sequence.Queue
Pantalla 8-11. Definición de Start Sequence.Queue: el módulo de datos Queue

344 Capítulo 8
Storage ID Order Release Wait

Transporter Unit Cart(SDS,Cart #)
Entity Location Order Release
Pantalla 8-12. El módulo Request Block
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 #).
Duration 0.25
Storage ID Order Release Pickup
Pantalla 8-13. El módulo Delay Block
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
Transporter Unit Cart(Cart #)

Destination SEQ
Pantalla 8-14. El módulo Transport Block
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
(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.
8.4 Transportadores continuos

Habiendo incorporado los carros en el sistema para movimiento de materiales, reemplácelos aho-
ra con un sistema de transportadores continuos. Se mantendrá el sistema bastante sencillo y la
concentración se centrará en las técnicas de modelado. Supóngase que se desea un transportador
continuo de circuito cerrado que seguirá el camino principal del pasillo en la misma dirección del
sentido del movimiento de las manecillas del reloj, requerido para los transportadores. Se tendrán
puntos de entrada y de salida del transportador para las piezas en cada una de las seis ubicaciones
en el sistema. El transportador continuo se moverá a una velocidad de 20 pies por minuto. En la
figura 8-5 se dan las distancias de recorrido, en pies. También se supondrá que todavía existe un
requisito para la actividad de carga y descarga, de 0.25 minutos. Se supondrá además que cada
pieza tiene 4 pies por lado y que se quiere 6 pies de espacio del transportar en el desarrollo del
tránsito para proporcionar holgura en las esquinas y evitar cualquier daño posible.
Los transportadores continuos de Arena operan sobre el concepto de que cada entidad que
se va a transportar debe esperar en su ubicación hasta que se disponga de espacio suficiente en el
transportador, antes de que pueda tener acceso a éste. Un transportador continuo de Arena cons-
ta de celdas de igual longitud que se encuentran en movimiento constante. Cuando una entidad
intenta abordar el transportador, debe esperar hasta que, en ese punto, se dispongan de un nú-
mero definido de celdas consecutivas desocupadas. Una vez más, puede resultar de ayuda pensar
en términos de una escalera mecánica angosta en un aeropuerto, correspondiendo cada escalón
a una celda y personas diferentes que requieren números diferentes de escalones. Por ejemplo,
un viajero con varias maletas puede necesitar dos o tres escalones, en tanto que una persona sin
maletas puede precisar sólo de un escalón. Cuando se mira una escalera mecánica, el tamaño de
celda es más bien obvio. Sin embargo, si se considera un transportador de banda o de rodillos, el
tamaño de celda no es obvio en lo absoluto.
348 Capítulo 8
Cell 1 Cell 2
Order Exit
Release System
Cell 4 Cell 3
Figura 8-5. Longitudes del transportador continuo
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
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.
8.4.1 Modelo 8-4: el pequeño sistema de fabricación con transportadores

continuos no acumuladores
Ahora se está listo para incorporar los transportadores no acumuladores en el sistema. Si se
está construyendo este modelo junto con el del libro (después de todo, esa fue la idea), podría
ser que se quisiera considerar hacer otro cambio. Después de incluir los transportadores conti-
nuos y ejecutar el modelo, es probable que se encuentre que los tiempos de carga y descarga son
tan pequeños en relación con los otros tiempos que es difícil ver si el transportador está traba-
jando con propiedad. (En realidad, ya se ha ejecutado el modelo y se sabe que esto sucederá.)
Asimismo, puede ser que se desee realizar algo de experimentación para ver qué impacto tienen
estas actividades sobre el comportamiento del sistema. De modo que se sugiere se definan dos
nuevas variables, Load Time (Tiempo de carga) y Unload Time (Tiempo de des-
carga), y se fijen los tiempos iniciales para las dos en 0.25 minutos. A continuación, reemplá-
cense los tiempos constantes actuales con el nombre apropiado de la variable; lo que permitirá
hacer cambios globales para estos tiempos en un lugar.
Comiéncese por tomar el modelo 8-1 y, de nuevo, borrar los caminos de la ruta. Defínase
el transportador continuo usando el módulo de datos Conveyor del panel Advanced Transfer,
como en la pantalla 8-15.
Dos de estas entradas, Cell Size (Tamaño de celda) y Max Cells Occupied (Celdas ocupadas
como máximo), demandan algo de discusión. Con base en los resultados del modelo anterior, re-
sulta bastante claro que no hay gran cantidad de tráfico en el sistema. También, si se tiene una leve
demora antes de que una pieza pueda Acceder (Access) al espacio sobre el transportador, el único
impacto sería incrementar ligeramente el tiempo de ciclo de la pieza. De modo que se decidió
hacer las celdas del transportador tan grandes como fuera posible. Se elige un tamaño de celda de
3 pies, debido a que esto dará por resultado un número entero de celdas para cada una de las lon-
Name Loop Conveyor

Segment Name Loop Conveyor.Segment
Type Nonaccumulating
Velocity 20
Cell Size 3
Max Cells Occupied 2
Pantalla 8-15. El módulo Conveyor

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.
Name Start Sequence

Delay Load Time
Units Minutes
Logic
Transfer Out Access Conveyor
Conveyor Name Loop Conveyor
# of Cells 2
Connect Type Convey
Pantalla 8-16. El módulo Leave para los transportadores continuos

352 Capítulo 8
Name Cell 1 Station

Station Type Station
Station Name Cell 1
Logic
Delay Unload Time
Units Minutes
Transfer In Exit Conveyor
Pantalla 8-17. El módulo Enter para los transportadores continuos
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
Name Loop Conveyor.Segment

Beginning Station Order Release
Pantalla 8-18. El módulo de datos Segment

Pantalla 8-19. El módulo de datos Segment
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!).
Pantalla 8-20. El cuadro de diálogo Segment
Figura 8-6. Los segmentos del transportador continuo

354 Capítulo 8
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
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>
Figura 8-7. Cambio de variables con el Run Controller
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.

transportadores acumuladores
Cambiar el modelo de transportador continuo de modo que éste sea acumulador es muy fácil.
Se principia usando el comando File > Save as (Archivo > Guardar como) para guardar una
copia del modelo 8-4 como modelo 8-5. Sólo se necesitan hacer dos pequeños cambios en el
módulo de datos Conveyor. Cámbiese el Type del transportador continuo a Accumulating e
introdúzcase una Accumulation Length (Longitud de acumulación) de 4, como en la pantalla
8-21. La adición de la Accumulation Length permite que las piezas acumuladas sólo requieran
4 pies de espacio sobre el transportador. Nótese que este valor, el cual se aplica sólo cuando una
entidad se detiene sobre el transportador, no necesita ser un número entero de celdas. Cuando
se elimina el bloqueo, las piezas automáticamente retomarán el espacio de 6 pies, o dos celdas,
requeridas para transitar sobre el transportador.
Habiendo hecho estos cambios, córrase el modelo y se debe de notar que ocurre muy poca
acumulación. Puede confirmarse esto al mirar las estadísticas del transportador en el reporte
resumen. La acumulación promedio es menor que 1 pie y la utilización promedio es menor que
6%. Para aumentar la cantidad de acumulación, lo cual es una buena idea para realizar una
verificación, cámbiense sencillamente los tiempos de carga y descarga a 4 o 5 minutos. El efecto
debe de ser bastante visible.
Puede verse que estos resultados son muy semejantes a los del sistema no acumulador, ex-
cepto por los tiempos de la pieza en el sistema, los cuales son mucho más altos. Se sospecha con
intensidad que esto se debe al corto tiempo de ejecución y la variación estadística resultante
para el modelo. Se dejará al lector interesado que confirme (o refute) tal sospecha.
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

El movimiento de la entidad es una parte importante de la mayoría de los modelos de simu-
lación. En este capítulo, se han ilustrado varios de los medios de Arena para modelar ese movi-
miento en diferentes circunstancias, para tener en cuenta el modelado válido.
Éste es el último capítulo “tutelar” general sobre el modelado con Arena. Se ha profundiza-
do algo sobre las capacidades detalladas de nivel más bajo, así como los temas pormenorizados
correspondientes, como la eliminación de errores y la animación con ajuste fino. Aunque se ha
mencionado cómo se puede tener acceso y mezclarse en el lenguaje SIMAN de simulación, de
ninguna manera se ha cubierto; véase entonces Pegden, Shannon y Sadowski (1995) para obte-
ner un tratamiento completo de ese lenguaje. En este punto, el lector debe de estar armado con
un arsenal formidable de herramientas de modelado para permitirle atacar muchos sistemas,
eligiendo construcciones desde varios niveles, como resulte adecuado.
Sin embargo, existen más construcciones de modelado y, francamente, “trucos” que el lector
podría hallar prácticos. Éstos se abordan a continuación, en el capítulo 9.
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
WS B 100 150 0 100 200

WS C 250 100 100 0 100
Exit 350 250 225 100 0
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.
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.
8-7 Actualmente se está diseñando un prototipo de un nuevo sistema de inspección de equi-

paje para aeropuertos, como se muestra en la figura inferior. Las maletas arriban al sistema
con tiempos entre llegadas de EXPO(0.25) (todos los tiempos se dan en minutos) y se cargan
en un transportador continuo (75 pies de largo), llevándose hasta una zona de escaneo inicial.
En ésta, las maletas se dejan caer en un tobogán para que esperen el escaneo inicial, el cual
tiene una duración TRIA(0.1, 0.25, 0.35). Con base en los resultados del escaneo, las maletas
aceptadas (79%) se cargan en un transportador continuo de salida (40 pies de largo) y se con-
ducen hacia la salida del sistema, en tanto que las rechazadas se cargan en un transportador
continuo secundario (20 pies de largo) y se canalizan hasta una zona de escaneo secundario.
En esta última, las maletas se dejan caer en un tobogán para que esperen la realización de una
inspección visual, la cual tarda TRIA(0.6, 1.2, 1.4). Después de la inspección, se envían a través
de un escáner secundario que tiene 10 pies de largo. Este escaneo tarda 1.2 minutos y sólo una
maleta puede estar en el escáner a la vez. Al final del escáner secundario, otro inspector examina
las maletas, tardando EXPO(0.4). Con base en los resultados de esta inspección secundaria,
10% de las maletas se envían a una zona de rechazo para que reciban una inspección adicional,
las maletas aceptadas se cargan en un transportador continuo 2 de salida (20 pies de largo)
Escaneo
inicial
Maletas que llegan Tobogán
Salida del sistema
Salida del sistema
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.
8-8 Desarrolle un modelo de un sistema de cruce de andén en el que se agrupe y se transfiera

el material para el embarque posterior. Esta instalación tiene cinco andenes de entrada y tres de
salida. Los camiones llegan a cada uno de los andenes de entrada con cargas de material sobre
tarimas. El tiempo entre llegadas es UNIF(30, 60), entre las llegadas de los camiones a cada andén
de entrada (todos los tiempos se dan en minutos). Cada camión tendrá un número de tarimas ex-
traído de una distribución UNIF(10, 22) (redondeado hasta el entero más cercano) que necesitan
ser transferidas a uno de los andenes de salida. Suponga una probabilidad igual de que cualquier
tarima entrante vaya a cualquiera de los andenes de salida. Cuando los camiones llegan, un dispo-
sitivo automático de descarga baja las tarimas al andén de entrada. Suponga que esto no necesita
tiempo, de modo que las tarimas están inmediatamente listas para la transferencia. Las tarimas
se transfieren por medio de uno de cinco montacargas de horquilla hacia los andenes de salida,
los cuales están ubicados al otro lado del edificio. La distancia entre cualquier andén de entrada
y cualquiera de salida es de 75 pies y los montacargas viajan a 75 pies por minuto. El tiempo para
que un montacargas cargue una tarima es de UNIF(0.3, 0.4) y aquél para descargar una de éstas
es de UNIF(0.2, 0.4). La medida del desempeño que interesa es el tiempo promedio que una tari-
ma pasa en el sistema. (PISTA: Si coloca todos los montacargas en los andenes de salida, como su
posición inicial, no tiene que sumar las distancias entre los andenes de entrada.) Fije la longitud
de la ejecución para que sea de 720 minutos y considere ésta como una simulación de terminación.
Desarrolle un modelo para cada uno de los dos casos siguientes y anime sus modelos:
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
Un muestrario de aspectos y técnicas

adicionales de modelado
En los capítulos 4 al 8 se hizo un recorrido razonablemente completo en torno a cómo modelar

diferentes clases de sistemas, por medio de una sucesión de ejemplos cada vez más complicados
conforme se avanzaba. Se eligieron estos ejemplos con varios objetivos en mente, incluyendo la
realidad e importancia (según la experiencia de los autores) de la aplicación, la ilustración de
diversos aspectos del modelado y la indicación de cómo se puede hacer que Arena represente
cosas de la manera en que se desea (en muchos casos, con bastante facilidad y rapidez). Arma-
do con estas habilidades, el lector podrá construir una rica variedad de modelos de simulación
válidos y eficaces.
Pero ningún conjunto razonable de ejemplos digeribles podría posiblemente profundizar en
todos los rincones y grietas de las clases de aspectos del modelado (y, sí, en trucos) que, a veces,
la gente necesita considerar ni, mucho menos, en todas las características de Arena. No se preo-
cupe, tampoco se va a intentar en este capítulo. Pero sería conveniente señalar algo de lo que los
autores consideraron que son los aspectos y técnicas (y trucos) adicionales más importantes del
modelado y decirle al lector cómo hacer que Arena los lleve a cabo para él.
Se hará esto mediante la construcción de más ejemplos, pero éstos se enfocarán más hacia téc-
nicas específicas de modelado y características de Arena, de modo que tendrá un alcance menor.
En la sección 9.1 se refinarán los modelos de transportadores continuos que se desarrollaron en
el capítulo 8; en la 9.2 se discutirán unos cuantos refinamientos más del modelado para los trans-
portadores discretos de ese mismo capítulo. En los sistemas de servicios, en especial aquellos en
los que se tienen humanos haciendo cola, a menudo hay que considerar el cliente que abandona
(reneging) (en otras palabras, que se sale de la fila en algún punto); esto se abordará en la sección
9.3, junto con el concepto de renuncia (balking). En la 9.4 se irá hacia los métodos (más allá de las
colas que ya se han visto) para mantener las unidades en algún punto, así como la de formar lotes
con ellas con la posibilidad de separar el lote más tarde. En la 9.5 se discutirá cómo representar un
sistema firmemente acoplado, en el cual a las entidades se les tiene que dotar de recursos corriente
abajo de su posición actual, antes de que puedan seguir adelante; esto se conoce como recursos
traslapados desde el punto de vista de la entidad. Por último, en la sección 9.6, se mencionarán
con brevedad unos cuantos temas específicos, incluyendo los transportadores guiados, las colas
paralelas y la posibilidad de lógica compleja de decisión y formación de circuitos cerrados.
Este capítulo está estructurado de manera diferente a los primeros, en el sentido de que no
es imperativo que las secciones tengan que leerse en secuencia. Más bien, se pretende propor-
cionar un muestrario de técnicas de modelado y características de Arena que se han encontrado
útiles en una variedad de proyectos aplicados.
9.1 Modelado de transportadores continuos usando el panel

Transferencia Avanzada
En esta sección, se indican algunos refinamientos para los modelos básicos de transportadores
continuos que se describieron en el capítulo 8.
360 Capítulo 9
9.1.1 Modelo 9-1: almacenamientos intermedios finitos en las estaciones

En el capítulo 8 se dio una introducción a los transportadores continuos de Arena. En la sec-
ción 8.4.1 se desarrolló un modelo, modelo 8-4, para el pequeño sistema de fabricación que se
viene trabajando, usando transportadores continuos no acumuladores como el método para
transferir piezas dentro del sistema. En el desarrollo de ese modelo se supuso que había un al-
macenamiento intermedio infinito enfrente de cada celda, para el almacenamiento de las piezas
que esperan para ser procesadas. Esta hipótesis permitió usar las capacidades del transportador
continuo que se encuentran en los módulos Enter (Entrar) y Leave (Salir). Sin embargo, sí se ne-
cesitó agregar los módulos de datos Conveyor (Trasportador Continuo) y Segment (Segmento)
del panel Advanced Transfer para definir el transportador continuo.
Modifiquemos ahora esa hipótesis y supóngase que se tiene espacio limitado en las Cells 1
y 2 para el almacenamiento de las piezas no procesadas. De hecho, supongamos que, en cada
celda, sólo hay espacio para una pieza no procesada. Para este tipo de modelo, es necesario de-
finir lo que le sucede a la pieza que llega a la Cell 1 o a la 2 y encuentra que ya está otra ocupan-
do el espacio limitado de almacenamiento intermedio. Suponiendo que se pudiera determinar
una manera para limitar el almacenamiento intermedio usando el módulo Enter (no se puede
hacer), se estaría induciendo sencillamente a dejar que la pieza que llega esperara hasta que
la que ya está en ese almacenamiento se moviera hacia la máquina en esa celda. Por supuesto,
esto podría causar un estancamiento significativo en estas celdas. No sólo las piezas no podrían
entrar a la celda, sino que las piezas de camino a otras celdas formarían una cola detrás de ellas,
creando todavía otro problema. Resulta que las piezas procesadas que intentan salir de la celda
necesitan tener acceso a espacio en el transportador, antes de que puedan ser transportadas a
su siguiente estación de destino. Sí, el espacio al que están intentando tener acceso es el mismo
ocupado por la pieza que espera para entrar a la celda. Esto crearía lo que a veces se conoce
como paralización mutua o inmovilización por coacceso.
Por lo tanto, apliquemos la estrategia siguiente para las piezas que llegan a la Cell 1 o a la
2. Si, en ese momento, no se encuentra una pieza esperando en el almacenamiento intermedio
para la celda, a la pieza que llega se le permite entrar a éste. De lo contrario, a la pieza que llega
se le transporta alrededor del transportador de circuito cerrado de regreso al mismo punto para
intentar por segunda (o tercera, o cuarta, etc.) vez. Para realizar esto, se necesita alterar el mo-
delo de modo que se pueda tener mejor control cuando la pieza sale del transportador. El pa-
nel Advanced Transfer proporciona cinco módulos nuevos para los transportadores continuos
(Access [Tener acceso], Convey [Transportar], Exit [Salir], Start [Arrancar] y Stop [Detenerse])
que permiten modelar las actividades de estos transportadores con un nivel más detallado. El
módulo Exit hace que una entidad salga de un transportador, liberando la celda (o celdas) que
esté(n) ocupada(s). En esencia, esto es lo que sucede cuando se selecciona la opción Exit Con-
veyor (Salir del transportador) en el cuadro de diálogo Transfer In (Transferir hacia dentro)
del módulo Enter. El módulo Access hace que una entidad solicite o tenga acceso a espacio
sobre un transportador, en una ubicación específica, normalmente su ubicación en la estación
actual. El módulo Convey se usa para transportar la entidad hasta su destino, una vez que ha
tenido acceso con éxito al espacio requerido del transportador. En esencia, se está pidiendo a
Arena Access y Convey una entidad al seleccionar la opción Access Conveyor (Tener acceso
al transportador) en el cuadro de diálogo Transfer Out (Transferir hacia fuera) de los módulos
Leave. Los módulos Start y Stop hacen que el transportador inicie o detenga su movimiento,
respectivamente. Se pueden usar estos dos módulos para desarrollar una lógica propia de falla
o, en general, controlar cuándo se tiene parado o funcionando el transportador.
Un muestrario de aspectos y técnicas adicionales de modelado 361
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
Figura 9-1. Lógica del modelo nuevo para Cell 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.
Name Cell 1 Station

Station Name Cell 1
Pantalla 9-1. El módulo Station
Name Space in Cell 1

Type 2-way by Condition
If Expression
Value NQ(Cell 1 Process.Queue) == 0
Pantalla 9-2. El módulo Decide

362 Capítulo 9
Transportar
de regreso a
la Celda 1
Name Convey Back to Cell 1

Station Name Cell 1
Pantalla 9-3. El módulo Convey

Name Delay for Cell 1 Unload Time
En este punto, seDelay Time
podría pensar: “¡Pero Unload Time
la entidad ya está en la estación Cell 1!” Arena su-
Units Minutes
pone que la intención es transportar la entidad y la enviará por su camino. Por supuesto, tam-
bién supone que es físicamente posible transportar la entidad al destino especificado, lo cual
es el caso. Por consiguiente, el módulo Convey transportará la entidad sobre el transportador
designado hasta el destino especificado. Si la entidad ya no está sobre el transportador, Arena
responderá con un mensaje de error como mensaje de terminación.
Si la cola en la Cell 1 está desocupada, la entidad satisfará la condición y se enviará al módu-
lo Delay conectado, de la pantalla 9-4, en donde se le mantendrá en el módulo Delay: Delay
for Cell 1 Unload Time (Demorar durante el tiempo para descarga en
la Celda 1) en el transcurso del tiempo para descarga. Enseguida, se envía al módulo Exit,
el cual saca la entidad del transportador y libera las celdas ocupadas por éste, lo que se muestra
en la pantalla 9-5.
La Entity (Entidad) se envía del módulo Exit al módulo Process que representa la operación
real de maquinado, como se muestra en la figura 9-1. Una vez que la pieza finaliza su operación,
sale del módulo Process y se envía al siguiente módulo Access para obtener espacio sobre el
transportador, como se muestra en la pantalla 9-6.
El módulo Access destina las celdas del transportador de modo que la entidad entonces se
pueda transportar a su destino siguiente; en realidad, no transporta la entidad. Por lo tanto, si
no se hace que la entidad sea transportada de inmediato, esto provocará que todo el transpor-
tador se detenga hasta que esa entidad se transporte.
Name Convey Back to Cell 1
En el caso de que las celdas
Conveyor requeridas noLoop
Name estuvieran disponibles, la entidad residiría en la
Conveyor
cola [Access Conveyor at Cell 1.Queue
Station Name Cell(Tener
1 acceso al transportador en
Celda 1.Cola)] hasta que el espacio estuviera accesible. Esto suministra una manera para
Name Delay for Cell 1 Unload Time

Delay Time Unload Time
Units Minutes
Pantalla 9-4. El módulo Unload-Delay

Salir en la
Celda 1
Name Exit at Cell 1

# of Cells 2
Pantalla 9-5. El módulo Exit
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
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
Name Exit at Cell 1

# of Cells 2
Name Access Conveyor at Cell 1

# of Cells 2
Pantalla 9-6. El módulo Access

364 Capítulo 9
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
Figura 9-2. Lógica del modelo nuevo para Cell 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.
9.1.2 Modelo 9-2: piezas que permanecen sobre el transportador

durante el procesamiento
Ahora que el lector ha dominado estos nuevos módulos del transportador continuo, examine-
mos otro problema rápido. Empiécese con el modelo del transportador continuo acumulador,
modelo 8-5, presentado en la sección 8.4.2. Supóngase que se está intentando una nueva dispo-
sición del equipo, que requiere que se realicen las operaciones en Cell 2 con la pieza permane-
ciendo sobre el transportador. Específicamente, las piezas transportadas hasta Cell 2 no salen
del transportador, pero la pieza se detiene en esta celda, se realiza la operación real mientras esa
pieza se encuentra asentada sobre dicho transportador y, a continuación, la misma se transpor-
ta hasta su destino siguiente. Supuesto que el transportador es acumulador, las otras piezas que
se encuentren sobre él seguirán moviéndose, a menos que sean bloqueadas por aquélla sobre la
que se está operando en Cell 2.
Se podría implementar este nuevo giro si se reemplazan los módulos Enter y Leave para Cell
2 con un conjunto de módulos, de modo semejante a como se hizo para el modelo 9-1. Sin em-
bargo, ya que las entidades que llegan a Cell 2 no salen del transportador ni tienen acceso a éste,
existe una solución mucho más fácil. Se modificará la opción Transfer In del módulo Enter selec-
cionando la opción None (Ninguna). En este caso, la entidad no saldrá del transportador. Esto
hará que la entidad resida sobre el transportador mientras tiene lugar la operación definida por
el servidor. Sin embargo, si éste es el único cambio que se hizo, se presentará un error cuando la
entidad intente salir de la Cell 2. En el cuadro de diálogo Transfer Out del módulo Leave, con an-
terioridad se había seleccionado la opción Access Conveyor que hizo que la entidad intentara
tener acceso a espacio sobre el transportador y, puesto que la entidad permanecería sobre éste,
Arena quedaría confundido y terminaría con un error de tiempo de ejecución. Esto se arregla con
facilidad si se selecciona la opción None en el cuadro de diálogo Transfer Out de la sección Logic
(Lógica) del módulo Leave. Éstos son los únicos cambios requeridos en el modelo.
Se puede probar la nueva lógica del modelo si se observa la animación. Se sugiere se avance
rápido la simulación hasta cerca del tiempo 700, antes de empezar a observar la animación. En
este punto de la simulación, los efectos de estos cambios se vuelven bastante aparentes.
9.2 Más acerca de los transportadores (discretos)

En el capítulo 8 se presentaron los conceptos para modelar transportadores (discretos) y trans-
portadores continuos de Arena, utilizando la funcionalidad de la que se dispone en los módu-
los de alto nivel que se encuentran en el panel Basic Process. En la sección 9.1 se amplió más
esa funcionalidad para los transportadores continuos mediante el uso de módulos del panel
Advanced Transfer, para modificar y refinar los modelos presentados en el capítulo 8. Existen
también los mismos tipos de capacidades para los Transporters. Aunque no se va a desarrollar
un modelo completo usando estos módulos, se dará una breve cobertura de sus funciones y se
mostrará la secuencia requerida de módulos para modelar varias situaciones diferentes. Esto
puede ser suficiente para permitir el empleo exitoso de tales construcciones en los modelos pro-
pios. Recuérdese que la ayuda en Internet siempre está disponible.
Empecemos por las capacidades básicas cubiertas en la sección 8.3. En las secciones Trans-
fer In y Transfer Out de los módulos Leave y Enter se dispone de las construcciones fundamen-
tales de los transportadores discretos. Considérese el proceso de pedir un transportador y la
transferencia subsiguiente del mismo y de la entidad hasta su estación o ubicación siguientes.
Los módulos Request y Transport que se encuentran en el panel Advanced Transfer proporcio-
nan también esta capacidad.
El módulo Request (Pedir) da lugar a la primera parte de la sección Transfer Out del módu-
lo Leave y es casi idéntica a ella. Se adquiere la capacidad de rechazar la Velocity (Velocidad)
predeterminada, pero se pierde la de especificar Load Time (Tiempo de Carga). No obstante,
se puede incluir este último al dirigir entonces la entidad hacia un módulo Delay (Demora).
En realidad, el módulo Request realiza dos actividades, destinar un transportador a la entidad
y mover el transportador vacío hasta la ubicación de esa entidad, si ese transportador no está
ya allí. El módulo Transport realiza la parte siguiente de la actividad Transfer Out al iniciar la
transferencia del transportador y la entidad hasta su ubicación siguiente. Consideremos ahora
una situación de modelado en donde sería conveniente separar estas dos funciones. Supón-
gase que cuando el transportador llega a la ubicación de la entidad se tiene una operación de
carga que requiere la asistencia de un operario. Si se quiere modelar explícitamente el operario,
se necesitarán estos nuevos módulos. En la figura 9-3 se muestra la secuencia de módulos (Re-
quest-Process-Transport) requerida para modelar esta situación.
También se pueden separar las dos actividades del módulo Request, si se usan los módulos
Allocate y Move. El módulo Allocate destina un transportador a la entidad, pero lo deja en
su ubicación actual. El módulo Move permite que la entidad a la que se le ha destinado un
transportador mueva el transportador vacío hacia cualquier parte en el modelo. Cuando se
usa el módulo Request, el transportador se mueve de manera automática hasta la ubicación
de la entidad. Considérese la situación en donde el transportador vacío debe primero levan-
tar de una zona de tarimas un accesorio requerido para transportar la entidad. En este caso,
se necesita destinar el transportador, enviarlo a la zona de tarimas, levantar el accesorio y, por
último enviarlo a la ubicación de la entidad. En la figura 9-4 se muestra la secuencia de módulos
(Allocate-Move-Process-Move) requerida para modelar estas actividades.
Pedir mon- El operario

Transportar
tacargas de carga la
montacargas
horquilla pieza
Figura 9-3. Carga del transportador asistida por operario

366 Capítulo 9
Destinar Mover el monta- Demora por Mover hasta la

montacargas de cargas hasta la la carga del ubicación de
horquilla zona de tarimas accesorio la entidad
Figura 9-4. Accesorio requerido para la transferencia de la entidad
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.
9.3 Abandono por parte de la entidad
9.3.1 Renuncia y abandono por parte de la entidad

Se tiene una renuncia por parte de la entidad o del cliente cuando al llegar uno de ellos no se
une a la cola porque no hay espacio, sino que se aleja o se dirige hacia algún otro lugar. Se tiene
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
Figura 9-5. Comprobación de la necesidad del accesorio

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.
9.3.2 Modelo 9-3: un modelo de servicio con renuncia y abandono

Consideremos la renuncia y el abandono en el contexto de un modelo muy sencillo. Los clientes
llegan, con tiempos entre arribos EXPO(5), a un sistema de servicio con un solo servidor; el
tiempo de servicio es EXPO(4.25). Todos los tiempos se dan en minutos. Aun cuando la línea de
espera tiene una capacidad infinita, cada cliente que llega ve el largo de la fila en ese momento y
lo compara con su tolerancia para esperar. Si el número en la fila es mayor que su tolerancia, se
retirará del sistema. Se representará la tolerancia del cliente respecto a la renuncia mediante la
generación de una muestra a partir de una distribución triangular, TRIA(3, 6, 15). Puesto que
368 Capítulo 9
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)
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
Nótese el uso de la función matemática “máximo”, MX.

Existe un problema con esta lógica que se puede componer con facilidad: el número en la
cola no es exacto porque contendrá cualesquiera unidades que todavía no hayan abandonado.
Se puede componer esto enviando las entidades que hayan abandonado a un módulo Delay, en
donde se demoran en el tiempo para abandonar; también se especifica un Storage (por ejemplo,
Renege_Customers). Ahora se cambia la primera proposición de Decide
Si el Límite para renunciar > Número en la cola + NSTO(Renege_Customers) [Número en
almacenamiento(Renunciar_Clientes)]
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
Crear llegadas (Create Arrivals)

Asignar tiempo para abandonar = ERLA(15, 2)
Asignar tiempo de llegada: Enter System = TNOW (Entrar al sistema =…)
Asign
ar número en la zona de permanencia (Assign Stay Zone Number) =
POIS(0.75)
Asignar tolerancia para renunciar (Assign Balking Tolerance) = TRIA(3, 6, 15)
Crear Duplicar (Create Duplicate) entidad
Entidad original hacia la cola del servidor
Si Balk de la cola
Contar (Count) renuncias
Disponer (Dispose)
Delay for Service Time = EXPO(4.25)
Tally system time
Disponer (Dispose)
Duplicar entidad
Demora por tiempo para abandonar
Buscar (Search) en la cola respecto a la posición de la entidad original
Si No hay entidad original
Disponer
Si posición en la Cola <= Número en la zona de permanencia
Disponer
Eliminar (Remove) entidad original de la cola y Disponer
Contar (Count) Abandono de cliente
Disponer
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
Figura 9-6. La lógica del modelo de servicio

Name Assign Attributes

Type Attribute
Attribute Name Enter System
New Value TNOW
Type Attribute
Attribute Name Renege Time
New Value ERLA(15, 2)
Type Variable
Variable Name Server Queue Capacity
New Value TRIA(3, 6, 15)
Type Attribute
Attribute Name Stay Zone
New Value POIS(0.75)
Type Variable
Variable Name Total Customers
New Value Total Customers + 1
Type Attribute
Attribute Name Customer #
New Value Total Customers
Pantalla 9-7. El módulo Assign
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
Cola del servidor
Label Customer Queue

Queue ID Server Queue
Capacity Server Queue Capacity
Pantalla 9-8. El módulo Queue del panel Blocks
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-
Tomar
Servidor
Label Seize Server

Resource ID Server
Number of Units 1
Pantalla 9-9. El módulo Seize del panel Blocks
riable nombrada Search # (Buscar #). El atributo Customer # contiene un número

único asignado de cliente cuando ese cliente entró al sistema. Después, la entidad se envía al
módulo Search siguiente, del panel Advanced Process. Un módulo Search permite buscar en
una cola para hallar el rango, o posición en la cola, de una entidad que satisface una condi-
ción definida de búsqueda. Un rango en la cola de 1 significa que la entidad está al frente de
ella (la entidad siguiente que va a recibir servicio). En el modelo, se quiere hallar el cliente
original con el que se creó la entidad duplicada con la que se está realizando la búsqueda. Ese
cliente tendrá el mismo valor para su atributo Customer # que el que se acaba de asignar
a la variable Search #.
El módulo Search (pantalla 9-10) busca en un intervalo definido a partir de una condición
definida. Lo típico es que la búsqueda se hará en todo el contenido de la cola, desde 1 hasta
NQ. (Nótese que se puede realizar la búsqueda hacia atrás, especificando el intervalo como NQ
hasta 1.)
Sin embargo, se puede buscar en cualquier intervalo que requiera el modelo lógico creado.
Si se expresa un intervalo que sobrepasa el número actual en la cola, Arena terminará con un
tiempo de ejecución de error. Arena asignará a la variable J el rango de la primera entidad
en el curso de la búsqueda que satisfaga la condición y hará salir a esa entidad por el punto
normal de salida (rotulado Found [Hallado]). Si la condición contiene las funciones mate-
374 Capítulo 9
Hallado
Buscar en
cola del
servidor
No hallado
Name Search Server Queue

Type Search a Queue
Queue Name Server Queue
Starting Value 1
Ending Value NQ
Search Condition Search # == Customer #
Pantalla 9-10. El módulo Search
máticas MX o MN (máximo o mínimo), buscará en el intervalo completo. Si, en la condición

de búsqueda, se usan atributos, se interpretarán como el valor del atributo de la entidad en
la cola de búsqueda. Si la cola está vacía, o si ninguna entidad satisface la condición, se hará
salir la entidad por el punto inferior de salida (rotulado Not Found [No hallado])]. Por lo
común, se tiene interés en hallar el rango de entidad de modo que pueda eliminarse ésta de la
cola (módulo Remove) o hacer una copia de la misma (módulo Separate). También se puede
usar el módulo Search para buscar entidades que se han formado como un grupo temporal
con la utilización de un módulo Batch (Formar lotes). Además, se puede buscar cualquier
expresión de Arena.
Para el modelo, se quiere buscar en todo el intervalo de la cola, desde 1 hasta NQ, en rela-
ción a la entidad original que tiene el mismo valor Customer # que la entidad duplicada que
inicia la búsqueda. Si la entidad, o cliente, original ya no está en la cola, la duplicada saldrá a
través del punto de salida Not Found y se enviará al módulo Dispose siguiente. Si se encuen-
tra la entidad original, se guardará su rango en la cola, en la variable J. Entonces se envía la
entidad al módulo Decide siguiente. La comprobación en este módulo es para ver si el valor
de J es menor que el valor del atributo Stay Zone o igual a éste. Si esta condición es True
(Verdadera), implica que la posición del cliente en la cola es suficientemente buena como para
que elija permanecer en la fila. En este caso, se dispone de la entidad duplicada (véase la figura
9-6). Si la condición es False (Falsa), se quiere que el cliente original abandone. Por lo tanto, se
envía la entidad duplicada al módulo Remove siguiente.
El módulo Remove permite eliminar una entidad de una cola y enviarla a otro lugar del mo-
delo. Requiere que se identifique la entidad que se va a eliminar, introduciendo el identificador
de la cola y el rango de esa entidad. Si se intenta eliminar una entidad de una cola no definida o
una entidad con un rango que es mayor que el número de entidades en la cola especificada, Are-
Original
Eliminar de
la cola
Entidad
eliminada
Name Remove from queue

Queue Name Server Queue
Rank of Entity J
Pantalla 9-11. El módulo Remove
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.
9.4 Retención de entidades y formación de lotes con ellas

En esta sección se abordará la situación común en donde es necesario retener las entidades a lo
largo de su camino por diversas razones. También se discutirá más adelante cómo combinar o
agrupar las entidades y cómo separarlas.
9.4.1 Opciones de modelado

A medida que se empiezan a modelar sistemas más complejos, en ocasiones se desea retener las
entidades en un lugar en el modelo hasta que alguna condición del sistema permita que estas
entidades sigan avanzando. Se podría pensar que ya se ha cubierto este concepto, en el caso
en el que una entidad que está esperando en una cola por un recurso, transportador discreto
o espacio en un transportador continuo disponibles, permite que se retenga esa entidad hasta
que se dispone de ese recurso. Aquí se está pensando en términos más generales; la condición
no tiene que basarse sólo en la disponibilidad de un recurso, transportador o espacio en un
transportador continuo. Las condiciones que permiten que la entidad siga adelante se pueden
basar en cualesquiera condiciones del sistema; por ejemplo, tiempo, tamaño de la cola, etc. Se
cuenta con dos métodos diferentes para liberar las entidades retenidas.
En el primer método, se retienen las entidades en una cola hasta que reciben el permiso o
una señal para seguir avanzando proveniente de otra entidad en el sistema. Por ejemplo, con-
sidérese una intersección muy concurrida con un policía dirigiendo el tránsito. Piénsese en los
376 Capítulo 9
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.
9.4.2 Modelo 9-4: un ejemplo del proceso de formación de lotes

Artículos que llegan en forma aleatoria se encuentran en lotes antes de ser procesados. Se po-
dría pensar en el proceso como un horno en el que se curan los artículos que llegan en lotes. El
tamaño máximo del lote que se puede enviar al proceso depende de la capacidad del diseño. Su-
pongamos que cada artículo debe colocarse sobre un accesorio especial para el proceso, y que
tales accesorios son muy caros. El número de accesorios determina la capacidad del proceso.
Supongamos además que estos artefactos se compran en pares. Por lo tanto, el proceso puede
tener una capacidad de 2, 4, 6, 8, etc. Además, se considerará que el proceso requiere un tamaño
mínimo de lote de 2 antes de que pueda arrancarse.
Los artículos que llegan se envían a una zona de formación de lotes, en donde esperan que
haya disponibilidad del proceso. Cuando el proceso queda disponible, se debe determinar el
tamaño del lote para ese proceso, o hacer que éste espere la llegada de un número suficiente de
artículos adicionales para formar un lote viable. A continuación, se describe la lógica requerida
de decisión:
El proceso queda disponible:

Si el número de artículos en espera ≥ 2 y ≤ Lote máximo (Max Batch)
Formar el lote de todos los artículos
Fijar el número de artículos en espera en 0
Procesar el lote
Si, de otro modo, el número (Number) de artículos en espera > Lote máximo
Formar el lote del tamaño del lote máximo
Disminuir el número de artículos en espera en el lote máximo
Procesar el lote
Si, de otro modo, el número de artículos en espera < 2
Esperar que lleguen artículos adicionales
Mientras se tengan artículos disponibles, éstos se procesan. Sin embargo, si el número de

artículos es insuficiente (< 2) para formar el lote siguiente, el proceso se detiene temporalmente
y se requiere una demora adicional del momento de arranque, antes que pueda procesarse tal
lote. Debido a esta demora adicional del arranque puede ser que se desee esperar la llegada de
más de dos artículos antes de volver a arrancar el proceso.
Se desea desarrollar un modelo de simulación que ayude a concebir los parámetros de este
proceso. Se tiene un parámetro de diseño (la capacidad del proceso o Max Batch) y uno lógico
(reiniciar tamaño del lote) que interesan. Además, resultaría adecuado limitar el número de
entidades en espera en alrededor de 25.
Se diseñará el modelo de simulación y, a continuación, se utilizará OptQuest para Arena con
el fin de buscar la mejor solución con base en la minimización del número de veces que tenga
que volverse a arrancar.
En la figura 9-7 se muestra el modelo completado que ahora se desarrollará. Se podría ad-
vertir que existe un módulo nuevo: Batch del panel Basic Process. También se podría notar que
no se tiene un recurso definido para el proceso; no se requiere, ya que el modelo limitará a 1 el
número de lotes en el horno. Empecemos con el módulo Variable y el cuadro de diálogo Run >
Setup > Replication Parameters (Ejecutar > Configurar > Parámetros de réplica) y, enseguida,
pásese a la lógica del modelo. Más adelante, se discutirá el módulo de datos Statistic.
Se usa el módulo Variable para definir los dos parámetros que se emplearán en OptQuest: el
tamaño máximo de lote o capacidad del proceso, Max Batch, y el tamaño de lote para volver
a arrancar, Restart. En un inicio, estas variables se fijan en 10 y 4, respectivamente. En el
cuadro de diálogo Run > Setup > Replication Parameters se especifica una duración de la repli-
cación de 10 000 (todos los tiempos se dan en minutos).
Obsérvese ahora el proceso de llegada de los artículos: los módulos Create-Hold (Crear-
Retener) que están en la parte superior izquierda de la figura 9-7. Se emplea el módulo Create
para generar llegadas con tiempos exponenciales entre éstas. Se ha usado un valor de 1.1 como
la media del intervalo entre llegadas. No se requieren otras entradas para este módulo. Los
artículos que llegan se envían entonces al módulo Hold del panel Advanced Process. El módulo
Hold retiene las entidades hasta que se recibe una señal que corresponda de alguna otra parte
del modelo. La señal se puede basar en una expresión o un valor de atributo. Entidades diferen-
tes pueden estar esperando que lleguen señales diferentes, o bien, todas pueden estar esperando
la misma señal. Cuando se recibe una señal que corresponda, el módulo Hold liberará hasta un
número máximo de entidades con base en el Limit (Límite) (el cual se predetermina como infi-
nito), a menos que la señal contenga límites adicionales de liberación. Esto se explicará cuando
se cubra el módulo Signal (Señal).
378 Capítulo 9
Retener en Formar lotes Demorar en

Crear
espera de la con las enti- espera del
llegadas
señal dades proceso
0
0
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
Asignar Señal para Registrar

Disponer 1
tamaño del liberar el lote tamaño del
lote lote 0
Figura 9-7. El modelo de procesamiento por lotes
En el ejemplo, todas las entidades esperarán la misma señal, la cual se ha especificado de

manera arbitraria como Signal 1. Se ha predeterminado el Limit hasta infinito, ya que se fijará
un límite en el módulo Signal. También se ha requerido una Individual Queue (Cola individual),
Hold for Signal.Queue (Retener en espera de la señal.Cola), de modo que
se puedan obtener estadísticas y trazar la gráfica del número en la cola para la animación.
Consideremos ahora las condiciones en el inicio de la simulación. Nada hay procesándose;
por lo tanto, nada debe de suceder hasta la llegada del cuarto artículo, con base en el valor
inicial de Restart. Ya que los artículos que llegan no provocan que se envíe una señal, debe
ponerse en el modelo algún otro mecanismo para hacer que se realice el arranque de la primera
operación de formación de lotes y del proceso.
Este mecanismo se puede hallar en la secuencia de módulos Create-Hold-Delay-Record,
etc., que se encuentra hacia el centro de la figura 9-7. El módulo Create: Create Scan En-
tity (Crear entidad para escaneo) tiene Max Arrivals (Máximo de llegadas) fijado
en 1, lo cual da como resultado se libere una sola entidad en el tiempo 0. Esta entidad se envía
directamente al módulo Hold que sigue.
El módulo Hold: scan for Condition (Retener Escaneando respecto a la
condición), con el tipo especificado como Scan for Condition, permite retener una entidad
hasta que sea verdadera la condición definida por el usuario; en ese momento se permite que
la entidad parta del módulo. Las entidades que esperan se retienen en una cola definida por
el usuario (la predeterminada) o en una cola interna. Si una entidad entra a un módulo Hold
que no tiene entidades en espera, se comprueba la condición y se deja que siga su camino si
la evaluación de la condición da como resultado que es verdadera. Si no hay otras unidades
esperando, la entidad que llega se une a la cola con su posición basada en la regla seleccionada
para establecer el rango en esa cola, predeterminada como FIFO (primero en llegar primero en
salir, del inglés first in first out). Si no existen otras unidades esperando, se comprueba la condi-
ción de escaneo como la última operación, antes que se dispare cualquier avance de tiempo de
Escanear
respecto a la
condición
Name Scan for Condition

Type Scan for Condition
Condition NQ(Hold for Signal.Queue) >= Restart
Pantalla 9-12. El módulo Hold (Scan for Condition)

Name Assign Batch Size
Type Variable
evento discreto en cualquier parte en el modelo. Si la condición es verdadera, la primera entidad
Variable Name Batch Size
en la cola de escaneo se enviará al módulo siguiente. Arena permitirá que la entidad continúe
New Value MN(NQ(Hold for Signal.Queue), Max Batch)
hasta que sea momento para el avance siguiente de tiempo. En tal momento, la condición se
comprueba de nuevo. Por lo tanto, es posible que todas las entidades en espera se liberen del
módulo Hold al mismo tiempo, aun cuando cada entidad se procese por completo antes que se
permita que la siguiente siga adelante.
Para el modelo, se introdujo una condición que requiere al menos estén cuatro artículos
en la cola de espera precediendo el módulo Hold, antes que se satisfaga la condición (pantalla
9-12); nótese que se puede usar el Arena Expression Builder (Constructor de expresiones de
Arena) si se hace clic derecho en este campo. En ese momento, la entidad se enviará al módulo
Delay Delay for 8 Minutes (Demorar durante 8 minutos). Conforme se empiece
a comprender el modelo completo, se podrá caer en la cuenta de que se ha diseñado de modo
que nunca haya más de una unidad en la cola de escaneo.
Ahora, al inicio de la ejecución de la simulación se creará el primer artículo que llega y se
enviará a la cola Hold for Signal.Queue. (Retener por Señal.Cola) Al mismo
tiempo, el segundo módulo Create hará que una sola entidad llegue y se coloque en la cola
Scan for Condition.Queue. Nada sucede hasta que la primera cola tiene cuatro artícu-
los. En ese momento, la entidad se libera del segundo módulo Hold y se envía al módulo Delay,
en donde incurre en una demora deScan
Name 8 minutos, que equivale al tiempo para volver a arrancar
for Condition
el proceso. Téngase
Type en cuenta que, Scan
en el transcurso de esta demora adicional, pueden haber
for Condition
Condition
llegado artículos. A continuación, laNQ(Hold
entidad sefor
envía a un módulo Record,
Signal.Queue) en donde el número
>= Restart
Name Assign Batch Size

Type Variable
Variable Name Batch Size
New Value MN(NQ(Hold for Signal.Queue), Max Batch)
Pantalla 9-13. Asignación del siguiente tamaño del lote para el proceso
380 Capítulo 9
Señal para
liberar el
lote
Name Signal for Batch Release

Signal Value 1
Limit Batch Size
Pantalla 9-14. El módulo Signal
de arranques, contador de Startups (Arranques), se incrementa en 1. En el módulo Assign

siguiente se calcula el nuevo tamaño del lote para el proceso, Batch Size (Tamaño de
Lote) en la pantalla 9-13. Recuérdese que, al menos para la primera entidad, se sabe que se
tienen por lo menos cuatro artículos en la cola de espera. Por lo tanto, el tamaño del lote para
el proceso es el número en la cola de espera o el tamaño máximo del lote, si el número de los que
esperan es mayor que la capacidad del proceso.
Habiendo calculado el tamaño del lote siguiente y asignándole una variable global, Batch
Size, se envía la entidad a un módulo Signal, el cual se ve en la pantalla 9-14. Este módulo
envía una señal con un valor de 1 a través de todo el modelo, lo que se hace que se liberen
las entidades en la cola de espera, hasta un Batch Size máximo. Entonces esta entidad entra
en un módulo Record, en donde se hace concordar el siguiente tamaño del lote y, después, se
dispone de esa entidad.
Se pueden tener múltiples Signal y múltiples módulos Hold en el modelo. En este caso, un
módulo Signal enviará un valor de señal a cada módulo Hold con el Type especificado como
Hold for Signal y, de todos los módulos Hold en donde corresponda la Signal, se liberará
el número máximo especificado de entidades.
Ahora el proceso ha pasado por una demora del arranque y se ha liberado el primer lote
de artículos hacia el módulo Batch: Batch Entities (Formar lotes con las en-
tidades) que sigue al módulo Hold: Hold for Signal. El módulo Batch permite acu-
mular entidades que entonces se formarán en un lote permanente o temporal representado
por una sola entidad. En el ejemplo, se ha decidido formar un lote permanente. Por lo tanto,
se pierden los valores únicos de los atributos de las entidades con las que se formó el lote por-
que se dispone de ellos. Los valores de los atributos de la entidad representativa resultante se
pueden especificar como los de la Last (Última), First (Primera), Product (Producto) o Sum
(Suma) de las entidades separadas que llegan y con las que se forma el lote. Si se integra un
lote temporal, las entidades que forman éste se sacan de la cola y se retienen internamente
para volverse a instalar más adelante usando un módulo Separate. También se puede formar
el lote de las entidades con base en un valor de criterio de acoplamiento. Si se forma un lote
permanente, todavía se puede usar el módulo Separate para volver a crear después el número
equivalente de entidades. Sin embargo, se han perdido los valores por separado de los atribu-
tos de estas entidades.
Name Batch Entities

Batch Size Batch Size
Pantalla 9-15. Formación del lote para el proceso
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
9.5 Traslape de recursos

En los capítulos 4 al 8 se concentraron los esfuerzos en la construcción de modelos usando los
módulos de los que se dispone en el panel Basic Process, el panel Advanced Process y el panel
Advanced Transfer. Aun cuando se usaron estos módulos en varios modelos diferentes, todavía
no se han agotado todas las capacidades.
A medida que se desarrollaron los modelos en los primeros capítulos, no sólo se tuvo interés
en introducir al lector a las nuevas construcciones de Arena, sino también se trató de cubrir
diferentes técnicas de modelado que podrían ser útiles. Se ha presentado de manera constante
material nuevo en la forma de ejemplos que requieren el uso de nuevas capacidades de mode-
lado. A veces, la fabricación de un buen ejemplo para ilustrar la necesidad de nuevas capaci-
dades de modelado es una tarea intimidante. Se tiene que admitir que el ejemplo que se está
cerca de presentar es en cierta medida un estiramiento, no sólo en términos de la descripción
del modelo, sino también en la manera en la que se desarrolla éste. Sin embargo, si el lector es
condescendiente con los autores de este libro a lo largo del desarrollo de tal modelo, creemos
que obtendrá varias adiciones prácticas para su caja de herramientas.

El sistema que se estará modelando es uno estrechamente acoplado, un sistema de producción
con tres estaciones de trabajo. Se han usado las palabras “estrechamente acoplado” debido al
proceso único de llegada de las piezas y porque se tiene un espacio limitado para el almacena-
miento intermedio de las mismas entre las estaciones de trabajo.
Se supondrá un abastecimiento ilimitado de materiales en bruto que se pueden entregar
al sistema al solicitarlos. Cuando una pieza entra a la primera estación de trabajo, de manera
automática se dirige una solicitud a un almacén adjunto para la entrega de una pieza de reapro-
visionamiento. Debido a que el almacén está realizando otras funciones, la pieza de reaprovisio-
namiento no siempre se entrega de inmediato. En lugar de modelar esta actividad con detalle,
se supondrá una demora exponencial de la entrega, con media de 25 (todos los tiempos se dan
en minutos), antes de actuar en relación con la solicitud. En ese punto, se supondrá que la pie-
za ya se encuentra lista para la entrega, siguiendo el tiempo para la entrega una distribución
UNIF(10, 15). Para iniciar la simulación, se considerará que dos piezas se encuentran listas
para su entrega a la primera estación de trabajo.
Las piezas de reaprovisionamiento que llegan a la primera estación de trabajo se retienen en

un almacenamiento intermedio hasta que esa estación queda disponible. Una pieza que entra
a la primera estación de trabajo de inmediato requiere un operario para su montaje. Se supone
que el tiempo de montaje es EXPO(9). Una vez que se completa el montaje, en la estación se
procesa la pieza, lo que dura TRIA(10, 15, 20). Entonces, la pieza completada se mueve hacia el
almacenamiento intermedio entre las estaciones 1 y 2. Tal espacio de almacenamiento interme-
dio está limitado a dos piezas; si el almacenamiento se encuentra lleno, se bloquea la estación 1
hasta que se disponga de espacio. Se supondrá que todos los tiempos de transferencia entre las
estaciones de trabajo son despreciables, o que tendrán efecto en tiempo de 0.
Se tienen dos máquinas casi idénticas en la estación 2. Sólo difieren en el tiempo que tardan
en procesar una pieza: los tiempos de procesamiento son TRIA(35, 40, 45), para la máquina
2A y TRIA(40, 45, 50), para la máquina 2B. Una pieza en espera será procesada por la primera
máquina que quede disponible. Si las dos máquinas están disponibles, se elegirá la máquina 2A.
En esta estación no se requiere montaje. Una pieza completada se transfiere a continuación a
la estación 3. Sin embargo, no hay almacenamiento intermedio entre las estaciones 2 y 3. Por
consiguiente, la estación 3 debe estar disponible antes que pueda ocurrir la transferencia. (¡En
realidad, ésta afecta el comportamiento del sistema!) Si tanto la máquina 2A como la 2B han
completado piezas (las cuales están bloqueando tales máquinas) que esperan para pasar a la
estación 3, la pieza de la máquina 2A se transfiere primero.
Cuando una pieza entra a la estación 3, requiere al operario de montaje (el mismo operario
usado para el montaje en la estación 1). Se supone que el tiempo de montaje es EXPO(9). El
tiempo para el proceso en la estación 3 es TRIA(9, 12, 16). La pieza completada sale del sistema
en este punto.
También se tienen fallas en cada estación de trabajo. Las estaciones 1 y 3 tienen un Up Time
(Tiempo a disponibilidad) medio de 600 minutos con un Down Time (Tiempo de interrupción)
medio para reparación de 45 minutos. Las máquinas 2A y 2B, de la estación 2, tienen Up
Times medios de 500 minutos y Down Times de 25 minutos. Todos los tiempos por la falla y la
reparación siguen una distribución exponencial. Un punto sutil, pero muy importante, es que el
Up Time sólo se basa en el tiempo que las máquinas están procesando piezas, no en el tiempo
transcurrido.
Ahora, para complicar todavía más las cosas, supongamos que se tiene interés en el porcen-
taje del tiempo en que las máquinas de cada estación se encuentran en los diferentes estados.
Esto debe de dar una gran percepción acerca de cómo mejorar el sistema. Por ejemplo, si la
máquina de la estación 1 se bloquea mucho tiempo, se podría querer considerar el incremento
de la capacidad de la estación 2.
Los estados posibles para las diferentes máquinas son los siguientes:
Estación 1: Processing (Procesamiento), Starved (Subalimentada), Blocked (Bloqueada),
Failed (Averiada), Waiting (Esperando) al operario de montaje y Setup (Montaje).
Máquinas 2A y 2B: Processing, Starved, Blocked y Failed.
Estación 3: Processing, Starved, Failed, Waiting al operario de montaje y Setup.
También resultaría atractivo seguir el rastro al porcentaje del tiempo que el operario de
montaje pasa en las estaciones 1 y 3. Estos estados serían WS 1 Setup (Montaje en WS 1), WS
2 Setup e Idle (Desocupado).
Éstas son medidas típicas usadas para determinar la efectividad de los sistemas estrecha-
mente acoplados. Proporcionan una gran cantidad de información sobre los que son los verda-
384 Capítulo 9
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
Demorar por Liberar Asignar pro- Demorar por

Asignar mon-
montaje en montaje en cesamiento en el procesa-
taje para WS 1
WS 1 WS 1 WS 1 miento
Asignar Tomar alma-

bloqueado cenamiento Liberar WS 1
en WS 1 intermedio
Figura 9-8. Llegada de la pieza y WS1 (Estación de Trabajo 1)
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.
9.5.2 Modelo 9-5: un sistema de producción estrechamente acoplado

En el desarrollo del modelo se usará una diversidad de módulos diferentes. Empecemos con
los módulos para el proceso de llegada y la Workstation 1 (Estación de trabajo 1), los cuales se
muestran en la figura 9-8.
Puesto que el lector ya ha visto casi todos los módulos que serán usados en este modelo, no
se darán todas las pantallas. Sin embargo, se proporcionará suficiente información para que el
lector pueda recrear el modelo por sí mismo. Por supuesto, siempre se puede abrir el Model
09-05.doe y seguirlo detalladamente.
Empecemos con las llegadas iniciales que proporcionan las dos primeras piezas para el siste-
ma. Todas las llegadas restantes se basarán en una petición emitida cuando una pieza entra a la
máquina en la primera estación de trabajo. El sencillo módulo Create que se encuentra en la parte
superior izquierda de la figura 9-8 tiene tres entradas: un Name (Nombre), un Batch Size de 2 y
Conjunto de
estados
Pantalla 9-16. Los estados del StateSet de la WS 1
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
Pantalla 9-17. El módulo Seize WS 1
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.
Name Seize WS 1 Setup

Resources
Type Resource
Resource Name Setup Operator
Resource State WS 1 Setup
Pantalla 9-19. Toma del operario de montaje

A continuación, se dirige al módulo Seize: Seize WS 1 Setup (Tomar montaje en

WS 1), en donde se solicita el operario de montaje, mostrado en la pantalla 9-19. Nótese que se
especifica el estado del recurso de montaje como WS 1 Setup. Esto permite obtener estadís-
ticas de frecuencias acerca del Setup Operator Resource.
Por ahora, puede ser que el lector se esté rascando la cabeza y preguntándose: “¿Qué estoy
haciendo?” Bien, se le puso sobre aviso respecto a que este problema estaba un poco contorsio-
nado y, una vez que se finalice con el desarrollo de la Workstation 1, se le dará un repaso de alto
nivel de la secuencia completa de los eventos. De modo que continuemos.
En el módulo Assign que sigue Assign Setup for WS 1 (Asignar montaje para
WS 1), se fija el recurso WS 1 en el estado Setup y, después, se demora en el bloque Delay:
Delay WS 1 Setup (Demorar por montaje en WS 1) para la actividad de montaje.
Después de completar el montaje, se libera el recurso Setup Operator, se asigna el estado
del recurso WS 1 en Processing y pasa por la demora por el procesamiento. Después del
procesamiento, se asigna el estado del recurso WS 1 en Blocked. En tal punto no se está se-
guro de que se tiene espacio en el almacenamiento intermedio en la Workstation 2 (Estación
de Trabajo 2). Ahora se entra al módulo Seize Buffer Seize para requerir el espacio de ese
almacenamiento del recurso Buffer. Una vez que se cuenta con el recurso de almacenamiento
intermedio, se libera el recurso WS 1 y se parte hacia la Workstation 2.
Ahora (¡Uf!; sentimos como que nos falta el aliento después de recorrer esta lógica), revise-
mos la secuencia de actividades para una pieza en la Workstation 1. Se empieza por crear dos
piezas en el instante 0; seguimos sólo una de ellas. Esa pieza se marca con su tiempo de llegada
y se genera y se le asigna un tiempo de entrega. Se registra el tiempo de entrega y la pieza se
encamina hacia la Workstation 1. Una vez que entra a ésta, se une a la cola para esperar por el
recurso WS 1. Habiendo tomado el recurso, sale del módulo Seize, en donde duplica la pieza
de reaprovisionamiento, la cual se envía de regreso hacia el lugar de donde partió la primera
pieza. La pieza entonces asigna el estado del recurso servidor en Waiting for setup y
Liberar alma- 0
Tomar WS 2 cenamiento Tener WS 2A Verdadero
intermedio
Falso
Demorar por el Asignar para WS

Asignar pro- Liberar WS
2A Estado de Tomar WS 3
cesamiento para procesamiento en
Recurso: para 2A 2A
WS 2A WS 2A
Bloqueado
Asignar pro- Demorar por el Asignar para WS

Tomar WS 3 Liberar WS
cesamiento para procesamiento en 2B Estado de Re-
para 2B 2B
WS 2B WS 2B curso: Bloqueado
Figura 9-9. Módulos de la Workstation 2

388 Capítulo 9
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.
Asignar espera Tomar el Asignar Demorar por Liberar

por el montaje montaje en montaje para el montaje en montaje de
en WS 3 WS 3 WS 3 WS 3 WS 3
Asignar pro- Demorar por el Liberar Registrar Disponer de la

cesamiento en procesamiento WS 3 tiempo del pieza
WS 3 en WS 3 ciclo
0
Figura 9-10. Módulos de la Workstation 3 (Estación de Trabajo 3)

Pantalla 9-20. El módulo Statistic para las estadísticas de frecuencias
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
WS 1 Resource Número de observaciones Tiempo promedio Porcentaje estándar Porcentaje restringido

Blocked 76 19.0329 2.89 2.89
Failed 54 47.5478 5.14 5.14
Processing 1.668 15.0505 50.21 50.21
Setup 1.668 9.0429 30.17 30.17
Starved 1 6.5662 0.03 0.03
Waiting for setup 662 8.7386 11.57 11.57
WS 2A Resource Número de observaciones Tiempo promedio Porcentaje estándar Porcentaje restringido

Blocked 616 16.1455 19.89 19.89
BUSY 1 28.8279 0.06 0.06
Failed 49 30.3818 2.98 2.98
Processing 714 49.3787 70.51 70.51
Starved 205 16.0090 6.56 6.56
WS 2B Resource Número de observaciones Tiempo promedio Porcentaje estándar Porcentaje restringido

Blocked 422 24.3547 20.56 20.56
Failed 51 22.7702 2.32 2.32
Processing 522 67.4234 70.39 70.39
Starved 177 19.0171 6.73 6.73
WS 3 Resource Número de observaciones Tiempo promedio Porcentaje estándar Porcentaje restringido

Failed 59 40.4841 4.77 4.77
Processing 1.666 12.2982 40.98 40.98
Setup 1.666 9.0603 30.19 30.19
Starved 636 11.2011 14.25 14.25
Waiting for setup 507 9.6755 9.81 9.81
Figura 9-11. El informe de frecuencias del sistema estrechamente acoplado
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.
9.5.3 Modelo 9-6: adición de estadísticas de los estados de las piezas

Antes de continuar con el desarrollo del modelo, describamos lo que es necesario hacer para
obtener la información deseada sobre el estado de las piezas. Lo que se quiere es el porcentaje
del tiempo que las piezas pasan en cada uno de sus estados definidos con anterioridad: Travel
to WS 1, Wait for WS 1, Wait for Setup at WS 1, Setup at WS 1, Process at WS 1, Blocked at
WS 1, Wait for WS 2, Process at WS 2, Blocked at WS 2, Wait for Setup at WS 3, Setup at WS
3 y Process at WS 3.
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
TNUM(Seize WS 1.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 ƀ
TAVG(Seize
FRQTIM(Frequency WS 2.Queue.WaitingTime)
ID, Category) ƀ
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
en donde WS 1 Resource (Recurso en WS 1) es el nombre de la estadística de frecuencia

definida con anterioridad (definida en el módulo de datos Statistic) y Setup es el nombre de la
categoría para el estado de montaje para el recurso en WS 1 (definido en el módulo de datos
StateSet).
Si se definen todas las expresiones de esta manera, las nueve expresiones restantes son:
Wait for Setup at WS 1 FRQTIM(WS 1 Resource, Waiting for Setup)/

Tot
Setup at WS 1 FRQTIM(WS 1 Resource, Setup)/Tot
Process at WS 1 FRQTIM(WS 1 Resource, Processing)/Tot
Blocked at WS 1 FRQTIM(WS 1 Resource, Blocked)/Tot
Process at WS 2 FRQTIM(WS 2A Resource, Processing)/Tot +
FRQTIM(WS 2B Resource, Processing)/Tot
Blocked at WS 2 FRQTIM(WS 2A Resource, Blocked)/Tot +
FRQTIM(WS 2B Resource, Blocked)/Tot
Wait for Setup at WS 3 FRQTIM(WS 3 Resource, Waiting for Setup)/
Tot
Setup at WS 3 FRQTIM(WS 3 Resource, Setup)/Tot
Process at WS 3 FRQTIM(WS 3 Resource, Processing)/Tot
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
Salida Valor
Blocked at WS 1 0.3881
Blocked at WS 2 5.4040
Process at WS 1 6.6783
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
Figura 9-12. El informe resumen con anexo
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
9.6 Unos cuantos aspectos diversos del modelado

La intención de los autores al escribir este tomo no fue intentar cubrir todas las funciones de
las que se dispone en el sistema de simulación de Arena. Todavía existen unos cuantos módulos
en los paneles Basic Process, Avanced Process y Advanced Transfer que no se han discutido. Y
se tienen muchos más en los paneles Blocks y Elements que se han despreciado por completo.
No obstante, en el tiempo libre del lector, se le alienta a que agregue los paneles que rara vez use
y coloque algunos módulos. El uso de las características de Help le dará una buena idea de lo
que se ha omitido en este libro. En la mayor parte de los casos, los autores sospechan que nunca
necesitará estas características adicionales. Antes de cerrar este capítulo, nos gustaría señalar
y discutir con brevedad unas cuantas características que no se han cubierto. No sentimos que
estos temas requieran una comprensión profunda; basta cierto conocimiento.
9.6.1 Transportadores guiados

Existe todo un conjunto de características diseñadas para usarse con los transportadores (dis-
cretos) guiados. Estas características son útiles no sólo para modelar los sistemas de vehículos
guiados automatizados (AGV, del inglés automated guided vehicle), sino también para sistemas
de almacenamiento y de manejo de materiales en los que se aplica el concepto de carro móvil,
peso, guía, accesorio, etc. Algo interesante es que también son muy buenas para representar
muchos aparatos de los parques de diversiones. Debido a que este tema fácilmente llenaría uno
o dos capítulos adicionales, se ha elegido no presentarlo en este libro. Empero, se puede hallar
una discusión completa de estas características en el capítulo 9 de Pedgen, Shannon y Sadowski
(1995).
9.6.2 Colas paralelas

Se tienen también muchos módulos especializados del panel Blocks, QPick y PickQ, que rara
vez se usan; pero si se les necesita pueden facilitar mucho la tarea de modelado. El módulo
QPick se puede usar para representar un proceso en donde se quiere levantar la entidad si-
guiente, para procesarse o para moverla, de dos o más colas diferentes, con base en alguna regla
de decisión. Básicamente, el módulo QPick se asentaría entre un conjunto de módulos Queue
separados y un módulo que reparta algún tipo de recurso escaso (por ejemplo, los módulos
Allocate, Request, Access o Seize). Digamos que se tienen tres corrientes diferentes de entida-
des que convergen a un punto, en donde intentan tomar el mismo recurso. Además, supóngase
que se quiere mantener separadas entre sí las entidades provenientes de cada corriente. En la
figura 9-13 se muestran los módulos requeridos para esta parte del modelo. Cada corriente de
entidades finalizaría enviando la entidad a su cola Detached (Separada) (en breve, se abundará
sobre una cola Detached). El enlace entre los módulos QPick y Queue se verifica por medio del
módulo Labels (Etiquetas). Cuando el recurso queda disponible, básicamente se pedirá al mó-
dulo QPick que determine de cuál cola seleccionar la entidad siguiente a la que se la designará
el recurso. Nótese también que, para que esto funcione, se debe usar el módulo Seize del panel
Blocks, no el módulo Seize del panel Avanced Process. Al emplear los módulos del panel Bloc-
ks, Arena no define en forma automática las colas, los recursos, etc. Por lo tanto, puede ser que
se tengan que colocar los módulos correspondientes de los paneles Basic Process o Elements
para definir estos objetos.
Se puede usar el módulo PickQ para representar un proceso en donde se tiene una sola
corriente de llegada y se aplicará una regla de decisión para seleccionar entre dos o más colas
en las cuales colocar la entidad. Supongamos que se tiene una corriente de entidades entrantes
Queue
Cola1
Queue QPick Seize
Cola 2
Queue
Cola 3
Figura 9-13. Uso de un módulo QPick
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
Figura 9-14. Uso de un módulo Pick Q

396 Capítulo 9
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.6.3 Lógica de decisión

Se presentan situaciones en donde se puede requerir una lógica compleja de decisión basada
en las condiciones en curso del sistema. Arena proporciona varios módulos en el panel Blocks
que podrían probar resultar útiles. El primero es un conjunto para el desarrollo de la lógica si-
entonces-de otra manera. Se pueden usar los módulos If (Si), ElseIf (DeOtraManeraSi), Else
(De otra manera) y EndIf (FinalizarSi) para desarrollar una lógica de ese tipo. En este texto, no
se explicarán estos módulos con detalle, pero se alienta al lector a que use Help si implementa
alguna lógica con estos módulos. Aun cuando estos módulos permiten desarrollar una lógica
poderosa, se necesita ser cuidadoso para garantizar que tal lógica está funcionando correcta-
mente. Estos módulos se encuentran diseñados para funcionar sólo cuando todos los módulos
entre un If y su correspondiente EndIf (incluyendo cualesquiera módulos ElseIf o Else en el
interior) se conectan en forma gráfica con Arena. Esto permite usar muchos módulos de Arena
dentro de la lógica If/EndIf, como Assign, Seize y Delay, pero impide el uso de aquellos que
no permiten conexiones gráficas, como Route, Convey y Transport. También existen un con-
junto de módulos para implementar la lógica hacer-mientras: los módulos While (Mientras) y
EndWhile (FinalizarMientras). También se aplican a estos módulos las mismas advertencias
dadas con anterioridad.
Si en realidad se necesita implementar este tipo de lógica, existen varias alternativas. La más
fácil es utilizar las opciones Label (Rotular) y Next Label (Enseguida rotular) para conectar los
módulos, en lugar de conexiones gráficas directas. Aunque esto funciona, no muestra el flujo
de la lógica. Una alternativa es escribir la lógica como un archivo .mod externo de SIMAN y
usar el módulo Include (Incluir), del panel Blocks, para anexar esta lógica en el modelo. Por
desgracia, no se dispone de esta opción para ser usada con el software de versión académica.
La opción más segura y que se usa con más frecuencia es la de aplicar una combinación de los
módulos Decide y Branch (Rama) para implementar la lógica. Esto siempre funciona, aunque
la lógica puede que no sea muy elegante.
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.
Paquetes que llegan Descarga 1 Descarga 2

10 pies 10 pies
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
Estación de Estación de Estación de

trabajo 6 trabajo 5 trabajo 4
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-
stations 1 y 3 para procesarse, pero se reciben piezas procesadas en el carro en la Workstation

2. Los tiempos de procesamiento son 8 + WEIB(4.4, 4.48) minutos, UNIF(8, 11) minutos y
TRIA(8, 11, 18) minutos para las Workstations 1, 2 y 3, respectivamente. Supóngase que todos
los tiempos de carga y descarga son despreciables.
Estación de trabajo 1
Dock Estación de trabajo 2
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
cesamiento de un lote, se saca del procesador y se coloca en un separador en donde se divide

en unidades de una libra. El proceso de separación requiere 0.05 minuto por libra. Nótese que
éste no es un “proceso de lotes”, sino más bien en cada unidad de tiempo de 0.05 se completa
una unidad de una libra. Tales unidades se envían hacia una de las tres máquinas para envolver.
Cada una de estas máquinas tiene su propia cola, enviándose la unidad a la cola más corta. Las
que envuelven son máquinas idénticas, excepto por los tiempos de procesamiento. Los tiempos
para envolver son constantes de 0.20, 0.22 y 0.25 minutos para las máquinas 1, 2 y 3, respec-
tivamente. Los productos envueltos son agrupados, por la máquina para envolver, en lotes de
seis, para el empaque final. Una vez que se tiene un grupo de seis artículos, se envía hacia una
empaquetadora en la que se envuelve el producto, lo cual dura 0.18 + WEIB(0.24, 4.79) mi-
nutos. Estos paquetes salen del sistema. Supóngase que todos los tiempos de transferencia son
despreciables.
a) Desarrolle una simulación y una animación de este sistema y ejecútela durante 1 000
minutos, observando las estadísticas sobre las utilizaciones de los recursos, las colas y
el número total de paquetes embarcados.
b) Modifique su modelo para incluir fallas en el proceso de envolver, con las característi-
cas siguientes para todas las máquinas correspondientes: EXPO(20) para los tiempos
de disponibilidad y EXPO(1) para los tiempos de reparación.
c) Agregue una verificación de la calidad en el modelo del inciso b). Cada media hora se
hace un escaneo, empezando con la primera cola de las máquinas para envolver, en
búsqueda de los productos que tengan más de cuatro minutos de haber sido produci-
dos; es decir, que salieron del procesador hace más de 4 minutos. Cualquiera de esos
artículos se saca de la cola y se dispone de él. Transcurren 3 segundos para hallar cada
artículo y sacarlo de la cola. Sígase el rastro del número de unidades extraídas.
9-7 Un pequeño sistema automatizado en una panadería produce hogazas de pan. La má-
quina amasadora suelta una porción de masa cada UNIF(0.5, 1.0) minutos. Esta porción de
masa entra a una tolva para esperar que haya espacio en el horno. La tolva soltará las porcio-
nes en grupos de cuatro y se colocarán sobre el área de carga del horno para esperar que haya
espacio en el transportador continuo de este último. Se tiene espacio sólo para un grupo de
porciones en el área de carga del horno. El transportador de éste tiene 10 cucharones, cada uno
de 1 pie de largo y se mueve a 0.35 pies por minuto.
a) Desarrolle su modelo usando los módulos Hold (Scan for Condition), Signal y Hold
(Wait for Signal) en su lógica para controlar el grupo de porciones. Ejecútelo durante
3 000 minutos y observe las estadísticas sobre el número de porciones en la tolva, la
utilización del horno y la salida de hogazas por hora.
b) Modifique su modelo del inciso a), reemplazando el módulo Hold (Scan for Condi-
tion) con lógica desarrollada con base en el módulo Decide.
9-8 Llegan clientes, con tiempos entre arribos distribuidos como EXPO(5) —todos los tiem-
pos se dan en minutos— a un pequeño centro de servicio que tiene dos servidores, cada uno
con una cola separada. Los tiempos de servicio son EXPO(9.8) y EXPO(9.5) para los Servers
(servidores) 1 y 2, respectivamente. Los clientes que llegan se unen a la cola más corta. Se pre-
senta cambio de cola de los clientes siempre que la diferencia entre las longitudes de las colas
es de 3 o más. En ese momento, el último cliente en la cola más larga se mueve hacia el final de
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.
10.1 Modelo 10-1: lectura y escritura de archivos de datos

Se empezará con modelo muy sencillo (de hecho, trivial) de un centro de atención telefónica.
Enseguida, se mejorará tal modelo de varias maneras interesantes. Este centro tiene una sola co-
rriente de llegada de llamadas generadas en forma aleatoria y un solo agente que procesa esas lla-
madas, después de lo cual se dispone de éstas. El gerente del centro ha estimado que las llamadas
entran con un intervalo promedio entre ellas de 1.1 minutos, según una distribución exponencial,
y que las duraciones de las mismas tienden a ser de alrededor de 0.75 minuto, con un rango de 0.3
Crear la Atender la Terminar la

llamada llamada llamada
Figura 10-1. Modelo de un centro sencillo de atención telefónica

404 Capítulo 10
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.
(Create module) [(Módulo Crear)]

Name (Nombre) Create Call (Crear llamada)
Entity Type (Tipo de entidad) Arrival Entity (Entidad Llegada)
Type (Tipo) Random (Expo) [Aleatorio (Expo)]
Value (Valor) 1.1
(Process module) [(Módulo Proceso)]
Name (Nombre) Handle The Call (Responder la llamada)
Action (Acción) Seize Delay Release (Tomar liberación de la
demora)
Resource Name (Nombre del recurso) Agent (Agente)
Delay Type (Tipo de demora) Triangular (Triangular)
Minimum (Mínimo) 0.3
Value (Valor) 0.75
Maximum (Máximo) 1.1
(Dispose module) [(Módulo Disponer)]
Name (Nombre) Terminate Call (Terminar llamada)
Pantalla 10-1. Los módulos Create (Crear), Process (Procesar) y Dispose (Disponer)
Replication Length (Duración de la replicación) 8

Time Units (Unidades de tiempo) Hours (Horas)
Pantalla 10-2. Parámetros de replicación

Integración y personalización de Arena 405
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
10.1.1 Modelo 10-2: lectura de llegadas de entidades desde un archivo de texto

Para hacer esta modificación al modelo del centro de atención telefónica, se requerirá un archi-
vo que contenga los tiempos de arribo durante el periodo que se va a estudiar y se necesitará
reemplazar la lógica del modelo para la creación de entidades con el fin de usar los datos de
este archivo. Para simplificar la lógica requerida, se estructurará el archivo de datos como un
archivo de texto ASCII que contenga los valores que correspondan a los tiempos de simulación,
suponiendo que la ejecución se inicia en el minuto 0 del tiempo. En la figura 10-2, se muestran
unos cuantos de los primeros valores de este archivo (Model 10-02 Input.txt). Como
los autores se pueden dar el lujo de estar escribiendo un libro de texto, en lugar de tener que
resolver problemas de la vida real, pasarán por alto los detalles de cómo se creó este archivo
ASCII. En la práctica, el lector probablemente encontrará que la información que puede obte-
ner no está almacenada de manera tan conveniente, pero con una aplicación creativa de la hoja
de cálculo o del software de base datos, por lo común puede exportar los puntos de los datos en
bruto hacia valores listos para la simulación en un archivo de texto.
Es necesario decidir cómo usar los datos históricos almacenados en el archivo de texto. Se
deben entonces enfrentar dos aspectos: la mecánica de la transferencia de datos, del archivo
hacia el modelo y, a continuación, cómo usar los valores para generar entidades en los tiempos
apropiados. En primer lugar se considerará la lógica requerida para crear las entidades en los
tiempos apropiados, cubriendo los detalles de lectura de los datos cuando se llegue a esa parte
de la lógica del modelo.
Hasta ahora, el procedimiento utilizado para la creación de las entidades ha sido usar un
módulo Create, el cual produce una entidad nueva una que otra vez, a todo lo largo de la
ejecución, con base en el tiempo entre llegadas. En la simulación a mano, se vio (¿recuerda el
lector las dificultades en el capítulo 2?) que en cada creación de entidad, la “que llega en ese
momento” se envía hacia el modelo y la entidad “siguiente en llegar” se coloca en el calendario
para arribar en el momento futuro apropiado. Los datos en la sección Time Between Arrivals
(Tiempo entre llegadas) del cuadro de diálogo determinan qué tanto después en el futuro se va
a programar la entidad siguiente en arribar; lo más frecuente es que esto comprenda el muestreo
de una distribución de probabilidad.
Sin embargo, para establecer las llegadas de las llamadas a partir del archivo de datos no se
puede formular una expresión sencilla para el tiempo entre llegadas. En lugar de ello, se usará
una unidad de control que imite la lógica de la entidad “que llega en ese momento” y de la
“siguiente en llegar” directamente del modelo, como se muestra en la figura 10-3. Los primeros
cuatro módulos que se muestran allí reemplazan el módulo Create del modelo original del cen-
tro de atención telefónica.
406 Capítulo 10
Separar en entidad Original

Crear entidad de Leer el momento Demorar hasta duplicada para
control para leer de la llegada el tiempo de la la llegada de la
los datos siguiente llamada actual llamada
Duplicada
Atender la Terminar la
llamada llamada
Figura 10-3. Lógica para generar entidades a partir de un archivo
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.
Name (Nombre) Create Control Entity to Read Data (Crear entidad de

control para leer datos)
Entity Type (Tipo de entidad) Arrival Entity (Entidad Llegada)

Type (Tipo) Constant (Constante)
Value (Valor) 1
Max Arrivals (Máx de llegadas) 1
Pantalla 10-3. El módulo Create (Crear) modificado

Name (Nombre) Read Next Arrival Time (Leer tiempo de

la llegada siguiente)
Type (Tipo) Read from File (Leer de archivo)
Arena File Name (Nombre de archivo de Arena) Arrivals File (Archivo de llegadas)
Attribute Name (Nombre del atributo) Call Start Time (Tiempo de inicio de la
llamada)
Pantalla 10-4. El módulo ReadWrite (LeerEscribir)
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
Pantalla 10-5. El módulo Delay (Demorar)

408 Capítulo 10
Name (Nombre) Separate into Duplicate Entity for Call Arrival (Separar en
entidad duplicada para llegada de llamada)
Pantalla 10-6. El módulo Separate (Separar)
Cuando la entidad de control completa la demora, es el momento de crear la entidad real

de la llamada y despacharla hacia la lógica del sistema. El módulo Separate (Separar) del panel
Basic Process funciona admirablemente para satisfacer esta necesidad, como se muestra en la
pantalla 10.6. Envía la entidad de control (el punto de salida del módulo rotulado Original) de
regreso al módulo ReadWrite, para obtener el tiempo de la llamada siguiente del archivo de
datos, y crea un duplicado de sí misma que se envía hacia la lógica del modelo por el punto de
salida rotulado como Duplicate (Duplicado) (como se mostró con anterioridad en la figura 10-
3). Esta entidad duplicada representa la llegada de una nueva llamada, la cual se moverá por el
resto de la lógica del modelo para procesar esa llamada.
El cambio final al modelo es especificar la información requerida acerca del archivo de datos.
Para hacerlo, se edita el módulo de datos File que se encuentra en el panel Advanced Process,
como se muestra en la pantalla 10-7. Cuando se tecleó Arrivals File como el Arena File
Name, en el módulo ReadWrite, Arena creó en forma automática una entrada correspondiente
en el módulo de datos File. Para completar la información requerida, se introduce Model 10-
02 Input.txt (Entrada del modelo 10-02…) como el Operating System File Name
(Nombre del archivo del sistema operativo). Esto le dice a Arena que tenga acceso a Model
10-02 Input.txt, almacenado en donde sea que esté ubicado el archivo del modelo, siem-
pre que un módulo ReadWrite haga referencia al Arena Arrivals File. (El lector podría
dar una ruta completa para el archivo, como C:\My Documents\Cool Stuff\Model
10-02 Input.txt, pero si decidiera enviar el modelo y el archivo de datos a alguien más,
tendrían que tener la misma estructura de la carpeta. Dependiendo de sus gustos acerca de los
nombres de las carpetas, ésta podría ser o no una buena idea.) Se dejan las otras opciones en
sus valores predeterminados, incluyendo el tipo de archivo como Free Format (Formato
libre), lo cual indica que el archivo Model 10-02 Input.txt contiene valores de texto.
También se retuvo la acción predeterminada de fin del archivo como Dispose, de modo que
se dispondrá de la entidad de control después de que lea el último valor que se encuentre en el
archivo, terminando efectivamente la corriente de llegadas de llamadas al modelo.
Name (Nombre) Arrivals File (Archivo de llegadas)

Operating System File Name (Nombre del Model 10-02 Input.txt (Entrada del modelo
archivo del sistema operativo) 10-02.txt)
Pantalla 10-7. El módulo de datos File
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
Figura 10-4. Datos de los tiempos de las llamadas en la tabla Access
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.

Access Type (Tipo de acceso) Microsoft Access (*.mdb)
Operating System File Name (Nombre del Model 10-03 Input.mdb (Entrada del modelo 10-
archivo del sistema operativo) 03.mdb)
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
Recordset Name (Nombre del conjunto de registros) ArrivalTimes (TiemposDeLlegadas)

Table Name (Nombre de la tabla) ArrivalTimes (TiemposDeLlegadas)
Pantalla 10-9. El Recordsets Editor

412 Capítulo 10
Recordset ID (ID del conjunto de registros) ArrivalTimes (TiemposDeLlegadas)
Pantalla 10-10. El módulo ReadWrite (LeerEscribir)
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
Figura 10-5. Datos de los tiempos de llamadas en la hoja de cálculo de Excel
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.

Access Type (Tipo de acceso) Microsoft Excel (*.xls)
Operating System File Name (Nombre del Model 10-03 Input.xls (Entrada del
archivo del sistema operativo) modelo 10-03.xls)

414 Capítulo 10

Named Range (Rango nombrado) ArrivalTimes (TiemposDeLlegadas)
Pantalla 10-12. El Recordsets 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.

Named Range (Rango nombrado) ArrivalTimes (TiemposDeLlegadas)
Recordset Name (Nombre del conjunto de registros) ProcessTimes (TiemposDeProceso)
Named Range (Rango nombrado) ProcessTimes (TiemposDeProceso)
Pantalla 10-13. El módulo Files y el Recordsets Editor
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
Demorar hasta Separar en en-

Crear entidad de Leer el tiempo que se alcance tidad duplicada
control para leer siguiente de el tiempo de la para la llegada Original
los datos llegada llamada real de la llamada
Duplicada
Escribir el
tiempo de pro-
llamada llamada
cesamiento
Figura 10-6. Lógica para escribir los datos de tiempo del proceso
416 Capítulo 10
Name (Nombre) Write Processing Time (Escribir Tiempo

de Procesamiento)
Type (Tipo) Write to File (Escribir para Archivo)
Arena File Name (Nombre de archivo de Arena) Arrivals File(Archivo de Llegadas)
Recordset ID (ID del conjunto de registros) ProcessTimes (TiemposDeProceso)
Type (Tipo) Other (Otro)
Attribute Name (Nombre del atributo) TNOW – Call Start Time
Pantalla 10-14. Escritura del tiempo del proceso en el módulo ReadWrite
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.
10.1.3 Lectura y escritura avanzadas

Aunque la vida sería fácil si los datos siempre vinieran en una sola forma, rara vez es el caso.
En lugar de ello, con frecuencia se reciben datos que no se ajustan a nuestro uso. En un caso
sencillo, podría ser un archivo de texto con un número excesivo de datos en él. Por ejemplo, ¿qué
pasa si el archivo de datos se mira como el de la figura 10-8?
Es evidente que estos valores se miran un tanto raros ya que las dos primeras líneas aparentan
que cada una contiene una palabra y dos números. La tercera línea se observa como que contiene
una palabra y un solo número. Pero, de hecho, es el mismo archivo que se presentó en la figura
10-2, excepto que contiene una descripción en las columnas 1 a la 8. Para leer este tipo de archivo,
se utilizaría una lectura formateada. Una manera sencilla de hacer esto es modificar el módulo
Figura 10-7. Datos de salida de tiempo del proceso con gráfica
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
Pantalla 10-15. Módulo File para datos formateados

418 Capítulo 10
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,
Name (Nombre) Read Next Arrival Time (Leer Tiempo de

la llegada siguiente)
Type (Tipo) Read from file (Leer de archivo)
Arena File Name (Nombre de archivo de Arena) Arrivals File (Archivo de llegadas)
Attribute Name (Nombre del atributo) JunkValue (ValorBasura)
Attribute Name (Nombre del atributo) JunkValue (ValorBasura)
Attribute Name (Nombre del atributo) Call Start Time (Llamar tiempo de
inicio)
Pantalla 10-16. El módulo ReadWrite para saltarse los datos extraños

Provider=Microsoft.JET.OLEDB.4.0;
Data Source=C:\Documents\Book1.xls;
Extended Properties=””Excel 8.0; HDR=Yes;””
Pantalla 10-17. Excel con encabezados usando ADO

Driver={SQL Server};
Server=RSI-Joe;
Database=BizBikes;
Uid=BizWareUser;
pwd=MyPassword
Pantalla 10-18. Comandos SQL usando ADO
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).
10.2 VBA en Arena

En esta sección, se presentan los conceptos que rodean a VBA, el cual está incrustado en Arena.
Se puede usar esta tecnología para escribir un código personalizado que aumenta la lógica del
modelo de Arena del usuario. En las secciones 10.3 y 10.4 se proporcionan unas cuantas ilus-
traciones de cómo funcionan juntos Arena y VBA.
420 Capítulo 10
10.2.1 Panorama general de ActiveX Automation y VBA

Arena explota dos tecnologías de Microsoft Windows que están diseñadas para mejorar la
integración de aplicaciones de escritorio. La primera, ActiveX® Automation, permite que las
aplicaciones se controlen entre sí y a sí mismas a través de una interfaz de programación. Es
una estructura “escondida” proporcionada por Windows, accesible a través de un lenguaje de
programación (como Visual Basic®) que se ha diseñado para utilizar las capacidades de Acti-
veX. De hecho, si se ha creado una macro en Excel, se ha aplicado esta tecnología, aun cuando
el usuario se haya dado cuenta o no. Las macros de Excel se almacenan como código VBA en
el que se utiliza una interfaz ActiveX para hacer que la aplicación Excel haga cosas como for-
matear celdas, cambiar fórmulas o crear gráficos.
Los tipos de acciones que una aplicación soporta son definidos por lo que se llama un mode-
lo de objetos, Los diseñadores de la aplicación (por ejemplo, los desarrolladores de Excel o Are-
na) construyen este modelo de objetos para suministrar una interfaz de modo que los lenguajes
de programación puedan hacer que la aplicación realice lo que un usuario normalmente haría
en forma interactiva con un ratón y el teclado. El modelo de objetos incluye lo siguiente:
< una lista de objetos aplicación que se pueden controlar (por ejemplo hoja de cálculo de
Excel, gráfico, celda);
< las propiedades de estos objetos que se pueden examinar o modificar (por ejemplo, el
nombre de una hoja de cálculo, el título de un gráfico, el valor de una celda), y
< los métodos (o acciones) que se pueden efectuar sobre los objetos o que éstos pueden
realizar (por ejemplo, borrar una hoja de calculo, crear un gráfico o combinar celdas).
Cuando se instala una aplicación que contiene un modelo de objetos, su proceso de montaje
registra aquél con el sistema operativo Windows (es decir, lo agrega a la lista de modelos de
objeto de los que se dispone en la computadora). Entonces, si se aplica un lenguaje de progra-
mación y se quiere utilizar la funcionalidad de la aplicación, se puede establecer una referencia
a su modelo de objetos y programarlos directamente. Se verá cómo funciona esto cuando se
escriba un código VBA en Arena para enviar datos a Microsoft Excel. Muchas aplicaciones
de escritorio se pueden automatizar (es decir, ser controladas por otra aplicación), incluyendo
Microsoft Office, AutoCAD® y Visio®. Para crear el programa que controla la aplicación, se
pueden usar lenguajes de programación como C++, Visual Basic o Java.
La segunda tecnología explotada por Arena para la integración de aplicaciones incrusta
un lenguaje de programación (VBA) directamente en el propio Arena para permitir escribir el
código que automatice otras aplicaciones sin tener que comprar o instalar un lenguaje separado
de programación. VBA es el mismo lenguaje que funciona con Microsoft Office, AutoCAD y
Arena. También es el mismo motor que se encuentra detrás de Visual Basic. Cuando el lector
instala Arena, también recibe este entorno completo de programación Visual Basic, al que se
tiene acceso a través de Tools > Macro > Show Visual Basic Editor (Herramientas > Macro >
Mostrar Editor de Visual Basic).
Estas dos tecnologías funcionan juntas para permitir que Arena se integre con otros progra-
mas que soportan ActiveX Automation. Se puede escribir el código Visual Basic directamente
en Arena (a través del Visual Basic Editor) que automatiza otros programas, como Excel, Auto
CAD o Visio. En la mejora del modelo del centro de atención telefónica, se creará una nueva
hoja de cálculo de Excel, se le poblará de datos en el curso de la ejecución de la programación y
construirá en forma automática una gráfica de los datos, todo sin “tocar” Excel de manera di-
recta. También se puede escribir código VBA para automatizar Arena, como agregar variables
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.
10.2.2 Eventos VBA integrados en Arena

El panel Project (Proyecto) que está en el lado izquierdo de la ventana del Visual Basic Editor
muestra una lista de modelos abiertos, conteniendo cada uno a su vez una lista de los Arena
Objects (Objetos de Arena) que se inicia con una sola entrada llamada ThisDocument (EsteDo-
cumento). El objeto ThisDocument da al proyecto VBA acceso a varios eventos dentro del mo-
delo de Arena. Para agregar el código para un procedimiento de evento, selecciónese el objeto
Figura 10-9. Ventana del Visual Basic Editor

422 Capítulo 10
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)
2. Arena hace las verificaciones e inicializa el modelo
3. RunBeginSimulation (IniciarEjecuciónDeSimulación)
4. RunBeginReplication (IniciarEjecuciónDeReplicación)
5. Arena ejecuta la replicación
OnKeystroke (GolpeDeTeclaParaAcción)
UserFunction (FunciónDelUsuario), etcétera
6. RunEndReplication (FinalizarEjecuciónDeReplicación)
7. RunEndSimulation (FinalizarEjecuciónDeSimulación)
8. Arena termina la ejecución de la simulación
9. RunEnd (FinalizarEjecución)
Figura 10-10. Eventos VBA en la ejecución de la simulació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
detectó errores en el modelo, no se llamará a este evento; en primera instancia, se tienen

que arreglar las equivocaciones para dar lugar a la inicialización apropiada del modelo.)
Cuando se está ejecutando el código VBA en RunBeginSimulation, Arena mantiene
suspendido el arranque de la simulación. Por lo tanto, en este punto, se pueden cargar
con seguridad grandes cantidades de datos provenientes de fuentes exteriores como Excel,
Access u Oracle®; desplegándose una UserForm para pedir a quienquiera que sea el que
está ejecutando el modelo un aviso oportuno, como cuántos turnos se desean ejecutar en
la simulación de hoy; o establecer los encabezamientos en un archivo de Excel en el que
se estarán almacenando algunos resultados detallados de la simulación (como se verá en
el modelo 10-6). A menudo, este código finalizará asignando valores a las variables en el
modelo de Arena, aunque también podría crear entidades, alterar las capacidades de los
recursos, o docenas de otras funciones que se encontrarán si se profundiza en el modelo
de objeto de Arena. Una vez que el código VBA RunBeginSimulation ha finalizado la
realización de su trabajo, Arena se mueve hacia el paso siguiente.
4. Se llama a ModelLogic_RunBeginReplication.
Para cada replicación que se ha definido para esta ejecución, Arena llamará a
RunBeginReplication al principio de tales replicaciones (es decir, antes de que se
haya introducido al modelo cualquier entidad). Los tipos de cosas que se podrían hacer
aquí son semejantes a las descritas para RunBeginSimulation, excepto que, cualquiera
que sea lo que se defina en RunBeginReplication se repetirá al principio de cada
replicación. En el modelo 10-6 se verá cómo se pueden usar juntos estos dos eventos.
5. Arena ejecuta la simulación.
A continuación, se ejecuta el modelo. En este paso, se crean las entidades y se dispone
de ellas, se toman y se liberan los recursos, etc.; básicamente, se pone a trabajar todo lo
que el lector ha aprendido con sufrimiento a lo largo de los capítulos anteriores de este
libro. En el transcurso de la ejecución, Arena proporciona varias oportunidades para
activar el código VBA, como las siguientes:
< ModelLogic_UserFunction: se llama siempre que se hace referencia a la
variable UF en la lógica de Arena. Se podría utilizar este evento para realizar
cálculos complejos para la demora de un proceso o el criterio de decisión.
< ModelLogic_VBA_Block_Fire: se llama cuando una entidad pasa a tra-
vés de un módulo VBA (del panel Blocks) en la lógica del modelo. En el mo-
delo 10-6 se aplica este evento para escribir información detallada en Excel, a
medida que cada entidad parte del modelo.
< ModelLogic_OnKeystroke: se llama siempre que el usuario golpea una
tecla en el curso de la ejecución de la simulación. Por ejemplo, el código VBA
podría presentar una UserForm con el estado resumen del modelo siempre
que se presione la tecla “1”.
< ModelLogic_OnClearStatistics (ActivarEliminarEstadísti-
cas); se llama siempre que se eliminan las estadísticas, como cuando el tiem-
po de simulación llega al valor introducido para el periodo de calentamiento
en el cuadro de diálogo Run Setup. Aquí se podría escribir el código VBA
para fijar ciertas variables del modelo o para enviar una entidad hacia este úl-
timo, con el fin de activar la lógica especializada que aumente la inicialización
estándar de Arena de las estadísticas.
6. Se llama a ModelLogic_RunEndReplication si la simulación llega al final de

una replicación.
Lo típico es que, en este evento, se almacene el código VBA que escribe la información
resumen en un archivo externo, se incrementen algunas variables globales o se realicen
ambas cosas. Nótese que sólo se llama cuando la ejecución llega al final de una
replicación; si aquélla se suspende por alguna otra causa (como que el usuario haga clic
en el botón End de la barra de herramientas Run), entonces no se ejecuta este evento.
7. Se llama a ModelLogic_RunEndSimulation.
Sin importar la manera en que Arena finalice la ejecución, en este evento, se ejecutará
el código VBA. Cuando se llama a RunEndSimulation todavía se tienen disponibles
los datos del tiempo de ejecución de la simulación, de modo que, en este punto, el código
VBA puede tener acceso a los valores finales de las estadísticas, los estados de los recursos,
etc. Por lo común, RunEndSimulation contiene la lógica para escribir estadísticas
personalizadas en archivos, hojas de cálculo o bases de datos, así como un código de
“limpieza” para cerrar los archivos o desplegar mensajes de fin de la ejecución.
8. Arena termina la ejecución de la simulación.
Ésta es la contraparte del paso 2. Arena elimina todos los datos del tiempo de ejecución
de la simulación y regresa el modelo a un estado de edición.
9. Se llama a ModelLogic_RunEnd.
Por último, se llama al evento ModelLogic_RunEnd, que proporciona un balance
para el evento RunBegin del paso 1. En tal evento, el código VBA no puede tener
acceso a información de ningún tipo de la ejecución que se acaba de realizar (porque el
malintencionado paso 8 anterior la quitó), pero se dispone de todas las demás funciones
del código VBA. Si se desea, podría desplegarse una UserForm en el RunEnd que
pregunte si el usuario quiere ejecutar otra vez la simulación, ¡de modo que se enviará de
forma automática de regreso al paso 1, para arrancar de nuevo el proceso!
10.2.3 Modelo de objetos de Arena

Una vez que se haya decidido en dónde ubicar el código, es probable que haya necesidad de
tener acceso a información de Arena. El modelo de objetos (también conocido como biblioteca
de tipos) proporciona una lista de objetos y sus propiedades, así como de los métodos de los que
se dispone para el código. La totalidad de la información que necesita el código proveniente
de Arena y todas las acciones que ese código hace que el programa realice serán llevadas a la
práctica mediante la utilización de elementos del modelo de objetos del propio Arena.
Un objeto es algo que se puede controlar desde el código. Sus características, mencionadas
como propiedades, se pueden examinar en VBA, y muchas de las propiedades también se pue-
den cambiar mediante el código. Ejemplos de las propiedades de objetos incluyen los colores
de líneas para los rectángulos, las polilíneas, etc.; las posiciones (x y y), y los identificadores
para los objetos de animación, como las estaciones y las colas. La mayor parte de los objetos
también tienen métodos que se pueden llamar para hacer que se realice una acción; por ejemplo,
la activación de una ventana o la creación de un polígono nuevo. Asimismo, la mayor parte de
los tipos de objetos se agrupan en colecciones, las cuales son sencillamente uno o más objetos
del mismo tipo (por lo común). En la biblioteca de objetos de Arena se tiene una colección de
Modules, por ejemplo, que contiene todos los casos de módulos (los cuales son objetos del tipo
Module), en una ventana de submodelos.
426 Capítulo 10
Figura 10-11. El navegador de objetos de VBA
Si al usuario le gustaría examinar la biblioteca de objetos, VBA proporciona un práctico

navegador, que se abre al seleccionar View > Object Browser (Ver > Navegador de objetos) en la
ventana de Visual Basic Editor o al presionar la tecla F2. Esto permite navegar por las bibliote-
cas de objetos, examinar estos últimos así como sus propiedades y métodos. En la figura 10-11
se muestra la pantalla del navegador para el objeto de la colección Status Variables (Variables
de estado) y su método Create, en la biblioteca de objetos de Arena.
El modelo de objetos de Arena contiene las siguientes categorías de objetos:
< Objetos de ventanas de modelos: Todo lo que se puede colocar en una ventana de modelo
de Arena o verse a través de su hoja de cálculo. Los módulos, conexiones, líneas, polígo-
nos, texto, los objetos de animación y los objetos relacionados con interacciones, como
vistas nombradas, se ajustan en esta categoría.
< Objeto SIMAN: El tipo especial de objeto que proporciona acceso a la información
acerca de la ejecución de la simulación, como valores de las variables, capacidades de los
recursos, longitudes de las colas y tiempo en curso de la simulación.
< Objetos estructurales: Los objetos que se utilizan para tener acceso a las funciones ge-
nerales de Arena, como los objetos Application, Module Definition (Definición del mó-
dulo) y Panel.
Cuando se escribe un código que simule lo que de manera normal se realizaría en forma
interactiva (es decir, a través del ratón o del teclado), se estará trabajando principalmente con
objetos que caen en la categoría de ventanas de modelos. Estos objetos también constituyen la
mayor parte de aquellos que se verán si se navega por la biblioteca de objetos, porque Arena
tiene un gran número de ellos con los que se puede trabajar en un modelo.
Por ejemplo, el código de la figura 10-12 agrega diez variables de animación al modelo que
contiene este código VBA. La primera variable de objeto a la que se hace referencia en el código
se nombra oModel. Se declara como tipo Arena.Model, lo cual lo define como proveniente
de la biblioteca de tipos de modelos de objetos Arena y ser del tipo Model. (Se usa la letra
minúscula ‘o’, como un prefijo del nombre de la variable, como una manera de indicar que es
una variable de objeto, en oposición a un entero u otro tipo de datos.) Se fija la variable oModel
para que apunte hacia la ventana de modelo que contenga el código VBA mediante el uso de un
objeto especial proporcionado por el modelo de objetos de Arena, llamado ThisDocument
Dim oModel As Arena.Model

Dim i As Integer
Dim nX As Long
’ A
dd the status variables to this Arena model (’ Agregar las variables de estado a este
modelo de Arena)
Set oModel = ThisDocument.Model
nX = 0 ’ Start at x position 0 (’ Iniciar en la posición x = 0)
For i = 1 To 10
’ Add a status variable to the model window (’ Agregar una variable de estado a la
ventana del modelo)
oModel.StatusVariables.Create nX, 0, _
nX + 400. 150 “WIP(“& i &)”*,***,**, False (Falso)
RGB (0, 0, 255), RGB ( 0, 0, 0,)”Arial”
’ Move over 500 world units for next position (’ Moverse en 500 amplias unidades para
llegar a la posición siguiente)
nX = nX + 500
Next i
Figura 10-12. Código muestra para crear diez variables de estado
(EsteDocumento) y obteniendo la propiedad de su Model. Entonces, dentro del circuito

cerrado creado, se añade una nueva variable de animación usando el método Create de la
colección StatusVariables, a la cual se le hace seguir por varios parámetros que establecen
los identificadores de la misma, como WIP(1) hasta WIP(10) —formados por la concatena-
ción de la cadena ''WIP('' con la variable índice del circuito, i, y cerrándola con '')'' para
completar el nombre— y las posiciones, tamaños y características del texto.
La segunda área principal de contenido en la biblioteca de objetos cae en el tipo principal
de objeto, SIMAN. Este objeto, el cual está contenido en un objeto Model, proporciona acceso
a toda la información acerca de la ejecución de un modelo de simulación. Con el uso de las
propiedades del objeto SIMAN, el código VBA puede averiguar casi cualquier cosa acerca de
la simulación. Si se hace clic sobre el objeto SIMAN en el navegador, se verá que existe una lista
extensa de funciones a disposición.
En la figura 10-13 se muestra un retazo de código en el que se presenta un mensaje en el que
se pide al usuario el valor de una variable (usando la función InputBox [CuadroDeEntrada]
de Visual Basic, la cual se tiene debajo del código), asignando a continuación un valor nuevo
a la variable Mean Cycle Time (Tiempo medio del ciclo) del modelo. La respuesta
suministrada en el InputBox se almacena en una variable local de cadena, sNewValue (sVa-
lorNuevo). Entonces se fija la variable oSIMAN para que apunte al objeto SIMAN contenido
en ThisDocument.Model. (SIMAN es el motor de simulación que ejecuta los modelos de Are-
na.) Se tendrá acceso a cualquier información que se quiera obtener acerca de la ejecución de la
simulación o cambio en ella mediante el empleo de esta variable oSIMAN. Las dos líneas finales
del código asignan el valor a la variable. En primer lugar se utiliza la función SymbolNumber
(NúmeroDelSímbolo) para convertir el nombre de la variable en el índice interno usado por
el motor SIMAN. Por último, se cambia la propiedad VariableArrayValue (ValorDel
ArregloDeVariables) a cualquiera que sea la que se haya tecleado en el InputBox.
Debido a las naturalezas de estas dos categorías, es común que se empleen en secciones di-
ferentes del código. Los objetos ventana del modelo se incorporan más a menudo en el código
que se aloja fuera de Arena o en los funciones VBA de utilidad para hacer actividades como
desplegar tablas de variables (como en la figura 10-12) o construir en forma automática un mo-
delo de Arena (como en la interfaz Visio que se distribuye con Arena).
Por otra parte, el objeto SIMAN sólo se encuentra activo en el curso de la ejecución de la
simulación. Por lo general, se utiliza en los eventos integrados que se describieron en la sección
428 Capítulo 10
Dim oSIMAN As Arena.SIMAN

Dim nVarIndex As Long
Dim sNewValue As String
’ Prompt for a new value
sN
ewValue = InputBox(“Enter the new average cycle
time:”)
’ Assign their answer to the Mean Cycle Time variable
Set oSIMAN = ThisDocument.Model.SIMAN
nVarIndex = oSIMAN.SymbolNumber (“Mean Cycle Time”)
oSIMAN.VariableArrayValue(nVarIndex) = sNewValue
Figura 10-13. Código para asignar un valor nuevo a la variable,

en el curso de la ejecución
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.
10.2.4 Grabador de macros de Arena

Como se pudo ver en las secciones 10.2.1 a 10.2.3, VBA suministra un poder y una flexibili-
dad significativos, pero también puede ser un tanto difícil de aprender. Muchos productos que
soportan VBA también proporcionan una capacidad de grabado de macros para entregar un
arranque en salto. Una macro es una serie de comandos o instrucciones VBA almacenados en
un módulo de Visual Basic que se pueden ejecutar siempre que se necesiten para realizar una
tarea. El Macro Recorder (Grabador de macros) es una herramienta que facilita generar macros
para grabar los comandos asociados con tareas reales. En esta sección se examinará cómo em-
plear macros para ayudar a construir soluciones VBA.
Digamos que se quiere escribir cierto código para colocar algunos módulos. Aunque es evi-
dente que se podría examinar el modelo de objetos de Arena descrito en la sección 10.2.3, en lugar
de ello se generará algún código muestra que se pueda personalizar. Se empezará por activar el
grabador de macros al seleccionar Tools > Macro > Record Macro (Herramientas > Macro >
Grabar macro), o bien, seleccionando el botón Start/Pause/Resume (Iniciar/Pausa/Reanudar)
en la barra de herramientas Record Macro. Esto hace aparecer el cuadro de diálogo Record Ma-
cro, en donde se le da al macro un nombre significativo y una descripción. Complétese el nombre
Pantalla 10-19. Inicio para grabar una macro
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
Name (Nombre) MyCreation (MiCreación)

Entity Type (Tipo de Entidad) JustMyType (SóloMiTipo)
Value (Valor) 1.5
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
Figura 10-15. Código generado en el curso de la grabación de un macro
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
Pantalla 10-20. Ejecución de la macro PlaceCreateModule
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”.
10.3 Modelo 10-5: presentación de las opciones de llegadas al usuario

En la sección 10.1 se explotaron las características de Arena para integrar datos en un modelo.
A continuación, se volverá la atención a cómo se puede interactuar con alguien que está ejecu-
tando un modelo de Arena.
En el modelo 10-5 se montará un mecanismo para cuando el modelo se ejecute permita
elegir usar llegadas de llamadas generadas a partir de un proceso aleatorio (como en el modelo
10-1 original) o provenientes de un archivo (como en el modelo 10-2). Al principio de una eje-
Figura 10-16. UserForm de Visual Basic

432 Capítulo 10
Crear entidades usando tiempos provenientes de archivo
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
Crear entidades usando

tiempos aleatorios
llamada llamada
Crear
llamada
Figura 10-17. Lógica de la creación de llamadas para el modelo 10-5
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”!
10.3.1 Modificación de la lógica de creación

En primer lugar, se necesita montar el modelo de modo que pueda generar entidades a partir
del proceso de llegadas aleatorias del modelo 10-1 o del archivo de entrada del modelo 10-2.
Para hacerlo, se colocarán los dos juegos de lógica en el mismo modelo, conectando al módulo
Process que se localiza al principio de la lógica de las llamadas, como en la figura 10-17.
Si se está utilizando la lógica de llegadas de proceso aleatorio, entonces se fijará el campo
Max Arrivals en el módulo Create en Infinite (como fue el caso en el modelo 10-1) y el Max
Arrivals en el módulo Create de la lógica de archivo en 0, indicando que allí no deben de entrar
entidades al modelo. En el otro caso, para las llegadas desde el archivo, se fijará el Max Arrivals
del módulo Create de llegadas de proceso aleatorio en 0 y el valor en el módulo Create para la
lógica de archivo en 1. (Recuerde que su lógica sólo crea una sola entidad.) En la pantalla 10-21
se muestra el módulo Create para desactivar las entidades en el módulo Create de llegadas de
proceso aleatorio.
Para verificar que el modelo funciona con propiedad, se pueden editar los módulos Create
para fijar sus valores de Max Arrivals, después ejecutar la simulación y observar los contado-
res que siguen a los dos módulos Create. Después de agregar el código VBA al principio de la
ejecución, no será necesario preocuparse acerca de los campos Max Arrivals; VBA llenará los
valores apropiados, con base en la selección del usuario para el tipo de llegadas.
Max Arrivals (Llegadas Máximas) 0
Pantalla 10-21. Módulo Create con Max Arrivals de 0
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.
10.3.2 Diseño de la UserForm de VBA

Ahora que el modelo está diseñado para disparar cualquiera de los dos tipos de creación de las
llamadas, se redirigirá la atención hacia VBA, para dar al modelador una elección cada vez que
se inicia la ejecución de una simulación. En primer lugar, se dibujará la forma que se presenta-
rá cuando se inicie la ejecución, entonces se escribirá algún código VBA para actuar sobre la
selección hecha en la forma.
Para agregar una UserForm (la cual se mencionará como forma), ábrase el Visual Basic
Editor y selecciónese la opción del menú Insert > UserForm. Esto agrega un objeto nuevo al
proyecto y abre una ventana en la cual se puede dibujar la forma, disponer los controles (los ele-
mentos con los que un usuario puede interactuar), agregar imágenes y rótulos, etc. Pasaremos
por alto los detalles de cómo se diseñan las formas en VBA; el tema de ayuda de VBA que se
encuentran en el tema con el rubro Microsoft Forms Design Reference (Referencia de diseño de
formas de Microsoft) puede ayudar a entender los conceptos básicos, las barras de herramien-
tas y las características de las Microsoft Forms.
Para que el código VBA tenga acceso a la forma, necesita tener un nombre. Se le llama-
rá frmArrivalTypeSelection (frmSelecciónDelTipoDeLlegada), al escribir en el
campo Name del cuadro Properties, como se ve en la figura 10-19.
Para diseñar el contenido de la forma, arrástrense los controles de la Control Toolbox (Caja
de herramientas de controles) sobre la forma. Arrástrese un rótulo sobre la forma y tecléese
su campo Caption (Encabezado) (en el cuadro Properties) para que corresponda con el texto
descriptivo de la figura 10-20 (Call entities can... [Las entidades de llamadas
pueden...]). Enseguida, arrástrese un botón de opción sobre la forma, debajo del rótulo.
Cámbiese su nombre a optFromRandomProcess (frmDelProcesoAleatorio), su Cap-
tion a Random iterarrival-time process (Proceso aleatorio de tiempo en-
tre llegadas) y su valor a True (Verdadero), de modo que sea la selección predetermi-
nada. Después, agréguese otro botón de opción nombrado optFromFile (optDeArchivo),
teniendo como su encabezamiento Arrival times from a file (Tiempos de llega-
das de un archivo) y un valor predeterminado de False. El control final es el botón de
Figura 10-19. UserForm en Project de VBA

Figura 10-20. Disposición de la UserForm
comando debajo de la forma. Nómbrese como cmdOK, con un encabezamiento de OK y fíjese

su propiedad Default (Predeterminada) como True, de modo que la tecla Enter (Introducir)
actuará como si se hubiera hecho clic en el botón de comando.
Esta UserForm ahora es parte del modelo de Arena; cuando se guarde el archivo del mode-
lo, se guardará la forma con él. Sin embargo, no es de mucha ayuda hasta que VBA sabe qué
hacer con esa forma. Se realizará ese esfuerzo a continuación.
10.3.3 Visualización de la forma y establecimiento de los datos del modelo

Se requiere que el código VBA de este modelo active y desactive las llegadas de los dos módulos
Create, con base en cuál tipo de llamadas desea en realidad el usuario que se ejecuten en el curso
de la simulación. Para que estos cambios funcionen, es preciso fijar los campos Max Arrivals
en los dos módulos Create, antes de que se inicie la ejecución. Para hacerlo, se compilarán los
valores hacia el modelo, precisamente como si los módulos hubieran sido editados tecleando
valores en sus cuadros de diálogo. Si se recuerdan los pasos resumidos en la sección 10.2, el
evento RunBegin proporciona la oportunidad perfecta para hacer tales cambios. Se le llama
al iniciarse cada ejecución de simulación, antes de que se verifique el modelo, de modo que los
cambios en los datos de los módulos hechos por el código VBA se incluyan en esa ejecución.
Figura 10-21. Adición del evento ModelLogic_RunBegin al proyecto VBA

436 Capítulo 10
Option Explicit (Opción Explícita)

Private Sub ModelLogic_RunBegin ()
’ Display the UserForm to ask for the type of arrivals
frmArrivalTypeSelection.Show
Exit Sub (Salir de Sub)
End Sub
Figura 10-22. Código ModelLogic_RunBegin para desplegar la forma
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.
Private Sub cmdOK_Click()

End Sub
Figura 10-23. Evento cmdOK_Click de la UserForm

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
Dim nCreateRandomProcessIndex As Long

Dim oCreateRandomProcessModule As Arena Module
Dim nCreateFileIndex As Long
Dim oCreateFileModule As Arena Module
Dim oModel As Arena Model
’ Find the two Create modules
nCreateRandomProcessIndex= _
oModel.Modules.Find(smFindTag, _
“Create from random process”)
If nCreateRandomProcessIndex = 0 Then
MsgBox “No module with tag ‘Create from random process’”
frmArrivalTypeSelection.Hide
Exit Sub
End If
Set
oCreateRandomProcessModule = _
oModel.Modules(nCreateRandomProcessIndex)
nCre
ateFileIndex = _
oModel.Modules.Find(smFindTag, “Create from file”)
If nCreateFileIndex = 0 Then
MsgBox “No module with tag ‘Create from file’”
Exit Sub
End If
Set oCreateFileModule = oModel.Modules(nCreateFileIndex)
Figura 10-24. Localización de los módulos Create a través de etiquetas de VBA

438 Capítulo 10
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
Module: Create (Módulo Crear)

Operands Container in Dialog ‘Create’ (Operandos contenidos en el diálogo ‘Crear’)

Operand Name (Nombre del operando) Prompt (Mensaje)
Name (Nombre) Name (Nombre)
Entity Type (Tipo de entidad) Entity Type (Tipo de entidad)
Iterarrival Type (Tipo de entre llegadas) Type (Tipo)
Schedule (Programa) Schedule Name (Nombre del programa)
Value (Valor) Value (Valor)
Expression (Expresión) Expression (Expresión)
Units (Unidades) Units (Unidades)
Batch Size (Tamaño de lote) Entities per Arrival (Entidades por llegada)
Max Batches (Máx de lotes) Max Arrivals (Máx de llegadas)
First Creation (Primera creación) First Creation (Primera creación)
Figura 10-26. Lista de operandos de BasicProcess.txt
el archivo nombrado BasicProcess.txt y se encuentra el módulo Create, el cual está co-

locado de manera conveniente arriba del archivo. Si se mira hacia abajo de la lista de mensajes
de la figura 10-26, se ve que el operando cuyo mensaje es “Max Arrivals” tiene un nombre de
operando de Max Batches (no nos pregunte por qué), de modo que, para el método Data, se
introduce Max Batches como el argumento.
Como recordatorio, repasemos cómo se llegó hasta aquí. Alguien inició la ejecución de una
simulación, quizá haciendo clic en el botón Go de la barra de herramientas Run. Arena llamó el
evento ModelLogic_RunBegin de VBA, en donde el código llamó a su vez al método Show
para obtener la forma frmArrivalTypeSelection. Quienquiera que haya iniciado la eje-
cución, tuvo la oportunidad entonces de seleccionar el tipo de llegadas que se van a usar para
esta ejecución, al hacer clic en los botones de opción. (Por cierto, las formas de VBA cuidan de
sólo permitir que se seleccione un botón de opción.)
Mientras se desplegaba la forma, se suspendió la ejecución de Arena, esperando con pacien-
cia el código VBA que se haya escrito para finalizar el trabajo
Llegado el momento (es de esperar), alguien hizo clic en el comando OK de la forma, lo
cual causó que VBA llamara el evento cmdOK_Click en la ventana de código frmArrival
TypeSelection. Este código abrió el submodelo Create y el Direct Arrivals (Llegadas di-
rectas) halló los dos módulos Create e introdujo los valores apropiados en los campos Max
Arrivals. Y recuérdese que todo esto se llevó a cabo en RunBegin, el cual se llamó antes de
que se comprobara y se compilara el modelo, de modo que los cambios a los datos del módulo
se aplicaran para la ejecución. Se necesitó colocar el código allí, en lugar de en RunBegin
Simulation o RunBeginReplication, porque esos dos eventos se llaman después de que
se han compilado los módulos e inicializado la ejecución, donde se puede tener acceso a los
datos del tiempo de ejecución sólo a través de la parte SIMAN del objeto Model. (Éste podría
ser un buen momento para ir páginas atrás hasta la figura 10-10, con el fin de repasar el orden
de los eventos VBA de Arena.)
Y ahora, el momento que ha estado esperando el lector… ¡la sorpresa! Para cerrar el tra-
bajo al principio de la ejecución de la simulación, se agregará algo de drama al proyecto (o se
despertará al soñoliento modelador) tocando alguna música agitada a través de un archivo de
sonido colocado en la ventana del modelo. Para esta adición, se necesita insertar el archivo de
sonido en el modelo de Arena, darle una etiqueta única de modo que el código pueda hallarlo,
y entonces escribir el código VBA para hacer que se reproduzca el sonido.
440 Capítulo 10
Figura 10-27. Arrastrar y soltar un archivo en Arena
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
Dim nSoundFileIndex As Long

' Play the sound file
nSoundFileIndex = _
oModel.Embeddeds.Find(smFindTag, “Mission Possible”)
If nSoundFileIndex > 0 Then _
oModel.Embeddeds.Item(nSoundFileIndex).Do
Figura 10-28. Código para reproducir el archivo de sonido

restablecer la excitación al modelo, se puede cambiar sencillamente el 0 en 1 en el enunciado If,

un truco práctico para el código que no es seguro que el lector siempre quiera utilizar.
Ahora que se ha completado todo el trabajo, incluyendo la sorpresa, el último paso es cerrar
la UserForm y salir del método Click del botón OK, de modo que Arena puede empezar la
ejecución de la simulación. Estas líneas del código se encuentran abajo en la figura 10-29, en la
cual se tiene una lista del código completo para el evento cmdOK_Click.
Private Sub cmdOK_Click ()

' Set the Max Arrivals field in each of the Create modules
' based on the selection in the UserForm
Dim nCreateRandomProcessIndex As Long
Dim oCreateRandomProcessModule As Arena.Module
Dim nCreateFileIndex As Long
Dim oCreateFileModule As Arena.Module
Dim oModel As Arena.Model
Dim nSoundFileIndex As Long
' Find the two Create modules
nCreateRandomProcessIndex = _
oModel.Modules.Find(smFindTag, _
“Create from random process”)
If nCreateRandomProcessIndex = 0 Then
MsgBox “No module with tag 'Create from random process'”
Exit Sub
End If
Set oCreateRandomProcessModule = _
oModel.Modules(nCreateRandomProcessIndex)
nCreateFileIndex = _
oModel.Modules.Find(smFindTag, “Create from file”)
If nCreateFileIndex = 0 Then
MsgBox “No module with tag 'Create from file'”
Exit Sub
End If
Set oCreateFileModule = oModel.Modules(nCreateFileIndex)
' Set the Max Arrivals fields
If optFromRandomProcess.value = True Then
oCreateRandomProcessModule.Data(“Max Batches”) = “Infinite”
oCreateFileModule.Data(“Max Batches”) = “0”
Else
oCreateRandomProcessModule.Data(“Max Batches”) = “0”
oCreateFileModule.Data(“Max Batches”) = “1”
End If
' Play the sound file
nSoundFileIndex = _
oModel.Embeddeds.Find(smFindTag, “Mission Possible”)
If nSoundFileIndex > 0 Then _
oModel.Embeddeds.Item(nSoundFileIndex).Do
' Hide the UserForm to allow the run to begin
Exit Sub
End Sub
Figura 10-29. Código VBA completo del evento cmdOK_Click

442 Capítulo 10
Después de que la forma se esconde y se sale del procedimiento cmdOK_Click, el control

del código VBA regresa a la subrutina ModelLogic_RunBegin después de la llamada al
evento Show para la forma. De regreso en la figura 10-22, se vio que RunBegin sencillamente
sale de la subrutina. En este punto, Arena comprueba el modelo, inicia la ejecución de la simu-
lación y empieza la primera replicación, todo mientras el usuario se entretiene con la música
inspiradora del archivo de sonido intercalado.
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
Figura 10-30. Resultados de Microsoft Excel

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.
10.4.1 Montaje de Excel al principio de la ejecución

Para almacenar los datos de las llamadas en el transcurso de la ejecución, en principio se creará
el archivo de Excel, precisamente como si se hubiera ejecutado Excel e iniciado un nuevo archi-
vo. Al inicio de cada nuevo día (es decir, replicación), también se quiere escribir los encabezados
para las columnas de datos. Para hacer esto, se usarán dos de los eventos VBA integrados de
Arena: RunBeginSimulation y RunBeginReplication. En RunBeginSimulation
se colocará el código de arranque para ejecutar Excel y crear el nuevo libro de trabajo (es decir,
archivo). Y, como se podría esperar, en RunBeginReplication es en donde se escribirán los
encabezados, ya que se necesita un nuevo juego para cada día (replicación) de la ejecución.
En las figuras 10-31, 10-33 y 10-34 se da la lista del código VBA para el modelo 10-6. Para
ver este código en el modelo de Arena, ábrase el archivo Model 10-06.doe, el cual es el
modelo 10-2 más el código VBA descrito en esta sección. Selecciónese Tools > Macro > Show
Visual Basic Editor y hágase doble clic sobre el elemento ThisDocument, en la barra de herra-
mientas del proyecto de Visual Basic. Nótese que cuando se crean las funciones correspondien-
tes para los eventos integrados en la ventana del código, se agrega el prefijo ModelLogic_. En
las discusiones que siguen, por sencillez, se dejará a un lado el prefijo, ya que la lista de eventos
VBA de Arena lo hace.
La sección de declaraciones globales, que se muestra en la figura 10-31, que consta de las
líneas que se encuentran fuera de cualquier procedimiento (es decir, antes de la línea que define
el procedimiento ModelLogic_RunBeginSimulation), define las variables que son glo-
bales para todos los procedimientos a través de una serie de enunciados Dim (la sintaxis de la
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
Figura 10-31. Declaraciones de variables globales de VBA para el modelo 10-6

444 Capítulo 10
declaración de variables de Visual Basic, abreviatura de “dimensión”). Asimismo, se incluyó el

enunciado Option Explicit para decir a VBA que deben declararse todas las variables (es
decir, con los enunciados Dim); se recomienda usar esta opción para impedir que resulte difícil
encontrar los errores de codificación debidos a nombres mal escritos de las variables.
Se declara una variable global oSIMAN que se fijará en RunBeginSimulation para apun-
tar al objeto de datos SIMAN del modelo y que se usará en los procedimientos restantes para
obtener valores de la ejecución de la simulación. El tipo de variable Arena.SIMAN establece
que la variable oSIMAN es una variable objeto SIMAN de la biblioteca de objetos de Arena.
Las otras variables de los dos primeros enunciados Dim se usan para seguir el rastro de otros
valores que se necesitan en más de uno de los procedimientos. Se les describirá conforme se
examine el código que las usa.
Las variables globales restantes —cuyos tipos de datos empiezan con Excel.— se declaran
como variables objetos de la biblioteca de objetos de Excel. Debido a que este último es una
aplicación externa (en oposición a Arena, la cual es la aplicación que aloja el código VBA que
se está usando), se debe establecer una referencia a la biblioteca de Excel haciendo clic en la en-
trada Microsoft Excel Object Library (Biblioteca de objetos de Microsoft Excel) del cuadro de
diálogo References (Referencias) de la ventana del Visual Basic Editor, el cual se abre a través de
Tools > References como se muestra en la figura 10-32. Esta referencia permitirá que se utilicen
las llamadas ActiveX Automation para controlar Excel. Nótese que también se requiere que se
instale Excel en la computadora en la que se está ejecutando este modelo. Si el lector no cuenta
con Excel, podrá abrir y editar este modelo, pero no podrá realizar ejecuciones de simulación.
Si se examina el código RunBeginSimulation de la figura 10-33, en primer lugar se fija
la variable oSIMAN igual a alguna serie interesante de caracteres que contenga puntos. Cuando
se está leyendo el código que explota objetos, a menudo resulta de ayuda leer la parte del objeto
de derecha a izquierda, usando los puntos como separadores entre los elementos. Por ejemplo,
el enunciado Set oSIMAN = ThisDocument.Model.SIMAN se puede concebir como algo
semejante a “Fijar la variable oSIMAN para que apunte a la propiedad SIMAN del objeto Mo-
del contenido en ThisDocument”. Sin profundizar demasiado en los detalles del modelo de
objetos de Arena o de Visual Basic, sólo digamos que ThisDocument se refiere al modelo de
Arena que contiene este código RunBeginSimulation; Model es su objeto principal, que
Figura 10-32. Cuadro de diálogo Tools > References de VBA

Private Sub ModelLogic_RunBeginSimulation()

' Set the global SIMAN variable
' Set global variable to store Arrival Time attribute index

nArrivalTimeAttrIndex= oSIMAN.SymbolNumber("Call Start Time")
' Start Excel and create a new spreadsheet

Set oExcelApp = CreateObject("Excel.Application")
oExcelApp.Visible = True
oExcelApp.SheetsInNewWorkbook = 1
Set oWorkbook = oExcelApp.Workbooks.Add
Set oWorksheet = oWorkbook.ActiveSheet

With oWorksheet
.Name = "Call Data"
.Rows(1).Select
oExcelApp.Selection.Font.Bold = True
oExcelApp.Selection.Font.Color = RGB(255, 0, 0)
.Rows(2).Select
oExcelApp.Selection.Font.Bold = True
oExcelApp.Selection.Font.Color = RGB(0, 0, 255)
End With
End Sub
Figura 10-33. Código VBA de RunBeginSimulation para el modelo 10-6
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
Private Sub ModelLogic_RunBeginReplication()

Dim nReplicationNum As Long, i As Integer
' Set variables for the columns to which data is to be written
nReplicationNum = oSIMAN.RunCurrentReplication
nColumnA = (4 * (nReplicationNum - 1)) + 1
nColumnB = nColumnA + 1
nColumnC = nColumnA + 2
' Write header row for this day’s call data and
' set nNextRow to 3 to start writing data in third row
With oWorksheet
.Activate
.Cells(1, nColumnA).value = "Day " & nReplicationNum
.Cells(2, nColumnA).value = "Start Time"
.Cells(2, nColumnB).value = "End Time"
.Cells(2, nColumnC).value = "Duration"
For i = 0 To 2
.Columns(nColumnA + i).Select
oExcelApp.Selection.Columns.AutoFit
oExcelApp.Selection.NumberFormat = "0.00"
Next i
End With
nNextRow = 3
End Sub
Figura 10-34. Código VBA de RunBeginReplication
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.
10.4.2 Almacenamiento de los datos de las llamadas por separado

usando el módulo VBA
En la tarea siguiente, se requiere tanto cambiar la lógica del modelo como escribir algo de códi-
go VBA. Primero, hagamos la modificación del modelo. Precisamente antes de que finalice una
llamada (es decir, antes de salir del modelo a través del módulo Dispose), se debe de disparar el
código VBA para escribir sus estadísticas —tiempo de inicio de la llamada, tiempo de comple-
to de ésta y duración de la misma— en el renglón siguiente de la hoja de cálculo de Excel. En
Demorar hasta Separar en

Crear entidad de Leer el tiempo que se alcance entidad duplicada
control para leer de llegada Original
el tiempo de la para la llegada de
los datos siguiente llamada real la llamada
Duplicada
VBA
llamada llamada
Figura 10-35. Módulo VBA
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
Private Sub VBA_Block_1_Fire()

' Retrieve create time and current time from SIMAN object data
Dim dCreateTime As Double, dCurrentTime As Double
dCreateTime
= oSIMAN.EntityAttribute(oSIMAN.ActiveEntity, nArrivalTimeAttrIndex)
dCurrentTime = oSIMAN.RunCurrentTime
' Write the values to the spreadsheet
With oWorksheet
.Cells(nNextRow, nColumnA).value = dCreateTime
.Cells(nNextRow, nColumnB).value = dCurrentTime
.Cells(nNextRow, nColumnC).value = dCurrentTime - dCreateTime
End With
' Increment the row variable
nNextRow = nNextRow + 1
End Sub
Figura 10-37. Código VBA_Block_1_Fire
de la variable oSIMAN que se fijó en RunBeginSimulation). En primer lugar, se almacena

el valor del atributo de la entidad activa, con valor de índice nArrivalTimeAttrIndex
en una variable local dCreateTime (dCrearTiempo). La variable global nArrivalTime
AttrIndex se declaró fuera de todos los procedimientos (de modo que se dispone de ella para
todos ellos) y su valor se asignó en RunBeginSimulation para que fuera el índice del atributo
nombrado Call Start Time (usando la función SymbolNumber). A continuación, se alma-
cena el tiempo de la simulación en curso en una variable local dCurrentTime (dTiempo
Actual). Estos valores se usan para almacenar información acerca de esta entidad en la hoja
de cálculo, utilizando la variable nNextRow para determinar el renglón, el cual entonces se in-
crementa. Después de que se ejecuta este código para una entidad particular, la entidad regresa
al modelo y entra al módulo Dispose (Disponer), en donde se destruye.
10.4.3 Construcción del gráfico de los resultados y limpieza al final de la ejecución

La última tarea es crear gráficos de las duraciones de las llamadas para cada replicación y
guardar el archivo de la hoja de cálculo al final de la ejecución de la simulación. Aun cuando se
podría hacer toda la construcción de gráficos al término de la ejecución, ya que los datos exis-
tirán en su hoja de cálculo, en lugar de ello, se colocará el código en RunEndReplication
para construir los gráficos conforme se desarrolla la ejecución.
Después de que se ha procesado la entidad final, al finalizar cada replicación, Arena llama
el procedimiento RunEndReplication de VBA. En el modelo que se está trabajando, se
trazará el gráfico de los datos contenidos en la columna Duration de la hoja de cálculo para
la replicación (día) que se acaba de completar, mostrando una gráfica lineal de las duraciones
de las llamadas en el curso de esa replicación. Se pasará por alto la discusión del código para
construir el gráfico. Si el lector tiene interés en examinar las características de construcción de
gráficos de Excel, se le recomienda navegar en la ayuda en línea y usar el grabador de macros
para probar diferentes opciones para construir gráficos.
Por último, al final de la ejecución de la simulación, se llama al procedimiento RunEndSi-
mulation; sencillamente se guardará el libro de trabajo de Excel para el archivo Model 10-
06.xls en la misma carpeta del modelo (usando ThisDocument.Model.Path (….Ruta),
saliendo de la ejecución de Excel. En la figura 10-38 se muestra el código para estas dos rutinas.
Cuando se ejecute este modelo, se verá aparecer una copia de Excel en el escritorio, al princi-
pio de la ejecución, seguida por una serie de números que se van agregando a la hoja de cálculo
Private Sub ModelLogic_RunEndReplication()

' Chart today’s sales call data on a separate chart sheet
oWorkbook.Sheets("Call Data").Select
oWorksheet.Range(oWorksheet.Cells(3, nColumnC), _
oWorksheet.Cells(nNextRow, nColumnC)).Select
oExcelApp.Charts.Add
' Format the chart
With oExcelApp.ActiveChart
.ChartType = xlLineMarkers
.SetSourceData Source:=oWorksheet.Range(oWorksheet.Cells(3, _
nColumnC),
oWorksheet.Cells(nNextRow,
nColumnC)),
PlotBy:=xlColumns
.SeriesCollection(1).XValues = ""
.Location Where:=xlLocationAsNewSheet, _
Name:="Day " & oSIMAN.RunCurrentReplication & "Calls"
.HasTitle = True ' Title and Y axis
.HasAxis(xlValue) = True
.HasAxis(xlCategory) = False ' No X axis or Legend
.HasLegend = False
.ChartTitle.Characters.Text = "Call Times"
.Axes(xlValue).MaximumScale = 60
.Axes(xlValue).HasTitle = True
.Axes(xlValue).AxisTitle.Characters.Text = "minutes"
End With
End Sub
Private Sub ModelLogic_RunEndSimulation ()
' Save the spreadsheet
oExcelApp.DisplayAlerts = False ' Don’t prompt to overwrite
oWorkbook.SaveAs ThisDocument.Model.Path & "Model 10-06.xls"
End Sub
Figura 10-38. Código VBA para el final de la replicación y el final de la ejecución
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.
10.5 Creación de módulos usando la edición profesional de Arena: plantilla 10-1

Ahora se lanzará una breve mirada a cómo se puede personalizar Arena mediante la cons-
trucción de nuevos módulos aplicando las capacidades de construcción de la plantilla de este
programa. Si el lector está usando la versión estudiantil de Arena (la cual es la que se encuentra
en el CD que acompaña este libro), no podrá intentar esto por sí mismo, ya que no se incluyen
las características de construcción con plantilla. Sin embargo, la construcción con plantilla es
parte de los paquetes Research o Educational Lab, cualquiera de los cuales se pueden obtener
a través de la institución académica del lector. Aunque, de cualquier manera, podrá ver en un
modelo de Arena el uso del módulo que se describe en esta sección.
Para presentar este rápido viaje por la creación de plantillas, se recorrerán los pasos para
construir un módulo muy sencillo, en el que se muestran algunas de las ventanas y los cuadros de
diálogo a lo largo del camino. Aun cuando se finalizará con un módulo utilizable (y potencialmen-
te útil), sólo se tocará una pequeña parte de las características de construcción con plantilla de
450 Capítulo 10
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).
10.5.1 Crear a partir del módulo File

En relación con la plantilla, se volverá a visitar la modificación al modelo del centro de atención
telefónica, Model 10-02, en el cual se desarrolló la lógica para leer tiempos de llegada desde
un archivo, para los tiempos de creación de las llamadas. En la realización de esta tarea, se
usaron cuatro módulos —Create, ReadWrite, Delay y Separate— más el módulo de datos File,
el cual funcionó de manera conjunta para generar entidades que se llevarán al modelo en los
tiempos apropiados. Si se estuviera haciendo una cantidad importante de modelado en el que
se podría utilizar este procedimiento impulsado por el análisis, para la creación de entidades,
podría resultar práctico “empaquetar” estos módulos (y los datos apropiados para hacer que
las cosas funcionen en forma correcta) en un solo módulo. Así, se tendría que recordar el truco
de cómo se llevaron las entidades al modelo en el momento correcto, y los propios modelos
serían un poco menos complicados de visualizar.
Para construir este módulo, al que se le dará el nombre de Create from File (Crear
desde archivo), se copiará la lógica del modelo, que ya se construyó en el modelo 10-2, en
lo que se llama archivo plantilla. A continuación, se definirá un operando —un campo que se
muestra en el cuadro de diálogo cuando se hace doble clic en el módulo— que permita cambiar
el archivo nombrado siempre que se use un caso del módulo Create from File. (A los
autores no les gustaría ser tan presuntuosos como para pensar que todos los módulos que den
se leerán desde un archivo nombrado Model 10-02, como el original que se hizo.) También
se dibujará una imagen para que se visualice en la barra de herramientas de la plantilla y se
dispondrán los objetos que se deben mostrar cuando el módulo se coloque en la ventana de
un modelo. Estos cuatro sencillos pasos —definición de la lógica, operandos, ícono del panel y
vista del usuario— son los básicos para la construcción de plantillas en Arena.
Antes de dar una mirada más cuidadosa a cada uno de estos pasos, veamos el resultado final
—uno de estos módulos Create from File colocado en la ventana de un modelo— como se
Figura 10-39. Crear a partir del módulo File usado en un modelo

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.
10.5.2 El archivo fuente de plantilla: Template 10-01.tpl

Para examinar la definición del módulo Create from File, se mirará el archivo Template
10-01.tpl que contiene su lógica, operandos, etc. Si el lector está ejecutando la versión Resear-
ch o Educational Lab de Arena, puede abrir este archivo a partir de la opción estándar de menú
File > Open; sólo cambie la entrada en los Files del campo tipo a Template Files (*.tpl)
y seleccione Template 10-01.tpl. Con esto se abre una ventana de plantilla, en la que se
tiene una lista de todos los módulos contenidos en ella. (Para el ejemplo que se está trabajando,
únicamente se tiene el solitario módulo Create from File.) Desde esta ventana, los botones
en la barra de herramientas Template Development (Desarrollo de plantillas) (de la figura 10-40)
abren las otras diversas ventanas que definen los módulos, presentan una vista previa del cuadro
de diálogo del módulo y generan el archivo del objeto panel de plantilla (.tpo) para que se use en
el modelo.
10.5.3 Ícono del panel y vista del usuario

Antes de hundirse en las entrañas del módulo Create from File, se discutirán con brevedad
las dos primeras cosas que ve alguien que use el módulo. Para utilizar el módulo en un modelo
de Arena, se necesita adjuntar, a la barra de herramientas Template, el panel de la plantilla que
lo contiene, como se mostró en la figura 10-39. En esta barra, Arena presenta una imagen dibu-
jada por el creador de la plantilla para cada módulo, conocida como ícono del panel del módulo.
En el caso del módulo Create from File, la imagen ilustra una página con una de sus
puntas doblada y una flecha (representando de la mejor manera, según las limitadas habilidades
artísticas del diseñador de este módulo, el concepto de crear entidades a partir de un archivo).
Cuando un modelador coloca un caso del módulo en la ventana de un modelo, los objetos
gráficos que se encuentran agregados a la ventana se mencionan de manera colectiva como la
vista del usuario del módulo. Cada módulo tiene por lo menos un asa, la cual por lo común es
el nombre del módulo rodeado por un cuadro. La mayor parte de los módulos tienen también
Figura 10-40. Ventana y barra de herramientas de la plantilla

452 Capítulo 10
Figura 10-41. Ventana lógica en la definición del módulo
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).
10.5.4 La lógica del módulo y los operandos

El corazón de lo que un módulo proporciona cuando se coloca en la ventana de un modelo es
la lógica real que se va a desplegar en el transcurso de la ejecución de la simulación. Cuando
el usuario, en la plantilla que le pertenece, está construyendo un módulo, define esta lógica
precisamente como construye un modelo, colocando y conectando módulos provenientes de
otras plantillas. La lógica subyacente en el módulo Create from File contiene los módulos
que se usaron en el modelo 10-2 más un módulo Assign para contar el número de entidades
que salen del módulo. En la figura 10-41 se muestra esta lógica, la cual se coloca en la ventana
lógica de la definición del módulo. Se copiaron los cuatro módulos y sus conexiones del modelo
10-2 y se pegaron en la ventana lógica. Después se agregó el módulo Assign del panel Blocks,
conectándolo al punto de salida rotulado Duplicate del módulo Separate.
Cada vez que se coloca este módulo Create from File en un modelo, se incluirá dicha
lógica subyacente de modo que se generen las entidades y se envíen al modelo, basadas en los
datos del archivo de texto. Un lector astuto podría preguntarse: “¿Cuál archivo? ¿A qué parte
del modelo?” Aquí es en donde los operandos del módulo entran en juego. Si únicamente se
utilizó la lógica original del modelo 10-2, entonces sólo se podría usar el Create from File
para generar entidades desde un archivo llamado Model 10-02.txt. En lugar de ello, se
Figura 10-42. Cuadro de diálogo del módulo

cuando está colocado en el modelo
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.
Figura 10-43. Ventana de operando en la definición del módulo

454 Capítulo 10
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
Figura 10-44. Properties Design para el operando File Name
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
Figura 10-45. Establecimiento de referencias para los operandos

mediante el módulo de la ventana lógica
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.
10.5.5 Usos de las plantillas

Se pueden desarrollar plantillas para que se encarguen de una amplia gama de necesidades.
Algunas se podrían concebir para que sean usadas por un mercado objetivo grande, como la
Arena Contact Center Template (Plantilla para centro de contacto de Arena) o la Arena Pack-
aging Template (Plantilla para empaquetamiento de Arena). Otras podrían resultar más como
una utilidad, como el ejemplo sencillo que se presentó en este capítulo.
Las plantillas más ambiciosas de Arena son aquellas que se desarrollan para un mercado
comercial, normalmente centrado en una industria particular, como la producción de alta ve-
locidad o los centros de contacto de relaciones con los clientes. Existen dos ventajas principales
de las plantillas enfocadas a la industria. En primer lugar, en la plantilla se puede utilizar termi-
nología que sea apropiada para la industria, minimizando la abstracción necesaria para que un
modelador traslade un sistema al software. Lo que es más importante, a través de la jerarquía

de Arena, se puede construir una plantilla que se personalice por completo para representar
con exactitud los elementos de los sistemas de la industria. El diseñador de la plantilla tiene las
capacidades a mano para imitar con exactitud el comportamiento del equipo, las personas, las
piezas, los componentes, etc., proporcionando cualquier espectro de opciones que sea apropiado
para las variaciones de estos elementos del sistema. Además, a través de la tecnología ActiveX
Automation soportada por Arena, se pueden crear asistentes de descarga e instalación y otras
utilidades que trabajen en cooperación con una plantilla en particular para generar gráficas e
informes especializados, cargar datos en forma directa desde bases de datos externas, etcétera.
Muchas de las plantillas que se desarrollan usando Arena ayudan a los modeladores en la
representación de un sistema, instalación o proceso particulares. Aun cuando pueden no ser del
“grado comercial”, estas plantillas tienen muchas de las mismas metas que las de aquellas para
la industria y proporcionan varios de los mismos beneficios. Aunque, en este caso, el foco podría
ser más angosto que el de una plantilla comercial. Por ejemplo, se podría construir una plantilla
para emplearse en el análisis de esquemas para cargar camiones o para representar reglas de envío
de las llamadas entrantes hacia los técnicos. Estas plantillas enfocadas a la aplicación benefician,
desde la estructura jerárquica de Arena, de las mismas maneras que aquellas enfocadas a la in-
dustria: se puede personalizar la interfaz presentada a un modelador para que sea muy familiar
(tanto en términos de la animación gráfica como de la terminología presentada al usuario), y se
pueden representar con exactitud los elementos del entorno de la aplicación objetivo. En algunos
casos, un modelador podría construir estas plantillas sólo para su propio uso individual, si existe
la posibilidad de que se modele el mismo tipo de problema repetidas veces. En otros casos, se po-
drían crear plantillas para ocuparse entre modeladores de un grupo común, así como se pueden
compartir plantillas de aplicaciones entre grupos diferentes de modelado en toda una empresa.
Para un modelador por sí solo, las plantillas de Arena proporcionan la oportunidad de volver
a usar técnicas de modelado que se aprendieron en el proceso de construcción de modelos. En la
evolución de herramientas de programación se capturó código reutilizable en procedimientos/su-
brutinas/funciones; más adelante, las herramientas orientadas a los objetos permitieron que se
definieran las características completas de los “objetos” representados en el software para reuti-
lizarse. Se puede pensar en un módulo como análogo a un objeto (en el software orientado a los
objetos): el módulo permite capturar las características completas de un proceso que se quiere
modelar, en un paquete autocontenido que se puede reutilizar y personalizar en cada uso. El mó-
dulo Create from File, cuyo esquema se desarrolló en esta sección, es un ejemplo de este
tipo de plantilla, en donde una vez que se estableció y probó una técnica de modelado, se “escon-
dieron” los detalles de su implementación dentro de la definición del módulo. Los usos posteriores
de la misma técnica requieren poco conocimiento de los detalles de su enfoque o implementación
y tienen menos riesgo de error, puesto que ya se ha probado la lógica incrustada.
10.6 Integración en tiempo real

Hasta ahora, la discusión acerca de la integración se ha referido principalmente a la obtención
de información de un archivo (o a ponerla en un archivo) al principio (o al final) de una ejecu-
ción o, quizá, por incrementos mientras se está ejecutando una simulación. Pero existen muchos
usos interesantes de la simulación que pueden ser el resultado de compartir datos de aquélla
con otro software en el curso de una ejecución. En particular, existen muchos usos potenciales
en el mundo del control de procesos: el mundo de las computadoras de bajo nivel (véase la figu-
458 Capítulo 10
Figura 10-46. Controlador de procesos
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
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
Figura 10-47. Ejemplo de una consola de prueba física

460 Capítulo 10
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.
Puesta en servicio sin simulación
Generación del código de control
Adquisición del hardware
Instalación en el sitio La instalación

se vuelve
operativa
Capacitación de los operarios
Prueba de la lógica de control y eliminación de errores
Puesta en servicio con simulación
Generación del código de control Tiempo y gastos

ahorrados
debido a la prueba
Adquisición del hardware y capacitación
tempranas
Instalación en el sitio
Capacitación de los operarios
Prueba de la lógica de control y eliminación de errores
La instalación
se vuelve
operativa
Tiempo
Figura 10-48. Impacto de la simulación sobre el tiempo de puesta en servicio
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
High-Level Architecture (HLA, Arquitectura de alto nivel) y aplicaciones semejantes, en donde

se están sincronizando múltiples modelos de simulación.
Arena RT también incluye construcciones para integrar comportamiento externo en la ló-
gica de la simulación (búsquese “TASKKID” en la Ayuda de Arena). Esta característica se
encuentra integrada en un esquema para comunicación entre procesos basado en enviar y re-
cibir mensajes para comunicar peticiones de acción y cambios de estado. La comunicación
se implementa en un código que puede personalizar el usuario con un ejemplo de Windows
Sockets. Existe un modo de evaluación para todas las características antes mencionadas de
Arena. Consúltese la carpeta Examples (dentro de la carpeta Arena 10.0) y búsquese el modelo
RT Real Time Clock (Reloj registrador RT) para observar un ejemplo sencillo de
la ejecución en tiempo real y véase el RT Execution Mode (Modo RT de ejecución) del
modelo para conocer un ejemplo de la emisión y recepción de mensajes.
Se espera que en la próxima edición de Arena se tengan varias mejoras importantes. OPC,3
mencionado con anterioridad, es un estándar popular para las comunicaciones en el mundo
del control. Trabaja mediante la definición de OPC Servers que manejan los datos y de OPC
Clients que alimentan datos a esos servidores y los consumen de ellos mismos. La versión 11.5
de Arena tendrá capacidad innata para ser OPC Client, OPC Server o las dos cosas (en caso
de que el usuario deseara que Arena hable consigo mismo). Esto proporciona un mecanismo
fácil para compartir datos. Con unos cuantos clics, se pueden repartir todas las variables de un
modelo de Arena con otras aplicaciones OPC, sin cambios de código. Y si se elige definir Tags
(Etiquetas) en forma manual (compartiéndose los elementos de datos), también se puede hacer
con el Rockwell Tag Browser, el cual se utiliza ampliamente a través de todos los productos
Rockwell y permite que una etiqueta se defina una vez, haciéndose referencia a ella con facili-
dad en otras aplicaciones.

En este capítulo, se han examinado varios temas que son parte de uno que se refiere a aspectos
diferentes de la personalización del modelado de Arena y de la integración de éste con otras
aplicaciones. Se realizó un recorrido arremolinado con VBA, se vio cómo pueden trabajar jun-
tos Arena y Microsoft Office y se estructuró en forma personal una construcción de modelado,
según las necesidades propias, con las herramientas para desarrollar plantillas. Se finalizó con
una mirada a algunas aplicaciones en tiempo real y sus beneficios. El material de este capítulo
representa la “punta del témpano”, con el intento de hacerle cosquillas a la imaginación del
lector acerca de lo que es posible, así como para armarlo con conocimientos fundamentales
suficientes de las características para salir y explorar por sí mismo.
Si elige continuar, encontrará que en el capítulo 11 se aborda el tema del modelado de proce-
sos de cambio continuo, como el flujo de líquidos y de materiales a granel. Después se volverá la
atención hacia algunos tópicos importantes que sustentan y soportan los buenos estudios sobre
simulación de los capítulos 12 y 13.
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.
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
Modelos continuos y discretos/

continuos combinados
Hasta el momento, si el lector cayó o no en la cuenta, todo nuestro modelado se ha centrado en

sistemas discretos; es decir, procesos en los que los cambios para el estado del sistema ocurren
en puntos aislados en el tiempo llamados eventos. En Arena, estos tiempos de evento se mane-
jan mediante el calendario de eventos, con entidades que se mueven por el proceso diagramado
para definir cuándo ocurrirán los cambios en el estado del sistema y cuáles deben tener lugar
(por ejemplo, se libera un recurso). En el capítulo 2 la simulación manual explicó todas estas
transiciones, definiendo todos los eventos que podrían cambiar el sistema y sus tiempos de
ocurrencia exactos. Estos modelos de evento discreto pueden captar muchos tipos de sistemas,
desde procesos de servicio (como el centro de reparación de automóviles del capítulo 5) hasta
sistemas de manufactura (como el sistema de manufactura pequeño del capítulo 7).
Sin embargo, en otros casos, el estado del sistema podría cambiar de forma continua con
el tiempo. Considere una cervecería, donde varios ingredientes (lúpulos, cebada, agua) se mez-
clan, calientan, almacenan y transfieren en tuberías entre depósitos. En este sistema, el proceso
de vaciar un recipiente se relaciona con el flujo de un producto. Para modelar el volumen de
cerveza en el tanque, se desearía poder representar su tasa de cambio con el tiempo y permitir
que esta tasa produzca un flujo continuo de cerveza clara en el receptáculo objetivo (de prefe-
rencia uno que esté destinado para su siguiente reunión social). El nivel del recipiente en algún
tiempo futuro se puede calcular aplicando la tasa de cambio al nivel de inicio; aritmética simple
es todo lo que se necesita, suponiendo que no ocurre ningún evento intermedio, como corte de
luz, falla técnica o gran degustación de un grupo de visitantes. El lector podría desear captar
tales eventos discretos que interactúan con este proceso continuo, como cerrar una válvula para
interrumpir el proceso de vaciado y fijar en cero la tasa de cambio del nivel del tanque.
En procesos más complejos podría haber tasas de cambio que dependen de otros procesos
continuos, en cuyo caso el valor de nivel futuro no se puede calcular de manera tan simple. En
tales situaciones, se emplean algoritmos de integración para determinar los niveles con base en
la relación entre los procesos continuos. La temperatura del agua en un acuario es un ejemplo
de dicho tipo de sistema. Ésta cambia continuamente con el tiempo, dependiendo de factores
como el calor de la luz del sol, la variación de temperatura del espacio en el que se muestra y el
ciclo de encendido y apagado del calentador. Estos elementos, el calor del sol, la temperatura
ambiente y el calor generado por el calentador, cambian también en forma continua. Para
captar tales procesos con exactitud en un modelo de simulación, se emplean métodos especiali-
zados de modelado continuo que permiten que estas relaciones sean definidas como ecuaciones
matemáticas que son incorporadas en el algoritmo de integración.
En el presente capítulo, se prestará atención a los procesos en los que el estado del siste-
ma puede cambiar continuamente con el tiempo. En la sección 11.1 se analizará la naturaleza
de los procesos continuos y se introducirá la terminología de Arena y constructos para modelar
los aspectos continuos de estos sistemas a través de un modelo simple. Se abrirá entonces paso
hacia la interfaz entre los procesos continuos y la lógica de modelo discreto en la sección 11.2
466 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.
11.1 Modelado de sistemas simples discretos y continuos

Cuando se modela un proceso de cambio continuo, los dos elementos primarios de interés
son el valor que está cambiando y su tasa de cambio con el tiempo. Arena provee dos tipos de
variables llamadas niveles y tasas para representar tales valores. Para cada par (un nivel y una
tasa), Arena aplica la tasa de cambio definida para aproximar un cambio continuo en el valor
del nivel. La porción de evento discreto del modelo (es decir, los módulos que el lector está
acostumbrado a emplear para modelar un proceso) puede asignar también valores nuevos a
niveles y tasas.
En esta sección, se introduce un ejemplo pequeño, modelo 11-1, que ilustra cómo funcionan
las características del modelado continuo y discreto y continuo combinado.
11.1.1 Modelo 11-1: un sistema continuo simple

Veamos un proceso continuo muy simple donde algún producto acuoso, un líquido limpiador
para alfombras, se vacía en un tanque a una tasa fija de 10 unidades de volumen por minuto.
Construiremos en nuestro modelo un solo nivel (llamado volumen del tanque [Tank Volume])
y su tasa correspondiente (designada como tasa de entrada del tanque [Tank Input Rate],
que tiene un valor inicial de 10), y se añadirá una gráfica1 de animación del valor del volumen
del tanque (Tank Volume), figura 11-1. Se necesita también un módulo continuo, que establece
algunos de los ajustes requeridos para modelos continuos.
Niveles Tasas Continuo
Volumen del Tasa de entrada

tanque del tanque
Volumen del tanque
Figura 11-1. Modelo continuo simple
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)
Pantalla 11-1. Módulo Niveles que define el 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.
Continuo
Minimum Step Size (Tamaño de paso mínimo) 1.0

Maximum Step Size (Tamaño de paso máximo) 1.0
Method (Método) Euler
Cross Severity (Severidad de cruce) Warning (Advertencia)
Pantalla 11-3. Modelo continuo para el modelo 11-1
11.1.2 Modelo 11-2: interconexión de la lógica continua y discreta

En este modelo del líquido limpiador para alfombras, ¿qué pasaría si se deseara que la canti-
dad de líquido en el tanque llegara a un límite y se vaciara después a una tasa constante (por
ejemplo, representar a grandes rasgos la vida de nuevos dueños de perritos)? Aquí, se necesita
interconectar la lógica de proceso, discreto, con el modelo continuo.
Se empleará un método muy simplista para ilustrar esta idea. Se mantendrá el valor inicial
de la Tasa de entrada del tanque (Tank Input Rate) en 10, de modo que el volumen cambie
a una tasa de 10 unidades de volumen por minuto. Se añadirá lógica de modelo para crear una
entidad al comienzo de la ejecución, retrasar 10 minutos para permitir que el volumen llegue a
100 y fijar después la Tasa de entrada del tanque (Tank Input Rate) en −10. Esto
cambiará el cálculo de Volumen del tanque (Tank Volume) para disminuir a una tasa de
10 unidades de volumen por minuto, vaciando el tanque. Después de hacer la asignación, nues-
tra entidad se retrasa de nuevo 10 minutos para permitir que se vacíe el tanque, luego asigna la
Tasa de entrada del tanque (Tank Input Rate) de nuevo a +10 para empezar el
proceso de rellenado. (Esta versión del modelo es Model 11-02a.doe.)
En la figura 11-2 se muestra la lógica y una gráfica del Volumen del tanque (Tank Vo-
lume).2 Esto funciona bien, siempre que sea posible calcular los tiempos de retraso requeridos
hasta que el tanque estuviera lleno o vacío; es decir, no hay ningún otro evento que afecte el
volumen en el tanque (el nivel) o la tasa de llenado o vaciado.
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
Volumen Tasa de entrada

del tanque del tanque
Retardar 10 Asignar Retardar 10

minutos para Asignar la
Crear una entidad minutos para la tasa a
vaciar tasa a 10
llenar menos 10
Volumen del tanque
Figura 11-2. Lazo de control para vaciar y volver a llenar el tanque
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
Vigilar el nivel del tanque sobre 100 en dirección positiva
Asignar la Disponer la entidad

Detectar tasa a menos de detección de
10 tanque lleno
Volumen del tanque
Vigilar el nivel del tanque abajo de 0 en dirección negativa
Disponer la entidad
Asignar la
Detectar de detección de
tasa a 10
tanque vacío
Volumen del tanque
Volumen del Tasa de entrada del

tanque tanque
Figura 11-3. Lógica de llenado y vaciado por medio de módulos Detect (Detectar)
Detectar
Crossing Variable (Variable de cruce) Tank Volume (Volumen de tanque)

Crossing Direction (Dirección de cruce) Positive (Positiva)
Threshold Value (Valor límite) 100
Crossing Tolerance (Tolerancia de cruce) 0.0
Pantalla 11-4. Módulo Detect (Detectar) que vigila el tanque lleno
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
Name (Nombre) Assign Rate to Minus 10 (Asignar la tasa a

menos 10)
Other (Otra) Tank Input Rate (Tasa de entrada del tanque)
New Value (Nuevo valor) −10
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.
Valor
Nuevo valor = 100.6
Límite = 100 Tolerancia = 0.1
Último valor = 99.7
Tamaño de
paso = 0.01
Tiempo
3.31 3.32
Figura 11-4. Relación entre tolerancia de cruce y actualizaciones de tiempo
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.
11.2 Operación de carga de carbón

En esta sección, se construirá un modelo un poco más grande (y quizá más interesante) de un
sistema combinado discreto y continuo; una operación de carga de carbón a lo largo de la rivera
de un río que se mueve lentamente.
474 Capítulo 11
Muelles
RÍO LENTO
Almace-
namiento
principal
de carbón
Rampas de carbón
Remolcador
y barcazas
Figura 11-5. Instalación de carga de carbón

En esta instalación, el carbón se carga de un patio de almacenaje principal por rampas hacia las
barcazas en los cuatro muelles de la instalación. La tasa a la cual se puede descargar el carbón
del área de almacenaje está fijada en 2 400 toneladas por hora, pero se puede dividir en cuatro
rampas paralelas para llenar las barcazas en los muelles, como se ilustra en la figura 11-5.
Cuando llega un remolcador a la instalación de carga, espera hasta que está disponible
uno de los cuatro muelles. Entonces, un equipo amarra el remolcador y sus barcazas al muelle
y se prepara para la carga, lo cual toma TRIA(2, 5, 10) minutos. La cantidad total de carbón
requerida para llenar las barcazas varía con base en el número de barcazas y sus tamaños. (El
remolcador y sus barcazas serán tratados como una sola unidad en este modelo.) La tabla 11-1
enlista las distribuciones de requisitos de tonelaje para tránsito en este sitio.
Después que termina la operación de llenado, el equipo del muelle desata el remolcador y
sus barcazas, y el remolcador se aleja dejando libre el muelle. Este proceso toma TRIA(3, 4.5,
7.5) minutos, dependiendo de cuánto platiquen los equipos del remolcador y el muelle. La ins-
talación de carga opera 24 horas al día, pero la llegada de los remolcadores varía en la jornada
como se ilustra en la tabla 11-2. Para los propósitos de este análisis, se supondrá que el equipo
del muelle tiene el personal suficiente para manejar la demanda.
Al evaluar esta operación, nos interesan los remolcadores que no pueden empezar a car-
gar de inmediato. Siempre que todos los muelles de la instalación se encuentren ocupados, los
remolcadores y sus barcazas estarán esperado río arriba. Nos gustaría saber algo acerca del
número de remolcadores en espera de un muelle, así como cuánto tiempo lleva procesar los
remolcadores en la instalación.
11.2.2 Método de modelado

Si recuerda la explicación anterior de conceptos de simulación (sección 2.3.7), se dijo que los
eventos ocurren en un instante de tiempo simulado y causan cambios en el estado del sistema
Tabla 11-1. Distribución de las capacidades de las barcazas
Capacidad (toneladas) Porcentaje

300 12
400 3
450 13
500 7
550 8
600 12
650 24
700 3
800 11
1 000 7
Tabla 11-2. Llegadas de remolcadores
Periodo Número promedio de remolcadores que

llegan por hora
12:00 a.m.-2:00 a.m. 0.50
2:00 a.m.-6:00 a.m. 1.00
6:00 a.m.-8:00 a.m. 2.00
8:00 a.m.-12:00 p.m. 3.50
12:00 p.m.-1:00 p.m. 1.75
1:00 p.m.-3:00 p.m. 2.75
3:00 p.m.-4:00 p.m. 4.00
4:00 p.m.-6:00 p.m. 5.00
6:00 p.m.-8:00 p.m. 4.50
8:00 p.m.-9:00 p.m. 2.50
9:00 p.m.-10:00 p.m. 1.00
10:00 p.m.-12:00 a.m. 0.50
(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
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.
11.2.3 Modelo 11-3: carga de carbón con el método continuo

De la clasificación de las actividades del sistema como discretas o continuas en la sección 11.2.2,
se concluyó que la única porción que se modelará como un proceso continuo es la carga real
de carbón en las barcazas desde el área de almacenaje. Cualquier otra actividad en el modelo
se representará como procesos discretos, algunos de los cuales interferirán con la porción con-
tinua del sistema.
Se definirán primero los niveles y tasas de cambio continuo para el sistema en los módulos
Levels y Rates (Niveles y Tasas). Debido a que se tienen cuatro procesos similares —las opera-
ciones de llenado en cada uno de los cuatro muelles— en este sistema, se usarán arreglos para
los niveles y las tasas, así que nuestro modelo puede indexar en el arreglo con base en el número
de muelle asignado a un remolcador para su operación de llenado. La pantalla 11-6 muestra las
entradas para el módulo Levels (Niveles), donde se añade un solo nivel llamado Barge Level
(Nivel de barcaza). Se definen cuatro variables de nivel, numeradas del 1 al 4, estableciendo un
Número de inicio de 1 y un Índice de arreglo 1-D de 4. Se llamarán Barge Level (1) [Nivel
de barcaza (1)] a Barge Level (4) [Nivel de barcaza (4)]. Durante la ejecución de la
simulación, éstos serán tratados de manera independiente; se usa un arreglo simplemente por la
conveniencia de indexar cuando se hacen asignaciones en la lógica de modelo.
El módulo Rates (Tasas) contiene entradas similares, como se ilustra en la pantalla 11-7.
Éstas se numerarán también como tasas 1 a 4 para hacer corresponder las variables Barge
Level (Nivel de barcaza) y se hará referencia en el modelo como Barge Rate (1) [Tasa
de barcaza (1)] a Barge Rate (4) [Tasa de barcaza (4)].
Se añadirá también un módulo Continuous para establecer los ajustes de los cálculos conti-
nuos de la ejecución, como se muestra en la pantalla 11-8. Puesto que aún se está usando el mé-
Number (Número) 1
Name (Nombre) Barge Level (Nivel de barcaza)
1-D Array Index (Índice de arreglo 1-D) 4
Pantalla 11-6. Módulo Levels que define cuatro niveles de barcaza

478 Capítulo 11
Number (Número) 1
Name (Nombre) Barge Rate (Tasa de barcaza)
Pantalla 11-7. Módulo Rates que define cuatro tasas de barcaza
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
Minimum Step Size (Tamaño de paso mínimo)

Maximum Step Size (Tamaño de paso máximo)
Pantalla 11-8. Módulo Continuous
Crear la Cambiar la tasa Disponer la entidad

Tomar el muelle Comenzar el
barcaza que de llenado a la de llegada de la
y preparar para llenado de la
llega llegada de la barcaza
el llenado barcaza
barcaza
Figura 11-6. Lógica de llegada de barcazas

Name (Nombre) Create Arriving Barge (Crear barcaza que llega)

Entity Type (Tipo de entidad) Empty Barge (Barcaza vacía)
Time Between Arrivals (Tiempo entre llegadas)
Type (Tipo) ) Schedule (Programa)
Schedule Name (Nombre de Barge Traffic Schedule (Programa de tránsito de
programa) barcazas)
Pantalla 11-9. Módulo Create para arribar a muelles vacíos
Name (Nombre) Seize Dock and Prepare for Filling (Tomar el

muelle y preparar para llenado)
Action (Acción) Seize Delay (Tomar Demorar)
Type (Tipo) Set (Conjunto)
Set Name (Establecer nombre) Docks (Muelles)
Save Attribute (Guardar atributo) Dock Number (Número de muelle)
Delay Type (Tipo de retraso) Triangular (Triangular)
Minimum (Mínimo) 2
Value (Most Likely)[Valor (más probable)] 5
Pantalla 11-10. Módulo Process para entrar a un muelle
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
Name (Nombre) Begin Filling Barge (Comenzar a llenar la

barcaza)
Variable Name (Nombre de la variable) Filling Docks (Muelles de llenado)
New Value (Valor nuevo) Filling Docks + 1 (Muelles de llenado + 1)
Other (Otro) (Barge Rate (Dock Number)[Número de muelle
(Tasa de barcaza)]
400/Filling Docks (2
400/Muelles de llenado)
Other (Otra) (Begining Fill Time (Dock Number) [Tiempo de
llenado inicial (Número de muelle)]
New Value (Nuevo valor) TNOW
Other (Otro) Barge Capacity (Dock Number) [Capacidad de la
barcaza (Número de muelle)]
New Value (Nuevo valor) SC (0.12, 300, 0.12, 400, 0.28, 450, 0.35,
DI
500, 0.43, 550, 0.55, 600, 0.79, 650, 0.82,
700, 0.93, 800, 1.00, 1 000)
Pantalla 11-11. Módulo Assign para comenzar el llenado de la barcaza
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.
Name (Nombre) Change Filling Rate on Barge arrival (Cambiar la

tasa de llenado a la llegada de la barcaza)
Other (Otro) Barge Rate (1) [Tasa de barcaza (1)]
New Value (Nuevo valor) (Barge Rate (2) > 0) * (2400/Filling Docks) [(Tasa
de barcaza (2) > 0) * (2400/Muelles de llenado)]
Pantalla 11-12. Tasa de ajuste para muelle de llenado
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
Asignar número ¿Alguna bar- Verdadero

Detectar caza aún se está
de muelle y de-
tener el llenado llenando?
Nivel de barcaza (J)
Falso
Estaciones
Muelle de barcaza 1
Muelle de barcaza 2
Muelle de barcaza 3
Muelle de barcaza 4
Figura 11-7. Lógica de Detectar para barcazas completas
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.
Beginning Station Range (Intervalo de estación inicial) 1

Ending Station Range (Intervalo de estación final) 4
Crossing Variable (Variable de cruce) Barge Level (J) [Nivel de barcaza
(J)]
Crossing Direction (Dirección de cruce) Positive (Positiva)
Threshold Value (Valor límite) Barge Capacity (Capacidad de la
barcaza)
Crossing Tolerence (Tolerancia de cruce) 0
Pantalla 11-13. Módulo Detectar para barcazas completas

Name (Nombre) Assign Dock Number and Stop Filling

(Asignar número de muelle y detener el
llenado)
Atributte Name (Nombre del atributo) Entity.Type (Entidad.Tipo)
New Value (Nuevo valor) Full Barge (Barcaza llena)
Atributte Name (Nombre del atributo) Dock Number (Número de muelle)
New Value (Nuevo valor) Entity.Station (Entidad.Estación)
Atributte Name (Nombre del atributo) Barge Rate (Dock Number) [Tasa de barcaza
(Número de muelle)]
Atributte Name (Nombre del atributo) (Barge Level (Dock Number)[Nivel de
barcaza (Número de muelle)]
Atributte Name (Nombre del atributo) (Barge Capacity (Dock Number) [Capacidad
de barcaza (Número de muelle)]
Atributte Name (Nombre del atributo) Filling Docks (Muelles de llenado)
New Value (Nuevo valor) Filling Docks - 1 (Muelles de llenado– 1)
Pantalla 11-14. Asignaciones para barcaza completa
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)
Pantalla 11-15. Módulo Decide (Decidir) que comprueba si se

está llenando alguna barcaza
484 Capítulo 11
Cambiar la tasa
de llenado a
Verdadero la salida de la
barcaza
Registrar el Limpiar y liberar Eliminar la enti-

tiempo de llenado el muelle dad de barcaza
Falso
de la barcaza
Figura 11-8. Eliminar entidades de 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.
Name (Nombre) Record Barge Fill Time (Registrar el tiempo de

llenado de la barcaza)
Type (Tipo) Expression (Expresión)
Value (Valor) TNOW - Beginning Fill Time (Dock Number) [TNOW -
Tiempo de llenado inicial (Número de muelle)]
Tally Name (Nombre de la cuenta) Barge Fill Time (Tiempo de llenado de la barcaza)
Pantalla 11-16. Módulo Record (Registro) para el tiempo de llenado de la barcaza

Name (Nombre) Clear and Release Dock (Limpiar y liberar

el muelle)
Action (Acción) Delay Release (Demorar Liberar)
Type (Tipo) Set (Establecer)
Set Name (Establecer nombre) Docks (Muelles)
Selection Rule (Regla de selección) Specific Member (Miembro específico)
Set Index (Establecer índice) Dock Number (Número de muelle)
Delay Type (Tipo de retraso) Triangular (Triangular)
Units (Unidades) Minutos
Minimum (Mínimo) 3
Value (Most Likely) [Valor (más probable)] 4.5
Maximum (Máximo) 7.5
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
Number of Replications (Número de duplicaciones) 15

Warm-up Period, Time Units (Periodo de calentamiento, 5, Days (5, días)
unidades de tiempo)
Replication Length, Time Units (Duración de la 205, Days (205, días)
duplicación, unidades de tiempo)
Hours Per Day (Horas por día) 24
Base Time Units (Unidades de tiempo base) Hours (Horas)
Pantalla 11-18. Parámetros de duplicación para el modelo 11-3

486 Capítulo 11
Últimos tres días

1000
Capacidad de la
Muelle 1 barcaza
Nivel de la
1000 barcaza
Muelle 2
1000
Muelle 3
1000
Muelle 4
Número de barcazas en espera

30
Figura 11-9. Gráficas para el modelo 11-3
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
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.
11.2.4 Modelo 11-4: carga de carbón con proceso de flujo

Se examinará ahora empleando una plantilla de Flow Process (Proceso de flujo), que facilita el
modelado de áreas de retención de material a granel, detección de sensores, lógica de control
y flujo continuo y semicontinuo entre esas áreas de retención. ¿Esto le suena familiar? Bien, de
hecho esta plantilla provee una forma más fácil y directa de modelar sistemas como las opera-
ciones del carbón recién modeladas. En esta sección, se empezará con una breve introducción
a la plantilla de Flow Process y después se mostrará cómo se pueden usar estos módulos en el
modelo del carbón.
El proceso de flujo tiene siete módulos que siguen el paradigma de los tanques y reguladores,
pero podría ser útil considerarlos en el sentido más amplio posible. El módulo Tank (Tanque)
representa un área de retención donde se almacena el material y define los reguladores que con-
trolan el flujo de entrada y salida de esa área de retención. Un regulador es una entrada o salida
monitoreada del tanque en el que se puede ajustar la tasa de flujo máximo mediante el módulo
Regulate (Regular). El módulo Flow (Flujo) crea una conexión de flujo temporal hacia dentro y
fuera de un tanque, o entre dos tanques. La lógica de flujo de este módulo basada en la entidad
es ideal para representar operaciones de procesamientos de lotes. El módulo Sensor (Sensor)
es un poco similar al módulo Detect (Detectar) analizado en la sección 11.1.2; éste le permite
detectar y actuar en cambios en el nivel del tanque. Y finalmente los últimos tres módulos le
permiten tratar a los reguladores de una manera similar a los recursos, es decir, tomar, liberar
y agrupar en un conjunto.
Una característica relacionada es un objeto Nivel de tipo Flujo, que provee un mecanismo
fácil de usar para animar tuberías, transportadores y otros dispositivos que llevan flujo. El nivel
provee un indicador de animación de la dirección y la tasa relativa de flujo.
El lector podría pensar que los constructos recién introducidos son similares, y un poco
redundantes, a otros de Arena. En cierto grado, tendría razón. No obstante, los constructos
continuos analizados antes en este capítulo se diseñaron para manejar sistemas complejos y
poder introducir complejidad innecesaria en sistemas comunes de procesamiento por lotes. El
proceso de flujo no sólo permite modelar estos sistemas, sino que es también más eficaz (es de-
cir, se puede ejecutar más rápido), más exacto y provee algunas capacidades más complejas.
En la sección 11.2.2 cuando se describió primero este modelo de carga de carbón, parecía
simple modelar con conceptos discretos. Luego, conforme se entró en detalle en los aspectos
continuos, la lógica se volvió un poco más compleja. Esta vez se seguirá el mismo procedimiento
básico del modelo anterior, excepto que con el método de proceso de flujo será una descripción
de proceso lineal sin necesidad de la mayor parte de los módulos de datos. Se modelará el área
de almacenaje de carbón como un tanque (recuerde, un tanque es sólo un área de retención). Se
considerará cada uno de los muelles como un regulador; es decir, una salida regulada del inven-
488 Capítulo 11
Crear la Tiempo de
Tomar Almacenaje
barcaza atraca-
muelle principal de
entrante miento carbón
Asignaciones Actualizar las Asignaciones Actualizar

Cargar la
antes de la tasas de carga después de la las tasas de
barcaza
carga máximas carga carga máxima
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-11. Módulo Tank (Tanque) que representa el almacenaje de carbón

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
Figura 11-14. Módulo Flow (Flujo) para transferir carbón a la barcaza
la cantidad de material especificada en el atributo llamado Barge Capacity (Capacidad de

la barcaza).
Esta aplicación simple apenas rasguña la superficie de las capacidades del módulo Flow
(Flujo). El flujo puede transferir hacia fuera de o entre los tanques, y maneja de manera auto-
mática los casos del tanque que se llena o vacía, o situaciones en las que el flujo se restringe de
otro modo. Dirije también la asignación de prioridad entre reguladores que compiten por la
misma capacidad de tanque. Las opciones en el diálogo permiten terminar el flujo con base en
una señal o tiempo transcurrido. Y el Flow maneja con gracia un flujo que se termina anormal-
mente por cualquier razón. Pero mientras todo esto sucede, en el exterior, el Flow se comporta
como un retraso simple (una entidad entra al Flow y espera hasta que se completa o termina la
transferencia especificada, luego la entidad sale al módulo siguiente).
Después que se completa la transferencia de material en el módulo Flow, se usan de nuevo
los módulos Assign y Regulate para limpiar después de la transferencia. (Note que los módulos
Regulate no son necesarios de modo rutinario con el Flow, pero en este caso, se están ajustando
las tasas de flujo máximo en los reguladores cada vez que se inicia o detiene cualquier transfe-
rencia.) Puesto que los módulos de proceso de flujo asumen que el material está siendo movido
de un lugar a otro, se necesita añadir alguna clase de lógica de reabastecimiento para asegurar
que no se acabe el carbón. Se tomará el método más simple añadiendo una entrada a Assign-
ments After Loading (Asignaciones después de la carga) para asignar el TankLevel
(Main Coal Storage) [Nivel de tanque (Almacenaje principal de carbón)] a 10 000, relle-
nando esencialmente la pila después de que se ha atendido a la barcaza. El resto del modelo es
similar al previo, de nuevo usando los módulos Delay (Retraso) y Release Regulador (Liberar
regulador) en lugar del módulo Process que se empleó antes.
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.
11.3 Sistemas de cambio de estado continuo

En las secciones 11.1-11.3 se examinaron procesos continuos en los que la tasa de cambio de las
variables continuas (por ejemplo, líquido en un tanque, carbón en una barcaza), fue constante
o cambió en puntos discretos en el tiempo. Muchos sistemas físicos caen en esta categoría, en
particular donde algún producto a granel o líquido está siendo fabricado o transferido entre
recipientes. Arena se encuentra bien equipado (y ahora, el lector lo está) para analizar dichos
procesos de manera exacta con las características que hemos presentado hasta aquí.
Se volverá la atención a procesos continuos un poco más complejos, donde los valores de las
tasas cambian también continuamente con el tiempo. Muchos tipos de procesos caen en esta
categoría, en particular cuando tienen lugar actividades físicas relacionadas con la temperatura
o reacciones químicas. Otros casos, como estudios de poblaciones grandes (por ejemplo, para
dispersión de enfermedad), requieren también el tipo de método de modelado que se analizará
aquí.
Para introducirlo a los nuevos conceptos requeridos para modelar estos procesos, se usará
un ejemplo simple de la industria metalúrgica donde se necesita modelar la temperatura de
un horno y los lingotes que son calentados en su interior. Se examinará el método conceptual
requerido para captar tal proceso, y se estudiarán los algoritmos empleados por Arena para
simular estos tipos de sistemas. Cuando haya dominado dicho material, el lector debe estar
armado con el conocimiento suficiente que le permita identificar el método apropiado para
simular sistemas continuos y emplear Arena para efectuar el trabajo con éxito.
11.3.1 Modelo 11-5: un horno de termodifusión

Este sistema contiene un horno de termodifusión, donde los lingotes de acero son calentados
para que puedan ser rolados en la etapa siguiente del proceso (Ashor y Bindingnavle, 1973).
Los lingotes llegan a este proceso aproximadamente cada 2.25 horas en promedio, después de
una distribución exponencial para tiempos entre llegadas. El horno en sí tiene espacio para a lo
sumo nueve lingotes, que pueden ser cargados y recargados de modo independiente. Si el horno
se encuentra lleno cuando llega un nuevo lingote, éste se mantiene en un área de almacenamien-
to hasta que hay espacio disponible. Cada lingote se calienta en el horno a una temperatura de
2 200 grados, luego se retira y sale del sistema.
Cuando se carga un lingote en el horno, su temperatura de distribuye de manera uniforme
entre 300 y 500 grados. Debido a que se halla más frío que la temperatura del horno, reduce su
492 Capítulo 11
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.
11.3.2 Modelado de las tasas que cambian en forma continua

Para modelar el proceso del horno se usarán muchos de los conceptos y constructos que fueron
apropiados para captar la operación de carga de carbón en la sección 11-2. Los elementos que
cambian continuamente con el tiempo —las variables de nivel para este modelo— son la tempe-
ratura del horno y la de cada uno de los lingotes en él. Se definirá un nivel para la temperatura
global del horno y otras nueve variables de nivel que representan la temperatura de los lingotes
en las nueve posiciones del horno (correspondientes a su capacidad de nueve lingotes). Estos ni-
veles son análogos a las variables de nivel establecidas en la operación de carga de carbón para
monitorear la cantidad de carbón cargada en las barcazas de un remolcador.
Donde el asunto se torna interesante es cuando se consideran las tasas para este proceso
(cómo cambia la temperatura en el horno con el tiempo y para calentar los lingotes). Previa-
mente, nuestras tasas mantuvieron valores constantes con el tiempo, aunque se podrían intro-
ducir cambios instantáneos en las tasas asignándoles nuevos valores (por ejemplo, dividir in-
mediatamente el flujo de carbón de modo distinto entre los cuatro muelles cuando una barcaza
comienza o termina su operación de llenado). No obstante, en el sistema del horno la tasa a
la cual éste se recalienta a su temperatura objetivo de 2 600 grados depende de su temperatura
actual. De modo similar, la tasa a la cual se calienta el lingote depende de su temperatura y la
del horno. Lo que complica la determinación de cualquiera de las tasas o temperaturas en un
punto del tiempo es que están cambiando continuamente con el tiempo.
Sistemas como éstos se modelan por medio de ecuaciones diferenciales, que son ecuaciones
matemáticas en las que interviene la derivada (tasa de cambio) de una o más variables. Si se
denota el valor de alguna variable del sistema (por ejemplo, una temperatura) como x, entonces
su derivada se denota por dx/dt y define su tasa de cambio con respecto al tiempo.3 En Arena,
un nivel define una variable del sistema, x, y una tasa define su derivada, dx/dt. Cuando no se
puede definir directamente el valor de una cantidad con el tiempo, se emplea este método de
modelado continuo para calcularlo de modo indirecto vía una ecuación diferencial.
Los modelos que han sido vistos hasta el momento en este capítulo utilizaron ecuaciones
diferenciales, donde la derivada (o tasa) fue un valor numérico que cambió sólo en puntos dis-
cretos del tiempo (vía asignaciones de modelo). El lector podría recordar que cuando se aña-
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.
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:
dPj /dt = 0.15 (F Pj )

dPj /dt = 0.15 (F Pj )
donde Pj es la temperatura del lingote que actualmente ocupa la posición j-ésima en el horno.
Serán necesarias nueve ecuaciones de este tipo para definir por completo las temperaturas de
los lingotes.
11.3.3 Método de Arena para resolver ecuaciones diferenciales

Excepto para ciertas clases especiales de problemas, las ecuaciones diferenciales son difíciles
de resolver matemáticamente. Debido a esto, se han desarrollado técnicas numéricas especiales
para aproximar los valores de las variables continuas con el tiempo. (Note que tales métodos
se aplican en general sólo a sistemas de ecuaciones diferenciales de primer orden; en otras pa-
labras, aquellas en las que interviene la variable continua o su tasa pero no derivadas de orden
superior. Las ecuaciones diferenciales de orden superior deben ser convertidas a una serie de
ecuaciones de primer orden.)
Arena emplea estas técnicas para calcular el valor de una variable de cambio continua en un
nuevo punto del tiempo con base en su valor previo, el cambio en el tiempo y su estimación de
la tasa de cambio sobre ese paso de tiempo. En la figura 11-15 se ilustra cómo funciona esto,
Tasa
Error de paso
Valor
∆t
Tiempo
Figura 11-15. Aproximación numérica para variables de cambio continuas

494 Capítulo 11
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.
11.3.4 Construcción del modelo

Para captar las actividades de los lingotes que se mueven por el horno, se tendrán porciones
discretas y continuas en nuestro modelo, justo como en el modelo de operación de carga de
carbón de la sección 11.12. La porción continua del modelo, figura 11-16, incluye un módulo
Continuous; variables de nivel individuales para la temperatura del horno y para cada posición
de lingote en el horno; variables de tasa para modelar la tasa de cambio de temperatura para
los lingotes y el horno; y, un nuevo módulo, CStats, que se usará para colectar una estadística
en la temperatura del horno.
Continuo Niveles Tasas CStats
10 Temperatura del lingote Tasa de calentamiento del Temperatura del

Temperatura del horno lingote horno
Tasa de calentamiento del
horno
Figura 11-16. Módulos relacionados continuos

Number of Dif. Equations (Número de ecuaciones 10

diferenciales)
Minimum Step Size (Tamaño de paso mínimo) 0.01
Maximum Step Size (Tamaño de paso máximo) 0.1
Save Point Interval (Intervalo de Guardar punto) 0
Method (Método) RFK
Absolute Error (Error absoluto) 0.00001
Relative Error (Error relativo) 0.00001
Severity (Severidad) Warning (Advertencia)
Cross Severity (Severidad de cruce) Warning (Advertencia)
Pantalla 11-19. Módulo Continuous (Continuo) para el modelo de horno de termodifusión
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)
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)
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,
SIMAN Expression (Expresión SIMAN) Furnace Temperature (Temperatura del

horno)
Name (Nombre) Temperature of Furnace (Temperatura
de horno)
Data Type (Tipo de datos) “Continuous” (“Continuo”)
Category (Categoría) “User Specified” (“Especificado por
el usuario”)
Identifier (Identificador) “Furnace Temperature” (“Temperatura
del horno”)
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
Llegan los lingotes. Carga en el horno
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
Asignar la Liberar el Disponer

temperatura del espacio del la entidad
lingote a 0 para horno lingote
eliminar
Figura 11-17. Lógica de creación de lingote

498 Capítulo 11
Lingotes a la temperatura objetivo. Eliminar del horno
Asignar Señalar el Disponer la

Detectar número de calentamiento entidad de detec-
lingote terminado del ción de lingote
Temperatura del lingote(J) lingote calentado
Estaciones
Figura 11-18. Lógica para eliminar lingotes del 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.
11.3.5 Definición de las ecuaciones diferenciales con VBA

Se ha completado la porción del modelo que trata con los lingotes: introducirlos al sistema, car-
gándolos en el horno y eliminándolos cuando han alcanzado la temperatura objetivo. Ahora se
Figura 11-19. Habilitación en VBA de ecuaciones continuas
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-
Private Sub ModelLogic_UserContinuousEquations()

Dim oSIMAN As Arena.SIMAN
Dim dFurnaceTemp As Double
Dim nIngotNum As Long
' Establecer la tasa de calentamiento para cada lingote
dFurnaceTemp = oSIMAN.LevelValue(10)
For nIngotNum = 1 To 9
oSIMAN.RateValue(nIngotNum) = _
0.15 *(dFurnaceTemp - oSIMAN.LevelValue(nIngotNum))
Next nIngotNum
' Establecer la tasa de calentamiento para el horno
oSIMAN.RateValue(10) =* 2(2600 - dFurnaceTemp)
End Sub
Figura 11-20. Ecuaciones diferenciales codificadas en VBA

500 Capítulo 11
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.

El capítulo 11 concluye los temas de modelado de este libro. En él se examinó el marco de traba-
jo de Arena para modelar sistemas de cambio continuo. Se juntaron también los conceptos de
modelado discreto de capítulos anteriores con el modelado continuo, ilustrando cómo se apli-
can estos conceptos en dos ejemplos. Además, se construyó un modelo con base en constructos
de proceso de flujo y su combinación.
Cuando el lector se encuentre preparándose para analizar un sistema en el que líquidos u

otras materias primas están siendo elaboradas o manejadas, deben ser considerados los mé-
todos de modelado continuo y proceso de flujo. Algunos sistemas pueden ser modelados por
medio de conceptos continuos y discretos, debido a la naturaleza del material que está siendo
modelado. La estructura de Arena se encuentra diseñada para modelar cualquier combinación
de procesos discretos y continuos, con módulos de proceso de flujo o el módulo Detect y asig-
naciones de tasa continua y variables de nivel ilustradas en este capítulo.
Los dos capítulos restantes no tienen relación directa con el modelado, pero analizan temas
importantes que son críticos para efectuar buenos estudios de simulación. En el capítulo 12 se
complementa el tratamiento de los fundamentos probabilísticos y cuestiones estadísticas en la
simulación, que comenzaron en la sección 2.6, sección 4.6, capítulo 6, y la sección 7.2. Luego,
en el capítulo 13 se proporcionarán algunas observaciones y consejos sabios acerca de cómo
conducir estudios de simulación, incluyendo modelado, diseño, análisis y tratar con personas.
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
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
Cuestiones estadísticas adicionales
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.
12.1 Generación de números aleatorios

Oculto en el cuarto de máquinas de cualquier simulación estocástica se encuentra un generador
de números aleatorios (random-number generator, RNG) trabajando en silencio. El único propó-
sito de tal máquina es producir un flujo de números que son observaciones (conocidas también
como extracciones, muestras o realizaciones) de una distribución uniforme continua entre 0 y 1
(véase el apéndice D) e independientes entre sí. En la simulación, éstos se llaman números alea-
torios. Por supuesto ésta no es la única distribución de probabilidad de la cual el lector deseará
sacar observaciones para mover sus simulaciones (véase la sección 4.6), pero como se compro-
bará en las secciones 12.2 y 12.3, generar observaciones de las otras distribuciones y procesos
aleatorios comienza con números aleatorios.
Cualquier método para generar números aleatorios en una computadora es sólo cierta clase
de algoritmo recursivo que puede repetir la misma secuencia de números “aleatorios” una y
506 Capítulo 12
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
Tabla 12-1. Trazo de una aritmética de LCG
i 22Zi − 1+4 Zi Ui i 22Zi − 1+4 Zi Ui i 22Zi − 1+4 Zi Ui

0 19 24 1 060 52 0.8254 48 400 22 0.3492
1 422 44 0.6984 25 1 148 14 0.2222 49 488 47 0.7460
2 972 27 0.4286 26 312 60 0.9524 50 1 038 30 0.4762
3 598 31 0.4921 27 1 324 1 0.0159 51 664 34 0.5397
4 686 56 0.8889 28 26 26 0.4127 52 752 59 0.9365
5 1 236 39 0.6190 29 576 9 0.1429 53 1 302 42 0.6667
6 862 43 0.6825 30 202 13 0.2063 54 928 46 0.7302
7 950 5 0.0794 31 290 38 0.6032 55 1 016 8 0.1270
8 114 51 0.8095 32 840 21 0.3333 56 180 54 0.8571
9 1 126 55 0.8730 33 466 25 0.3968 57 1 192 58 0.9206
10 1 214 17 0.2698 34 554 50 0.7937 58 1 280 20 0.3175
11 378 0 0.0000 35 1 104 33 0.5238 59 444 3 0.0476
12 4 4 0.0635 36 730 37 0.5873 60 70 7 0.1111
13 92 29 0.4603 37 818 62 0.9841 61 158 32 0.5079
14 642 12 0.1905 38 1 368 45 0.7143 62 708 15 0.2381
15 268 16 0.2540 39 994 49 0.7778 63 334 19 0.3016
16 356 41 0.6508 40 1 082 11 0.1746 64 422 44 0.6984
17 906 24 0.3810 41 246 57 0.9048 65 972 27 0.4286
18 532 28 0.4444 42 1 258 61 0.9683 66 598 31 0.4921
19 620 53 0.8413 43 1 346 23 0.3651 67 686 56 0.8889
20 1 170 36 0.5714 44 510 6 0.0952 68 1 236 39 0.6190
21 796 40 0.6349 45 136 10 0.1587 69 862 43 0.6825
22 884 2 0.0317 46 224 35 0.5556 70 950 5 0.0794
23 48 48 0.7619 47 774 18 0.2857
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
Figura 12-1. Gráficas para un LCG

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:
A = (1403580 An – 2 –– 810728 An – 3)) mod 4294967087

Annn =
A = (1403580 Ann –– 22 – 810728
(1403580 A Ann –– 33) mod
810728 A mod 4294967087
4294967087
B == (527612
(527612 Bn – 1 –– 1370589
1370589 B ) mod 4294944443
B
Bnnn =
A (527612 B
(1403580 n – 1 ––1370589
BA
n –n 1– 2
Bnnnn––––3333)) mod
B
810728 A mod 4294944443
mod 4294967087
4294944443
Luego combina estosBdos–valores
B = (527612 1370589enBel n-ésimo paso como sigue:
) mod 4294944443
n n–1 n–3
Z = (A – Bn)) mod 4294967087

Znnn =
Z = (A
(Annn –– B
Bnn) mod
mod 4294967087
4294967087
Por último,
Z = este
(A –RNG entrega
B ) mod el n-ésimo número aleatorio Un como
4294967087
n n n
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
Pongamos en perspectiva la diferencia entre las duraciones de ciclo anterior y nueva. Si el

viejo generador se puede agotar en diez minutos (lo cual es posible en una PC de 2 GHz si sólo
se generan los números aleatorios y se descartan), el nuevo generador mantendría ocupada
esta máquina durante 2.78 × 1040 milenios. Ahora bien, sabemos lo que usted está pensando
“sí, pero en 1982 pensaron que 2.1 × 103 millones era mucho y que duraría por siempre”, pero
incluso bajo la ley de Moore (la cual observa que las computadoras duplican la velocidad cada
año y medio), será algo como 216 años antes de que una computadora común sea capaz de ago-
tar este nuevo generador en un año sin dejar de calcular. Así que somos buenos por un tiempo,
pero admitámoslo, no por siempre.
Resulta ser bastante útil poder separar el ciclo de un generador en flujos adyacentes de nú-
meros aleatorios sin traslape, lo cual se puede considerar como grifos separados que entregan
flujos distintos de números aleatorios. Para definir un flujo se necesita especificar el vector semi-
lla (seis números en el generador de Arena) y tener cuidado de que los vectores semilla de flujos
sucesivos estén apartados alrededor del ciclo para que las flujos sean largos. El generador de
Arena tiene facilidad para dividir el ciclo de 3.1 × 1057 números aleatorios en 1.8 × 1019 flujos
separados, cada una de longitud 1.7 × 1038. Cada flujo se subdivide en 2.3 × 1015 subflujos de
logitud 7.6 × 1022 por cada una. Nuestra cansada PC de 2 GHz tardaría 669 millones de años
en agotar uno de los subflujos; bajo la ley de Moore, en 49 años, le tomará un mes agotar un
subflujo, pero 187 miles de millones de milenios para agotar un flujo.
El lector puede especificar qué flujo se usará siempre que pida una observación de una
distribución en Arena anexando el número de flujo a los parámetros de la distribución; por
ejemplo, para generar una observación exponencial con media 6.7 a partir del flujo 4, use
EXPO(6.7,4). Si no especifica un número de flujo, Arena lo predetermina en 10. (Puesto que
Arena hace algo de su propia generación de números aleatorios, por ejemplo al generar patro-
nes de llegada no estacionarios y en un módulo Decide [Decidir] tipo “posibilidad”, utiliza el
flujo 10 para eso, así que debe evitar usar el flujo 10 si usted está especificando sus propios flu-
jos.) La idea de utilizar flujos separados de números aleatorios para propósitos individuales en
una simulación (por ejemplo, el flujo 1 para tiempos entre llegadas entre partes, el flujo 2 para
tipos parciales, el flujo 3 para tiempos de proceso, etc.) viene bastante bien para reducción de
varianza, analizada en la sección 12.4. Arena no guarda en realidad todos los vectores semilla,
sino además emplea un método sobre la marcha para calcularlas cuando usted hace referencia
al flujo correspondiente; por esta razón, el lector debe usar probablemente los flujos en el orden
1, 2, 3, etc. (pero omitir 10), para que Arena no tenga que calcular un grupo de vectores semilla
para intervenir los flujos que usted no va a usar.
Por último, si el lector está haciendo duplicaciones múltiples de su modelo (véase capítulo 6
y sección 7.2.2), Arena se moverá de modo automático al comienzo del siguiente subflujo den-
tro de los flujos que usted está usando (incluso si está empleando sólo el flujo predeterminado
10) para la siguiente duplicación. Como se verá en la sección 12.4, esto es importante para sin-
cronizar el uso de números aleatorios en variaciones de un modelo a fin de mejorar la precisión
de sus comparaciones entre alternativas.
Si bien sentimos que el RNG actual de Arena es extremadamente bueno, el lector puede
optar por utilizar el anterior (aunque no lo recomendamos) si en realidad lo necesita por alguna
razón de legado. Para eso, necesita colocar un módulo Seeds (Semillas) del panel Elements (Ele-
mentos) en su modelo; requerirá editar este módulo para evitar un error en tiempo de ejecución,
pero no importa qué semilla especifique para cuál flujo (siempre que identifique un flujo que
está usando) puesto que su sola presencia le indica a Arena que use el generador anterior. La
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 Generación de variables aleatorias

En la sección 4.6 se describió cómo se puede seleccionar distribuciones de probabilidad apro-
piadas para representar la entrada aleatoria para su modelo. Ahora que ya sabe cómo generar
números aleatorios, es decir, muestras de una distribución uniforme entre 0 y 1, necesita trans-
formarlos de alguna manera en extracciones de las distribuciones de probabilidad de entrada
que desea para su modelo. En la simulación, las personas se refieren con frecuencia a tales
extracciones como variables de la distribución.
El método preciso para generar variables de una distribución dependerá, por supuesto, de la
forma de la distribución y los valores numéricos que usted estimó o especificó para sus paráme-
tros, pero hay algunas ideas generales que tienen aplicación en la mayor parte de las distribucio-
nes. Debido a que la puesta en práctica es un poco diferente para variables aleatorias discretas
y continuas, se considerarán por separado.
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
0.1 0.5 0.4
U:
0.0 0.1 0.6 1.0
X= 2 X= 0 X= 3
Figura 12-2. Generación de una variable aleatoria discreta
Este método, examinándoloF(x) en cualquiera de las formas anteriores, se generaliza claramente

a cualquier distribución discreta
1.0 con un número finito de posibles xi. De hecho, se puede usar
incluso si la cantidad de xi es infinita. En cualquier caso, el trabajo real se reduce a cierta clase
de búsqueda para hallar el subintervalo [0, 1] en el cual cae un número aleatorio U, luego de-
U
volver X como la xi apropiada. Si el número de variables xi es grande, esta búsqueda se puede
volver lenta, en cuyo caso hay métodos diferentes por completo para la generación de variables.
No se cubrirán estas ideas0.6
aquí.
Arena tiene integrada la distribución de Poisson, así como cualquier distribución de inter-
valo finito definida por el usuario
0.1 (véase el 0.5
apéndice D). En ambos0.4 casos, se usa el algoritmo
anterior para generar las variables.
12.2.2 Continuas U: 0.1

Consideremos ahora la generación de variables a partir de una distribución de probabilidad x
continua (sección C.2.3 en 0el.0apéndice
0.1 0.6se puede pensar en
C). En tal caso, no 1.0términos de la pro-
2 0 3
babilidad de obtener (exactamente) un valor particular devuelto
Grupo X = 3 puesto que esta probabilidad
siempre será cero. En cambio,X =se 2necesita X = 0 en términos
pensar deXla
=X3 devuelta localizada entre
dos valores. Como un ejemplo específico, tome la distribución exponencial con media β = 5,
que tiene función de densidad de probabilidad (PDF):
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
(1/5)e–x/5 para x > 0

f(x) = (1/5)e –x/5
para x<> 00
f(x) = 0 para x
0 para x < 0
y CDF
1 – e–x/5 para x > 0
F(x) = 10 – e–x/5 para
F(x) = x>
para x <0
0 para x < 0
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.
12.3 Procesos de Poisson no estacionarios

Muchos sistemas tienen cierta clase de eventos de origen externo que los afectan, como clientes
que llegan, llamadas entrantes, automóviles que se aproximan a una intersección o accidentes
que ocurren en una planta. Con frecuencia, es apropiado modelar esta clase de proceso de
evento como aleatorio con alguna distribución de probabilidad continua para tiempos entre
eventos, lo que implica cierta distribución discreta para el número de eventos que ocurren en un
intervalo fijo de tiempo. Si el proceso que gobierna las ocurrencias de evento es estacionario en
el marco de tiempo de la simulación, el lector puede decidir la distribución correcta de tiempo
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
12.4 Reducción de varianza

Como se indicó en varias partes (incluso las secciones 2.6, 4.6, 7.2 y el capítulo 6), las simula-
ciones que usan variables aleatorias de distribuciones de probabilidad como parte de la entrada
producirán a su vez salida aleatoria. En otras palabras, hay cierta varianza relacionada con
la salida de una simulación estocástica. Mientras más varianza haya, menos precisos son sus
resultados; una manifestación de varianza alta son los intervalos de confianza amplios. Así que
la varianza de salida es el enemigo, y sería bueno eliminarlo, o por lo menos reducirlo. Una
forma (mala) de eliminar la varianza en la salida es purgar toda aleatoriedad de sus entradas,
quizá reemplazando las variables aleatorias de entrada por sus valores esperados. Sin embargo,
como se demostró en la sección 4.6.1, esto podría hacer su salida bonita y estable pero también
la volverá por lo general seriamente errónea.
Por consiguiente, a excepción de mayor violencia para la validez de su modelo, lo mejor que
puede esperar en realidad es reducir la varianza en sus medidas de desempeño de salida. Una
forma obvia de hacer esto es con más simulación. Para modelos de terminación, esto implica
más duplicaciones (puesto que ampliar la duración de una duplicación invalidaría el modelo
en el caso de terminación); en la sección 6.3 se proporcionó un par de fórmulas de las cuales
el lector puede aproximar el número de duplicaciones que requiere para reducir el semiancho
del intervalo de confianza a un valor suficientemente pequeño. Para modelos de estado estable,
usted podría hacer también más duplicaciones si está tomando el método de duplicaciones
truncadas para análisis, como se analizó en la sección 7.2.2; o podría hacer más larga su du-
plicación (única) si está tomando el método de medias por lote (sección 7.2.3). En la sección
12.5 se estudiará todo esto en detalle, incluso cómo puede lograr que Arena “decida” sobre la
marcha cuánta simulación hacer.
Pero a lo que se aspira en esta sección es a un almuerzo gratis. Obtener resultados más pre-
cisos mediante trabajo de simulación adicional no es difícil, pero hay muchas situaciones donde
usted puede lograr lo mismo sin ningún1 esfuerzo extra. Lo que por lo común permite esto es el
hecho de que, a diferencia de la mayor parte de los experimentos físicos, el lector tiene el control
de la aleatoriedad en un experimento de simulación puesto que puede controlar el generador
de números aleatorios, como se explicó en la sección 12.1. Esto le permite inducir ciertas clases
de correlaciones que puede explotar a su favor para reducir la varianza y, por lo tanto, la im-
precisión, de su resultado. Estas clases de esquemas se llaman técnicas de reducción de varianza
(o a veces estrategias de reducción de varianza). En la mayor parte de los casos, el lector nece-
sita tener una comprensión completa de la lógica de su modelo y cómo se representa en Arena
a fin de aplicar tales métodos.
Las técnicas de reducción de varianza pueden ser bastante diferentes entre sí y han sido cla-
sificadas en varias categorías amplias. Se analizará en detalle sólo la más popular de ellas, en la
sección 12.4.1, y se describirán de manera breve algunas otras, en la sección 12.4.2.
12.4.1 Números aleatorios comunes

La mayor parte de los estudios de simulación tienen que ver con más que sólo una alternativa (o
escenario) de un modelo. Las diferentes alternativas se podrían determinar mediante algo de sólo
un cambio de parámetro de entrada a una revisión completa del diseño y operación del sistema.
En estas situaciones, usted no está interesado tanto en los valores particulares de las medidas
de desempeño de salida de cada una de las alternativas, sino más bien en sus diferencias en las
alternativas. Estas diferencias son medidas del efecto de cambiar de una alternativa a otra.
1
Bueno, sin ninguno pesado.
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
Figura 12-5. Módulo Statistic (Estadísticas) completo para el modelo 12-1

518 Capítulo 12
Figura 12-6. Resultados de Compare Means

(Comparar medias) para la comparación natural
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
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.
Tabla 12-2. Asignación y uso de flujo para el modelo 12-2
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
(primera visita)
11 Tipo parcial 2 en la celda 2 S P1 C2 De nuevo Módulo Sequence
(segunda visita)
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
Figura 12-7. Resultados de Compare Means (Comparar medias)

para la comparación de CRN sincronizados
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
Var( X –Y ) = Var(X ) + Var(Y)
Var(X –Y ) = Var(X ) + Var(Y ) – 2 Cov(X,Y )

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
Var(X –Y ) = Var(X ) + Var(Y ) – 2 Cov(X,Y )
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.
12.4.2 Otros métodos

Además de los CRN, hay otras técnicas de reducción de varianza, las cuales se mencionarán
sólo de manera breve aquí; véase el capítulo 3 de Bratley, Fox y Schrage (1987) para más de-
talles sobre éstos y otros métodos. A diferencia de los CRN, tales técnicas tienen aplicación
cuando usted tiene sólo una variante de interés del modelo.
El método de variables antitéticas intenta inducir correlación negativa entre los resultados
de una duplicación y otra, y usa esta correlación para reducir la varianza. En una simulación
de terminación, realice la primera duplicación de la manera usual, pero en la segunda reem-
place los números aleatorios U1, U2,... que utilizó en la primera duplicación por 1 − U1, 1 −
U2, etc. Esto aún da como resultado generación de variables válidas puesto que, si U se dis-
tribuye de modo uniforme en [0, 1], entonces 1 − U también. La idea es que, puesto que una
U “grande” produce una 1 − U “pequeña” (y viceversa), los resultados de las duplicaciones
uno y dos estarán correlacionadas negativamente. Su primera observación para el análisis es-
tadístico, entonces, no es el resultado de la primera duplicación, sino más bien el promedio de
los resultados de las primeras dos duplicaciones, que se tratan como un par. Entonces usted
podría continuar y hacer la duplicación tres con letras U “nuevas” (independientes), luego
volverlas a usar en la duplicación cuatro pero en su forma antitética 1 − U; su segunda obser-
vación para el análisis estadístico es entonces el promedio de los resultados de las duplicacio-
nes tres y cuatro. Dentro de un par antitético, la correlación negativa (con esperanza) causará
que el promedio de las dos estadísticas de salida se mueva hacia la verdadera expectativa más
cercanamente que si fueran independientes. Como el método de los CRN, este último requie-
re sincronización cuidadosa del uso de números aleatorios en su modelo, probablemente con
flujos y semillas. En Arena, usted necesitaría llevar a cabo alguna manipulación de bajo nivel
para poner en práctica variables antitéticas puesto que no hay ningún soporte directo.
Las variables de control emplean una variable aleatoria “controladora” para ajustar sus re-
sultados hacia arriba o hacia abajo, como garantiza la variable de control. Por ejemplo, en el
524 Capítulo 12
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).
12.5 Muestreo secuencial

Cuando el lector hace una simulación, debe tratar de cuantificar siempre la imprecisión en sus
resultados. Si considera que tal imprecisión no es suficientemente grande entonces ha termina-
do. Pero si la imprecisión es de cierta magnitud que resulta molesta, necesita hacer algo para
reducirla. En la sección 12.4 se analizaron las técnicas de reducción de varianza, lo cual podría
ayudar. Y en la sección 6.3 se dio un par de fórmulas para aproximar el número n de duplica-
ciones que usted necesitaría (en un modelo de terminación) para obtener una semiamplitud de
intervalo de confianza hasta a un valor suficientemente pequeño que pueda tolerar.
Pero una idea bastante obvia es seguir simulando, un “paso” a la vez, hasta que usted esté
feliz. En el caso de modelos de terminación, un “paso” es la siguiente duplicación; en el caso de
modelos de estado estable, un “paso” es la siguiente duplicación truncada (si usted está toman-
do esa estrategia, como en la sección 7.2.2); o si usted se encuentra haciendo medias por lote
en una sola duplicación (como en la sección 7.2.3), extienda en cierta cantidad la duplicación
simple que tiene en curso. Entonces, después de este siguiente “paso”, compruebe de nuevo
para ver, por ejemplo, si el semiancho del nuevo intervalo de confianza es suficientemente pe-
queño. Si es así, puede parar; si no, continúe y haga el siguiente paso. Si puede darse el lujo, tal
muestreo secuencial es bastante simple y por lo común le dará la precisión que necesita. Lo que
incluso es mejor es que estas ideas, si bien del todo intuitivas, están respaldas por una teoría
estadística sólida; una consecuencia es que la probabilidad de cobertura real de su intervalo de
confianza se aproximará a lo que se supone es, a medida que sus demandas de pequeñez en el
semiancho se vuelvan más estrictas.
En esta sección se le presentarán algunos ejemplos de muestreo secuencial, indicando cómo
puede usted establecer las cosas de modo que Arena tenga cuidado de comprobar y parar por
usted. Se considerarán las simulaciones de terminación en la sección 12.5.1 y el caso de estado
estable en la sección 12.5.2.
12.5.1 Modelos de terminación

Primero se considerará una simulación de terminación. Se modificará el modelo 12-2 (con el es-
tablecimiento de flujos de números aleatorios) puesto que usted nunca sabe cuándo podría de-
sear hacer alguna reducción de varianza y sincronizar los números aleatorios. Se verá esto como
una simulación de terminación o como una simulación de estado estable utilizando el método
de duplicaciones truncadas pero sin ninguna necesidad de periodo de calentamiento. Como

medida de desempeño de salida de interés primario (aquélla cuya semiamplitud de intervalo de
confianza se desea asegurar es “suficientemente pequeña”), se tomará el WIP total promedio.
Primero se hace un número fijo de duplicaciones (25, además de las diez originales para darnos
una mejor posibilidad de obtener una estimación de varianza decente), sin saber en realidad
qué tan amplios serían nuestros intervalos de confianza; se obtiene un intervalo de confianza
de 13.03 ± 1.28. En la sección 6.3 se analizaron también dos fórmulas para aproximar cuántas
duplicaciones serían necesarias para reducir el semiancho de un intervalo de confianza de 95%
para un valor fijo; en este ejemplo, para reducirlo de 1.28 a, digamos, 0.5, nuestras fórmulas di-
cen lo que se necesitaría para hacer 124 o 164 duplicaciones totales en lugar de 25, dependiendo
de qué fórmula se emplee (y sin olvidar que aquéllas son quizá aproximaciones burdas sujetas a
incertidumbre en la estimación de varianza de estas 25 duplicaciones iniciales).
Invocaremos en cambio la idea de muestreo secuencial para reducir esta semiamplitud a
0.5. Se tiene que hacer un cambio menor a nuestro modelo (en lo que llamamos modelo 12-3)
para pedirle que mantenga la duplicación hasta que el semiancho del intervalo de confianza de
95% en las duplicaciones para la medida de desempeño de salida de WIP total promedio mida
menos de 0.5, para después detener las duplicaciones. Recuerde, de la sección 6.3, que si usted
solicita las duplicaciones múltiples, Arena calculará de forma automática intervalos de con-
fianza de 95% en las duplicaciones en las cantidades que usted especifique para sus informes;
utilizaremos las variables internas de Arena que describen estos intervalos de confianza para
continuar el muestreo secuencial. Las variables de Arena pertinentes son:
< ORUNHALF (Output ID), el semiancho del intervalo de confianza automático en las
duplicaciones de muchas otras que han sido completadas, donde Output ID es la identi-
ficación de la medida de salida de interés (en nuestro caso, Avg Total WIP);
< MREP, el número total de duplicaciones que estamos requiriendo (inicialmente el cam-
po Number of Replications [Número de duplicaciones] en Run > Setup > Replication
Parameters [Ejecutar > Fijar > Parámetros de replicación]);
< NREP, el número de duplicación en el que se está en el momento (= 1, 2, 3,...).
Aquí tiene la estrategia general. Al comienzo, especifique MREP como algún valor ab-
surdamente enorme en el campo Number of Replications en el cuadro de diálogo Run >
Setup > Replication Parameters; esto inicia las duplicaciones y las mantiene así hasta que noso-
tros mismos las cortamos cuando el semiancho se vuelve suficientemente pequeño. Se añade un
poco de lógica al modelo para ocasionar que la única entidad de control llegue al comienzo de
cada duplicación, cuyo trabajo es comprobar si ya terminamos; en otras palabras, si ORUNHALF
(Avg Total WIP) es menor que la tolerancia que se desea, 0.5. Si no, se necesita seguir con
la simulación para que dicha entidad se elimine por sí misma; se continuará y se hará la dupli-
cación que está comenzando y se comprobará de nuevo al comienzo de la siguiente duplicación.
Por otro lado, si el semiancho actual es suficientemente pequeño, se está listo para terminar.
Sin embargo, debido a que ya hemos comenzado la duplicación actual (al tener mostrada la
entidad checking [comprobación]) tenemos que terminarla, pero antes se dirá a nuestra entidad
de control que restablezca MREP (el número total de duplicaciones que se desea) a NREP (el
número que habremos completado al final de la que está iniciando), lo cual concluirá las dupli-
caciones después de ésta.
Note que tal estrategia “excede” (por uno) el número de duplicaciones requeridas en reali-
dad; resulta que el lector no puede hacer de manera confiable la comprobación de terminación
526 Capítulo 12
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-8. Lógica de control para el muestreo secuencial

en simulaciones de terminación
Figura 12-9. Módulo Create para la lógica de control del muestreo

secuencial en simulaciones de terminación
su valor absurdamente alto y continuamos y hacemos esta duplicación (y comienza la siguiente

también). A continuación, la comprobación en el módulo Decidir es ver si el semiancho actual
ORUNHALF (Total Cost) es aún demasiado grande; si es así, se necesita iniciar más dupli-
caciones, de modo que se elimine la entidad también (de nuevo vía una conexión gráfica).
Si, sin embargo, NREP es por lo menos 3 y el semiancho que tenemos en registro (la com-
pletada al final de la duplicación previa) es a lo sumo 0.5, se descenderá por ambas declara-
ciones If y se sacará el punto de salida Else, cuya conexión gráfica envía la entidad al módulo
Assign (figura 12-11), donde MREP se establece en NREP, el número de duplicación actual, lo
cual ocasiona que la simulación se detenga al final de la duplicación que ahora inicia (como se
mencionó, tal duplicación final no es necesaria desde el punto de vista técnico pero se ejecutará
de cualquier modo). Note en el módulo Assign que se seleccionó el Tipo de asignación (Assig-
nment Type) como Otro (Other), puesto que MREP es una variable integrada de Arena con una
palabra reservada como su nombre. Seleccionar Assignment Type como Variable daría como
Figura 12-10. Módulo Decide para la lógica de control del muestreo

528 Capítulo 12
Figura 12-11. Módulo Assign (Asignar) para lógica de control del muestro
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-
Salida Promedio Promedio

Promedio Semiamplitud mínimo máximo
WIP total promedio 13.6970 0.50 8.7036 30.0500
Figura 12-12. Informe para la ejecución de muestreo secuencial de terminación

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).
12.5.2 Modelos de estado estable

La preparación del muestreo secuencial para los modelos de estado estable es por lo menos tan
fácil como para los modelos de terminación, aunque por supuesto la cantidad de tiempo de
cálculo puede volverse aterradora si necesita hacer duplicacines realmente largas y demanda
también precisión muy estricta. Quizá es prudente tener alguna idea de cuánta precisión es
práctica antes de preparar una ejecución de muestreo secuencial y hacerla menos estricta.
Si usted está tomando el método de las duplicaciones truncadas para el análisis de estado
estable, como se describió en la sección 7.2.2, puede hacer cosas justo como se describió en la
sección 12.5.1, excepto que ahora tendría un periodo de calentamiento especificado en Run >
Setup > Replication Parameters (Ejecutar > Configurar > Parámetros de replicación) para
llevar a cabo el truncamiento de datos iniciales a fin de aminorar el sesgo de inicio. Una precau-
ción aquí es que usted necesita hallarse bastante seguro de que el tiempo de calentamiento es
suficiente para deshacerse del sesgo de inicialización, de tal manera que no realice calentamien-
tos más largos de lo necesario. La razón de este consejo es que si quiere un intervalo de confian-
za estricto con esta estrategia, lo tendrá en realidad. Sin embargo, si hay sesgo en sus resultados
debido a calentamiento insuficiente, sus intervalos de confianza determinados de modo secuen-
cial se volverán menos estrictos en torno a un punto sesgado, lo cual significa que el bonito in-
tervalo estricto que usted obtiene falla probablemente en términos de abarcar el valor esperado
de estado estable. Y, mientras más estricto haga su intervalo, peor es el problema puesto que el
sesgo sigue presente, pero el intervalo se hace más pequeño y, por lo tanto, tiene más probabi-
lidades de no cumplir con la esperanza de interés de estado estable. Así, mientras más trabaje,
peor estará en términos de la probabilidad de cobertura del intervalo de confianza.
Por lo tanto, a menos que usted se encuentre bastante confiado de que ha eliminado mucho
sesgo inicial, podría ser más seguro preparar una sola ejecución larga que mantendrá hasta
530 Capítulo 12
que el semiancho del intervalo de confianza resultante satisfaga su criterio de pequeñez. En

este caso, los intervalos de confianza de medias por lote que Arena intenta formar a partir de
una sola ejecución larga (sección 7.2.3) funcionan bastante bien para este propósito. La clave
es el campo de condición de terminación Run > Setup > Replication Parameters, donde usted
especifica el criterio de pequeñez de semiamplitud (y elimina de su modelo los otros dispositivos
de paro de duplicación, como el campo Replication Length [Duración de la duplicación] en
Run > Setup > Replication Parameters). Las variables internas pertinentes de Arena para esto
son THALF(Tally ID), que devuelve el semiancho actual del intervalo de confianza de 95%
en una estadística Tally (Cuenta) con Tally ID(identificación de cuenta) en su argumento, y
DHALF(Dstat ID) para la estadística de salida (persistente con el tiempo) DSTAT. El esquema
de procesamiento y reprocesamiento por lotes descrito en la sección 7.2.3 se hace cargo y su
ejecución se detendrá tan pronto como se satisfaga la condición de terminación. Si una determi-
nada duración de ejecución en el trayecto no es suficientemente larga para formar un intervalo
de confianza válido de medias de lote, y ocasiona que este esquema concluya “(Insuficiente)”
o “(Correlacionado)” como se describe en la sección 7.2.3, el valor numérico de la variable
semiamplitud es establecido por Arena en un número enorme; esto causará que su duplicación
se extienda puesto que el semiancho parece demasiado grande, que es el comportamiento que
usted desea.
Para ilustrar esto, se creará el modelo 12-4 modificando el modelo 7-4 de la sección 7.2.3, que
originalmente se preparó para una sola ejecución larga de 50 días de los cuales se desecharon
los dos primeros como un periodo de calentamiento. El resultado obtenido de la sección 7.2.3
fue un intervalo de confianza de media por lote de 95% de 13.6394 ± 1.38366 en el WIP total
promedio esperado de estado estable. ¿Qué piensa de ampliar la ejecución lo suficiente para que
la amplitud baje a 1, por ejemplo? Hacer este cambio requiere sólo un par de modificaciones en
Run > Setup > Replication Parameters, como se ilustra en la figura 12-13. Hemos limpiado el
campo Replication Lenght (el valor predeterminado de “Infinite” aparece después de cerrar el
cuadro de diálogo) y llenado el campo Terminating Condition con la regla de detención que se
desea, DHALF (Total WIP) < 1.0. Eliminamos también el archivo de salida Total WIP
History One Long Run.dat del módulo de datos Statistic, puesto que ya no es necesario
guardar estos valores.
Parte del informe aparece en la figura 12-14 e indica que la precisión deseada para la medida
de salida Total WIP se logró en realidad, aunque de nuevo sólo apenas, como se esperaría
de una regla de detención secuencial. Para lograr esto, el modelo decidió ampliar su tiempo de
ejecución a casi 99 días (142148.4917 minutos, para ser más precisos), en comparación con la
ejecución original de 50 días.
Como con el muestreo secuencial para simulaciones de terminación, el lector puede modifi-
car la condición de terminación para incluir criterios de pequeñez en cada uno de los distintos
intervalos de confianza en lugar de sólo uno. Usted puede especificar también las reglas de
detención de precisión relativa con base en la relación del semiancho a la estimación puntual;
para este fin, las variables de Arena TAVG (Tally ID) y DAVG (DStat ID) dan el promedio
actual de la estadística indicada Tally o Dstat, respectivamente (véase el ejercicio 12-6).
12.6 Diseño y ejecución de experimentos de simulación

Como hemos tratado de remarcar en todo el texto, un modelo de simulación es mucho más que
algo para ejecutar sólo una vez. Además, usted debe considerarlo como una base de pruebas
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
Time Persistent Average Half Width Minimum Value Maximum Value

(Persistente en el tiempo) (Promedio) (Semiamplitud) (Valor mínimo) (Valor máximo)
WIP total 12.6314 0.979115017 0.00 34.0000
Figura 12-14. Resultados para el muestreo secuencial en el WIP total de estado

estable usando los intervalos de confianza automáticos de medias de lote
532 Capítulo 12
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
será al comienzo de su ejecución). En vez de eso, compruebe la condición en su forma equiva-

lente, H < 0.05 A.
12-7 Como se observó en la sección 12.4.1, los módulos Decide tipo-posibilidad utilizan el
flujo 10 de números aleatorios para sus lanzamientos de hipermoneda, y no hay forma de cam-
biar eso en el módulo. Describa (en palabras) cómo podría trabajar en torno a este asunto a
fin de emplear cualquier flujo que usted desee para realizar lo mismo. Construya también un
módulo Decide que lance una hipermoneda de cuatro lados con probabilidades 0.2, 0.4, 0.1 y
0.4 para rutas salientes A, B, C y D, respectivamente, excepto el flujo 7 de números aleatorios.
Verifique que su modelo produce decisiones con probabilidades que son aproximadamente co-
rrectas.
CAPÍTULO 13
Realización de estudios de simulación
En la sección 2.8 esbozamos brevemente los ingredientes clave de un estudio de simulación.

Ahora que el lector ha logrado cierta perspectiva del proceso de desarrollo y análisis de un
modelo de simulación, es el momento de dar un paso atrás y analizar las actividades generales
incluidas en un típico estudio de simulación. Conforme procedamos con este análisis, supon-
dremos que usted es el analista, es decir, el individuo que llevará a cabo el estudio de simulación.
Puede estar dentro del personal de apoyo corporativo, de apoyo a nivel operacional o ser un
consultor externo. El cliente es quienquiera que solicite el estudio, el cual se enfocará en un
sistema de algún tipo. El sistema podría producir bienes fabricados, comida rápida o servicios.
También podría ser un sistema para manejo de papelería, un centro de atención telefónica, un
centro o sistema de distribución o cualquier otro sistema que dé como resultado un producto
o servicio. Supondremos que el lector es capaz de trasladar las ideas que se presentan en este
capítulo (así como en el resto del libro) a sus propias circunstancias.
Existen muchas publicaciones de las actividades que se van a analizar en el capítulo. Proba-
blemente la mejor fuente sea Proceedings of the Winter Simulation Conference (Procedimientos
de la Conferencia de simulación de invierno), una conferencia llevada a cabo anualmente en
el mes de diciembre. Una selección de ellos incluye a Balci (1990, 1995), Farrington y Swain
(1993), Goldsman (1992), Kelton (1996), Kleindorfer y Ganeshan (1993), Musselman (1993),
Sadowski (1989, 1993), Sargent (1996) y Seila (1990). Otra muy buena fuente es un artículo de
Banks y Gibson (1996) en la revista IIE Solutions.
Comenzaremos con el análisis de lo que constituye una simulación exitosa en la sección 13.1,
seguida por la sección 13.2 que contiene algunos consejos sobre la formulación del problema.
La sección 13.3 toca el tema del uso de la metodología adecuada para la solución del problema.
Suponiendo que la simulación sea la metodología preferida para la solución, continuamos con
la especificación del sistema y de la simulación en la sección 13.4. La formulación del modelo
y las actividades de construcción se analizan en la sección 13.5 y los enfoques de verificación
y validación siempre presentes se plantean en la sección 13.6. La sección 13.7 analiza la ex-
perimentación y el análisis, y la sección 13.8 proporciona una visión general de los requisitos
sobre la forma de presentar los reportes y la documentación para un proyecto de simulación.
Concluimos este capítulo con un breve análisis de la capacidad de tiempo de ejecución de Arena
(sección 13.9), que es una buena forma para difundir su trabajo.
13.1 Un estudio exitoso de simulación

Antes de empezar a hablar sobre lo que involucra un estudio de simulación, hay que tratar el
tema de lo que define un exitoso proyecto de simulación. Parecería obvio que si se resuelve el
problema o se satisfacen los objetivos se logrará el éxito; sin embargo, éste no siempre es el caso.
En la mayor parte de las situaciones, la declaración final de éxito o fracaso la hará el nivel más
alto de la gerencia que pague la cuenta… y, le guste o no, ahí tienen la tendencia de ver el pro-
blema o los objetivos en un contexto diferente. Ilustremos esto con un ejemplo de la vida real.
536 Capítulo 13
Un proveedor automotriz desarrolló un proceso altamente exitoso para producir un con-

junto especializado de partes para la automotriz OEM (original equipment manufacturer [fa-
bricante de equipo original]) y después para el mercado. El proceso se implementó usando
un concepto de célula de fabricación de alto volumen y semiautomática. Aunque el proceso
produjo partes de alta calidad y bajo costo, el sistema inicial no lograba un uso elevado para la
pieza clave y más costosa del equipamiento en el proceso. Debido a la variabilidad en los tipos
y cantidades de partes que se producían y en los tiempos de proceso de esas partes, se eligió
la simulación como una herramienta de análisis. El objetivo era rediseñar el sistema existente
o diseñar un nuevo sistema de producción que hiciera un mejor uso del equipo clave; en otras
palabras, un sistema que lograra la misma calidad, pero a un costo de producción por parte más
bajo. Un objetivo secundario era idear una forma de permitir aumentos graduales en el volu-
men de producción al añadir equipo al sistema de forma paulatina, en lugar de sólo construir
una nueva célula.
Se emprendió el estudio de simulación y, después de un exhaustivo análisis del sistema exis-
tente, se determinó que no era posible lograr los resultados deseados con el concepto actual
de célula. La simulación entonces se usó para desarrollar, diseñar y analizar varios enfoques
nuevos. Esto dio como resultado un diseño de sistema de producción completamente diferente
que en última instancia se recomendó a la administración como el sistema de producción del fu-
turo. Este nuevo diseño de sistema satisfizo todos los objetivos y el equipo del proyecto declaró
que el estudio de simulación había sido un éxito. La administración aceptó la recomendación
del equipo y autorizó la construcción de un sistema que usara el nuevo concepto de diseño. Se
construyó el nuevo sistema, pero no funcionó como se proyectó, haciendo que la administra-
ción declarara que el estudio de simulación había sido un fracaso dado que el nuevo sistema,
que se construyó con base en los resultados de la simulación, no cumplía con las expectativas.
De hecho, la producción resultante fue casi 30% más baja que la proyectada.
Así que, ¿qué sucedió? Por fortuna para la reputación de la simulación, el equipo encargado
de ella se dedicó a realizar un análisis posterior del sistema. El modelo de simulación del nuevo
sistema se desempolvó y comparó con el sistema real, que ahora existía. Se modificó la simu-
lación para representar el sistema como se construyó de verdad y, para la sorpresa del equipo
de simulación, predijo que el nuevo sistema produciría exactamente el volumen que estaba
generando en la actualidad. Así que analizaron las modificaciones que se hicieron al modelo de
simulación y encontraron que podrían clasificar aquéllas en dos grupos.
El primer grupo de modificaciones al modelo estaba compuesto de los cambios de datos
requeridos para el modelo con base en las mediciones de los tiempos reales de operación que
ocurrían en el nuevo sistema. Como con frecuencia sucede, se habían incluido varios tipos nue-
vos de equipamiento en el nuevo diseño del sistema y los vendedores que proporcionaron este
nuevo equipo fueron más que optimistas en sus estimados de los tiempos de operación. Esto
justificó un tercio de la pérdida de producción resultante.
El segundo grupo de modificaciones al modelo estaba compuesto de cambios en el diseño
del sistema real que se implementó. Como resultado, había dos errores críticos en el nuevo dise-
ño del sistema. Uno fue causado porque la colocación del nuevo sistema no permitía suficiente
espacio de piso como lo solicitaba el diseño de la simulación. Así, el diseño del sistema se modi-
ficó para que se ajustara al espacio disponible. El segundo error se debía a cambios solicitados
por la alta gerencia en un intento por disminuir el costo total del nuevo sistema. Los cambios
justificaron los dos tercios restantes de la pérdida de producción.
Realización de estudios de simulación 537
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.
13.2 Formulación del problema

El primer paso en cualquier tarea de resolución de problemas es definir y formular éste. En el
mundo real, rara vez va a recibir las hojas de papel con el problema a resolver completamente
definido. Con mayor frecuencia al lector (el analista) se le acercará alguien (el cliente) que pien-
sa que usted podría ayudarlo. El problema inicial rara vez se encuentra claramente definido. De
hecho, puede no ser obvio que la simulación sea la herramienta apropiada. En este punto, el
lector tiene que ser capaz de abrir un diálogo con quien lo solicita, o su representante, y hacerle
una serie de preguntas que al final le permitirán definir el problema por completo. Con frecuen-
cia, el problema final que se acaba tratando es muy diferente del que inicialmente se presentó.
Muchos estudios de simulación tratan con sistemas que no satisfacen las expectativas de los
clientes. El cliente quiere saber ¿cómo soluciono esto? Otros estudios de simulación no se con-
centran en un problema conocido, sino que intentan evitar un potencial problema futuro. Este
caso es el más frecuente cuando se usa una simulación para ayudar a diseñar un nuevo sistema.
Aun hay otro tipo de estudios de simulación compuesto por aquellos enfocados en un sistema
que se halla totalmente diseñado, pero que todavía no se ha construido o implementado. En
este caso, se le preguntará si el sistema se desempeñará como se predijo.
Así que con frecuencia, los problemas se lanzan en la forma de una serie de preguntas: ¿lo
puede arreglar? ¿Funcionará? ¿Puede asegurarme que funcionará? En realidad, éstos son los
mejores tipos de problemas porque el lector poseerá el potencial de tener un impacto en el sis-
tema (y en su carrera). El peor tipo de problema se presenta cuando se anuncia que la empresa
quiere comenzar a usar la simulación, así que se le pide desarrollar una simulación para un
sistema arbitrario.
Supongamos que el lector tiene por lo menos una vaga noción de cuál es el problema y, con
un poco de suerte, una mejor idea de lo que es el sistema. Podría ser una buena idea comenzar
con el sistema. ¿Existe el sistema en la actualidad, es un nuevo diseño o aún no se ha diseñado?
Sabiendo esto, puede intentar limitar el sistema para propósitos de estudio. ¿El sistema consta
de una sola operación o un pequeño número de ellas, un departamento grande, toda una insta-
lación o la empresa por completo? Aunque sería bueno que pudiera construir paredes alrededor
del sistema, de forma que no hubiera interacciones con el otro lado de la misma (como la Gran
Muralla china), probablemente ése no sea el caso. Sin embargo, podría por lo menos intentar
colocar límites iniciales al tamaño del sistema. Pruebe no moldear estas fronteras en piedra, ya
que quizá deba expandirlas o contraerlas conforme sepa más acerca del problema y el sistema.
Habiendo establecido algunas fronteras iniciales, ahora intente definir las métricas del des-
empeño. En realidad existen dos tipos de métricas que le incumben. Las primeras, y las más
obvias, son las métricas del desempeño que se emplearán para medir la calidad del sistema en
estudio. Las segundas, y quizá las más importantes, son las métricas del desempeño que se usa-
rán para mensurar el éxito del estudio. Concentrémonos en la primera clase de métricas. Aun-
que el cliente puede insinuar que sólo existe una métrica, casi siempre existen varias que hay que
considerar. Por ejemplo, la aplicación puede ser un restaurante de comida rápida en donde el
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.
13.3 Metodología de solución

No vamos a intentar describir cada técnica de solución de problemas conocida por la humani-
dad y recomendar dónde debería usarla. Sin embargo, sí le recomendamos que por lo menos
considere técnicas de solución alternativas. También debería tener en cuenta, en cierta forma,
el costo de usar una técnica de solución particular comparada con los beneficios potenciales
de la solución final. Por desgracia, identificar la mejor metodología de solución no siempre es
una tarea fácil. Si determina que una metodología en específico podría darle la mejor respuesta,
pero nunca ha usado tal técnica, éste puede no ser el mejor momento para experimentar. Por
lo tanto, debe reformular la pregunta. Dadas las metodologías de solución con cuyo empleo se
siente a gusto, ¿cuál sería la que más probablemente le dé la solución más rentable?
Algunas veces la elección es obvia, al menos para nosotros. Por ejemplo, si se le pide desa-
rrollar un análisis de capacidad aproximada de un sistema propuesto y únicamente se le dan
los valores medios para todos los parámetros del sistema, y está sólo interesado en los usos
promedio, puede ser más rápido (e igual de acertado) usar una calculadora para determinar la
respuesta. En el otro extremo, se le podría pedir que encontrara la configuración de las rutas
óptimas para una flotilla de autobuses escolares o camiones de basura. Aunque podría usar la
simulación, existen otras herramientas específicamente diseñadas para resolver este problema.
Le sugeriríamos considerar la compra de un producto para implementar tal herramienta.
Averigüe primero qué tanto tiempo tiene para analizar el problema. Si necesita una res-
puesta de inmediato, entonces la simulación no es una opción. Nosotros evitamos esto un poco
porque existen raras circunstancias en donde la simulación se puede usar para analizar proble-
mas de forma rápida. Podría tener un problema muy sencillo, o un sistema muy pequeño, que
le permita desarrollar una simulación usando las construcciones de alto nivel de Arena en sólo
unas pocas horas.
También existen casos en donde las empresas dedican esfuerzos a desarrollar modelos de
simulación genéricos que se pueden alterar de forma rápida. Estos tipos de modelos se realizan
por lo general cuando existen muchos sistemas similares dentro de una organización. Enton-
ces se desarrolla una simulación genérica que pueda usarse para modelar cualquiera de estos
sistemas simplemente cambiando los datos. La tarea de cambiar los datos puede realizarse
muy fácilmente si los valores se encuentran contenidos en un archivo o programa externos.
Esta fuente externa podría ser un archivo de texto o una hoja de datos. Casos en donde se ha
540 Capítulo 13
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.
13.4 Especificación del sistema y la simulación

Hasta el momento quizá hemos dado la impresión de que un estudio de simulación consiste en
una serie de pasos bien definidos que hay que seguir en un orden específico, como la receta de
un libro de cocina. Aunque la mayoría de los analistas en simulación experimentados están de
acuerdo en que por lo general existen algunas actividades o pasos bien definidos, a menudo és-
tos se desempeñan en forma repetida en una manera interactiva. Puede encontrar que a medio
camino del desarrollo de una simulación, las condiciones cambian de forma imprevista, hay
nueva información disponible o se logra una pronta perspectiva que engendra nuevas ideas. Lo
cual puede hacer que vuelva a visitar la fase de la formulación del problema o altere el diseño
de su modelo de forma drástica. Esto no es del todo poco común, así que prepárese para retro-
ceder y visitar de nuevo el problema siempre que cambien las condiciones.
El proceso de desarrollar las especificaciones puede tomar muchas formas, dependiendo
del tamaño del estudio, la relación entre el analista y el cliente y la habilidad de ambas partes
para ponerse de acuerdo en los detalles en esta etapa temprana. Si un individuo juega ambos
roles (cliente y analista) tal paso puede combinarse con la formulación del modelo y las fases
de construcción. Aunque todavía sea necesario definir y entender el sistema por completo,
probablemente no se requiera el desarrollo de una especificación de simulación formal. Sin
embargo, si usted mismo se encuentra en el otro extremo, en donde el analista es un consultor
externo, una especificación formal podría ser muy útil para ambas partes. Para propósitos
del siguiente análisis, imaginemos que nos hallamos en alguna parte entre los dos extremos.
Supongamos que el cliente y el analista no son la misma persona y que se desarrollará un
documento escrito.
Antes de proceder, resumamos en dónde nos encontramos en el proceso y hacia dónde que-
remos ir. Ya formulamos el problema y definimos los objetivos del estudio. Decidimos usar la
simulación como medio para resolver nuestro problema y ahora estamos listos para definir los
detalles del estudio de simulación que sigue.
Un buen lugar para comenzar es en el propio sistema. Si el sistema existe, vaya al lugar y ca-
mine por él. El mejor consejo es que observe, toque y pregunte. El lector quiere entender lo que
está sucediendo y por qué está ocurriendo, así que no tema hacer preguntas, incluso aquellas
que parezcan insignificantes. A menudo descubrirá que las actividades se desarrollan de una
forma específica sólo porque ésa es la forma en que siempre se han hecho, mientras que otras
veces encontrará que existen muy buenas razones para una rutina. Conforme aprenda más
sobre el sistema, comience pensando en términos de cómo modelará estas actividades. Y más
importante, piense acerca de si es necesario incluir ciertas actividades en el modelo de simula-
ción. En esta etapa del proceso, el lector se desempeñará como analista de sistemas, no como
un modelador de simulación. Por lo tanto, no tema hacer las recomendaciones que podrían
mejorar el proceso. Proporcionar entradas tempranas que resulten sólo en mejoras menores
puede aumentar su credibilidad para las siguientes tareas.
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
< ¿Qué tipo de animación se requiere?

¿Se necesitan diferentes animaciones en las diversas fases del proyecto?
¿Cómo se usarán estas animaciones?
< ¿Quién verificará y validará el modelo y cómo se hará esto?
¿Hay disponibles datos para comparar?
¿Qué tan precisos son estos datos?
< ¿Qué tipo de salidas se requieren?
¿Cuáles son las medidas de desempeño primarias?
¿Pueden éstas clasificarse o ponderarse?
< ¿Qué tan general deberá ser el modelo?
¿Será éste revisado para otras decisiones?
< ¿Quién desempeñará el análisis?
¿Qué tipo de análisis se requiere?
¿Qué tan confiable debe ser en sus resultados?
< ¿Cuántos escenarios considerará?
¿Cuáles son?
< ¿Cuáles son los principales fundamentos del estudio?
¿Cuándo tienen que completarse?
< ¿Cuáles son las formas de entrega?
Ésta no intenta ser una lista completa, pero debería darle una idea general de los detalles
requeridos.
Por lo general, dicho tipo de análisis ilumina a ambas partes. En tal clase de foro, el analista
pregunta y registra la información. La suposición es que el cliente tiene toda la que se requiere,
o al menos la mayor parte. La experiencia demuestra una situación algo diferente. En la ma-
yoría de los casos, el cliente es un equipo de tres a seis individuos que representan diferentes
niveles de interés en el sistema. Por lo general, tienen diferentes áreas de especialización y co-
nocimiento del sistema. Es común encontrar que estos individuos difieren bastante en algunos
de los detalles del sistema que por lo general tienen que ver con descripciones del proceso y la
lógica de decisión, aunque no quedan excluidas otras áreas. Esto no debería sorprender, ya que
lo que se intenta es obtener una completa comprensión del sistema, así como un consenso en
cuanto a cómo funciona. Si hay desacuerdo en ciertos detalles, le sugerimos que se aparte y deje
que el equipo del cliente llegue a un consenso.
Si está desarrollando unas especificaciones por primera vez, no espere obtener todas sus
respuestas durante el encuentro inicial. Podría considerar la regla 70/20/10. A través de la expe-
riencia, hemos encontrado que casi el 70% del tiempo el equipo del cliente poseerá la respuesta
completa o la información requerida. Cerca del 20% de este tiempo el equipo no sabrá la res-
puesta, pero sí cómo obtenerla (por ejemplo, quizá deban preguntarle a Dennis, quien tiene el
turno nocturno). El 10% del tiempo restante no tiene ni idea de cuál es la respuesta ni de dónde
encontrarla (o hay varias respuestas compitiendo entre sí). Esto le podría sorprender, pero es
un fenómeno bastante común. No permita que le moleste; sólo deje en claro que usted necesita
la información y pregunte cuándo estará disponible.
En dicha reunión, también explorará la disponibilidad, o falta de la misma, de datos para
llevar a cabo su simulación. De nuevo, no espere obtener todos los datos que necesita en la pri-
mera reunión. Sin embargo, es importante saber qué datos estarán disponibles al final y cuándo.
También debería tomar nota de qué datos provienen de fuentes históricas y cuáles serán estima-
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
13.5 Formulación y construcción del modelo

La parte agradable de tener una especificación completa del modelo y el estudio de simulación
es que permite diseñar un modelo que pueda satisfacer fácilmente todos los objetivos. Antes
de abrir una nueva ventana de modelo y comenzar a colocar módulos, le recomendamos que
invierta algo de tiempo en la formulación del diseño. Algunas de las cosas que tendrá que tomar
en consideración son la estructura y las restricciones de los datos, el tipo de análisis a desarro-
llar, el tipo de animación requerida y su comprensión actual de Arena. Cuanto más complicado
sea el sistema, más importante será la formulación.
Por ejemplo, considere una simulación de un gran almacén con 500 000 SKU. Obviamente
tendrá que desarrollar una estructura de datos que contenga la información necesaria sobre
el estado cambiante de los contenidos y a la que se pueda tener un fácil acceso mediante el
modelo de simulación. Si está interesado sólo en el número de recolectores y parrillas de carga
que se requieren para un nivel de actividad dado, puede no ser ni siquiera necesario incluir la
información en un nivel SKU. Podría crear un modelo con base en pedidos generados de forma
aleatoria. Si puede desarrollar expresiones exactas para la frecuencia y ubicaciones de tales
actividades, este tipo de modelo podría responder sus preguntas. Sin embargo, si se encuentra
interesado en los detalles del sistema, obviamente tendrá que crear un modelo mucho más ela-
borado. También debe entender los requerimientos de la animación. Si no se pide animación
alguna, podría animar el movimiento del recolector y las actividades como una serie de demo-
ras. Si necesita una animación detallada, tendrá que estructurar su modelo, muy probablemente
usando construcciones guiadas de transportadores, para permitir el movimiento y posiciona-
miento reales de los recolectores en la animación.
También tendría que considerar el impacto potencial de los diferentes escenarios que se
vayan a evaluar. ¿Debería crearse cada escenario como un modelo diferente, o sería suficiente
con crear un modelo general que sólo requiera cambios de datos? Considere nuestro almacén.
Si desea comparar una operación de recolección manual con una operación de recolección
automática, quizá requiera diferentes modelos (aunque puede emplear la misma estructura de
datos para ambos modelos). Sin embargo, si sólo quiere comparar diferentes tipos de diseños,
podría desarrollar un modelo general.
Una vez formulado el enfoque de su modelo, deberá pensar en qué construcciones va a usar
para construir su modelo. Hasta el momento nos hemos dedicado a un enfoque de arriba hacia
abajo. Esto sugiere que su primera opción deberían ser los módulos del panel Basic Process (de
Procesos básicos), seguidos por módulos de los paneles Advanced Process (de Procesos avan-
zados) y Advanced Tranfer (de Transferencia avanzada) y módulos de los paneles Blocks (Blo-
ques) y Elements (Elementos) sólo cuando se requieran. Éste es el enfoque que se recomienda
para el usuario de Arena novato, pero conforme gane experiencia y confianza en sus habilidades
de modelado, será más probable que emplee un enfoque diferente. La mayoría de los modelado-
res experimentados prefieren comenzar con los paneles Advanced Process y Advanced Transfer
y seleccionan de los otros paneles cuando es necesario. Esto les permite crear exactamente el
tipo de modelo que requieren y les da la mayor flexibilidad.
Por último, el lector está listo para abrir una nueva ventana de modelo y comenzar la cons-
trucción del mismo, lo que con probabilidad es la parte más divertida de todo el estudio. Antes
de que comience, nos gustaría ofrecerle otro consejo. Conforme se vuelva más experimentado
con el sistema de Arena, comenzará a desarrollar hábitos (algunos buenos, otros malos). Ten-
drá la tendencia a usar aquellas construcciones con las que esté más familiarizado para cada
modelo que desarrolle. Recordamos a un consultor que creó un modelo muy detallado de un
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.
13.6 Verificación y validación

Una vez que tenga trabajando su modelo, y a veces incluso mientras lo construye, es el mo-
mento de verificarlo y después validarlo. La verificación es la tarea de asegurar que el modelo
se comporta como se planeó; de forma más coloquial, esto se conoce como depuración del
modelo. La validación es la tarea de asegurar que el modelo se comporta de la misma forma que
el sistema real. Introdujimos brevemente estos temas en las secciones 2.7 y 7.1.6. Extendamos
nuestro análisis primero al considerar el tema de la verificación.
Ahora el lector tiene un modelo de simulación completo, o al menos un componente com-
pleto, y le gustaría estar seguro de que el modelo se desempeña de la forma en la que se diseñó.
Esto parece ser una tarea sencilla, pero conforme sus modelos y los sistemas que representan
se hacen más complicados, puede llegar a ser algo muy difícil. En modelos más grandes, es
posible que tenga muchas actividades ocurriendo de forma simultánea que pueden provocar
interacciones que nunca se planearon. Deberá diseñar o desarrollar pruebas que le permitan
seguir buscando las interacciones ofensivas o sólo los errores de modelado llanos y sencillos. Si
todavía no ha desarrollado una animación, le sugerimos completar esa tarea antes de comenzar
la fase de verificación. No necesita ser la animación final, pero debería tener suficiente detalle
como para permitirle ver las actividades que ocurren dentro del sistema. Podría comenzar re-
visando lo obvio.
Considere el sistema que modelamos en el capítulo 7, que producía tres partes diferentes.
Altere su modelo de manera que sólo cree un caso sencillo del Part Type 1 y observe el flujo
solitario de las partes a través del sistema. Repita esto para los otros dos tipos de partes. Cam-
bie todos los tiempos de su modelo a valores constantes y libere un número limitado de partes
dentro del sistema. Los resultados deberían ser predecibles. Pruebe el otro extremo al disminuir
la tasa de entre llegadas de las partes y observe lo que sucede conforme se sobrecarga el sistema.
Cambie la mezcla de las partes, los tiempos de proceso, las tasas de falla, etc. Lo que usted está
intentando hacer es crear una amplia variedad de situaciones diferentes en donde la lógica de su
modelo sólo debería fallar. Por supuesto, si encuentra problemas, corríjalos. Tendrá que decidir
si debe repetir algunas de las pruebas anteriores.
Una vez que haya completado las pruebas obvias, debería intentar retroceder y visualizar
qué tipos de escenarios tendría que considerar en su análisis. Duplique tales escenarios proyec-
tados de la mejor forma posible y vea si su modelo todavía se desempeña de forma adecuada. Si
tiene periodos en los que no usa su computadora, predetermine el tiempo de réplica y permita
que la simulación se ejecute por amplios periodos de tiempo. Este tipo de experimento debería
desempeñarse mejor durante la noche. Revise con cuidado los resultados de estas ejecuciones,
buscando grandes colas, recursos no utilizados, etc. Básicamente, hágase la siguiente pregunta:
¿tienen sentido los resultados? Si dispone de amplios periodos de tiempo en los que está en su
escritorio, pero sin usar su computadora, permita que el modelo se ejecute con la animación ac-
tiva. Cuanto lo permita el tiempo, eche un vistazo a su monitor y vea si todo parece estar bien.
Si confía en que su modelo funciona de forma correcta, está listo para la prueba de fuego.
Vuelva a convocar al grupo de clientes y muéstreles su simulación. En la mayoría de los ca-
sos, esto significa animación. Si hay problemas, probablemente es aquí en donde se detectarán.
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
El primer conjunto de ejecuciones produjo resultados que desconcertaron por completo a

los clientes. Había cuellos de botella en el modelo que no ocurrían en el sistema real y cuellos
de botella en el sistema real que no se mostraban en los resultados del modelo. De hecho, una
comparación detallada de las estadísticas de utilización de los recursos del modelo con los re-
gistros históricos mostró que había diferencias importantes. Este problema se resolvió bastante
rápido cuando se hizo evidente que los tiempos de proceso mantenidos en las bases de datos de
la instalación se basaban en los tiempos estándares usados para los costos. De ninguna manera
representaban los tiempos de proceso reales observados en la planta. Esté consciente de que se
trata de un problema bastante común. Con frecuencia los datos se mantienen por conveniencia
del contador, no del ingeniero de sistemas. Por suerte, alguien había desarrollado un conjunto
de tablas de conversión que trasladaban los tiempos estándares a tiempos de procesos precisos.
Estas tablas se incluyeron en el modelo y el proceso de validación continuó.
Todo parecía ir bien hasta que se realizó una ejecución de simulación para un año completo
y los resultados se compararon con los registros históricos. Once de los doce meses produjeron
resultados casi idénticos. Sin embargo, hubo un mes cerca de la mitad del año simulado en
donde los registros indicaban que el resultado era aproximadamente 40% mayor que lo pre-
dicho por el modelo de simulación. Se invirtió mucho tiempo intentando averiguar qué había
ocasionado esta discrepancia. Se supuso que había un problema con el modelo de simulación
(¡equivocación!). Por último, el grupo de análisis comenzó a sospechar que quizá los datos
históricos eran defectuosos. Al observar las estadísticas detalladas del mes en cuestión, se hizo
evidente que las estadísticas de los recursos provenientes de la simulación concordaban muy de
cerca con aquéllas reportadas. De hecho, se determinó rápidamente que la única diferencia era
el número total de transmisiones producidas. Además, todos se encontraban convencidos de
que el sistema no tenía la capacidad para producir tantas unidades. La investigación detectives-
ca tomó varias semanas de medio tiempo antes de que surgiera la respuesta.
Por fin alguien se dio cuenta de que el mes en cuestión era el último del año fiscal de la
empresa. Como resultó, había una pequeña cantidad de producto que se rechazaba por varias
razones durante los primeros 11 meses del año. Estos productos simplemente se dejaban a un
lado hasta el mes final, cuando de repente se convertían en aceptables y se reportaban como
parte de la producción de ese mes. El razonamiento era que mejoraba el desempeño del sistema
durante el año. Semanas después estos productos se rechazaban formalmente, pero los registros
de años anteriores nunca se ajustaban. Quitar estos artículos rechazados del rendimiento men-
sual permitió por fin que el modelo se validara.
Si no existen registros precisos del sistema real, entonces puede ser imposible validar el
modelo. En ese caso, concéntrese en la verificación y use el mejor juicio de los individuos que
se encuentran más familiarizados con la capacidad del sistema. A veces los individuos del piso
de producción tienen una extraña habilidad de predecir con precisión el desempeño del nuevo
sistema. Recuerde, la clave para ambos, analista y cliente, es tener confianza en los resultados
del modelo.
Si ha llegado hasta aquí con su proyecto de simulación, ha aclarado la mayoría de los prin-
cipales obstáculos. Ahora está listo para usar el modelo y responder algunas preguntas.
13.7 Experimentación y análisis

Ya hemos cubierto la mayor parte, si no es que todos, los temas estadísticos asociados al análisis
de simulación y no repetiremos ese material aquí. Sin embargo, existen varias implicaciones
prácticas de las que nos gustaría estuviera consciente. Idealmente, antes de comenzar cual-
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.
13.8 Presentación y conservación de resultados

Cuando llegue a esta etapa, habrá completado por lo menos el estudio inicial y estará listo para
seguir adelante con sus resultados. En muchos casos, sólo se requiere o espera un reporte por
escrito. En otros, tendrá que presentarse frente a un grupo de tomadores de decisiones y les
expondrá una presentación formal o informal de sus resultados. Ésta puede ser de hecho la fase
más importante del proyecto, porque puede determinar si sus resultados son aceptados. No nos
adentraremos mucho en los detalles sobre cómo escribir o exponer un reporte. Si siente que le
faltan dichas habilidades, le sugerimos encontrar un libro dedicado a estos temas o tomar un
curso formal para agudizarlas. Verá que necesitará estos tipos de habilidades en muchas otras
áreas también. Sin embargo, hay algunos puntos obvios que tiene que tomar en cuenta.
Primero, asegúrese de que está planteando las preguntas correctas y de que proporciona
respuestas concisas. Siempre incluya el equivalente a un resumen ejecutivo que señale sus reco-
mendaciones de forma clara, y las principales razones para ellas, en una página (o diapositiva)
o menos. Si es posible, intente evitar la presentación de números en términos absolutos; use
rangos o intervalos de confianza. Entienda a su audiencia antes de seguir adelante. Si cuenta
con volúmenes de material para respaldar sus recomendaciones, póngalos en un apéndice o
manténgalos en reserva (para usarlos sólo si se los solicitan). No se sienta tentado a responder
preguntas acerca de las características del sistema que no estén incluidas en su modelo. Por últi-
mo, prepárese para recibir instrucciones de retroceder y buscar alternativas adicionales.
La conservación de los resultados tendría que ser una tarea continua durante toda la du-
ración del proyecto. Normalmente, llamaríamos a esto el proceso de documentación. Debería
incluir no sólo las recomendaciones finales, sino también la documentación del modelo y los
detalles del análisis. Es cierto que la mayoría de los proyectos de simulación no se vuelven
a visitar. Pero hay sus excepciones y es común tener que desempolvar un modelo viejo años
después para llevar a cabo más análisis. Sabemos de un modelo de simulación desarrollado en
1983, como un modelo SIMAN, que todavía se usa de forma periódica, aun cuando el modelo
es básicamente el mismo.
La mayoría de los profesionales coinciden en que existe una ley de la naturaleza, o quizá
incluso un teorema, acerca de la documentación. Cuanta más documentación posea sobre un
proyecto, menor será la probabilidad de tener que usar el modelo otra vez. Siempre parecen ser
esos proyectos fallidos que no dejan tiempo para la documentación los que se le pide que resu-
cite años más tarde. Sin embargo, si siguió nuestro consejo de este capítulo la mayor parte de su
documentación ya está disponible y en forma electrónica. Si almacena toda esta información
(el modelo de simulación, especificación, reporte y presentación) en la misma carpeta, habrá
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á.
13.9 Difusión del modelo

Durante el curso de un estudio de simulación, ciertamente compartirá su modelo de simulación
y animación con su cliente. Si los clientes tienen una copia de Arena, sólo tendrá que enviarles
el archivo del modelo más reciente (.doe) y ellos podrán ver y alterar su modelo en cualquier
momento. Si los clientes (o alguien más) no tienen el software, obviamente esto no funcionará.
Arena tiene un modo de tiempo de ejecución que permite al usuario abrir, ejecutar y ver la
animación y los resultados de cualquier modelo. Posibilita que el usuario edite cualquier dato
existente y guarde de nuevo el modelo, pero sin añadir o alterar cualquier lógica o módulo de
datos. Si se requiere la versión de tiempo de ejecución, debería contactar a Rockwell Automa-
tion para obtener mayor información.
APÉNDICE A
Una especificación funcional para

The Washington Post
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.
A.1.1 Organización del documento

Se proporciona este documento para describir las operaciones del departamento de correspon-
dencia en The Washington Post de Springfield, Va., y proponer unas instalaciones en Maryland.
La descripción incluirá el detalle necesario para desarrollar un modelo de simulación de Arena
con bastante precisión de ambas operaciones.
Este documento se divide en seis secciones. La primera define los objetivos del proyecto de
simulación, el propósito de este documento, el uso del modelo de Arena y el software y hard-
ware requeridos para ejecutar tal modelo. La segunda sección describe los componentes físicos
de la operación del departamento de correspondencia, así como los enfoques de modelado
para cada componente. La tercera sección describe la animación del modelo de simulación. La
cuarta resume los requisitos de las entradas del usuario para el modelo de Arena y el resultado
deseado generado por aquél. La quinta sección describe las formas de entrega del proyecto. Por
último, la sexta sección contiene las firmas del acuerdo y de la aceptación que se requieren para
proceder con el proyecto.
A.1.2 Objetivos de la simulación

El objetivo del estudio de simulación es proporcionar a The Washington Post una herramienta
de apoyo para la toma de decisiones que le ayudará al momento de evaluar la operación de
carga de los camiones de la planta de Springfield, así como de la instalación propuesta en Ma-
ryland. La simulación asistirá en la evaluación del impacto de los resultados de las rotativas,
el uso de las bandejas, la tasa de viajes de éstas y los patrones de llegada de los camiones en las
operaciones de carga.
Con la finalidad de obtener los objetivos de la simulación, se desarrollarán dos modelos de
simulación bajo este contrato. Éstos incorporarán datos operacionales reales e información
recopilada de las instalaciones de Springfield y Maryland. La simulación usará secuencias de
producción reales y la lógica de decisión que se requiere para representar las operaciones de la
instalación de forma adecuada. Además, la simulación incorporará la información y los resul-
554 Apéndice A
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.1.3 Propósito de la especificación funcional

La especificación funcional sirve a cuatro propósitos. Primero, y más importante, este docu-
mento describe la operación del departamento de correspondencia en las instalaciones del pe-
riódico en Springfield y Maryland, en el nivel de detalle que se requiere para los propósitos de
modelado. La descripción incluye flujos de procesos, funcionalidad de los equipos, procedi-
mientos y reglas de la operación, interacciones del sistema y temas logísticos. Estos sistemas
deben ser entendidos por completo antes de que puedan representarse en una simulación por
computadora.
Segundo, se definen las entradas requeridas por el usuario para llevar a cabo el análisis de
simulación, las cuales incluyen aspectos tales como el comportamiento de las rotativas, ubica-
ciones de los puertos, tiempo de carga de los camiones y otras características operativas.
Tercero, se definen los resultados generados en la simulación por computadora. Por lo gene-
ral los resultados aparecen en forma de medidas de desempeño del sistema desde las que se lleva
a cabo el análisis de simulación. Estas estadísticas de salida incluyen aspectos tales como uso de
los puertos, tiempos de carga de los camiones, uso de las bandejas, etcétera.
Por último, se describen las formas de entrega del proyecto. Estas formas de entrega se
hallarán contenidas en una carpeta de tres anillas e incluirán los discos de computadora que
contienen el modelo de Arena, los archivos de datos de las entradas, copias de los archivos de
datos, un manual del usuario que describa cómo usar el software y el reporte final.
Este documento define de forma explícita los temas que son parte de la cotización y de otros
documentos no oficiales intercambiados entre SM y The Washington Post. Por lo tanto, para
aquellos temas que se analicen en otros documentos, éste sustituye a toda la correspondencia en la
definición del proyecto.
A.1.4 Uso del modelo

El uso del modelo de simulación se detallará por completo en el manual del usuario propor-
cionado al término del proyecto. El uso del modelo incluye la iniciación del modelo de Arena
y los archivos de entrada con los parámetros deseados, su ejecución en la computadora y la
generación de los resúmenes de las estadísticas y reportes. Se pueden comparar los reportes de
los resúmenes de varias ejecuciones para evaluar el impacto de los parámetros específicos en el
desempeño del sistema.
Una especificación funcional para The Washington Post 555
A.1.5 Requerimientos de hardware y software

SM desarrollará un modelo de simulación de Arena bajo el ambiente del sistema operativo
de Microsoft® Windows®. Los software y hardware que se requieren para ejecutar el modelo
incluyen:
< Edición estándar de Arena 1.25 o mayor.
< Computadora Personal de IBM 486, compatible o mayor.
< Windows 3.1 o 3.11.
< 8 MB en RAM (recomendados 16 MB).
< 30 MB de espacio en disco duro.
El software mencionado no fue incluido con este proyecto, pero se puede adquirir bajo un
contrato por separado.
A.2 Descripción del sistema y enfoque de modelado

Las siguientes secciones definen el flujo de los periódicos desde las rotativas a través del depar-
tamento de correspondencia hasta los puertos de carga. Se describirán los diversos componen-
tes del sistema para las instalaciones de Springfield y Maryland ya que las dos plantas tienen
diferentes distribuciones y modos de operar. Cualquier diferencia operativa se tratará con el
detalle necesario para este trabajo de modelado. En general, la lógica definida será similar para
ambas instalaciones.
El modelo incluirá la producción de encabezados (o primera plana), movimientos del pro-
ducto de encabezados a través del sistema de bandejas a los puertos y la colocación en las
tarimas (o paletas) y la carga de los atados de diarios a los camiones en los puertos. También
incluirá la carga de los productos de avanzada previamente elaborados sobre los camiones en
los puertos.
A.2.1 Cronología del modelo

El modelo podrá simular las actividades del departamento de correspondencia que van desde
un día hasta una semana completa.
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
Tabla A-1. Resultados de las rotativas de ejecución tardía generados

por la simulación de AGV (Rotativa 1)
Secuencia de la En función/Sin Tiempo Velocidad de la rota- Aumento Velocidad de aumento

rotativa 1 funcionar (minutos) tiva (copias/hora) (copias) (copias/hora)
1 En función 30 70 000 5 000 56 000
2 Sin funcionar 5 0 0 0
3 En función 45 70 000 5 000 56 000
4 Sin funcionar 10 0 0 0
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.1 Programa de resultado de las rotativas de la simulación de AGV

Los programas de resultado de las rotativas de ejecución tardía generados por el modelo de
simulación de AGV se importarán hacia el modelo del departamento de correspondencia como
archivos ASCII. Para cada rotativa, estos archivos consistirán en secuencias de tiempos de fun-
cionamiento, tiempos sin funcionar y velocidades. Un ejemplo de un programa de resultado de
rotativa de ejecución tardía generado por la simulación de AGV se presenta en la tabla A-1.
A.2.2.2 Programa de rotativa definido por el usuario

Los parámetros de las rotativas definidos por el usuario se leerán dentro del modelo de simula-
ción desde un archivo ASCII e incluirán, para cada rotativa: 1) tamaño del pedido de trabajo
total, 2) velocidades de las rotativas, 3) contadores de aumento y 4) velocidades de aumento.
En la tabla A-2 se proporciona un ejemplo de parámetros de una rotativa definidos por
el usuario.
Además del tiempo sin funcionar del relaminado, cada rotativa también experimenta tiem-
pos sin funcionar aleatorios. Este tiempo sin funcionar es causado ya sea por 1) un rollo de pa-
pel en mal estado o 2) cortes en la red del papel periódico. Para cada tipo de falla, la frecuencia
de ocurrencia se basará en el contador de titulares, mientras que el tiempo para la distribución
de reparación se expresará en minutos.
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-2. Programa de resultados de las rotativas definido por el usuario
Número de Pedido de trabajo Velocidad de la rotativa Aumento (copias) Velocidad de aumento

rotativa (copias) (copias/hora) (copias/hora)
1 120 000 70 000 5 000 56 000
2 120 000 65 000 3 000 49 000
3 120 000 55 000 5 000 49 000
4 120 000 70 000 5 000 56 000
Tabla A-3. Tiempo sin funcionar inducido por el relaminado y definido por el usuario
Relaminado Ocurrencia del relaminado Tiempo sin funcionar de relaminado

(minutos) (minutos)
1o. 1:15 a 1:30 7 a 10
2o. 2:15 a 2:30 10 a 15
3o. 2:45 a 3:00 7 a 10
4o. : :
en el tiempo. En la tabla A-3 se da un ejemplo del programa de relaminado. En este ejemplo, se

supone que las rotativas se encienden entre 12:15 a.m. y 12:30 a.m. y se apagan entre 4:30 a.m.
y 4:40 a.m. Para los propósitos de esta simulación, se supondrá que puede haber hasta diez
relaminados en una ejecución dada.
La mayor parte del tiempo, el relaminado debería inducir la siguiente secuencia: rotativas
1 y 2 bajan, rotativa 1 retrocede, rotativa 3 baja, rotativa 2 retrocede, rotativa 4 baja, rotativa 3
retrocede y rotativa 4 retrocede.
A.2.3 Tipos de producto

Las rotativas generan dos tipos de producto: avance y encabezados. El producto de avance es la
parte del periódico que no es sensible al tiempo y puede por ende producirse más temprano en
el día. El encabezado (o primera plana) por lo general son las primeras secciones del periódico
que contienen noticias sensibles al tiempo. Para los propósitos de esta simulación, se supondrá
que todo el producto de avance necesario para un día dado se encuentra disponible cuando se
necesita para cargar los camiones de reparto. Sólo la producción de encabezados se modelará
de forma explícita.
A.2.4 Líneas de empaque de las rotativas

Cada rotativa alimenta tres líneas de empaque y cada línea de empaque de las rotativas se co-
necta con el sistema de bandejas. La producción de las rotativas se puede regular a través de
cada una de sus tres líneas de empaque. Estas líneas introducen encabezados y producen atados
de diarios. Una línea de empaque de una rotativa tiene tres modos operativos: 1) de respaldo, 2)
regular y 3) inserción manual. En el modo de respaldo, la línea de empaque de la rotativa está
desocupada y no produce ningún atado de diarios. En el modo regular, un porcentaje definido
por el usuario de producción de la rotativa se introduce en la línea y se transforma mecánica-
mente en atados de diarios. El tamaño de los atados de diarios será definido por el usuario. En
el modo de inserción manual la línea funciona según el modo regular, excepto que los atados
de diarios son revisados a mano para satisfacer requerimientos adicionales del producto. Tales
requerimientos incluyen la combinación de productos de avance con encabezados. El proceso
de inserción manual se describirá en A.2.9.
A.2.5 Sistema de bandejas

Los atados de diarios que entran al sistema de bandejas desde las líneas de empaque de las ro-
tativas no tienen un destino predefinido. En el punto de determinación del sistema de bandejas,
558 Apéndice A
Tabla A-4. Programa de llegada de los camiones
Número Cubo Identificación del Cantidad de tirada Tipo de camión

camión
1 1 0906 12 294 2
2 1 0907 5 050 3
: : : : :
n 8 9451 650 1
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.
A.2.5.1 Sistema de bandejas de Springfield, Va.

El sistema de bandejas de Springfield consiste en dos transportadores de bandejas idénticos que
conducen atados de diarios desde las rotativas y apiladoras hasta los puertos y entarimadores
de carga. Los dos transportadores de bandejas se diferencian e identifican por su color, verde o
amarillo. La producción de cada rotativa se dedica a uno o dos transportadores, con la produc-
ción de las rotativas 1 y 3 enviadas al transportador verde y la producción de las rotativas 2 y 4
enviadas al transportador de bandejas amarillo. El transportador de bandejas verde cuenta con
exactamente 263 bandejas, mientras que el amarillo tiene exactamente 266 bandejas. Ambos
transportadores se mueven a una velocidad de 150 bandejas/minuto y pueden entregar atados
de diarios a cualquiera de los puertos de atados de diarios o a cualquier entarimador. La tasa
de viajes de las bandejas determina qué tan frecuentemente se puede desviar un producto a
una ubicación determinada. En el punto de determinación del sistema de bandejas, el atado de
diarios analizará el camión con la más alta prioridad que se encuentre en ese momento en el
puerto. Si no se excede la tasa de viajes, el atado de diarios será desviado a esa ubicación. Si se
excediera la tasa de viajes, el atado de diarios analizará los camiones con prioridades cada vez
menores hasta que encuentre un destino válido. Si el atado de diarios no puede encontrar un
destino válido, vuelve a circular en el transportador de bandejas. La velocidad del transporta-
dor y su tasa de viajes son definidas por el usuario.
A.2.5.2 Sistema de bandejas de Maryland

El sistema de bandejas en la instalación de Maryland funcionará de forma similar. Sin embar-
go, puesto que la instalación de Maryland es historia, sólo hay un transportador en el sistema
de bandejas. Además, cada una de las líneas de empaque se encuentra conectada directamente
a uno de los cuatro puertos. Esto permite que los atados de diarios sean enviados directamente
a un puerto, evitando el sistema de bandejas. Una línea de empaque sólo desviará un atado de
diarios al sistema de bandejas si no hay camiones listos para cargar en ninguno de los puertos.
El periódico debe definir el diseño físico del transportador y el número exacto de bandejas en el
transportador antes de que se construya el modelo. La velocidad del transportador y la tasa de
viaje son definidas por el usuario.
* 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.
A.2.6 Llegadas de los camiones

Las llegadas de los camiones se controlan desde un archivo de programa definido por el usuario
(tabla A-4). Cada camión tiene una única identificación, un periodo de rendimiento, una canti-
dad de tirada y un tipo. El periodo de rendimiento determina el segmento de tiempo en el que
llega el camión. La cantidad de tirada es el número de copias a cargar en ese camión. El tipo de
camión se refiere a la clase de servicio que realiza, que puede ser ya sea de autopista, de entrega
a domicilio o de puesto de periódicos.
Los camiones llegan en el modelo en un periodo de rendimiento (n − 1) para empezar con la
carga del producto de avance en un puerto de avance. Cuando este producto de avance se ha car-
gado completamente, el camión puede moverse a un puerto de envío en donde recibirá los encabe-
zados necesarios para terminar. Los camiones se atienden según su tiempo de llegada al puerto.
A.2.6.1 Entrega a domicilio

Los camiones de entrega a domicilio (home delivery, HD, por sus siglas en inglés) reciben el
producto en uno de los puertos dedicados al avance. Las tarimas de productos de avance se
desmontan y transportan en atados de diarios en un transportador dedicado al camión. La tasa
de carga en atados de diarios por minuto y el tiempo de configuración del puerto en minutos los
define el usuario. Después de recibir todo el producto de avance, el camión HD puede dirigirse
a los puertos de envío regulares en donde se carga con la misma cantidad de producto de enca-
bezado. Los atados de diarios de encabezados llegan mediante el sistema de bandejas. La tasa
de carga en atados de diarios por minuto y el tiempo de configuración del puerto en minutos
los define el usuario. Un porcentaje de camiones HD definidos por el usuario se estiman como
“lentos” y como tal tienen un tiempo de carga y de configuración más largos.
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.6.3 Puesto de periódicos/ventas en la calle

Los camiones para puestos de periódicos o ventas en las calles (NS/SS, por sus siglas en inglés)
no reciben productos de avance. En su lugar, después de su llegada al puerto de envío, los atados
de diarios se generan a partir del proceso de inserción manual. Estos atados de diarios viajan a
través del sistema de bandejas hasta el camión NS/SS. Los tiempos de carga y de envoltura son
similares a los de los camiones HD.
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.7.1 Puertos de Springfield, Va.

La instalación propuesta de Springfield cuenta con exactamente 12 puertos dedicados a tari-
mas, 10 puertos de atados de diarios de avance y 14 puertos de atados de diarios dedicados a
encabezados.
A.2.7.2 Puertos de Maryland

La instalación propuesta de Maryland tiene exactamente 10 puertos de combinaciones de ata-
dos de diarios de avance y de tarima y 18 puertos dedicados de atados de diarios de encabe-
zados.
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.
A.2.8.1 Entarimadores de Springfield, Va.

La instalación de Springfield contiene cinco entarimadores, localizados en el primer piso.
A.2.8.2 Entarimadores de Maryland

La instalación propuesta de Maryland contiene cuatro entarimadores.
A.2.9 Proceso de inserción manual

La inserción manual comienza cuando llega el primer camión NS/SS a un puerto y continúa
hasta que son atendidos todos los camiones de este tipo. Cuando las líneas de empaque de las
rotativas cambian al modo de inserción manual, se asigna a quienes van a insertar a mano de
entre un grupo de trabajadores para ensamblar atados de diarios de producto de avance y en-
cabezados. Estos atados de diarios, llamados atados de diarios NS/SS, se envían a los camiones
NS/SS. Cada línea de empaque es provista de personal con un máximo de 25 trabajadores.
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.
A.4 Resumen de entradas y salidas
A.4.1 Entrada del modelo

Los temas de datos que se leen en el modelo de simulación de los archivos ASCII incluyen pero
no se limitan a:
Rotativas
< Tasa de producción.
< Programa de producción (1 día o 1 semana).
< MTBF, MTTR.
Nota: Puede emplearse el resultado del programa de producción de la simulación de AGV
Roll Delivery en lugar de estas entradas.
Línea de empaque de las rotativas
< Patrones de activación de línea (modos, fases).
< Sistema de bandejas.
< Velocidad.
< Tasa de viaje (puertos).
< Tasa de viaje (entarimadores).
Entarimadores
< Tasa de producción.
< Atados de diarios por tarima.
< MTBF, MTTR.
Atados de diarios
< Copias por atado de diarios (avance).
< Copias por atado de diarios (encabezados).
< Copias por atado de diarios (inserción a mano).
Tiempo de proceso
< Tasas de carga de camión.
w Encabezado-HD (regular).
w Encabezado-HD (lento).
w Avance-HD.
w HWY (última tarima).
w HWY (otros entarimadores).

< Tiempos de cambio de puerto.

w Encabezado-HD (regular).
w Encabezado-HD (lento).
w Avance-HD.
w HWY.
Programa de los camiones (para cada camión)

< Periodo de rendimiento.
< Identificación del camión.
< Cantidad de tirada.
< Tipo de camión.
Inserción a mano
< Quienes insertan a mano por línea.
< Tasa de servicio de quien inserta a mano.
A.4.2 Resultados del modelo

Las siguientes medidas de desempeño se escribirán en uno o más archivos de datos ASCII en la
conclusión de la ejecución de simulación. Dichas estadísticas se recopilarán y producirán diaria
o semanalmente.
Parámetros de entrada
< Tiempos de proceso.
< Niveles de equipamiento y recurso.
< Tasas de falla.
Actividad de las rotativas (para cada rotativa)
< Tiempo disponible (arriba).
< Producción total.
< Tasa promedio de producción.
< Historial de averías.
Actividad de inserción manual (para cada línea)
< Producción total.
< Tasa promedio de producción.
< Atados de diarios de encabezados apilados hacia abajo.
Actividad de las bandejas
< Utilización (verde y amarillo).
Atados de diarios
< Estadísticas de destino.
Estadísticas de envío
< Camiones puntuales.
< Camiones retrasados.
< Tiempo para completar el porcentaje de los camiones.
564 Apéndice A
Carga de periodo de rendimiento (por periodo)

< Total de unidades cargadas (real).
< Total de unidades cargadas (programadas).
Estadísticas de los puertos (por puerto)
< Uso de los puertos.
< Total de unidades cargadas.
< Uso por periodo de rendimiento.
Estadísticas del camión (por camión)
< Puerto usado.
< Tiempo de carga de avance.
< Tiempo de espera.
< Tiempo desocupado.
< Tiempo de carga.
< Tiempo de cambio.
< Resumen para cada tipo de camión.
A.5 Entregables del proyecto

En las siguientes secciones se analizan las entregas del proyecto. Una vez terminado el proyecto,
se suministrará a The Washington Post todos los archivos de computadora que se desarrollen
bajo el contrato. El modelo de simulación y todos los archivos de datos de soporte son de pro-
piedad única y exclusiva del comprador. Esto no incluye ningún software de Arena, a menos
que esté específicamente señalado y que se tenga previsto un presupuesto. SM guardará copias
de respaldo para mantenimiento y registro en el caso en que The Washington Post desee cam-
bios al modelo en el futuro.
A.5.1 Documentación del modelo de simulación

La documentación del modelo será un proceso continuo durante todo el desarrollo del modelo.
Esta documentación se hallará contenida dentro del modelo de Arena e incluirá comentarios
detallados que describan todas las secciones importantes de la lógica del modelo. También se
incluirá un listado completo de las variables que contenga las descripciones de todas las varia-
bles, atributos de las entidades, estaciones, colas, etc., que se emplearon en el modelo.
A.5.2 Manual del usuario

El manual del usuario incluirá todos aquellos temas de los cuales SM sea responsable. Este
manual sólo contendrá información que sea específica a este proyecto. El usuario será remitido
a la Guía de Arena para temas que sean específicos de tal software. Los contenidos del manual
del usuario serán:
1. La especificación funcional.
2. Una copia del archivo del modelo en un disco.
3. Una copia de todos los archivos de los datos de entrada en un disco.
4. Las instrucciones de cómo usar el modelo.
A.5.3 Validación del modelo

La validación es el proceso de establecer que el modelo representa de forma precisa el sistema
real. Los datos de desempeño reales requeridos como entradas para el modelo de simulación
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.
Modelo de simulación del departamento de correspondencia de The Washington Post.

Especificación funcional suministrada por:
______________________________
Scott A. Miller, Gerente del proyecto
Servicios de simulación y consultoría
Systems Modeling Corporation
Acordado y aceptado por:
___________________________________
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
IIE/RA Problemas de concurso
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
Una actualización en probabilidad

y estadística
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.
C.1 Fundamentos de probabilidad

Un experimento es cualquier actividad que se puede llevar a cabo cuyo resultado exacto es in-
cierto (hasta que se hace y se ve lo que sucede). Aunque el término puede evocar las imágenes
de un laboratorio de química en la escuela, su interpretación en probabilidad es mucho más
amplia. Por ejemplo:
< Lance una moneda. ¿Caerá en cruz?
< Lance un dado. ¿Caerá en 4? ¿Será un número impar? ¿Será un número mayor a 2 pero
menor a 5?
< Mañana conduzca al trabajo. ¿Cuánto tiempo le tomará? ¿Cuánto se retrasará debido a
las obras? ¿Lo golpeará un asteroide?
< Opere un centro de atención telefónica durante una semana. ¿Cuántas llamadas mane-
jará? ¿Cuál será la duración promedio que sus clientes esperan en la línea? ¿A cuántos
clientes rechazará debido a que las colas de espera están llenas?
570 Apéndice C
< 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
Figura C-1. Unión, intersección y complemento
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
< P(E ∪ F) = P(E) + P(F) – P(E ∙ F).

< Si E y F son mutuamente excluyentes (E ∙ F = ∅), entonces P(E ∪ F) = P(E) + P(F).
< Si E es un subconjunto de F (esto es, el evento E implica el evento F), entonces P(E) ≤
P(F).
< Si o1, o2, o3,... son resultados individuales en el espacio (finito o infinito) de la muestra,
entonces Ŷ P( oi ) â1.
todas i
A veces, saber que un evento aconteció puede alterar la probabilidad de que otro evento
también ocurra. La probabilidad condicional de E dado F se define como
P (E | F ) â P∙
P(E∙F)=P(E Ƙ F ) / P( F )
( EF)/P(F)
(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 Variables aleatorias

Los eventos se pueden definir de muchas maneras y pueden ser muy complejos. Una forma
de cuantificar y simplificar los eventos es definir las variables aleatorias relativas a ellos. En
esta sección analizaremos las ideas básicas de las variables aleatorias, sus dos formas básicas
(discretas y continuas) y después consideraremos las variables aleatorias múltiples definidas
conjuntamente y sus posibles relaciones.
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
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.
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.
C.2.4 Distribuciones conjuntas, covariancia, correlación e independencia

Hasta ahora hemos considerado las variables aleatorias de una a la vez. Pero a veces aparecen
en secuencias ordenadas dobles, triples y aun más largas (que tienen el maravilloso nombre de
tuplas), a las que se llama variables aleatorias distribuidas de forma conjunta o vectores aleato-
rios. Por ejemplo, en el modelado de entrada de una simulación para un taller de producción,
un pedido que llega puede tener variables aleatorias que representen el tipo de parte (dictando
su ruta a través del taller), la prioridad y los tiempos de proceso en los pasos junto con su ruta.
576 Apéndice C
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
y la CDF marginal de X1, es, para todos los valores reales de x,
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
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
Las variables aleatorias X1 y X2 se llaman independientes si su CDF conjunto siempre se

factoriza dentro del producto de sus CDF marginales:
De forma equivalente, la independencia se puede definir en términos de factorización similar

de la PMF conjunta dentro del producto de los PMF marginales, o la factorización de la PDF
conjunta dentro del producto de los PDF marginales. Aquí hay algunas propiedades de las
variables aleatorias independientes X1 y X2:
< Parafraseando, independencia significa que saber el valor que golpea X1 no dice nada
acerca de dónde puede haber caído X2.
< Si dos variables aleatorias son independientes, entonces tampoco estarán correlaciona-
das. Lo contrario, sin embargo, por lo general no es cierto (a menos que las variables
aleatorias tengan una distribución normal conjunta). La verdad es que los contraejem-
plos son patológicos, pero ahí están.
< Para las variables aleatorias independientes, E(X1, X2) = E(X1) E(X2).
< La independencia de las variables aleatorias es un acuerdo bastante grande en proba-
bilidad y estadística ya que, lo crea o no, la propiedad de factorización en la definición
anterior presenta un montón de posibles derivaciones en donde de otra forma podrían
ser totalmente imposibles.
< Quizá debido a que la independencia es tan importante analíticamente, es demasiado
tentador sólo suponerla cuando no se está del todo seguro de si se encuentra justificada.5
Todo lo que podemos hacer es alertar al lector ante el hecho de que dicha suposición está
ahí y que violarla por lo general tiene ramificaciones desconocidas.
En el caso de más de dos variables aleatorias en el vector aleatorio, la independencia signifi-
ca que la CDF conjunta (o PMF o PDF) factoriza dentro del producto de una única contrapar-
te marginal; esto implica independencia entre parejas, pero no necesariamente la independencia
de todas las variables aleatorias.
Los temas de correlación e independencia de las variables aleatorias surgen en por lo menos
un par de lugares en la simulación. Del lado de las entradas, por lo general modelamos varias
cantidades aleatorias que dirigen la simulación como si fuera independiente y simplemente las
generamos en concordancia. Pero hay veces en que debiera estar presente un tipo de dependen-
cia que necesitamos captar por el bien de la validez del modelo; en la sección 4.6.7 se analiza
esto brevemente y se dan algunas referencias. Del lado de las salidas, una ejecución de una
simulación en el tiempo por lo general produce una secuencia de variables de salida aleatorias
que pueden estar correlacionadas, quizá mucho, entre ellas. Esto complica el análisis estadístico
apropiado de tales datos y se debe tener cuidado para diseñar las ejecuciones y usar los resulta-
dos adecuadamente; la sección 7.2 trata algunos problemas y remedios particulares.
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.
C.3 Muestreo y distribuciones de muestreo

El principal propósito del análisis estadístico es estimar o inferir algo concerniente a una gran
población, que se supone es demasiado grande para analizarse por completo, haciendo algunos
cálculos con una muestra sacada de ella. Algunas veces es más conveniente pensar en el mues-
treo de un proceso en curso en lugar de una población estática. La base matemática para esto
es que hay una variable aleatoria (o quizá un vector aleatorio) con alguna distribución, que
gobierna el comportamiento de la población; en este sentido, puede pensarse en la población
como la variable aleatoria y su distribución, y una muestra es sólo una secuencia de observa-
ciones (o realizaciones) distribuidas de forma independiente e idéntica (IID, por sus siglas en
inglés) en esta variable aleatoria. Cualquiera que sea el caso, no se conocen los parámetros de
la población o la distribución que la rige y hay que tomar una muestra para hacer estimados de
cantidades o probar hipótesis.
Ha habido muchas teorías estadísticas elaboradas para esto (sólo describiremos unas cuan-
tas pertinentes a los ejemplos de simulación del libro e indicaremos al lector las referencias
mencionadas al inicio del presente apéndice). Esta teoría estadística supone que la muestra ha
sido tomada de forma aleatoria, esto es, de tal forma que cada posible muestra de cualquier
tamaño que tome tenga la misma probabilidad de ser la muestra realmente elegida. El vínculo
entre muestrear para inferencia estadística y la teoría de probabilidad analizada hasta ahora
en este apéndice es que “el experimento”, al que nos referimos antes, es en este caso el acto de
tomar una muestra aleatoria. El resultado es un conjunto particular de datos (uno de muchos
posibles) del que se calculan varias cantidades, que claramente dependen de la muestra de la
que se obtuvieron.
En simulación, el muestreo se reduce a hacer algunas ejecuciones de su modelo, ya que la
entrada aleatoria conlleva un resultado aleatorio. Suponiendo que el generador de números
aleatorios opera de forma adecuada y se usa de forma correcta, está garantizada la aleatorie-
dad de la muestra; esto contrasta con experimentos físicos o de laboratorio en donde a menudo
se sufren muchas penalidades para asegurar que la muestra obtenida en verdad es realmente
aleatoria.
Sea X1, X2,. . ., Xn una muestra aleatoria observada de alguna población. De forma equi-
valente, estos datos son observaciones IID de alguna variable aleatoria subyacente X cuya dis-
tribución rige la población. En simulación, esto surge del lado de las entradas en donde los
datos son observaciones del sistema real al que se ajustará alguna distribución para que sirva
como una entrada para la simulación (como en la sección 4.6). También surge del lado de los
resultados en donde los puntos de los datos son estadísticas de resumen entre n réplicas IID de
la ejecución de simulación (como en las secciones 6.2 a 6.6 y 7.2.2), o son quizá medias de lotes
desde el interior de una única ejecución larga de simulación de estado constante (como en la
sección 7.2.3). Sea μ = E(X), σ2 = Var(X) y p = P(X ∈ B) donde B es un conjunto que define
alguna “característica distintiva” de X (como ser mayor que 25). Como formalizaremos en la
sección C.4, es razonable “estimar” X
X estas tres cantidades, respectivamente, por:
n
n
Ŷ iŶ
Xi Xi
â1
<
Xâ
La media de la muestra: X â iâ1
n n
n
ŶŶ
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úmero de Xi que está en B

< La proporción de la muestra: pˆ â
n
XX X
(Otros parámetros población/distribución, y estimados de ellos, son ciertamente posibles, pero
n n n E ( X ) â y Var ( X ) âį 2 n
estos tres servirán Ŷ ŶXiŶ Xpara
i Xi nuestros propósitos.) Note que cada una de estas cantidades X puede
calcularseXX sólo
Xâ
â iâa
X iâ 1âpartir
1iâ1 del conocimiento X de los X datos de la
~ N ( Ĩ,į / n )muestra (esto es, no hay parámetros
XX n n n involucrados);
población/distribución tales cantidades se llaman estadísticas (de X la muestra). n
n
n
Ŷ Xi Lo
importante a recordar nn
acerca de Ŷ lasXiestadísticas es que están basadas en una muestra n
aleatoria y
ŶiŶ X iâ1
Ŷ E(s ) = į ŶX â
2 2
n XXi ii
n n
Xi
que, como
XX Xâ
tales,
â
â iâiâ
â 1Ŷ
Ŷiâ1iâ11
1(porXŶ(i
X Źsí
(
i Ź
XX i
X
)Ź
mismas 2X
) 2 2 iâ1
X â ) son aleatorias;
n (n Ź1) į s 2 el 2 lector obtiene su muestra y nosotros la nuestra
X â iâ1
n
(del mismo s 2â s tamaño
2 iâ1
âs 2nâ nn n), que eran probablemente 2 muestras diferentes, así que también n probable-
Źn 1Źn1Ź1 numéricos
n valores ĳ n
Ŷ
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 ĳ n2ĳŹn1 Źĳuna 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
į ĳnn2Ź en
n Ź 11
inglés) denotados como ĳ 2
. Cualquier libro convencional de estadística tendrá una
ĳĳ
2 n Ź 1
ĳ2n2Ź11 E(ĳpˆ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
Źppp)))///nnn . Para una n grande, la distribuciónŶde

2
E(((pˆppˆˆ)))â
EE â
âppp yyyyVar Var(((pˆppˆˆ)))â
Var ââppp(1((11Ź Ź ( pî )pŹ
E( X ââ
es Xp )número
y Var ( pˆ )de
aproximada- âX p(i1 que
Ź p ) está
/ n en B
<
ˆ
mente normal. s 2 â iâ1 n
n Ź1
La importancia de las distribuciones de muestreo es que proporcionan la base para la esti-
mación y la inferencia acerca de los parámetros población/distribución. número E ( X ) â y Var ( X ) âį 2 n
de Xi que está en B
pˆ â
n X ~ N ( Ĩ,į / n )
C.4 Estimación puntual
Las cantidades que son características de población/distribución, como μ, σE(s 2
y2)p, = se llaman
į 2į 2 n
E ( X ) â y Var ( X ) â
parámetros. A menos que de alguna manera conozca (o suponga) todo acerca (de la
n Ź1) s2 į 2 población/
distribución, no sabrá los valores de los parámetros. En su lugar, lo mejor Xque puede2/ hacer
~ N ( Ĩ,į
es estimar estos parámetros con estadísticas de muestra, como se describió en la sección ĳ n Ź1 nC.3.
)
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.
ĳ 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
E(s2) = į 2en probabilidad y estadística

Una actualización n 581
2
(n Ź1) s į 2 Ŷ ( Xi Ź X )2
s 2 â iâ1
ĳ n2 Ź1 nŹ
propiedad reconfortante y, de los resultados de la distribución del muestreo citados en la1sec-
ción C.3, es uno que disfruta X para m, s para σ Ey( pˆ )para
2 2
â p yp.Var ( pˆ )â p(1 Ź p ) / n
Aunque el que no haya sesgo nes bueno, no habla de la estabilidad del estimador número entredelas
Xi que está en B
pˆ â
muestras. Con otras cosas (comoŶque Xi no haya sesgo) constantes, preferiríamos un estimador n
â1
que posea una varianza bajaXya â ique es más probable que esté cerca del parámetro a estimar.
n
El estimador de varianza más baja se llama más eficiente; tal término es de hecho análogo a
E ( X ) â y Var ( X ) âį 2 n
la eficiencia económica en el muestreo, n pues un estimador más eficiente requerirá una muestra
más pequeña para que su varianza Ŷ ( Xi Ź X )2 a un nivel tolerable.
disminuya X ~ N ( Ĩ,į / n )
s 2 â iâ1
Relacionada con la eficiencia se encuentra la noción de consistencia de un estimador. Aun-
n Ź1
que hay varios tipos diferentes de consistencias, la idea básica es que, a medida E(s2)que
= į 2el tamaño
de la muestra n crece, el estimador se hace “mejor” en algún sentido (la falta (de n Ź1) s2 propiedad
esta į2
ciertamente sería algo negativo). número
Por de Xi nos
ejemplo, quegustaría
está en Bque la varianza de un estimador dis-
pˆ â ĳ n2 Ź1
minuyera, de preferencia a cero y también rápidamente, n conforme se incrementa el tamaño de
la muestra. Si se echa un vistazo a las expresiones para las varianzas de X , s2Ey( pˆ ), â Var ( pˆ ) â p(1 Ź p ) / n
enplay sección
C.3, es notorio que todas ellas
E ( Xsatisfacen
) â y Var (esta propiedad.
X ) âį2 n n
Ŷ Xi
C.5 Intervalos de confianza X ~ N ( Ĩ,į / n ) X â iâ1
n
La mayoría de los estimadores puntuales más comunes tienen buenas propiedades. Pero todos
E(s2) = įcon
poseen una variabilidad asociada 2 ellos, así que por lo general “pierden”n el parámetro que
estén estimando. Un intervalo (n Ź1de s 2
į2
) confianza proporciona una forma de2 cuantificar Ŷ ( Xi Ź X )2
tal impre-
s â iâ1
cisión. El objetivo del procedimiento ĳ n2 Ź1del intervalo de confianza es formar unn intervalo, Ź1 con
puntos finales determinados por la muestra, que contendrá o “cubrirá” el parámetro objetivo
E( pˆ ) â p Var ( pˆ )â p(1 Ź p ) / n
con una probabilidad especificada dey antemano (alta) llamada nivel de confianza. La notación
númerodel de Xi que está en B
usual es que el nivel de confianza es 1 − α, resultando en 100(1 − α) pˆporcentaje â intervalo
de confianza. n
Empleando los resultados de la distribución del muestreo, así como resultados similares
encontrados en libros de estadística como los mencionados al inicioEde ( Xeste
) â yapéndice,
Var ( X ) â seį 2han
n
obtenido los siguientes intervalos de confianza para varios problemas comunes de estimación
de parámetros: X ~ N ( Ĩ,į / n )
< La esperanza μ de población/distribución: el intervalo de confianza

E(s2) =es:
į 2
(n Ź1) s2 į 2
ĳ n2 Ź1
tn Ź1, 1Ź Ĝ /2 E( pˆ ) â p y Var ( pˆ )â p(1 Ź p ) / n
donde tn Ź1, 1Ź Ĝ /2 es el punto que tiene debajo la probabilidad 1 − α/2 para la distribución
t de Student con n – 1 DF (este punto se llama el punto crítico superior 1 − α/2 para tal
distribución y se coloca en la tabla como parte del ejercicio C-4 al final de este apéndice
ÖÞ
1) s 2 (n Źlibro
n Źcualquier
y (en 1) s2 2 de estadística). La probabilidad de cobertura apropiada para dicho
ÖÞ
,( n Ź2 1) s ( n Ź 1) s 2
ĳ 2
intervalo ĳ
n Ź1, 1Ź Ĝ /2supone ,
que
2 n Ź1, 1Ź Ĝ /2 la2 distribución subyacente es normal, pero el teorema del límite
tn Ź1, 1Ź Ĝ /2 ĳ n Ź1, 1Ź Ĝ /2 ĳ n Ź1, 1Ź Ĝ /2
central asegura al menos una cobertura correcta aproximada para una n grande.
< La varianza σ2 de población/distribución: el intervalo de confianza es
ÖÞ
(n Ź 1) s 2 2 (n Ź 1) s 2 2
ÖÞ
Ź 1) s , (2n Ź 12) s
ĳ(nn22Ź1, ĳ Ź1,1)1Źs Ĝ /2 (n Ź 1) s 2
ÖÞ
1Ź Ĝ /2 ,( n nŹ
ĳ nŹ1, 1 ŹĜ /2 2 ĳ n2Ź 1, Ĝ,/2 2
ĳ ĳ 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
ÖÞ
ĳ n2Ź1, 1 ŹĜ /2 s A2,ĳ/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 ĳ n Ź1, 1Ź Ĝ /2 esĳel
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 ,
ĳ n2Ź1, 1Ź Ĝ /2 ĳ 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
ÖÞ
ĳ
(n Ź 1) s 2 (n Ź 1anterior:
1Ź Ĝ /2 finales del intervalo
2
ĳ
,
n Ź 1, 1 Ź Ĝ / 2
2
)s 2
n Ź 1, Ĝ / 2 tn Ź1, 1Ź Ĝ /2
(ÖÞ
(n Ź 1) s (n Ź 1) s
2 2
,Ĩ – ĨB :
ÖÞ
n Źĳ1) s (n Ź 1)ĳs
2 2A 22
,
n Ź 1, 1 Ź Ĝ / 2 n Ź 1, Ĝ / 2
ÖÞ
ĳ 2
ĳ 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,
ĳ n2Ź1, 1Ź Ĝ /2 ĳ 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
ĳ n2Ź1, 1 ŹĜ /2 ĳ 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 ĳ nŹ1, 1 ŹĜ /2entre
2
ĳ 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Â) pˆ B (1 Ź pˆB)
<
de Ź pˆ B ï z1Źesa /2
pˆ A confianza pˆàA(1 Ź pÂ) (1 Ź
pˆ BA(pˆ1AŹ (1 Ź
pÂB)pÂ) 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

n pˆ n (1Ź pˆ )
pˆ A(1 Ź pÂ) pˆ (1 Ź pˆB)

pˆ A Ź pˆ B ï z1Ź a /2 à B
nA nB
con la interpretación obvia de los subíndices A y B. Ambos tamaños de muestra tienen

que ser “grandes”, como se describe en el punto anterior.
C.6 Pruebas de hipótesis

Además de la estimación, ya sea puntual o de intervalo, de los parámetros población/distribu-
ción, se pueden usar los datos para “probar” alguna afirmación hecha acerca de la población/
distribución. Estas preguntas y procedimientos se llaman pruebas de hipótesis y hay muchas,
muchas pruebas que las personas han ideado para una gran variedad de aplicaciones. No hare-
mos ningún intento de dar un tratamiento completo de las pruebas de hipótesis, sino que sólo
describiremos la idea general y daremos un par de ejemplos específicos de simulación. Para
más información sobre derivación y fórmulas específicas para hacer pruebas de hipótesis, por
favor consulte un libro de estadística como aquellos que mencionamos al principio del presente
apéndice.
La afirmación a ser probada se llama hipótesis nula, por lo general denotada como H0. Con
frecuencia, representa el statu quo o la situación histórica, o lo que alguien más reclama. La
negativa (lo opuesto) de la hipótesis nula es la hipótesis alternativa, que denotaremos como H1.
El intento de la prueba de hipótesis es desarrollar una regla de decisión para usar los datos y
elegir ya sea H0 o H1, además de estar tan seguro como se pueda que lo que sea que se declare
como cierto en verdad lo sea.
Sin embargo, exceptuando la información completa acerca de la población/distribución,
nunca podemos estar completamente seguros de que hacemos la elección correcta entre H0 y
H1. Si H0 es realmente cierta y aun así la rechazamos a favor de H1, cometemos un Error tipo I.
Pero si H1 es en verdad lo cierto y aun así no rechazamos a H0, cometemos un Error de tipo II.
Las pruebas de hipótesis se configuran para permitir especificar la probabilidad α de un Error
tipo I, mientras se hace todo lo posible por maximizar la probabilidad β de un Error tipo II. Si
se exige en verdad una α pequeña, la obtendrá pero al costo de una β mayor (aunque la relación
entre las dos no es sencilla), a menos que pueda recopilar algunos datos más. En la prueba de
hipótesis, H0 y H1 no reciben el mismo tratamiento, se le da el beneficio de la duda a H0, así que
si rechazamos H0 y estaremos tomando una decisión bastante sólida y confiada de que H1 es
cierta. Pero si no podemos acumular suficiente evidencia en contra de H0 para rechazarla, no
hemos “probado” necesariamente que H0 es la verdad: sólo hemos fallado al encontrar eviden-
cia en contra de ella. La razón de no rechazar H0 podría, por supuesto, ser que en realidad es
cierta. Pero otra razón para no rechazar H0 es simplemente que no tenemos suficientes datos
para “ver” que H0 es falsa.
Otra forma de configurar y llevar a cabo una prueba no es tomar una decisión firme de sí/no,
sino más bien de cuantificar qué tan “acertado” se está acerca de qué hipótesis es la correcta.
El valor p de un conjunto de datos en una prueba es la probabilidad de obtener un conjunto de
datos, si H0 es cierta, que esté más a favor de H1 que el que se obtuvo. Así que si el valor p es
muy pequeño, el lector está indicando que es muy difícil obtener información que se encuentre
más a favor de H1 que la información que ya tiene en su conjunto de datos, así que la evidencia
para H1 es fuerte. Si el valor p es grande, digamos 0.3 o 0.6, entonces es enteramente posible
584 Apéndice C
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.
a ) Grafique p(x) para todas las x en el rango.
b ) Calcule numéricamente y grafique la función de distribución acumulada F(x).
c ) Calcule P(1.4 ≤ X ≤ 4.2).
d ) Calcule P(1.4 < X < 4.2).

e ) Calcule el valor esperado de E(X).
f ) Calcule la varianza Var(X).
g ) Calcule la desviación estándar de X.
C-2 Suponga que X tiene una distribución uniforme (continua) entre 10 y 20 (véase el apén-
dice D).
a ) Calcule E(X).
b ) Calcule Var(X).
c ) Calcule P(X < 12).
d ) Calcule P(X > 12).
e ) Calcule P(X < 8 o X > 22).
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.)
a ) Calcule P(X > 5).
b ) Calcule P(1.4 ≤ X ≤ 4.2).
c ) Calcule P(1.4 < X < 4.2).
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.
Tabla D-1. Resumen de distribuciones de probabilidad de Arena
Distribución Valores de parámetros

Beta BETA BE Beta, Alfa
Continua CONT CP CumP1, Val1, . . . CumPn, Valn
Discreta DISC DP CumP1, Val1, . . . CumPn, Valn
Erlang ERLA ER ExpoMedia, k
Exponencial EXPO EX Media
Gamma GAMM GA Beta, Alfa
Johnson JOHN JO Gamma, Delta, Lambda, Xi
Lognormal LOGN RL LogMedia, LogEstándar
Normal NORM RN Media, Desviación estándar
Poisson POIS PO Media
Triangular TRIA TR Mínimo, Moda, Máximo
Uniforme UNIF UN Mínimo, Máximo
Weibull WEIB WE Beta, Alfa
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
Beta (𝛃, 𝛂) BETA(Beta, Alfa) o

BE(Conjunto de parámetros)
Función de f(x)
densidad de x ĝ Ź1 (1 Ź x)Ĝ Ź1
probabilidad f (x) = para 0 < x <1
B( ĝ , Ĝ)
f(x) 0 de otra forma

f(x)
x ĝĝ Ź1
(1 Ź x) Ĝ Ź1
x (1 Ź x)Ĝ Ź1 para 0 < x <1
Ź1
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
Continua CONTINUOUS(CumP1, Val1, . . ., CumPn, Valn) o

(c1, x1, . . ., cn, xn) CONT(CumP1, Val1, . . ., CumPn, Valn) o CP(Conjunto de parámetros)
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
c1 si x â x1 (una masa de probabilidad c1 en x1)
f(x) = cj Ź cjŹ 1 si xjŹ 1 ǔ x< xj , para j = 2, 3, . . ., n
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
(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.
Rango [x1, xn ]
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
Discreta DISCRETE(CumP1, Val1, . . ., CumPn, Valn) o

(c1, x1 . . ., cn, xn) DISC(CumP1, Val1, . . ., CumPn, Val n) o DP(Conjunto de parámetros)
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.
Rango {x1, x2, . . ., xn}
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.
Erlang (𝛃, k) ERLANG(ExpMean, k) o ERLA(ExpMean, k) o

ER(Conjunto de parámetros)
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.
Rango (0, +∞)
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
Exponencial (𝛃) EXPONENTIAL(Mean) o EXPO(Mean) o

EX(Conjunto de parámetros)
Función de f(x)
densidad de
1
probabilidad ĝ 1 Ź x /ĝ
e para x > 0
f (x) = ĝ
0 de otra forma
0 x
Parámetros La media (β) especificada como un número real positivo.
Rango [0, +∞)
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.
Gamma (𝛃, 𝛂) GAMMA(Beta, Alfa) o GAMM(Beta, Alfa) o

GA(Conjunto de parámetros)
Función de f(x)
densidad de Ĝâ 1/2
ĝ ŹĜx Ĝ Ź1eŹx / ĝ
Ĝ=1/2 para x > 0
probabilidad f (x) = Ą (Ĝ )
Ĝâ 1 0 de otra forma

Ĝâ 2
k=2
Ĝâ
k=33
en donde Ą es la función gamma
completa dada por
x ƈ
0 Ą(Ĝ ) âƞ t Ĝ Ź1e Ź tdt
0
Parámetros El parámetro de escala (β) y el parámetro de forma (α) especificados como valores
reales positivos.
Rango [0, +∞)
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
Johnson JOHNSON(Gamma, Delta, Lambda, Xi) o

JOHN(Gamma, Delta, Lambda, Xi) o JO(Conjunto de parámetros)
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 (ξ).
Rango (−∞, +∞) Familia no acotada
[ξ, ξ + λ] Familia acotada
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.)
Lognormal (𝛍, 𝛔) LOGNORMAL(LogMean, LogStd) o

LOGN(LogMean, LogStd) o RL(Conjunto de parámetros)
Función de f(x) Denota los parámetros de entrada

densidad de
probabilidad Ĩl įl
Ĩ â ln(Ĩ l2 / į 2l à Ĩ 2l )
f(x) ln (į 2l los
į â Denota 2
l )/
Ĩ 2l
à Ĩparámetros de entrada
0
f(x)
x Denota los parámetros de entrada
Ĩl įl
Ĩl įĨ
Ĩ â ln( l
2
/ į 2 à Ĩ 2)
l l l
į â ln (į à Ĩ ) / ĨĨ2l â ln(Ĩl / į l à Ĩ l )

2 2 2
2 2
l l
x
į â ln (į à Ĩ ) / Ĩ 2l
2
l
2
l
0 1 2 2
0 x eŹ(ln(x) ŹĨ) /( 2į ) para x > 0

f(x) = į x 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
Normal (𝛍, 𝛔) NORMAL(Mean, StdDev) o

NORM(Mean, StdDev) o RN(Conjunto de parámetros)
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.
Rango (−∞, +∞)
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.
Poisson (𝛌) POISSON(Mean) o POIS(Mean) o

PO(Conjunto de parámetros)
Función de (x)
pf(x)
masa de e Źħ ħx
probabilidad paraxġ {0, 1, . . .}
p(x) = x!
de otra forma
0 x
Parámetros La media (λ) especificada como un número real positivo.
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
Triangular (a, m, b) TRIANGULAR(Min, Mode, Max) o

TRIA(Min, Mode, Max) o TR(Conjunto de parámetros)
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
Varianza (a2 + m2 + b2 – ma – ab – mb)/18
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).
Uniforme (a, b) UNIFORM(Min, Max) o

UNIF(Min, Max) o UN(Conjunto de parámetros)
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
Weibull (𝛃, 𝛂) WEIBULL(Beta, Alfa) o

WEIB(Beta, Alfa) o WE(Conjunto de parámetros)
Ĝ = 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
E.1 Autorización para copiar el software

Este software académico puede instalarse en cualquier computadora universitaria, así como
en las computadoras de los estudiantes. Está pensado para usarse junto con este libro con el
propósito de aprender simulación y Arena. El lector tiene el derecho a usar y hacer copias del
software para uso académico con propósitos de enseñanza e investigación. El uso comercial
del software se encuentra prohibido. El soporte del software se suministra sólo al instructor
registrado.
Este libro de texto describe Arena 10.0 y lo emplea para compilar y ejecutar los ejemplos,
pero se espera que las versiones futuras de Arena se puedan usar con los mismos buenos resul-
tados con él. Dado que las nuevas descargas de Arena por lo general se adelantan a las actua-
lizaciones de este texto, animamos a las instituciones académicas a mantener su software de
laboratorio e investigación al día y hacer copias de su último CD de instalación disponible para
que los estudiantes reemplacen lo que se incluye en el libro. Sin embargo, es importante que
los estudiantes usen la misma versión de software que se emplea en los laboratorios, porque los
modelos son compatibles con las futuras versiones, pero no con las anteriores (por ejemplo, un
modelo de Arena 10.0 puede cargarse en Arena 11.0, pero uno de Arena 11.0 no puede cargarse
en Arena 10.0).
E.2 Instalación del software de Arena

Siga esta secuencia para instalar su software de Arena. Por favor note que no puede aceptar
todas las predeterminaciones; hay algunos pasos específicos que debe seguir durante el proceso
de instalación:
1. Introduzca el CD de Arena para iniciar el programa de autoejecución que despliega la
pantalla de instalación de Arena. Si no se ejecuta de forma automática, busque en el di-
rectorio CD para localizar autorun.exe y haga doble clic para iniciar la instalación.
2. Del diálogo de instalación seleccione Install Arena 10 00.00 (CPR 7). Cuando pregunte
por el número de serie, teclee STUDENT para activar la versión académica. Ésta perso-
naliza la instalación, proporciona acceso a los ejemplos referidos en el libro de texto y
le permite construir modelos más grandes.
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
3. Cuando elija la ubicación para instalar Arena en el disco duro de su computadora,

por favor note que Arena se colocará en la subcarpeta Arena 10.0 de la carpeta que
especifique.
4. Después de instalar Arena, reinicie su computadora si así se requiere.
5. Si tiene más preguntas, por favor consulte la sección Zona del usuario de nuestro sitio
web en www.ArenaSimulation.com.
La activación de la licencia no se provee con la versión STUDENT de Arena, ni se requiere

para ella. Si ve una opción para instalar la activación de Arena, ésta debería despejarse (no
marcarse). Si se encuentra instalando el paquete de laboratorio de Arena (Arena PE Educatio-
nal Lab Package), o para más información acerca de la activación de la licencia o cualquier otro
aspecto de la instalación, seleccione Installation Notes de la pantalla de instalación de Arena.
E.3 Requisitos del sistema

Los requisitos y recomendaciones mínimos para ejecutar el software de Arena son:
< 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
posterior).
< Microsoft Internet Explorer 5.01 o posterior. (Éste no necesita ser su buscador activo,
pero algunos componentes IE son necesarios para que Arena funcione.)
< Adobe Acrobat Reader 7.0 o posterior para ver la documentación.
< Unidad de disco duro con 75-250 MB de espacio libre en disco (dependiendo de las
opciones instaladas).
< 64 MB en RAM (se recomienda 128 MB en RAM o más, dependiendo del sistema ope-
rativo).
< Mínimo un procesador Pentium, 300 Mhz o más.
< La ejecución y animación de los modelos de simulación pueden requerir la realización
de muchos cálculos, así que un procesador más rápido con memoria adicional podría
resultar en un desempeño significativamente mejor. Además, se recomienda contar con
un monitor grande y una pantalla de resolución de al menos 1 024 × 768 para mejorar
la vista de la animación.
< Con Windows 2000 y Windows XP debe contar con los privilegios del administrador para
instalar el software.
< Algunos sistemas Windows 98 SE pueden no ejecutar Autorun.exe o Setup.exe de forma co-
rrecta. Si surge tal problema, cree un directorio en el disco duro local y copie los contenidos
del CD de instalación de Arena 10.0 en ese directorio. Después cargue ya sea Autorun.exe
o Setup.exe del directorio recién creado.
Referencias
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
Harrison, J. M. y C. H. Loch, (1995), “Operations Management and Reengineering”, Graduate

School of Business, Stanford University, Stanford, CA.
Hogg, R. V. y A. T. Craig, (2005), Introduction to Mathematical Statistics, 6a. ed., Macmillan,
Nueva York, NY.
Johnson, M. A., S. Lee y J. R. Wilson, (1994), “Experimental Evaluation of a Procedure for
Estimating Nonhomogeneous Poisson Processes Having Cyclic Behavior”, ORSA Journal
on Computing 6, pp. 356-368.
Kelton, W. D., (1996), “Statistical Issues in Simulation”, Proceedings of the 1996 Winter Simu-
lation Conference, J. M. Charnes et al. (eds.), pp. 47-54.
Kleindorfer, G. B. y R. Ganeshan, (1993), “The Philosophy of Science and Validation in Simu-
lation”, Proceedings of the 1993 Winter Simulation Conference, G. W. Evans et al. (eds.),
pp. 50-57.
Kuhl, M. E. y J. R. Wilson (2000), “Least squares estimation of nonhomogeneous Poisson
processes”, Journal of Statistical Computation and Simulation 67, pp. 75-108.
Kuhl, M. E. y J. R. Wilson (2001), “Modeling and simulating Poisson processes having trends
on nontrigonometric cyclic effects”, European Journal of Operational Research 133, pp.
566-582.
Kulwiec, R. A., (1985), Materials Hyling Hybook, 2a. ed., John Wiley & Sons, Inc., Nueva
York, NY.
L’Ecuyer, P., (1996), “Combined Multiple Recursive Generator”, Operations Research 44, pp.
816-822.
L’Ecuyer, P., (1999), “Good Parameter Sets for Combined Multiple Recursive Random Num-
ber Generators”, Operations Research 47, pp. 159-164.
L’Ecuyer, P., R. Simard, E. J. Chen y W. D. Kelton, (2002), “An Object-Oriented Random
Number Package with Many Long Streams and Substreams”, Operations Research 50, pp.
1073-1075 (Online Companion at http://or.pubs.informs.org/Media/L%27Ecuyer.pdf).
Lane, David M., (2005), HyperStat Online Textbook, http://davidmlane.com/hyperstat/index.
html.
Lane, M. S., A. H. Mansour y J. L. Harpell, (1993), “Operations Research Techniques: A Lon-
gitudinal Update 1973-1988”, Interfaces, vol. 23, pp. 63-68.
Law, A. M. y W. D. Kelton, (2000), Simulation Modeling and Analysis, 3a. ed., McGraw-Hill,
Nueva York, NY.
Leemis, L. M., (1991), “Nonparametric Estimation of the Intensity Function for a Nonhomo-
geneous Poisson Process”, Management Science 37, pp. 886-900.
Lindley, D. V., (1952), “The Theory of Queues with a Single Server”, Proceedings of the Cam-
bridge Philosophical Society 48, pp. 277-289.
Marsaglia, G., (1968), “Random Numbers Fall Mainly in the Planes”, National Academy of
Science Proceedings, vol. 61, pp. 25-28.
Morgan, B. J. T., (1984), Elements of Simulation, Chapman & Hall, Londres.
Morgan, C. L., (1989), “A Survey of MS/OR Surveys”, Interfaces, vol. 19, pp. 95-103.
Musselman, K. J., (1993), “Guidelines for Simulation Project Success”, Proceedings of the 1993
Winter Simulation Conference, G. W. Evans et al. (eds.), pp. 58-64.
Nance, R. E., (1996), A History of Discrete Event Simulation Programming Languages, History
of Programming Languages, T. J. Bergin y R. J. Gibson (eds.), ACM Press and Addison-
Wesley Publishing Company, pp. 369-427.
Referencias 607
Nance, R. E. y R. G. Sargent, (2003), “Perspectives on the Evolution of Simulation”, Operatio-

ns Research 50, pp. 161-172.
Nelson, B. L., (1990), “Control-Variate Remedies”, Operations Research 38, pp. 974-992.
Nelson, B. L., J. Swann, D. Goldsman y W. Song, (2001), “Simple Procedures for Selecting the
Best Simulation System when the Number of Alternatives is Large”, Operations Research
49, pp. 950-963.
Palisade Corporation, (2006), @RISK, http://www.palisade.com/, Ithaca, NY.
Pegden, C. D., R. E. Shannon y R. P. Sadowski, (1995), Introduction to Simulation Using SI-
MAN, 2a. ed., McGraw-Hill, Nueva York, NY.
Rasmussen, J. J. y T. George, (1978), “After 25 Years: A Survey of Operations Research Alum-
ni, Case Western Reserve University”, Interfaces, vol. 8, pp. 48-52.
Sadowski, R. P., (1989), “The Simulation Process: Avoiding the Problems and Pitfalls”, Procee-
dings of the 1989 Winter Simulation Conference, E. A. MacNair et al. (eds.), pp. 72-79.
Sadowski, R. P., (1993), “Selling Simulation and Simulation Results”, Proceedings of the 1993
Winter Simulation Conference, G. W. Evans et al. (eds.), pp. 65-68.
Sargent, R. G., (1996), “Verifying and Validating Simulation Models”, Proceedings of the 1996
Winter Simulation Conference, J. M. Charnes et al. (eds.), pp. 55-64.
Sargent, R. G., K. Kang y D. Goldsman, (1992), “An Investigation of Finite-Sample Behavior
of Confidence Interval Estimators”, Operations Research 40, pp. 898-913.
Schmeiser, B. W., (1982), “Batch Size Effects in the Analysis of Simulation Output”, Operations
Research 30, pp. 556-568.
Schriber, T. J., (1969), Fundamentals of Flowcharting, John Wiley & Sons, Inc., Nueva York,
NY.
Seila, A. F., (1990), “Output Analysis for Simulation”, Proceedings of the 1990 Winter Simula-
tion Conference, O. Balci et al. (eds.), pp. 49-54.
Shannon, R. E., S. S. Long y B. P. Buckles, (1980), “Operations Research Methodologies in
Industrial Engineering”, AIIE Trans., vol. 12, pp. 364-367.
Swart, W. y L. Donno, (1981), “Simulation Modeling Improves Operations, Planning, and Pro-
ductivity for Fast Food Restaurants”, Interfaces, vol. 11, pp. 35-47.
Thomas, G. y J. DaCosta, (1979), “A Sample Survey of Corporate Operations Research”, In-
terfaces, vol. 9, pp. 102-111.
Wysk, R. A., J. S. Smith, D. T. Sturrock, S. E. Ramaswamy, G. D. Smith y S. B. Joshi, (1994),
“Discrete Event Simulation for Shop Floor Control”, Proceedings of the 1994 Winter Si-
mulation Conference, J. D. Tew et al. (eds.), pp. 962-969.
Índice analítico
Símbolos Acumulador estadístico, variables del 23

.AND. 205 Acumuladores estadísticos 23, 26
Archivo .dat 268, 274, 314 Adjuntar panel de plantillas (Attach,
Archivo .dgr 274 Template Panel) 80
Archivo .doe 55, 75, 277, 421 Adjuntar panel de plantillas, diálogo
Archivo .exp 109, 310 (Attach Template Panel, dialog) 80
Archivo .gif 88 Adjuntar plantilla (Template Attach) 55
Archivo .out 78, 79 ADO 414
Archivo .p 277 Agrupadas 276
Archivo .pan 277 Agrupar 100, 104
Archivo .plb 68, 85, 98, 150 Ajustar todos (Fit All) 179
Archivo .tpo 80 Ajustar todos, resumen de (Fit All
Archivo .jpg 88 Summary) 180
Archivo .mod 109, 310, 396, 506 Ajuste de las distribuciones de entrada 176
Archivo .vsd 98 Aleatoria, distribución (Expo) (Random
Botón << 85 [Expo]) 40, 62, 81, 299
Dos rutas por probabilidad (2-way by Chan- Aleatoriedad 34, 265
Aleatorio 6, 304, 335
ce) 122
Algoritmo de integración continua 468
.EQ. 205
Alineación del diagrama de flujo
Extensión de archivo .tpo 80
(Flowchart Alignment) 60, 100
.GE. 205
Alinear 100, 104
.GT. 205
Almacenaje, módulo (Storage ID) 343
Inventario (s, S) 244, 245
Almacenamiento 105
.LE. 205
Almacenamiento intermedio infinito 360
.LT. 205
Almacenamiento, botón (Storage) 346
.NE. 205
Almacenamientos intermedios finitos 360
.OR. 205
Almacenamientos intermedios
Tecla ? 59, 89
finitos 360
< 129, 205
infinitos 360
<= 205
Almacenar-requerir-demorar-desalma-
<> 205
cenar-tTransportar (Store-Request-
== 205, 305
Delay-Unstore-Transport) 346
> 129, 205
Alt+ 54
>= 205
Alt+Prnt Scrn 57
@RISK 47
Alt+Tab 57
A Alternativas 273
Alto nivel (Top-Level) 57
Abandono del sistema, rechazo del sistema Análisis comparativo 549
(Balking) 198, 208, 366, 368 Análisis de sensibilidad 173, 175, 537
Acceso directo, tecla de 59, 89 Análisis de variancia 584
Acceso, módulo de 349 Análisis estadístico 48, 293
Acción 64, 83, 124 Análisis predictivo 550
Aceleración 129 Análisis, tipos de 549
Activate, módulo 366 comparativo 549
ActiveX® Automation 420 de candidatos 549
ActiveX® Data Objects 414 predictivo 550
Actualizar (Refresh) 70 Analista, nombre del 72, 89
Acumulación de pedidos atrasados Analizador de procesos (Process Analyzer)
Backlogging) 245 75, 99, 265, 268, 277
610 Índice analítico
Analizador de resultados (Output Arena News Flash 99

Analyzer) 34, 99, 265, 268, 274, 276, Arena, analizador de datos de entrada de
314, 320, 521, 584 (Arena Input Analyzer ) 34
Analizar datos de entrada (Input Analyzer) Arena, analizador de resultados de (Arena
34, 99, 173, 176, 177, 272, 584 Output Analyzer) 34
Anderson, D. 569, 605 Arena, archivos SMART de 102
Ángel de pausa (Break Angel) 21 Arena, ayuda de 102
búsqueda 102
Animación 12, 68, 147
índice 102
recurso 68
tabla de contenido 102
separación de la 148
Arena, carpeta 55, 80
Animación, barra de herramientas
Arena, edición profesional (Arena
(Animate, ToolBar) 84, 103 Professional Edition) 449
graficar (Plot) 104 Arena, fábrica de símbolos (Arena Symbol
Animación, cola de 147, 148 Factory ) 99, 100
Animación, factor de velocidad Arena, ícono de 54
(Animation Speed Factor) 129 Arena, jerarquía de 200
Animar con color de fondo de escritorio Arquitectura de alto nivel (High-Level
(Animate At Desktop Color Depth) Architecture [HLA] ) 461
101 Arranque 29
Animar conexiones (Animate Connectors) Arranque, condiciones de 24
69, 81, 101, 104 Ashour, S. 491, 605
ANOVA 584 Asignación, comando de (ASSIGN,
Aplicaciones, plantillas de soluciones para 11 command) 354
centros de contacto 11 Asignación, módulo de (Assign, module)
líneas de empaque 11 60, 117, 120, 343, 385, 488
Árbol 75 Asimétrico 272
Archivo de datos, módulo del 408, 410, 413 Atracción, puntos de 105
Archivo de resultados (Output File) 268, Atributo 21, 26, 67, 117, 119
274, 317 Atributo de estación de entidad (Entity
Archivo de texto ASCII 177 Station (M)) 295, 301, 482
Archivo File, menú 98 Atributo de secuencia de entidad (Entity
adjuntar/retirar panel de plantillas Sequence, NS), 295, 300
(Template Panel Attach/Detach) 98 AutoCAD 98, 306, 420
configuración de impresión (Print Autoconectar (Auto-Connect ) 69, 81,
Setup) 98 101, 117
DXF Import 98 Autocorrelación 44, 46
enviar (Send) 98 Autopista 350
importar diagrama de VISIO (Import autorun.exe 603
Visio Drawing) 98 Avisos de error (Errors/Warnings) 165
imprimir (Print) 98 ventana 109
paleta de color abierta (Open Color Ayuda 107
Palette) 98 Ayuda, botón de (Help) 107
salir (Exit) 98 Ayuda, menú de (Help) 102, 107
salvar paleta de color (Save Color archivos SMART 108
Palette) 98 Arena Help 102
vista previa (Print Preview) 98 Arena SMART Files 102
Archivos 54 asistencia de Arena en la Web 102
Arcos 103, 105 Manuales de producto (Product
Área 71 Manuals) 102
Área de estacionamiento (Parking Area) 339 ¿Qué es esto? (What’s This) 102
Arena 10 Release Notes 102
archivos .doe 55 Soporte y entrenamiento (Support and
ventana de 55, 56 Training) 102
versión académica 54 Ayuda, sensible al contexto 55, 103,
viaje por 53 107
Arena en tiempo real (Arena Real-Time) 461 Ayuda, tema de 108
Índice analítico 611
B estándar (Standard) 102

grabar macro (Record Macro) 104
Balci, O. 535, 605 integrar (Integration) 104
Bambi 55 organizar (Arrange) 71, 88, 104
Banda continua, segmentos de 352 vista (View ) 104
Bandas transportadoras acumuladoras Bases de datos 14
349, 398 BasicProcess.tpo 80
Bandeja para hornear 112 Basura que entra, basura que sale 175
Banks, J. 535, 605 Bauer, K. 524, 605
Barra de depuración (Debug Bar) 99, 167 Beta (BETA) (BE), distribución 176, 587,
ventana calendario 167 589
ventanas de monitoreo de valores Bibliotecas 68
(Watch) 167 Bimodal 182, 183
ventana entidad activa (Active Entity Bindingnavle, S. 491, 605
Window) 167 Block de Asignación (Assign Block) 252,
ventana puntos de pausa (Breakpoints 254, 255
Window) 167 Bloque de búsqueda (Search Block) 373,
Barra de elementos de corrida (Runtime 374, 395, 399
Elements Bar) 99 Bloque de Demora (Delay Block) 255
Barra de herramientas estándar 102 Bloque de demora (Queue Block) 344
abrir modelo (Open Model) 103 Bloque de detección (Detect Block) 470
ayuda sensible al contexto (Context- relación con el tamaño de paso 473
sensitive Help) 103 Bloque de disposición (Dispose Block)
conectar (Connect) 103 253, 256
controles de corrida (Run Controls) 103 Bloque de levantamiento (Pickup Block)
cortar (Cut) 103 395
deshacer (Undo) 103 Bloque de sección o rama (Branch Block)
desplegar vista compuesta (Display 253, 396
Composite View) 103 Bloque de suspensión (Dropoff Block) 395
dividir pantalla (Split Screen) 103 Bloque fin mientras (EndWhile Block) 396
editar excepciones (Edit Exceptions) 103 Bloque fin si (EndIf Block) 395
editar parámetros de tiempo (Edit Time Bloque mientras (While Block) 396
Patterns) 103 Bloque otro (Else Block) 395
enfocar (Zoom) 103 Bloque otro si (ElseIf Block) 395
imprimir (Print) 103 Bloque si (IF Block) 395
layers 103 Bloqueada 382
nuevo modelo (New Model) 103 Bloques 11, 58
pegar (Paste) 103 Bola azul (Blue Ball) 83
rehacer (Redo) 103 Bondad del ajuste, pruebas de 584
retirar (Detach) 103 Bonferroni 584
salvar modelo (Save Model) 103 Botón añadir (add button) 69, 83
submodelo (Submodel) 103 Botón de conexión 68
vista de una región (View a Region) 103 Botones
vista previa impresión (Print Preview) almacenamiento (Storage) 346
103 añadir (Add) 68, 83
Barra de herramientas, animación de avance rápido (Fast-Forward) 129
(Animate Transfer, ToolBar) 105, 106 ayuda (Help) 107
Barra divisora 453 cadena de texto (Text String) 88
Barras de herramientas 56, 99 caja (Box) 88
animar (Animate) 103 coincidir (Snap) 59
animar transferencia (Animate Transfer) coincidir objeto a la retícula de puntos
105, 162 (Snap to Grid) 59
correr interacción (Run Interaction) 104, color de línea de contorno (Line Color)
165, 171 88
dibujar (Draw) 71, 88, 103, 105 color de texto (Text Color) 71, 88
comando (Command) 171, 354 coincidir objeto a la retícula de puntos

conectar (Connect) 68 (Snap Object to Grid) 100
dibujo (Draw) 88 desagrupar (Ungroup) 100
distancia (Distance) 338 distribuir (Distribute) 100
ejecutar (Go) 73, 128, 130, 354 mandar objeto al fondo (Send to Back)
enfocar acercamiento (Zoom In) 59 100
enfocar alejamiento (Zoom Out) 59 mover objeto horizontal o vertical (Flip)
estación (Station) 161 100
estacionamiento (Parking) 339 Cambiar punto de coincidencia de objeto
fila (Queue) 345 (Change Object Snap Point) 100
finalizar (End) 74 Campana, curva de 272
graficar (Plot) 68, 85, 154 Campo, nombre del 62
mandar objeto al fondo (Send to Back) Candidatos, análisis de 549
88 Canicas 112
mostrar (Show) 59 Cantidad 64
paso (Step) 129 Cantidad en espera 28
pausa (Pause) 129, 354 Capacidad 64, 66, 137
recurso (Resource) 84, 306 Capas 99, 103, 128, 166
rellenar con color (Fill Color) 88 Captura en formato AVI (AVI Capture)
retícula (Grid) 59 100
revisar (Check) 128, 165 Carga, área de 348
rutear (Route) 162 Carga, tiempo de 350, 365
segmento (Segment) 353 Carpeta de Ejemplos del Libro 55
texto (Text) 71, 88 Carpetas 54
traer objeto al frente (Bring to Front) 307 Carretillas 333
transportador (Transporter) 334 Carros de transporte de materiales 333
Box 88, 103, 106 Cascada 56, 101
Bratley, P. 523, 605 Caso Western Reserve University 5
Buckles, B. 6, 607 Categoría 391
Buffon, Comte de 8 Categorías 142
Buffon, cruz de 9 Categorías, reporte general de 74, 75, 130,
Buffon, problema de la aguja de 9 268
Buscar 102 CDF (función de distribución acumulada)
Busy 134, 137 512, 573, 575
CDF (función de distribución acumulada)
C conjunta 576
C 10, 11, 202 CDF inversa 513, 514
C++ 11, 420 CDF marginal 577
Caballete, grúas de 328 Celda, tamaño de 348, 350
CAD, dibujos 98, 293, 297, 306 Celdas 347
CAD, paquetes 53 Centros de atención 197
Cadena de texto, diálogo (Text String) 88 Checar modelo (Check Model) 73, 104,
Caja de texto (TextBox) 454 109, 128, 423
Cajero automático (ATM) 2 Check, botón 165
Cálculo “por detrás de lo que se ve” 18 Chen, E. 509, 606
Calendario, programas (Calendar Schedules) Ciclado 507
98 Ciclar tranportadores 335
Calendario, ventana 167 Cíclico 304, 357
Calificación de la tarea 506 Ciclo 510
Cambiar punto de coincidencia de objeto Ciclo, tiempo del 18, 383
(Change Object Snap Point) 100 Ciencias, museos de 112
agrupar (Group) 100 Cifra de mérito económica total 238
alineación de diagrama de flujo Cinema 310
(Flowchart Alignment) 60, 100 Cinlar, E. 516, 605
Clasificación 373 Conjunto, nombre de (Set) 228

Clasificado 24 Conjuntos, tomar un miembro en
Clic derecho 54, 79 específico 304
Cliente 535 Conservación de los resultados 551
Cliente, zona de permanencia del 369 Constructor de expresiones (Expression
CMRG 509 Builder) 63, 65, 69, 71, 86, 87, 379
Coherencia 581 Construir expresión 63, 140
Coincidir (Snap) 59, 81, 104, 149, 339 Contact Center 100
Coincidir con retícula (Snap to Grid) 81, 99 herramientas, menú de 99
Coincidir objeto con retícula (Snap Object Contacto, centros de 11, 14, 58
to Grid) 59, 100 Contador 131
Cola 22, 84 Contador, ejemplo de 193
Colas paralelas 394 Contador, estadística del 77
Color de fondo de ventana (Window Contadores 73, 130
Background Color) 106 Continuas 7
Color de línea (Line Color) 88, 103, 106 Continuos-discretos mezclados 7
Color de texto (Text Color) 71, 106 Control 54
Color de texto, botón (Text Color) 88 Control de corrida (Run Control) 126
Colores, paleta de 98 Control, entidad de 405
Comando 104, 109, 171, 354 Control, variables estadísticas de 524
Comandos, botones de 82 Controlador de corrida (Run Controller)
ComboBox 454 171, 354
Comenzar de nuevo (Start Over) 109 Controlador, respuesta del 458
Comienzo, botón de (Start) 54 Controles 277
Comilla simple de cierre 455 Convey, módulo 349
Comparación de alternativas 36, 273 Copia, protección para el software Arena
Comparaciones múltiples 584 102
Comparar semejante con semejante 523 Copiar (Copy) 54, 56, 98
Comparativo de medias (Compare Jeans) Copiar bloque (Copy Block) 395
275, 521 Correlación 576, 577
Complemento 570 Correlación negativa 524
Comunicaciones 14 Correlacionadas (Correlated ) 79, 131, 319,
Conectar (Connect ) 101, 103, 294, 327 523, 530
Conectores, animación de 69 Correo 98
Conexión de módulos 452 Correr > configurar (Run > Setup) 72, 89,
Conexión inteligente (Smart Connect) 81 101, 125, 131
Conexión inteligente (Smart Connection) Correr > ejecutar (Run > Go) 73
69, 81, 101 Correr modelo en lotes (sin animación)
Conexiones 68, 117, 327 (Batch Run; No Animation) 109, 129,
Conexiones directas 156, 158 142, 267, 314
Conferencia de simulación de invierno Corrida, menú de (Run) 101, 108
(Winter Simulation Conference) 321 avance rápido (Fast-Forward) 101, 108
Configuración de impresión (Print Setup) checar modelo (Check Model) 101, 109
107 comando (Command) 109
Configuración de reticulado y coincidencia comenzar de nuevo (Start Over) 101, 109
(Grid & Snap Settings) 59 configurar (Setup) 101, 108
Conjunto (Set) 232 control de corrida (Run Control) 101
Conjunto de distancias (Distance Set) 334, corrida de grupo sin animación (Batch
337 Run) (No Animation) 109
Conjunto de estados (StateSets) 385 ejecutar (Go) 101, 108
Conjunto de estados, módulo (StateSet) finalizar (End) 101, 109
139, 385 observar (Watch) 109
Conjunto, índice de (Set) 228 paso (Step) 101, 108
Conjunto, módulo 228 pausa (Pause) 101, 108
Conjunto, módulo (Set) 61, 232, 299 pausa en módulo (Break on Module) 109
puntos de pausa (Breakpoints) 109 archivo (File) 408, 410, 413

revisar errores (Review Errors) 101, 109 conjunto (Set ) 61, 299
señalizar módulo activo (Highlight conjunto avanzado (Advanced Set) 232
Active Module) 109 conjunto de estado (StateSet) 139, 385
shift+F5 109 distancia (Distance) 338, 339
SIMAN 101, 109 entidad (Entity) 61, 63, 83, 126
Corrida, modo de (Run Mode) 74, 109 estadísticas (Statistic) 140, 242, 268,
Cortar 54, 56, 98, 103 317, 377, 381
Costeo 64, 68, 231, 242 expresión (Expression) 241, 298
Costo, medida del 64, 68, 231, 242 falla (Failure) 67, 138, 385
Covariancia 523, 576, 577 fila (Queue) 61, 67, 84, 140, 219, 343
Craig, A. 569, 606 programa (Schedule) 61, 136
Creación de entidades 405 recurso (Resource) 61, 64, 66, 84, 329,
Crear, módulo 54, 60, 62, 81, 117, 119, 203, 331, 385
370, 377, 405, 432, 527 secuencia (Sequence) 295, 298
Crear bloque (Create Block) 251 segmento (Segment) 352
Crear desde archivo (Create from File) 88 transportador de banda continua
Crear objeto (VBA) 445 (Conveyor) 350
CRN 520, 521, 522 transportador (Transporter) 334
Cruce de andenes 358 variable (Variable) 61, 199, 298, 377
Crystal Ball® 47 Datos, recolección de 174, 175
Crystal Reports® 77 DAVG 251
Ctrl+ 54 Decide, módulo 60, 111, 117, 122, 123, 208,
236, 366, 368, 396, 527
Ctrl+C 56
Decisión, lógica de 395
Ctrl+Clic 56
Decisión, variable de 39
Ctrl+D 80
Declaración de independencia
Ctrl+N 56
(Declaration of Independence) 578
Ctrl+O 56
Déficit, costo del 246
Ctrl+P 107
Dejar inconcluso (Preempt) 134, 135, 139
Ctrl+Tab 56, 106
Dejar, módulo (Leave) 330, 335, 336, 343,
Ctrl+V 56
351
Cuadrícula 59, 81, 104, 339 “Demonio causante de la caída del
Cuadro delimitador de gráfico 71 sistema” 21
Cubo en bandas no acumuladoras (Bucket) Demora 33, 64, 120
349 Demora, botón de 345
Cuenta 17, 77, 124, 131, 319, 391 Demora, módulo de 236, 336, 407
Cuenta, nombre de la 124 Demorar 120
Current Expression 87, 141 Densidad, función normal de 272
Curva de Bézier 103, 105 Derivadas parciales 5
Curvas persistentes en el tiempo 28 Desaceleración 129
Desagrupar (Ungroup) 100, 104
D Desarrollo de plantillax, barra de
herramientas (Tank) 451
DaCosta, J. 5, 607 Descripción predeterminada 61
Data, pestaña 281 Deseleccionar todos (Deselect All) 98
Data Tip 61, 99 Deshacer (Undo) 71, 98, 103, 339
descripciones predeterminadas 61 Despliegue de vista compuesta (Display
descripciones definidas por el usuario 61 Composite View) 103
Datos ad hoc 184 Desviación estándar 574, 575
Datos de entrada de variables aleatorias Detención 24
múltiples y correlacionadas 187 Detención, condiciones de 24, 125
Datos, grupo de 274 Detención secuencial 529
Datos, módulos de 61 Detener, módulo (Halt) 366
almacenaje (Storage) 343 Determinístico 7
Devore, J. 569, 605 Distribución empírica discreta DISC (DP)

Devroye, L. 188, 605 177, 369, 587, 592
DF (grados de libertad) 522, 580 Distribución marginal 576
DHALF 320 Distribución normal conjunta 578
Diagrama de flujo 202 Distribuciones
Diálogo, cuadros de 54 beta 176, 587, 589
Diálogo, forma del 454 de Erlang 176, 587, 593, 595
Dibujo, barra de herramientas 71, 88, 103, de Johnson 587, 596
105 de Poisson 369, 587, 599
ancho y estilo de línea (Line Width and de Weibull 115-116, 176, 587, 602
Style) 106 del muestreo 529
arcos (Arcs) 103, 105 empírica continua 177, 587, 590
cajas (Box) 103, 106 empírica discreta 177, 369, 587, 592
color de fondo de ventana (Window exponencial 19, 35, 62, 115, 118, 176,
Background Color ) 106 184, 587, 593, 594
color de línea (Line Color) 103, 106 gamma 176, 587, 593, 595
color de texto (Text Color) 106 lognormal 176, 587, 597
curvas de Bézier 103, 105 normal 39, 65, 176. 185, 580, 587, 598
elipse (Ellipse) 103, 106 triangular 35, 65, 115, 176, 184, 587, 600
estilo de línea (Line Style) 106 uniforme 65, 176, 184, 587, 601
fondo (Background) 103 Distribuciones conjuntas 576
línea (Line) 103, 105 Distribuir (Distribute) 100
mostrar dimensiones (Show Doble clic 54
Dimensions) 103, 107 Documentación 48, 551
Donno, L. 4, 607
polígono (Polygon) 103, 106
Dos muestras t, prueba (Two-Sample-t)
polilínea (Polyline) 103, 105
276, 522
rellenar (Fill) 103
Dstat ID 320
rellenar color (Fill Color) 106
Dstats, elemento de 250
rellenar patrón (Fill Pattern) 103
Duplicar (Duplicate) 98
texto (Text) 103, 106
Duplicar entidades 408
Dinámicos 7
Duplicar escenario (Duplicate Scenario) 279
Discos 54
Duraciones 136, 137, 231
Discretas 7
DXF, formato 98, 306
Diseño experimental 48, 531
Diseño, ventana de diálogo de 453
E
caja de herramientas (Toolbox) 453
explorador de operandos (Operand Ecuaciones diferenciales 468, 492
Explorer) 453 métodos 4
propiedades de diseño (Design Edición de excepciones (Edit Exceptions) 103
Properties) 453 Edición de patrones de tiempo (Edit Time
Dispersión, búsqueda de 283 Patterns ) 103
Distancia 105 Edición, error de 165
Distancia, botón de 338 Edición, menú de 98, 439
Distancia más corta, regla de la 333, 335, copiar (Copy ) 98
357 cortar (Cut) 98
Distancia más larga (Largest Distance) 333, de-seleccionar todos (Deselect All) 98
335, 357 deshacer (Undo) 98
Distancia, módulo de 338, 339 duplicar (Duplicate) 98
Distancias 339, 341, 352 encontrar (Find) 98
Distribución acumulada 39 imágenes de entidad (Entity Pictures) 98
Distribución acumulada, función de (CDF) insertar nuevo control (Insert New
512, 573, 575 Control) 99
Distribución empírica continua CONT insertar nuevo objeto (Insert New
(CP) 177, 587, 590 Object ) 99
liga OLE (OLE Link) 98 Empaque 58

ligas (Links) 99 Empate, ruptura del 220
objeto (Object) 99 Emulación 459
pegar (Paste) 98 En vacío 25
pegar Liga (Paste Link) 98 Encontrar (Find ) 98, 128
programas calendario (Calendar Energizado y libre 398
Schedules) 98 Enfocar (Zoom) 99, 103, 104
propiedades (Properties ) 99 Enfocar acercamiento (Zoom In) 59, 129
rehacer (Redo) 98 Enfocar alejamiento (Zoom Out) 59, 129,
seleccionar todos (Select All) 98 148
Edición, modo de 74, 109 Enrutamiento 327
Editar vía caja de diálogo (Edit via Dialog) Enter, módulo 330, 336, 351, 352
136, 137 Enteros 62
Editor de imágenes (Picture Editor) 85, 150 Entidad, módulo de (Entity) 61, 63, 83, 126
Editor de Visual Basic (Visual Basic Editor) Entidades 20
104, 421 en espera 375
Editor gráfico de programas de eventos “falsas” 21
(Graphical Schedule Editor) 136, 137 formación de lotes 375
Educational Lab, paquete 449 Entidades, llegada de, lectura desde un
Efecto 532 archivo de texto 405
Ejecución, controles de la 103 Entidades por arribo (Entities per Arrival)
Ejecución, duración de la 24, 126, 131 63, 119
Ejecución, terminación de la 409 Entidades “simuladas” 21
Ejecutar simulación (Go) 73, 108, 128, 130, Entidades, transferencia de, restringida por
279, 354 los recursos 328, 357
Elemento continuo (Continuous Element) Entity JobStep (IS), atributo 295
468, 492 Entrada 81
Elemento CStats (CStats Element) 496 Entrada aleatoria 34, 173
Elemento de atributo (Attributes, Element) Entrada, análisis de la 172
248, 343 Entrada, datos de 174
Elemento de estaciones (Stations Element) Entrada, distribución de probabilidad de
482 la 34
Elemento de expresiones 248 Entrada, punto de 68, 81
Elemento de parámetros (Parameters Entrega, demora de la 245
Element) 588 Enviar (Send) 98
Elemento de resultados (Outputs Element) Equipo original, fabricante del 536
251 Erlang ERLA (ER), distribución de 176,
Elemento de semilla (Seeds Element) 510 587, 593, 595
Elementos 11, 58, 247 Error cuadrático mínimo 180
Elementos de entidades (Entities Element) Error Tipo I (Type I Error) 583
248 Error Tipo II (Type II Error) 584
Elementos de tiempo de corrida, ventana Error Tipo III (Type III Error)
de 169 Esc, tecla 108, 129
áreas activas (Active Areas) 169 Escala, parámetro de 116
estadísticas (Statistics) 169 Escalera mecánica 328, 349
filas (Queues) 169 Escalera por condición (Scan for
procesos (Processes) 169 Condition) 378
recursos (Resources) 169 Escanear la fila 381
variables (Variables) 169 Escenario 277, 279
Elementos, panel de (Elements, panel) 11, Escenario, propiedades del 278
202, 244, 247, 342, 343, 393, 510 Escenarios “azules” 280
Eliminación de errores 108, 506 Escenarios “rojos” 281
Elipses 103, 106 Escritorio, modelo de 4
Embeddeds, colección de (VBA) 440 Espacio 104
Espacio de almacenamiento intermedio Estructura numérica 16

382 Etiqueta 396, 432
Espacio muestral 570 Evento 23, 25, 26, 570
Espacio mundial 58 calendario 23, 25, 26, 467
Especificación funcional 553 futuro 23
Espera de tiempo máximo en la fila 17 orientación 32
Espera, líneas de 15 registro 23
Esperanza 573 Evento futuro 23
Esperar (escanear por condición) (Hold Evento nulo 571
(Scan for Condition) ) 400 Evento vacío 571
Esperar (Wait) 134, 135, 139, 231 Eventos discretos, modelos de 465
Esperar, módulo (Hold) 377, 378, 379, Eventos discretos, simulaciones de 33
399, 400 Eventos, proceso de 515
Estación 105, 161 Excel 40
Estación, atributo (Station) 295 construcción de diagramas de
Estación, módulo (Station) 157, 158, 302, resultados (VBA) 442, 444
330, 384 macro 420
Estacionamiento (Parking) 105 Experimento 569
Estacionamiento (Parking), botón de 339 Experimento, archivo del 310
Estación-demorar-liberar (Station-Delay- Exponencial EXPO (EX), distribución 19,
Free) 336 35, 62, 115, 118, 176, 184, 587, 593,
Estaciones 156 594
Estaciones animadas 161 Exportar el informe 75
Estaciones, símbolos formadores de 157 Exportar modelo a base de datos (Export
Estadística 569, 580 Model to Database) 100
contador 76, 77, 131 Expresión 137, 140, 241
de cuentas 17, 76, 77, 131, 319 Expresión de Gráfico (Plot Expression),
de tiempo continuo 76, 77 diálogo 70
de tiempo discreto 76, 77 Expresión, módulo de 199, 241, 298
dstat 319 Expresiones 199
persistente en el tiempo 17, 76, 77, 131,
319 F
salidas 131
Estadística de entidades 68 F10, tecla 108
Estadística de parámetros discretos 17 F4, tecla 128
Estadística de tiempo continuo 77 F5, tecla 108, 128, 279
Estadística de tiempo discreto 17, 77 Factor de enfoque (Zoom Factor) 99
Estadística, módulo de (Statistic) 140, 242, Factores 532
243, 250, 268, 317, 377, 381 Factorial, diseño 532
Estadística, recolección 131 Factory Analizer 100
Estadísticas persistentes en el tiempo 17, Falla basada en el conteo 138
76, 77 Falla basada en el tiempo 138
Estado, barra de 56, 58, 99, 129 Falla, módulo de 67, 138, 385
Estado estacionario 79, 131, 266, 293, 312, Falla, nombre de la 139
320, 516, 529 Fallar cuando (Fail When) 139
Estado estacionario, simulación de 200, Fallas 133, 134, 138, 383, 385
266, 312 Fallido (Failed) 134, 147
Estado fallido 142 Farrington, P. 535, 605
Estático 7 Fast-Forward 108, 109, 129, 142
Estilo de línea (Line Style) 106 F, distribución 582
Estimación puntual 581 Fecha y hora de comienzo (Start Date and
Estimador, eficiencia del 581 Time) 72
Estimar 581 Feria del condado 401
Estocástico 6, 7 Ferris, G.W.G. 401
Estructura lógica 15 Ferris, rueda de 401
FIFO (PEPS, primeras entradas primeras George, T. 5, 607

salidas) 15, 67, 217, 329 Gibson, R. 535, 605
Fila, animación de la 67, 83, 122 Girar 104
Fila compartida 220, 329 Girod, O. 543, 553, 565
Fila, disciplina en la 48 Glover, F. 287, 605
Fila, módulo (Queue) 61, 67, 84, 140, 219, Goldsman, D. 282, 321, 535, 605, 607
343 Gossett, W. S. 9
Fila, nombre de (Queue Name) 122, 140 GPSS 10
Fila, posición en la 373 Grabador de macros (Macro Recorder)
Fila, rango en la 395 428
Fila-requerir-demorar-transportar (Queue- Grabar estadísticas de entidades (Record
Request-Delay-Transport) 342 Entity Statistics) 125
Filas 15, 22 Grabar macro, barra de herramientas 104
Filas, teoría de 4, 19 Grabar, módulo (Record) 60, 117, 124, 208,
Fin (End) 109 372, 379
Fin, botón 74 Grados de libertad (DF) 36, 522, 580
Firmemente acoplado 359, 382, 384 Graficar (Plot) 69, 104, 154, 256, 314
Fishman, G. 319, 605 Gráficas 105
Fit, menú 179 Gráficas, archivo de 88
Flechas conectoras (Connector Arrows) 99 Gráficas dinámicas 85
Flip 100, 104 Gráfico de caja y dispersión 280
Flujo, módulo de (Flow, module) 487, 489 Gross, D. 244
Fondo 103 Grúas de puente 328
Forgionne, G. 6, 605 Grupo permanente 376
Forma, parámetro de 116 Guardar 83, 103
Formación de bloques 532 Guía de desarrollo de plantillas de
FORTRAN 9, 12 Arena (Arena Template Developer’s
Fox, B. 523, 605 Guide) 449
Frecuencia 146 Guías (Guides) 60, 81
Frecuencias 140, 385, 389
Frecuencias, estadística de 133, 140 H
Frecuencias, informe de 146, 390 H0 583
Frecuency ID 391 H1 583
Fronteras del sistema 538 Hacer clic 54
FRQTIM 391 derecho 54, 79
Función objetivo 39 doble 54
Funciones matemáticas 367 Hacer mientras (Do-While) 396
máximo (MX) 374 Hallar el error 165
mínimo (MN) 374 Harpell, J. 6, 605, 606
Herramienta, punta de la 107, 278
G
Herramientas, menú de 99, 421
Gamma, función 595 Arena News Flash 99
Gamma GAMM (GA), distribución 176, Arena Symbol Factory 99, 109
587, 593, 595 AVI Capture 100
Ganchos, líneas de 398 Contact Center 99, 100
Ganeshan, R. 535, 606 Export Model to Database 100
Gass, S. 244 Factory Analyzer 100
Generación de variables estadísticas Import Model from Database 100
aleatorias 34 Input Analyzer 99
continuas 513 Macro 100
discretas 511 Model Documentation Report 100
Generador congruencial lineal (LCG) 506 Options 100
Generador recurrente múltiple combinado OptRequest para Arena 100
(CMRG) 509 Output Analyzer 99
Process Analyzer 99 vista general de categoría (Category

Report Database 100 Overview) 74, 268
Hipótesis alternativa 583 Inicializar el sistema (Initialize System) 243
Hipótesis nula 583 Inicializar entre réplicas (Initialize
Hipótesis, pruebas de 276, 583 Between Replications) 266, 267
Histograma 178, 180 Inicializar estadísticas (Initialize
Hogg, R. 569, 606 Statistics) 243
Hoja de cálculo, vista de 60, 63 Inicializar modelo 423
Hojas de cálculo 14, 38, 53 Inmovilización por coacceso 360
Horas por día 72 Ins, tecla 80
Humus 526 Insertar bloque (Insert Block) 395
Insertar control (Insert Control) 278
I Insertar gráfica (Insert Chart) 280
Insertar nuevo control (Insert New
Idéntico 35
Control) 99
Identificación de almacenaje (Storage ID)
Insertar nuevo objeto (Insert New
344
Object ) 99
Identificadores 148
Insertar respuesta (Insert Response) 278
Identificar mejores escenarios (Identify
Instalación del software 603
Best Scenarios) 280
Instituto de ingenieros industriales
Ignorar 134, 139, 231
(Institute of Industrial Engineers) 1,
IID 36, 266, 267, 579 567
IIE/RA, concurso de simulación de 567 Insuficiente 79, 131, 319, 530
Imagen en estado ocupado (Busy Picture) Integración 13
85 Integración, algoritmo de 468
Imagen inicial (Initial Picture) 83, 126 Integración de aplicaciones de escritorio 403
Imagen, nombre de la 152 Integración en tiempo real 457
Imagen.Bola Azul (Picture.Blue Ball) 83 Integration, barra de herramientas 104
Imagen.Reporte (Picture.Report) 126 editor de Visual Basic (Visual Basic
Imágenes, biblioteca de 85, 98, 150, 152 Editor) 104
Imágenes de entidades 98, 127, 150, modo de diseño en VBA (VBA Design
164 Mode) 104
Implementación 537 módulo de transferencia de datos
Importación (Module Data Transfer ) 104
archivo de dibujos Viso 98 Interacción de corrida, barra de herra-
dibujos CAD 98 mientas (Run Interaction) 104, 108,
gráficas 105 165, 171
Importar modelo de base de datos (Import animar conectores (Animate
Model from Database) 100 Connectors) 104
Impresión 98, 107 checar módulo (Check Model) 104
Imprimir (Print) 75, 103 comando (Command) 104
Inactivo (Inactive) 134 observar (Watch) 104
Incontablemente infinito 574 pausa (Break) 104
Independencia 576 pausa e ir a módulo (Break and
Independiente 35, 571, 578 Module) 104
Independiente e idénticamente distribuidas Interrupciones 134
(IID) 36, 266, 267, 579 Intersección 105, 570
Index 102 Intervalo de confianza 36, 42, 79, 131, 268,
Informe 131, 550 271, 276, 281, 316, 318, 521, 525, 530, 581
Informes 57, 74, 126, 143, 172 en la proporción 583
categoría por réplica (Category by en la razón de dos desviaciones
Replication) 74, 267 estándar 583
frecuencias (Frequencies) 390 en la razón de dos variancias 582
recursos (Resources) 74 para la desviación estándar 582
SIMAN, resumen 78, 79 para la media 581
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
Máximo, función matemática (MX) 368, 374 ModelLogic_UserFunction (VBA) 424

Máximo número de ramificaciones (Max ModelLogic_VBA_Block_Fire (VBA) 424
Number of Branches) 254 Modelo 3
Media 573 eliminación de errores 108
Medias por intervalos o lotes de datos en miniatura 4
131, 318, 524, 530 estructura lógica 15
M/M/1 19, 49 estructura numérica 16
Menú de organización de objetos lógica 4
(Arrange, menu ) 100 matemático 4
alinear (Align) 100 Modelo abierto 103
traer objeto al frente (Bring to Front) Modelo, archivo del 310, 421
100 nuevo 54
Menús 54, 97 Modelo estático 38
archivo (File) 98 Modelo lógico 4
ayuda (Help) 102 Modelo matemático 4
editar (Edit) 98 Modelo nuevo 103
ejecutar (Run) 101 Modelo nuevo, archivo del 54
herramientas (Tools) 99 Modelo, objeto del (VBA) 426
objeto (Object) 101 Modelo, representación del 47
organizar (Arrange) 100 Modelo, ventana del 56
ventana (Window) 101 nueva 80
vista (View) 99 vista de hoja de cálculo 56, 57
Método abreviado 54 vista del diagrama de flujo 56, 57
Método estadístico 273 Modelos
Métodos numéricos 514 3-1: Navegación a través de un modelo
Métrica, del rendimiento 539 existente 62
Métrica para el éxito 537 3-2: Procesamiento en serie 90
Microsoft® Access 77 3-3: Procesamiento en paralelo 92
Microsoft® Office 420 3-4 y 3-5: Efecto de la variabilidad del
Microsoft® Windows® 53 tiempo de tarea 95
Miembros 232 4-1: Montaje electrónico y sistema de
Miller, S. 543, 565 prueba 115
Mínimo, función matemática (MN) 251, 374 4-2: Montaje electrónico mejorado y
Mirar y sentir 53 sistema de prueba 132
MN 256, 374 4-3: Mejora de la animación 147
Model Documentation Report 61, 100 4-4: Montaje electrónico y sistema de
Modelado prueba con movimientos de piezas
cuantitativo 173 156
estructural 173 4-5: Cuenta de observaciones normales
Modelado continuo con VBA 498 negativas 185
Modelado, enfoque del 116 5-1: Sistema simple de centro de
Modelado estructural 172 atención telefónico 196
Modelado, flexibilidad del 11 5-2: Sistema mejorado de centro de
ModelLogic_OnClearStatistics (VBA) 424 atención telefónico 225
ModelLogic_OnKeystroke (VBA) 424 5-3: Más medidas del rendimiento de la
ModelLogic_RunBegin (VBA) 423, 435 salida 238
ModelLogic_RunBeginReplication (VBA) 5-4: Simulación de inventario (s,S) 244
424 6-1: Intervalos de confianza 267
ModelLogic_RunBeginSimulation (VBA) 6-2: Alcance de la precisión deseada
423, 443 270
ModelLogic_RunEnd (VBA) 425 6-3: Normalidad de la salida 272
ModelLogic_RunEndReplication (VBA) 6-4: Comparación de dos escenarios 273
425, 448 6-5: Uso del analizador de procesos
ModelLogic_RunEndSimulation (VBA) (Process Analizer) 278
425, 448 6-6: Uso de OptQuest 283
7-1: Sistema pequeño de fabricación 293 de estado estacionario 516, 529

7-2: Determinación del tiempo de terminante 516
calentamiento del sistema (Warmup) Modelos continuos/discretos 469
313 Modelos, ejecución de 108
7-3: Replicaciones truncadas 316 Modulación de transferencia de datos,
7-4: Medias en lotes 317 asistente de (Module Data Transfer)
8-1: Transferencias restringidas por el 104
recurso 329 Módulo de agrupamiento en lotes (Batch,
8-2: Transportadores 334 module) 60, 374, 377, 380
8-3: Animación refinada del Módulo de conjunto avanzado (Advanced
transportador 341 Set Module) 232
8-4: Transportadores de banda no Módulo de disposición (Dispose, module)
acumuladores 350 60. 68, 85, 117, 124, 208
8-5: Transportadores de banda Módulo repartir (Allocate, Module) 365,
acumuladores 355 366
9-1: Almacenamientos intermedios Módulo, arrastrar y soltar 81
finitos en las estaciones (Stations) 360 Módulo, definición de lógica del 452
9-2: Piezas que permanecen en el Módulos 57, 60
transportador de banda en el curso Módulos de diagrama de flujo (Flowchart,
del proceso 364 modules) 60
9-3: Modelo de servicio con rechazo activar (Activate) 366
(Balking) y abandono (Reneging) 367 asignar (Assign) 60, 117, 120, 343, 385
9-4: Ejemplo de proceso de formación buscar (Search) 373, 374, 399
de lotes 376 conjuntos (Sets) 228
9-5: Sistema de producción firmemente crear (Create) 60, 62, 81, 117, 119, 203,
acoplado 384 370, 377, 527
9-6: Adición de estadísticas de estado dar entrada (Enter) 330, 336, 351, 352
de las piezas 390 decidir (Decide) 60, 111, 117, 122, 123,
10-1: Lectura y escritura de archivos de 208
datos 403 dejar (Leave) 330, 335, 336, 343, 351
10-2: Lectura de las llegas de entidades demorar (Delay) 236, 336
desde un archivo de texto 405 detener (Halt) 366
10-3 y 10-4: Lectura y escritura de disponer (Dispose) 60, 68, 85, 117,
Access y Excel 409 124, 208
10-5: Presentación de elecciones de esperar (Hold) 377, 378, 379, 399, 400
llegadas 431 estación (Station) 157, 158, 330, 384
10-6: Grabación y construcción de estadística (Statistic) 243
gráficas de resultados del modelo 442 expresión (Expression) 199
11-1: Sistema continuo simple 466 formar lotes (Batch) 60, 117, 120, 343,
11-2: Establecimiento de interfaz entre 385
lógica continua y discreta 469 grabar, registrar (Record) 60, 117, 124,
11-3: Carga de carbón con enfoque 208, 372, 379
continuo 477 liberar (Free) 366
11-4: Carga de carbón con proceso de localizar (Allocate) 365, 366
flujo (Flow Process) 487 mover (Move) 365, 366
11-5: Horno con foso de proceso (Process) 60, 64, 83, 117, 122,
recalentamiento 491 123, 336
12-1: Números aleatorios comunes no remover (Remove) 374, 375, 399
sincronizados 517 rutear (Route) 157, 158, 301, 303, 330,
12-2: Números aleatorios comunes 384
sincronizados 520 secuenciar (Sequence) 297
12-3: Muestreo secuencial, terminante señal (Signal) 380, 399, 400
525 separar (Separate) 60, 371, 374, 380, 385
12-4: Muestreo secuencial, de estado solicitar (Request) 336, 365
estacionario 530 soltar (Release) 330
tomar (Seize) 329, 385, 386 Ningún dato 183

transportar (Transport) 336, 365 Nivel 466, 532
Módulos del panel de procesos básicos Nivel, animación del (Level) 256
(Basic Process) Nivel de confianza 271, 581
agrupar en lotes (Batch) 201 No correlacionado 131
asignar (Assign) 201 Nombre de estación (Station Name) 158
crear (Create) 201 Nombre del recurso (Resource Name) 64,
decisión (Decide) 201 142, 232, 330
disponer (Dispose) 201 Nombres 61
grabar (Record) 201 Normal NORM (RN), distribución 39,
proceso (Process) 201 65, 176, 185, 580, 587, 598
separar (Separate) 201 desventaja de la 185
Montacargas de horquilla 333, 356, 357 No sesgada 581
Moore, “ley” de 510 NQ 69, 86, 140, 154, 171, 368, 373
Morgan, B. 9, 606 NR 71, 87, 171
Morgan, C. 6, 606 NREP 525, 527, 528
Mosaico 56, 101 NSPP 515
Mostrar, botón (Show) 59 NSTO 369
Mostrar, comando (Show) 354 Nuevo punto de pausa, botón de (New
Mostrar dimensiones (Show Dimensions) Breakpoint Button) 167
103, 107 Número de réplicas 72, 131, 266
Mover, módulo (Move) 365, 366 Numero de unidad (Unit Number) 336
MR 171 Números aleatorios 39, 505, 506
MREP 525, 527, 528 Números aleatorios comunes (CRN) 42,
M/U/1, Fila 44 517, 520
Muestra 579 Números aleatorios independientes 521
Muestra aleatoria 579 Números aleatorios, corriente de 144, 519,
Muestra, desviación estándar de la 36 521, 523, 525
Muestra, estadísticas de la 580 corriente predeterminada 510
Muestra, media de la 36, 269, 580 Números aleatorios, generador de (RNG)
Muestra, proporción de la 580 505, 521
Muestra, tamaño de la 269 Números aleatorios, sincronización de los 519
Muestra, variancia de la 580 Números ocupados 28
Muestreo 579 Números seudoaleatorios, generadores
secuencial 9 de 506
Muestreo correlacionado 520 Números reales 62
Muestreo, distribuciones de 579, 580 Num Reps 280
Muestreo independiente 522
O
Muestreo secuencial 9, 524, 525
Múltiples (Tuples) 576 Object, menú
Musselman, K. 535, 607 animar al color de fondo del escritorio
MX 250, 368, 374 (Animate At Desktop Color Depth)
101
N animar conectores (Animate
Connectors) 101
N alternativas por oportunidad (N-way by autoconectar (Auto-Connect) 101
Chance) 208 conectar (Connect ) 101
Nance, R. 10, 12, 607 conexión inteligente (Smart
Navegación, panel de (Navigate, panel) Connection) 101
Navegar (Navigate) 57 Objetivo del rendimiento 539
botón Thumbnail 57 Objeto 99
NC 243 Objeto de estación (Station Object) 157
Nelson, B. 282, 524, 607 Objeto, descripción de propiedades de
Next Label 396 (Object Properties Description) 61
Objeto, modelo del 420 P

Objeto, nombre del 121
Objeto, propiedades del 99 Palabras, procesador de 14, 53
Objetos (VBA) 420, 425 PAN 277, 279, 280, 283, 288, 325
colecciones 425 Panel avanzado de transferencia
métodos 420 (Advanced Transfer, panel) 11, 58,
navegación 426 60, 158, 201
propiedades 420, 425 Panel de bloques (Blocks, panel) 11, 195,
Objetos dinámicos 20 201, 244, 342, 370, 393
Observar (Watch) 104, 109 Panel de procesos avanzados (Advanced
Observar, ventanas (Watch) 167 Process, panel) 11, 58, 67, 138, 195,
201, 222, 242, 370
Ocioso (Idle) 134, 147
Panel de procesos básicos (Basic Process,
Ocupada 25
Panel) 11, 57, 80, 117, 195, 201
OEM 536
Panel, ícono del 451
OLE para control de proceso 458
Paneles 57, 80
OLE, vínculo 98
adjuntar 98
Opción secuencial 301
adjuntar plantilla (Attach Template) 80
Opciones 58, 100
bloques (Blocks) 11, 58, 195, 201, 342,
Opciones, botones de 54
370, 393
Opciones de gráficos (Chart Options) 281
elementos (Elements) 11, 58, 202, 342,
Operando 450
343, 393, 510
Operando, hacer referencia al 455
navegar (Navigate) 57
Operando, nombre del 438 proceso avanzado (Advanced Process)
Operando oculto (Hidden Operand) 454 11, 58, 67, 138, 195, 201, 222, 242, 370
Operario, capacitación/certificación del 460 proceso básico (Basic Process) 11, 57,
Operario, diseño de la interfaz del 460 80, 117, 195, 201
Optimización 39, 282 quitar 98
Option Explicit, instrucción (VBA) 443 transferencia avanzada (Advanced
OptRequest para Arena 100, 265, 283, Transfer) 11, 58, 60, 158, 201
287, 288, 377, 381 Panorama general de un estudio de
OptTek Systems Inc. 283 simulación 47
Orden de magnitud, aproximación de la 19 PAN, proyecto 277
Orden preferido, regla (Prefered Order) Pantalla de impresión (Print Screen) 57, 107
304, 335 Pan/zoom 59
Organizar barra de herramientas Paralización mutua 360
(Arrange) 71, 88, 104 Parámetros 581
agrupar (Group) 104 Pares concordados (Matched Pairs) 520
alinear (Align) 104 Paso 108, 129, 309
desagrupar (Ungroup) 104 Patrón de rellenado (Fill Pattern) 103
espaciar horizontal o vertical (Space) Pausa 73, 108, 129, 354
104 Pausa (Break) 104
mandar objeto al fondo (Send to Back) Pausa de páginas (Page Breaks) 99
104 Pausa en módulo 104, 109, 168
mover objeto vertical u horizontal (Flip) PDF (función de densidad de
104 probabilidad) 513, 574, 575
rotar (Rotate) 104 PDF (función de densidad de
traer objeto al frente (Bring to Front) 104 probabilidad) conjunta 576
Organizar íconos (Arrange Icons) 101 PDF marginal 577
Origen (Home) 59 Pedido, costo del 245
ORUNAVG 532 Pegar a guías de diagrama de flujo (Glue
ORUNHALF 525, 527 to Guides ) 60, 99
Otro (Other) 299 Pegar (Glue) 81
Output ID 525 Pegar liga (Paste Link) 98
OVALUE 251 Pegar (Paste) 54, 56, 98, 103
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
Punto crítico 582 Recursos movibles 328

Punto de referencia de entidades 150 Recursos, programa 133, 134, 136
Punto de viaje (Ride Point) 334 Recursos traslapados 359, 382
Puntos de historia (History Points) 70 Recursos, unidad 22
Puntos de interrupción (Break Points) 109 Red 105
Puntos de interrupción, ventana de 167 Redondeo, error por 16
Reducción en la variancia 522
Q Registro de información 23
Regla de cálculo 309, 347
QPick Block 394, 395
Regla de clasificación en la fila 378
¿Qué es esto? (What’s This) 102
primeras entradas, primeras salidas
Quincunx 111
(FIFO) 378
Quitar 80, 98, 103
Regla de falla (Failure Rule)
R dejar inconcluso (Preempt) 139
esperar (Wait) 139
Radio, botones de 54 ignorar (Ignore) 139
Ramaswamy, S. 14, 607 Reglas 59, 81, 99, 104
Random Numbers Fall Mainly in the Regulador de tomas, módulo (Seize
Planes, Marsaglia 1968 508 Regulador) 488, 489
Rango 142 Regular liberación, módulo (Release
Rapidez estimada, función de 515 Regulador) 488
Rapidez, función de 515 Regular, módulo (Regulate) 330
estimada 515 Rehacer (Redo) 98, 103
Rapidez, función de, seccionalmente cons- Reingeniería de procesos en negocios 14
tante 186 Reisenrad 401
Rasmussen, J. 5, 607 Rellenar (Fill) 103, 106
Rastro 26 Rellenar área (Fill Area) 71
Ratón 54 Rellenar color (Fill Color) 106
Razones 466 Rellenar color, botón de (Fill Color
Realidad virtual 14 Button) 88
Realizaciones 20, 267, 505, 579 Reloj 24
Recordatorio 506 Remoción de un panel de plantillas 80
Recurso 64, 84, 104, 124, 306 Remolcar, cadenas para 398
unidad 22 Remover bloque, módulo (Remove Block)
Recurso, animación del 68, 84 374, 375, 395, 399
Recurso, botón 84 Rendimiento, estimación del 309
Recurso (Resource) 104 Rendimiento, métrica del 539
Recurso, módulo (Resource) 61, 64, 66, Rendimiento, objetivo del 539
84, 329, 331, 385 Renunciar 366, 367, 369
Recurso ocioso, imagen de 25, 134, 147 Repartir-mover (Allocate-Move) 336
Recurso, punto de referencia del 152 Replicación 35, 38, 79, 110, 316
Recursos 22 independiente 266
traslape 359 longitud 126, 299, 530
Recursos, capacidad de 328 parámetros 72, 89
Recursos, conjunto 228 truncada 524
Recursos, diálogo de (Resources) 64 Replicación, duración de la 72
Recursos, estados 134, 383 Replicaciones independientes 266
descompuesto (Failed) 134 Replicaciones truncadas 316, 524
inactivo (Inactive) 134 Replicar, elemento (Replicate) 250
ocioso (Idle) 134 Reportar base de datos (Report Database)
ocupado (Busy) 134 100
Recursos, fallas de los 133, 138 Reportar estadísticas 64
Recursos, imágenes de los 73, 152 Reporte por réplica de categoría 74, 267, 318
Recursos, informe de 74 Reportes, panel de (Reports) 74
Report Label 140 cíclica 304

Requerir (Request) 333, 337 orden preferido 304
Requerir, bloque (Request Block) 336, Seleccionar todos (Select All) 98
344, 365 Semiancho 36, 79, 131, 268, 169, 318, 319,
Requerir-demorar-transportar (Request- 525, 528
Delay-Transport) 336 Semiancho del intervalo de confianza 131
Requisito 243 Semiconductores 14
Research, paquete 449 Sensible a mayúsculas y minúsculas, 59,
Resolución, técnica de 539 89, 120
Respuestas 277, 532 Sensor, módulo 487
Restricciones 243 Señal, módulo (Signal) 380, 399, 400
Resultados, estadística de 131 Señal (Signal) 376, 377
Resumen de entidad, diálogo de 129 Señalizar módulo activo (Highlight Active
Retícula 508 Module ) 109, 166
Retirar plantilla (Template Detach) 55 Separar, módulo (Separate) 60, 371, 374,
Revisar errores (Review Errors) 109, 166 380, 385, 408
RNG 505 Separar pantalla (Split Screen) 57, 99, 103
Rock, música de, irritante 197 SEQ 345
Rótulo en X (X-Labels) 71 Servicio, tiempos de 16
Rótulos en Y (Y-Labels) 71 Sesgada 313
Ruta 105, 156, 162, 294, 327, 330 Shannon, R. 6, 58, 109, 182, 258, 311,
Ruta, camino de (Route) 157 356, 394, 607
Ruta, diálogo de (Route) 162 Shewhart, Walter A. 9
Ruta, módulo (Route) 157, 158, 301, 303, Shift+F5 109
330, 384 Shift, tecla 54, 105
Rutas animadas 161 SIMAN 10, 11, 12, 33, 58, 101, 109, 140,
195, 197, 201, 244, 310, 356, 396
S SIMAN, objeto (VBA) 426
Simard, R. 509, 606
Sadowski, R. 58, 109, 182, 258, 311, 356, SIMSCRIPT 10
394, 535, 607 Simulación 1
Salida 25, 81, 98, 349 computadora 5
Salida aleatoria 6, 34 continua 7
Salida, análisis estadístico de la 144, 312 continua-discreta mixta 7
Salida, punto de 68, 81 de estado estacionario 200, 266, 293,
Salvar atributo (Save Attribute) 304 312, 320
Sargent, R. 12, 321, 535, 607 desventajas de la 6
Scheffé 584 determinística 7
Schmeiser, B. 319, 607 dinámica 7
Schrage, L. 523, 605 discreta 7
Schriber, T. 60, 607 especificación 540
Secuencia, atributo (Sequence) 295 estática 7
Secuencia de números aleatorios, estocástica 7
asignación de 520, 521 estudio 47
Secuencia, módulo (Sequence) 295, 297, 298 evento discreto 33
Secuencias 157, 198, 293, 295, 300, 327, futuro de la 13
330, 345 historia de la 12
Secuencias de números aleatorios 510 lenguajes de 10
Segmento 105 marco de tiempo 265
Segmento, botón (Segment) 353 panorama general de un estudio 47
Segmento, diálogo (Segment) 353 reloj 22, 24
Segmento, módulo (Segment) 352 terminante 200, 266, 525
Seila, A. 535, 607 Simulación, banco de pruebas de 459
Selección, reglas de 335 Simulación con éxito 535
aleatoria 304 Simulación con hojas de cálculo 38
Simulación, lenguajes de 10 Terminación, condición de 530

Simulación mecanística 20 Terminante 266, 516
Simulación por computadora 5 Termómetros, animaciones de 256
Simulación, tabla 42 Texto 103, 106, 155
Simulación terminante 199, 266, 525 Texto, archivo de 405
Simuladores 10 Texto, botón (Text) 71, 88
Sincronización 519 THALF 320, 530
de los números aleatorios 519 The Washington Post 1, 543, 553
Sincronizar 523 This Document (VBA) 422
Sistema 2, 535 Thomas, G. 5, 607
ejemplos de 2 Thumbnail, botón 57
juego con el 3 Tiempo de corrida, eventos de (VBA) 422
Sistema, controles del 280 Tiempo de descarga (Unload Time) 350
Sistema, límites del 538 Tiempo de entrega (Lead Time) 245
Sistema, requisitos del 604 Tiempo de espera de la entidad (Entity
Sistema, tiempo del 383 Wait Time) 242
Sistemas continuos 202, 465, 473 Tiempo de espera en la fila 17
Sistemas terminantes 268 Tiempo de funcionamiento en este estado
SKU 296, 544 solamente (Uptime in this State
SLAM 10 Only) 139
SMART, archivos 108 Tiempo de movimiento (Move Time) 330,
Smith, G. 14, 607 336
Smith, J. 14, 607 Tiempo de procesamiento más corto,
Software de alto nivel, prueba de 460 regla del 48
Software, instalación del 603 Tiempo de ruta (Route Time) 158
Song, W. 282, 607 Tiempo en funcionamiento (Up Time)
Sonido, archivo (Sound) (VBA) 439 139, 383
Soporte y entrenamiento (Support and Tiempo entre arribos (Time Between
Training) 102 Arrivals) 62, 118
Stock-Keeping Units (SKU) 296 Tiempo entre llegadas 16
“Student” 9 Tiempo fuera de funcionamiento (Down
Student, distribución de 36, 582 Time) 139, 383
Sturrock, D. 14, 607 Tiempo, persistente en el 131
Subconjunto 570 Tiempo, promedio 17
Subconjunto mensurable 570 Tiempo promedio de espera en la cola fila
Submodelo 64, 103 17, 32
Subsecuencias (Substreams) 510 Tiempo promedio, del número de piezas
Sugerencias, listas de 120 que esperan en la fila 17
Tiempo promedio, duración de, en la fila 32
Suposición 18
Tiempo real 458
Swain, J. 535, 605
Tiempo total promedio en el sistema 32
Swann, J. 282, 607
Tiempo, unidades de 16, 72
Swart, W. 4, 607
Tipo 140, 232, 242
Sweeney, D. 569, 605
Tipo de conexión (Connect Type) 330, 336
Symbol Number (VBA) 445
Tipo de demora 65
T Tipo de destino (Destination Type) 158, 301
Tipo de estación (Station Type) 158, 330
Tabú, búsqueda 283 Tipo de fila (Queue Type) 67
Tamaño continuo del paso 468, 473 Tipo de frecuencia (Frecuency Type) 142
Tamaño mínimo de paso 468 Tipo de gráfico (Chart Type) 280
Tanque, módulo (Tank) 487, 488 Tipos de expresión (Expression Type) 140
TAVG 391, 531 Tiro por la culata 523
t, distribución 36, 582 TNOW 24, 141, 166, 384
Teclado 54 TNUM 391
Terminación 73 Tolerancia 526
Tolerancia al error (Error Tolerante) 280, de camino libre 333

281, 282 guiados 333, 334
Tolerancia continua 473 montacargas de horquilla 333, 356, 357
Tomar, área (Seize) 85, 153 Transportadores de banda continua 328,
Tomar (Seize) 22, 64, 105, 122 347, 349, 360
Tomar demorar (Seize Delay) 120 acumuladores 349, 398
Tomar demorar liberar (Seize Delay no acumuladores 349, 350, 356, 360
Release) 64, 120 Transportadores guiados 333, 394
Tomar, módulo (Seize) 329, 385, 386 Transportadores no acumuladores 349,
Tomar un miembro específico 304 350, 356, 360
Trabajo en proceso (WIP) 110, 313, 537 Transporte 333, 337
Traer objeto al frente (Bring to Front) Transporte bloque de (Transport Block)
100, 104, 307 336, 345, 365
Transferencia (Transfer) Transporter, módulo 334
almacenaje (Storage) 105 Traslapo 274
distancia (Distance) 105 Trayectorias 54
estacionamiento (Parking) 105 Triangular TRIA (TR), distribución 35,
estación (Station) 105 65, 115, 176, 184, 587, 600
intersección (Intersection) 105 Trucos 359
promover vía (Promote Path) 105 TSR, regla 344
redes (Network) 105 Tukey 584
rutear (Route) 105 Type, biblioteca (VBA) 425
segmento (Segment) 105
tomar (Seize) 105 U
transportador (Transporter) 105
Últimas entradas, primeras salidas (PEPS)
(LIFO) 217
Transferencia de estación (Station
Transfers) 156 Unidad 22
Transferencias 156 Unidad de transporte (Transporter Unit) 344
Transferir hacia adentro (Transfer In) Unidades, campo de 62, 65
330, 365 Unidades de tiempo base (Base Time
Transferir hacia afuera (Transfer Out) Units) 16, 70, 72, 75, 126, 299, 485
330, 335, 358, 365 Uniforme UNIF (UN), distribución 65,
Transportador 105, 344 184, 587, 601
Transportador, botón (Transporter) 334 Unión 570
Transportador de banda 349 UserForm (VBA) 431
Transportador de banda continua 347, 397 Usuario definido, descripción del 61
Transportador de banda continua, Usuario especificado 131
estadística del 354 Usuario, interfaz del, controles de la 454
Transportador de banda continua, Utilización 18, 32, 142, 144
módulo de 350 instantánea (Instantaneous) 144
Transportador, permanencia en el 364 programada (Scheduled) 144
Transportador, reglas de selección 333, 344 Utilización instantánea de recursos
aletorio (Random) 335 (Instantaneous Utilization) 144, 193
cíclico (Cyclical) 335, 357 Utilización programada (Scheduled
distancia más corta a una estación Utilization) 144, 146, 193
(Smallest Distance to Station [SDS]) 344 Utilizar color de fondo del sistema
distancia más corta (Smallest Distance) (Use System Background Color) 101
333, 335, 357 Utilizar estas respuestas (Use These
distancia más larga (Largest Distance) Responses) 280
333, 335, 357
orden preferido (Preferred Order) 335
V
Transportadores 328, 333, 334, 365 Vacío y en vacío 16, 312
carretillas 333 Validación 34, 47, 132, 308, 546, 547
carros 333 de nuestro modelo 404
Validez 4, 5 Vehículo guiado automatizado (AGV) 333,

Válido 7 394
Valor 142, 231 Velocidad 336, 365
Valor alto (High Value ) 142 Velocidad de corrida (Run Speed) 126
Valor alto primero (High Value First) 217 Vendedor de periódicos, problema del 38
Valor, combinación de duraciones (Value, Ventana de entidad activa (Active Entity
Duration Combination) 231 Window) 167
Valor de atributo más bajo (Lowest Ventana, menú (Window) 101
Attribute Value Rule) 67 en cascada (Cascade) 101
Valor esperado 573, 575 organizar íconos (Arrange Icons) 101
Valor más bajo primero (Low Value First revestir (Tile) 101
Rule) 217 utilizar color de fondo del sistema (Use
Valor p correspondiente (Corresponding System Background Color) 101
p-value) 181, 584 Verificación 47, 132, 308, 310, 546
Valor semilla 506 Verificar 132
Valores atípicos 182 Versión académica 54
Valores, campo de 62 Viaje a través de Arena (Tour through
Valores en la línea de base 539 Arena) 53
Valores p 181, 584 Viaje de vuelta sin carga 347
Valores, campo de 62 Vía libre, transportadores de 333
Variabilidad 95 Video, lector de 73
Variable 21, 238 Viento 112
acumulador estadístico 23 Vínculos 99
Visio® 306, 420
global 25
Visio, archivo de dibujos 98
Variable aleatoria continua 513, 569, 572,
anterior (Previous) 104
574
coincidir (Snap) 104
Variable, animación de la 154
enfocar acercamiento (Zoom In) 104
Variable global 21, 199
enfocar alejamiento (Zoom Out) 104
Variable, módulo 61, 199, 247, 298, 377
reglas (Rulers) 104
Variables 26, 199
retícula (Grid) 104
locales 21
todo (All) 104
Variables aleatorias 173, 571
vista, barra de herramientas (View) 104
Variables aleatorias discretas 511, 572 vistas nombradas (Named Views) 104
Variables aleatorias distribuidas Vista de región (View Region) 103
conjuntamente 576 Vista, hoja de cálculo de 60
Variables de proceso básico (Basic Process Vista, menu (View) 99
Variables) 140 barra de depuración (Debug Bar) 99
Variables, elemento 247 barra de elementos de tiempo de
Variables estadísticas 511 corrida (Runtime Elements Bar) 99
Variables estadísticas aleatorias 39, 511 barra de estatus (Status Bar) 99
Variables estadísticas antitéticas 9, 523 barras de herramientas (Toolbars) 99
Variables locales 21 capas (Layers) 99
Varianza 516, 573, 575, 582 coincidir con retícula (Snap to Grid) 99
Varianza, reducción de la 42, 516 coincidir objeto con retícula (Snap
estrategias 516 Object to Grid) 59
técnica 9 coincidir (Snap) 99
VBA 194 354 configuración de retícula y
ecuaciones continuas 498 coincidencia (Grid & Snap Settings)
VBA_Block_Fire, evento 447 59, 99
VBA_Block (VBA) 424 Data Tips 99
VBA Design Mode 104 dividir pantalla (Split Screen) 99
VBA, eventos de tiempo de ejecución 422 enfocar (Zoom) 99
VBA, módulo 447 factor de enfocamiento (Zoom Factor)
Vector aleatorio 576 99
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

Simulación Con Software Arena (4a. Ed.) PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Simulación Con Software Arena (4a. Ed.) PDF

Cargado por

Copyright:

Formatos disponibles

S 1 M U l •

Simulación con software Arena

MÉXICO · BOGOTÁ · BUENOS AIRES · CARACAS · GUATEMALA · LISBOA · MADRID

Traducción: María Jesús Herrero, José Hernán Pérez, Francisco Sánchez

SIMULACIÓN CON SOFTWARE ARENA

Prohibida la reproducción total o parcial de esta obra,

DERECHOS RESERVADOS © 2008 respecto a la cuarta edición en español por

Traducido de la cuarta edición de: Simulation with Arena.

Impreso en México Printed in Mexico

Albert, Anna, Anne, Christie y Molly

Diana, Kathy, Melanie y Victoria

Capítulo 1: ¿Qué es la simulación?....................................................................................... 1

Capítulo 2: Conceptos principales de simulación............................................................... 15

2.3.3 Variables (globales)........................................................................ 21

Capítulo 3: Un recorrido guiado a través de Arena............................................................. 53

Capítulo 4: Modelación de operaciones y entradas básicas.............................................. 115

4.1 Modelo 4-1: montaje electrónico y sistema de prueba.......................................... 115

4.3 Modelo 4-3: mejora de la animación.................................................................... 147

Capítulo 5: Modelado de operaciones detalladas................................................................ 195

5.1 Modelo 5-1: un sistema de centro de atención telefónica sencillo......................... 196

Capítulo 6: Análisis estadístico de resultados de las simulaciones terminadas.............. 265

6.1 Marco de tiempo de las simulaciones................................................................... 266

Capítulo 7: Modelado intermedio y análisis estadístico de estado estable ..................... 293

7.1 Modelo 7-1: un sistema pequeño de fabricación.................................................. 293

Capítulo 8: Transferencia de entidades................................................................................ 327

8.1 Tipos de transferencias de entidades.................................................................... 327

Capítulo 9: Un muestrario de aspectos y técnicas adicionales de modelado.................. 359

9.1 Modelado de transportadores continuos usando el panel Transferencia

Capítulo 10: Integración y personalización de Arena............................................................ 403

10.1 Modelo 10-1: lectura y escritura de archivos de datos.......................................... 403

10.2.3 Modelo de objetos de Arena........................................................... 425

Capítulo 11: Modelos continuos y discretos/continuos combinados.................................. 465

11.1 Modelado de sistemas simples discretos y continuos........................................... 466

Capítulo 12: Cuestiones estadísticas adicionales................................................................. 505

12.1 Generación de números aleatorios....................................................................... 505

12.2 Generación de variables aleatorias....................................................................... 511

Capítulo 13: Realización de estudios de simulación............................................................. 535

13.1 Un estudio exitoso de simulación . ...................................................................... 535

Apéndice A: Una especificación funcional para The Washington Post................................ 553

A.1 Introducción........................................................................................................ 553

A.4.1 Entrada del modelo........................................................................ 562

Apéndice B: IIE/RA Problemas de concurso.......................................................................... 567

Apéndice C: Una actualización en probabilidad y estadística.............................................. 569

C.1 Fundamentos de probabilidad............................................................................. 569

Apéndice D: Distribuciones de probabilidad de Arena.......................................................... 587

Apéndice E: Instrucciones de instalación del software académico..................................... 603

E.1 Autorización para copiar el software................................................................... 603

Referencias . ............................................................................................................................. 605

Índice analítico............................................................................................................................ 609

W. David Kelton es profesor en el Departamento de Análisis Cuantitativo y Gerencia de Ope-

Randall P. Sadowski se desempeña actualmente como gerente de producto en Rockwell Auto-

David T. Sturrock es gerente de producto de simulación en Rockwell Automation. Es respon-

Obtuvo su licenciatura en ingeniería industrial por The Pennsylvania State University,

Rockwell Automation proporcionó tiempo, software, hardware, asistencia técnica y estímulo

La presente edición en español fue posible gracias al apoyo de:

1.1.1 ¿Qué se está modelando?

1.1.2 ¿Y si sólo se juega con el sistema?

1.1.3 A veces no se puede (o no se debe) jugar con el sistema

1.1.4 Modelos físicos

1.1.5 Modelos lógicos (o matemáticos)

1.1.6 ¿Qué es lo que se hace con un modelo lógico?

1.2 Simulación por computadora

1.2.1 Popularidad y ventajas