Modelizacion y Simulacion Libro de Practicas Con Simio - Edited

Modelización y Simulación: Libro
de Prácticas con SIMIO
Jeffrey Allen Joines

Stephen Dean Roberts
North Carolina State University
F. Javier Otamendi
Universidad Rey Juan Carlos, Madrid,
ISBN: 978-0-9829782-4-5
Modelización y Simulación: Libro de Prácticas
con SIMIO
Jeffrey Allen Joines
Stephen Dean Roberts
Raleigh, North Carolina
F. Javier Otamendi
Universidad Rey Juan Carlos
Madrid, España
Noviembre 2010
Edición 1.1
Spanish Electronic Book ISBN: 978-0-9829782-4-5
Published by SIMIO, LLC, (http://www.simio.com)
Modelización y Simulación: Libro de Prácticas con SIMIO

Tabla de Contenidos
Los autores ...................................................................................................................................................v
Prefacio: Aprendizaje Activo .................................................................................................................. vii
1ª PARTE: ¿QUÉ HACE A ESTE LIBRO DIFERENTE?................................................................................... VII
2ª PARTE: ¿QUIÉN SE BENEFICIA DE LA ENSEÑANZA ACTIVA?............................................................... VII
3ª PARTE: ¿POR QUÉ ENFATIZAR EN LA “MODELIZACIÓN”? .................................................................. VIII
4ª PARTE: ORGANIZACIÓN DEL LIBRO .................................................................................................... VIII
5ª PARTE: ESTILOS Y FORMATOS UTILIZADOS EN ESTE LIBRO ................................................................ IX
6ª PARTE: RECONOCIMIENTOS .................................................................................................................. X
Capítulo 1 Introducción a SIMIO: La Tienda de Helados ......................................................................1
SECCIÓN 1.1: EL INICIO ..............................................................................................................................1
SECCIÓN 1.2: LA TIENDA DE HELADOS .....................................................................................................3
SECCIÓN 1.3: POTENCIANDO LA ANIMACIÓN ............................................................................................6
SECCIÓN 1.4: VIENDO RESULTADOS ..........................................................................................................8
SECCIÓN 1.5: COMENTARIO .....................................................................................................................10
Capítulo 2 Modelizando Distancias y Desplazamientos: Un Aeropuerto, ............................................11
SECCIÓN 2.1: DESARROLLANDO EL MODELO ...........................................................................................11
SECCIÓN 2.2: UTILIZANDO LA BIBLIOTECA DE DISEÑO 3D DE GOOGLE .................................................12
SECCIÓN 2.3: EXAMINANDO LOS RESULTADOS .......................................................................................13
SECCIÓN 2.4: USANDO EXPERIMENTOS....................................................................................................14
Capítulo 3 Caminos con Desvíos, Tablas de Ritmos y Dependencias entre Entidades:
Aeropuerto bis ........................................................................................................................................16
SECCIÓN 3.1: ELECCIÓN DE CAMINOS .....................................................................................................16
SECCIÓN 3.2: CAMBIANDO EL RITMO O PATRÓN DE LLEGADA ...............................................................18
SECCIÓN 3.3: DIFERENCIANDO ENTRE ENTIDADES: TABLAS DE DATOS .................................................19
SECCIÓN 3.4: MÁS SOBRE RUTAS ............................................................................................................21
SECCIÓN 3.5: HORARIOS Y TURNOS DE TRABAJO....................................................................................22
Capítulo 4 Secuencias y Viajeros: Célula de Fabricación......................................................................24
SECCIÓN 4.1: CONSTRUYENDO EL MODELO ............................................................................................25
SECCIÓN 4.2: ESPECIFICANDO LAS CAPACIDADES ..................................................................................26
SECCIÓN 4.3: INCORPORANDO SECUENCIAS ............................................................................................27
SECCIÓN 4.4: MEJORA: CARRITOS DE TRANSFERENCIA ..........................................................................28
Capítulo 5 Agrupaciones, Funciones, Variables de Estado, y Estadísticas:
Ensamblaje de Tarjetas de Memoria .......................................................................................................32
SECCIÓN 5.1: CREANDO EL MODELO .......................................................................................................32
SECCIÓN 5.2: CAMBIANDO EL TIEMPO DE PROCESO EN FUNCIÓN DE LA LONGITUD DE LA COLA..........35
SECCIÓN 5.3: AÑADIENDO MÁS ANIMACIÓN ..........................................................................................37
SECCIÓN 5.4: CREANDO ESTADÍSTICAS ...................................................................................................38
Capítulo 6 Procesos en SIMIO: Ensamblaje de Tarjetas de Memoria bis ...........................................41
SECCIÓN 6.1: LOS DISPARADORES DE PROCESO: ILUSTRANDO EL PROCESO ASSIGN .............................41
SECCIÓN 6.2: CREANDO UN PROCESO “REUTILIZABLE”..........................................................................42
SECCIÓN 6.3: OBTENIENDO ESTADÍSTICAS SOBRE VARIABLES DE OBSERVACIÓN
(TALLY STATISTICS) ................................................................................................................................43
SECCIÓN 6.4: UNA INTRODUCCIÓN A RECURSOS (RESOURCES)..............................................................46
Tabla de Contenidos i
Capítulo 7 Tiempos de Proceso Específicos por Pieza y Fuentes Únicas: Célula de Fabricación bis 48
SECCIÓN 7.1: NUEVO ENUNCIADO DEL PROBLEMA ................................................................................ 48
SECCIÓN 7.2: UN CARRIL DE TRANSFERENCIA ........................................................................................ 53
SECCIÓN 7.3: FALLOS DE MÁQUINA EN LA CÉLULA DE FABRICACIÓN ................................................... 56
SECCIÓN 7.4: COMENTARIO..................................................................................................................... 57
Capítulo 8 “Material Consumido”, Cambios, Propiedades: Un Ensamblaje...................................... 59
SECCIÓN 8.1: ENSAMBLAJE DE UNA MAQUETA ...................................................................................... 59
SECCIÓN 8.2: TIEMPO DE PREPARACIÓN EN FUNCIÓN DE LA SECUENCIA .............................................. 61
SECCIÓN 8.3: UTILIZANDO MATERIALES EN LA OPERACIÓN .................................................................. 63
SECCIÓN 8.4: LLEGADA DE MATERIA PRIMA DURANTE LA SIMULACIÓN .............................................. 65
SECCIÓN 8.5: IMPLANTANDO UN ENFOQUE JUSTO-A-TIEMPO (JUST-IN-TIME) ...................................... 67
Capítulo 9 Variables Continuas, Abandonos, Interrupciones, Verificación: Una Gasolinera .......... 71
SECCIÓN 9.1: UN TANQUE SIMPLE .......................................................................................................... 71
SECCIÓN 9.2: LA GASOLINERA ................................................................................................................ 75
SECCIÓN 9.3: ABANDONO CUANDO LOS SURTIDORES SE APAGAN ........................................................ 80
SECCIÓN 9.4: INTERRUMPIENDO EL SUMINISTRO A LOS COCHES CUANDO EL SURTIDOR SE APAGA..... 81
SECCIÓN 9.5: BUSCANDO ERRORES ........................................................................................................ 82
Capítulo 10 Recursos Múltiples que Fallan: Clínica de Cuidados Intensivos ..................................... 84
SECCIÓN 10.1: USANDO UNA ÚNICA OPERACIÓN PARA MODELIZAR MÚLTIPLES RECURSOS ............... 84
SECCIÓN 10.2: FALLOS EN LOS SERVIDORES........................................................................................... 86
SECCIÓN 10.3: HACIENDO REPETICIONES: PARANDO LA EJECUCIÓN DE UNA SIMULACIÓN .................. 88
SECCIÓN 10.4: COMENTARIO................................................................................................................... 89
Capítulo 11 Modelizando Múltiples Recursos con Múltiples Operaciones:
la Clínica de Cuidados Intensivos bis................................................................................................... 90
SECCIÓN 11.1: EVITANDO EL PROBLEMA DE FALLO CUANDO SE USA UN ÚNICO SERVIDOR ................ 90
SECCIÓN 11.2: DIRIGIENDO LOS PACIENTES HACIA LOS MÉDICOS ......................................................... 91
SECCIÓN 11.3: HACIENDO QUE TODOS LOS PACIENTES ESPEREN JUNTOS ............................................. 93
SECCIÓN 11.4: COMENTARIO................................................................................................................... 97
Capítulo 12 Variables, gráficos SMORE, Optimización: Inventarios y Cadenas de Suministros .... 98
SECCIÓN 12.1: CONSTRUYENDO UNA CADENA DE SUMINISTROS ........................................................... 98
SECCIÓN 12.2: PROCESANDO PEDIDOS EN LA CADENA DE SUMINISTROS ............................................ 101
SECCIÓN 12.3: CREANDO LA PIEZA DE REPOSICIÓN DE LA CADENA DE SUMINISTROS ........................ 102
SECCIÓN 12.4: USANDO UN EXPERIMENTO PARA DETERMINAR LOS MEJORES VALORES ................... 104
SECCIÓN 12.5: USANDO GRÁFICOS SMORE PARA DETERMINAR LOS MEJORES VALORES ................. 105
SECCIÓN 12.6: USANDO PROCEDIMIENTOS DE RANKING Y SELECCIÓN PARA DETERMINAR
EL MEJOR ESCENARIO ........................................................................................................................... 107
SECCIÓN 12.7: USANDO OPTQUEST™ PARA OPTIMIZAR PARÁMETROS............................................... 108
SECCIÓN 12.8: MÁS SOBRE OPTQUEST ................................................................................................. 110
SECCIÓN 12.9: COMENTARIO................................................................................................................. 112
Capítulo 13 Usando el Objeto Recurso: Clínica Veterinaria .............................................................. 113
SECCIÓN 13.1: LA CLÍNICA VETERINARIA ............................................................................................ 113
SECCIÓN 13.2: UTILIZANDO EL OBJETO RECURSO ................................................................................ 113
SECCIÓN 13.3: RECURSOS EN FUNCIÓN DEL TIPO DE PACIENTE ........................................................... 117
Capítulo 14 Objetos Inteligentes: Clínica Veterinaria bis................................................................... 122
SECCIÓN 14.1: USANDO LA POTENCIA DE OBJETOS INTELIGENTES PARA TOMAR DECISIONES ........... 122
SECCIÓN 14.2: AÑADIENDO UN PROCESO ADICIONAL .......................................................................... 123
SECCIÓN 14.3: CAMBIANDO LA SELECCIÓN DE RECURSOS................................................................... 125
ii Modelización y Simulación: Libro de Prácticas con SIMIO
Capítulo 15 Usando un Operario: Clínica Veterinaria Tres ...............................................................127
SECCIÓN 15.1: DIRECCIONANDO PACIENTES .........................................................................................127
SECCIÓN 15.2: USANDO WORKER COMO UN RECURSO MÓVIL................................................................131
SECCIÓN 15.3: VOLVIENDO AL DESPACHO ENTRE PACIENTES ..............................................................133
SECCIÓN 15.4: EVENTOS DE TIEMPO CERO ...........................................................................................135
SECCIÓN 15.5: COMENTARIO .................................................................................................................136
Capítulo 16 Usando un Operario como un Recurso de Transporte: Un Banco.................................137
SECCIÓN 16.1: UN PEQUEÑO BANCO .....................................................................................................137
SECCIÓN 16.2: USANDO UN OPERARIO COMO UN RECURSO Y UN TRANSPORTADOR ...........................137
SECCIÓN 16.3: ACOMPAÑANDO A LOS CLIENTES A LA CAJA DE SEGURIDAD .......................................140
SECCIÓN 16.4: USANDO LA FUNCIÓN TRANSPORTE DE UN OPERARIO ..................................................144
Capítulo 17 Creando Objetos: Actividades en un Almacén ................................................................148
SECCIÓN 17.1: CREANDO UN MODELO SIMPLE CON RECURSOS: UN ALMACÉN ...................................148
SECCIÓN 17.2: APARTANDO UN OBJETO PARA AVERIGUAR POR QUÉ ..................................................150
Capítulo 18 Creando Objetos Nuevos Utilizando Subclases: Objeto Delay (Retardo) .....................155
SECCIÓN 18.1: HACIENDO UNA SUBCLASE DEL NODO DE TRANSFERENCIA PARA CREAR UN NODO DE
RETARDO................................................................................................................................................155
SECCIÓN 18.2: MODIFICANDO LOS PROCESOS Y AÑADIENDO PROPIEDADES EN UN NODO NUEVO .....157
SECCIÓN 18.3: CREANDO UN MODELO PARA PROBAR EL NUEVO DELAYTRANSFERNODE .....................159
Capítulo 19 Creando Nuevos Objetos: Objeto Delay bis .....................................................................164
SECCIÓN 19.1: CREANDO UN NODO DELAY DESDE CERO.....................................................................164
SECCIÓN 19.2: USANDO EL NUEVO OBJETO DELAYOBJECT .................................................................168
SECCIÓN 19.3: MEJORANDO EL MODELO CON DISPARADORES DEFINIDOS POR EL USUARIO ..............169
SECCIÓN 19.4: MEJORANDO EL OBJETO DELAY CON ASIGNACIONES ...................................................171
Capítulo 20 Sistemas dentro de Sistemas: Una Célula de Fabricación ..............................................174
SECCIÓN 20.1: MODELO DE UNA CÉLULA .............................................................................................174
SECCIÓN 20.2: CREANDO UN SUBMODELO ............................................................................................175
SECCIÓN 20.3: CREANDO UN MODELO UTILIZANDO EL SUBMODELO WORKCELL ..............................177
SECCIÓN 20.4: AÑADIENDO EL OBJETO WORKCELL .............................................................................178
SECCIÓN 20.5: MOSTRANDO PROPIEDADES RESOURCE Y CAPACITY....................................................179
Capítulo 21 Más Sobre Submodelos: Una Línea de Camisas ..............................................................181
SECCIÓN 21.1: EL MODELO DEL SISTEMA .............................................................................................181
SECCIÓN 21.2: USANDO UN VEHÍCULO PARA MOVER LAS CAMISAS A LOS PUESTOS DE DOBLADO ....183
SECCIÓN 21.3: PERMITIENDO LLEVAR VARIAS PIEZAS .........................................................................185
SECCIÓN 21.4: PERMITIENDO UNA CARGA Y UNA DESCARGA CADA VEZ ...........................................187
SECCIÓN 21.5: HACIENDO QUE LA ANIMACIÓN SEA LA CORRECTA......................................................188
Capítulo 22 Más Subclases: Modelización Avanzada de Cadenas de Suministros ...........................190
SECCIÓN 22.1: DESARROLLANDO UN OBJETO ESPECIALIZADO PARA LA CADENA DE SUMINISTRO .....190
SECCIÓN 22.2: AÑADIENDO LA ESTACIÓN DE PEDIDOS Y LAS CARACTERÍSTICAS
PARA PROCESARLOS ..............................................................................................................................192
SECCIÓN 22.3: AÑADIENDO LA LÓGICA DE COMPORTAMIENTO DEL SISTEMA DE PEDIDOS .................195
SECCIÓN 22.4: AÑADIENDO LA LÓGICA DEL SISTEMA DE REPOSICIÓN DE INVENTARIO ......................198
SECCIÓN 22.5: USANDO LOS NUEVOS OBJETOS PARA MODELIZAR LA CADENA DE SUMINISTROS ......201
SECCIÓN 22.6: AÑADIENDO UN SEGUNDO PROVEEDOR ........................................................................204
Tabla de Contenidos iii
Capítulo 23 Más Sobre Subclases: Planificación de Procesos/Gestión de Proyectos ........................ 207
SECCIÓN 23.1: PLANIFICACIÓN DE PROCESOS....................................................................................... 207
SECCIÓN 23.2: CREANDO UN CAMINO TIMEPATH PARA REPRESENTAR ACTIVIDADES ........................ 208
SECCIÓN 23.3: CREANDO UN OBJETO JUNCTION PARA MODELIZAR RELACIONES DE PRECEDENCIA . 210
SECCIÓN 23.4: CREANDO UNA PEQUEÑA RED PARA PROBAR EL NUEVO OBJETO ................................ 215
SECCIÓN 23.5: CONSTRUYENDO LA RED DEL EJEMPLO ........................................................................ 216
SECCIÓN 23.6: AÑADIENDO LA HOLGURA Y LA CRITICIDAD EN LOS CÁLCULOS ................................. 218
SECCIÓN 23.7: AÑADIENDO HOLGURA Y CRITICIDAD: SEGUNDO ENFOQUE ........................................ 224
Capítulo 24 Sistemas Lean: Sistemas Kanban con Operarios Multidisciplinares ............................ 226
SECCIÓN 24.1: BLOQUEOS BASADOS EN ALMACENES: ENFOQUE KANBAN ......................................... 226
SECCIÓN 24.2: MODELIZANDO EL SISTEMA .......................................................................................... 233
SECCIÓN 24.3: EL OPERARIO FORMADO INTERDISCIPLINARMENTE ..................................................... 236
Capítulo 25 Múltiples Productos: Cadena de Suministro Bis ............................................................. 242
SECCIÓN 25.1: CAMBIANDO LAS PROPIEDADES PARA MANEJAR MÚLTIPLES SKUS............................ 242
SECCIÓN 25.2: ASOCIANDO UNA TABLA A UNA HOJA EXCEL .............................................................. 243
SECCIÓN 25.3: CAMBIANDO LOS PROCESOS PARA MANEJAR MÚLTIPLES SKUS ................................. 245
SECCIÓN 25.4: MODIFICANDO EL SISTEMA ........................................................................................... 248
Índice ........................................................................................................................................................ 251
iv Modelización y Simulación: Libro de Prácticas con SIMIO

Los autores
JEFFREY A. JOINES es Associate Professor y Associate Department Head of
Undergraduate Programs en el Department of Textile Engineering, Chemistry, and Science
de NC State University. Obtuvo un B.S. en Electrical Engineering y B.S. en Industrial
Engineering, un M.S en Industrial Engineering, y Ph.D. en Industrial Engineering, todos de
la NC State University. Recibió en 1997 el premio Pritsker Doctoral Dissertation Award del
Institute of Industrial Engineers. Es miembro de IEEE, IIE, ASEE, Tau Beta Pi, Etta Kappa
Nu, Alpha Pi Mu y Phi Kappa Phi. Sus investigaciones versan sobre la optimización de la
cadena de suministros utilizando simulación y métodos de optimización computacional. El Dr. Joines
imparte clases tanto de grado como de post-grado en Computer information systems, Computer based
modeling in Excel and VBA, y Computer Simulation for Six-Sigma. El Dr. Joines también ha impartido
clases en Design for Six Sigma, Simulation and Six Sigma, y Data Management to Assist in Six Sigma en
programas Six Sigma Black Belt and Master Black Belt. El Dr. Joines ha sido Program Chair de la 2005
Winter Simulation Conference (WSC) y el editor de los Proceedings de 2000 WSC así como que ha
desarrollado y mantenido el sistema de gestión de artículos de WSC en el período 2000-2009. Forma parte
del consejo de WSC representando a IEEE Systems, Man, and Cybernetics Society. Ha sido también autor y
session chair en varias Winter Simulation Conferences.
El Dr. Joines está involucrado en la utilización de tecnología en el aula y cómo afecta en la capacidad para
resolver problemas. Se le concedieron los premios a la docencia NC State University Outstanding Teaching
Award y College of Textiles Outstanding Teacher, lo que le ha permitido ser admitido como miembro de la
Academy of Outstanding Teachers. En 2009, el Dr. Joines (junto con el Profesor Roberts) han sido
galardonados con el premio Gertrude Cox Award for Innovative Excellence in Teaching and Learning with
Technology for Transformative Large Scale Projects.
STEPHEN D. ROBERTS es el A. Doug Allison Distinguished Professor in the Edward P.

Fitts Department of Industrial and Systems Engineering at NC State University. El Dr.
Roberts obtuvo sus títulos, Ph.D., M.S.I.E., and B.S.I.E. (with Distinction) por School of
Industrial Engineering de Purdue University. Su principal interés estriba en la simulación y
la ingeniería en sistemas sanitarios y de salud. Empezó en NC State University en 1990, y ha
sido Department Head of the Department of Industrial Engineering y Interim Director of the
Integrated Manufacturing Systems Engineering Institute. Con anterioridad, estuvo en el Department of
Internal Medicine en Indiana University School of Medicine y en School of Industrial Engineering at Purdue
University. También fué el Director of the Health Systems Research Group at Regenstrief Institute for
Health Care. Con anterioridad, estuvo como docente el Department of Industrial and Systems Engineering de
the University of Florida y fué el Director of the Health Systems Research Division of the J. Hillis Miller
Health Center, University of Florida. Ha estado de sabático en Wolverine Software y en University of
Central Florida/Institute for Simulation and Training.
El Profesor Roberts es miembro de Alpha Pi Mu, Tau Beta Pi, Sigma Xi, Sigma Tau, y Omega Rho y Fellow
of the Institute of Industrial Engineers. Ha obtenido la Kaiser Aluminum Fellowship y la NDEA Title IV
Fellowship. Recibió los premios AIIE 1967 Graduate Research Award, Outstanding Paper Award at the 12th
Annual Simulation Symposium, Pritsker and Associates Outstanding Undergraduate Teaching Award in the
Purdue School of Industrial Engineering, CA Anderson Outstanding Teacher in the NCSU Department of
Industrial and Systems Engineering, Outstanding Teacher from the NCSU College of Engineering, NCSU
Academy of Outstanding Teachers, Gertrude M. Cox Award for Transformative projects from NC State
University (con el Profesor Joines), Distinguished Service Award from INFORMS College on Simulation, y
ha sido miembro, Vice - Chair, y Chair de Winter Simulation Conference (WSC) Board of Directors
representando a TIMS (ahora INFORMS) College on Simulation, y Secretary, Vice-President/Treasurer,
President, and Past-President de WSC Foundation Board. Fué Proceeding Editor de 1983 WSC, Associate
Program Chair en 1985, y Program Chair en 1986. Ha sido WSC presenter, session chair, track coordinator,
y keynote speaker.
Los autores v
F. JAVIER OTAMENDI es Profesor Titular del Departamento de Economía Aplicada I en
la Universidad Rey Juan Carlos de Madrid y Coordinador de las Titulaciones Económicas.
Obtuvo sus títulos de Ingeniería Industrial y Management (B.S y M.S) en Oklahoma State
University. Con posterioridad obtuvo el título de Licenciado en Administración y Dirección
de Empresas en la Universidad Complutense de Madrid y el título de Doctor por la
Universidad Politécnica de Cartagena por el Programa de Tecnologías Industriales. Su
principal interés estriba en la optimización de sistemas vía simulación así como la aplicación de la
simulación en las ciencias económicas y del transporte. Su carrera docente empezó en la Universidad Carlos
III de Madrid enseñando simulación y gestión de calidad, y siguió en la Universidad Complutense de Madrid
y en Saint Louis University, Madrid, enseñando estadística para las ciencias sociales. En la actualidad,
imparte clases de estadísticas en los grados y de dirección de operaciones y simulación en postgrado.
También estuvo dos años como investigador en el Centro COTEC I+D aplicando simulación en aeropuertos.
El Dr. Otamendi ha sido el Conference Chair y Proceedings Editor de European Conference in Modelling
and Simulation en 2009 (ECMS09). Es miembro del Consejo de ECMS desde 2007. Ha participado como
ponente, track chair o session chair en ECMS, SCSC y otros congresos de simulación.
vi Modelización y Simulación: Libro de Prácticas con SIMIO

Prefacio: Aprendizaje Activo
La mayoría de los libros se escriben con un tono explicativo y los autores se encuentran con tremendos
problemas para explicar, con todo lujo de detalles, los conceptos y las ideas que se transmiten. Este estilo
también es el habitual en los libros sobre simulación, de los que existen básicamente dos categorías – los que
utilizan como base un lenguaje específico y los que no. Si el libro se basa en un lenguaje de simulación,
entonces se han de explicar las principales características y los posibles usos del software a la vez que se
explican conceptos básicos de simulación. Por el contrario, los libros que no se basan en un lenguaje en
particular se concentran en los conceptos fundamentales sobre simulación, especialmente en los aspectos
estadísticos o analíticos. El libro asume como mínimo tener instalada la versión 3.42 de SIMIO.
1ª Parte: ¿Qué hace a este libro diferente?
Este libro es distinto a la mayoría. Para empezar, está escrito en lo que se podría llamar un estilo
participativo. El lector no se puede sentar a leerlo sin un ordenador en el que esté instalado SIMIO. Con este
libro se espera que se participe activamente mediante la utilización de SIMIO a medida que se vayan
pasando las páginas. Nosotros, los autores, intentamos mantener una conversación con usted, lector. Nuestro
convencimiento es que la simulación no es un deporte para el espectador. Tiene que trabajar a la vez para
desarrollar competencias con el SIMIO, competencias que se desarrollan a través de la práctica. Este libro le
invita a practicar y a utilizar sus conocimientos y capacidades.
En segundo lugar, el libro se enfoca en la modelización con SIMIO, dejando aparte la mayoría del análisis
estadístico y de toma de decisiones, ya que estos conceptos se deben aprender en otra parte. No es que no
pensemos que estos temas sean importantes, porque son vitales (y cuando enseñamos simulación los
incluimos como una parte fundamental del curso), pero no vamos a emplear demasiado tiempo en este
documento, porque existen libros excelentes que pueden cubrir el vacío que dejamos. Sugerimos que, si el
lector está enseñando/aprendiendo simulación, que a la vez disponga de uno de estos libros que no están
basados en un software en particular1
Por último, este libro es deliberadamente barato (tanto el libro electrónico como su versión en papel). Un
nuevo lenguaje de simulación como SIMIO va a estar cambiando constantemente. De hecho, la gente de
SIMIO intenta tener nuevas versiones (llamadas “sprints”) una vez cada tres meses. Cualquier libro que
describa las tripas de SIMIO se volverá obsoleto rápidamente, por lo que queremos que se añadan las nuevas
características en nuevas versiones a menudo. Es posible que cambiemos algo el contenido del libro a
medida que encontremos nuevos ejemplos o enfoques. Si el lector no paga mucho por el libro, es posible que
vuelva a adquirir nuevas versiones para estar al día con los nuevos contenidos.
2ª Parte: ¿Quién se beneficia de la Enseñanza Activa?
Nuestra intención es que usted, como lector, se convierta en un alumno activo y, como sugiere el título,
trabaje a la vez que lee. Nuestra experiencia en las aulas es que el alumno aprende más al hacer los trabajos,
por lo que este “manual de trabajo” se centra en el trabajo de laboratorio, en lo que nuestros alumnos hacen
en clase. Los capítulos de este libro generalmente corresponden a una sesión de practica de laboratorio. Si el
lector no es alumno de enseñanza reglada, pero quiere aprender SIMIO por su cuenta, pensamos que este
enfoque es atractivo para la auto-enseñanza. Un capítulo se puede cubrir en una tarde.
1
Por ejemplo, Discrete-Event System Simulation (5th Edition), Jerry Banks, John Carson, Barry Nelson, David Nicol, Prentice-Hall,
2010 (622 páginas)
Prefacio: Aprendizaje Activo vii

Existen diversos mecanismos para incluir la enseñanza activa en un aula. Algunos profesores empiezan la
clase con algún tipo de planteamiento del problema y de orientación hacia las técnicas de modelización
apropiadas en ese caso. Algunos otros van directamente al grano y realizan un ejercicio junto con los
alumnos. Y otros intentan que los alumnos sigan el manual a su propio ritmo. Aún así, lo que es crítico en
este tipo de enseñanza son los denominados “momentos de enseñanza”, como oposición a las clases
magistrales. Estos momentos aparecen cuando se hacen preguntas u observaciones, lo que provoca una
discusión en detalle sobre un tema en concreto. Algunas personas piensan en este proceso como un sistema
de educación tipo “pull”. El enfoque asusta a muchos profesores porque no se puede seguir un formato
estándar de clase o porque la discusión se alargue y algún tema se deje “sin cubrir”.
Para asegurar que todos los implicados participan en este proceso activo de enseñanza, normalmente
entregamos al principio de la clase una o dos páginas con preguntas que deben surgir al resolver el ejercicio.
Hemos incluido algunas de ellas a lo largo y ancho del libro. Son preguntas que tienen respuestas cortas y
que requieren que los alumnos presten atención a lo que van desarrollando. El resultado es una clase con un
alto nivel de asistencia y participación, aunque no se controle oficialmente la asistencia, porque puntuamos a
aquéllos que entregan los ejercicios al finalizar la clase. Asignaturas en la que se sigue esta metodología
docente se crean una reputación de obligada asistencia.
3ª Parte: ¿Por qué enfatizar en la “Modelización”?
Bajo nuestro punto de vista, la modelización vía simulación es una forma de “ingeniería de sistemas”,
entendidos sistemas como procesos productivos o logísticos, incluso administrativos. Nuestra intención es
hacer ingeniería o re-ingeniería de un proceso o sistema, pero, al ser complejo, dificultoso o incluso
imposible experimentar con tal sistema, necesitamos desarrollar un modelo en un ordenador a imagen y
semejanza del real o del futuro sistema, y experimentar con ese modelo (de forma similar a lo que hacen con
un túnel de viento los diseñadores de nuevos aviones). La actividad crítica es el “desarrollo del modelo” – lo
que se llama “modelización mediante simulación”, o “simulación” simplemente. Este tipo de modelización
no es una ciencia exacta, pero se basa en un enfoque de resolución de problemas. Para desarrollar un modelo
se necesita: (1) un conjunto robusto de conceptos sobre modelización (y el lenguaje en que se realiza la
simulación), y (2) una implantación en un ordenador. Luego para ser un buen “simulador”, es necesario que
adquieras conocimientos sobre los conceptos de modelización y experiencia en su uso.
SIMIO proporciona un amplio abanico de conceptos y posibilidades sobre modelización vía simulación así
como capacidades atractivas tanto visuales como tabulares para presentar resultados numéricos. Sin
embargo, cualquiera que haya tenido experiencia en simulación sabe que los lenguajes y las herramientas
tienen limitaciones y alguna vez no han podido desarrollar el modelo como les hubiera gustado. En lugar de
utilizar el enfoque de “unidad/objeto, atributo y recurso”, SIMIO se basa en un paradigma con orientación a
objetos más general, en el que los objetos ejecutan “procesos u órdenes”. Así, además de disponer de los
objetos y procesos incluidos en una librería estándar, el usuario puede añadir más, quitar los actuales o
cambiarlos para satisfacer sus necesidades particulares.
Por lo que aprender a utilizar SIMIO requerirá de un cambio de mentalidad. Tendrá el usuario que apartar los
enfoques que hayan utilizado con otros lenguajes y empezar a adoptar otra visión a la hora de atacar el
proceso de desarrollo del modelo. Pensamos que si se trabaja este libro con cariño y atención, se aprenderá
lo suficiente sobre el enfoque que sigue SIMIO como para poder subir un nivel y convertirlo en su propio
enfoque sobre simulación.
4ª Parte: Organización del libro
Este libro está organizado de forma conceptual para hacer modelos rápidamente. En los primeros cinco
capítulos, nos concentramos en el uso de la Librería de Objetos Estándar, “Standard Library Objects”, de
SIMIO. Se puede realizar mucha modelización sin necesidad de recurrir a conceptos u objetos más
complejos. Los siguientes siete capítulos explican cómo ampliar los objetos estándar utilizando procesos,
viii Modelización y Simulación: Libro de Prácticas con SIMIO
“processes”. Este aprendizaje dota de mayor flexibilidad a la modelización sin necesidad de inventar una
nueva librería de objetos. Los últimos capítulos se utilizan para discutir la creación de nuevos objetos y la
modificación de los ya existentes en SIMIO, de forma que se demuestre todo el poder de este enfoque
orientado a objetos.
El libro está diseñado para que sea lea capítulo a capítulo, aunque sea posible elegir ciertos conceptos y
temas. En los primeros capítulos, construimos modelos de forma directa sin mucha explicación de cómo se
seleccionan ciertas características. En los últimos capítulos, por el contrario, se argumentan las elecciones de
las distintas opciones así como otras posibles vías de modelización. Otros capítulos al final del libro
profundizan también en ciertos temas vistos con anterioridad, puesto que es sabido que la redundancia en el
aprendizaje ayuda a fortalecer los conceptos. Para cuando se acabe con el libro, se debe por tanto estar bien
preparado para construir modelos en SIMIO y entender las bondades de los distintos enfoques que se pueden
utilizar.
Al final de la mayoría de los capítulos, se incluyen comentarios sobre los temas tratados. Se enfatizarán las
fortalezas y debilidades del enfoque de modelización y el lenguaje utilizado (no tenemos intereses
financieros en SIMIO). Los diseñadores de SIMIO fueron también los diseñadores de Arena, por lo que se
encontrarán trazas y reminiscencias de Arena en SIMIO. Ya que alguno de los lectores migrará desde Arena,
proporcionaremos información sobre estas trazas. Sin embargo, prepárense para ir mucho más allá de lo
aprendido con otros lenguajes de simulación.
Cuando se compara Arena y SIMIO, no se encontrarán en SIMIO rutinas de análisis para datos de entrada o
de salida. SIMIO probablemente nunca tendrá la capacidad de analizar los datos de entrada, ya que hay
muchos disponibles2. Cuando se usa un modelizador de datos de entrada, es necesario establecer de forma
correcta una relación entre los parámetros estimados por el modelizador y los parámetros necesarios en
SIMIO. El analista de resultados, “Output Analyzer”, y el analista de procesos, “Process Analyzer”, han sido
incorporados a SIMIO, con la posibilidad de escribir información en ficheros externos para su posterior
análisis. SIMIO está mejorando la presentación de resultados casi de forma diaria. También ha incorporado
recientemente rutinas sobre selección y ranking de subconjuntos de alternativas, así como posibilidades de
optimización.
En un sentido muy limitado, SIMIO es como Arena con las capacidades de Siman para analizar procesos.
Sin embargo, esta visión no hace justicia a la mayor flexibilidad y las enormes posibilidades ofrecidas por
SIMIO. Además, SIMIO presenta la posibilidad de representar a escala el modelo en 3D, y posee una
orientación a objetos que permite añadir y modificar objetos de forma sencilla. SIMIO dispone de una
apariencia y una disposición más modernas y, en nuestra opinión, unas posibilidades mayores que las de la
mayoría de los otros lenguajes de simulación.
5ª Parte: Estilos y Formatos Utilizados en este Libro
Ciertos estilos se utilizan en este libro para ilustrar objetos, nombres y parámetros y para diferenciarlos
claramente. Los objetos estándar de SIMIO se escriben en Versales y una fuente Courier New (SERVER)
mientras que los creados por el usuario también irán en negrita (DELAYOBJECT). Las propiedades asociadas
con estos objetos se incluyen en cursiva (Processing Time). Los nombres de los procesos irán en cursiva y
entre-comillados, como “OnEnteredProcessing”, mientras que los disparadores de proceso, “triggers”
(Exited) sólo irán en cursiva al ser propiedades. Etapas en los procesos, como Assign se presentan en
cursiva y en Courier New. SIMIO utiliza también muchas expresiones, que se indican en Courier New (
SrvOffice.Contents >0). Los nombres de los objetos que han sido definidos por el usuario irán en
negrita (incluir un servidor, SERVER, de nombre SrvOffice). Los valores asociados con las propiedades se
incluirán de la misma forma que las expresiones o entre comillas para cadenas de texto (“True”).
2
Por ejemplo, véase EasyFit en http://www.mathwave.com/
Prefacio: Aprendizaje Activo ix

6ª Parte: Reconocimientos
Queremos dar las gracias a nuestros alumnos, que han ayudado mucho a nuestra comprensión del proceso de
aprendizaje y que a menudo nos hacen que demostremos nuestra ignorancia o nuestra falta de preparación.
Apreciamos también la respuesta amable de la gente de SIMIO a nuestra inacabable batería de preguntas y
dudas, en especial a Dave Sturrock y a Dennis Pegden. Finalmente, queremos dar las gracias a nuestras
familias por su comprensión y paciencia porque a menudo pasamos más tiempo hablando entre nosotros que
con ellos.
Por favor, hágannos saber cómo mejorar este “workbook” y cómo podemos satisfacer mejor sus necesidades.
Jeff Joines (JeffJoines@ncsu.edu)

Steve Roberts (roberts@ncsu.edu)

Raleigh, North Carolina
F. Javier Otamendi (franciscojavier.otamendi@urjc.es)
Universidad Rey Juan Carlos

Madrid, España
x Modelización y Simulación: Libro de Prácticas con SIMIO

Capítulo 1
Introducción a SIMIO: La Tienda de Helados
La simulación es muy útil. Casi cualquier persona que conoce y aprende simulación ve sus tremendas
posibilidades de aplicación al mundo real. Prácticamente, cualquier sistema de fabricación, producción o
servicios se puede beneficiar de un estudio basado en modelos de simulación. SIMIO puede hacer que la
aplicación sea no sólo fácil de realizar sino que sirva a la vez como un enfoque robusto y potente para
analizar problemas complejos.
La simulación es divertida. Se pueden crear modelos que sean atractivos visualmente y SIMIO eleva el
disfrute a niveles insospechados con su capacidad de presentación en 3 dimensiones (3D). Lo que significa
que no sólo el lector puede ver cómo se comporta el modelo, sino también los que trabajan con él,
aumentando la credibilidad del proceso.
Sección 1.1: El inicio
Asumimos que ha instalado SIMIO en su ordenador y que está listo para empezar.
Paso 1: Abra SIMIO o bien a través del menú Inicio en Windows o bien haciendo clic en un icono de
SIMIO, “ ”, que quizás haya incluido en la barra de herramientas de Windows o en el Escritorio.
Barra de
Parece MS SIMIO
Office
Crear un
nuevo modelo
Información
General de SIMIO
Modelos
Elementales
Versión
Modelos
Completos
Figura 1.1: Abriendo la ventano de SIMIO
Introducción a SIMIO: La Tienda de Helados 1

La ventana que se abre según la Figura 1.1 se asemeja a las de Microsoft Office. Se ha de fijar en los
recursos que SIMIO le facilita. “SimBits” hace referencia a la librería de modelos elementales (cada uno
ilustrando una estructura de modelización particular de SIMIO) y “Example Projects” hace referencia a la
librería con modelos completos. También se muestra la versión de SIMIO3. Querrá mantener su versión
actualizada. Pinche ahora en “Create a new model.” para crear un nuevo modelo.
Undo/Redo
MySimioProject
Unidades
Pestaña de
Ejecución Objetos in
Pestaña MySimioProject
Abrir/Cerrar
Panel de
[Librería Navegación
Tapiz de
Estándar] Diseño
Inspector de
Propiedades
[Librería de
Proyecto]
Figura 1.2: Creando un nuevo modelo

Paso 2: Cuando se crea un nuevo modelo (véase la Figura 1.2), se definen automáticamente dos objetos. El
tipo de entidades, MODELENTITY, que creará “entities” (traducido en este manual como “unidad o
entidad”) que se mueven por el modelo mientras que el modelo, MODEL, contendrá el posicionamiento de
los objetos y el flujo de las unidades. Dicho de otra forma, las unidades se mueven alrededor y entre los
objetos que están posicionados.
Paso 3: Haga clic con el botón derecho del ratón en MODELENTITY y MODEL en el Panel de Navegación,
Navigation Panel, y seleccione las propiedades o características del modelo, Model Properties.
Pregunta 1: ¿Cuál es el nombre por defecto de MODELENTITY?
3
Las versiones “Sprint” de SIMIO salen aproximadamente una vez cada tres meses, por lo que el software irá cambiando
rápidamente. Asegúrese de conseguir las actualizaciones con nuevas características y con correcciones de posibles errores.
2 Modelización y Simulación: Libro de Prácticas con SIMIO
Pregunta 2: ¿Cuál es el tipo de objeto de MODEL?
Paso 4: Tenga en cuenta siempre los botones Undo/Redo. Se pueden utilizar para corregir errores y recuperar
componentes del modelo previamente utilizados. Cuando una acción no pueda ser revertida, SIMIO
lanzará una advertencia.
Paso 5: Las unidades (“Units”) son una forma conveniente de especificar las unidades por defecto de tiempo,
distancia o longitud y de flujo.
Sección 1.2: La Tienda de Helados
Una pequeña tienda de helados vende cucuruchos de helado. Los clientes llegan y esperan en cola hasta ser
atendidos por uno de los dos dependientes. Estos dependientes reciben y preparan el pedido y se lo entregan
al cliente, quien se dirige al cajero para pagar. Después de pagar, los clientes se van de la tienda. Mientras se
prepara la simulación, suele ser conveniente realizar un diagrama de proceso o flujograma. La Figura 1.3
muestra los cuatro procesos en que se divide la compra y el pago del helado.
Llegada Elección del Pago del Salida del

del Cliente Helado Helado Cliente
Dependiente En el Cajero
Figura 1.3: Flujograma de la Tienda de Helados

Asumamos que conocemos lo siguiente:
 Que los clientes llegan a la tienda según un modelo de probabilidad exponencial, con un tiempo
medio entre llegadas de 0.5 minutos.
 Que el tiempo que tarda el dependiente en interactuar con el cliente y entregarle el cucurucho de
helado se puede representar mediante un modelo de probabilidad triangular, con un mínimo 0.4
minutos, una moda o valor más habitual de 0.9 minutos, y un máximo de 1.5 minutos.
 Que el tiempo que emplea el cajero en cobrar sigue también una distribución triangular con un
mínimo de 0.3, una moda de 0.4 minutos, y un máximo de 0.6 minutos.
 Que el tiempo de desplazamiento entre cada proceso es de 15 segundos.
Si ambos dependientes están ocupados, los clientes esperarán en una única cola según lleguen, siguiendo lo
que se denomina una prioridad FCFS (first-come, first-served; o FIFO; al primero que entra, primero se le
atiende). También hay cola única delante del cajero. Asumiremos también que no hay problemas de espacio.
Paso 1: Debería estar bastante claro que los clientes deberían ser modelizados con un MODELENTITY mientras
que el MODEL representará el flujograma presentado en la Figura 1.3.
Paso 2: Añada objetos en el modelo haciendo un clic sobre el objeto que se desee en la [Standard Library].
Arrastre el objeto sobre el tapiz de diseño y vuelva a hacer clic para colocarlos en posición (también
puede hacer clic y arrastrar los objetos para recolocarlos o borrarlos del modelo). Cuando haga clic en un
objeto, sus propiedades aparecen en el inspector de propiedades, property inspector (que suele estar
colocado en el panel inferior derecho) - véase Figura 1.4.

 Añada un objeto fuente o generador de entidades, SOURCE, dos objetos que procesan o transforman
entidades, SERVER, que será traducido por facilidad como servidor, y un objeto sumidero o
eliminador de entidades, SINK – véase Figura 1.4.
 Conecte los objetos con un camino con tiempo de desplazamiento o retardo, TIMEPATH, haciendo
clic en el nodo de salida (“output”, diamante azul) de un objeto y conectándolo con el nodo de
entrada (“input”, diamante gris) de otro objeto. Puede hacer clic entre los nodos para crear un
aspecto de línea quebrada lo que permite tener más flexibilidad a la hora de representar la conexión
entre los objetos.
Note cambios en la barra
Objeto Fuente
(Source)
Propiedades
Seleccionado
de la Fuente
Servidor
Nombre
del Objeto
Camino con
Tiempo de
Desplazamiento
Figura 1.4: Comenzando a Modelizar

Paso 3: Añada nombres (“name”) a cada objeto. Puede cambiar el nombre de un objeto directamente4 o en la
propiedad “General” dentro de la ventana de propiedades.
Pregunta 3: Un objeto servidor, SERVER, tiene tres líneas (“lines”) que lo rodean. ¿Cómo se llaman?
Pregunta 4: Un objeto SERVER tiene un nodo “input” y otro “output”. Estos nodos son también objetos
de la [Standard Library]. ¿Cuál es el nombre en la librería estándar del nodo de entrada?
Pregunta 5: ¿Cuál es el nombre en la librería estándar del nodo de salida?
4
Haga doble click encima del objeto para cambiar el nombre directamente.
Paso 4: Haga clic en cada objeto y rellene sus propiedades según las hipótesis y los datos de partida. La
Figura 1.5 muestra las propiedades asociadas con el objeto fuente, SOURCE.
Nombre de la Entidad
Propiedades
Objeto Fuente Llegadas en función
de Tiempo entre
Llegadas
Unidades de
Tiempo Editor de
Expresiones
Revela
Detalles
Descripción de
la Propiedad
Figura 1.5: Propiedades de una Fuente

Es importante estar seguro de que las unidades de tiempo son las correctas cuando se identifican expresiones
que incluyen tiempos y distancias. Para introducir o revelar detalles en una ventana de diálogo, debe hacer
clic en el icono . El editor de expresiones, Expression Editor, te permite escribir expresiones con el
siguiente formato:
Object.SubObject.SubObject(parámetros)
Para activar el editor de expresiones, empiece por especificar un carácter. Selecciona el objeto, su(s)
subobjeto(s), y su(s) propiedades. Los editores de expresiones tienen la facilidad de “auto-completar”, lo que
significa que se completará el nombre a partir de los primeros caracteres. También indica si existen
subobjetos disponibles para este objeto en particular.
Pregunta 6: ¿Qué unidades de tiempo están asociadas al tiempo entre llegadas?
Paso 5: Complete su modelo añadiendo información a los dos servidores, SERVERS:
 Para el objeto PEDIR:

o Initial Capacity: 2
o Processing time: Random.Triangular(0.4, 0.9,1.5)
o Units: Minutes
 Para el objeto PAGAR:
o Processing time: Random.Triangular(0.3, 0.4, 0.6)
o Units: Minutes
 Para los objetos TIMEPATH:
o TravelTime: 15
o Units: Seconds

Note que los nombres de los objetos están listados en la categoría “General” en el inspector de
propiedades.
Paso 6: Antes de ejecutar el modelo, vamos a cambiar el momento de tiempo en el que acabará la simulación
en el configurador Run Setup, en la pestaña Ejecutar (“Run”), como muestra la Figura 1.6.
Determinando
el final
Figura 1.6: Determinando el Tiempo de Ejecución
Paso 7: Ahora, simulemos durante un rato – haga clic en el botón para empezar la simulación.
Paso 8: Vea cómo se mueven las entidades, MODELENTITIES ( ), por los caminos, TIMEPATHS. Las
entidades se acumulan en el lugar denominado contenidos de la fila de entrada,
INPUTBUFFER.CONTENTS, y se procesan en la fila PROCESSING.CONTENTS, ambos mostrados como
“líneas” que rodean los objetos servidor. Puede mover los objetos mientras el modelo está en ejecución.
Paso 9: Haga clic en la pestaña “View” y seleccione “3-D”.
Pregunta 7: Mantenga apretado el botón izquierdo del ratón, y muévalo a derecha y a izquierda, arriba y
abajo. ¿Qué sucede?
Pregunta 8: Mantenga apretado el botón derecho del ratón, y muévalo a derecha y a izquierda, arriba y
abajo. ¿Qué sucede?
Paso 10: Cambie entre las vistas 2-D y 3-D usando las teclas “2” y “3”
Pregunta 9: ¿Qué sucede en 2-D cuando se mantiene apretado el botón izquierdo del ratón, y éste se
mueve a derecha y a izquierda, arriba y abajo?
Pregunta 10: ¿Qué sucede en 2-D cuando se mantiene apretado el botón derecho del ratón, y éste se
mueve a derecha y a izquierda, arriba y abajo?
Paso 11: Experimente en 2-D y 3-D mientras mueve las estaciones y cambia el “layout” del modelo.
Cambie el tiempo de desplazamiento del puesto Pedir a 50 segundos para percibir otro tipo de cambio.
Sección 1.3: Potenciando la Animación
La animación, Animation, es a menudo lo que interesa a la gente acerca de un modelo. Un modelo de SIMIO
en 3-D, aunque pueda requerir algo de trabajo adicional, puede motivar cierta atención extra. En esta
sección, le daremos instrucciones para crear una animación que se asemeje a lo que se muestra en la Figura
1.7.

Figura 1.7: Animación
Paso 1: Haga que los clientes aparezcan como personas, en vez de triángulos. Haga clic en MODELENTITY en
el panel [Project Library] y arrástrelo dentro del tapiz. Seleccione el triángulo verde y, dentro de la
sección Symbol→Project Symbols, busque dentro de los grupos y seleccione una persona de
“Library\People”, haciendo clic sobre el icono para sustituir al triángulo. Mire la figura en 3-D y
agrándela pasando el ratón por encima.
Paso 2: Seleccione el objeto Pedir y elija una mesa, “table”, como figura. Repita el procedimiento para el
objeto Pagar. Ajuste el tamaño de los objetos SERVER para que correspondan con el tamaño de una
persona.
Paso 3: Ahora, añadamos gente de pie detrás de las mesas. Para hacerlo, cambie a 3-D y seleccione la
pestaña para dibujar, “Drawing”. Haga clic en el botón “Place Symbol” y seleccione una persona que
represente al dependiente. Cuando la persona ha sido posicionada, puede hacer clic en una de las
esquinas y presionar la tecla Ctrl para rotar el dibujo. Sitúe a la persona detrás de la mesa. Duplique al
dependiente utilizando la secuencia Ctrl-V y Ctrl-P. Haga lo mismo para el objeto Pagar.
Paso 4: Mueva los símbolos por el tapiz para conseguir una mejor visualización de la tienda de helados.
Puede ahora añadir paredes utilizando la herramienta “Polyline” del Drawing panel. Asegúrese de incluir
la altura del objeto en la sección “Object”. Debe darse cuenta de que las medidas de distancia están
especificadas en metros salvo que lo especifique en Unidades. Puede que tenga que modificar la altura
de los objetos para que sean consistentes.
Paso 5: En una animación anterior, el camino entre Pagar y Salida debería también incluir un “path
decorator”. Los decoradores de caminos se pueden invocar seleccionando el camino y seleccionando
“Decorator”. Para visualizar mejor a la gente en este camino, el tiempo de desplazamiento a 300
segundos.

Paso 6: Ejecute la simulación y mire la animación. Cuando simule, puede que necesite ajustar su apariencia
tanto en 2-D como en 3-D. Los símbolos que representan las colas o filas de espera se pueden alargar.
Por ejemplo, el número de personas que esperan para pedir puede ser muy larga, por lo que igual desea
alargar esa línea. Lo mismo puede suceder con la de procesamiento Processing.Contents.
Recuerde que la longitud no tiene impacto en la capacidad sino sólo en la animación (incluso puede
haber más en espera que dibujados).
Pregunta 11: Enseñe la simulación a sus amigos. ¿Cuál es su reacción?
Sección 1.4: Viendo Resultados
Aunque la animación llama la atención, el objetivo de la simulación es comprender las características

numéricas del sistema que está modelizando. Típicamente, estará haciendo cambios en el modelo hasta que
identifique los cambios que quiera proponer o recomendar.
Paso 1: Primero, miremos los resultados del modelo básico, mostrados en la Figura 1.8. Quizá podamos
denominar a este modelo “sistema actual” (“present system”). En la pestaña de ejecución, “Run”, cambie
la duración de la simulación a 8 horas. Los resultados de las simulación se pueden ver en la pestaña de
resultados, “Results”.
Pestaña de
Resultados
Atributos Filtro
Variable
Reordenar
Resultados
Figura 1.8: Viendo Resultados

Paso 2: Los resultados de la simulación se muestran en forma de tabla, “pivot table.” En la tabla se disponen
los resultados en función de atributos, que son las cabeceras de cada columna.
Paso 3: Cada atributo va acompañado de dos símbolos – uno para re-ordenar la columna y otro para filtrar o
seleccionar lo que se muestra en cada columna.
Pregunta 12: Filtre la estadísticas para mostrar sólo las medias para MODELENTITY. ¿Cuál es el número
medio en el sistema, Number in System, y el tiempo medio de permanencia en el sistema, Time in
System?
Paso 4: Los atributos se pueden mover a derecha e izquierda en la pantalla.
Paso 5: Haciendo clic con el botón derecho en “Results Field”, puede mostrar “show field list.” Así puede
añadir otros campos de cálculo a las columnas.
Paso 6: Las categorías, “Categories”, para las que se pueden obtener estadísticas son: Contenido, Content,
Producción total, Throughput, Capacidad, Capacity, Tiempo de flujo, FlowTime, Estado en el que se
encuentra un recurso, ResourceState y Tiempo de espera, HoldingTime. Estos resultados se aplican a
cada fuente de datos.
Paso 7: La utilización de recursos, Resource utilization, incluye tanto la utilización programada,

“ScheduledUtilization”, como las unidades asignadas, “UnitsAllocated”, programadas,
“UnitsScheduled”, y usadas, “UnitsUtilized”. Estas variables hacen referencia a la utilización real de la
capacidad de un objeto así como a la capacidad programada media. La utilización programada,
“ScheduledUtilization”, se calcula como el ratio que resulta de dividir el tiempo real de uso de un
recurso entre el tiempo total que estaba previsto que trabajara según la programación.
Pregunta 13: ¿Cuál es la utilización de la capacidad del objeto Pedir?
Paso 8: Advierta que el tiempo de espera se muestra como “HoldingTime” del “InputBuffer” mientras que
“Content” de InputBuffer muestra el número en espera.5
Pregunta 14: ¿Cuál es el número medio (contents) en el InputBuffer de Pedir?
Pregunta 15: ¿Cuál es el tiempo medio de espera (holding time) en el InputBuffer de Pedir?
Pregunta 16: ¿Por qué el número medio de Content de Pedir es igual a la media de unidades
programadas, UnitsAllocated, con anterioridad?
Pregunta 17: ¿Cuál es la utilización del objeto Pagar?
Paso 9: Para volver al modelo, necesita seleccionar la pestaña “Facility”, que está a la misma altura que la
pestaña “Results”.
5
La terminología de SIMIO de “HoldingTime” y “Content” puede parecer que no sea estándar. Generalmente, la Teoría de Colas o
de Líneas de Espera utiliza los términos “waiting time” y “number in queue”. También “waiting line length” o “number waiting” son
términos que se utilizan en vez de “number in queue.”

Sección 1.5: Comentario
Si ha estado construyendo el modelo con nosotros, puede haber notado lo siguiente:
 El botón de deshacer/rehacer de SIMIO, undo/redo, es muy conveniente. En el caso de caminos,

puede cambiar el tipo de camino usando el botón derecho del ratón. Estas características facilitan
la posibilidad de probar, y entonces deshacer o rehacer los cambios.
 Las entidades no cambian de orientación durante la animación sino son los caminos los que
ayudan a cambiar de dirección, pero manteniendo la orientación en las líneas que representan las
colas de espera o de procesamiento (lo que puede ser una oportunidad para una nueva versión de
SIMIO).
 La herramienta visual para mostrar resultados de forma gráfica se describirá más tarde.
 La noción de una librería estándar de la que se arrastran objetos dentro del tapiz es muy similar a
la forma en que se construyen modelos a partir de módulos en Arena. En lugar de los cuadros de
diálogo de Arena, SIMIO utiliza el inspector de propiedades.
Si usted está familiarizado con el diseño orientado a objetos, Object Oriented Design (OOD), la librería de
SIMIO, [Standard Library], debería ser denominada más apropiadamente como una librería de clase, “class”
library. Son las clases de las que se crean objetos. La acción de seleccionar y mover al tapiz estos objetos es
lo que permite crear una instancia del objeto. Las propiedades, tal como se muestran en el inspector de
propiedades, son las características básicas de los objetos. Más adelante, verá cómo añadir propiedades. Las
propiedades se pueden inicializar pero no cambiar. Otro tipo de atributo, al que SIMIO denomina variable de
estado, STATE variable, puede ser incluida en el modelo si los atributos han de ser modificados durante la
simulación.

Capítulo 2
Modelizando Distancias y Desplazamientos: Un
Aeropuerto,
Nuestro objetivo es modelizar gente en su llegada al aeropuerto para pasar el proceso de facturación. En
primer lugar, sólo nos preocuparemos con el tiempo que necesitan los pasajeros para llegar al control de
seguridad, y que se puedan determinar el número de mostradores necesarios en facturación. Los pasajeros
llegan al terminal y se acercan al puesto de facturación para obtener el billete. Después del check-in, los
pasajeros se dirigen al control de seguridad.
Los pasajeros llegan de acuerdo a un modelo exponencial con una media de un minuto entre llegadas. Se
dirigen andando hacia el mostrador de facturación a un ritmo de entre 2 y 4 millas por hora (según un
modelo uniforme).
Los pasajeros cubren una distancia de 50 yardas desde la entrada al edificio hasta el check-in. Después de la
facturación, han de recorrer 65 yardas hasta el control de seguridad.
Existen en la actualidad 4 mostradores con sus respectivos operarios, que tardan entre 2 y 5 minutos por
pasajero, siguiendo una distribución uniforme. Los pasajeros esperan en una fila común a todos los puestos
según su orden de llegada.
El modelo de simulación debe ser ejecutado para un período de 24 horas.
Sección 2.1: Desarrollando el modelo
Paso 1: Cree un nuevo modelo, como el que se muestra en la Figura 2.1. Haga clic con el botón derecho en
objetos en el panel [Navigation] y vea sus propiedades. Llame al proyecto, PROJECT, “Aeropuerto”.
Incluya el valor “Pasajeros” en la propiedad Model Name. Llame al modelo, MODEL, “Aeropuerto”.
Añada una fuente o llegada, SOURCE, un servidor, SERVER, y un sumidero o salida, SINK, de a librería
estándar al tapiz Facility, y conéctelos utilizando un camino, PATH (todo esto puede ser realizado
utilizando el Add-In desde “Project Home”).
Paso 2: Haga clic y arrastre dentro del tapiz una entidad de MODELENTITY desde el panel [Project Library].
Cambie los nombres de los objetos para identificar el puesto o la operación que representan. Cambie
también el nombre de DefaultEntity a Pasajero. Cambie su símbolo a una persona utilizando la librería
de objetos y personas.
Modelizando Distancias y Desplazamientos: Un Aeropuerto, 11

Figura 2.1: El Modelo Básico
Paso 3: Incluya la velocidad de movimiento del pasajero como Random.Uniform(2,4) en millas por
hora (miles per hour), en el objeto Pasajero. Incluya el ritmo de llegadas en la propiedad interarrival
time, Random.Exponential(1) en minutos, en el objeto Llegada. Ponga como ProcessTime en
CheckIn Random.Uniform(2,5) en minutos y determine la capacidad de este elemento como 4.
Paso 4: Para los caminos, cambie la propiedad Drawn to Scale , dibujar a escala, a “FALSE” e incluya las
distancias correctas en ambos objetos. Recuerde que el camino desde la entrada a check-in es de 50
yardas mientras que el camino entre check-in y seguridad es de 65 yardas.
Sección 2.2: Utilizando la Biblioteca de Diseño 3D de Google
Paso 1: Aunque ya podríamos ver la simulación, cambiemos el símbolo del CheckIn. Se puede hacer tanto
haciendo clic en el objeto y cambiando el símbolo a alguno de los predeterminados de SIMIO, o
descargando nuevos símbolos desde Google’s 3D Warehouse. O si ya dispone de modelos en su
ordenador, importando dibujos desde ellos.
Paso 2: Para utilizar nuevos símbolos, seleccione el objeto CheckIn y elija alguna de las opciones de Project
Symbols. “Google’s 3D Warehouse” debería aparecer cuando selecciona el botón “Download Symbol”,
que le permitirá buscar el modelo que quiera. Cuando lo haya encontrado, haga clic en “Download
Model” y SIMIO los importará en una ventana en la que se pueden cambiar sus propiedades, como el
tamaño y la orientación. Pruebe a buscar “Airport Baggage”.
Paso 3: Cuando haya descargado de Google, aparece la ventana “Import”. Puede ver el símbolo descargado
en 2D o 3D. El símbolo tiene su longitud, anchura y altura en metros, variables que pueden ser
modificadas. También se muestra una ayuda, “hint”, sobre la altura, en relación a la de una persona.
Finalmente, se puede rotar el objeto de forma que tenga la orientación6 adecuada.
Paso 4: Posicione el CheckIn de forma que el input BASICNODE, la fila InputBuffer, y la fila de Processing
se asemejen a un aeropuerto, siguiendo la Figura 2.2.
Paso 5: Ejecute el modelo y ajuste la animación (en 2D y 3D). Modifique la fila Processing de CheckIn de
forma que sólo 4 personas puedan estar en proceso a la vez (recuerde que la capacidad es cuatro).
6
Utilice la ventana “hint”, que se abre al presionar la tecla “h” del teclado: ayuda a rotar, dimensionar y mover objetos en SIMIO.
Processing (para Símbolo
4 puestos) Descargado
Input
Input Buffer
Queue
Figura 2.2: CheckIn
Sección 2.3: Examinando los resultados
Los resultados de una simulación son variables aleatorias producidas por las entidades que fluyen por el
modelo y son procesadas. Su llegada es aleatoria lo mismo que los tiempos de proceso. Así, una repetición o
ejecución del modelo resulta en un único valor experimental. Este valor no es preciso, por lo que
necesitamos hacer muchas repeticiones para mejorar la precisión.
Paso 1: Cambie la duración de una repetición a 24 horas y ejecute la simulación. Cuando finalice, haga clic
en “Results” y accede a la pantalla de resultados.
Pregunta 1: ¿Cuál es el número medio de personas esperando en el mostrador de facturación?
Pregunta 2: ¿Cuánto tiempo esperan de media?
Pregunta 3: ¿Piensa que son buenos resultados? ¿Por qué sí o por qué no?
Paso 2: Para ganar en confianza en nuestros resultados, el modelo ha de ser simulado varias veces. En la
pestaña “Project Home” se puede añadir un experimento que facilite la ejecución múltiple de un modelo.
En la pestaña “Design”, cambie el número de repeticiones a 10 y realice el experimento. Debe tardar
poco y el final de cada repetición debe ir apareciendo en la ventana de comentarios en la parte de debajo
de la pantalla. Las repeticiones no tienen que ser realizadas en un orden secuencial, pues dependerá de
las características del ordenador.
Paso 3: Puede ver los resultados en la tabla “Pivot Grid” o en la pestaña “Reports”. Los campos incluidos
ahora son el mínimo “Minimum”, el máximo “Maximum”, y el error “Half-width”. El error es la mitad
de la anchura de un intervalo de confianza del 95%. El nivel de confianza, “Confidence Level”, puede
ser modificado en las propiedades del experimento, Experiment Properties.
Pregunta 4: ¿Cuáles fueron los resultados para el número de pasajeros en el sistema de facturación, en
términos medios, mínimos y máximos, y de error?
Paso 4: Se puede añadir la desviación típica o estándar de la media haciendo clic con el botón derecho sobre
Filter Fields, y seleccionando la opción Std. Dev de “Show Field List”.
Pregunta 5: ¿Qué valor ha obtenido para la desviación típica del número de pasajeros en el sistema?

Paso 5: Para quitar un campo, arrástrelo a la lista de campos, PivotGrid Field List.
Sección 2.4: Usando experimentos
Suponga ahora que queremos analizar el efecto de los cambios en la capacidad o número de operarios en los
mostradores de facturación o check-in. Podríamos simplemente cambiar la capacidad y volver a ejecutar la
simulación para obtener nuevos resultados. Una forma mejor es montar un experimento de SIMIO,
“experiments”.
Paso 1: En el panel Facility, seleccione el objeto CheckIn. Haga clic con el botón derecho en la propiedad
capacidad inicial, Initial Capacity, y seleccione “Set Referenced Property”. Cree una nueva propiedad,
“Create New Referenced Property”, y denomínela CheckInCapacity.
Paso 2: En la pestaña “Project Home”, cree un nuevo experimento, “New Experiment”, y vea la pestaña de
diseño, “Design”. Se muestra nuestra nueva propiedad de referencia en una nueva columna.
Paso 3: Añada nuevos escenarios, nuevas filas en la tabla, y cambie los valores de la nueva variable
CheckInCapacity a 2, 3 y 4. Puede añadir filas haciendo clic en el símbolo asterisco “*” de la primera
columna. La tabla del experimento debe asemejarse a la mostrada en la Figura 2.3.
Propiedad de
Referencia
Figura 2.3: Escenarios del Experimento

Paso 4: Ejecute el experimento, que se compone de 10 repeticiones de cada escenario. Se finaliza
rápidamente puesto que SIMIO utiliza todos los procesadores de su ordenador.
Paso 5: Advierta que la tabla de resultados, Pivot Grid, incluye ahora columnas para cada escenario.
Pregunta 6: ¿Cuál es el tiempo medio en el sistema mínimo para el Scenario Cap4?
Paso 6: La pestaña de resultados, “Reports”, es una buena forma de comparar escenarios, pues estos se
ordenan bajo cualquier variable.
Pregunta 7: ¿Cuál es el valor medio y el error para el tiempo medio de permanencia en el sistema? ¿Por
escenario?
Paso 7: Suele ayudar y es aconsejable añadir variables de salida o respuesta, “responses”, en el experimento.
Simplemente, haga clic en “Add Response” en la pestaña “Design”. Añada las siguientes dos respuestas
con las siguientes expresiones:
 Tiempo en el Sistema (TimeInSystem): Pasajero.TimeInSystem.Average

 Número total atendido (TotalNumberProcessed): Pasajero.NumberDestroyed
Paso 8: Haga reset y empiece otra vez la simulación mirando a los resultados en los gráficos de respuesta
(“Response Chart” results) a la vez que la tabla de resultados (véase Figura 2.4). Para organizar las

pestañas, haga clic en la pestaña que desea mover y arrástrela a la posición que desee en la ventana.
También lo puede hacer con el botón derecho, para moverlas de forma agregada.
Respuestas
Gráficos de
Máximo respuesta
Mínimo Percentil del

75%
Media
Percentil del
25% Mediana
Figura 2.4: Resultados obtenidos

Paso 9: Claramente, a medida que la capacidad sube (hay más operarios), el tiempo en el sistema baja y el
número de clientes atendidos aumenta.
Paso 10: Puede modificar la gráfica utilizando las opciones proporcionadas por el “Response Chart”.
La gráfica muestra por defecto el máximo valor observado de la variable, el percentil del 75% o cuartil
3, la mediana o el percentil del 50%, el percentil del 25% o cuartil 1 y el mínimo (véase Figura 2.4). La
sombra proporciona además el intervalo de confianza de la media, con el nivel de confianza especificado
en el experimento.
 La desviación típica que se muestra en el “Results Field” es realmente el error estándar

(desviación típica de la media). No se calculan las desviaciones típicas de una repetición del
modelo, aunque sería posible y disponer de ella ayudaría en ciertos casos (por ejemplo, al
determinar políticas de gestión de stocks). El peligro estriba en que la desviación típica tomando
como base una única repetición no puede ser utilizada para calcular un intervalo de confianza
robusto, ya que las observaciones no provienen de una distribución normal y no son
independientes e idénticamente distribuidas (iid).
 La tabla de los experimentos es similar al Process Analyzer de Arena. SIMIO, sin embargo,
permite ejecutar repeticiones y escenarios en múltiples procesadores en paralelo. Los gráficos en
SIMIO se denominan SMORE (SIMIO Measure of Risk and Error) plots (para más información,
lea el “Experiment Response Chart” en la documentación de SIMIO).
 El Capítulo 12 describirá con más detalle la forma de analizar resultados: Gráficos SMORE,
selección de alternativas (selección de subconjuntos - subset selection -, ranking y selección -
ranking/selection -, y optimización).
 En Arena, las salidas de los modelos se gestionan en MSAccess. SIMIO gestiona los resultados
internamente.

Capítulo 3
Caminos con Desvíos, Tablas de Ritmos y Dependencias
entre Entidades: Aeropuerto bis
En un aeropuerto, existe normalmente más de un tipo de facturación, así como más de un tipo de pasajero
(por ejemplo, auto check-in o un pasajero internacional). Nuestro objetivo es mejorar el modelo desarrollado
en el Capítulo 2, para dirigir los flujos hacia los diferentes mostradores de facturación cambiando los
patrones de llegada de los pasajeros en función de su tipología. Los cambios se realizan utilizando tablas de
datos (data tables) y de ritmos (rate tables). Como en el capítulo anterior, nuestra principal preocupación es
controlar el tiempo que tardan los pasajeros en facturar y llegar al control de seguridad, buscando determinar
el número de mostradores de facturación necesarios.
Sección 3.1: Elección de Caminos
Paso 1: Borre el objeto EXPERIMENT del modelo del aeropuerto desarrollado en el capítulo anterior.
Mejoraremos el modelo para incluir la elección de tres posibles rutas a seguir por los pasajeros que
llegan al aeropuerto. Los pasajeros que necesitan facturar y coger sus billetes pueden tanto facturar en la
acera exterior del terminal o en los mostradores principales dentro del aeropuerto, mientras que el resto
que no ha de facturar puede ir directamente hacia el control de seguridad (véase Figura 3.1).
Ruta1
Ruta2
Ruta3
Figura 3.1: Creando Caminos

Ruta1: Los pasajeros que facturan en la acera necesitan recorrer 10 yardas para llegar al mostrador
donde un único operario emplea para facturar entre 1 y 5 minutos, con una valor más habitual o
moda de 2 minutos. Una vez que han facturado, recorren 125 yardas hasta el control de seguridad.
Ruta2: Los pasajeros que han realizado la facturación online y no necesitan pasar por el mostrador,
sólo necesitan recorrer las 125 yardas hasta el control de seguridad.
Ruta3: El resto de pasajeros, que van a utilizar los mostradores dentro del edificio, necesitan recorrer
50 yardas hasta alcanzar uno de los dos mostradores que existen. Los operarios emplean por pasajero
entre 3 y 10 minutos, según un modelo uniforme. Para llegar al control de seguridad, han de recorrer
65 yardas más.
Paso 2: Se ha observado la distribución de probabilidades por ruta de los pasajeros (Tabla 3.1).

Tabla 3.1: Tipos de Pasajero
Check-in Porcentaje
Acera 10%
Mostrador 70%
No Check-in (Carry on) 20%
Paso 3: Para modelizar la decisión de un pasajero sobre su posible ruta, se ha de utilizar la propiedad
Selection Weight , de los objetos camino, PATH. La probabilidad de elegir una ruta en particular es el
peso otorgado a esa ruta dividido por la suma de los pesos otorgados a cada una de las rutas alternativas.
Incluya ahora los pesos a cada ruta (véase Figura 3.2).
Peso según
Probabilidad
Figura 3.2: Pesos para Cada Ruta

Paso 4: Recuerde que hay que seleccionar también la regla de conexión, en este caso de salida, Outbound
Link Rule. En esta caso hay que hacer referencia a las probabilidades, por lo que se elige la opción “By
Link Weight” en Output@Llegada (véase Figura 3.3).
Reglas de
Conexión
Figura 3.3: Regla de Salida

Paso 5: Simule el modelo una vez, con una duración de 24 horas. Puede que quiera mejorar la animación.
Pregunta 1: ¿Cuál es el número medio de pasajeros esperando tanto en la acera como en los
mostradores?
Pregunta 2: ¿Y los tiempos medios de espera en ambos procesos de facturación?
Caminos con Desvíos, Tablas de Ritmos y Dependencias entre Entidades: Aeropuerto bis 17
Pregunta 3: ¿Cuál es el tiempo medio de espera en el sistema de facturación?
Sección 3.2: Cambiando el Ritmo o Patrón de Llegada
Los pasajeros no suelen llegar con un ritmo constante a lo largo de todo el día a un aeropuerto (incluso si
llegan de forma aleatoria), por lo que debemos ampliar nuestro modelo para manejar esa situación. Nuestro
nuevo enfoque es permitir variaciones en los ritmos de llegada a lo largo del día. Para modelizar estos
cambios de ritmo, utilizaremos un objeto en SIMIO que se denomina tabla de ritmos, RATE TABLE. Esta
tabla se ha de referenciar cuando se determine la lógica de llegadas de un objeto fuente, o SOURCE. Es
importante comprender que los tiempos entre llegadas consecutivas para estos ritmos asumirán que
provienen, como es habitual, de una distribución exponencial. La media de esta distribución es lo que cambia
durante el día. Si estos tiempos son uniformes, es conocido que el número de llegadas sigue una distribución
Poisson. Como el parámetro (su media) cambia con el tiempo, se denomina formalmente como un proceso
de llegadas “Poisson no-homogéneo”, o NHPP (Non-Homogeneous Poisson Process). De esta forma, cuando
se utiliza una tabla de ritmos de SIMIO, se asuma que el proceso de llegadas es NHPP.
Paso 1: Para crear un patrón de llegadas, RATE TABLE, seleccione los datos en la pestaña “Data” y luego
haga clic en Create→Rate Table, asignando el nombre PassengerArrivalRate. La Tabla 3.2 muestra el
flujo por hora a lo largo de las 24 horas del día. Se muestra que llegan más pasajeros por la mañana entre
las 6 y las 9 y por la tarde entre las 18 y las 20 horas. Un ritmo de 0 implica que no llegan clientes
durante esa hora.
Tabla 3.2: Patrón Horario de Llegadas

Comienzo del Intervalo Final del Intervalo de Tiempo Ritmo de
de Tiempo Llegada
Día 1, 00:00:00 Día 1, 01:00:00 0
Día 1, 01:00:00 Día 1, 02:00:00 0
Día 1, 02:00:00 Día 1, 03:00:00 0
Día 1, 03:00:00 Día 1, 04:00:00 0
Día 1, 04:00:00 Día 1, 05:00:00 0
Día 1, 05:00:00 Día 1, 06:00:00 30
Día 1, 06:00:00 Día 1, 07:00:00 90
Día 1, 07:00:00 Día 1, 08:00:00 100
Día 1, 08:00:00 Día 1, 09:00:00 75
Día 1, 09:00:00 Día 1, 10:00:00 60
Día 1, 10:00:00 Día 1, 11:00:00 60
Día 1, 11:00:00 Día 1, 12:00:00 30
Día 1, 12:00:00 Día 1, 13:00:00 30
Día 1, 13:00:00 Día 1, 14:00:00 30
Día 1, 14:00:00 Día 1, 15:00:00 60
Día 1, 15:00:00 Día 1, 16:00:00 60
Día 1, 16:00:00 Día 1, 17:00:00 75
Día 1, 17:00:00 Día 1, 18:00:00 100
Día 1, 18:00:00 Día 1, 19:00:00 90
Día 1, 19:00:00 Día 1, 20:00:00 30
Día 1, 20:00:00 Día 1, 21:00:00 0
Día 1, 21:00:00 Día 1, 22:00:00 0
Día 1, 22:00:00 Día 1, 23:00:00 0
Día 1, 23:00:00 Día 2, 00:00:00 0

Aunque puede modificar la duración y el número de los intervalos de tiempo durante los cuales el
ritmo de llegada es constante, no se puede modificar el ritmo, que está fijado según los eventos por
hora, events per hour.
Paso 2: Modifique la fuente Llegada (véase la Figura 3.4 en busca de detalles).
Modifique las
llegadas
Figura 3.4: Especifique un Ritmo de Llegada Variable

Paso 3: Ejecute el modelo otra vez y analice los resultados.
Pregunta 4: ¿Cuál es el tiempo medio de espera en cada uno de los tipos de mostrador?
Pregunta 5: ¿Cuál es el tiempo medio de facturación de un pasajero?
Sección 3.3: Diferenciando entre Entidades: Tablas de Datos
En un aeropuerto aparecen distintos tipos de pasajero. Algunos son viajeros nacionales mientras que otros
son viajeros internacionales. Algunos pasajeros son minusválidos y requieren atención especial. Los
diferentes tipos de pasajeros implican distintos tipos de proceso. Para modelizar estos tres casos, se usan
tablas de datos, Data Tables.
Paso 1: Para crear una tabla de datos, DATA TABLE, haga clic en “Tables” en la pestaña “Data”, y luego en
“Add Data Table.” Llámela PassengerTable. En nuestra tabla de datos, se ha de mostrar el tiempo de
procesos para cada uno de los tres tipos de pasajero en cada mostrador de facturación. Seleccione las
propiedades en la opción “Standard Property” en la sección Properties. La propiedad PassengerPriority
será de tipo entero, Integer, mientras que los tiempos de facturación serán propiedades tipo Expression7.
Las prioridades 1, 2, y 3 representan los pasajeros nacionales, internacionales y minusválidos (Figura
3.5).
Propiedades
Figura 3.5: La Tabla de Datos
7
Si primero especifica el nombre “General”, se convertirá en el valor por defecto de la propiedad “DisplayName”.
Aunque los tiempos de facturación estén en minutos, no tenemos que especificar sus unidades, “Unit
Type” (véase Figura 3.68).
Dejar sin
Especificar las
Unidades de
Tiempo
Figura 3.6: Propiedades de Check-In

Paso 2: Referenciaremos estos tiempos de llegada directamente desde la tabla de datos, utilizando la
propiedad, InitialPriority , y la variable de estado Priority del objeto Pasajero. Para inicializar las
prioridades de forma diferente para representar cada uno de los tipos de Pasajero, debemos utilizar una
distribución discreta, Discrete (introducida según su distribución acumulada). En la Figura 3.7, cada
tipo de pasajero que es igualmente posible.
Distribución
Prioridad Discreta donde
Inicial cada tipo de
pasajero es
igualmente
posible (un
tercio)
Figura 3.7: Propiedades de Pasajero

Paso 3: Una propiedad, “property”, de un objeto se inicializa cuando se crea el objeto y no puede ser
cambiada. Aún es más, comparte sus valores con todos los demás objetos. Una variable de estado, “state
variable”, es una característica de un objeto que sí puede ser alterado. Además, las variables de estado
pueden ser asociadas con objetos individuales y así cada objeto tiene sus propios valores (pero
modificables). La propiedad InitialPriority se define en SIMIO para todas las entidades del modelo, pero
se asigna inmediatamente por SIMIO cuando se crea la correspondiente variable de estado Priority
(también definida por SIMIO).
Pregunta 6: ¿Dónde se puede encontrar la definición de MODELENTITY sobre la variable de estado

Priority?
8
Puede parecer obvio que las unidades de las propiedades de tiempo se deben especificar; sin embargo, si las unidades de tiemp o no
están en horas (véase Paso 3), SIMIO no hará la interpretación apropiada. Por eso es mejor dejar las unidades sin especificar y no se
intentarán convertir los datos hasta que se usen.
Paso 4: Necesitamos ahora especificar el tiempo de proceso de los distintos mostradores de facturación para
que dependa del tipo de pasajero. Para ello se trabaja con la variable de estado Priority:
 En CurbSideCheckin:
PasajeroTabla[Pasajeros.Priority].CurbSideCheckInTime
 En CheckIn:
PasajeroTabla[Pasajeros.Priority].InsideCheckInTime
Perciba que lo que va entre corchetes [] se usa para designar la fila específica dentro de la tabla, de
forma similar a las matrices en los lenguajes de programación. Desafortunadamente, el editor de
expresiones no conoce las propiedades de la tabla de datos, DATA TABLE, por lo que se debe teclear la
propiedad dentro de la expresión. También, asegúrese de que las unidades del tiempo de proceso son
minutos.
Paso 5: Ejecute el modelo. Acuérdese de que no llega nadie hasta las 5am, por lo que no hay animación
hasta ese momento.
Pregunta 7: ¿Cuál es el tiempo medio de espera por tipo de facturación (Curbside y Inside)? 9
Pregunta 8: ¿Cuál es tiempo medio de facturación para un pasajero?
Sección 3.4: Más sobre Rutas
Hay veces que las filas en los mostradores tradicionales de dentro del edificio parecen saturadas. Decidimos
añadir un segundo mostrador dentro del terminal para atender a los pasajeros durante los períodos pico.
Esencialmente, los pasajeros se dirigirán a aquella fila que tenga menos gente. La distancia desde este
segundo grupo de mostradores al control de seguridad es de 75 yardas.
Paso 1: Añada el segundo mostrador. Llámelo CheckIn2. Asuma que tiene una capacidad de 1 y un tiempo
de proceso igual a los de los otros mostradores. Añada un camino adicional de 75 yardas hasta el control
de seguridad, Security.
Paso 2: Hay que modelizar la decisión que toman los pasajeros que facturan en el interior del terminal de
forma que se dirijan a la fila con menos gente. Hay varias formas para modificar el modelo. Quizá la
forma más obvia sea añadir un TRANSFERNODE que manda pasajeros a la cola más corta. La distancia
desde LLEGADA a este TRANSFERNODE es de 50 yardas (recuerde que el peso es 70 para este camino y que
tendrá que borrar el camino original hacia el objeto CheckIn).
 En el TRANSFERNODE se debe especificar la regla Outbound Link Rule como “By Link Weight”
 Marque las propiedades de pesos, Selection Weights, de los dos caminos que salen del
TRANSFERNODE (el “valor” de una expresión verdadera, “true”, es 1 y 0 si es falsa, “false”)
(1) Hacia CheckIn:

CheckIn.InputBuffer.Contents.NumberWaiting <=
CheckIn2.InputBuffer.Contents.NumberWaiting
9
Los resultados del modelo no se separan automáticamente por tipo de pasajero. Hay que utilizar conceptos (por ejemplo, añadir tus
propias variables de resultados) que se describen en el Capítulo 5 y en el Capítulo 6.
(2) Hacia CheckIn2:
CheckIn2.InputBuffer. Contents.NumberWaiting <
CheckIn.InputBuffer.Contents.NumberWaiting
Pregunta 9: ¿Cuál de los dos mostradores es el elegido cuando existen empates porque las filas
InputBuffer tienen el mismo número de pasajeros (por ejemplo, si las dos están vacías)?
Pregunta 10: ¿Cuál es la utilización de CheckIn2? ¿Tiene sentido tener los dos mostradores?
Sección 3.5: Horarios y Turnos de Trabajo
Supongamos que deseamos tener abierto el segundo mostrador sólo entre las 10am y las 6pm. Esta
problemática requiere la utilización de horarios de trabajo, que serán especificados con el componente
“Schedules” de la pestaña “Data”.
Paso 1: Haga clic en el botón “Add Schedule” en el icono “Schedules” de la pestaña “Data”. Denomine este
horario como SecondCheckInStation. Cambie el patrón de días de trabajo, Days in Work Pattern, a 1 –
este horario se repetirá todos los días.
Paso 2: En la pestaña de ciclo de trabajo, “Work Cycle”, haga clic con el botón derecho en la ventana para
que aparezca el editor de ciclos, “Edit Cycle Item”. Incluya un valor de 1 en la variable que especifica
que este recurso sí trabaja durante un período reducido, On Shift Value, y que empieza su jornada a las
10am y la acaba a las 6pm.
Paso 3: En la tapiz Facility, haga clic en el objeto CheckIn2. Cambie el tipo de capacidad de trabajo,
Capacity Type a WorkSchedule y el horario Work Schedule a SecondCheckInStation (Figura 3.8).
Horario de
Trabajo
Figura 3.8: Especificando un Work Schedule

Paso 4: Ahora, necesitamos asegurarnos de que la gente que elige facturar dentro del terminal sólo va hacia
el segundo mostrador CheckIn2 cuando esté abierto. Se necesita otro TRANSFERNODE (Figura 3.9).
Input@CheckIn
Llegada de
Pasajeros TRANSFERNODE en el que se
elige la fila más corta
Nuevo TRANSFERNODE
para elegir un mostrador Input@CheckIn2
que esté abierto
Figura 3.9: Añadiendo un TransferNode para Mejorar la Lógica

 El nuevo TRANSFERNODE debe dirigir también a los pasajeros según el peso By Link Weight.
 El camino hasta Input@CheckIn tiene una distancia de 0 y una propiedad Selection

Weight: TimeNow <=10 || TimeNow>=18

 El camino hacia TRANSFERNODE para elegir la fila más corta tampoco tiene longitud y como
propiedad Selection Weight: TimeNow > 10 && TimeNow <18
Paso 5: Ejecute el modelo y obtenga los siguientes resultados:
Pregunta 11: ¿Cuál es el tiempo medio de facturación de un pasajero?
Pregunta 12: ¿Cuál es el tiempo medio de espera de un pasajero en el mostrador situado en la acera?
Pregunta 13: ¿Cuál es el tiempo medio de espera de un pasajero en el mostrador del terminal?
Pregunta 14: ¿Cuánto tiempo está trabajando el operario que está situado en el mostrador de la acera?
¿Porcentaje de utilización?
Pregunta 15: ¿Cuánto tiempo están trabajando los operarios que están situados en los mostradores
interiores? ¿Porcentaje de utilización?
Paso 6: Dése cuenta que en la simulación, hay pasajeros que están en fila cuando el mostrador CheckIn2
cierra porque acaba su jornada. Allí se quedan estancados; solucionaremos el problema en otro capítulo
más adelante.
 La especificación de NHPP en SIMIO es casi idéntica a la de Arena, incluso cuando se fija en

número de unidades según el ritmo de llegada (llegadas por hora).
 SIMIO cambia la probabilidad acumulada y su valor de cómo se especificaba una distribución
discreta en Arena. Ambas requieren que se incluyan de forma acumulada. Tenga cuidado.
 No resulta obvio que las unidades de medida no deban ser especificadas cuando se usan en las
tablas de datos otras que no sean horas (o metros). La razón no está clara y se basa en cómo
SIMIO convierte tiempos en horas y distancias en metros. Por ejemplo, supongamos que su tabla
de datos incluye un tiempo de proceso de 30 minutos (especificando minutos). SIMIO
almacenará este valor como 0.5 horas. Si entonces se referencia este tiempo como tiempo de
proceso en minutos, el valor se usa como si fuera en minutos. Al dejarlo sin especificar, los datos
de la tabla no se convierten y se interpretan de forma correcta. Más aún, podríamos decir
también que el tiempo de proceso es en horas y si la tabla de tiempos utiliza minutos como
unidad, la conversión también es correcta. Lo que se ha dicho sobre tiempo también aplica a
distancias, pues la unidad básica en SIMIO es el metro. Una de las razones de utilizar este
sistema de conversión es que se referencia directamente la propiedad de tabla a través de su fila
y SIMIO no se acuerda de las unidades de esta propiedad. Más adelante, utilizaremos referencias
que no emplean una referencia directa y por tanto no serán necesarias estas manipulaciones de
unidades.
 En SIMIO, cuando la capacidad de un servidor se hace cero y todavía hay entidades que se están
procesando, se acabarán las operaciones. Los usuarios de Arena reconocerán esta situación como
una de las tres reglas de resolución de conflictos (“ignore”, wait, preempt). Si ésta no es la regla
deseada, necesitará implementar una regla adicional utilizando conceptos más avanzados, que
serán descritos más adelante.
Capítulo 4
Secuencias y Viajeros: Célula de Fabricación
 Más opciones de modelización utilizando objetos básicos SOURCE, SERVER, y SINK.
 Secuencias de entidades.
 Uso de vehículos
Una pequeña célula de fabricación está compuesta por tres estaciones de trabajo en la que se procesan cuatro
piezas distintas. Las estaciones A, B, y C, se disponen de forma que las piezas sigan una ruta circular (Figura
4.1). Si una pieza cumple su último proceso en la Operación C, tendrá que ir a la Operación A y luego a la B
antes de dirigirse hacia la salida. Se desea realizar una simulación de una semana de 5 días, con un jornada
de trabajo diaria de 8 horas, para un total de 40 horas en una semana.
Llegada Salida de
de Piezas Dirección de Piezas
Movimiento
Figura 4.1: Disposición en Planta o Layout

Layout:
Todas las piezas llegan a la entrada, “Parts Arrive”, y salen de la planta por la salida, “Parts Leave”. La
velocidad de movimiento es constante a 2 millas por hora. Piense que las unidades de velocidad por defecto
en SIMIO, Initial Desired Speed, para las distintas entidades es metros por segundo.
Las distancias (yardas) entre estaciones se muestran en la Tabla 4.1.
Tabla 4.1: Distancias entre Estaciones

Caminos Distancias (yardas)
Desde la Entrada a la Operación A 25
Desde la Operación A a la Operación B 35
Desde la Operación B a la Salida 20
Desde la Salida a la Operación C 30
Desde la Operación C a la Entrada 40

Piezas:
La llegada de piezas es como sigue10:
 La Pieza 1 llega aleatoriamente con una media de 15 minutos entre llegadas.
 La Pieza 2 tiene un tiempo entre llegadas con una media de 17 minutos y una desviación típica de 3
minutos.
 La Pieza 3 puede llegar con un tiempo entre llegadas consecutivas entre 14 y 18 minutos.
 La Pieza 4 llega en lotes de 5, con una cadencia prácticamente exacta de 1 hora y 10 minutos.
Pregunta 1: ¿Qué distribuciones elegiría para modelizar estos cuatro procesos de llegada?
Cada una de los tipos de piezas (entity) presenta una ruta distinta de procesamiento. De hecho, no todas
tienen que pasar por todas las estaciones. Las secuencias se muestran en la Tabla 4.2.
Tabla 4.2: Secuencia por Pieza
Paso 1 2 3
Pieza 1 Operación A Operación C
Pieza 2 Operación A Operación B Operación C
Pieza 3 Operación A Operación B
Pieza 4 Operación B Operación C
Propiedades de las Estaciones:

 La Operación A es una máquina con un tiempo de proceso que varía entre 2 y 8 minutos con un
valor modal de 5 minutos.
 La Operación B tiene dos máquinas, cada una con un tiempo de proceso que varía entre 5 y 11
minutos, con un tiempo más habitual de 9 minutos.
 La Operación C se compone de dos máquinas que operan durante las cuatro primeras horas de cada
día y una máquina que lo hace durante las últimas cuatro horas. Cada una tiene un tiempo de proceso
que varía entre 2 y 11 minutos con una moda de 6 minutos.
Pregunta 2: ¿Qué distribuciones siguen los tiempo de proceso?
Sección 4.1: Construyendo el Modelo
Paso 1: Primero, cree el modelo en SIMIO utilizando cuatro fuentes, SOURCES, para cada una de las cuatro
entidades (arrastrando cuatro MODELENTITIES dentro del tapiz). Son necesarias cuatro fuentes de piezas
porque cada una tiene su propio proceso de llegada. Necesitaremos tres servidores, SERVERS (uno para
cada estación) y un único sumidero, SINK. Denomine cada objeto de forma que sean fácilmente
reconocibles (Figura 4.2).
Paso 2: Probablemente el mejor método para simular la circulación circular sea utilizar un nodo básico
BASICNODE, tanto en la entrada como en la salida de cada estación11. Esto permite a las entidades seguir
el patrón de las secuencias sin tener que añadir procesos no deseados.
10
Por ahora, le dejaremos pensar sobre cuál es la distribución más adecuada en función de estos parámetros.
Secuencias y Viajeros: Célula de Fabricación 25

Paso 3: Conecte los objetos utilizando conectores, CONNECTORS, y caminos, PATHS. Percátese de que como
no hay tiempo o distancia a recorrer entre los caminos circulares y las estaciones, usaremos conectores.
Las distancias entre estaciones se calcularán utilizando cinco caminos que conectan cada nodo de
entrada y de salida. Asegúrese que dibuja los conectores y los caminos en la dirección correcta – si hace
un zoom, verá las “flechas” como se muestra en la Figura 4.2.
Conectores
Nodo
Básico
Caminos
Figura 4.2: Modelo Inicial

Paso 4: Cambie las propiedades de cada entidad de forma que se muevan a la velocidad deseada de 2 millas
por hora12.
Paso 5: Cambie las propiedades de las fuentes de forma que incluyan la pieza y los patrones de llegada
correctos. Elegimos la distribución Exponencial, Normal, y Uniforme, respectivamente, para los tiempos
de llegada de las piezas 1, 2, y 3, incluyendo los parámetros proporcionados para cada caso. Para la
Pieza 4, elegimos un tiempo entre llegadas constante de 70 minutos y en la propiedad lote, Entities Per
Arrival, introducimos un valor de 5.
Paso 6: Incluya las distancias entre estaciones que cubren cada uno de los cinco caminos. Tendrá que
especificar como “False” la propiedad Drawn To Scale para cada camino.
Paso 7: Utilice para el tiempo de proceso de cada estación la distribución Beta habitual en la técnica Pert de
control de duración de tareas, Pert (BetaPert). En general, se prefiere la distribución Beta a Triangular.
Se especifican las dos con los mismos parámetros (mínimo, moda, máximo), pero no son tan probables
los valores extremos, lo que suele representar más fiablemente los tiempos de proceso.
Sección 4.2: Especificando las Capacidades
Paso 1: Especifique las capacidades de la Operación A y la Operación B como “1” y “2”, respectivamente.
Para la Operación C, necesitaremos añadir un horario que recoja los cambios en capacidad a lo largo de
la jornada.
11
Un TRANFERNODE para la entrada/salida de una estación romperá la secuencia interna de SIMIO en cuanto a los pasos de las piezas
si no es cuidadoso.
12
Seleccione las cuatro entidades utilizando la tecla Ctrl y especifique la velocidad simultáneamente para todas las entidades.
Paso 2: En la pestaña “Data”, seleccione “Schedules” en el panel izquierdo, y luego “Add Schedule”. Llame
al horario, work schedule, ScheduleForC y deje sin rellenar la propiedad de fecha de inicio, Starting
Date, que será identificada en las opciones del menú de ejecución, Run.
SIMIO repetirá el ciclo de trabajo tantas veces como días haya en el patrón de trabajo. Dado que
nuestra simulación empezará a las 12am y durará 40 horas, hemos de rellenar el campo “días” como
“1” en la propiedad Work Pattern y dejar que se repita el ciclo una vez pasadas 24 horas.
Señale ahora las cuatro primeras horas de la pestaña “Work Cycle” empezando a las 12am y haga
clic con el botón derecho para añadir un nuevo elemento en el ciclo de trabajo. Cuando aparezca la
ventana de diálogo, cambie la opción a On Shift con un valor de “2” y haga clic en OK. Señale
después las cuatro siguientes horas, añada un elemento, y cambie la opción a On Shift con un
valor de “1”. Repita este proceso para todo el día.
Paso 3: Vuelva a la pestaña “Facility” y asigne a la propiedad Capacity Type de la Operación C el valor
“WorkSchedule”, incluyendo ScheduleForC.
Pregunta 3: ¿Durante cuántas horas en un día de 24 horas es la capacidad de la Operación C igual a 2?
Sección 4.3: Incorporando Secuencias
Según la configuración actual de nuestro modelo, las entidades se separarán en los nodos en función de
pesos y de la dirección del enlace. Sin embargo, deseamos que las piezas sigan una secuencia establecida de
estaciones. Queremos estar seguros que siguen una ruta circular hasta que lleguen al nodo que les dirige a la
estación apropiada. Para modelizar esta situación, utilizaremos las denominadas Tablas de Secuencias,
“Sequence Tables” (pestaña “Data”).
Paso 1: Haga clic en el botón con el que se añade una tabla, “Add Sequence Table”, y denomine la nueva
tabla como SequencePart1 para que corresponda con la primera pieza. Añada otras tres tablas, una para
cada una de las otras tres piezas.
Paso 2: Añada la secuencia de nodos que debe seguir la Pieza 1. Sólo es necesario incluir los nodos a visitar
así como la salida. Una vez que la secuencia está lista, siempre seguirá la ruta más corta hasta llegar al
primer nodo de la lista. La secuencia correcta para la Part1 se detalla en la Figura 4.313.
Asegúrese de
incluir la salida en
la secuencia
Figura 4.3: Secuencia para la Pieza 1

Paso 3: Incluya la secuencia para cada una de las otras tres piezas. Los nombres de las estaciones pueden
aparecer de forma diferente en función de cómo hayan sido denominados.
13
Vea que se especifican los nodos de entrada de los SERVERS y SINK en vez de los objetos.

Paso 4: Vuelva a la pestaña “Facility” y haga clic en la entidad Part1. Establezca la propiedad de secuencia
inicial, Initial Sequence, en “SequencePart1”, que ha sido creada con anterioridad para la Pieza 1. Haga
lo mismo para las otras entidades y sus secuencias.
Paso 5: Para cada uno de los 7 nodos, TRANSFERNODES (nodos de salida de cada fuente y estación), cambie la
propiedad de destino, Entity Destination Type, a “By Sequence”. Cuando por primera vez una entidad
pasa por uno de los nodos en que la opción es “By Sequence”, el nodo marca como destino de la entidad
el valor del indicador de la primera fila de la tabla de secuencias, SEQUENCE TABLE. Después de eso,
cada vez que una unidad pasa por un nodo de transferencia con destino “By Sequence”, el indicador de
fila de la tabla se incrementa en 1 y el destino de la entidad se marca como el siguiente nodo en la
tabla14.
Pregunta 4: Al pasar por un BASICNODE, ¿cambiará el indicador de fila de una tabla de secuencias,
SEQUENCE TABLE?
Paso 6: Antes de ejecutar la simulación, puede ser apropiado cambiar los colores de cada una de las piezas
de forma que sea fácil distinguirlas en el modelo. También ayudará para verificar que siguen la
secuencia correcta. Ejecute la simulación durante 40 horas a un ritmo lento para cerciorarse de que las
piezas siguen la secuencia correcta.
Pregunta 5: Desactive las llegadas de todos los tipos de piezas menos de 1. ¿Sigue la secuencia correcta?
Sección 4.4: Mejora: Carritos de Transferencia
Podemos ahora aprender que en lugar de que dejen el sistema, las piezas han de ser transportadas en un
carrito hasta el almacén que está situado a 300 yardas. El carrito puede transportar un máximo de 3 piezas a
una velocidad de 4 pies por segundo. Después de descargar las piezas, ha de volver a recoger un nuevo lote
de piezas o esperar a que haya alguna para ser transportada. El carrito no tiene por qué estar lleno para
dirigirse al almacén, esto es, llevará las piezas que estén disponibles, en este caso, 1, 2 ó 3.
Paso 1: Borre el conector entre el objeto salida y el nodo básico anterior. Incluya un nodo de transferencia,
TRANSFERNODE, entre los dos. Llame a este nuevo nodo TransferCart. Conecte el BASICNODE al
TRANSFERNODE con un camino, PATH, de 10 yardas de longitud. Conecte el nodo de transferencia al
sumidero con un camino o PATH (asegurando que es bidireccional, bidirectional, de forma que el carrito
pueda moverse en ambas direcciones). Fije la longitud del camino en 300 yardas.
Paso 2: Arrastre dentro del tapiz un vehículo, VEHICLE de la [Standard Library]. Los cambios deben
asemejarse a lo mostrado en la Figura 4.4.
14
Si el indicador de fila corresponde a la última fila y la entidad entra en un TRANSFERNODE con un destino “By Sequence”, el
indicador de fila volverá a tomar el valor 1.
Parking del Cart
Crear espacio hasta

TRANSFERNODE para tres piezas
TransferCart alargando la fila de
donde se cogen
piezas
Figura 4.4: Añadiendo un Vehículo

Paso 3: Cambie la propiedad del TRANSFERNODE, Ride On Transporter, a “True” y especifique como
transportador, Transporter Name, a “Cart” (Figura 4.5). Cada vez que una entidad pase por este nodo,
generará una petición de transporte al vehículo especificado. La entidad no puede continuar hasta que el
vehículo llega a recogerla.
Figura 4.5: Especificando el Nodo para que las Entidades Utilicen un Transportador
Paso 4: Use la Figura 4.6 como guía para que el vehículo Cart circule con la velocidad deseada, Initial
Desired Speed, 4 pies por segundo, así como su capacidad de transporte, Ride Capacity, a 3. Recuerde
también que debe asignar el sitio donde debe aparcar un vehículo, Initial Node(Home), como
TransferCart. Cambie ahora la propiedad Idle Action a “Park At Home”, con lo que el vehículo se
dirigirá a su garaje cuando no hay entidades que hayan lanzado peticiones de transporte. Si no lo indicara
así, el vehículo se mantendría en la salida hasta recibir una nueva petición. Aumente también el tamaño
del lugar donde las entidades esperan a ser recogidas (Figura 4.4).

Figura 4.6: Propiedades del Vehículo
Paso 5: Adicionalmente, se necesita un lugar donde aparcar al vehículo de forma que no desaparezca cuando
esté aparcado15. Haga clic en el nodo TransferCart y seleccione “Draw Queue” de la pestaña
“Appearance”. Haga clic a su vez en “ParkingStation.Contents”. Un cursor con forma de cruz
aparecerá en el tapiz. Haga clic con el botón izquierdo en el lugar donde quiere situarlo (antes de hacer
clic con el botón derecho para localizar el final de la fila, puede continuar haciendo clic con el botón
izquierdo para añadir más vértices). Haga clic en la fila y en la ventana de propiedades para cambiar
Queue State ParkingStation.Contents. Esta fila permitirá la animación del parking del nodo
TransferCart para los vehículos que aparquen en este nodo.
Paso 6: Simule para ver cómo se comporta el vehículo visualmente.
Paso 7: El modelo no muestra cuántas piezas están esperando al carrito en el nodo de transferencia, por lo
que será útil ver cuántas se encuentran esperando en cualquier momento de la ejecución. Podemos añadir
la denominada Fila Separada, “Detached Queue.”
Paso 8: En la pestaña de “Animation”, haga clic en “Detached Queue.” Aparecerá un cursor en el tapiz
principal. Haga clic con el botón izquierdo en el sitio donde quiere que empiece la fila y después con el
derecho en el lugar que quiere que finalice (antes de hacer clic con el botón derecho para localizar el
final de la fila, puede continuar haciendo clic con el botón izquierdo para añadir más vértices). Como se
aprecia en la Figura 4.7, dibuje la fila en forma de “L”. De otra forma, una entidad parece que está
intentando entrar en el nodo y al sobreponer “L” se muestran todas las entidades que están esperando ser
transportadas.
Fila Separada
para las entidades
que esperan para
ser recogidas
Figura 4.7: Fila de Recogida
15
La fila de aparcamiento sólo es para la animación, puesto que el transportador está físicamente en el nodo incluso si no se muestra
en pantalla.
Haga clic ahora en la cola y en la ventana de propiedades cambie Queue State a
TransferCart.RidePickupQueue, donde TransferCart es el nombre del nodo de
transferencia en donde se recogen las piezas acabadas. Su nombre puede ser diferente.
Paso 9: Simule para ver cómo se comporta la Fila Separada.
Pregunta 6: ¿Cuál es el porcentaje de utilización del carrito durante las 40 horas que dura la repetición?
 Los horarios y patrones de trabajo, Work schedules, las secuencias, sequences, las colas
separadas, detached queues, y los transportadores o vehículos, presentan en SIMIO
características similares a las de Arena.
 La animación en SIMIO garantiza un vista atractiva, mucho más realista que la de Arena.
 El uso de vehículos en SIMIO es fácil de implantar y más fácil de usar que en Arena.

Capítulo 5
Agrupaciones, Funciones, Variables de Estado, y
Estadísticas: Ensamblaje de Tarjetas de Memoria
 Agrupando y combinando entidades
 Direccionando entidades
 Tiempo de proceso que depende del tamaño de la fila
 Estadísticas y variables de salida
Las tarjetas de memoria contienen unos chips de memoria insertados mediante una operación de ensamblaje,
con capacidad 4. Cada tarjeta de memoria requiere cuatro chips. Las tarjetas de memoria, así como los chips,
llegan de forma aleatoria, por lo que el ensamblador espera a tener cuatro chips del mismo tipo y una tarjeta
antes de realizar el ensamblado. Después, la tarjeta de memoria ensamblada se manda a una de tres
estaciones de empaquetado, cada una con un operario. Las tarjetas se mandan a la fila de empaquetado con
un menor número de unidades esperando. Estas características numéricas se resumen en la Tabla 5.1.
Tabla 5.1: Distribuciones Numéricas de las Características de las Tarjetas de Memoria

De A Tiempo (minutos)
Llegada de las Tarjetas de Memoria Ensamblaje de Uniforme(3,5) minutos
Tarjeta
Llegada de los Chips de Memoria Ensamblaje de Uniforme(4,6) minutos
Tiempos de Tarjeta
Desplazamiento Ensamblaje de Tarjeta Packer Operación 1 Pert(10,12,15) minutos
Ensamblaje de Tarjeta Packer Operación 2 Pert(5,7,10) minutos
Ensamblaje de Tarjeta Packer Operación 3 Pert(4,5,7) minutos
Cualquier Operación de Exit 3.5 minutos
Empaquetado
Tiempo entre Llegadas para las Tarjetas de Memoria Exponencial(2) minutos

Información
Tiempo entre Llegadas para los Chips de Memoria Exponencial(0.5) minutos
de Llegadas
50% de los chips son de Tipo 1 y 50% de Tipo 2 Discreta
Tiempos de Tiempo de proceso del Ensamblaje de Tarjeta Uniforme(2,4) minutos
proceso Tiempo de Empaquetado Triangular(3,5,8) minutos
Sección 5.1: Creando el Modelo
Paso 1: Cree un nuevo modelo con dos fuentes, SOURCES, una para tarjetas y otra para chips de memoria.
Añada dos entidades, MODELENTITIES, en el modelo, una denominada MemoryBoard para tarjetas, y
otra denominada Memory para chips.
Paso 2: Utilice distintos símbolos para diferenciar las entidades (Figura 5.1). Puede utilizar sus propios
símbolos si hace clic en el botón “New Symbol” en la sección “Create” de la pestaña “Project Home”.
Cuando cree un símbolo nuevo, debe especificar su altura, “height”, en metros. En el caso mostrado en
la Figura 5.1, se ha creado un rectángulo con una altura de 0.5 metros16. No hay que preocuparse en
16
Las tarjetas de memoria no son de 0.5 metros de ancho pero se ha hecho así para facilitar su visión en 3-D.
exceso sobre las especificaciones exactas ya que el símbolo puede ajustarse manualmente después de
hacer clic en el símbolo de MemoryBoard y utilizando nuestro nuevo símbolo (haciendo clic en
SYMBOL1 y en Symbols→Project Symbols).
Paso 3: Para los chips de memoria, añada un símbolo adicional17, coloreando este segundo símbolo con un
color diferente para diferenciarlos en el sistema.
Paso 4: Introduzca en el modelo un objeto agrupador, COMBINER, denominado BoardAssembly, para

representar la operación de ensamblado, como se muestra en la Figura 5.1, Este nuevo elemento
combinará un objeto “padre” (tarjeta) con un objeto “miembro” (chip). Especifique la capacidad inicial
del objeto BoardAssembly como “4”. Conecte las dos fuentes, SOURCES, con los nodos mediante
caminos, TIME PATHS.
Figura 5.1: Initial Memory Board Model

Paso 5: Recuerde que una tarjeta requiere cuatro chips idénticos. Por tanto, el combinador, COMBINER, debe
agrupar cuatro miembros del mismo tipo. Añada una variable de estado a las entidades para
distinguir entre los dos tipos de chips. Seleccione MODELENTITY en el panel [Navigation] y elija la
sección “States” de la pestaña “Definitions”. Como coexisten dos tipos distintos de chips, incluya
una nueva variable “Discrete State”, de nombre ChipType.
Paso 6: Volviendo a la pestaña “Facility”, haga clic en MemoryArrivals. Para asignar la nueva variable
ChipType, se especificará una asignación, Before Existing State Assignment, de forma que se
otorgue un valor a ChipType antes de que la entidad abandone la fuente. Haga clic en la opción
que se encuentra a la derecha de Before Exiting State Assignments para que aparezca el editor de
propiedades, “Repeating Property Editor”, y añada la siguiente propiedad:
State Variable Name: ModelEntity.ChipType

New Value: Random.Discrete(1,.5,1,1)18
 Como es igual de probable que el chip sea de un tipo o del otro, se utiliza una distribución discreta
para asignar a ChipType el valor 1 o el valor 2.
Paso 7: Ahora, agrupe (batch) 4 miembros en el COMBINER mediante la especificación de Match Members
como una regla de agrupación, Matching Rule, con ModelEntity.ChipType como una propiedad
Member Match Expresión (Figura 5.2).19
17
Seleccione Memory y luego el botón Symbols→Additional Symbols→Add Additional Symbol.
18
La distribución Discrete debe ser especificada según las probabilidades acumuladas.
Agrupaciones, Funciones, Variables de Estado, y Estadísticas: Ensamblaje de Tarjetas de Memoria 33

Figura 5.2: Especificando la Lógica de Agrupación en un Combiner
Paso 8: Incluya 3 SERVERS, uno por empaquetadora con el tiempo de proceso apropiado, y un SINK
denominado Exit (Figura 5.3). Utilice TIMEPATHS para conectar la ensambladora con las
empaquetadoras y añada los tiempos de desplazamiento correspondientes (no conecte todavía las
empaquetadoras con la salida).
Utilice este
TRANSFERNODE
Figura 5.3: Las Empaquetadoras en el Modelo

Paso 9: Recuerde que las ensambladoras necesitan elegir la empaquetadora con el menor número ya
asignado. En el TRANSFERNODE de salida asociado al COMBINER, la decisión de direccionamiento necesita
ser especificada, utilizando la propiedad de destino, Entity Destination Type.
Paso 10: Cuando una tarjeta ya está ensamblada, puede seleccionar uno de tres destinos:
Input@Packer1, Input@Packer2, o Input@Packer3. Cree un nuevo nodo LIST (pestaña
“Definitions”) y denomínelo LstPackers, empezando con Input@Packer1 (Figura 5.4).
Figura 5.4: Nodo Lista para Elegir Empaquetadora

Paso 11: Ahora, en el TRANSFERNODE, especifique que las entidades deben ser direccionadas a los
destinos de acuerdo a las siguientes propiedades:
Entity Destination Type: Select from List

Node List Name: LstPackers
Selection Goal: Smallest Value ()
19
Los combinadores pueden casar entidades entre sí, casar miembros entre sí o casar ciertos miembros con padres.
Selection Expression: Candidate.Node.NumberRoutingIn+
Candidate.Server.InputBuffer.Contents.NumberWaiting+
Candidate.Server.Processing.Contents.NumberWaiting20
Pregunta 1: Examine la expresión de selección, Selection Expression, y advierta que se compone de tres
componentes. ¿Qué representan cada uno de ellos?
Paso 12: Especifique la forma de trasladarse desde las empaquetadoras a la salida utilizando una
propiedad del modelo, “Model Property”, que se encuentra en la pestaña “Definitions”. Incluya una
propiedad numérica de tipo real, “Real” , elegida del menú “Standard Property” y opción TimeToExit, y
especifique su valor por defecto, Default Value, como “3.5”, con las unidades por defecto en minutos
(Unit Type, Time; Default Units, Minutes).
Paso 13: Ahora ya puede especificar el tiempo de desplazamiento, Travel Time, de cada uno de los
caminos hasta la salida21 como , esto es, con una propiedad de referencia, reference
property. Si desea cambiar ahora el tiempo de desplazamiento de los tres caminos a la vez, sólo hay que
cambiar la nueva propiedad.
Paso 14: Guarde el modelo y ejecútelo durante 10 horas, y conteste a las siguientes preguntas.
Pregunta 2: ¿Cuánto están las entidades en el sistema (desde la entrada a la salida)?
Pregunta 3: ¿Cuál es el grado de ocupación de BoardAssembly?
Pregunta 4: ¿Cuál es el grado de ocupación de cada una de los empaquetadoras?
Sección 5.2: Cambiando el Tiempo de Proceso en Función de la Longitud de la Cola
Supongamos que es necesario cambiar el ritmo de operación de Packer1 en función del número de tarjetas
que están esperando (tamaño de la fila). Específicamente, la eficiencia de la empaquetadora es sólo del 80%
cuando no hay tarjetas esperando, 90% cuando hay 1, y 100% cuando hay al menos dos.
Paso 1: Necesita ahora incluir una tabla de eficiencias, “efficiency” table, para determinar el tiempo de
proceso. Esta tabla puede ser también modelizada como una tabla “Function” en SIMIO (dicho de otra
forma, f(x)). En la pestaña “Data”, añada una tabla discreta, “Discrete Function Table”, cuyos valores
son 0.8 cuando x = 0, 0.9 cuando x = 1, 1 cuando x = 2, y 1 cuando x = 100 (Tabla 5.2).
20
La designación de candidato, Candidate, es una referencia que toma como valor la identidad del objeto al que está haciendo
referencia. Aquí hace referencia al nodo hacia el que la entidad está siendo dirigida y la fila específica de entrada, INPUTBUFFER, o
de procesamiento, PROCESSING, de la estación que está al final del camino.
21
Seleccione a la vez los tres caminos y después haga click con el botón derecho en la propiedad Travel Time y seleccione la nueva
propiedad de referencia TimeToExit.

Tabla 5.2: Tabla con Función
Recuerde que la tabla interpola para valores que se encuentren entre los valores especificados. Denomine
Efficiency a la tabla.
Paso 2: En la propiedad ProcessTime de Packer1, cambie la expresión de forma que la distribución

Triangular se divida por la función de eficiencia cuando se calcula el tiempo real de proceso. Para buscar
en tablas, SIMIO utiliza la notación [] (no ()). La nueva expresión se define como sigue:
Random.Triangular(3,5,8)/
Function.Efficiency[Packer1.InputBuffer.Contents.NumberWaiting]
Pregunta 5: ¿Por qué dividimos el tiempo original del proceso entre la eficiencia?
Paso 3: Quisiéramos estar seguros de que nuestra función “eficiencia” está funcionando. Para comprobarlo,
utilizaremos un gráfico de estado, “Status Plot”, que se puede encontrar en la pestaña “Animation”.
Utilice las siguientes especificaciones para el gráfico.
Title: Efficiency at Packer 1

X Axis: Time
Y Axis: Number in Packer 1 Queue
Time Range: 10 Minutos
Asimismo, añada la expresión que será dibujada:
Paso 4: Parte del gráfico se muestra en la Figura 5.5.
Figura 5.5: Gráfico de Eficiencia

Pregunta 6: ¿Da la sensación que la función de eficiencia está funcionando?

Sección 5.3: Añadiendo Más Animación
Paso 1: Arreglemos primero la animación de la tarjeta de memoria de forma que parezca que los chips están
pegados. Haga clic en el símbolo de MEMORYBOARD y añada una fila del tipo BATCHMEMBERS que está
incluida en “Attached Animation” en el menú “Draw Queue”. Posiciónela encima del MEMORYBOARD
como se muestra en la Figura 5.6.
BATCHMEMBERS
Figura 5.6: Fila de Chips Ensamblados

Para poner un objeto encima de otro, necesita seleccionar el objeto y apretar luego la tecla Shift. Es
probablemente mejor hacerlo cambiando iterativamente entre 2-D y 3-D.22
Paso 2: Utilicemos el color de las tarjetas para designar y diferenciar entre los dos tipos. Para hacer esto,
haga clic en la entidad MEMORY y después en “Add Additional Symbol” en la sección “Additional
Symbols” dentro de la pestaña Symbols. Puede colorear un símbolo en rojo y el otro en verde mediante
la simple selección de un símbolo, activándolo como “Active Symbol”, y cambiándolo de color. Fíjese
que los dos símbolos han sido numerados como 0 y 1 (no 1 y 2).
Paso 3: También se puede asignar colores a los diferentes tipos de chip. Seleccione la fuente
MemoryArrivals. Haga clic en el recuadro que se encuentra a la derecha de Before Exiting State
Assignments, dado que queremos asignar el color antes de que la entidad se vaya de la fuente. Se abre
entonces el editor de propiedades “Repeating Property Editor”. Se debe añadir una variable de estado
adicional con las características siguientes:
State Variable Name: ModelEntity.Picture

New Value: ModelEntity.ChipType-1
El valor de una variable de estado, “state variable”, en contraposición al de una propiedad, puede ser
modificado durante la simulación, y el dibujo de una entidad se trata en SIMIO como si fuera una
característica de la entidad (lo que a veces se denomina como un atributo de la entidad).
Pregunta 7: ¿Por qué restamos 1 de la propiedad ChipType?
Paso 4: Simule para ver que la animación se comporta como debe.
Pregunta 8: ¿Cambian los chip de color en función de su tipo?
Paso 5: Supongamos que queremos que el símbolo que sale de la estación de empaquetado parezca un
“paquete”. Se puede realizar la animación de diversas formas. Una forma fácil es utilizar una asignación
22
Recuerde que la tecla “h” hace aparecer instrucciones sobre cómo mover los objetos tanto en 2D como en 3D, así como ideas
sobre cómo manipular objetos. Presionando la tecla “h” otra vez hace desaparecer las instrucciones.

de estado antes de dejar una estación, Before Exiting State Assignments; en este caso, en las
empaquetadoras. Desde una de las empaquetadoras, invoque al editor de propiedades, Repeating
Property Editor, y añada:
State Variable Name: ModelEntity.Size.Height

New Value: 2.1
Puede que tenga que experimentar con el valor. La idea es cambiar la altura, “height”, de la tarjeta
de memoria de forma que encapsule los chips para que no se vean (se esconde entonces los
miembros del lote dentro de la tarjeta).
Paso 6: Ejecute el modelo y ajuste la altura hasta que el icono que sale de la empaquetadora parezca un
paquete. Tendrá que realizar el mismo cambio en el resto de empaquetadoras.
Paso 7: Mire el modelo en 3-D y vea los cambios realizados.
Paso 8: Guarde el modelo y ejecútelo durante un período de 10 horas y conteste a las preguntas siguientes.
Pregunta 9: ¿Cuánto están las entidades en el sistema (desde la entrada a la salida)?
Pregunta 10: ¿Cuál es el grado de ocupación de BoardAssembly?
Pregunta 11: ¿Cuál es el grado de ocupación de cada una de las empaquetadoras?
Pregunta 12: ¿Cuál es el número medio de entidades en MemberInputBuffer?
Pregunta 13: ¿Cuál es el número medio de entidades en ParentInputBuffer?
Pregunta 14: ¿Cómo es la fila CombinerBatch?
Sección 5.4: Creando Estadísticas
Algunas veces, el proceso automático de cálculo y presentación de estadística simplemente no proporciona la

información que interesa. Por ejemplo, nos gustaría conocer el tiempo que emplean las tarjetas y los chips en
ir desde la entrada a la salida, o la eficiencia media de Packer1. El tiempo en el sistema, o en un subsistema,
es un ejemplo de lo que generalmente se conoce como variables basadas en observaciones, “observation-
based” statistics. Este tipo de variable se denomina en SIMIO como variable contador, “Tally Statistic”. En
el caso de la eficiencia, su valor cambia (con saltos discretos) a lo largo del tiempo, y la variable resultado se
denomina generalmente como variable basada en el tiempo, “time-persistent” o “time-weighted”. En SIMIO,
este tipo de variable se denomina variable de estado, “State Statistic” y como la eficiencia cambia al suceder
eventos concretos, se denomina variable de estado discreta “Discrete State Statistic”.23
Paso 1: Considere primero la variable eficiencia. Para calcular su valor, tenemos que definir una variable de
estado. En la pestaña “Definitions”, seleccione “States” y haga clic en “Discrete State” para definir una
nueva variable Packer1Efficiency.
23
No confundir una variable de estado, “state variable”, con una estadística de estado, “state statistic”.
Pregunta 15: Existen diversas variables de estado, pero la única discreta es la relevante. ¿Qué hay de
discreto en los cambio en eficiencia?
Paso 2: Para garantizar que Packer1Efficiency proporciona el valor correcto, modifiquemos las
asignaciones, “State Assignments”, en Packer1. En particular, hagamos la siguiente asignación al entrar
en la estación, On Entering:
State Variable: Packer1Efficiency

New Value:
Paso 3: Finalmente, necesitamos definir la estadística del tipo estado, “State Statistic”, lo que podemos
realizar desde la pestaña “Definitions”, pero en la sección de elementos, “Elements”. Denominémosla
Packer1Utilization y usemos Packer1Efficiency como nombre de la variable de estado, State Variable
Name.
Paso 4: Guarde y ejecute el modelo de simulación.
Pregunta 16: ¿Cuál es el grado de ocupación de la empaquetadora 1, Packer1Utilization?
Paso 5: Obtengamos también estadísticas sobre el tiempo de permanencia en el sistema tanto de las tarjetas
de memoria como de los chips. Una vez más, hay diversas formas de hacer esto. Aunque piense que
tiene que proporcionar información adicional a SIMIO, este es un caso en el que podemos ayudarnos en
la forma en que SIMIO calcula estadísticas. Recuerde que automáticamente se obtiene el tiempo en el
sistema de las entidades que cruzan el sumidero o salida. Utilizaremos esta forma de modelizar.
Paso 6: Para obtener resultados de las tarjetas y los chips, podemos separarlos y mandarlos a salidas distintas
– y hacerlo sin cambiar las estadísticas habituales. Nuestro enfoque se muestra en la Figura 5.7.
Miembros
separados
Figura 5.7: Separando Entidades
Se sustituye el sumidero, SINK, por un separador, SEPARATOR, de la [Standard Library], para que ayude
a separar los “padres” de los “miembros”. Los miembros se separan y se mandan a diferentes salidas.
Los distintos objetos se conectan con conectores, CONNECTORS.
La separación de miembros se basa en pesos, “Selection Weight.” El peso para las RedLeaves es:
ModelEntity.ChipType==1. Y para las GreenLeaves es: ModelEntity.ChipType==2.
Paso 7: Ejecute el modelo durante 10 horas y conteste a las siguientes preguntas.
Pregunta 17: ¿Cuál es el tiempo de permanencia de las tarjetas de memoria en el sistema?

Pregunta 18: ¿Cuál es el tiempo de permanencia de los chips rojos en el sistema?
Pregunta 19: ¿Cuál es el tiempo de permanencia de los chips verdes en el sistema?
Pregunta 20: ¿Cuál es el grado medio de ocupación de la empaquetadora 1 en las 10 horas?
 Las funciones y las gráficas de SIMIO se asemejan a las de Arena. En cambio, las capacidades
de animación de SIMIO son claramente mejores.
 El cálculo de estadísticas para variables de estado en SIMIO es similar al usado en Arena para
las variables que dependen del tiempo. El cálculo de estadísticas basadas en observaciones en
SIMIO no puede ser realizado en un módulo como en Arena. Sin embargo, como veremos en el
siguiente capítulo, el uso de procesos puede fácilmente adaptarse para obtener este tipo de
información.

Capítulo 6
Procesos en SIMIO: Ensamblaje de Tarjetas de Memoria
bis
 Disparadores de procesos, Add-On Process Triggers
 Procesos Reutilizables
 Pasos en un proceso (Asignar o Assign, Decidir o Decide, Contar o Tally,
Desagrupar o Unbatch, Apresar o Seize, Retrasar o Delay, Liberar o Release, etc.)
 Recursos
Una característica innovadora de SIMIO es su capacidad para modificar el comportamiento de un objeto

mediante la utilización de procesos, SIMIO “Processes.” Estos procesos ofrecen una amplia gama de
oportunidades de modelización, que se emplearán en este y posteriores capítulos. Los procesos son muy
flexibles y pueden modelizar comportamientos dispares, yendo mucho más allá de las posibilidades
intrínsecas de un objeto (como un servidor, SERVER). Los procesos ayudan a ampliar y expandir las
capacidades de modelización del SIMIO básico.
Hay dos consideraciones básicas cuando se desarrollan y se usan procesos:

1. “Cuándo” se llama, se invoca o se ejecuta el proceso, y
2. “Cómo” se escribe un proceso para producir el comportamiento deseado.
Típicamente, los procesos se invocan mediante acciones de los objetos durante la simulación o por eventos
que el modelizador diseña. Escribir un proceso es similar a crear un flujograma estilizado, con excepción de
que los componentes del flujograma son etapas lógicas como Asignar, Decidir, Contar, Transferir, Apresar,
Retrasar, Liberar ... La ejecución de un proceso se realiza con una señal, ficha o “token.” Las fichas (o
fichas) provocan la realización de los pasos del proceso para un objeto, normalmente, el objeto que lanza la
ficha o aquel cuyo comportamiento se ve modificado por el proceso.
Sección 6.1: Los Disparadores de Proceso: Ilustrando el Proceso Assign
Casi todos los objetos de SIMIO tienen disparadores, “Add-On Process Triggers”. Estos disparadores hacen
que se ejecuten procesos externos, esto es, procesos arbitrarios diseñados por el propio usuario para cambiar
o expandir el comportamiento de un objeto (por ejemplo, SERVER). La otra opción sería clonarlos o hacer
subclases de los objetos (vea el Capítulo 18 para más información sobre subclases).
En el Capítulo 5, se cambiaron ciertas características o atributos de las entidades. En un caso, los distintos
tipos de una entidad (chips) se colorearon para facilitar su diferenciación, y, en un segundo caso, se
incrementó la altura de otra entidad (tarjeta de memoria) para mejorar la animación del modelo. En ambos
casos, cambiamos los valores de variables de estado, “state variables”, utilizando las propiedades de
asignación de estados, “State Assignments”. Verá que las posibilidades de realizar este tipo de asignaciones
son limitadas, mientras que son más numerosas si se utilizan disparadores. Más aún, los “State Assignments”
sólo pueden asignar valores, mientras que un proceso puede incorporar lógica más compleja que las
asignaciones simples.
Paso 1: Veamos cómo se pueden replicar las asignaciones, “State Assignments”, utilizando disparadores.
Abra el modelo usado en el Capítulo 5. Primero, elimine los “State Assignment” de MemoryArrivals
(utilizando el editor de propiedades).
Procesos en SIMIO: Ensamblaje de Tarjetas de Memoria bis 41

Paso 2: Haga clic en el menú “Add-On Process Triggers” para expandirlo.
Pregunta 1: ¿Qué disparadores están disponibles para los objetos fuente, SOURCE?
Pregunta 2: ¿Cuándo se pueden utilizar “State Assignments” con los objetos fuente?
Paso 3: Elija el disparador que se dispara cuando sale una entidad, “Exited”. Haciendo doble clic en este
disparador se creará un nuevo proceso denominado MemoryArrivals_Exited y se le remitirá a la
pestaña de procesos, “Processes”. Verá un flujograma con un comienzo, “Begin”, y un final, “End”
(Figura 6.1). Haciendo clic en uno de los pasos del proceso, puede insertarlo en el flujograma, que se
ajustará automáticamente.
Pregunta 3: Enumere alguno de las etapas disponibles que se pueden utilizar para crear un proceso.
Pregunta 4: ¿Por qué ha elegido los que ha citado?
Paso 4: Inserte una etapa asignar, Assign (Figura 6.1).

Insertar un paso “Assign”
Figura 6.1: Insertando un paso Assign

Paso 5: En propiedades, puede ver un sitio para incluir el nombre de la variable de estado, State Variable
Name, y su nuevo valor, Value. También puede invocar al editor de propiedades, Repeating property
Editor, si hace clic al lado de “Assignments (More).” En cualquier caso, añada las dos siguientes
asignaciones:
State Variable Name: ModelEntity.ChipType

New Value: Random.Discrete(1,.5,2,1)
State Variable Name: ModelEntity.Picture

New Value: ModelEntity.ChipType-1
Paso 6: Borre la asignación “On Entering” en Packer1. Cree un disparador “Entered” e introduzca un
proceso Assign que hace lo siguiente:
State Variable Name: Packer1Efficiency

New Value:
Sección 6.2: Creando un Proceso “Reutilizable”
En el modelo del Capítulo 5, la asignación utilizada para cambiar la altura de las tarjetas de memoria para
que la entidad se asemejara a un paquete compacto fue realizada en cada empaquetadora. Por supuesto, este
enfoque puede ser duplicado mediante la creación de un disparador “Exited” para cada una de las
empaquetadoras. Sin embargo, la misma lógica de asignación de la altura ha de ser incluida en cada uno de
los tres disparadores “Exited”. Creemos entonces un proceso que pueda se referenciado por cada una de las

empaquetadoras, en vez de crear un proceso distinto para cada empaquetadora. Este tipo de proceso se
denomina “reutilizable” y permite su modificación en un único sitio en lugar de en tres.
Paso 1: En la pestaña “Processes”, haga clic en el botón de creación de un proceso, “Create Process”,
denominando el nuevo proceso como Packaged. Añada una etapa Assign al flujograma con las
siguientes asignaciones.
State Variable Name: ModelEntity.Size.Height

New Value: 2.1
Paso 2: Borre los “State Assignments” de cada una de las empaquetadoras.
Paso 3: Vaya al disparador “Exited Add-On Process Trigger” de cada uno de las empaquetadoras. En lugar
de crear uno nuevo, seleccione el disparador Packaged de la lista.
Pregunta 5: ¿Cuál es la ventaja de tener un proceso y referenciarlo a cada operación de empaquetado en

lugar de tener los procesos duplicados en cada empaquetadora?
Paso 4: Ejecute el modelo y asegúrese de que replica el comportamiento previo.
Sección 6.3: Obteniendo Estadísticas Sobre Variables de Observación (Tally Statistics)
Recuerde que las estadísticas basadas en la observación se denominan TALLY en SIMIO. Estas estadísticas se
recogen como observaciones durante la ejecución de una simulación. Como ejemplos más habituales se
pueden citar los tiempos de permanencia en una fila, los tiempos totales de permanencia en el sistema o los
tiempos de ciclo. En general, son estadísticas cuyas observaciones son intervalos de tiempo.
Paso 1: Consideremos que son necesarias las estadísticas TALLY del tiempo que están tanto las tarjetas de
memoria como de los chips hasta que empiezan a ser empaquetadas en Packer1. Necesitamos definir
primero un nuevo elemento. En la sección “Definitions→Elements”, haga clic en “Tally Statistic” para
crear una nueva variable denominada SystemTimePacker1.
Paso 2: Necesitamos definir el proceso de recogida de observaciones. Inserte una etapa Tally en
Packer1_Entered (Figura 6.2). En este caso:
Value Type: Expression

TallyStatistic Name: SystemTimePacker1
Value: TimeNow-ModelEntity.TimeCreated24
Figura 6.2: Utilizando una Etapa Tally para Controlar el Tiempo antes de la Empaquetadora 1
Pregunta 6: ¿Podría ser el valor simplemente ModelEntity.TimeInSystem?
24
TimeNow es la hora actual del reloj de la simulación y la función TimeCreated devuelve la hora en que la entidad fue creada.

Paso 3: Guarde el modelo y ejecútelo para ver los resultados.
Pregunta 7: ¿Cuál es el tiempo que tardan tanto las tarjetas como los chips desde la entrada hasta el
comienzo de la operación de empaquetado 1?
Paso 4: Suponga que ahora queremos saber el tiempo que emplea una entidad ensamblada desde que
empieza en la estación Packer1 hasta la salida después de 4 horas de simulación. Tenemos que
modificar nuestro proceso para que sólo se obtengan las observaciones referidas a las tarjetas pasadas las
primeras cuatro horas.
Paso 5: Modifique nuestro proceso “Packer1_Entered” y añada una etapa decidir, Decide, antes de
Tally (Figura 6.3). Esta etapa Decide es similar a una función SI en Excel donde si una condición es
verdadera el proceso continuará por una rama del flujograma, la rama “True”, y en caso contrario seguirá
por la otra rama, “False”. La propiedad que marca el tipo de decisión, Decide Type, debe basarse en una
condición, “ConditionBased”, con una expresión Expression que indique: TimeNow > 4.
Figura 6.3: Añadiendo una Etapa Decide

Paso 6: Guarde y ejecute el modelo.
Pregunta 8: ¿Qué tiempo de permanencia obtiene para las tarjetas y los chips desde que llegan hasta el
momento en que empiezan a ser empaquetados en Packer1?
Paso 7: Es posible que desea usar etapas de proceso para reemplazar los cambios en la modelización que se
realizaron sobre el modelo del Capítulo 5 de forma que se obtengan estadísticas de tiempo en el sistema
por tipo de chip (verde o rojo) y para las tarjetas.
 Primero, vuelva a introducir el sumidero original Exit (SINK)

 Borre todas los objetos (SEPARATOR y los tres SINKS) que se implementaron cuando se reemplazó
Exit.25
 Conecte las tres operaciones de empaquetado con el sumidero de forma similar a lo que se hizo en la
Figura 5.3.
Paso 8: Definamos tres nuevas estadísticas TALLY (recuerde que son elementos, “Elements”), denominadas
BoardTimeInSystem, RedTimeInSystem, y GreenTimeInSystem.
Paso 9: Creemos un proceso en el sumidero que utilice el disparador de destrucción de entidades,

“Destroying Entity”. Este proceso se denomina Exit_DestroyingEntity (Figura 6.4).
25
Cuando borra un nodo, desaparecen todas sus conexiones. Puede conectar nodos rápidamente si aprieta las teclas Shift y Ctrl, y
hace clic en el nodo de origen y arrastra el conector hasta el destino. Tendrá que seleccionar el tipo de conexión.
Figura 6.4: Proceso de Destrucción de Entidades
Ha sido necesario incluir una etapa previa, para desagrupar, UnBatch, las entidades. Ha sido
elegida del panel de etapas y del conjunto de todas las etapas, “All Steps (A-Z)”. La etapa UnBatch
funciona como un objeto separador, SEPARATOR, excepto que se utiliza para desagrupar los “padres”
y los “miembros” y dirigirlos por las ramas correctas.
La etapa decidir, Decide, es condicional, basada en la condición:

ModelEntity.ChipType==1
Las etapas Tally simplemente graban el tiempo en el sistema, ModelEntity.TimeInSystem,

en cada una de las etapas en función del tipo de entidad.
Pregunta 9: ¿Cuáles son las ventajas y las desventajas de este enfoque frente al original donde el modelo
físico se cambió para obtener estadísticas?
Pregunta 10: ¿Qué otras etapas que aparecen en la lista “All Steps (A-Z)” no aparecen en las etapas más
comunes, “Common Steps”?
Paso 10: Guarde y ejecute el modelo de forma que observe si hay diferencias con el modelo anterior.
Pregunta 11: ¿Cuánto tiempo están las tarjetas de memoria en el sistema (desde la entrada a la salida)?
Pregunta 12: ¿Cuánto tiempo están los chips verdes en el sistema (desde la entrada a la salida)?
Pregunta 13: ¿Cuánto tiempo están los chips rojos en el sistema (desde la entrada a la salida)?
Paso 11: Los resultados deben ser comparables con los obtenidos en el capítulo anterior.
Pregunta 14: Dado que los resultados son comparables, ¿qué enfoque es más fácil para usted?26
26
La gente suele intentar no utilizar procesos al principio, especialmente si pueden realizar los modelos sin ellos (esta es parte de la
nueva forma de pensar que require SIMIO). Sin embargo, encontrará que el tiempo invertido en aprender a utilizarlos vale la pena en
cuanto se enfrente a sistemas más complicados. El resto de capítulos ilustrará por qué los procesos son tan esenciales.

Sección 6.4: Una Introducción a Recursos (Resources)
A veces la capacidad no se reduce a objetos como SERVERS o COMBINERS, que se basan en sus capacidades
internas. En cambio, la limitación puede no estar fijada en el sentido de que la capacidad está situada en una
localización concreta. Por ejemplo, supongamos que la operación de ensamblaje de las tarjetas de memoria
requiere de un accesorio o útil para ensamblar los chips en la tarjeta de memoria. Además, el mismo útil se
utiliza para transferir la unidad ensamblada hasta empaquetado. Para cada operación de ensamblaje, el útil
debe acercarse desde la empaquetadora, para lo que se tarda unos 3 minutos. Asumamos que existen 10
útiles idénticos disponibles para la doble operación ensamblaje-empaquetado.
Paso 1: Primero, arrastre y deje un objeto recurso, R ESOURCE27 en el tapiz, quizá debajo del combinador,
COMBINER como se nuestra en la Figura 6.5. Llame al recurso Fixture y asígnele una capacidad inicial,
Initial Capacity, de 10 (no modificaremos la capacidad en este caso).
Es un recurso
RESOURCE fijo
Figura 6.5: Añadiendo el Recurso Fixture

Paso 2: Se necesita especificar la lógica de utilización de este recurso. El útil será “apresado” justo antes de
del ensamblaje y “liberado” justo después del empaquetado. Hay que dotar tiempo para que vuelva
a la primera estación, por lo que se necesitará de los procesos para manipular los recursos,
RESOURCES.
Paso 3: Para sustituir el combinador, COMBINER, BoardAssembly, cree un disparador “Processing”

denominado BoardAssembly_Processing. Este disparador se ejecuta justo antes de que el
combinador esté listo para empezar a procesar. La etapa utilizada para apresar un recurso, Seize,
será utilizada para especificar que se necesita un Fixture antes de empezar a ensamblar (Figura 6.6)
y apresar o conseguir una unidad de capacidad. No nos ha de importar ahora cuál de los útiles se
apresa, puesto que son idénticos. Una vez que los útiles han sido apresados (lo que quiere decir que
están disponibles), se va a utilizar un retardo, Delay, de 3 minutos para representar el tiempo
necesario para traer el útil desde las empaquetadoras.
27
El Capítulo 13 cubrirá con más detalle el objeto RESOURCE.
Figura 6.6: Apresando una Unidad de Útil y Acercándolo
Paso 4: Cuando se acaba un paquete, se libera el útil para poder ser utilizado otra vez en el ensamblaje. Este
proceso tiene que ser modelizado para cada uno de las tres empaquetadoras, de forma que será más
fácil utilizar el proceso reutilizable Packaged, al que se llama cuando la tarjeta de memoria sale de
la estación de empaquetado. A partir de la pestaña “Processes”, incluya la etapa soltar o liberar,
Release (Figura 6.7), lo que liberará una unidad de Fixture.
Figura 6.7: Soltando un Útil Fixture

Paso 5: Ejecute el modelo y obtenga el tiempo en el sistema de tarjetas de memoria y chips.
Paso 6: Cambie la capacidad del útil a 20, y simule otra vez.
Pregunta 15: ¿Cuál es la diferencia en el tiempo en el sistema de tarjetas y chips si se comparan los
resultados de los dos escenarios (10 frente a 20 útiles)?
 Las bondades de los procesos lógicos de SIMIO es una de sus características sobresalientes, pues
permite extender y particularizar los modelos de forma única y poderosa. Su uso puede requerir
un cambio de mentalidad en la forma de enfocar la simulación.
 En Arena los bloques y los elementos de SIMAN corresponden someramente con las etapas y los
elementos en SIMIO. Sin embargo, en Arena los módulos han sido compuestos a partir de los
componentes de SIMAN, por lo que todo viene de SIMAN. En SIMIO, los objetos son
totalmente nuevos y existen varias definiciones y procesos disponibles para alterar el
comportamiento de los modelos estándar de SIMIO. El potencial de estas características de
SIMIO no se encuentra en Arena/SIMAN.
 Se pueden realizar muchos tipos de modelizaciones diferentes utilizando recursos, una cualidad
que exploraremos en otros capítulos (Capítulo 13, Capítulo 14, Capítulo 16, etc.).

Capítulo 7
Tiempos de Proceso Específicos por Pieza y Fuentes
Únicas: Célula de Fabricación bis
 Tiempos de proceso que dependen del tipo de pieza
 Fuente de piezas únicas para muchos tipos de piezas
Sección 7.1: Nuevo Enunciado del Problema
Recuerde el enunciado del problema del Capítulo 4 donde el objetivo era modelizar cuatro tipos de piezas
que pasaban por tres estaciones: A, B, y C. Las estaciones estaban situadas de forma que el patrón de
movimiento es circular y unidireccional (Figura 7.1). Por ejemplo, si se termina una pieza en la Operación C,
tendrá que recorrer el camino hasta la Operación A, y luego hasta la Operación B, antes de que puede
dirigirse hasta la salida. Queremos simular un período de 40 horas. Las piezas se mueven a una velocidad de
2 millas por hora.
Llegada Salida de
de Piezas Travel Direction Piezas
Figura 7.1: Layout de la Célula de Fabricación

En el Capítulo 4, el tiempo de proceso para cada una de las estaciones era el mismo independientemente del
tipo de pieza. En este capítulo, el tiempo va a depender de la pieza a fabricar, según los valores mostrados en
la Tabla 7.1.
Tabla 7.1: Secuencias y Tiempos de Proceso (en Minutos)

Pieza 1 2 3
Pieza 1 Station A (Pert(2,5,8)) Station C (Pert(2,6,11))
Pieza 2 Station A (Pert(1,3,4)) Station B (Uniforme(5 a 11) Station C (Uniforme(2 a 11))
Pieza 3 Station A (Triangular(2,5,8)) Station B (Triangular(5,9,11))
Pieza 4 Station B (Pert(5,9,11)) Station C (Triangular (2,6,11))
También en el Capítulo 4, las piezas llegaban desde cuatro fuentes distintas, cada una con su propio patrón
de llegadas. Algunas veces, es necesario modelizar utilizando una única fuente, aunque haya cuatro tipos
distintos de piezas, cada uno con un porcentaje sobre el total (Tabla 7.2).

Tabla 7.2: Porcentaje por Tipo de Pieza
Tipo de Pieza Porcentajes
Pieza A 25%
Pieza B 35%
Pieza C 15%
Pieza D 25%
Pregunta 1: ¿Cuándo piensa que es mejor disponer de una única fuente en vez de múltiples fuentes?
Las distancias en yardas se muestran en la Tabla 7.3.
Tabla 7.3: Distancias en Metros Entre Estaciones

Camino desde Distancia (yardas)
Entrada a Operación A 25
Operación A a Operación B 35
Operación B a Salida 20
Salida a Operación C 30
Operación C a Entrada 40
Paso 1: Abra en primer lugar el modelo del Capítulo 4, guárdelo con otro nombre, y borre todas las fuentes
menos una (Figura 7.2).
Única Fuente
Nodo básico
de Salida
Figura 7.2: Modelo con la Célula de Fabricación

Paso 2: Para modelizar el tiempo de procesos de forma que sea dependiente del tipo de pieza, el tiempo de
procesos necesita ser adjuntado en la tabla original de secuencias. (Nota: se podría utilizar una expresión
más complicada para el tiempo de proceso, utilizando reglas SI – si la pieza es de tipo A, entonces el
tiempo de proceso es X, si es B, Y, ..., pero la rutina se complica si el número de piezas diferente
aumenta).
Paso 3: En la pestaña “Data”, haga clic en SequencePart1 que está asociada con la Pieza 1. Debido a que
los tiempos de proceso pueden seguir cualquier distribución (o expresión válida), añada una columna
Tiempos de Proceso Específicos por Pieza y Fuentes Únicas: Célula de Fabricación bis 49
nueva para incluir expresiones denominada ProcessingTimes a partir del menú Standard Property.
Asegúrese de que la columna tiene las unidades apropiadas haciendo que Unit Type sea “Time” y las
unidades por defecto, Default Units, “minutes.”
Paso 4: Fije el tiempo de proceso para StationA según la función Pert, Random.Pert(2,5,8), el de
StationC según Random.Pert(2,6,11)y finalmente Exit en 0 (Figura 7.3).
Figura 7.3: Nueva Tabla de Secuencia para la Pieza A

Paso 5: Repita los dos últimos pasos para las otras tres piezas, creando la tabla de secuencias con los datos
incluidos en la Tabla 7.1.
Paso 6: Para que una única fuente sea capaz de producir múltiples tipos de entidades, se ha de crear una
nueva tabla de datos para especificar el tipo de pieza de las entidades así como el mix de producto en
porcentaje. Añada una tabla nueva denominada TableParts con cuatro columnas (Tabla 7.4).
Tabla 7.4: Definiciones de las Columnas

Columna Nombre Tipo
1 PartType Entity
2 ProcessingTime Expression
3 PartMix Integer (or Real)
4 PartSequence Sequence
A continuación, especifique cada entidad como una nueva fila con la información correspondiente
(Tabla 7.5).
Tabla 7.5: Contenidos de TableParts
Especificar SequencePart1.ProcessingTimes implica que el tiempo de proceso vendrá de

la columna asociada con ProcessingTimes en la tabla SequencePart1.
Paso 7: Para que se pueda utilizar tiempos de proceso dependientes del tipo de pieza, cambie las expresiones
de tiempo de proceso en las tres estaciones de forma que se lean losvalores
TableParts.ProcessingTime. Más en concreto, esta lógica hace que el tiempo de proceso se lea de la
columna ProcessingTime de la tabla de datos, TableParts. Como cada pieza se mueve en función de las
filas de su propia tabla de secuencias, obtendrá el tiempo de proceso de la fila correspondiente. La
propiedad es ahora una propiedad del tipo referencia

, que sólo puede ser convertida a una propiedad
normal haciendo clic con el botón derecho en la etiqueta ProcessingTime y especificando el nuevo valor.
Paso 8: Para generar múltiples tipos de piezas de la misma fuente, el tipo de entidad, Entity Type, necesita
ser modificado para incluir cada tipo de entidad. En la fuente, SOURCE, especifique que el valor de Entity
Type se busque en TableParts.PartType. Esta especificación permite que Entity Type pueda ser de
cualquiera de los tipos especificados en la tabla.
Paso 9: Haga que el tiempo entre llegadas sucesivas de piezas se comporte según una distribución
Exponential con una media 10 minutos.
Paso 10: Para determinar qué tipo de pieza se crea, se debe incluir en las propiedades del objeto los
porcentajes del mix de productos. La fuente, SOURCE, tiene una categoría de propiedades para asignar
valores de una tabla, “Table Reference Assignment”. Existe la posibilidad de realizar dos asignaciones:
antes de la creación de una entidad, Before Creating Entities, o justo después de haberlas creado, On
Created Entity. En este caso, queremos realizar la asignación antes de la creación deforma que se cree el
tipo de pieza de forma correcta (Figura 7.4).
Tabla de
Piezas
Fila
Figura 7.4: Haciendo la Asignación hacia la Tabla de Referencia

Puede especificar qué tabla (TableParts) y qué fila se asocian al objeto. En este caso, la fila se
determina de forma aleatoria utilizando los porcentajes incluidos en la columna PartMix y
especificando que se ha de generar una fila aleatoria (TableParts.PartMix.RandomRow).
Paso 11: La asignación a una tabla de referencia se puede realizar de forma alternativa utilizando un
disparador, “Add-On Process Triggers”, en el objeto fuente, SOURCE. El proceso que se dispara puede
añadir flexibilidad (aunque no sea necesario en este ejemplo), puesto que el objeto dispone de cuatro
disparadores distintos (Tabla 7.6).
Tabla 7.6: Disparadores Disponibles para un Objeto SOURCE

Disparador Descripción
Initialized Se ejecutará al comienzo de la simulación
Creating Entities Se ejecutará antes de que se cree la entidad
Created Entity Se ejecutará después de crear la entidad
Exited Se ejecutará justo después de que la entidad abandone la
fuente
Paso 12: El tipo de pieza se tiene que determinar antes de crear la entidad (Creating Entities). Para
llamar a este proceso de creación, Creating Entities, haga doble clic en la etiqueta para crear un proceso,
o utilice la pestaña “Processes”. Esta acción añadirá un proceso SrcParts_CreatingEntities así como
que hará que “Processes” sea la pestaña activa.
Paso 13: Hay que asociar también una fila de la tabla de piezas a la entidad que se va a crear. Incluya
la etapa Set Table (listada en la sección All Steps (A-Z)), arrastrándola entre Begin y End (Figura
7.5).
Figura 7.5: Añadiendo la Etapa Set Table en un Proceso

Paso 14: En la ventana de propiedades de la etapa Set Table (Figura 7.5), especifique qué tabla
(TableParts) y qué fila de la tabla se asocia al objeto. En este caso, la fila de determina de forma
aleatoria utilizando la columna PartMix y especificando que una fila aleatoria ha de ser generada
(TableParts.PartMix.RandomRow).
Figura 7.6: Propiedades de la Etapa Set Table

La fila aleatoria, “Random Row”, se obtiene como antes de la columna PartMix de la tabla TableParts.
Asegúrese de que el tipo de objeto, Object Type, se especifica como ficha, Token, porque la entidad no
ha sido todavía creada. Después de que se ejecute el proceso, se creará la entidad y se hará que herede
las propiedades de la ficha, TOKEN, asociada.
Paso 15: Ejecute la simulación por un período de 40 horas a velocidad lenta para asegurarse de que
las piezas siguen su secuencia correctamente y conteste a las preguntas siguientes:
Pregunta 2: ¿Cuánto tiempo está cada tipo de pieza en el sistema?
Pregunta 3: ¿Cuál es el grado de ocupación de las estaciones, SERVERS?
Pregunta 4: ¿Cuánto tiempo están las piezas (conjuntamente) en el sistema?
Pregunta 5: ¿Cuál es el grado de ocupación de cada recurso?

Sección 7.2: Un carril de transferencia
Suponga ahora que la transferencia entre las estaciones de la célula de fabricación se realiza con un carril de
transferencia, que es una cinta transportadora continua, continuous conveyor, posiblemente en circuito
cerrado, que tiene estaciones de carga/descarga. Cuando una pieza se sitúa en una de estas estaciones, la
línea entera se para hasta que la pieza se coloca sobre ella o se retira de ella. Estas operaciones tardan entre
0.5 y 1.5 minutos.
SIMIO dispone de dos formas de modelizar las cintas: acumuladoras, accumulating, y no acumuladoras,
non-accumulating. Las cintas acumuladoras permiten que las piezas se junten al final, puesto que la cinta se
sigue moviendo aunque no pueda descargar en una estación. Como ejemplo, se pueden mencionar las cintas
de rodillos. Una cinta no acumuladora se debe parar hasta que la operación de carga/descarga finaliza. Como
ejemplo, se puede mencionar los sistemas aéreos con balancinas que llevan piezas durante el ensamblaje de
coches.
Las cintas en SIMIO no tienen estaciones de carga/descarga, por lo que el carril de transferencia tendrá que
ser modelizado como una serie de cintas individuales. Como el carril se para durante las operaciones, el
concepto de no acumulación es el que hay que emplear, aunque las cintas deben coordinarse entre sí.
Paso 1: Cambie todos los caminos interiores del modelo a cintas. Seleccione un camino y acceda haciendo
clic con el botón derecho al submenú Convert To Type. Para mejorar visualmente el modelo, añada
decoradores de caminos para las cintas (Figura 7.7) a través de la pestaña “Path Decorators”.
Paso 2: Modifique también los símbolos de las piezas de forma que sus dimensiones sean de 1 un metro de
ancho por 1 metro de largo por medio metro de alto. Seleccione las cuatro piezas y cambie sus
dimensiones utilizando la propiedad General→Size and Location. Tendremos que ser un poco más
específicos sobre estas dimensiones cuando dimensionemos también la cinta. Hemos creado estos
símbolos utilizando la sección “Create” de la pestaña “Project Home”, y haciendo clic en “New Symbol”
y seleccionando “Create a New Symbol”. Cuando estemos creando el símbolo, debemos prestar atención
a su tamaño (la cuadrícula está en metros).
Nuevos Símbolos
para las piezas
Cintas
Figura 7.7: Vista en 3D de las Cintas Transportadoras

Paso 3: Es necesario especificar las propiedades de las cintas. Las longitudes de los caminos (recordemos
que eran 25, 35, 20, 30, y 40 yardas) no tienen que ser modificada. Selecciones las cinco cintas
(apretando la tecla ctrl.) y marque la velocidad como 0.5 metros/segundo para cada cinta. A la vez, y
manteniendo todas seleccionadas, hay que marcar la propiedad de acumulación, Accumulating, como
falsa, “False”, para cada cinta.
Paso 4: En la propiedad de alineamiento de la entidad, Entity Alignment, elija la opción Cell Location. Esta
opción equivale conceptualmente a dividir la cinta en celdas. Las piezas que van sobre la cinta han de ser
posicionadas sobre una celda. Así, fije el número de celdas en el número asociado a la longitud de la
cinta. Si no es así, y selecciona la opción Any Location, una pieza puede ir sobre la cinta en cualquier
lugar, incluso interfiriendo con otras.
Paso 5: Repita el paso anterior para cada cinta que conforma el carril de transferencia.
Paso 6: Dado que el carril de transferencia está formado por muchas cintas en vez de una, hay que
sincronizarlas de forma que cuando las piezas se cargan/descargan de una de las cintas, el carril entero
(el conjunto de cintas) se para hasta que acabe la operación.28 Defina primero una variable discreta de
estado (a partir de la pestaña “Definitions”) y denomínela como número de nodos funcionando,
NumberNodesWorking. Esta variable representará el número de nodos que están o colocando o
retirando piezas del carril. Cuando esta variable es 0, el carril se moverá, y cuando la variable de estado
sea al menos 1, el carril entero se pasará.
Paso 7: Añada ahora un proceso Nuevo (a través de la pestaña “Processes”, seleccione “Create Process”).
Llámelo On_Off_Entered. Este proceso consistirá en las etapas incluidas en la Figura 7.8.
Figura 7.8: Proceso que Refleja la Entrada/Salida de Partes del Carril

 Cuando una pieza llega a una operación de carga/descarga, la etapa Assign incrementa
NumberNodesWorking en una unidad (NumberNodesWorking = NumberNodesWorking +1)
y todas las cintas tienen que pararse, haciendo que su velocidad sea cero (Figura 7.9)
Figura 7.9: Incrementando el Número de Nodos Trabajando y Parando las Cintas

 La etapa Delay se utiliza para modelizar el tiempo de carga/descarga, que se asume que sigue una
distribución uniforme con un mínimo de 0.5 y un máximo de 1.5 minutos.
 La segunda etapa Assign reducirá el número de nodos trabajando, NumberNodesWorking.
28
La sincronización no es exacta dado que la cinta aguas abajo no conoce que una celda de la cinta aguas arriba está ocupada y que
piezas que están en una celda pueden entrar en conflicto con otras piezas que llegan de una cinta anterior.
 La etapa Decide se basa en la condición de que el número de nodos en espera es 0,
NumberNodesWaiting == 0, lo que significa que no hay otros nodos cargando o descargando
sobre el carril.
 La última etapa Assign hace que las cintas vuelvan a arrancar. SIMIO guarda internamente todos
las velocidades en metros por hora, por lo que una asignación de 0.5 se guardará como 0.5 metros
por hora. Si la variable de estado tiene unidades distintas, éstas se pueden especificar vía
asignaciones. Asegúrese de que cambia las unidades a metros por segundo o una especificación de
0.5 metros por segundo será tratada como 0.5 metros por hora 29. Puede convertir 0.5 metros por
segundo en 1800 metros por hora para que sean unidades consistentes con la interpretación de cómo
SIMIO realiza las asignaciones, así como evitar tener que hacer la conversión todas las veces. La
Figura 7.10 muestra cómo se arranca el carril.
Figura 7.10: Arrancando las Cintas

Paso 8: Hay que invocar el proceso genérico On_Off_Entered en el momento adecuado (cuando una pieza
se carga o descarga). Seleccione On_Off_Entered como el proceso a ejecutar desde todos los nodos y
del camino especificado en la Tabla 7.7.
Tabla 7.7: Todos los Disparadores que Deben ser Incluidos en la Lógica de Carga/Descarga
Disparador de Procesos A qué Objeto se Asocia
Exited Output@SrcParts (TRANSFERNODE)
Entered Input@StationA (BASICNODE)
Exited Output@StationA (TRANSFERNODE)
Entered Input@StationB (BASICNODE)
Exited Output@StationB (TRANSFERNODE)
Entered Path7 (PATH): El camino que sale de la célula.
Entered Input@StationC (BASICNODE)
Exited Output@StationC (TRANSFERNODE)
Pregunta 6: ¿Por qué no usar simplemente el proceso On_Off_Entered en el BASICNODE de
entrada/salida de la cinta?
Paso 9: Ejecute la simulación durante 40 horas a velocidad lenta para asegurarse de que las piezas siguen de
forma correcta la secuencia y conteste a las siguientes preguntas.
29
La presunción de un tiempo interno representa una elección de eficiencia en contra de la facilidad de uso.
Pregunta 7: ¿Cuánto tiempo está cada tipo de pieza en el sistema?
Pregunta 8: ¿Cuál es el grado de ocupación de cada estación, SERVERS?
Pregunta 9: ¿Cuánto tiempo emplean las piezas en ser procesadas?
Pregunta 10: ¿Cuántas piezas hay de media en el Conveyor2?
Pregunta 11: ¿Cuál es el tiempo medio de permanencia en el Conveyor3?
Sección 7.3: Fallos de Máquina en la Célula de Fabricación
Los fallos son parte de la mayoría de sistemas mecánicos. SIMIO proporciona algunos métodos
relativamente simples para modelizar estos fallos o roturas dentro de la sección de fiabilidad, “Reliability
Logic”, de los objetos SERVER (y también de otros objetos). Por supuesto, en el caso de un carril de
transferencia, se necesita parar el carril cuando una de las máquinas o estaciones esté siendo reparada.30
Asumamos que la Operación C, StationC, es poco fiable. En particular, asumamos que el tiempo entre
fallos, MTBF (Mean Time Between Failures), sigue una distribución exponencial con una media de 10
horas, mientras que el tiempo medio de reparación, MTTR (Mean Time To Repair), se modeliza con una
distribución Triangular (0.5, 1, 2), en horas.
Paso 1: En la sección “Reliability Logic” de la Operación C, especifique que el tipo de fallo, Failure Type,
se base en el tiempo, “Calendar Time Based”, que el tiempo entre fallos, Uptime Behavior, sea
Random.Exponential(10), con Units en horas, y que el tiempo de reparación, Time To Repair, sea
Random.Triangular(0.5,1,2), con unidades en horas (Figura 7.11).
Figura 7.11: Especificando Fallo y Reparación

Paso 2: Cuando falla la Operación C, StationC, se debe detener el carril entero, y debe reiniciarse una vez
que sea reparada la estación. Seleccione StationC y cree unos disparadores de procesos, reparando,
“Repairing”, y reparado, “Repaired”, para generar los procesos nuevos StationC_Repairing y
StationC_Repaired. El disparador “Repairing” se ha de invocar cuando suceda el fallo, mientras que el
disparador “Repaired” debe ser invocado cuando la estación haya sido reparada. En
StationC_Repairing, utilice una etapa Assign para desconectar todas las cintas y poner su velocidad,
DesiredSpeed, a “0”. En StationC_Repaired, utilice una etapa Assign para volver a arrancar las
30
El coste tremendo de parada debido a que se paraliza el carril entero es la razón fundamental de por qué cada vez es más difí cil
encontrar carriles y otros sistemas totalmente automatizados.
cintas si no hay nodos realizando operaciones de carga/descarga (asignando DesiredSpeed = 0.5
para todas las cintas) como se aprecia en la Figura 7.12.31
Figura 7.12: Disparadores de los Procesos Repaired y Repairing

Paso 3: El proceso On_Off_Entered no debería hacer que el carril arrancase si la Operación C, StationC,
ha fallado y está siendo reparada. Cambie la etapa Decide del proceso On_Off_Entered de forma que
la expresión condicional sea la siguiente32:
(NumberNodesWorking==0) && (StationC.Failure.Active==False)
Paso 4: Finalmente, cambie la animación de StationC de forma que tome el color rojo cuando ha fallado.
Seleccione StationC y haga clic en el botón “Add Additional Symbol”. Cambie el color del segundo
símbolo a rojo utilizando la sección Decoration. Después de seleccionar la estación StationC, asigne la
propiedad Current Symbol Index de StationC a Math.if(StationC.Failure.Active ==
1,1,0), lo que hará que el símbolo tome el valor 0 o 1 (acuérdese de que el indicador de símbolo
empieza en 0).33
Paso 5: Ejecute el modelo y asegúrese de que el carril se detiene cuando la estación está siendo reparada.
Pregunta 12: ¿Hay algo acerca de la animación que no le acabe de gustar?
 Algunas características de SIMIO explicadas en este capítulo tienen características análogas en

Arena. Pero Arena no ofrece la posibilidad de modificar los procesos ejecutados por los objetos,
ni visualiza la simulación en 3D.
 No es deseable en cambio que los tipos de fallo en SIMIO no incluyan como opción fallos
basados en el tiempo de proceso.
 En este capítulo se empiezan a explotar los procesos de SIMIO para desarrollar y modelizar
comportamientos más complejos de los objetos en el modelo.
 El uso del concepto de cintas transportadoras es relativamente fácil de implantar y favorece la
animación.
31
Copie las etapas Decide y Assign del proceso On_Off_Entered.
32
La función Object.Failure.Active devolverá “true” si el objeto ha fallado.
33
En el Capítulo 10 se discutirá en profundidad sobre fallos.
Capítulo 8
“Material Consumido”, Cambios, Propiedades: Un
Ensamblaje
 El objeto Estación de Trabajo, Workstation
 Tiempos de preparación dependientes de la secuencia
 Material consumido
 Propiedades
Sección 8.1: Ensamblaje de una Maqueta
Un proceso de ensamblaje de una maqueta es un proceso en el que se construye una maqueta a partir de los
componentes disponibles. Las peticiones de ensamblaje llegan a una estación de trabajo siguiendo una
distribución Poisson con un tiempo entre llegadas de 3 minutos. La orden se realiza por una cantidad de
unidades iguales. Las maquetas se ensamblan a partir de 3 componentes; un subcomponente SubA, un
subcomponente B, y dos conectores – este estructura de producto se denomina también lista de materiales o
Bill of Materials (BOM). Cada maqueta se procesa en un tiempo que se asemeja a una distribución triangular
de parámetros (0.1, 0.2, 0.3) minutos. Sólo se puede ensamblar una unidad a la vez en la estación. Se desea
obtener para el análisis de la estación el número de unidades producidas así como de componentes utilizados,
así como información sobre el cumplimiento de los pedidos.
Existen cuatro tipos de maquetas producidas a partir del mismo BOM, según el color: 15% amarillas, 20%
rojas, 35% azules, y 10% verdes. Después de completar un pedido, se necesita 1 minuto para limpiar la
estación, así como 2 minutos para prepararse para el siguiente pedido. Esta restricción sufrirá modificaciones
más adelante. Finalmente, los pedidos tardan en llegar a la estación entre 1 y 2 minutos, lo mismo que tardan
para llegar a la salida desde la estación.
Paso 1: Cree un nuevo modelo que tenga una fuente, SOURCE (OrdersArrive), un sumidero, SINK
(OrdersLeave), y una estación de trabajo, WORKSTATION (KitOperation) .
 Los caminos se recorren en Uniform(1,2) minutos.
 Las maquetas llegan cada Exponential(3) minutos.
 El tiempo requerido para cada maqueta se modeliza como Triangular(0.1, 0.2, 0.3)
minutos.
 La limpieza es de 1 minuto.
 El tiempo actual de cambio es de 2 minutos.
Paso 2: Incluya una nueva entidad, MODELENTITY, de nombre Orders.
Paso 3: Añada 3 símbolos adicionales para la entidad Orders. Seleccione Order y haga clic en el botón Add
Additional Symbol. Asigne color a los símbolos adicionales: “Amarillo”, “Rojo”, y “Azul”. Los símbolos
se enumeran empezando en 0.
“Material Consumido”, Cambios, Propiedades: Un Ensamblaje 59

Paso 4: Todos los objetos de SIMIO tienen ciertas características programadas. Las propiedades se
inicializan al comienzo de la simulación (por ejemplo, número inicial en el sistema, número máximo de
llegadas), y sus valores no pueden ser cambiados a lo largo de la ejecución. La variable de estado
Priority es un ejemplo para una entidad y ha sido utilizado con anterioridad para representar el tipo de
objeto. En SIMIO, tiene la posibilidad de añadir sus propias propiedades así como estados a los objetos.
Las propiedades, Properties, y los estados, States, se añaden utilizando la pestaña “Definitions”.
Seleccione MODELENTITY en el panel [Navigation] y seleccione la sección Definitions→States. Cada
pedido ha de tener una cantidad diferente y se necesita una variable de estado para almacenar esa
información.
 Debe usar la variable de estado discreta, “Discrete State Variable”, de nombre Picture, para
representar la imagen que va a representar a la entidad. Esa variable la proporciona SIMIO.
 Debe añadir, en cambio, otra variable de estado discreta, “Discrete State Variable”, de nombre
OrderQuantity, que representará la cantidad de maquetas en el pedido.
Paso 5: Se necesita una tabla para determinar el porcentaje de veces de cada tipo de pedido y el número
correspondiente al dibujo del símbolo. Seleccione MODEL en el panel [Navigation]. Cree una
TableSymbol para los dibujos de las entidades (Tabla 8.1) a través de la pestaña “Data”.
Tabla 8.1: Símbolo y Porcentaje por Tipo de Pedido
Paso 6: Hay que determinar el tipo de pedido (Verde, Amarillo, etc.), la cantidad que lleva el pedido, o
tamaño del pedido, y el dibujo correcto. Las asignaciones de valores a las variables de estado para las
entidades entrantes a través de la fuente serán realizadas por el disparador de procesos denominado
“procesado”, “Processed” y cuyo nombre será OrdersArrive_CreatedEntity. Es este proceso,
podemos realizar las asignaciones de los valores de las variables de estado para las piezas entrantes,
como se muestra en la Figura 8.1.34
Figura 8.1: Etapas del Proceso OrdersArrive_CreatedEntity

Paso 7: Use la etapa Set Table para asignar aleatoriamente la fila de TableSymbol a la entidad que será
utilizada en la etapa Assign para especificar la figura.
Pregunta 1: ¿Por qué se decidió utilizar la tabla en el disparador “Created” en vez de en el disparador
“Creating” como se hizo en la Figura 7.5?
34
En lugar de utilizar un disparador de procesos, se podía haber utilizado la asignación On Created Entity Table Reference
Assignment para conseguir el mismo objetivo.
Paso 8: Asigne el dibujo correcto así como el tamaño del pedido. Puede hacer esto en dos etapas diferentes o
en una misma etapa con múltiples filas, si hace clic en el botón “0 Rows”. Tiene que añadir cada
asignación como se muestra desde la Figura 8.2 hasta la Figura 8.4.
 Use el editor “Repeating Property Editor” para hacer asignaciones múltiples (Figura 8.2).
Figura 8.2: Haciendo Asignaciones Múltiples

 Haga que el dibujo represente el símbolo asociado con el tipo de pedido (Figura 8.3).
Figura 8.3: Asignación de Imagen

 Asigne la tamaño del pedido según una distribución Binomial (Figura 8.4).
Figura 8.4: Asignación del Tamaño del Pedido

Pregunta 2: Se está utilizando una variable aleatoria Binomial para modelizar el tamaño de pedido.
¿Por qué sumamos 1?
Paso 9: Guarde el modelo y ejecútelo durante un período de 8 horas
Pregunta 3: ¿Cuál es el tiempo medio de flujo para los pedidos?
Pregunta 4: ¿Cuántos pedidos fueron procesados en 8 horas?
Pregunta 5: ¿Qué nos falta en el modelo?
Sección 8.2: Tiempo de Preparación en Función de la Secuencia
Cuando la estación de procesado de las maquetas cambia de un color a otro, se incurre en un tiempo de
cambio o preparación de máquina que depende del color que precedió al pedido actual. El tiempo de cambio,
en minutos, se muestra en la Tabla 8.2.

Tabla 8.2: Tiempos de Cambio (De/A, From/To) en Horas
Añadamos los tiempos de cambio, dependientes de la secuencia, en nuestro modelo. En las propiedades de la
estación, WORKSTATION, se puede especificar los tiempos de cambio como si fueran constantes (Specific) (dos
minutos para cada operación). Pero antes de utilizar tiempos que dependan de la secuencia, debemos ver
cómo se incorporan los tiempos de cambio en un modelo de SIMIO.
Paso 1: Primero, se necesita una lista, LIST, de identificadores que se puedan utilizar en una tabla de
cambios, en la que, en este caso, se escriba como una lista de caracteres, Strings. Utilizando la pestaña
“Definitions”, genere una lista, LIST, de caracteres, de nombre Colors. Los contenidos de la lista Colors
corresponderán con los nombres de los colores asignados: “Green”, “Yellow”, “Red”, y “Blue” como se
muestra en la siguiente Figura. Es importante que se incluyan en el orden correspondiente a los símbolos
(0, 1, 2, y 3).
Figura 8.5: Lista de Colores

Paso 2: Utilizando la pestaña “Data”, añada una matriz de cambios, CHANGEOVERS, de nombre Changeover.
Use la lista Colors como lista asociada. Cambie las unidades de tiempo a horas e introduzca los valores
en la matriz a partir de la Tabla 8.2.
Paso 3: Especifique la lógica de los tiempos de cambio en la estación KitOperation (Figura 8.6).
 Setup Time Type: Sequence Dependent

 Operation Attribute: TableSymbol.Symbol
 Changeover Matrix: Changeover
Figura 8.6: Especificando los Cambios Según la Secuencia en la Operación
Paso 4: Se puede especificar el resto de elementos de la lógica para la estación de trabajo
 Propiedad Operation Quantity (el número de unidades en cada pedido):

ModelEntity.OrderQuantity

 Processing Batch Size (Lote): 1
(Este es el número de unidades que se pueden procesar simultáneamente. Por lo que si la cantidad,
Operation Quantity, es 10, y el tamaño de lote es 2, será necesario realizar 5 lotes para procesar el
pedido entero y con cada lote necesitando de un tiempo de proceso diferente.)
 Teardown Time (Limpieza): 1 minuto
Paso 5: La estación puede estar en estados distintos: esperando piezas, starved, procesándolas, processing,
preparándose, setup, y limpiando, teardown. Para ver cómo varían los porcentajes a lo largo del tiempo,
añada un gráfico de tarta, “Status Pie” a partir de la pestaña “Animation”. Especifique la propiedad Data
Type, como una lista de estados, ListState, que debe relacionarse con
KitOpereaton.ResourceState.
Paso 6: Guarde el modelo y ejecute la simulación para un período de 1 hora. Luego, ejecútelo en modo
rápido, fast-forward, para un período de 2, 4, y 8 horas. Después de 8 horas, conteste a lo siguiente.
Pregunta 6: ¿Cuál es el tiempo medio de flujo para los pedidos?
Pregunta 7: ¿Cuántos pedidos fueron procesados en 8 horas?
Pregunta 8: ¿Qué nos falta en el modelo?
Sección 8.3: Utilizando Materiales en la Operación
El objeto “estación de trabajo” tiene más posibilidades que un objeto “server”. Por ejemplo, puede utilizarse
para controlar las materias primas que tiene que consumirse, según lo especificado en el “bill of materials”
de la pieza que se está procesando. Si las materias primas no están disponibles, las piezas no pueden ser
procesadas.
Paso 1: Guarde el modelo como un nuevo proyecto.
Paso 2: Tenemos que declarar la existencia de las materias primas que lleva una maqueta así como la lista de
materiales que especifica la cantidad de cada tipo de materia prima que se necesita para fabricar una
maqueta. Se necesita definir cuatro nuevos “Elements”, del tipo MATERIAL, a partir de la sección
Definitions→Elements.
 Cree SubA, SubB, y Connectors como tipos de material, todos con una cantidad inicial, Initial
Quantities, de “0” unidades, lo que será cambiado en breve.
 Cree KitsBOM como un elemento tipo MATERIAL, pero utilizando el editor de propiedades
BillofMaterial, como muestra la Figura 8.7, en la que se define qué materiales componen el producto
final (1 SubA y 1 SubB y 2 Connectors).

Figura 8.7: Bill of Materials
 Finalmente, cree un elemento de tipo “Material” denominada Kits (con cantidad inicial, Initial
Quantity, de 0), para representar el producto final producido con las materias primas según el BOM.
Paso 3: Como el nivel de inventario es una característica física de nuestro modelo y sólo necesita ser
inicializado al comenzar la simulación, es el momento ideal de utilizar una propiedad de SIMIO.
Utilizando la pestaña “Definitions”, haga clic en “Properties” para añadir nuevas propiedades a los
objetos. Cree tres nueva propiedades “Standard Real Properties”, InitInvA, InitInvB, e InitInvC.
Coloque estas propiedades en la nueva categoría InvModel. La primera vez, hay que teclear el nombre
de la nueva categoría (InvModel) en la ventana correspondiente. Para las dos nuevas propiedades puede
seleccionar la categoría del desplegable.
Paso 4: Vuelva a “Elements” e indique Initial Quantity, de cada uno de los tres materiales como una
propiedad de referencia hacia las nuevas propiedades definidas. Recuerde que esta operación se realiza
haciendo clic con el botón derecho en el desplegable y seleccionando la propiedad de referencia.
Paso 5: Como parte del análisis, cree algunas estadísticas para estudiar los materiales que se han consumido
así como sobre el producto final. Existen tres tipos de estadísticas que se pueden definir. Recuerde que
una estadística “Tally” es una estadística basada en observaciones (por ejemplo, tiempo de espera en una
fila). Una estadística de estado, “State statistic”, es en cambio una estadística basada en el tiempo que
monitoriza una variable de estado (número en una fila). Una estadística de final de simulación, “Output
Statistic” puede utilizarse para mostrar el valor de una expresión, una vez al final de cada repetición.
Añada 4 estadísticas finales, OUTPUT STATISTICS, con los siguientes nombres y expresiones.
 SubAConsumed que muestre SubA.QuantityConsumed

 SubBConsumed que muestre SubB.QuantityConsumed
 ConecteorsConsumed que muestre Connectors.QuantityConsumed
 KitsProduced que muestre Kits.QuantityProduced
Paso 6: Vuelva a KitOperation y rellene las propiedades Other Requirements (por ejemplo, Material
Consumido, Material Consumption, Nombre del Material Consumido, Consumed Material Name,
Cantidad Consumida, Consumed Quantity, Producción de Materiales, Material Production, Nombre del
Material Producido, Produced Material Name, y Cantidad Producida, Produced Quantity) como se
muestra en la Figura 8.8. Estas propiedades harán que la estación consuma materiales según lo indicado
en el BOM cuando se procesan las maquetas.

Figura 8.8: Otros Requisitos de Material para una Operación
Paso 7: Haga clic en las propiedades del modelo, Model “Properties” (haciendo clic con el ratón derecho en
el objeto “Model” en el [Navigation Panel]). En la sección InvModel, asigne los valores de InitInvA
como 100, InitInvB como 100, y InitInvC como 200.
Paso 8: Guarde el modelo y ejecútelo por un período de 8 horas y observe las estadísticas. Aunque desee ver
la animación durante un rato, necesitará ejecutarlo en modo rápido hasta el final para obtener los
resultados.
Pregunta 9: Después de analizar el número de maquetas producidas, ¿tiene alguna duda sobre las
especificaciones del modelo?
Pregunta 10: ¿Cuántas maquetas se producen en el período de 8 horas?
Paso 9: Cambie el valor del inventario inicial para permitir que se produzcan maquetas durante las 8 horas.
Pregunta 11: ¿Cuántos pedidos se atendieron durante las 8 horas?
Pregunta 12: ¿Cuántas maquetas se producen ahora?
Pregunta 13: ¿Qué cantidad de materias primas SubAs y SubBs se necesitaron?
Pregunta 14: ¿Cuántos Connectors se utilizaron?
Pregunta 15: ¿Cuál es el tiempo de ciclo de los pedidos?
Sección 8.4: Llegada de Materia Prima Durante la Simulación
En lugar de que las materias primas estén disponibles para todo el período de 8 horas al principio de la
simulación, las materias primas han de llegar cada dos horas, empezando en 0. ¿Cómo se modeliza esta
nueva situación en SIMIO?
Paso 1: Tome algunas estadísticas sobre los niveles de inventario para las tres materias primas a lo largo de
un día: SubA, SubB, y Connectors. Dado que el inventario es una estadística basada en el tiempo, hay

que añadir primero tres variables de estado, STATE STATISTICS, utilizando la sección
Definitions→Elements.
 SubAAvailable: SubA.QuantityAvailable
 SubBAvailable: SubB.QuantityAvailable
 ConnectorsAvailable: Connectors.QuantityAvailable
 Para cada una de las estadísticas añadidas, incluya User como Category y Number como Data Item.
Paso 2: Guarde el modelo y ejecútelo durante un período de 8 horas utilizando como cantidades iniciales de
stock, 1000, 1000, y 2000 para SubA, SubB, y Connectors (especificándolas en “Model Properties”).
Pregunta 16: ¿Cuál fue la disponibilidad media de SubAAvailable?
Pregunta 17: ¿Cuál fue la disponibilidad media de SubBAvailable?
Pregunta 18: ¿Cuál fue la disponibilidad media de ConnectorsAvailable?
Pregunta 19: ¿Cuántas maquetas se han producido?
Paso 3: Implementemos ahora un sistema de reposición en el que un operario aparece por la estación de
maquetas cada dos horas, empezando en 0, y rellena stock de SubA, SubB, y Connectors hasta un nivel
prefijado.
Paso 4: Añada tres propiedades de tamaño de pedido, SubAOrderQty, SubBOrderQty, y ConnOrderQty,

utilizando la pestaña “Definitions”. Cada una de estas propiedades debe ser definida como “Integer” en
Data Format dentro de la categoría InvModel. Estas propiedades se usarán como las cantidades que el
operario utiliza para reponer el inventario de materias primas.
Paso 5: Utilizando la sección Definitions→Elements, añada un temporizador, TIMER, que lanzará un evento
basado en un intervalo de tiempo (un “timer event” es una interrupción en la simulación que permitirá
que un proceso se ejecute).
 Ejecute el temporizador en 0.0 (la propiedad Time Offset debe ser 0) y debe activar un proceso cada
2 horas (Time Interval debe ser 2).
 Llame StockerArrives al temporizador.
Paso 6: Utilizando la pestaña “Processes”, cree un proceso, RespondtoTimerEvent, que responda al

temporizador (Figura 8.9).
 Triggering Event: StockerArrives.Event

 Añada una etapa Assign que haga las asignaciones siguientes al proceso que iguala siempre la
cantidad disponible a la cantidad de pedido-
SubA.QuantityAvailable = SubAOrderQty
SubB.QuantityAvailable = SubBOrderQty
Connectors.QuantityAvailable = ConnOrderQty

Figura 8.9: Proceso Utilizado para Responder al Evento Generado por el Temporizador
Paso 7: En las propiedades del modelos, “Model Properties”, inicialice las cantidades de las materias primas
SubA, SubB, y Connectors a 0, ya que el primer evento StockerArrives sucede en el minuto 0.0 y se
rellenará el stock en el comienzo de la simulación. Fije las cantidades de pedido de SubA, SubB, y
Connectors en 250, 250, y 500, respectivamente.
Paso 8: Guarde el modelo y ejecútelo durante un período de 8 horas y conteste a lo siguiente.
Sección 8.5: Implantando un enfoque Justo-A-Tiempo (Just-In-Time)
El ejemplo anterior asume que el reponedor llegará exactamente cada dos horas y subirá el nivel de stock
hasta el límite establecido. Sin embargo, la compañía desea implantar una filosofía de producción similar al
Just-In-Time (JIT). Tienen un proveedor que tiene un almacén situado muy cerca de la planta y que
responderá a los pedidos rápidamente. La compañía ha implantado un sistema de monitorización tal que
cuando un pedido hace que el inventario baje por debajo de un límite, se lanza un pedido al proveedor que lo
ha de atender en 1 hora.
Paso 1: Guarde el modelo con su propio nombre. Tiene que borrar ahora el temporizador StockerArrives y
el proceso RespondToTimerEvent o deshabilítelo cambiando el valor de la propiedad Initially Enabled
a False, utilizando la propiedad “General” del temporizador, TIMER.
Paso 2: Añada un nuevo sumidero, SINK, InventoryLevel. Posiciónelo debajo de la estación que fabrica la
maqueta.
Paso 3: Vaya a la pestaña “Definitions” y añada tres elementos controladores, MONITOR, MonitorA,
MonitorB, y MonitorC, utilizando la sección “Element”. Un elemento controlador puede ser utilizado
para monitorizar el valor de una variable de estado cuando ésta cambia su valor o cuando el valor cruza
un límite. Las propiedades de MonitorA se pueden ver en la Figura 8.10.

Figura 8.10: Propiedades del Controlador
Lo siguiente ayuda a controlar el nivel de inventario de SubA.
 Monitor Type debe ser CrossingStateChange

 Crossing Direction debe ser Negative (una reducción de 5 a 4 hará que se lance un evento)
 El Threshold Value debe indicar una propiedad a una nueva referencia, New Reference,
SubAReorderPT.
 El controlador puede causar que un evento se lance de la misma forma que un temporizador,
pero no utilizaremos esta cualidad en este momento.
Paso 4: Repita el mismo proceso para las materias primas SubB y Connector utilizando las propiedades de
referencia SubBReorderPt y ConnReorderPt, respectivamente.
Paso 5: Añada tres Fuentes, SOURCES (suppliers), SupplierA, SupplierB, y SupplierC, que enviarán las
materias primas a la estación, como se muestra en la Figura 8.11.
Figura 8.11: Proveedores

 Asuma que se tarda entre 50 y 65 minutos en suministrar las materias primas entre las Fuentes y el
sumidero Inventory (el tiempo se modeliza con la propiedad Travel Time de un TIMEPATH).
 Fije la propiedad Arrival Mode de los proveedores en On Event y los nombres Event Name
to MonitorA.Event, MonitorB.Event y MonitorC.Event respectivamente para
cada una de las tres fuentes. La fuente creará entidades cuando el evento generado por el
controlador se activa y manda las entidades a la operación correspondiente.
Paso 6: Cuando la material prima llega al final del camino, necesita sumar al nivel actual la cantidad del
pedido. Añada un disparador de proceso (“ReachedEnd”) que calcula este nuevo valor. La Figura 8.12
enseña cómo añadir la cantidad SubA y el tamaño de pedido35.
35
SIMIO proporciona una etapa producir, Produce, que hace esencialmente lo mismo y otra consumir, Consume, con la que se
realiza una resta, pero la lógica utilizando una etapa Assign parece directa.
Figura 8.12: Incrementando la Cantidad Disponible
Paso 7: Repita el proceso para las otras dos materias primas al final de sus respectivos caminos.
Paso 8: En las propiedades del modelo, fije los valores iniciales de las materias principales SubA, SubB, y
Connectors otra vez en 250, 250, y 500, dado que la acción de reposición se activa convenientemente.
Fije los puntos de pedido y los tamaños de pedido en los valores incluidos en la Tabla 8.3.
Tabla 8.3: Punto de Pedido (Reorder Point) y Tamaño de Pedido (Order Quantity)
Materia Punto de Tamaño de
Prima Pedido Pedido
SubA 125 200
SubB 125 200
Connector 250 400
Paso 9: Añada seis etiquetas de estado, “Status Labels” utilizando la pestaña “Animation”, para que se
muestren las cantidades disponibles de cada uno de los tres niveles de materias primas disponibles:
SubA, SubB, y Connectors (Figura 8.13). Estas primeras tres etiquetas son simplemente texto, mientras
que las otras tres tendrán una expresión (Figura 8.14) para mostrar la cantidad disponible
QuantityAvailable.
Figura 8.13: Etiquetas de Estado
Figura 8.14: La Expresión de las Etiquetas de Estado

Paso 10: Guarde el modelo y ejecútelo durante un período de 8 horas, y conteste a las siguientes
preguntas.

 Este es uno de los capítulos más interesantes en cuanto que ilustra cómo modelizar lo que se
considera un operación compleja compuesta no sólo por temas de inventarios, sino también por
conceptos relacionados con la cadena de suministros, que serán nuevamente explorados en el
Capítulo 12, Capítulo 22 y Capítulo 25.
 Se han introducido otras capacidades muy valiosas en este capítulo que deberían ser ampliadas,
lo que haremos en capítulos futuros.
 Como si fuera un ejercicio de modelización, ¿cómo construiría un modelo equivalente en otro
lenguaje de simulación?

Capítulo 9
Variables Continuas, Abandonos, Interrupciones,
Verificación: Una Gasolinera
 Variables continuas
 Más procesos
 Abandono en una fila
Las variables continuas son variables cuyo valor puede cambiar durante la simulación (al contrario que las
variables discretas). Las variables continuas se conocen en SIMIO como variables de nivel, “Level State”–
véase “States” en la pestaña “Definitions”. Cuando se crea una variable de nivel, puede especificar también
el flujo, utilizando la propiedad Rate Value, así como su valor inicial, Initial State. Al contrario que las
variables discretas, DISCRETE STATE, las variables de nivel, LEVEL STATE, pueden cambiar de forma
continua en función de un ritmo.
Sección 9.1: Un Tanque Simple36
Paso 1: Cree un nuevo modelo. Vamos a gestionar un simple tanque de gasolina, haciendo que cambia el
valor de su ritmo de llenado y/o vaciado. Asumiremos que el volumen del tanque puede variar entre 0 y
100 galones.
Paso 2: Añada un objeto RESOURCE, y llámelo Tank.
Paso 3: Cree un nuevo símbolo, TankSymbol, para asociarlo con el tanque (Project Home→New
Symbol→Create Symbol), y que se asemeje al mostrado en la Figura 9.1. El símbolo que representa el
interior es un cuadrado con una altura de 10 metros (la altura determina el contenido/nivel del tanque).
Añada un textura Gold Comb para asemejarlo al color de la gasolina.
Figura 9.1: Representación en 2D y 3D del Símbolo del Tanque
36
Este ejemplo de un “tanque simple” ha sido elegido de los “SimBits” que proporciona SIMIO. Se le aconseja revisar a menudo los
pequeños modelos, Simbits, a medida que aprende SIMIO.
Variables Continuas, Abandonos, Interrupciones, Verificación: Una Gasolinera 71

Paso 4: Use TankSymbol como símbolo de Tank.37 Una vez que está hecho, dibuje una caja estática a su
alrededor, de forma que pueda ver el nivel del tanque en 3D (Figura 9.2). La caja está hecho utilizando
una polilínea ancha, dejando una pequeña apertura en el frente, de forma que se vea el nivel. La polilínea
también necesita tener una altura de 10 metros.
Figura 9.2: Símbolo del Tanque

Paso 5: Añada una variable de nivel, LEVEL STATE, de nombre TankLevel, utilizando la sección
Definitions→States. Fije el nivel inicial, Initial State, en 0 y el flujo inicial, Rate Value, en 0. Un valor
negativo del flujo indica que el tanque se está vaciando mientras que el valor positivo indica que se está
llenando.
Paso 6: Añada dos elementos controlador, MONITOR: TankEmpty y TankFull. Estos controladores
detectarán si el valor TankLevel cruza los valores 0 y 100 respectivamente.
Paso 7: Para TankEmpty, fije sus propiedades como se muestra en la Figura 9.3.
Figura 9.3: Especificación de TankEmpty

Paso 8: Y haga lo mismo para TankFull (Figura 9.4).
Figura 9.4: Especificación de TankFull
37
Seleccione el objeto y elija los símbolos de la pestaña “Symbols”.
Paso 9: Cree un nuevo proceso para los dos disparadores del tipo On Event Process, y defínalos según la
Figura 9.5 y la Figura 9.6.38
Paso 10: El proceso que se ejecuta cuando se vacía el tanque, “TankEmpty_OnEventProcess”, se

inicia cuando el tanque se vacía (TankLevel = 0). Necesitaremos que el tanque se deje de vaciar, que
espere a que lleguen provisiones y pueda empezar a llenarse, y luego se vaya llenando (Figura 9.5).
Figura 9.5: Cuando se Vacía el Tanque

La etapa Assign fija tanto el flujo TankLevel.Rate en 0, lo que hace que la variable de nivel,
LEVEL STATE, no cambie, y fija la altura Tank.Size.Height en 0. Use la etapa Delay para forzar
una espera de 0.2 horas antes de que el tanque empiece a llenarse otra vez. La última etapa Assign
fija el flujo TankLevel.Rate en su máximo nivel de 100, lo que ayuda a que el tanque empiece a
llenarse dado que el valor asignado es positivo.
Paso 11: El proceso que indica que el tanque está lleno, “TankFull_OnEventProcess”, se activa
cuando el tanque llega a su nivel máximo. Las etapas del proceso son, entonces, parar de llenar, esperar a
que llegue demanda, y empezar a vaciar (Figura 9.6).
Figura 9.6: Cuando se Llena el Tanque

La etapa Assign fija el flujo TankLevel.Rate en 0. Se espera durante 0.1 horas. La última etapa
Assign asigna un valor negativo al flujo (por ejemplo, TankLevel.Rate = -200).
Paso 12: Finalmente, tenemos que tener cuidado con la altura del tanque en la animación. Lo haremos
en el proceso que se ejecuta al iniciar la simulación, “OnInitialized”. Utilizando la pestaña “Processes”,
seleccione OnInitialized del desplegable “Select Process”. La etapa ejecutar, Execute39, hace que se
inicialice “TankEmpty_OnEventProcess” y empiece el tanque a llenarse. La etapa Delay hará que el
proceso se pare durante un minuto y la etapa Assign fija la altura Tank.Size.Height en
TankLevel/10 (Figura 9.7).
38
Puede o bien crear el proceso aquí para que responda al evento generado por MONITOR o bien puede crear un proceso genérico con
la propiedad Triggering Event fijada en dicho evento, TankFull.Event.
39
La etapa Execute iniciará cualquier proceso que haya sido definido.

Figura 9.7: Cambiando la Altura del Tanque
Aprecie que el sistema itera continuamente cada minuto, actualizando la altura del tanque para mejorar
la animación. Simplemente, agarre una esquina, “End”, y arrástrela.
Paso 13: Para que el nivel se muestre durante la animación, el indicador Current Symbol Index de la
sección “Animation” del Tank, debe ser fijado en 0, por lo que el proceso durante la inicialización,
“OnInitialized” se usa para especificar el cambio de altura. Seleccione el tanque Tank y un símbolo
adicional, y fije la propiedad Current Symbol Index en 0.
Paso 14: Para completar la animación, añada tres etiquetas de estado, Status Labels, en la pestaña
“Animation” y etiquetas de texto, Floor Labels (Text) (Figura 9.8). Las expresiones correspondientes
son, respectivamente, TankLevel.Rate, TankLevel, y Tank.Size.Height.
Etiquetas de Etiquetas de
Estado Texto
Figura 9.8: Añadiendo Status Labels

Paso 15: Añada una gráfica de estado, Status Plot, del nivel del tanque TankLevel en función del
tiempo (1 hora) – véase Figura 9.9.
Figura 9.9: Gráfica de Estado

Paso 16: Sitúe un medidor circular, a Circular Gauge (panel “Animation”), encima del tanque (Figura
9.10).40 Es una forma de visualizar el nivel del tanque en 2D. En la sección escala, Scale, fije la
propiedad Minimum en 0, la propiedad Maximum en 100 y el número de Ticks en 11. La expresión
Expression debe ser la variable de nivel TankLevel.
40
En la vista 3D, use la tecla shift para mover el medidor y colocarlo justamente encima.
Figura 9.10: Añadiendo un Medidor Circular al Nivel del Tanque
Paso 17: Guarde el modelo y ejecútelo mientras observa las etiquetas de estado y los gráficos.
Cambie a 3D para ver cómo sube y baja el contenido del tanque.
Pregunta 1: ¿Parecen convenientes la animación y los gráficos?
Pregunta 2: ¿Por qué el tanque se vacía más rápido de lo que se llena?
Sección 9.2: La Gasolinera
Una gasolinera tiene 4 surtidores con el mismo tipo de gasolina. Todos los surtidores se abastecen del mismo
tanque. Los coches que llegan pueden entonces acceder a cualquier surtidor. Si el tanque se vacía por debajo
de 100 galones, los surtidores se cierran, aunque finalizan las operaciones en curso. Cualquier coche en
espera continuará en la fila, pero los coches que llegan nuevos se irán. Un camión aparece de vez en cuando
a reponer gasolina. Llena el tanque (10000 galones), y los surtidores se vuelven a abrir.
El problema se puede atacar desde distintos puntos de vista. Una variable continua se puede utilizar para
modelizar el tanque, y los coches y el camión son los que van cambiando los flujos de entrada y de salida al
tanque. Los vehículos serán entonces nuestras entidades activas. La cantidad que repostan los coches en
galones sigue una distribución Triangular (4, 9.5, 25). El flujo de llenado de los coches en galones por hora
es Triangular (100, 125, 175). El camión llenará el tanque a 20000 galones por hora.
Paso 1: Modificaremos el tanque modelizado en la sección anterior. Añada dos fuentes, SOURCES, un
servidor, SERVER, tres sumideros, SINKS y dos entidades, MODELENTITIES, denominadas Cars y
RefillTrucks (Figura 9.11). Los coches Cars llegan según un modelo exponencial de media 1.5
minutos, con la primera llegada en 0.1, mientras que los camiones RefillTrucks llegan con una
separación en horas según una distribución uniforme entre 6.75 y 8.25. Use conectores, CONNECTORS,
para unir los objetos.

Figura 9.11: Estructura del Modelo
Paso 2: Defina una variable de estado discreta, DISCRETE STATE, de nombre PumpOn. Utilícela para
determinar si los surtidores (pumps) están abiertos o cerrados. Un valor de 1 indica que están abiertos y
un valor de 0 que están cerrados. Inicialice el valor inicial, Initial State Value, a 0.
Paso 3: Especifique el valor inicial, Initial State Value, de la variable de nivel, “LEVEL STATE”, denominada
TankLevel como 100.
Paso 4: Modifique los dos controladores, MONITOR, que vigilan el tanque y cree eventos que determinen que
el tanque está lleno o vacío. Cambie la propiedad de valor límite, Threshold, de TankEmpty a 100 de
forma que nuestro tanque no se vacíe completamente, y el valor TankFull a 10000 galones.
Paso 5: Inserte un elemento estadística de estado, STATE STATISTIC, de nombre StatisticsTank. Este
elemento proporcionará una estadística basada en el tiempo sobre el nivel del tanque (inventario medio).
Paso 6: Para los coches (MODELENTITY), definamos sus estados. Seleccione MODELENTITY en el panel
[Navigation]. Incluya los dos siguientes estados que serán característicos de cada coche a su llegada.
 Gasolina necesaria, GasNeeded, es una variable de estado discreta, “Discrete State”, con un valor
inicial, Initial State Value, de 0.
 Ritmo o flujo de llenado, CarPumpingRate, es otra variable de estado discreta, “Discrete State”,
con un valor inicial, Initial State Value, de 0.
Paso 7: Cuando los coches dejan su fuente, defina un proceso que se dispara con el disparador “Exited” de
Output@scrCars como se muestra en la Figura 9.12, para asignar las características al coche.41
Figura 9.12: Coches Saliendo de la Fuente
41
A lo largo y ancho de este ejemplo utilzaremos la etapa Assign en vez de las asignaciones de estado, Assignments, incluidas en los
objetos. Las etapas Assign son más generales puesto que las asignaciones sólo están disponibles en la entrada y la salida de un
objeto.
La etapa Assign garantiza con las variables de estado siguientes que el flujo es negativo.
ModelEntity.GasNeeded = Random.Triangular(4,9.5,25)
ModelEntity.CarPumpingRate = -Random.Triangular(100,125,175)42
Paso 8: Especifique la propiedad de tiempo de proceso, ProcessingTime (en horas), en la estación

SrvPumpGas como.
-ModelEntity.GasNeeded/ModelEntity.CarPumpingRate
La expresión toma en consideración la cantidad total de gasolina necesaria dividida por el flujo posible
de llenado. El signo negativo denota que el ritmo de llenado es negativo. Asegúrese que la propiedad de
capacidad inicial, Initial Capacity, de la estación SrvPumpGas se fija en 4 para indicar que hay sitio
para cuatro coches.
Paso 9: Si los surtidores están encendidos, los coches serán dirigidos hacia los surtidores, y si están apagados
se mandarán directamente al sumidero SnkCarsNoGas. Los pesos de los caminos que salen de las
fuente se definen como sigue para garantizar que un camino tenga un peso de 1 y el otro de 0.
 Para la conexión hacia SnkCarsNoGas, fije el peso, Selection Weight, como 1 – PumpOn.
 Para la conexión hacia SvrPumpGas, fije el peso, Selection Weight, como PumpOn.
Paso 10: Todos los lenguajes de simulación utilizan eventos y en SIMIO el usuario puede definir los
suyos propios. Utilizando la pestaña “Definitions”, añada un nuevo evento, EVENT, de nombre
EvntStartPumps, que permitirá que las entidades esperen a que los surtidores estén encendidos otra vez
después de que fueran apagados.
Paso 11: Considere lo que sucede cuando el camión llega (Figura 9.13). El camión apagará los
surtidores y empezará a llenar el tanque con una velocidad de 20000 galones por hora. El camión seguirá
llenando hasta que el tanque esté lleno (cuando TankFull alcance el límite). Utilice el disparador
“Entered” en el nodo de entrada de SnkTankLeaves (cuando el camión entra en el sumidero
correspondiente).43
Figura 9.13: Retirada del Camión

 En la etapa Assign, fije la variable de estado PumpOn en 0 y el flujo TankLevel.Rate en
20000 galones por hora (Figura 9.14).
42
Un flujo negativo implica la salida de gasolina del tanque y uno positivo llenado del tanque.
43
Es necesario invocar este proceso después de que el camión abandone el nodo de salida de la fuente para que se pueda calcular el
tiempo que está el camión en el sistema. Si el proceso se invoca antes de que salga de la fuente, el tiempo en el sistema no se
actualiza.

Figura 9.14: Apagando un Surtidor y Llenado el Tanque
 La etapa espera, Wait, retrasa el camión hasta que el tanque está lleno, lo que se avisará con un
evento denominado EvntStartPumps.
Figura 9.15: Esperando a que se Puedan Reiniciar los Surtidores

Paso 12: En la estación SvrPumpGas, considere en primer lugar el momento en que un coche
empieza a llenarse de gasolina (véase Figura 9.16)
Figura 9.16: El Procesamiento Empieza en el Surtidor

 Cuando el disparador “Processing” empieza:
La etapa “Decide” comprueba si el surtidor está encendido, PumpOn == 1
Si está apagado, entonces espere, etapa Wait, al evento EvntStartPumps.
En caso contrario, si está funcionado, cambia la velocidad de vaciado del tanque utilizando una etapa
Assign, añadiendo el ritmo de llenado del coche correspondiente:
TankLevel.Rate = TankLevel.Rate+ModelEntity.CarPumpingRate.
Paso 13: Cuando un coche acaba de llenarse en el surtidor (disparador “Processed” de

SrvPumpGas), Figura 9.17, necesitamos reducir la velocidad de vaciado del tanque:

TankLevelRate = Math.if(PumpOn==1,TankLevel.Rate-ModelEntity.CarPumpingRate,
TankLevel.Rate).
Figura 9.17: Coche Cambiando la Velocidad de Vaciado

Pregunta 3: ¿Por qué se necesita la función Math.if?
Pregunta 4: ¿De qué otra forma podíamos haber modelizado el cambio?
Paso 14: Haga el proceso correspondiente a cuando el tanque se queda vacío, utilizando el
controlador TankEmpty (Figura 9.18). Elimine las dos últimas etapas, dejando sólo la etapa Assign
que apagará los surtidores (PumpOn = 0.0) y cambie la velocidad a 0 (TankLevel.Rate =
0.0).
Figura 9.18: El Tanque está Vacío

Paso 15: Y para el evento TankFull, correspondiente a cuando se llena el tanque (Figura 9.19), se ha de
introducir cambios para encender los surtidores y dejar acercarse a los coches que estén esperando así
como dejar irse al camión.
Figura 9.19: El Tanque está Lleno

Fije la velocidad del tanque en 0 y abra los surtidores, utilizando la etapa Assign con las siguientes
asignaciones:
TankLevel.Rate = 0
PumpOn = 1
Use la etapa disparar, Fire , para que se ejecute el evento EvntStartPumps.
Paso 16: Cuando el evento EvntStartPumps se dispara, el camión que está esperando para que se
acabe el llenado se activa, lo mismo que los coches que están en espera.

Paso 17: Modifique el medidor circular, Circular Gauge, para que el máximo valor sea 10000 así como la
etapa Assign del proceso “OnIntialized” para dividir TankLevel entre 1000 en vez de entre 10.
Paso 18: Guarde el modelo y ejecútelo durante un período de 48 horas.
Pregunta 5: ¿Qué se aprecia en el medidor circular y en las gráficas?
Pregunta 6: ¿Funciona el sistema (cuántos coches consiguen gasolina y cuántos no)?
Pregunta 7: ¿Cuál es el nivel medio en el tanque?
Sección 9.3: Abandono Cuando los Surtidores se Apagan
En el modelo anterior se asumía que cuando el camión llegaba y se apagaban los surtidores, los coches
seguirían esperando a que se volvieran a encender. Modifiquemos el modelo de forma que todos los coches
que están esperando abandonen la fila y se vayan.
Paso 1: Cuando el camión llega, los coches que están esperando han de ser sacados de la fila de entrada de la
estación SrvPumpGas. Cuando se apague el surtidor, añada una etapa Search, que busque una
colección de objetos en una tabla, una lista, una instancia de un objeto, una fila, así como objetos
apresados por el padre o por objetos asociados. En este caso, fije la colección, Collection Type, a
“QueueState”, y el nombre de la fila, Queue State Name, a SrvPumpGas.AllocationQueue, por
lo que se buscarán coches en esa fila (Figura 9.20).
Paso 2: La búsqueda ha de encontrar todos los coches que están esperando, por lo que debe fijar la propiedad
del límites de entidades, Limit, en infinito, Infinity. La condición de casamiento, Match Condition,
permitirá que se busque ciertos objetos. Se podía haber dejado en blanco en este caso para que
devolviera un lista con todos los coches. Sin embargo, si elegimos caminos para unir objetos y un coche
estuviera en el camino y llegara a la vez que llega el camión, podría haber un coche que hubiera
accedido a un surtidor y estuviera en el estado espera para que el surtidor arrancara.
Figura 9.20: Haciendo que Abandonen Todos los Coches que están en Espera cuando se Apagan los
Surtidores

Paso 3: Inserte una etapa retirar, Remove, que hará que se eliminen todas las entidades que hay en
SrvPumpGas.AllocationQueue.
Paso 4: Añada un sumidero, SINK, denominado SnkCarsRenege, que ayudará a obtener estadísticas de los
coches que abandonan y se retiran.
Paso 5: Incluya un nodo, Set Node, que identifique la fila de entrada de SnkCarsRenege,
Input@SnkCarsRenege, como el nodo al que se envían los coches que abandonan. Hágalo con una
transferencia, Transfer, desde la operación actual hasta ese nodo.
Paso 6: Guarde el modelo y ejecútelo, observando qué sucede cuando llega el camión.
Pregunta 8: ¿Abandonan los coches que están esperando (es posible que tenga que mirar en los
resultados)?
Pregunta 9: ¿Cuántos coches abandonan en 48 horas de simulación?
Sección 9.4: Interrumpiendo el Suministro a los Coches Cuando el Surtidor se Apaga
En el modelo anterior, los coches que estaban esperando en el surtidor abandonaban la gasolinera cuando los
surtidores se apagaban. Los coches que estaban ya obteniendo gasolina del surtidor, seguían llenado el
depósito, y después se iban. Ningún otro coche debía ser enviado a los surtidores mientras están apagados.
Supongamos ahora que queremos que se interrumpa el suministro incluso para los coches que están en
operación. Estos coches dejarán el sistema utilizando también la misma salida, EXIT, SnkCarsRenege.
Paso 1: Para interrumpir el proceso de llenado, incluya una etapa interrumpir, Interrupt, antes de la
etapa Search (Figura 9.21). Esta etapa conecta los coches que han sufrido el parón con Set Node,
que había sido utilizado previamente para forzar a que los coches usaran el mismo sumidero
correspondiente a los coches que abandonan el sistema.
Figura 9.21: Interrumpiendo a los Coches en Servicio

 Use el nombre de proceso, Process Name, denominado SvrPumpGas.OnEnteredProcessing,
correspondiente al proceso que ejecuta la etapa Delay (procesado de los coches). Advierta que
forzamos a que se acabe el proceso, “EndProcess”, para los servicios interrumpidos, y que
establecemos un límite, Limit, de 4 ya que existen 4 surtidores que pueden estar potencialmente
operativos.

Pregunta 10: ¿Cómo puede decir si la interrupción está funcionando?
Pregunta 11: ¿Cuántos coches utilizaron el sumidero de abandonos durante las 48 horas de simulación?
Sección 9.5: Buscando Errores
Hasta ahora, seguro que ha cometido algún que otro fallo. SIMIO advierte de algunos de estos fallos. Sin
embargo, hay muchos otros que pasan sin que SIMIO lance ningún mensaje de advertencia o error. Quizás
sólo advierta que las entidades no se movían como esperaba. O quizás las estadísticas no parecían las
correctas. Podemos catalogar estos errores como lógicos. El modelo puede ser un modelo válido, SIMIO y
ser ejecutado sin errores, pero puede no estar funcionando como debiera.
En la pestaña “Project Home”, se encuentra la sección “Windows” que incluye ventanas para perseguir un
valor, “Trace”, mostrar errores, “Error”, vigilar una variable, “Watch”, o buscar algo, “Search”. Sólo esta
última ventana, “Search”, puede ser utilizada directamente para buscar lo que desee. La ventana “Error” se
activa cuando SIMIO detecta un error.
Paso 1: En la pestaña “Run”, haga clic en “Model Trace” y advierta que la ventana correspondiente se abre.
Si ejecuta la simulación haciendo clic en el botón “Step” de la sección “Run”, verá que se ejecuta cada
paso de la simulación.
Paso 2: Haga clic en “Step” varias veces. Se describe la información sobre la hora, Time, la entidad, Entity,
el objeto, Object, el proceso, Process, la ficha, Token, la etapa, Step, y la acción, Action. ¡Es mucha
información!44
Paso 3: Puede hacer clic con el botón derecho en una línea concreta así como filtrar por objeto o proceso.
Pregunta 12: Si en la hora 0.0 llegan un camión y un coche, ¿cuál llega primero?
Pregunta 13: Si en la hora 0.0 llegan un camión y un coche, ¿qué condición es necesaria para evitar que el
coche se aprovisione con gasolina?
Pregunta 14: ¿Cuándo llega el segundo camión?
Pregunta 15: ¿Qué coche es el primero en abrir el depósito y empezar a llenarlo?
Paso 4: Haga clic con el botón derecho en SnkCarsWithGas e introduzca un punto para que el modelo se
pare, breakpoint. Deje funcionado la lupa, Trace.
Pregunta 16: ¿Cuándo se va de la gasolinera el primer coche?
Paso 5: Haga clic con el botón derecho en SnkCarsWithGas y elimine el punto de parada, breakpoint. En la
pestaña “Run”, pare y resetee. Haga clic con el botón derecho en SnkTankerLeaves y seleccione
44
La información se vuelca automáticamente en un fichero con extension CSV, que se almacena en el mismo directorio que donde se
guarda el modelo. Se puede abrir con Excel para su análisis. Recomendamos utilizarlo para buscar y filtrar la información.
vigilar, “Watch”. Cambie la duración de la repetición a 24 horas y ejecute prestando atención a la nueva
ventana.
Pregunta 17: ¿Cuál es el número de observaciones de este objeto?
Pregunta 18: ¿Cuál es el tiempo medio en el sistema?
Paso 6: Desactive la ventana watch de SnkTankerLeaves y haga clic en la pizarra, “Open Dashboard
Window”, del objeto SrvPumpGas. Haga que la pizarra sea lo suficientemente grande como para verla
entera. Ejecute el modelo, pero párelo, Pause, de vez en cuando y ejecútelo paso a paso, “Step”.
Pregunta 19: ¿Aprecia cómo cambian los valores en la pizarra?
Pregunta 20: Incremente la llegada de coches (tiempo entre llegadas de 2 minutos) de forma que haya más
actividad en la pizarra. ¿Aparece ahora el gráfico con los contenidos de la fila de entrada,
InputBuffer.Contents?
Paso 7: Algunas veces, incluso las numerosas ventanas no son suficientes. Una forma interesante para ver
cómo cambian las variables de estado para las entidades a medida que se mueven por el sistema, es
utilizar una etiqueta de estado, “Status Label.” Seleccione el símbolo Cars y en la pestaña “Symbols”
seleccione “Status Label”. Cuando hace esta selección, el cursor cambia a una cruz, y puede colocar un
rectángulo cerca de los símbolos cuyo contenido es una expresión. Fije la propiedad Expression asociada
a STATUS LABEL con el valor de la variable de estado GasNeeded.
Paso 8: Ejecute el modelo de cero y durante un rato. Párelo y ejecútelo paso a paso.
Pregunta 21: ¿Advierte cómo las variables de estado aparecen en la animación?
Paso 9: Puede añadir y mostrar otras expresiones como etiquetas de estado para las entidades o para otros
objetos.
 Las variables continuas en SIMIO pueden ser muy útiles, aunque los cambios de velocidad
(segunda derivada) son constantes. La modelización de estos cambios es más flexible en Arena
ya que permite introducir sistema de ecuaciones diferenciales.
 El uso de los “Simbits” no debe ser infravalorado. Contienen numerosos ejemplos de enfoques
muy útiles sobre ciertos temas clave.
 Se han introducido los conceptos de abandono e interrupción en este capítulo. El abandono de
una fila permite que las entidades se muevan o sean destruidas. Los procesos también pueden ser
interrumpidos. Estas características no se usan a menudo, pero cuando son necesarias, son muy
valiosas. Advierta también que la modelización se consigue utilizando procesos, no a través de
especificaciones adicionales y precisas sobre objetos, como suele suceder en otros lenguajes de
simulación. El enfoque dota de una considerable flexibilidad al usuario.
 Las posibilidades de detección de errores en SIMIO son amplias. Cuando se combinan con la
animación, los comandos trace, breakpoint, watch, y dashboard window, pueden proporcionar el
detalle necesario sobre el comportamiento del modelo de simulación.

Capítulo 10
Recursos Múltiples que Fallan: Clínica de Cuidados
Intensivos
 Usando la capacidad de un servidor, SERVER, para modelizar recursos múltiples.
 Usando la lógica de fiabilidad de un servidor, SERVER, para modelizar fallos y excepciones.
Una nueva clínica de cuidados intensivos de urgencia acaba de ser abierta y a los gerentes les gustaría
analizar su operativa, para asegurarse de que sus clientes no esperan demasiado a la vez que se determina la
plantilla óptima en cuanto a número. Cuando un cliente llega, se da de alta en la ventanilla de la
recepcionista, quien verifica que toda la información es la correcta. Después, espera a que uno de los cuatro
médicos le atienda. Finalmente, los clientes pagan sus facturas al contable y les dan el alta.
Todos los pacientes caminan a una velocidad constante de 4.5 kilómetros por hora. Hay una distancia de 5
metros desde la puerta tanto a la ventanilla de recepción como al contable, y 25 metros desde la sala de
espera hasta las salas. Se observa que los pacientes llegan cada 6.5 minutos. Cada paciente tarda entre 1 y 3
minutos en registrarse y entre 3 y 6 minutos en darles el alta. El tiempo de consulta varía entre 12 y 30
minutos, con un valor más frecuente de 18 minutos. A día de hoy, los médicos pueden atender a cualquier
paciente.
Sección 10.1: Usando una Única Operación para Modelizar Múltiples Recursos
La forma más simple de modelizar la clínica es la utilización de servidores para cada actividad.
Paso 1: Cree un nuevo modelo, como se muestra en la Figura 10.1.
Figura 10.1: Modelo de la Clínica de Urgencias

El modelo es como sigue:
 Una entidad, MODELENTITY, denominada Patients, una fuente, SOURCE, ScrPatients, una estación
de recepción, SERVER, SrvReceptionist, una estación de atención al paciente, SERVER, SrvMD, una
estación de pago, SERVER, SrvClerk, y un sumidero, SINK, SnkExit. Advierta que los nodos de
entrada y salida se han posicionado de forma que la presentación visual sea más atractiva.
 Conecte los objetos con caminos, PATHS. La distancia entre la fuente de pacientes, ScrPatients, a la
recepción, SrvrReceptionist, es 5 metros y las distancias desde y hasta las salas, SrvMD, es de 25
metros.

 Recuerde que los pacientes llegan siguiendo un modelo exponencial de media 6.5 minutos.
 La entidad, MODELENTITY, Patient, camina con una velocidad constante de 4.5 km por hora o 4500
metros por hora, velocidad que debe ser introducida en la propiedad Initial Desired Speed.
 La capacidad de los médicos, SrvMD, se debe inicializar como 4.
 La recepcionista tarda en registrar entre 1 y 3 minutos, mientras que el contable tarda entre 3 y 6
minutos. Cada médico tarda entre 13 y 30 minutos, con un valor más habitual de 18 minutos.
Pregunta 1: ¿Qué distribución se debe utilizar para el tiempo de proceso o de atención, Processing Time,
de los médicos, SrvMD?
Paso 2: Será beneficioso indicar visualmente cuándo un médico está ocupado y trabajando haciendo que el
icono correspondiente se vuelva de color verde. Añada un símbolo adicional haciendo clic en SrvMD y
luego en el botón Add Additional Symbol. Advierta que existen dos símbolos activos ahora (con etiquetas
0 y 1) como se muestra en la Figura 10.2. Asegúrese de que se selecciona el símbolo de código 1.45
Cambiando de
Color
Figura 10.2: Añadiendo y Quitando Símbolos, así como Editando Dibujos y Colores
Podríamos haber añadido símbolos adicionales para indicar el número de médicos que están trabajando.
Paso 3: Cuando todos los médicos, SrvMD, están ociosos, se debería ver el símbolo gris (código 0),
mientras que el símbolo verde corresponde a la situación en que alguno de los médicos está trabajando.
Por defecto, la expresión lógica que está programada en la sección Animation de algún servidor, SERVER,
en indicador de símbolo, Current Symbol Index, es (SrvMD.Capacity.Allocated > 0). Cuando
no se ha asignado ninguna capacidad, la expresión será evaluada como falsa y se mostrará el símbolo
correspondiente al valor 0. Si algo de capacidad se ha asignado, la expresión se evalúa como verdadera y
se mostrará el símbolo con indicador 1.
Paso 4: Guarde el modelo como MultipleResSingleServer y ejecútelo durante un período de 40 horas,

especificando la duración como se muestra en la Figura 10.3.
45
También puede cambiar el símbolo del dibujo además de cambiar el color o la textura. Use el botón Remove Symbol para eliminar
el símbolo selecionado y se reordenarán el resto de símbolos.
Recursos Múltiples que Fallan: Clínica de Cuidados Intensivos 85

Figura 10.3: Especificando que el Modelo se Ejecute durante 40 Horas
La Figura 10.4 muestra una situación en que los cuatro médicos están atendiendo a pacientes, lo que se
muestra durante la animación en la fila de contenidos en proceso, Processing.Contents, de la parte de
procesado de una estación, que se muestra por defecto, encima del icono.46
Fila de
Contenidos
en Proceso
Figura 10.4: La Fila de Procesamiento de un Servidor

Pregunta 2: ¿Cuál es el grado de ocupación media de los médicos?
Pregunta 3: ¿Cuál es el tiempo total que un paciente tiene que esperar para esperar a que un médico le
atienda, así como el número medio de pacientes en espera?
Pregunta 4: ¿Cuál es el tiempo de ciclo medio de los pacientes?
Pregunta 5: ¿Por qué sería más apropiado utilizar cinco repeticiones de 8 horas en vez de una seguida de
40 horas (es un tema tanto estadístico como computacional)?
Pregunta 6: ¿Hay alguna otra cosa sobre el modelo que le preocupa?
Sección 10.2: Fallos en los Servidores
A menudo, las operaciones (ya sean máquinas, gente u otros recursos) fallan (roturas, excepciones...), lo que
necesita ser incluido en el modelo. Estas situaciones pueden ser modelizadas utilizando la sección sobre la
lógica de fiabilidad, “Reliability Logic”, incluida en operaciones, SERVERS, estaciones de trabajo,
WORKSTATIONS, combinadores, COMBINERS, separadores, SEPARATORS, recursos, RESOURCES, y otros
operarios, WORKERS.
Como parte de su trabajo habitual, la recepcionista recibe y atiende llamadas de teléfono que requieren su
inmediata atención. De media, se recibe una llamada cada 30 minutos (Exponencial). Estas llamadas duran
entre 1 y 6 minutos, con una moda de 3 minutos.
46
Una operación tiene tres estaciones, STATIONS, (InputBuffer, Processing, y OutputBuffer), cada una con su cola asociada de
contenidos, Contents, en donde se almacenan las entidades que están en la estación.
Paso 1: Las opciones sobre cómo introducir fallos se encuentran en la propiedad “Reliability Logic” del
objeto SERVER. En SIMIO, se pretende que el concepto de fallo se use para cualquier tiempo de parada,
excepción, o interrupción no modelizada. Existen 4 tipos de fallos que se pueden especificar, dos de los
cuales se basan en sucesos y los otros en tiempo.
Paso 2: En el caso de las llamadas, es apropiado utilizar un fallo de los basados en el tiempo, “calendar time
based failure”. En tiempo entre fallos, Uptime Between Failures, incluya la expresión
Random.Exponencial(20) minutos y en el tiempo de reparación, Time to Repair, la expresión
Random.Pert(1,3,6 ) minutos como se aprecia en la Figura 10.5. Nota: la operación se parará de
inmediato cuando el fallo ocurre.
Figura 10.5: Especificando un Fallo Basado en el Tiempo

Paso 3: Cambie la animación para indicar que la recepcionista está atendiendo a una llamada telefónica.
Añada un símbolo adicional y elija el color rojo.
Paso 4: Es necesario modificar la propiedad Current Symbol Index e incluir el nuevo símbolo para que sea
usado cuando la operación entra en modo fallo. Cada uno de los objetos que puede incluir lógica sobre
fiabilidad tiene un elemento FAILURE, de nombre Failure. El elemento FAILURE tiene varias funciones
(véase la ayuda de SIMIO). Podemos usar la siguiente expresión que tomará el valor 1 (Verdadero,
“True”, rojo) cuando falla y 0 (Falso, “False”, Gris) en caso contrario.
SrvReceptionist.Failure.Active>0
Paso 5: Cambie el tiempo entre fallos y el tiempo de reparación SvrReceptionist para comprobar que el
modelo funciona como debe.
Paso 6: Guarde y ejecute el modelo.
Pregunta 7: Cuando se ejecuta el modelo, ¿cambian como deben de color las operaciones?
Paso 7: Suponga que también hay llamadas de teléfono que interrumpen la consulta de los médicos. Añada
entonces un tercer símbolo a usar con SrvMD, de forma que haya tres símbolos (0, 1, y 2).
Paso 8: Se necesita modificar la propiedad Current Symbol Index de SvrMD para usar el nuevo símbolo, 2,
cuando se para por la llamada. La siguiente expresión valdrá 0, 1 o 2 utilizando la función SI, If, dentro
del objeto MATH.
Math.If(SrvMD.Failure.Active, 2, (SrvMD.Capacity.Allocated >0))
Otra forma de modelizar la misma expresión es usar una nueva sentencia matemática como se muestra
más abajo. Si la operación no ha fallado, tomará el valor 0 o 1 como antes, y si falla, el valor 2 o 3. Si el
valor es mayor que el último indicador, se seleccionará el símbolo con el indicador más grande.
2*SrvMD.Failure.Active+ (SrvMD.Capacity.Allocated >0)

Incluye cualquiera de las dos expresiones en la propiedad Current Symbol Index de SrvMD.
Paso 9: Asuma que las llamadas de teléfono a los médico llegan cada 6 horas y su duración está entre 40 y
60 minutos, y lo típico es 55 minutos. Modifique la propiedad “Reliability Logic” de SrvMD.
Paso 10: Ejecute el modelo de simulación (puede que necesite cambiar el tiempo entre fallos para que
llegue una llamada y el icono cambie de color).
Pregunta 8: ¿Cuál es el grado de utilización media de los médicos ahora, así como el tiempo medio de
fallos?
Pregunta 9: ¿Cuál es el tiempo total en el sistema de un paciente?
Pregunta 10: ¿Observa algún problema con el modelo?
Paso 11: Debe darse cuenta que cuando hay una llamada, se interrumpe la capacidad de la operación,
de todos los médicos. Este tipo de fallo puede modelizar otro tipo de problema, como un fallo eléctrico.
Sin embargo, no es el tipo de fallo deseado en nuestro modelo. Si la capacidad fuera 1, en cambio, sí se
espera que falle toda la operación. La forma correcta de modelizar fallos individuales se incluye en el
Capítulo 11.
Sección 10.3: Haciendo Repeticiones: Parando la Ejecución de una Simulación
Es bastante probable que la clínica no funcione de forma continua. Es más habitual que estén abiertas
durante 8 horas (desde las 11am hasta las 7pm). Es fácil ejecutar la simulación durante exactamente 8 horas,
utilizando la sección “Run Setup” de la pestaña “Run”. Pero suponga que queremos tener las puertas abiertas
desde las 11am a las 7pm, pero que se atenderán a todos los pacientes que hayan entrado durante ese
período. Esta salvedad hace preguntarse dos cosas sobre el modelo. Primero, ¿cómo paramos la llegada de
clientes a las 7pm?; segundo, ¿cómo paramos la simulación cuando se va el último cliente?
Paso 1: Hay varias formas de parar la llegada de pacientes después de 8 horas. Por ejemplo, los podemos
mandar a un sumidero después de las 7pm. Otra forma es crear un controlador, MONITOR, que cambia el
ritmo de llegada. Quizá sea menos obvio el uso de una expresión condicionada en Entities Per Arrival
del objeto SrcPatients, TimeNow < 8; está expresión valdrá 1 si el paciente llega antes de las 8 horas
de simulación, pero 0 después, eliminando toda llegada posterior.
Paso 2: Sin embargo, la forma más directa de parar una llegada es usar las condiciones “Stopping
Conditions” de una fuente, SOURCE, que apagarán el suministro en función de una de las siguientes
condiciones: especificando un número máximo de llegadas o entradas47, un tiempo máximo, o la
ejecución de algún evento. En nuestro caso, podemos especificar un tiempo máximo de 8 horas.
Paso 3: Si ejecuta el modelo con el cambio anterior, verá que los pacientes dejan de llegar, pero que la
simulación continúa enseñando, por ejemplo, los fallos. Para parar la simulación después de la salida del
último paciente, es necesario utilizar una estadística de conteo, TALLY statistic (sección
“Definitions→Elements→Statistics). Incluya una nueva estadística de conteo StopReplication que
utilice la siguiente condición como propiedad de parada, Stopping Condition:
((Patients.NumberInSystem -1) == 0) && (TimeNow >= 8)
47
Advierta que es número de llegadas y no de entidades.
Esta expresión dice que se acabará la simulación si es el último paciente en la clínica y el tiempo es
superior a 8 horas (las unidades de tiempo de la simulación son siempre horas).
Paso 4: Haciendo doble clic en el disparador “Destroying Entity” del objeto SnkExit, se creará el proceso
SnkExit_DestroyingEntity. Este disparador se ejecutará justo antes de que se destruya una entidad en el
sumidero, SINK. En este proceso, añada una etapa Tally que referencia el nombre de la estadística de
conteo, Tally Statistic Name, StopReplication, y recopile el tiempo actual, TimeNow, como su valor,
Figura 10.6: Proceso de Destrucción de Entidades

Paso 5: Guarde el modelo y ejecútelo (manteniendo la duración en 40 horas).
Pregunta 11: ¿A qué hora se para la simulación?
Paso 6: Recuerde que si hace varias repeticiones, cada una de ellas se parará en un momento diferente. Las
estadísticas finales, output statistics, se usan para recopilar estadísticas cuando la repetición se acaba.
 El fallo de toda la capacidad de una operación en SIMIO es igual que en Arena/Siman. Mientras
que Arena/Siman incluye reglas, “rules”, además de liberar, “preempt”, para interrumpir un
proceso en ejecución, SIMIO permite al usuario crear sus propias reglas cuando ocurre el fallo,
como se ha visto en el Capítulo 9.
 Usar condiciones arbitrarias con las que terminar una repetición y asociarlas con una estadística
de conteo, TALLY statistic, es diferente de Arena/Siman, que sólo presenta una posible condición
de fin de la ejecución.

Capítulo 11
Modelizando Múltiples Recursos con Múltiples
Operaciones: la Clínica de Cuidados Intensivos bis
 Usando múltiples servidores, SERVERS, para modelizar múltiples recursos
 Usando la lógica de fiabilidad de un servidor, SERVER, para modelizar fallos o excepciones.
 Utilizando una línea de espera común para diferentes estaciones.
Sección 11.1: Evitando el Problema de Fallo Cuando se Usa un Único Servidor
En el Capítulo 10, si uno de los médicos recibía una llamada de emergencia, todos los médicos no trabajaban
dado que el fallo estaba asociado a la operación y no a los recursos. Para evitar esta situación, la clínica se
modelizará ahora utilizando cuatro operaciones diferentes y se asignarán los pacientes a cada una de ellas.
Paso 1: Modifique el modelo original de forma que incluya cuatro operaciones con las mismas propiedades
que la estación original SrvMD, salvo que cada una tendrá una capacidad de 1. Llame a cada estación
según el apellido del médico: SrvAllen, SrvBaker, SrvCharles, y SrvDuke (véase la Figura 11.1).
Figura 11.1: Modelización Utilizando Cuatro Operaciones

 Cambie la capacidad de SrvMD a 1 y llámelo SrvAllen. Asegúrese de que la lógica de fiabilidad,
“Reliability Logic” es la correcta.
 Copie y pegue la operación 3 veces de forma que se mantenga la información sobre fallos, símbolos
y tiempos de proceso, pero cambie sus nombres a SrvBaker, SrvCharles, y SrvDuke.
 Cambie la expresión que figura en la propiedad Current Symbol Index de cada una de las
operaciones para que se incluya el nombre de la operación, por ejemplo,
Math.If(SrvAllen.Failure.Active,2,(SrvAllen.Capacity.Allocated >0))
 Añada un nodo de transferencia, TRANSFERNODE, antes de las 4 operaciones y haga que los pacientes
se dirijan a este nodo utilizando un conector desde la recepción, SrvReceptionist, y conecte el nodo
con las cuatro operaciones, esta vez utilizando cintas transportadoras, CONVEYORS, (por razones que
luego veremos). Las cintas deben tener una capacidad infinita y una distancia, Logical Length, de 25
metros.

 Conecte los cuatro médicos con la salida, SINK, utilizando conectores entre los nodos de salida de
las operaciones y un camino, PATH, de 25 metros desde SrvDuke a SrvClerk.
Paso 2: Guarde el modelo y ejecútelo durante un período 40 horas sin una condición de parada, observando
lo que sucede.
Pregunta 1: ¿Qué sucede a los otros médicos ahora, si uno de ellos recibe una llamada de emergencia?
Pregunta 2: ¿Eligen los pacientes la fila más corta (por qué o por qué no)?
Sección 11.2: Dirigiendo los Pacientes hacia los Médicos
Queremos ahora que los pacientes se asignen al médico con un menor número de pacientes en espera.
Paso 1: Vaya a la pestaña “Definitions” y cree una lista, NODE LIST, con el nombre ListStaff, y que
contenga la fila de entrada (Input) de cada uno de los cuatro médicos (Figura 11.2). Esto nos permitirá
seleccionar la fila que es más corta.
Figura 11.2: Creando una Lista de los Médicos

Paso 2: En el nodo de transferencia que llega a las operaciones, cambie la propiedad de regla de salida,
Outbound Link Rule a camino más corto, “Shortest Path”, y la propiedad que indica el tipo de destino,
Entity Destination Type, a “Select From List”, y para la propiedad nombre, Node List Name, seleccione
la lista ListStaff que acaba de ser creada.
Paso 3: Fije la propiedad Selection Goal en el mínimo, Smallest Value, e incluya como Selection
Expression48 la siguiente, con la que se determina la suma del número que se está dirigiendo hacia la
operación y el número en espera, Contents de InputBuffer49, o siendo atendido en la estación
Processing50:
48
No confunda la propiedad Selection Expression con la de Selection Condition que se utiliza para incluir posibles nodos.
49
Los contenidos, Contents, de la estación de entrada, InputBuffer STATION, se usa para ubicar a las entidades que están
esperando a ser procesadas en la operación, SERVER.
50
Los contenidos, Contents, de la estación de procesamiento, Processing STATION, representan la ubicación de las entidades
que se encuentran siendo procesadas en la operación, SERVER.
Modelizando Múltiples Recursos con Múltiples Operaciones: la Clínica de Cuidados Intensivos bis 91
Candidate.Node.NumberRoutingIn +
Candidate.Server.InputBuffer.Contents.NumberWaiting +
Candidate.Server.Processing.Contents.NumberWaiting51
Esta expresión hará que las entidades elijan el médico en función del menor número en espera o en
proceso, o que están andando hacia la zona de espera.
Paso 4: Guarde el modelo y ejecútelo observando lo que sucede cuando llegan los pacientes.
Pregunta 3: ¿Seleccionan las entidades la fila más corta y qué sucede si un médico está atendiendo una
llamada?
Paso 5: Sin embargo, si un médico está atendiendo una llamada urgente, no se le deberían enviar pacientes.
Para realizar esta tarea, la propiedad Select Condition puede incluir sólo ciertos valores de una lista. La
expresión incluida en esta propiedad debe ser evaluada como verdadera antes de que el objeto nodo,
CANDIDATE NODE, sea considerado como adecuado. Cambiemos la propiedad de forma que se seleccione
sólo entre aquellos candidatos que no han fallado (con llamada).
Paso 6: Acuérdese que la función fallo activo, Failure.Active, tomará el valor falso si la operación
está activa, esto es, sin fallo. Si la operación no ha fallado, entonces es cuando hay que reconocerla como
candidata para recibir pacientes, lo que se realiza utilizando la siguiente expresión como se muestra en la
Figura 11.3.52
!Candidate.Server.Failure.Active
Figura 11.3: Especificando la Condición de Selección de Nodo para Excluir las Operaciones que no
están Activas
Paso 7: Guarde y ejecute el nuevo modelo, y observe qué sucede. Puede que sea necesario que reduzca el
tiempo entre llamadas (una cada minuto) para que vea cómo funciona la lógica de direccionamiento.
Pregunta 4: ¿Cuál es el grado de utilización general de los médicos?
Pregunta 5: ¿Cuál es el tiempo total que un paciente tiene que esperar a un médico, así como el número
medio en espera, para cada uno de los médicos?
51
El objeto candidato, CANDIDATE, se utiliza para especificar funciones y variables de estado. SIMIO reemplazará el objeto
CANDIDATE con otro objeto de la lista cuando se determine el mínimo valor. Si existe un empate entre nodos, se seleccionará en
función del orden en que se encuentran en la lista.
52
Los operadores ! o Not se utilizan para obtener el complementario de una variable (! Falso es lo mismo que verdadero).
Pregunta 6: ¿Cuál es el tiempo en el sistema de un paciente?
Pregunta 7: ¿Cuáles son algunos de los inconvenientes de este modelo?
Sección 11.3: Haciendo que Todos los Pacientes Esperen Juntos
Cada operación (médico) tiene su propia fila de espera en lugar de que exista una común, lo que suele ser
más habitual en este tipo de clínicas. Juntar estas filas en una sola plantea un problema de modelización que
se puede resolver de distintas formas (¿tiene alguna idea?).
Pregunta 8: ¿Cuándo se prefiere N operaciones con N filas en lugar de N operaciones con una fila?
Paso 1: Guarde el modelo en su forma actual. Modelizaremos una fila única haciendo que los pacientes
esperen en la fila de salida de la operación, SERVER, como se muestra en la Figura 11.4, hasta que uno de
los médicos finalice con un paciente y esté ocioso, y entonces le redirigiremos un paciente.
Utilizar
como Sala Conector
de Espera
Uso de cintas
transportadoras
Figura 11.4: Inclusión de una Sala de Espera

 Borre el conector que une SrvReceptionist y TranferNode.
 Incluya un nuevo servidor, SERVER, con el nombre SrvWaitingRoom, y que hará las veces de sala
de espera.
 Especifique que la sala tiene capacidad infinita inicial, valor “Infinity” en Initial Capacity, y un 0 de
Processing Time.
 Conecte SrvReceptionist a esta nueva sala con un camino de 5 metros.
 Conecte la salida de la sala SrvWaitingRoom a TransferNode con un conector, CONNECTOR53.
53
Recuerde que un conector, CONNECTOR, no ocupa espacio físico en el modelo, lo que hace que el nodo de transferencia y la sala de
espera ocupen el mismo lugar. Un buen enfoque en SIMIO es la utilización de nodos de transferencia, TRANSFERNODES, como
Paso 2: Cambie el nombre de las cintas transportadoras a ConvAllen, ConvBaker, ConvCharles, y
ConvDuke54.
Paso 3: Seleccione cada uno de las cuatro cintas simultáneamente (usando la tecla Ctrl) y fije las
propiedades comunes a todos los objetos seleccionados (Figura 11.5).
 Fije la velocidad deseada, Desired Speed, de cada una de las cintas en 4.5 km por hora (4500 m por
hora).
 Permita que sólo una persona pueda ser transportada a la vez, porque sólo puede haber un paciente
asignado a cada médico.
 Cambie la longitud de cada cinta y fíjela en 20 metros.
Figura 11.5: Cambiando Propiedades de Varias Cintas a la Vez

Paso 4: Guarde el modelo y ejecútelo, observando qué sucede. Sólo una persona se puede mover por una
cinta a la vez, pero todavía los pacientes se mueven y acumulan delante de cada médico.
Paso 5: Dado que el nodo de transferencia, TransferNode, y la fila de salida, “output buffer”, de la
operación SrvWaitingRoom se encuentran en exactamente la misma ubicación, mueva el nodo de
transferencia hasta situarlo justo encima del nodo de salida55.
Paso 6: En la mayoría de las salas de espera, la gente se suele colocar cerca de las paredes en lugar de en una
fila ordenada.
 Borre la fila con la que se visualiza la estación de salida de un objeto servidor, SERVER, que por
defecto es la línea verde que se muestra a la derecha del objeto.
 Seleccione la sala SrvWaitingRoom y añada de forma manual una fila para la visualización,
utilizando la sección, Symbols→Attached Animation, de los contenidos, Contents, de la estación
OutputBuffer, como se muestra en la Figura 11.6.
conexiones, de forma que si el modelo cambia, la lógica introducida no se pierde cuando se borran objetos (si hubiéramos borrado el
nodo de transferencia y conectado la sala de espera directamente con los médicos, toda la lógica de selección de médicos habría que
haberla desarrollado de nuevo).
54
Este paso ayudará a reducir los errors en los próximos pasos, haciendo que las cintas se asocien instintivamente con un médico en
particular.
55
Advierta que si lo selecciona, el diamante tiene ahora dos mitades, permitiendo así que pueda elegir tanto el nodo de transferencia
como la fila de salida.
Figura 11.6: Añadiendo una Fila para Animación
 Dibuje una fila con forma de U haciendo primero clic en el punto superior derecho y luego
dibujando hacia atrás, haciendo clic en cada una de las esquinas que se quieran dibujar (Figura
11.7)56.
Uso: Sala de
Espera TRANSFERNODE
encima de
OUTPUTBUFFER
Figura 11.7: Añadiendo una Fila para Animación con una Forma Diferente
Paso 7: Existen muchas formas de modelizar la situación de forma que los clientes esperen hasta que haya
un médico completamente desocupado. Una de las más sencillas es utilizar un disparador “Add-On
Process Trigger” para bloquear la cinta haciendo que su velocidad sea nula, y volviendo a cambiarla una
vez que el médico vuelva a estar disponible57.
Paso 8: Dado que las cintas sólo van a transportar a los pacientes de uno en uno, deberán pararse cuando el
paciente llegue al final58.
 Seleccione la cinta ConvAllen y elija en la ventana de propiedades los disparadores “Add-On

Process Triggers”.
 Para crear un disparador, haga doble clic en la etiqueta “Reached End”, lo que creará un nuevo
proceso, que llevará como nombre por defecto, ConvAllen_ReachedEnd, así como activará la
pestaña “Processes”.
 Asigne el valor de 0 a la variable de estado ConvAllen.DesiredSpeed, que es la velocidad

límite para esta cinta, utilizando una etapa Assign (Figura 11.8).
56
El primer punto de una fila representa la cabeza de la fila y es la razón por la que se dibuja hacia atrás, de forma que los pacientes
se situarán más cerca del nodo de salida.
57
Los dos tipos de camino, PATHS y TIMEPATHS, tienen un comportamiento similar en cuando a su velocidad, DesiredSpeed, pero esta
propiedad no bloquerá los caminos como sí lo hace con las cintas.
58
Al llegar al final, la lógica de transferencia hacia el nodo se ejecuta incluso si la cinta se ha parado y su última parte no ha llegado
al final del objeto.
Figura 11.8: Fijando la Velocidad de una Cinta en Cero
Paso 9: Repita el paso anterior para las otras tres cintas, asegurándose que la variable de estado
correspondiente a la velocidad deseada se fije en 0. Para ser más eficiente, utilice el desplegable (Figura
11.9) para crear un nuevo proceso sin cambiar de la pestaña activa a la pestaña Processes59. Cuando haya
creado los tres disparadores, copie la etapa Assign anterior en cada uno de los procesos nuevos,
asegurándose de cambiar el nombre del objeto CONVEYOR por el correcto.
Figura 11.9: Creando Nuevos Disparadores de Procesos

Paso 10: Guarde y ejecute la simulación, asegurándose que esta parte del modelo funciona.
Pregunta 9: ¿Qué ha observado y por qué ocurre?
Paso 11: Es necesario que las cintas vuelvan a funcionar una vez que los médicos acaban con un
paciente. Una vez que uno de ellos deja la sala del médico, la velocidad de la cinta tiene que volver a se
4.5 km por hora.
Para cada uno de los servidores, SERVERS, cree un disparador “Exited” que se dispara cuando sale una
unidad, para que asigne un nuevo valor a la velocidad de la cinta, como se muestra en la Figura 11.10.
Recuerde que SIMIO convierte todo a horas y metros de forma interna, por lo que se necesita
especificar la nueva velocidad como 4500.
Figura 11.10: Fijando la Velocidad de las Cintas en 4.5 Km por hora

Paso 12: Guarde y ejecute la simulación, asegurándose que esta parte del modelo funciona.
Pregunta 10: ¿Cuál es el grado de ocupación?
Pregunta 11: ¿Cuál es el tiempo total que un paciente tiene que esperar para que un médico le atienda, así
como el número medio de personas en espera tanto en la sala como delante de los médicos?
59
Podría haber creado un nuevo proceso mientras estaba en la pestaña Processes y después haberlo seleccionado del desplegable
correspondiente al disparador.
Pregunta 12: ¿Cuál es el tiempo total de un cliente en el sistema?
Pregunta 13: ¿Hay todavía algún problema con el modelo?

_
 La modelización es un proceso creativo. Se sorprenderá de cuántas veces su creatividad será

recompensada con un modelo claro y conciso. El uso de una operación para representar una fila
de pacientes ha funcionado correctamente, aunque probablemente no fuera el enfoque que se le
hubiera ocurrido.
 Modelizar una situación en la que “gente atiende a gente” puede ser muy atractivo, puesto que
todos los objetos tienen inteligencia y toman sus propias decisiones. Sólo con un enfoque
orientado a objetos se puede representar correctamente esta situación.
Capítulo 12
Variables, gráficos SMORE, Optimización: Inventarios y
Cadenas de Suministros
 Usando variables de estado discretas, temporizadores y estadísticas
 Gráficos SMORE, selección de subconjuntos de escenarios
 Ranking y selección, Optimización
Muchas empresas encuentran muchos desafíos a la hora de competir en los nuevos mercados globales.
Variaciones en la demanda, largos tiempos de respuesta y fluctuaciones en la cadena de aprovisionamiento
pueden resultar en excesivos niveles de producto terminado o en un pobre servicio al consumidor final.
Muchas compañías con tiempos de respuesta largos se ven forzados a implantar una política de fabricar para
almacenar (make-to-stock) de forma que sean capaces de responder a la demanda de los clientes de forma
rápida para mantener su cuota de mercado. Excesivos niveles de inventario llevan a costes elevados y alta
obsolescencia mientras que un nivel bajo puede ocasionar roturas de stock y bajos niveles de satisfacción en
los clientes. Así, el diseño y la optimización de la cadena de suministros se ha convertido en una prioridad
puesto que influye en la supervivencia de las compañías. El principal objetivo de cualquier cadena de
suministros es suministrar el producto cuando se requiere y con un precio que maximiza el beneficio. Para
que se consigan ambos objetivos, se necesita balancear el sistema con suficiente stock para satisfacer la
demanda, pero no demasiado como para afectar negativamente la rentabilidad.
Sección 12.1: Construyendo una Cadena de Suministros
La Figura 12.1 muestra una cadena muy simple de suministros de tres etapas en la que los clientes llegan a
una tienda (que bien pudieran ser varias) a comprar un producto. Las tiendas lanzan un pedido al centro de
distribución, en este caso coincide con el fabricante, que suministrará el pedido si lo tiene en stock. El centro
de distribución utiliza un modelo basado en el punto de pedido para lanzar pedidos al proveedor, el cual se
supone que tiene una fuente o almacén lleno. Se tarda entre 3 y 6 días en suministrar con camiones el
producto desde el proveedor hasta el fabricante.
Suministro
Perfecto Clientes
Pedido Pedido
de Materia
Prima
Fabricante
Proveedor Tienda
Centro de
Flujo de Distribución Flujo de
Producto Producto
Figura 12.1: Cadena Simple de Distribución de Tres Etapas

El objetivo consiste en monitorizar el inventario medio existente en el centro de distribución así como el
nivel de servicio a lo largo de un año. Así, los clientes no forman parte del modelo, ya que el fabricante está
interesado en determinar su punto de pedido así como la cantidad a pedir. La tienda pide diariamente al
centro de distribución, que utiliza un modelo de revisión periódica (s,S). En este modelo, el nivel de stock se
revisa cada cierto tiempo, denominado intervalo, que es constante. La cantidad s es el punto de pedido, o el
valor por debajo del cual se lanza un pedido. La cantidad S es la cantidad deseada una vez que el pedido
llega.
Paso 1: Cree un nuevo modelo con dos sistemas separados, como se muestra en la Figura 12.2.
 El primer sistema se usará para modelizar los pedidos que se hacen desde la tienda y que deben ser
procesados por el fabricante. Cree una fuente, SOURCE, de nombre SrcOrders, una operación,
SERVER, de nombre SrvOrderProcessing y un sumidero, SINK, de nombre SnkOrderExit. Incluya
también una entidad, MODELENTITY, que se llame Orders, y asegúrese de que son creadas por la
fuente SrcOrders. Use conectores, CONNECTORS, para unir todos los objetos, de forma que se
modelicen las transacciones EDI entre las tiendas y el fabricante.
 El segundo sistema modelizará el flujo de productos desde el principio de la cadena hasta el final de
forma que se reponga el inventario en las operaciones correspondientes. Incluya dos servidores,
SERVERS, de nombre SrvSupplier y SrvDC, y un sumidero, SINK, de nombre SnkStore. Conecte
SrvSupplier y SrvDC con un camino TIME PATH en el que se emplea un tiempo entre 1 y 2 días,
siguiendo un modelo uniforme. Use un conector, CONNECTOR, para unir SrvDC y SnkStore, dado
que el modelo se centra en el centro de distribución.
Figura 12.2: Modelo en SIMIO del Proceso de Reaprovisionamiento

Paso 2: Dado que no vamos a modelizar cada unidad del sistema como una entidad distinta, añada una
variable de estado discreta, DISCRETE STATE, de nombre OrderAmt para la entidad, MODELENTITY 60,
para representar el tamaño del pedido (order amount).
Paso 3: Para el proceso de pedidos, incluya la siguiente información:

 Cambie SrcOrders para que llegue un pedido diario.
 La cantidad en cada pedido se comporta según un modelo Poisson con una media de 20. Usando la
propiedad State Assignments→Before Exiting, fije la variable ModelEntity.OrderAmt en
Random.Poisson(20).
Figura 12.3: Especificando la Cantidad en el Pedido

Paso 4: En Definitions→Properties, incluya tres propiedades del tipo Expression Standard Properties de
nombres InitialInventory (inventario inicial), ReorderPoint (punto de pedido) y OrderUptoQty
(inventario máximo deseado). Todas ellas deben ser incluidas en la categoría “Inventory”. 61
60
Seleccione MODELENTITY en el panel [Navigation] y vaya a la sección Definitions→States para añadir la variable de estado.
61
La primera vez hay que escribir el nombre de la categoría, pero luego ya se puede seleccionar del desplegable correspondiente.
Variables, gráficos SMORE, Optimización: Inventarios y Cadenas de Suministros 99

Tabla 12.1: Los Valores por Defecto de las Tres Propiedades
Valor por Tipo de
Propiedad Categoría Descripción
Defecto Unidad
InitialInventory El nivel inicial al comienzo de la
700 Inventory Unspecified
simulación.
ReorderPoint Valor por debajo del cual se lanza un
pedido.
OrderUptoQty El nivel máximo de inventario cuando
llega un pedido.
Pregunta 1: ¿Qué ventajas tiene utilizar propiedades y fijar su valor en este modelo?
Paso 5: En el modelo, incluya una variable de estado discreta, DISCRETE STATE, de nombre Inventory que
ha de representar el nivel actual de stock de un producto en el fabricante, y otra con nombre WIP que va
a representar la cantidad total que el fabricante va a pedir al proveedor. La propiedad Initial State Value
debe fijarse en 0 tanto para Inventory como para WIP.
Paso 6: Incluya varios elementos, ELEMENTS, como se muestra en la Figura 12.4.

 Incluya una estadística de observación, TALLY STATISTIC, de nombre TallySL para monitorizar el
nivel de servicio (Service Level).
 Incluya una estadística de estado, STATESTATISTIC, de nombre StateStatInv, para monitorizar el

nivel de inventario. Especifique en la propiedad State Variable Name la variable Inventory.
 Incluya un temporizador, TIMER, de nombre TimerReview, para modelizar el intervalo o período de

revisión. En la actualidad el centro de distribución revisa el nivel de inventario cada 5 días.
Figura 12.4: Preparando Estadísticas y el Temporizador para la Revisión Periódica

Paso 7: Cambie el tiempo de proceso de SrvOrderProcessing de forma que se tarde medio día en
recepcionar los pedidos antes de intentar satisfacerlos con el inventario disponible.
Paso 8: El proveedor tarda entre 10 y 30 minutos, con una moda de 20 minutos en procesar cada producto,
por lo que la propiedad Processing Time debe tomar el valor:
Random.Triangular(10,20,30)*ModelEntity.OrderAmt.
Paso 9: Cuando un producto llega al fabricante DC, el lote entero debe ser empaquetado antes de que esté
disponible para ser mandado a las tiendas. La propiedad Processing Time del fabricante DC debe incluir
la expresión Random.Pert(1,2,5)*ModelEntity.OrderAmt.
Paso 10: Guarde el modelo y ejecútelo durante un período de 26 semanas.
Pregunta 2: ¿Cuántos pedidos se producen en ese período de tiempo y cuál es su tiempo medio en el
sistema?

Sección 12.2: Procesando Pedidos en la Cadena de Suministros
Paso 1: Recuerde que la propiedad de nivel de inventario inicial (InitialInventory) fue especificada para
permitir que se puedan cambiar las condiciones de inicio. Dado que los valores por defecto de las
variables de estado no pueden ser propiedades de referencia, la variable de estado Inventory necesita ser
inicializada al comenzar la simulación mediante la ejecución del proceso “OnInitialized”. Incluya este
proceso utilizando el menú desplegable Processes→Select Process→OnInitialized. Incluya una etapa
Assign con el nuevo valor InitialInventory, como se muestra en la Figura 12.5.
Figura 12.5: Asignado el Valor Inicial al Nivel de Inventario

Paso 2: Cuando llegan los pedidos, Orders, al fabricante, tienen que ser atendidos en función de la posición
del inventario62. Incluya un disparador “Processed” en SrvOrderProcessing para actualizar la posición
de inventario así como el nivel de servicio.
 Incluya una etapa Decide que comprueba si la cantidad que lleva el pedido es mayor que cero,
antes de continuar (Figura 12.7).
 Añada una etapa Tally que actualizará TallySL con el valor igual a
Math.Min(1,Inventory/ModelEntity.OrderAmt)63.
 Incluya una etapa Assign que actualizará Inventory al restarle la cantidad del pedido actual,
OrderAmt. Sin embargo, si Inventory es menor que la cantidad, la resta dará un valor negativo;
como no se permiten roturas de stock, se ha de incluir la expresión (Math.Max(0,Inventory-
ModerEntity.OrderAmt) como se muestra en la Figura 12.7.
Figura 12.6: Proceso para Cumplir con los Pedidos de las Tiendas
62
Se define como posición de inventario el nivel de inventario en stock más el nivel de inventario pedido pero no recibido.
63
Algunos podrán argumentar que este cálculo del nivel de servicio es de hecho un ritmo de llenado, pues si el inventario es mayor
que la cantidad del pedido, el 100% de la demanda se ha cubierto.

Figura 12.7: Propiedades de Todas las Etapas
Paso 3: Para monitorizar la información mientras se ejecuta la simulación, incluya 6 etiquetas de estado,
status labels (utilizando la pestaña “Animation”, como se muestra en la Figura 12.8), para presentar el
valor actual y el valor medio del inventario así como el nivel de servicio. La primera columna de
etiquetas incluye las descripciones mientras que la segunda columna usa las expresiones Inventory,
StateStatInv.Average, y TallySL.Average.
Figura 12.8: Etiquetas de Estado que Muestran el Nivel Actual de Inventario, el Nivel Medio y el Nivel
de Servicio
Paso 4: Guarde el modelo y ejecútelo (puede que necesite ajustar el factor de velocidad a 100 o simular sin
animación).
Pregunta 3: ¿Cuál es el nivel de inventario actual?
Pregunta 4: ¿Cuál es el nivel medio de inventario y el nivel de servicio?
Sección 12.3: Creando la Pieza de Reposición de la Cadena de Suministros
El modelo incluido en la sección previa era capaz de atender los pedidos de las tiendas, pero una vez que se
acababa el stock, no existía reposición desde los proveedores. El nivel de servicio era por tanto bajo. El
temporizador tiene que ser modelizado como para lanzar un pedido de reposición cada cinco días si el nivel
de inventario está por debajo del punto de pedido; ha de lanzar entonces un pedido al proveedor en función
del nivel máximo y del nivel actual de inventario, así como de la cantidad de los pedidos ya lanzados (WIP).
Recuerde que la posición de inventario se define como el inventario en curso más el número pedido pero no
recibido.
Paso 1: Fije el período de revisión. Cree un proceso que responda al temporizador TimerReview. Utilizando
la pestaña “Processes”, cree un nuevo proceso de nombre InventoryReview. Fije la propiedad
Triggering Event para que responda al evento TimerReview.Event, lo que hace que el proceso se
ejecute siempre que se dispara el evento del temporizador (Figura 12.9).

Figura 12.9: Proceso de Revisión y Pedido
 Incluya una etapa Decide en la que se realice una comprobación basada en una condición,
“ConditionBased”, para ver si el nivel actual de inventario está por debajo del punto de pedido
(Inventory < ReorderPoint ).
 Si se necesita un nuevo pedido, utilice una etapa Create64 para crear un nuevo objeto Order como
se muestra en la Figura 12.10.
Figura 12.10: Creando un Nuevo Pedido para los Proveedores

 Para cada Order, use una etapa Assign que calcule la cantidad a pedir e incremente el valor WIP
en función de esa cantidad.
Tabla 12.2: Determinando la Cantidad a Pedir y Actualizando la Variable WIP
Variable de Estado Nuevo Valor
ModelEntity.OrderAmt Math.Max(0, OrderUpToQty – Inventory – WIP)
WIP WIP + ModelEntity.OrderAmt
 Cuando el pedido se ha realizado, el objeto Order tiene que ser mandado al proveedor utilizando
una etapa Transfer de forma que se mueva desde una fuente universal, “FreeSpace”, al nodo
Input de SrvSupplier.
Figura 12.11: Mandando un Pedido al Proveedor

Paso 2: Cuando los productos lleguen al fabricante y hayan sido empaquetados, se necesita incrementar el
valor de la variable Inventory y disminuir el valor de WIP en la cantidad recibida. Incluya un
disparador de procesos en SrvDC en el momento en que se acaba de empaquetar, “Processed”. Incluya
una etapa Assign que actualice los valores según la Tabla 12.3.
Tabla 12.3: Actualizando el Inventario Cuando se Recibe un Pedido de Reposición

64
La etapa Create puede crear nuevos objetos o copias de los objetos asociados así como de los objetos padre.

Inventory Inventory + ModelEntity.OrderAmt
WIP WIP - ModelEntity.OrderAmt
Paso 3: Guarde el modelo y ejecútelo (puede que necesite ajustar el factor de velocidad a 100 o simular sin
animación).
Pregunta 6: ¿Cuál es el nivel medio de inventario y el nivel de servicio?
Pregunta 7: ¿Es éste un sistema adecuado?
Sección 12.4: Usando un Experimento para Determinar los Mejores Valores
La simulación se utiliza a menudo para mejorar el rendimiento de un sistema. ¿Se puede encontrar un valor
de las variables máximo inventario deseado y punto de pedido que mejore el rendimiento del sistema?
¿Puede SIMIO ayudarnos a resolver este tipo de pregunta? ¿Puede SIMIO ayudarnos en la búsqueda de un
sistema mejor? La respuesta es afirmativa.
Paso 1: A partir de la sección Project Home→Create, incluya un nuevo experimento, “Experiment”, de

nombre FirstExperiment, lo que abrirá una nueva ventana en la que se creará automáticamente un
primer escenario, que es el modelo base utilizado hasta ahora, como se muestra en la Figura 12.12.
SIMIO automáticamente ha añadido también las tres propiedades como variables de control. 65
Paso 2: Incluya 8 escenarios más haciendo clic en la pequeña caja que se encuentra en la última fila de la
tabla. Esta acción copiará todos los parámetros del escenario base. Entonces, cambie el punto de pedido
y el máximo nivel permitido de forma que complete un diseño factorial utilizando tres valores para el
punto de pedido (200, 300, y 400) y otros tres para el máximo nivel (600, 700, 800) como se muestra en
la Figura 12.12.
Haga clic en la caja para crear

una copia del modelo base
Figura 12.12: Primer Experimento con Diferentes Valores de Punto de Pedido y Máximo Nivel de
Inventario
Paso 3: Utilizando el botón Design→Experiment→Add Response, incluya tres nuevas variables de respuesta
que serán utilizadas (Figura 12.12) para seleccionar el mejor escenario en función de unos parámetros
dados (Tabla 12.4). Las dos primeras variables de respuesta son muy lógicas. En este modelo, parece que
ambas variables entran en conflicto: si el nivel de stock baja, también lo hace el nivel de servicio. La
65
Se pueden definer otras variables de control adicionales.
tercera columna convierte un problema multi-objetivo en uno con un solo objetivo. Si el nivel de
servicio sube y el inventario baja, la respuesta también baja. Los límites inferior y superior se utilizarán
para advertir que los valores están fuera de los límites estipulados66. En este caso, deseamos tener un
nivel de servicio superior al 90%.
Tabla 12.4: Respuestas del Experimento

Nombre Expresión Objetivo Límite Inferior
Avg Inventory StateStatInv.Average Minimizar
Service Level TallySl.Average Maximizar 0.90
Inv/SL StateStatInv.Average/TallySL.Average Minimizar
Paso 4: La Figura 12.13 muestra los parámetros básicos del experimento, pudiéndose determinar el período
de calentamiento, warm up period, y el número de repeticiones por defecto67. En los gráficos SMORE y
la optimización, se mostrarán también el intervalo de confianza de la media así como los percentiles.
También tendrá que identificar cuál es la variable principal que servirá de base para los procedimiento de
ranking y selección así como para Optquest™ (siguientes secciones).
Figura 12.13: Fijando los Parámetros del Experimento

Paso 5: Guarde el modelo y ejecute el experimento.
Pregunta 8: Según los valores obtenidos, ¿qué punto de pedido y qué máximo nivel parece que son los
mejores?
Pregunta 9: ¿Cómo tomó la decisión?
Sección 12.5: Usando Gráficos SMORE para Determinar los Mejores Valores
En la sección anterior, simplemente utilizamos la media de las 10 repeticiones para tomar la decisión. La
dificultad estriba en que la variabilidad de un sistema no está incluida cuando se elige el mejor escenario.
Las gráficos de medida del riesgo y el error de SIMIO, SIMIO Measure of Risk & Error (SMORE), ofrecen
la posibilidad de ver la variabilidad así como los intervalos de confianza. Muestran los principales
percentiles (la mediana o el percentil del 50%, así como los percentiles mayor y menor elegidos) y la media,
junto con su intervalo de confianza.
66
Los valores que no cumplen con los límites se muestran en color rojo.
67
El valor por defecto son 10 repeticiones, aunque realizar más hará que la confianza en los resultados aumente.

Paso 1: Seleccione la pestaña “Response Chart” para ver los gráficos SMORE del último experimento
ejecutado. Se mostrará por defecto la variable que haya sido creada en primer lugar, pero las otras
variables se pueden seleccionar del desplegable (Figura 12.14). Rápidamente podemos ver que el
Escenario 6 es el mejor en función de la variable inventario medio. El Escenario 3 parece que es el
segundo mejor, aunque su variabilidad hace que sus resultados se solapen con los del Escenario 4. Sin
embargo, si se muestran y analizan los resultados correspondientes al nivel de servicio, sólo los
Escenarios 3, 7, 8, y 9 cumplen con los requisitos impuesto del 90% y no se puede elegir
estadísticamente el mejor (puede que el Escenario 7). Si se consideran las dos variable de forma
conjunta, el Escenario 3 aparece como la mejor opción.
Figura 12.14: Gráficos SMORE del Nivel de Inventario Medio y del Nivel de Servicio Medio
Paso 2: Mirando a la variable principal, inventario/servicio, de la Gráfica SMORE (Figura 12.15), el
Escenario3 parece que es el mejor. Su gráfica, sin embargo, se solapa mínimamente con la del Escenario
9.
Figura 12.15: Gráficos SMORE de la Variable Combinada Inventario/Nivel de Servicio

Paso 3: Haciendo clic en la opción de selección de un subconjunto de escenarios, “Subset Selection”, en la
sección “Analysis” dentro de la pestaña “Design”, puede ver las opciones seleccionadas por algoritmos
internos de SIMIO. Los escenarios se dividen entonces entre los incluidos en el mejor grupo posible,
“best possible group”, así como en el grupo de rechazo, “rejects group” (Figura 12.16).

Figura 12.16: Usando Selección de Subconjuntos
Advierta que se han seleccionado dos escenarios en función de la tercera variable de respuesta, Inv/SL.
Es posible que, aunque no se pueda demostrar estadísticamente cuál es el mejor de los dos, sí se pueda
demostrar que hay diferencia significativa entre el mejor subconjunto y el subconjunto de rechazo (que
se muestra en los gráficos con colores apagados).
Pregunta 10: ¿Cuál es el escenario que debe ser estadísticamente seleccionado como el mejor de las tres
respuestas?
Sección 12.6: Usando Procedimientos de Ranking y Selección para Determinar el Mejor

Escenario
El modelo actual es bastante sencillo (compuesto sólo por dos variables y el modelo) y 10 repeticiones
parecen suficientes para elegir la mejor opción. Sin embargo, para utilizar los Gráficos SMORE se requiere
un juicio y una identificación. El procedimiento de ranking y selección le permite seleccionar cuál es el
mejor escenario. Una de las ventajas de SIMIO es que tiene incorporado el novedoso método de ranking y
selección basado en las investigaciones de Kim y Nelson (denominado “KN”)68.
Paso 1: Guarde el modelo y presione el botón Reset para borrar los resultados.
Paso 2: Elija de la sección Design→Add-Ins la opción “Select Best Scenario using KN”, lo que añadirá el
algoritmo KN al experimento (
Paso 3: Figura 12.17).
Paso 4: Fije la propiedad de zona de indiferencia, Indifference Zone, en 5, lo que indica que una solución
puede considerarse como mejor que otra sólo si las soluciones difieren en más de 5 unidades. Dado que
el método de ranking y selección cambiará el número de repeticiones, la propiedad Replication Limit
especifica el número máximo de repeticiones a realizar.
68
S. Kim and B. L. Nelson, "A Fully Sequential Procedure for Indifference-Zone Selection in Simulation," ACM Transactions on
Modeling and Computer Simulation 11 (2001), 251-273.

Figura 12.17: Fijando los Parámetros KN
Paso 5: Fije el número de repeticiones mínimo, “Required” en la categoría Replications, en 1 y asegúrese de
que todos los escenarios están seleccionados (en la columna izquierda).
Paso 6: Vuelva a ejecutar el experimento y advierta que el número mínimo de repeticiones se ha elevado a
10. El algoritmo KN requiere que al menos se realicen 10 repeticiones de forma que se detecte de forma
fiable diferencias entre escenarios.
Pregunta 11: Basándose en las diferencias apreciadas en la columna Inv/SL, ¿piensa que es necesario
realizar más repeticiones para encontrar diferencias mayores de 5 unidades?
Paso 7: El algoritmo KN ha seleccionado el Escenario3 como el mejor (es el único seleccionado), como se
muestra en la Figura 12.18. En el caso de modelos más complejos, se necesitarán más de 10 repeticiones.
Figura 12.18: Resultados de Ejecutar KN

Paso 8: Verifique que el Scenario3 ha sido el seleccionado y examine su gráfico SMORE en “Response
Chart”.
Pregunta 12: ¿Cuál es el intervalo de confianza del 95% en la media?
Sección 12.7: Usando OptQuest™ para Optimizar Parámetros
El algoritmo KN que se ha usado en la sección previa ha ayudado a determinar el escenario óptimo a partir
de un conjunto predeterminado por el usuario. SIMIO dispone de una herramienta adicional, denominada
OptQuest™, que puede realizar optimización tradicional mediante la prueba de otros escenarios no
especificados. Permite además añadir restricciones tanto en las variables de decisión como en las de
respuesta.69
69
OptQuest es una herramienta que debe ser adquirida por separado.
Paso 1: A partir de la sección Project Home→Create, incluya un nuevo experimento, “Experiment”, de
nombre OptQuestExperiment, lo que abrirá una nueva ventana y creará el primer escenario.
Paso 2: Use el botón “Clear” para desactivar el procedimiento de selección de escenarios anteriormente
utilizado y seleccione “OptQuest for SIMIO”.
Paso 3: Añada las tres variables de salida utilizadas con anterioridad (Tabla 12.4).
Paso 4: Ya que el optimizador probará con valores distintos de las variables de control o decisión, hemos de
definir su dominio o rango factible. Seleccione los rangos apropiados así como sus incrementos para
favorecer la convergencia así como la calidad de la solución. Seleccione cada una de las variables de
control y fije sus valores según la Figura 12.19. Como puede apreciar, el nivel de inventario inicial no
está incluido en la optimización. Un incremento, increment, de 25 se ha elegido para las otras dos
variables para que el algoritmo seleccione valores en incrementos de 25.70
Figura 12.19: Fijando los Límites Superior e Inferior de las Variables de Decisión
Paso 5: Elija en la sección Design→Add-Ins “OptQuest for SIMIO”. Añadirá una sección de preparación en
las propiedades del experimento (Figura 12.20). El algoritmo utiliza un nivel de confianza para discernir
entre escenarios. El porcentaje de error relativo se expresa como un error de la media.
Figura 12.20: Parámetros de OptQuest

Paso 6: Guarde y ejecute el algoritmo de optimización. Vea cómo prueba valores distintos.
Paso 7: Ordene los escenarios de forma ascendente según la columna Inv/SL de forma que se vean los que
presentan un valor menor.
70
Puede que se consigan mejores soluciones con una mayor resolución (incrementos más pequeños). Sin embargo, esto puede afectar
la calidad de la solución. Si la resolución es menor, puede encontrar una primera buena solución rápidamente Una segunda
optimización alrededor del primer valor encontrado puede ayudar a encontrar una mejor solución.

Pregunta 13: ¿Cuál puede ser el mejor punto de pedido y el máximo nivel deseado si se considera no sólo
Inv/SL sino también el nivel de servicio?
Paso 8: Dado que OptQuest sólo ha usado 5 repeticiones, es posible que la variabilidad sea un problema.
Guarde los mejores 5 escenarios y borre el resto. Desactive OptQuest y seleccione el algoritmo para
seleccionar el mejor escenario. Asegúrese de que la variable de respuesta principal es Inv/SL. Utilice una
zona de indiferencia de 1. Ejecute el algoritmo KN.
Pregunta 14: ¿Qué mejores valores ha obtenido para el punto de pedido y el nivel máximo?
Pregunta 15: ¿Qué escenario o alternativa elige si quiere que el nivel de servicio sea por lo menos del
90%?
Paso 9: Para visualizar cuál es mejor que los otros, examine el gráfico de resultados con los cinco escenarios
(Figura 12.21). Tiene que seleccionarlos para verlos en el gráfico.
Figura 12.21: Comparando los Mejores Cinco Escenarios
Sección 12.8: Más Sobre OptQuest
Una debilidad de la selección KN es que no considera restricciones ni en las variables de control ni en las de
salida. Aunque OptQuest sólo puede optimizar un único objetivo (como KN), tiene la capacidad de incluir
restricciones en sus valores. Existen dos clases de restricciones en OptQuest para SIMIO: restricciones en las
variables de control y restricciones en las variables de salida.
Paso 1: Consideremos para empezar un problema de optimización algo distinto, en el que deseamos
minimizar el nivel de stock siempre y cuando se mantenga el nivel de servicio por encima del 90%.
Podemos escribir este problema de forma más formal como:
Minimizar: AvgInventory
Sujeto a: Service Level >= 0.90

200 <= ReorderPoint <= 500
500 <= Order UpToQty <= 1200

Paso 2: De las tres restricciones, las dos últimas son simplemente restricciones en los valores posibles de las
variables de entrada. La primera restricción sí que afecta a una variable de salida como es el nivel de
servicio.
Paso 3: Cree un nuevo experimento, de nombre OptQuestExperiment2.
Paso 4: Añada como variables de respuesta el nivel de servicio y el inventario medio. Fije los límites para el
punto de pedido y el nivel máximo. Añada un valor mínimo exigido de 95 para el nivel de servicio. Elija
minimizar el nivel medio de inventario.
Paso 5: Guarde y ejecute el algoritmo de optimización.
Paso 6: Ordene los escenarios de menor a mayor según la columna que incluye el inventario medio, de
forma que se puedan ver los escenarios con los mejores valores.
Pregunta 16: ¿Cuál parece ser el mejor valor para el punto de pedido y el inventario máximo si se
considera no sólo el nivel medio de inventario sino también el nivel de servicio?
Paso 7: Es instructivo examinar el gráfico de resultados (Figura 12.22) para ver cómo ha ido mejorando el
proceso de optimización.
Figura 12.22: Gráfico de Respuesta del Optimizador

Paso 8: Las restricciones pueden depender de valores de las variables de entrada. De hecho, es común incluir
restricciones de este tipo. Por ejemplo, y aunque pueda carecer de sentido para este modelo, se puede
plantear la restricción (ReorderPoint + 3*OrderUpToQty >=1000) como se aprecia en la
Figura 12.23.
Figura 12.23: Ejemplo de Restricción en Función de las Variables de Entrada
Esta restricción sólo ha sido un ejemplo ilustrativo, y no se pretendía que tuviera sentido.

 Este modelo sólo consideraba una posición de inventario en el fabricante. ¿Qué sucede si tiene
más de un centro de distribución, proveedor y/o tiendas? En un capítulo futuro, se creará un
objeto inventario que puede ser utilizado muchas veces.
 El uso de la selección de subconjuntos permite encontrar varias soluciones.
 Para un número grande de variables de control y de escenarios, el algoritmo KN de ranking y
selección facilita la elección estadística del mejor escenario.
 OptQuest es un buen optimizador si se dispone de tiempo suficiente. OptQuest también estaba
incluido en Arena; sin embargo, los gráficos SMORE, la selección de subconjuntos, y el
algoritmo KN ofrecen una verdadera ventaja.

Capítulo 13
Usando el Objeto Recurso: Clínica Veterinaria
 Usando el objeto recurso, RESOURCE, muy versátil para modelizar múltiples recursos.
 Usando las etapas Seize y Release para apresar y liberar recursos de una lista.
 Apresando recursos en función de las características de un paciente.
Sección 13.1: La Clínica Veterinaria
Una clínica veterinaria atiende a distintos tipos de animales. Como en el caso de la Clínica de Urgencias,
esta clínica intenta dar buen servicio utilizando los recursos de forma eficiente. Aunque la estructura de la
clínica veterinaria es similar a la de la clínica de urgencias, nos centraremos en las actividades que realizan
los veterinarios. Son veterinarios de nombre de pila Billy, Jim, Maisy, y Ellie. Esta clínica proporciona un
servicio más complicado que requiere de una forma de modelizar distinta a la incluida en el caso de la clínica
de urgencias.
Hay veces en las que se necesita disponer de distintos recursos, un veterinario y una máquina de rayos X,
antes de atender al paciente. También hay ciertas restricciones como que Jim es el único veterinario que
puede atender a las iguanas. El objeto SERVER no puede modelizar estos casos de forma fácil. Por ejemplo,
puede ser que sean necesarios tanto el veterinario como la enfermera para preparar un servicio, mientras que
la enfermera se basta por sí sola para acabar el servicio.
Sección 13.2: Utilizando el Objeto Recurso
El objeto recurso, RESOURCE, es un objeto fijo con capacidad (como un TRANSFERNODE o un SOURCE, que no
se mueven por la red del modelo), y que puede ser apresado o liberado por otro. Es un objeto genérico que
puede ser usado para restringir el flujo. Los RESOURCES tienen también posibilidad de incluir información
sobre su fiabilidad así como la habilidad para ordenar estáticamente y dinámicamente las entidades que los
solicitan (por ejemplo, elegir a los pacientes críticos primero) y también son capaces de rehusar una petición
y mantenerse desocupado.
Paso 1: Cree un nuevo modelo fijo (pestaña “Project Home”) dentro del mismo proyecto de un capítulo
anterior o puede crear un nuevo modelo. Puede disponer de distintos modelos en el mimo proyecto, pero
sólo uno se podrá ejecutar a la vez, a no ser que se utilice uno dentro de otro.
Paso 2: Añada una fuente, SOURCE, de nombre SrcPatients, un servidor, SERVER, de nombre SrvVetClinic,
y un sumidero, SINK, de nombre SnkExit. Añada una entidad, MODELENTITY, de nombre Patients.
Conecte los objetos con caminos de longitud 30 metros71.
 Los pacientes llegan según un modelo exponencial con un tiempo entre llegadas de 6.5 minutos.
 Cada paciente tarda en ser atendido por un veterinario entre 10 y 30 minutos, con un valor más
habitual de 15 minutos.
Si selecciona el nodo de salida de la fuente SOURCE mientras que aprieta las teclas Shift y Ctrl, SIMIO le dejará dibujar uniones,
71
LINKS, sin que seleccione el objeto en la Standard Library. Una vez que los caminos, PATHS, han sido dibujados, seleccione
ambos y cambie la propiedad Drawn to Scale a “False” y la propiedad Logical Length a 30 metros.
Usando el Objeto Recurso: Clínica Veterinaria 113

Paso 3: De la sección Standard Library, añada un nuevo RESOURCE72 de nombre Billy.
 Dado que los RESOURCES tiene la misma lógica de fiabilidad que los SERVERS, fije el mismo patrón
de llamadas de emergencias. Especifique el tiempo entre fallos, Uptime Between Failures, como una
distribución exponencial de media 6 horas y la expresión del tiempo de reparación, time to repair,
igual a Random.Pert(40,55,60) minutos, como se muestra en la Figura 13.1.
Figura 13.1: Lógica de Fiabilidad para Recibir Llamadas de Emergencia por un Veterinario
 Como en casos anteriores, añada dos símbolos adicionales. Coloree el iris del símbolo número 1 en
verde, para mostrar cuándo está ocupado, y el número 2 en rojo, para mostrar cuándo está en fallo.
El símbolo 0 se mantendrá de color azul, lo que indicará que está ocioso.
 En la sección “Animation”, dentro de la ventana de propiedades, cambie Current Symbol Index para
que refleje el estado del recurso, según la expresión:
Math.If(Billy.Failure.Active,2,(Billy.Capacity.Allocated > 0))
Paso 4: Copie el recurso Billy tres veces, con nombres Ellie, Jim, y Maisey respectivamente, para incluir al
resto de los veterinarios. Necesitará modificar Current Symbol Index para incluir el objeto RESOURCE
correcto, así como su estado, como se muestra en la Figura 13.2.
Color del iris en

recursos
Figura 13.2: Modelo de la Clínica Veterinaria Utilizando Cuatro Recursos

Paso 5: Cambie la capacidad de SrvVetClinic a Infinity de forma que su capacidad no restrinja el sistema,
ya que el objetivo del modelo es que sean los recursos los que lo hagan.
Paso 6: En este punto, podemos apresar un RESOURCE individual, pero nuestro modelo requerirá que se
seleccione entre los veterinarios disponibles. En la pestaña “Definitions”, cree una nueva lista, LIST of
OBJETOS, de nombre ListResources, y añada los cuatro recursos como se muestra en la Figura 13.3. Esta
lista se usará por los pacientes para seleccionar uno de los veterinarios.
72
El símbolo por defecto se asemeja a un ojo con un iris azul.
Figura 13.3: Creando una Lista de Recursos que Pueden ser Apresados
Paso 7: El modelo básico ha sido montado en base a recursos, RESOURCES; sin embargo, los pacientes,
necesitan apresar (pedir) un veterinario para que les atienda, y una vez hayan sido atendidos, deben
soltar al veterinario de forma que pueda atender a otro paciente. Los pacientes solicitarán un veterinario
cuando llegan a la clínica. Se han de utilizar entonces dos de los diez disparadores disponibles en el
servidor, SERVER.
Paso 8: El paciente necesita conseguir uno de los recursos disponibles antes de entrar en servicio (disparador
“Processing”). Para invocar este proceso “Processing”, seleccione en la ventana de propiedades “Add-
On Process Triggers” y haga doble clic en la etiqueta con la que se crea un proceso.
Paso 9: Dado que el paciente quiere apresar un recurso, incluya una etapa Seize: selecciónela de la lista de
posibles etapas y arrástrela entre los nodos Begin y End (Figura 13.4).
Figura 13.4: Usando una Etapa Seize para Conseguir un Veterinario

 Dentro de las propiedades “General” de una etapa, como se ve en la parte derecha de la Figura 13.4,
incluya el nombre SeizeStaff. En la propiedad “Basic Logic” se incluirán los recursos que puede ser
solicitados. Haga clic en el botón en la propiedad Seizes de la ventana de propiedades, que indica
que un tipo de recurso ha sido incluido y que puede ser solicitado.
 El editor Seize – Repeating Property Editor (véase Figura 13.5) aparecerá y permitirá que se
especifiquen tantos recursos como sean necesarios para empezar una operación. En este ejemplo,
especificaremos un tipo de recursos y fijaremos Object Type como “FromList”73, de forma que se
seleccione un recurso de cualquier lista. No queremos seleccionar un recurso que esté en fallo.
73
El Object Type en Seize puede ser “Specific”, “From List”, o “Parent Objeto”. La opción “Specific” le permite seleccionar un
recurso individual (por ejemplo, Jim) o un objeto que tiene capacidad (por ejemplo, Servers, Paths) o cualquier estación que esté
dentro de un objeto con capacidad. La opción “Parent Objeto” le permitirá conseguir capacidad de un objeto que está ejecutando un
proceso, por ejemplo, Processing STATION de una operación. En la opción “From List” se podrá especificar cualquier lista que
contenga un objeto que pueda ser solicitado.

Figura 13.5: Editor de Propiedades de la Etapa Seize
 Cuando se hayan acabado de incluir las propiedades en el editor, éste puede ser cerrado.
Paso 10: Los pacientes pueden ahora conseguir un veterinario, pero una vez que un paciente acaba su
procesamiento, éste también debe ser capaz de liberar al veterinario. Hay dos disparadores posibles
(“Processed” o “Exited”). Incluya un nuevo proceso “Processed”, haciendo doble clic en la etiqueta con
la que se crea un proceso.
 Incluya una etapa Release en el proceso entre los nodos Begin y End de forma que el paciente
pueda liberar al veterinario, como se muestra en la Figura 13.6.
Figura 13.6: Usando una Etapa Seize para Liberar un Veterinario

 Repita el proceso de nombrar a la etapa ReleaseStaff y especifique la propiedad Releases. Parecido
al editor Seize, el editor Releases→ – Repeating Property Editor permitirá a un paciente liberar los
recursos en función de las propiedades definidas en el editor.
Figura 13.7: Editor de Propiedades de la Etapa Release

Paso 11: Guarde el modelo y ejecútelo y observe lo que sucede.
Pregunta 1: ¿Cuál es el grado de ocupación de cada uno de los RESOURCES?

Pregunta 2: ¿Cuál es el tiempo total que un paciente tiene que esperar a un veterinario? ¿Cuál es el
número medio de pacientes en espera en la fila de entrada de la clínica?
Pregunta 3: ¿Cuál es el tiempo total en el sistema de un paciente?
Sección 13.3: Recursos en Función del Tipo de Paciente
El modelo anterior asumía que todos los pacientes pueden ser atendidos por todos los veterinarios. Sin
embargo, suponga que Billy y Masey tienen experiencia con pájaros mientras que Jim la tiene con iguanas,
pero si él está ocupado Ellie puede sustituirle. Los caballos y las vacas son grandes y necesitan ser atendidos
por dos veterinarios a la vez. Todos los demás animales (gatos y perros) pueden ser atendidos por cualquiera
de los veterinarios.
Paso 1: Cree una nueva tabla de datos, TableAnimals, que tenga una columna de tipo “String” para incluir
el nombre del animal, y otra de tipo “Real” que incluya el porcentaje de este tipo de animal en la clínica.
Los valores se muestran en la Tabla 13.1. Por ejemplo, el 25 por ciento son grandes.
Tabla 13.1:Tabla con Información Sobre Tipos de Animales
Paso 2: Cree dos nuevas listas, ListBird y ListIguana, de forma similar a como se creó ListResources, para
indicar qué veterinarios pueden atender a los animales especiales (Figura 13.8 y Figura 13.9).
Figura 13.8: Listas para el Pájaro y la Iguana

Paso 3: Añada tres símbolos adicionales a la entidad paciente para distinguir entre los distintos tipos de
animales. Se pueden utilizar cuatro colores diferentes, pero también dibujos descargados de Google 3D
Warehouse (Figura 13.9), y mostrarlos de forma horizontal (en vez de vertical). El orden de los símbolos
debe coincidir con la columna que refleja el tipo de animales en la tabla (Tabla 13.1).
Figura 13.9: Símbolos Descargados de Google 3-D Warehouse: Dog, Cow, Bird y Iguana
Paso 4: El objetivo es asignar de forma aleatoria los tipos de animales y sus respectivos dibujos (colores)
según los porcentajes de la tabla. La asignación se debe realizar una vez que la entidad ha sido creada, o

sea, utilizando el evento disparador “Created” en la fuente. Incluya este disparador74, que será ejecutado
un vez la entidad ha sido creada en SrcPatients.
 Una de las ventajas de SIMIO es su habilidad para asociar una o más tablas, o filas de una tabla, con
una entidad. Una vez creado, hay que asignar a un paciente con una fila específica de la tabla
TableAnimals, y después con el símbolo correcto en función del valor de la columna “Animal
Type”. Incluya una etapa Set Table y otra Assign en el proceso según la Figura 13.10.
Figura 13.10: Determinando el Tipo de Paciente Asociando una Fila de una Tabla de Datos con una
Entidad
 Especifique una fila de forma aleatoria utilizando el método RandomRow en función de los
porcentajes incluidos en la columna “PercentType” (Figura 13.11).75 También asegúrese que Object
Type en Advanced Options se especifica como “AssociatedObject”.76
Figura 13.11: Especificando las Propiedades de la Etapa Set Table

 Ya que se ha determinado el tipo de animal, en la Figura 13.12 se muestra las propiedades de la
etapa Assign utilizadas para asignar la columna “Type” de la tabla como símbolo a utilizar.77
Figura 13.12: Cambiando el Dibujo de una Entidad en Función de una Columna de una Tabla de
Datos
Paso 5: Guarde el modelo y ejecútelo para asegurarse de que se han creado los diferentes tipos de animales
según lo esperado. Pede que tenga que ajustar las filas de la animación en función de los tamaños de los
animales grandes.
Paso 6: Actualmente, todavía los pacientes, sin importar cuál es su tipo, apresarán un y sólo un veterinario.
Necesitamos añadir otro proceso para apresar y soltar recursos en función del resto de requisitos que se
han planteado (véase el flujograma incluido en la Figura 13.13):
74
Para invocar el proceso “Created”, abra “Add-On Process Triggers” en la ventana de propiedades de la fuente y haga doble-
click para crearlo.
75
Cualquier columna numérica puede ser utilizada para especificar una fila de una tabla aleatoriamente. Los números no tiene que
sumar 1 o 100. SIMIO sumará los valores de la columna y generará una fila en función de los porcentajes normalizados.
76
El objeto asociado, “Associated Object”, es el objeto representado por la ficha. En este caso, es la entidad o paciente. Las otras
opciones son “Token” para el que la ficha ejecuta el proceso y “ParentObjeto” que sería la fuente en la que se incluye el disparador.
77
Los tipos de animal se especificaron con valores entre 0 y 3 para coincidir con la numeración de los símbolos. La flecha verde
permite al usuario saber que se está referenciando una propiedad.
 Si el pacientes es del tipo perro/gato o caballo/vaca, podemos elegir cualquier recurso, pero si
es un animal grande, hay que apresar dos recursos.
 Si el paciente es un pájaro, es necesario elegir un veterinario de la lista ListBird.
 Finalmente, si es una iguana, la elección se hace de la lista ListIguana.
Si Paciente es True Consiguiendo

Begin un Perro o una un recurso de End
Vaca ListResource
False
True Consiguiendo
Si Paciente== Pájaro un recurso de
ListBird
False
Consiguiendo
un recurso de
ListIguana
Figura 13.13: Consiguiendo un Veterinario en Función del Tipo de Paciente

 Para seguir la lógica, necesitamos tomar algunas decisiones en función de los tipos de animal como
se muestra en el anterior flujograma. La lógica se incluye en una etapa Decide (Figura 13.14) que
es básicamente una condicional If/Else que tiene una opción verdadera, True, y otra falsa, False, en
función de si se cumple la condición o no. En la Figura 13.13, las dos propiedades de interés a
incluir en la etapa Decide son Decide Type y Expression.
Figura 13.14: Etapa Decide en SIMIO

La Figura 13.15 muestra el disparador “Processing”, con el que se eligen los veterinarios
apropiados en función del tipo de animal.
Figura 13.15: Consiguiendo el Recurso Apropiado en Función del Tipo de Animal

 Incluya una etapa Decide antes de Seize para determinar si el paciente es del tipo perro/gato o
vaca/caballo. Si es cierta la condición, el paciente apresará un veterinario en función de lo incluido

en ListResource. Especifique que la decisión es condicionada a que el animal sea del tipo 0 o 1
(Figura 13.16). 78
Figura 13.16: Especificando una Expresión Basada en una Condición en una Etapa Decide
 La segunda etapa Decide comprobará si el paciente es un pájaro. (Ayuda: copie el primer Decide
y péguelo en la rama False; cambie la expresión a (TableAnimals.Type==2)).
 Copie la etapa Seize tanto en True como en False de la segunda etapa Decide. Tendrá que
cambiar la lista en la que se busca la información (ListBird y ListIguana respectivamente).
 La primera etapa Seize ya puede apresar cualquier veterinario (ListResources). Sin embargo, por
defecto, sólo apresa uno. Se necesita apresar 2 cuando se está atendiendo animales grandes. Hay
varias formas de incluir esta lógica. Como el tipo de los animales gatos/perros es 0 y de
vacas/caballos es 1, se puede añador 1 al tipo para obtener un valor de 1 ó 2. En la propiedad
Number of Objects, incluya una expresión como la que se muestra en la Figura 13.17.
Número de
Recursos
Figura 13.17: Especificando una Expresión para Determinar el Número de Recursos a Conseguir
Paso 7: Guarde su modelo y ejecútelo. Puede que tenga que experimentar con los porcentajes para
asegurarse de que los animales están siendo atendidos por los veterinarios según lo esperado. La Figura
13.18 muestra una vaca siendo atendida tanto por Billy como por Jim.
Figura 13.18: Usando Dos Recursos para Atender a un Animal Grande.

Paso 8: La última cosa a hacer es liberar a los veterinarios una vez que han acabado con el animal. El
disparador es similar al disparador“Processing” pero utiliza una etapa Release en vez de una Seize.
Es importante que se suelte el número correcto de objetos y se incluyan de forma correcta en
ListResources.
78
La expresión (TablaAnimals.Type < 2) se podría haber especificado también como (TableAnimals.Type == 0 ||
TableAnimals.Type ==1) donde || es el operador lógico Or (O).
Figura 13.19: Soltando un Veterinario para que se Incluya en el Conjunto Adecuado
Paso 9: Guarde y ejecute su modelo para ver qué sucede (Figura 13.20).
Animales
siendo
Animales atendidos
en espera
Figura 13.20: Pantallazo del Modelo con Animales en Espera y en Operación
 La complicación de distinguir las entidades en función de su tipo se presente en muchas

situaciones distintas, y parece apropiado utilizar un tiempo para estudiar las posibilidades de
modelización.
 Aprecie el interés que suscita la representación en 3D y Google 3D Warehouse.

Capítulo 14
Objetos Inteligentes: Clínica Veterinaria bis
 Permitiendo que las ENTITIES tomen sus propias decisiones.
 Especificando listas de objetos en una tabla de datos
 Utilizando funciones en expresiones
Sección 14.1: Usando la Potencia de Objetos Inteligentes para Tomar Decisiones
En el capítulo anterior, exploramos el uso de recursos, RESOURCES, y mostramos cómo elegir diferentes
recursos de una lista en función del tipo de animal que tenía que ser atendido. Una de las características de
SIMIO es que se puede modelizar lógica muy complicada utilizando las etapas de proceso, ayudándolas con
la asociación de información incluidas en tablas de datos. En un capítulo anterior, el tiempo de proceso y la
información de rutas a seguir por diferentes tipos de piezas se asociaba a la propia pieza. Cuando las
entidades llegaban a la operación, SERVERS, se pregunta a la entidad cuánto tiempo era necesario para
procesarla. Muchos lenguajes de simulación, incluido SIMIO, tiene la posibilidad de especificar atributos
(variables de estado en SIMIO), a los que se puede asignar el tiempo de proceso cuando se crea la entidad.
Sin embargo, la información contenida en una tabla en SIMIO puede ser cambiada de forma dinámica para
que cualquier objeto la referencie.
Paso 1: Cree una copia del modelo del capítulo anterior.
Paso 2: Recuerde que sólo se ha utilizado con anterioridad la columna Type para tomar decisiones.
Modifique ahora la tabla de datos TableAnimals; incluya una columna “Integer” utilizando el
desplegable Standard Property, de nombre NumberStaff, para representar el número de veterinarios que
son necesarios para atender a un animal. Añada una columna OBJECT LIST a partir del desplegable
Object Reference, de nombre ListStaff, para representar la lista de los recursos que pueden ser
seleccionados. Especifique los valores como se muestra en la Figura 14.1. Ahora los pacientes saben qué
grupo de veterinarios les pueden atender así como el número necesario.
Figura 14.1: Incluyendo el Número de Veterinarios en TableAnimals

Paso 3: En la pestaña “Processes”, borre todas las etapas excepto un Release y un Seize en los
disparadores “Processed” y “Processing” respectivamente (Figura 14.2).79
79
Al modelizar la lógica de esta forma hemos conseguido eliminar dos etapas lo que hará que la simulación se ejecute de forma más
rápida. También simplifica la lógica y la facilita en el caso que se necesite añadir más tipos de animal. Ahora, la información está en
una tabla, por lo que no es necesario añadir más lógica.
Figura 14.2: Mejorando los Procesos Lógicos para Apresar y Liberar Veterinarios
Paso 4: Modifique las propiedades tanto en la etapa Seize como en Release para utilizar la propiedades
correspondientes a la asociación de tablas. En Object List Name y Number of Objects, haga clic con el
botón derecho y fije la propiedad Referenced Property en la columna correcta de la tabla
correspondiente. Cuando un paciente llega e intenta conseguir veterinarios, lo hará de forma dinámica
del grupo correcto.
Figura 14.3: Las Propiedades Seize y Release Utilizando Propiedades de Referencia

Paso 5: Guarde el modelo y ejecútelo y compare los resultados con los del modelo anterior.
Sección 14.2: Añadiendo un Proceso Adicional
Algunas veces, se necesita utilizar una máquina de rayos-X para explorar a los pacientes. La máquina se
encuentra en una sala diferente. Por ejemplo, un 25% de gatos/perros suelen necesitar una radiografía,
mientras que sólo lo necesitan 15%, 0% y 2% de vacas/caballos, pájaros e iguanas. Los pacientes se han de
dirigir a la sala contigua junto como los veterinarios. Después, los veterinarios son liberados para ir a atender
a otros pacientes.
Paso 1: Añada un nuevo servidor, SERVER , de nombre SrvXrayMachine.

 Fije su capacidad en “1”, puesto que sólo hay una máquina.
 El tiempo de proceso para realizar y leer la radiografía es una distribución Pert con un valor mínimo,
una moda y un máximo de 20, 25, y 35 minutos respectivamente.
 Conecte la salida de la nueva operación con SnkExit, utilizando un PATH de 30 metros.
 Conecte un PATH desde la salida de SrvVetClinic hasta la entrada de SvXrayMachine.
Paso 2: Dado que cada tipo de animal tiene una probabilidad distinta de necesitar una radiografía, añada una
columna “Real”, de nombre XrayLabPorcentaje en la tabla TableAnimals (Figura 14.4).
Objetos Inteligentes: Clínica Veterinaria bis 123

Figura 14.4: Porcentajes según la Necesidad de Radiografía
Paso 3: Si el paciente necesita una radiografía, no se debe liberar a los veterinarios directamente después de
los cuidados en la sala habitual. Se debe direccionar la entidad hacia la sala de rayos-X, en la que se dará
servicio a los animales en función de su orden estricto de llegada. Una vez leída la radiografía, se debe
liberar a los veterinarios y ser incluidos en el conjunto hábil para otros servicios, así como enviar las
entidades hacia la salida. La primera etapa ha de indicar si el paciente debe liberar al veterinario (etapa
Decide). Incluya una etapa Decide en el disparador “Processed” de SrvVetClinic. Mueva la etapa
Release a la rama “False” (Figura 14.5) de forma que sólo si no se necesita una radiografía se libere al
operario.
Figura 14.5: El Disparador “Processed” Modificado

 La etapa Decide se muestra en la Figura 14.6.
Figura 14.6: La Etapa Decide

Paso 4: Si el paciente necesita una máquina de rayos-X, la liberación se produce después. Incluya un
disparador “Processed” en SrvXrayMachine. Copie y pegue la etapa Release de
SrvVetClinic_Processed en el nuevo disparador.
Paso 5: Los pacientes que necesitan radiografía han de ser dirigidos a la nueva operación. Por defecto, los
pacientes serán dirigidos aleatoriamente hacia la salida o hacia la sala de rayos en igual proporción.80
Existen varias funciones (f(x) en el editor de expresiones) asociadas a los distintos objetos. En la Tabla
14.1 se incluye una descripción de la familia de funciones correspondientes a los objetos conseguidos,
SeizedObject. La función básica de SeizedObjects ejecutará la función
SeizedObjects.Count.
80
Podríamos haber especificado los pesos hacia cada ruta como 1-TableAnimals.XrayLabPercentage hacia la salida y
TableAnimals.XrayLabPercentage hacia la sala de rayos. Sin embargo, esta lógica sólo funciona de forma correcta si los
pacientes no necesitaran que los veterinarios les acompañaran a la sala de rayos.
Tabla 14.1: Descripción de las Funciones SeizedObjects
Función Descripción
Esta función calcula el número de objetos (RESOURCES, SERVER
SeizedObjects.Count
y LINK, etc.) apresados por el objeto que usa la función.
Toda copia de un objeto en un modelo de SIMIO tiene un
identificador numérico único (ID) (NODES, SERVERS,
SeizedObjects.FirstID
RESOURCES, etc.). Esta función devuelve ID del primer objeto
en la lista de objetos que ha sido apresado por el objeto.
Esta función devuelve ID del último objeto en la lista de
SeizedObjects.LastID
objetos que ha sido apresado por el objeto.
Esta función le permitirá determinar el número de unidades de
SeizedObjects.UnidadesOw
capacidad según el identificador objectID que ha sido
ned(objectID)
apresado por el objeto.
 Especifique el peso o probabilidad de tomar el camino que sale de SrvVetClinic y que llega a la
salida (SnkExit) como ModelEntity.SeizedObjects.Count == 0, lo que significa que el
paciente ha soltado al veterinario y puede dirigirse a la salida.
 Especifique el peso o probabilidad de tomar el camino que sale de SrvVetClinic y que llega a la sala
de rayos (SrvXrayMachine) como ModelEntity.SeizedObjects.Count > 0, lo que
significa que el paciente todavía no ha liberado a los veterinarios puesto que los necesita para
realizar las radiografías.
 Los pesos entonces serán evaluados a 0 ó 1, lo que fuerza a que tomen el camino correcto, esto es, el
que tenga el peso de 1.
Paso 6: Guarde el modelo y ejecútelo, observando lo que sucede.
Sección 14.3: Cambiando la Selección de Recursos
En la descripción original, Jim era el veterinario que debía atender a las iguanas y Ellie podía atenderlas si
Jim está ocupado. La clínica esté evaluando la posibilidad de que cuando Jim acaba de atender a un animal,
comprueba si hay una iguana esperando, y en ese caso, darle prioridad. La selección actual era FIFO, “first-
in and first-out”.
Los recursos, RESOURCES, como los servidores, SERVERS, tiene una regla de elección estática, static ranking
rule 81, que ordenará las solicitudes para un objeto. Tanto SERVER como RESOURCE procesarán las entidades
según como han sido ordenadas las entidades.82
Paso 1: Cambie la regla de ordenación de Jim a “largest value first”. La expresión debe referirse a la
propiedad tipo de animal, puesto que son las iguanas las que serán atendidas primero. 83 La regla estática
funciona porque el tipo de animal no cambia mientras que el paciente espera (Figura 14.7).
81
Las reglas estáticas son First-in First-out (por defecto), Last-in Last-Out, Smallest Value, y Largest Value; hay que añadir una
expresión en los dos últimos casos para posibilitar la comparación.
82
También hay reglas dinámicas, que se explicarán en el próximo capítulo.
83
Si Jim está ocupado y una iguana está la primera en la lista, Ellie puede seguir atendiéndola, lo que es aceptable. El objetivo es
aumentar las posibilidades de que sea Jim el que las atienda, pero sin eliminar completamente la otra posibilidad. Si sólo Jim
pudiera atender a las iguanas entonces utilice ListIguana para que sólo fuera Jim el incluido como recurso factible.
Objetos Inteligentes: Clínica Veterinaria bis 125

Figura 14.7: Regla Largest Value para Ordenar Solicitudes
Paso 2: Guarde el modelo y ejecútelo, observando lo que sucede. Puede que sea conveniente aumentar el
porcentaje que llega de iguanas.
Pregunta 1: ¿Hay algún problema con esta ordenación?
Paso 3: Este método hará que Jim atienda primero a las iguanas, pero también dará prioridad a las vacas
antes que a los perros. Jim sí debe atender primero a las iguanas; pero al resto de animales según su
orden de llegada. Una forma de conseguir esto es mediante la modificación de la propiedad “Ranking
Expresión” como se muestra en la Figura 14.8. La expresión lógica hará que las iguanas tengan un valor
de 1, y se mantenga su orden de llegada como factor determinante.
Figura 14.8: Modificando la Regla de Ordenación para no Atender a las Vacas antes que a los Perros
Paso 4: Guarde el modelo y ejecútelo y vea lo que sucede ahora.
 Una forma habitual de modelización, es añadir atributos adicionales a las entidades para que
incluyan valores o estados. Se podía haber utilizado una variable de estado discreta, Xray. En la
rama True del disparador “Processed” (Figura 14.9), se podía haber añadido una etapa Assign
para asignar el valor de 1 a Xray si fuera necesario hacer la radiografía.
Figura 14.9: Usando una Variable de Estado para representar la Necesidad de Hacer una
Radiográfica
 Los pesos se podían especificar entonces como (1-ModelEntity.Xray) y
(ModelEntity.Xray) para los caminos hacia la salida y la sala de rayos, respectivamente.
Los pesos valdrían 1 ó 0 y nunca serían los mismos. Si el paciente necesita una radiografía, (1-
ModelEntity.Xray) sería evaluada como 0 y (ModelEntity.Xray) como 1.

Capítulo 15
Usando un Operario: Clínica Veterinaria Tres
 Creando un direccionamiento más complicado
 Usando operarios, Worker
En el capítulo anterior (Capítulo 14) se ilustraba la flexibilidad de los recursos, RESOURCES, y de la lista de
recursos, RESOURCE LISTS, para modelizar relaciones complicadas. Sin embargo, estos tipos de recursos
están fijos, en el sentido de que no se mueven dinámicamente a lo largo del modelo. Cuando los pacientes
necesitan hacerse un radiografía, no se liberaba a los veterinarios mientras los pacientes se dirigían hacia la
sala de rayos. La animación sin embargo no mostraba el movimiento de los recursos. SIMIO tiene la
posibilidad de disponer de múltiples tipos de objetos (entities, workers, y vehicles) que pueden actuar como
recursos (apresados y liberados) y moverse a lo largo del sistema, justo como las entidades.
Sección 15.1: Direccionando Pacientes
Volvamos con nuestra clínica veterinaria. Sin embargo, haremos que la situación se asemeje todavía más a
una clínica. Los clientes han de llegar, registrarse y esperar en la sala de espera hasta que una esté libre. Los
pacientes entrarán entonces a una de las salas. El veterinario saldrá entonces de su despacho y recorrerá el
camino dinámicamente hacia las salas y atenderá a los pacientes según sea necesario. El veterinario va a ser
modelizado como un recursos móvil, que tiene que ser apresado y liberado.
Paso 1: Cree un nuevo modelo que tenga una fuente (SrcPatients), un sumidero (SnkExit), y cinco
operaciones (SrvVetWaiting, SrvRoom1, SrvRoom2, SrvRoom3, y SrvRoom4).
Paso 2: Incluya una nueva entidad, de nombre Patient. Los pacientes se moverán con un ritmo constante de
4.5 km por hora o 4500 metros por hora.
Paso 3: Incluya las salas con una disposición en planta correspondiente a dos pasillos con una sala de espera
común (Figura 15.1).84
 La capacidad de cada sala debe ser 1.
 El proceso de registro en SrvVetWaiting lleva entre 1 y 4 minutos (de forma uniforme) antes de que
el cliente se sitúe en la sala de espera.
 Cada paciente tarda en ser atendido entre 10 y 30 minutos con una moda de 12.
 Se ha observado que los pacientes llegan de forma exponencial, con un tiempo medio entre llegadas
de 6.5 minutos.
84
Para ser más eficiente, cree una sala con todas las propiedades y entonces cree tres salas nuevas, y llámelas con los nombres
propuestos.
Usando un Operario: Clínica Veterinaria Tres 127

Caminos
Separados para
Dar Salida a los
Pacientes
Figura 15.1: Nuevo Modelo de Clínica con Recursos Móviles

Paso 4: Incluya una pared con textura entre las habitaciones para dar mayor realismo a la separación (Figura
15.1). Asegúrese de especificar una altura de 4.5 metros85.
Paso 5: Conecte la salida de SrvVetWaiting con cada una de las entradas de las cuatro salas utilizando
caminos, PATHS , de nombre PathRoom1, PathRoom2, PathRoom3, y PathRoom4 respectivamente.
 La distancia entre la sala de espera y las salas 1 y 3 es de 15 metros y a las otras dos de 30.
 Seleccione los cuatro caminos y especifique su capacidad como 1 y la velocidad como 4500 metros
por hora.
Paso 6: Incluya caminos con las mismas distancias para posibilitar la salida de los pacientes. Se pueden usar
nodos de transferencia, TRANSFERNODES, para ayudar en el direccionamiento hacia la salida (Figura
15.1).86
Paso 7: Conecte la fuente con un conector, CONNECTOR, a SrvVetWaiting y use otro conector desde el
TRANSFERNODE hasta la salida SnkExit.
Paso 8: Incluya una nueva fila de salida con forma de U para animar SrvVetWaiting (véase Capítulo 11).
Paso 9: Como antes, los pacientes deben seleccionar una sala que esté disponible. Cree una lista, de nombre
ListRooms, que permita a los pacientes elegir una. En la Figura 15.2 se muestra la lista; fíjese que el
orden de preferencia es 1, 3, 2 y 4 (las más cercanas primero).
85
Después de seleccionar una línea o rectángulo, el área de edición de la altura, Object Height, y de la anchura, Line Width, se
encuentra en la sección “Object” de la pestaña “Drawing”.
86
Los conectores se usan para conectar las salidas de las salas con los TRANSFERNODES mientras que los caminos se usan para
conectar con los nodos.
Figura 15.2: Creando un Lista de Salas
Paso 10: En el nodo de salida de la sala de espera (Output@SrvVetWaiting), especifique Entity
Destination Type para que seleccione de una lista, “From a list”, de nombre ListRooms. El objetivo es
dirigir a los pacientes a una sala disponible. Especifique Selection Goal como “Smallest Value”. En los
capítulos anteriores utilizamos una expresión para determinar el número total de entidades como la suma
de los que se están dirigiendo hacia los nodos de entrada de las salas, esperando en el nodo de entrada de
la sala así como los que están siendo atendidos.
Paso 11: Sin embargo, se pueden utilizar funciones InputLocation (Tabla 15.1) para seleccionar
de forma dinámica entre los nodos de entrada de otros objetos. Estos nodos están asociados con una
operación interna (por ejemplo, Input@SrvRoom1 puede asociarse con una estación de entrada).
Tabla 15.1: Explicación de las Funciones InputLocation
Esta función calcula la capacidad actual de una
InputLocation.Capacity localización dentro de un objeto (por ejemplo, la
capacidad de la fila de entrada de una operación). 87
Esta función calcula la capacidad ociosa de una fila
InputLocation.CapacityRemaining
de entrada de una operación.
Esta función calcula el número de entidades en la
InputLocation.NumberInProcess localización (por ejemplo, en la fila de entrada,
InputBuffer.Contents)88.
Esta función calcula el número de entidades que
InputLocation.NumberWaitingEntry están esperando para entrar en la localización
(InputBuffer.EntryQueue).
Esta función calcula la carga, “load”, que es la
suma de entidades que se dirigen hacia un nodo, las
InputLocation.Load
que esperan a entrar en el objeto, y las que están en
el objeto.
Esta función calcula la sobrecarga, que es igual a la
InputLocation.Overload
carga “Load” menos la capacidad “Capacity”.
Con la expresión siguiente se calcula el número de entidades que se dirigen hacia una sala, que están
esperando para entrar en la sala, que están esperando en la sala y las que están siendo atendidas en la
sala:
87
La capacidad de una operación, SERVER, (estación Processing) no se incluye. Una capacidad infinita se representa por el mayor
valor entero, 2147483647.
88
InputLocation.NumberInProcess no incluye las entidades que se están procesando ni las que están en la fila de salida.

Candidate.Node.InputLocation.Load+Candidate.Server.Processing.Contents.NumberWaiting
Pregunta 1: ¿Funciona el modelo como se pretendía?
Paso 13: Los pacientes esperarán en las salas de atención después de registrarse, en vez de en la sala
de espera, que es lo que se pretendía. Tenemos que forzar a que los pacientes esperen en la sala de espera
a que haya salas libres. En cada uno de los cuatro caminos hacia las salas, cree un disparador “Reached
End” para que se ejecute cuando las entidades llegan al final del camino. El proceso se utilizará para
cerrar el camino (cambiando las velocidades no evita que las entidades entren en él).
 Incluya una etapa Assign para fijar la variable de estado DesiredDirection del camino en
Enum.TrafficDirection.None89 (por ejemplo, para el disparador PathRoom1_ReachedEnd la
variable de estado es PathRoom1.DesiredDirection). Cuando haya creado una etapa Assign, cópiela
y péguela en el resto de objetos, sin olvidarse de cambiar el nombre asociado (Figura 15.3).
Figura 15.3: Cerrando un Camino

Paso 14: Una vez que el paciente deja una sala, hay que abrir el camino para que otros clientes
puedan acercarse a ser atendidos. Para cada sala, cree un disparador “Exited” asociado a las entidades
que acaban y salen de la sala.
 Cambie la dirección deseada, DesiredDirection, a Enum.TrafficDirection.Forward en

Room1_Exited (Figura 15.4) y repita el proceso para cada una de las salas.90
Figura 15.4: Abriendo el Camino

Paso 15: Guarde el modelo y ejecútelo durante un período 40 horas.
Pregunta 2: Para las 40 horas, ¿cuál es el tiempo medio en el sistema y el tiempo medio de espera en la
sala de espera?
Pregunta 3: ¿Qué suposiciones hace el modelo?
89
Las enumeraciones son constantes predefinidas por SIMIO. TrafficDirection es un grupo de constantes de enumeración que
especifican en qué dirección pueden moverse en las uniones. Estas constantes pueden ser None (ninguna), Either (bi-
direccional), Forward (hacia adelante), o Backward (hacia detrás).
90
Cuando se ha acabado de crear los disparadores Exited, copie y pegue las etapas Assign asociadas con las salas,
cambiando el valor de Enum.TrafficDirection.None a Enum.TrafficDirection.Forward.
Sección 15.2: Usando WORKER como un Recurso Móvil
Nos hemos fijado hasta ahora en las salas, pero no en los veterinarios. Se podría utilizar como en los
capítulos anteriores un recurso fijo, RESOURCE. Como el veterinario se mueve, un recurso móvil parece más
representativo del sistema. Operarios, WORKERS, (y vehículos, VEHICLES) pueden ser asemejados a los
recursos (pues pueden ser apresados y soltados como los recursos y tienen capacidad como las estaciones,
STATIONS) y además son móviles.
Paso 1: De la [Project Library], añada un operario, WORKER, de nombre Vet. Cambie el símbolo a uno
apropiado.
Paso 2: Cree la red que va a ser utilizada por los veterinarios para moverse. Añada 6 nodos de transferencia,
TRANSFERNODES, de nombre TRoom1, TRoom2, TRoom3, TRoom4, TOffice, y TWaitRoom. Los
nodos TRoom se deben posicionar cerca de las salas, y el despacho en la parte de atrás (Figura 15.5).
 Conecte los nodos utilizando caminos, PATHS, bidireccionales, dado que los veterinarios se pueden
mover en ambas direcciones para ir a atender al siguiente paciente. Utilice distancias de 15 metros
para cada unión91. Los veterinarios utilizarán el circuito interior.
Circuito para
los
Veterinarios
Veterinarios
Figura 15.5: Clínica con el Circuito para los Veterinarios

Paso 3: Especifique para los veterinarios, Vet, que su nodo inicial, InitialNode es el despacho, TOffice.
Paso 4: Dado que un operario, WORKER, funciona como un vehículo, VEHICLE, tenemos que añadir los
lugares de aparcamiento para los operarios cuando llegan a las salas o al despacho. 92 Haga clic en uno de
los nodos de transferencia asociados con el circuito de veterinarios (TRooms o TOffice). Seleccione la
fila ParkingStation.Contents en la sección “Draw Queue” de la banda “Attached Animation” y
dibuje una fila animada muy cerca del nodo seleccionado. Repita el proceso para el resto de nodos del
circuito.
91
Seleccione todos los caminos y especifique la dirección y la distancia a la vez. Una nota de atención sobre los caminos
bidireccionales: pueden bloquear el sistema y sólo deben utilizarse cuando se utilizan un número pequeño de entidades, operarios o
vehículos. En caso contrario, es preferible utilizar dos caminos, uno en cada dirección.
92
Es para la animación, ya que, en caso contrario, los veterinarios desaparecerían una vez que llegaran a su destino.

Paso 5: Guarde el modelo y ejecútelo.
Paso 6: El veterinario Vet espera en su despacho y no buscan activamente atender a un paciente. Son los
pacientes los que necesitan llamar a un veterinario para que les atienda. Cuando un paciente va a ser
atendido, necesita apresar un Vet y luego soltarlo cuando haya acabado de atenderle.
 Cree un nuevo disparador “Processing” (Figura 15.6).

 Añada una etapa Seize para apresar un operario. La diferencia en este caso es que no queremos
apresar un operario hasta que no estemos en la sala.
 Modifique la propiedad de visita requerida Request Visit, para que sea ToNode y especifique el nodo
apropiado (TRoom1 para Room1). Esto fuerza a que llegue un operario al nodo de transferencia
TRoom1 antes de que el cliente puede empezar a ser atendido. La propiedad Visit Priority se puede
utilizar para especificar la prioridad si muchos nodos han requerido la presencia del operario (Figura
15.6).
Figura 15.6: Apresando un Operario y Forzando una Visita

 Cree un nuevo disparador “Processed” e incluya una etapa Release que libere al veterinario y le
posibilite atender a un nuevo paciente.
Figura 15.7: Liberando Operarios

 Repita el proceso para las otras tres salas; cree un nuevo disparador “Processing”.93
 En el desplegable del disparador “Processed”, seleccione SrvRoom1_Processed para cada uno
de las salas restantes, ya que la etapa Release está en ese momento soltando al veterinario Vet
(Figura 15.7).
Paso 7: Guarde el modelo y ejecútelo y observe cómo los veterinarios se mueven dinámicamente para llegar
a una sala a atender a un paciente.
sala de espera?
93
La forma más eficiente de conseguir nuestro objetivo es crear un nuevo disparador para cada una de las tres salas y copiar la etapa
Seize de la primera sala y después modificar la petición de visita en la propiedad Node Name para que incluya el nodo correcto.
Paso 8: Añada un segundo veterinario, cambiando la propiedad Initial Number in the System a “2”94.
sala de espera?
Pregunta 6: ¿Se puede justificar el segundo veterinario? ¿Por qué?
Sección 15.3: Volviendo al Despacho entre Pacientes
Un problema adicional de modelización es que los veterinarios necesitan volver a su despacho después de
cada visita a rellenar los informes del paciente que acaban de atender y leer el informe del siguiente paciente.
Las dos tareas han de ser realizadas antes de que vuelven a alguna sala para atender a un paciente. Tenemos
entonces que forzar a que vuelvan a su despacho y retenerlos durante un tiempo antes de que están hábiles
otra vez.
Dado que los operarios atienden a peticiones (dicho de otra forma, son los pacientes los que intentan
apresarlos), se puede modelizar esta situación como sigue: una entidad solicita a un veterinario para que vaya
a su despacho, de forma que el operario tenga que volver.
Paso 1: Guarde el modelo actual y fije el número de operarios otra vez en “1”.
Paso 2: Incluya un nuevo servidor, SERVER, de nombre SrvOffice cerca del nodo TOffice y conéctelo con
un sumidero, de nombre SnkOfficeWork (Figura 15.8). La realización de informes dura entre 4 y 14
minutos, siguiendo una distribución uniforme.
Figura 15.8: Modelizando la Elaboración de Informes

Paso 3: Incluya una nueva entidad, de nombre PaperWork. Será ésta la entidad que procese el operario en
su despacho. Dado que queremos que el veterinario acabe con los informes antes de ver a otro paciente,
otorguémosle a PaperWork una prioridad, Initial Priority, de 2 (recuerde que el valor por defecto es 1).
Cambie a su vez la propiedad Dynamic Selection Rule del operario a “Largest Value First”, e incluya la
expresión Value Expresión como Candidate.Entity.Priority.
94
Otra opción es añadir un segundo operario, de nombre VetB. Entonces, una lista de recursos tendría que ser creada para permitir
que las entidades eligieran uno de los operarios. Este tipo de modelización puede ser necesaria si los dos veterinarios atienden a
distintos tipos de pacientes, tienen diferentes prioridades o patrones de trabajo, etc.

Paso 4: Cuando el operario acabe con un paciente, se necesita crear una entidad PaperWork para que llame
al operario y le obligue a ir al despacho. Esta entidad necesita apresar, Seize, al veterinario antes que
otra sala lo haga. Como parte de este proceso, primero el paciente de la sala donde está debe liberarlo.
Modifiquemos el proceso SvrRoom1_Processed para conseguir todo esto (Figura 15.9). Recuerde que
este proceso se usa en todas las salas.
Figura 15.9: Creando y Transfiriendo la Necesidad de Informe

 Use la etapa Create para generar la nueva entidad.
Figura 15.10: Etapa Create para Producir una Entidad

 Use la etapa Transfer para mandar la nueva entidad al despacho.
Figura 15.11: Usando la Etapa Transfer Para Enviar la Entidad al Despacho

 Use la etapa Seize para que el veterinario sea requerido para hacer el informe. Recuerde cambiar el
nodo a visitar en la etapa Seize de TOffice.
 El veterinario será liberado con la etapa Release.
Paso 5: Finalmente, añada un disparador “Processed” que libere al operario después de que acabe los
informes, utilizando una etapa Release.
Pregunta 7: ¿Funciona el modelo como espera o observa algo inesperado?
Pregunta 8: ¿Qué pasa si añadimos un segundo Vet?¿Cómo se asegura de que el informe lo realiza el
veterinario correcto?

Sección 15.4: Eventos de Tiempo Cero
Una simulación por eventos discretos utiliza un calendario de eventos que se ordena en función de los
eventos futuros. Eventos de Tiempo Cero son eventos que ocurren justo en el mismo momento. 95 La etapa
Seize de los informes sucede a la vez que la etapa Release de las salas. Si la liberación ocurre antes que
la petición, el veterinario puede elegir atender a un paciente que lo haya solicitado en otra sala. La
ordenación de los eventos de tiempo cero puede convertirse en crítica durante la ejecución del modelo y
usted no sabrá cuál se ha ejecutado antes sin hacer de detective.
Una herramienta que ayuda a comprender lo que está sucediendo es el rastreador, “trace”. El “model trace,”
que se activa a través de la pestaña “Run”, es la descripción más completa de lo que está sucediendo. Sin
embargo, en este caso necesita rastrear y entender el comportamiento de un proceso. Para hacer esto, se ha
de seleccionar “Step” en la pestaña “Processes” y hacer clic en el botón de parada, break point , que se
encuentra en la banda, lo que hará que se vuelva rojo. En la pestaña “Facility”, seleccione “Model Trace”, lo
que hace aparecer el rastreador en su propia ventana en la parte de abajo de la pantalla.
Paso 1: Haga clic en la etapa “Create” de SvrRoom1_Processed y seleccione el botón de parada. La etapa
“Create” debe aparecer en color rojo.
Paso 2: Haga clic en el botón “Model Trace” dentro de “Run”. Ejecute el modelo.
Paso 3: Cuando la simulación se para, haga clic una vez en el botón “Step” (puede reconocer por qué se ha
parado, puesto que la línea del rastreador correspondiente también se colorea de rojo). Cuando hace clic
en el botón “Step”, se muestran una serie de acciones, en Amarillo, que representan una etapa en la
simulación. Puede que necesite retroceder en la pantalla para llegar a la parada.
Paso 4: La Figura 15.1296 es una impresión de todos los eventos que han ocurrido durante la parada.
Figura 15.12: Impresión del Rastreador en la que se Muestra la Ordenación de Eventos de Tiempo
Cero
Paso 5: Debe ahora leer el contenido del rastreador: la entidad, el objeto, la etapa y la acción. Vemos que la
entidad informe ha sido creada y que se transfiere a “SvrOffice.InputBuffer” antes de realizar la petición
de veterinario y esperar a que haya uno libre. Entonces, se ejecuta la etapa en que se libera a un operario.
Todo esto ocurre con el reloj de la simulación parado.
95
Existen docenas de eventos que ocurren al mismo tiempo y que pueden acarrear problemas, sobre todo, cuando hablamos de
recursos, operarios y vehículos.
96
La información incluida en el rastreador se salva automáticamente en un fichero CSV mientras que se ejecuta el modelo. El fichero
puede ser importado desde Excel para un análisis más en detalle.

Pregunta 9: ¿Puede ver ahora cómo la etapa Seize se realiza antes de la etapa Release?
Paso 6: Supongamos que por el placer de discutir, queremos que los pasos se realizaran en orden inverso.
Los eventos concurrentes han de ser ordenados. Para conseguirlo, ha de insertar una etapa Delay antes
de la etapa Seize (Figura 15.13), para representar la realización del informe. La duración ha de ser muy
pequeña, Math.Epsilon.97
Figura 15.13: Reordenando Eventos de Tiempo Cero Mediante el Tiempo Epsilon

Paso 7: El rastreador, después de ejecutar el modelo de nuevo, así como unos pocos “Steps”, tiene el aspecto
que se muestra en la Figura 15.14.
Figura 15.14: Reordenando los Eventos de Tiempo Cero

Paso 8: Por supuesto, esto NO es lo que queremos, luego quite el retraso introducido. Sí utilizaremos esta
táctica en cambio en capítulos venideros.
 Los objetos inteligentes ofrecen un número elevado de opciones de modelización, especialmente

cuando se trabaja como recursos, operarios y transportadores. Ya que hay tanta flexibilidad, se
pueden confundir las alternativas. Sin embargo, si utiliza estos objetos, empezará a desarrollar
patrones de modelización que parecen mejores que otros.
 Aunque es nuestra intención utilizar tantos enfoques de modelización como sea posible, es
necesario que nos ayude. Herramientas como el rastreador son muy útiles a la hora de entender
el funcionamiento de SIMIO. Es difícil modificar un comportamiento mientras que no se
comprenda del todo.
 Desafortunadamente, el comportamiento de los transportadores y de los operarios es complejo.
Tanto, que estos objetos pueden denominarse como los pesos pesados de la modelización. En
algunos diseños basados en objetos, estos pesos pesados se componen de pesos pluma que son
más sencillos. Pero este no es el caso de SIMIO, por lo que seguiremos investigando y
empleando la complejidad de estos objetos.
97
Math.Epsilon representa el menor valor real mayor que 0. Las etapas Delay interpretarán de hecho el número como 0, pero
fuerza a que el evneto se ponga al final del calendario de eventos. Si el tiempo se especificara como 0, SIMIO no cambiaría el orden.
Capítulo 16
Usando un Operario como un Recurso de Transporte: Un
Banco
 Usando un vehículo cono un recurso móvil
 Usando un vehículo para transportar entidades, que lo apresan.
En el Capítulo 15 utilizamos un operario como si fuera un recurso móvil. Los pacientes hacían que el recurso
visitara un nodo específico mediante la utilización de una etapa Seize, que obligaba al operario a situarse
en el nodo antes de que se iniciara la operación. Los vehículos, VEHICLES, también se pueden apresar y usar
como recursos de la misma manera. El objeto VEHICLE es un WORKER que puede transportar entidades. Los
conceptos que se utilizan en este capítulo son válidos tanto para vehículos como para operarios.
Sección 16.1: Un Pequeño Banco
Una pequeña sucursal de un banco emplea a varios especialistas en créditos que ayudan a los clientes. Los
clientes llegan al banco y esperan a un especialista en la sala de espera. El banquero recoge al cliente y le
acompaña a su oficina. Cuando se acaba la consulta, algunos clientes quieren también utilizar su caja de
seguridad, lo que implica que el banquero también le acompañe hasta las cajas. El banquero va a ser
modelizado utilizando o bien un operario o bien un vehículo.
Sección 16.2: Usando un Operario como un Recurso y un Transportador
Una ventaja cuando se utiliza un operario como un recurso móvil es que también puede ser utilizado como
transportador. Por ejemplo, el veterinario o el banquero pueden ir a la sala de espera y acompañar al paciente
a la sala (el recurso ha de ser apresado por el paciente). En el banco se acompaña al cliente al despacho.
Paso 1: Cree un nuevo proyecto.
Paso 2: Incluya una fuente, de nombre SrcWaitingRoom, una operación, de nombre SrvRoom, y un
sumidero, de nombre SnkExit.
 Conecte la entrada de SrcWaitingRoom a la entrada de SrvRoom con un camino de 15 metros y la

salida a SnkExit con otro camino de 15 metros.98
 Los clientes llegan según una distribución exponencial con un tiempo entre llegadas de 6.5 minutos.
 La capacidad de la operación es 1.
 Cada cliente suele estar en la oficina con el banquero entre 10 y 20 minutos, con una moda de 18
minutos.
98
Seleccione los dos caminos y cambie la propiedad Drawn To Scale a False y la propiedad Logical Length a 15 metros
simultáneamente.
Usando un Operario como un Recurso de Transporte: Un Banco 137

Paso 3: Incluya una entidad, MODELENTITY, de nombre Customer, y un operario, WORKER99, de nombre
Banker. El cliente y el banquero andan con una velocidad constante de 4.5 km por hora o 4500 metros
por hora.
 Cambie el símbolo del Banker a uno que sea más representativo (por ejemplo, una persona con
traje).
 Para Customer, añada 4 símbolos adicionales y elija cada uno de los cinco símbolos de la Library,
en particular de People. Fije Animation→Random Symbol a “True”, de forma que elija cualquiera de
los 5 de forma aleatoria.
 En el operario, mueva la fila de animación de forma que se sitúe al lado de Banker en lugar de
encima (Figura 16.1) y fije el nodo inicial, Initial Node (Home), como Output@SrcWaitingRoom.
 Asegúrese de que la fuente genera clientes.
Figura 16.1: Versiones en 2 y 3 Dimensiones Tanto para el Banquero como para el Cliente
Paso 4: Guarde el modelo y ejecútelo, asegurándose que la entidades se mueven correctamente.
Pregunta 1: ¿Genera símbolos de forma aleatoria para los clientes?
Paso 5: El banquero debe recoger a los clientes de la sala de espera y acompañarlos a su oficina. Cambie el
nodo de salida de SrcWaitingRoom (Output@SrcWaitingRoom) a un transportador, como se indica
en la Figura 16.2. Cambie la propiedad Ride On Transporter a “True” para permitir que pueda
transportar entidades y elija un tipo específico como tipo de transportador, Transporter Type, y
especifique Banker como el vehículo requerido.
Figura 16.2: Cambiando la Lógica del Nodo para Usar un Transportador

Paso 6: Indique que el camino entre SrcWaitingRoom y SrvRoom es bidireccional, ya que el banquero se
puede mover en las dos direcciones entre los dos lugares.
Paso 7: Guarde el modelo y ejecútelo, asegurándose que el banquero acompaña a las entidades hacia el
despacho.
99
Se puede utilizar también un VEHICLE.
Pregunta 2: ¿Qué observa? ¿Aguanta el banquero con el cliente mientras está siendo atendido?
El banquero es ahora mismo sólo un transportador que lleva clientes desde la sala de espera hasta la oficina,
pero no se queda con el cliente sino que vuelve a la sala de espera a por otro cliente.
Paso 8: Incluya un nuevo nodo TRANSFERNODE, de nombre TRoom100, encima de SrvRoom y conéctelo con
un camino bidireccional a la entrada de SrvRoom (Figura 16.3)101.
Figura 16.3: Modelo que Usa Vehículos como Recursos o como Transportadores
Paso 9: En SrvRoom, incluya disparadores en “Processing” y “Processed”. En “Processing”, incluya una
etapa Seize que aprese al banquero y le solicite una visita al nodo TRoom (Figura 16.4). En
“Processed”, use una etapa Release que libere al banquero cuando haya terminado con un cliente102.
Figura 16.4: Solicitando un Banquero para Verlo en el Nodo TRoom.

Pregunta 3: ¿Ha transportado el banquero al cliente hasta la oficina y después se ha colocado en posición
para atenderlo, antes de volver a por otro cliente?
100
Este nodo se utilizará como el nodo que necesita visitar en la etapa Seize. Por tanto, el nodo en el que el operario o el vehículo
dejan a los clientes no puede ser el mismo que deben visitar. Si se utiliza el mismo nodo, el modelo se bloqueará, pues el operario se
atasca en el modelo y la entidad en Inputbuffer, sin poder ser atendida.
101
Este camino bidireccional no consumirá tiempo porque su velocidad permitida es infinita.
102
La asignación como recurso es prioritaria sobre las solicitudes de movimiento. Si existe una entidad que solicita un transporte y
otra que solicita su servicio como recurso, el vehículo atenderá esta última primero.

Sección 16.3: Acompañando a los Clientes a la Caja de Seguridad
En esta sucursal, el 45 por ciento de clientes quiere abrir su caja fuerte después haber hablado con el
banquero.103 Se usará un método similar al usado en el Capítulo 14 para dirigir los pacientes hacia la
máquina de rayos-X. El recurso Banker no será liberado si el cliente necesita visitar la caja de seguridad.
Paso 1: Incluya una operación adicional, de nombre SrvSafetyDeposit.
 Fije la capacidad de la caja en 1, pues sólo hay una zona de seguridad.
 El tiempo que emplea un cliente en la zona de seguridad es una distribución Pert con un mínimo, una
moda y un máximo de 10, 15, y 25 minutos respectivamente.
 Conecte la salida de SrvRoom a la entrada de SrvSafetyDeposit con un camino de 5 metros.
 Conecte la salida de SrvSafetyDeposit a SnkExit con un camino de 15 metros.
Paso 2: Modifique el disparador SvrRoom_Processed para modelizar el comportamiento del banquero

cuando el cliente necesita que le acompañen a la caja de seguridad. Incluya una etapa Decide (Figura
16.5) que utilice una condición basada en probabilidad, y cuyo valor sea 0.45.
Paso 3: Si hay que realizar una visita a la caja de seguridad (rama “true”), incluya una etapa Set Node que
fijará el nodo de destino de la entidad como el nodo de entrada a SrvSafetyDeposit.104 Si no tienen que
ir a la caja de seguridad (rama “False”), se libera el banquero y se fija el nodo de destino en la entrada de
SnkExit105 (véase la Figura 16.6 para los detalles de las dos etapas Set Node). Cuando la entidad entra
en el nodo de transferencia de SrvRoom, en el que el tipo, Destination Type, ha sido establecido como
“continue”, el nodo de destino será el utilizado para enviar a las unidades.
Figura 16.5: Usando Set Node para Mandar Clientes a la Salida o la Caja de Seguridad
Figura 16.6: Valores de las Propiedades para Enviar una Entidad a la Caja o a la Salida
Paso 4: Incluya un disparador en “Processing” de SrvSafetyDeposit para apresar un banquero cuando la
operación se ha acabado (Figura 16.7).
103
El porcentaje es deliberadamente alto para determinar si el modelo se comporta como debe.
104
La etapa Set Node hace lo mismo que fijar la propiedad Entity Destination en un nodo TRANSFERNODE (ya sea con la opción
“Continue”, “Specific”, “By Sequence”, o “Select from List”).
105
En un capítulo previo, las funciones SeizedObject han sido ya usadas en los pesos de las uniones para enviar entidades o bien
a la salida o a la sala de rayos.
Figura 16.7: Apresando el Banquero en la Zona de Cajas de Seguridad
Paso 5: Incluya un disparador en “Processed” de SrvSafetyDeposit para liberar un banquero cuando la
operación sea ha acabado.106
Pregunta 4: ¿Hay clientes que van a las cajas de seguridad?
Pregunta 5: ¿Espera el banquero a que el cliente acabe su operación en la caja fuerte antes de ir a recoger
a otro cliente?
Pregunta 6: Si la pregunta anterior es cierta, ¿dónde espera el banquero mientras el cliente realiza su
operación en la caja?
Paso 7: El banquero no se mueve con el cliente desde la oficina hasta la caja de seguridad. Para facilitar este
movimiento del Banker hacia SrvSafetyDeposit, hay que incluir caminos que permitan al banquero
moverse (Figura 16.8).
Figura 16.8: Modelo para el Movimiento de Clientes y de Banqueros

 Incluya un nuevo nodo, TRANSFERNODE, de nombre TSafetyBox, y sitúelo cerca de
SrvSafetyDeposit. Será el nodo en el que el banquero se ocupe también del cliente mientras está en
la caja de seguridad.
 Incluya un conector que una el nodo TRoom con la salida de SrvRoom, de forma que el banquero
pueda usar el mismo camino para acompañar al cliente a la caja de seguridad.
106
Basta con que copie la etapa Release de SrvRoom_Processing en SrvSafetyDeposit_Processed.

 Conecte la salida de SrvSafetyDeposit a TSafetyBox con un camino y luego conecte TSafetyBox
con SrcWaitingRoom con un camino de 15 metros, lo que permite al banquero volver a la sala de
espera para atender al siguiente cliente.
Si el cliente necesita ir a su caja de seguridad, el banquero tiene que moverse con él. El proceso lógico se
incluye en el disparador “Processed” (Figura 16.5) y permite moverse a las entidades o bien hacia las cajas
de seguridad o bien hacia la salida según una etapa Decide basada en probabilidades, y una etapa Set
Node en la rama conveniente. Cuando se ejecuta el disparador, la ficha, TOKEN, está asociada a la entidad.
Así, cualquier etapa del proceso se aplica sólo sobre la entidad107 asociada con la ficha.
Para maniobrar con el banquero, será necesario identificarlo, con lo que emplearemos una etapa Search. La
etapa Search permite buscar algo en una colección y devolver fichas asociadas a lo encontrado.
Tabla 16.1: Las Propiedades de una Etapa Search

Propiedad Descripción
Collection Type Tipo de colección en la que buscar (véase Tabla 16.2 para más información).
Search Type Tipo de búsqueda a realizar (Forward, Hacia adelante, Backward, Hacia Atrás,
Mínimo Valor - MinimizeReturnValue, y Máximo Valor -
MaximizeReturnValue)108
Match Condition Condición adicional que se puede utilizar para filtrar los valores de la colección
antes de empezar la búsqueda. No se olvide de utilizar la clave CANDIDATE en la
condición.
Return Value Una expresión que se evalúa para cada unidad que cumple con la condición. La
suma total de esta expresión es el ReturnValue del TOKEN. Uno podría guardar
la información de un recurso e intentar apresar el mismo más tarde.
Starting Index Es un índice para empezar la búsqueda. Por defecto es 1 para búsquedas hacia
delante, y el número de elementos en la colección para búsquedas hacia atrás.
Limit Una expresión que especifica el máximo número de unidades que pueden ser
encontradas y especificadas.
Save Index Found Especifica una variable de estado discreta para guardar la último unidad
encontrada.
Save Number Especifica una variable de estado discreta para guardar el número de unidades
Found encontradas.
Tabla 16.2: Distintos Tipos de Colecciones
Tipo de Colección Descripción
ObjectInstance Búsqueda entre los objetos de una clase en particular (las que han
sido creadas...)
ObjectList Búsqueda entre los objetos en una lista (NodeList, ResourceList,
etc.)
ObjectsSeizedByParentObjeto Búsqueda entre los objetos que están apresados por un Parent
Object
ObjectsSeizedByAssociatedObjeto Búsqueda entre los objetos que están apresados por un Associated
Object
QueueState Búsqueda entre los objetos que están en una fila de espera
TableRows Búsqueda entre las filas de una Data table
107
En algunas etapas, la acción se puede aplicar al objeto padre del objeto asociado que tiene la ficha.
108
MinimizeReturnValue y MaximizeReturnValue buscarán en la colección y devolverán el límite de unidades que minimiza o
maximiza la expresión Return Value.
Paso 8: Si el cliente necesita ser acompañado a la caja de seguridad, incluya una etapa Search después de
la etapa Set Node (Figura 16.9). La rama “Original” se asocia con la ficha, TOKEN, original (el cliente)
mientras que la rama “Found” será invocada por la ficha asociada con cada unidad encontrada.
Figura 16.9: Buscando y Moviendo a un Banquero

 Fije la propiedad Collection Type en ObjectsSeizedByAssociatedObject, para
que busque entre todos los objetos que han sido apresados por los clientes.
 Fije Match Condition en Candidate.Is.Banker para que sólo se busque entre los
banqueros que han sido apresados.109 Esta condición asegura que sólo se identifica al
banquero que está asignado y no a otro objeto que está asignado a una entidad.
 Fije la propiedad Return Value para que calcule el identificador “ID” del operario que está
asignado.
Figura 16.10: Propiedades de la Etapa Search

Paso 9: Cuando el banquero ha sido encontrado, muévalo hacia TSafetyBox usando una etapa
Transfer110 (Figura 16.9) con las propiedades que se incluyen en la Figura 16.11.
Figura 16.11: Propiedades de Transfer para Dirigir al Banquero Hacia las Cajas
109
La entidad también ha apresado una unidad de capacidad de la operación SERVER, y no queremos que nos devuelva un objeto
SERVER.
110
La etapa Transfer se puede usar para mover objetos dinámicos (AGENTS, ENTITIES, VEHICLES, etc.) desde un Current Node,
Current Station, Free Space, o Link hacia otro nodo, Station, Parents External Node, o link.

Pregunta 7: ¿Se mueve ahora el banquero cuando el cliente necesita pasar por las cajas de seguridad?
Pregunta 8: ¿Funciona el modelo correctamente?
Sección 16.4: Usando la Función Transporte de un Operario
La dificultad del modelo anterior era que los clientes y el banquero se movían de forma independiente. Sería
mejor si el banquero pudiera recoger al cliente (funcionando como un vehículo) y transportarlo hasta las
cajas de seguridad, donde el cliente lo apresaría entonces otra vez de una forma similar a como se mueven
hacia la oficina del banquero.
Paso 1: Guarde el proyecto actual.
Paso 2: En este problema, sólo ciertas entidades necesitan ser transportadas por un operario/vehículo (las
que se dirigen a las cajas), mientras que los otros se dirigen hacia la salida. Entonces, el nodo de salida
de SrvRoom no puede ser el que se especifique para “Ride on Transporter” porque se transportarían a
todos los clientes. Una etapa Ride puede ser usada para forzar a que una entidad viaje en un vehículo.
Sin embargo, la etapa Ride sólo se puede utilizar en un disparador que se encuentre en un nodo,
TransferNode (por ejemplo, Output@SrvRoom). Así, toda la lógica utilizada para determinar
dónde irá la entidad después de ser atendidas en la oficina tiene que ser eliminada.
 Elimine el disparador “Processed” de SrvRoom al elegir “null” del desplegable111 (Figura 16.12)
dado que la lógica puede ser necesitada en otro disparador.
Figura 16.12: Eliminando un Disparador de un Objeto

 Seleccione la salida del nodo SrvRoom e incluya el proceso SrvRoom_Processed112 en el
disparador “Entered” (Figura 16.13). El proceso “Entered” se disparará cuando una entidad o
vehículo entre en el nodo.
111
También puede eliminar el disparador si lo selecciona y utiliza la tecla “backspace”. “Null” sólo inutiliza el disparador y n o el
proceso.
112
SrvRoom_Processed es justo el nombre del proceso y puede ser cambiado. Se podría haber creado un nuevo disparador y
entonces haber copiado toda la lógica.
Figura 16.13: Especificando el Disparador Entered
Paso 3: Si el cliente necesita ir a las cajas, el cliente debe solicitar un viaje en el vehículo y entonces liberar
al banquero de forma que pueda atender a otras solicitudes.
 En el proceso SrvRoom_Processed, borre la etapa Search dado que no se volverá a utilizar.
 Incluya una etapa Ride en la que el tipo Transporter Type ha de fijarse en “Specific” y el nombre
Transporter Name en Banker.
 Si la entidad necesita ir a la caja de seguridad y el cliente solicita un viaje, el banquero necesita ser
liberado de forma que pueda transportar al cliente hasta la caja de seguridad. Para volver a usar la
misma etapa Release en la rama “False”, alargue el final de la rama ( ) asociada con la etapa
Ride y déjela sobre la etapa Release (Figura 16.14).113
Figura 16.14: Añadiendo una Etapa Ride y Liberando al Banquero

Pregunta 9: ¿Qué observa cuando el cliente necesita ir a la caja de seguridad y el banquero va hacia el
nodo de salida de SrvRoom?
Paso 5: Cuando el banquero, que es el vehículo, llega al nodo de salida de SrvRoom a recoger a un cliente,
de hecho entra en el nodo con lo que se ejecuta la lógica incluida en la Figura 16.14: o bien sale del
modelo o es recogido por otro banquero. Se crea un bloqueo en el sistema. Sólo los clientes deben
ejecutar la lógica.
113
Podría también haber copiado y pegado otra etapa Release después de la etapa Ride

Paso 6: Incluya una nueva etapa Decide (Figura 16.15) antes de la etapa Decide incluida con
anterioridad, para comprobar si el objeto asociado con la ficha es una entidad. El operador Is
comprobará si el objeto es un objeto en particular, en este caso una entidad, Is.ModelEntity, y
devolverá un valor de “True” si es un cliente y “False” si es un banquero (WORKER/VEHICLE) como se
muestra en la Figura 16.15.
Figura 16.15: Usando el Operador Is Para Determinar si el Objeto es una Entidad

Pregunta 11: ¿Qué observa ahora cuando el cliente necesita ir a la caja de seguridad?
Paso 8: El problema es que el banquero responde a las peticiones según el orden de llegada. El cliente que va
a las cajas debería tener prioridad.
 Añada una etapa Assign que cambia las prioridades de los clientes (ModelEntity.Priority)
y las fija en 2 (Figura 16.16).
 Cambie la propiedad Task Selection Strategy de Banker a “Largest Priority” como se ve en la
Figura 16.17.114
Figura 16.16: Usando el Disparador Entered para Especificar un Viaje del Vehículo
Figura 16.17: Cambiando la Estrategia de Selección de un Vehículo

114
Al cambiar la estrategia de selección, Task Selection Strategy, se reordena la fila de recogida del vehículo.
Pregunta 13: ¿Funciona el modelo correctamente ahora?
 Usando el vehículo o el operario tanto para los transportes como las operaciones obliga a prestar
mucha atención a los detalles. Sin embargo, una vez entendidos, el modelo se comporta de
manera muy semejante al comportamiento real.

Capítulo 17
Creando Objetos: Actividades en un Almacén
 Conociendo cómo son los objetos SIMIO
 Haciendo subclases de los objetos SIMIO para crear versiones especiales
 Comprendiendo cómo los objetos SIMIO operar con subclases
Muchos lenguajes de simulación no tienen la habilidad de modificar el comportamiento de los objetos, y se

necesita que otro objeto actúe de forma complementaria. Si, por ejemplo, no le gusta cómo los creadores de
SIMIO han implantado el servidor, SERVER, puede modificarlo o crear su propio objeto.
Sección 17.1: Creando un Modelo Simple con Recursos: un Almacén
Un almacén tiene un zona de recogida a la que los clientes han de ir a por aquello que no esté en las
estanterías. La zona de recogida está atendida por un operario asociado que espera a que lleguen clientes.
Dado que no está ocupado todo el tiempo, el asociado también realiza tareas de apoyo en la colocación de
unidades en las estanterías. Obviamente, la dirección del almacén desea que dé prioridad a los clientes sobre
cualquier tarea de apoyo.
Paso 1: Cree un nuevo modelo.
Paso 2: Incluya dos SOURCES, de nombre SrcCustomers y SrcItems y dos MODELENTITIES, de nombre
Customers y Items.
 SrcCustomers debe crear Customers mientras que SrcItems debe crear Items.
 Los clientes llegan cada 2 minutos y las unidades cada 4 minutos (ambas según un modelo
exponencial).
 Coloree los Customers con color rojo.
 Fije la prioridad inicial, Initial Priority, de los Items en “0”. Por defecto, todas las entidades tiene
una prioridad de 1.
Paso 3: Incluya 2 SERVERS, de nombre SrvCustomer y SrvStorage, y un SINK, de nombre SnkExit.
 Cada uno de los servidores tiene que tener una capacidad de 1.

 La propiedad Processing Time de SvrCustomer es Exponencial (1.5) minutos y Exponencial (2.5)
para SvrStorage.
 Conecte las dos fuentes con los servidores apropiados con unos caminos que cubran una distancia
lógica de 10 metros y las operaciones con el sumidero con otro camino de las mismas características
(Figura 17.1).

Figura 17.1: Modelo de la Zona de Recogida de un Almacén
Paso 4: Incluya un RESOURCE, de nombre Associate, o mozo, y sitúelo entre las dos operaciones para
restringir el procesamiento de entidades (Figura 17.1).
 Cambie la propiedad Dynamic Selection Rule del mozo para que sea “Largest Value First”, mientras
que deje la propiedad Value Expression según su valor por defecto
(Candidate.Entity.Priority). Esto fuerza a que el asociado atienda primero a los clientes
si tiene que elegir.
 Añada un símbolo adicional, coloreando el círculo del símbolo 0 de color verde y el símbolo 1 de
color rojo (Figura 17.2) para indicar a qué tipo de pieza está atendiendo.
Figura 17.2: Añadiendo un Segundo Símbolo para el Mozo

Paso 5: Añada una nueva variable de estado discreta, DISCRETE STATE, de nombre AssociatePicture, para
que sirva para especificar el símbolo a mostrar durante la animación, ya que la imagen de un recursos no
se puede asociar de forma directa.
Paso 6: Cambie la propiedad Current Symbol Index de Associate para que refleje la nueva variable (Figura
17.3).
Figura 17.3: Símbolo para la Animación

Paso 7: En la pestaña “Processes”, cree dos nuevos procesos, de nombre SeizeAssociate y
ReleaseAssociate. El proceso ReleaseAssociate debe liberar al asociado mientras que el proceso
SeizeAssociate debe apresarlo así como asignar el valor de la prioridad de
ModelEntity.Priority al dibujo del recurso, AssociatePicture (Figura 17.4).
Creando Objetos: Actividades en un Almacén 149

Figura 17.4: Procesos para Apresar y Liberar al Asociado
Paso 8: En ambas operaciones, SrvCustomer y SrvStorage, especifique que el disparador de
SeizeAssociate es “Processing” y el de ReleaseAssociate es “Processed”.
Pregunta 1: Cuando el asociado acaba con un cliente, ¿atiende a un nuevo cliente si hay alguno
esperando?
Pregunta 2: ¿Por qué ocurre esto, si el criterio de selección, Dynamic Selection, del asociado se
especificó correctamente?
Sección 17.2: Apartando un Objeto para Averiguar Por Qué
Por alguna razón, el cliente que está esperando en la fuente SrvCustomer no registra una petición de
servicio. En este momento, el problema puede que no sea del todo evidente. En contra de lo que sucede en
otros lenguajes de simulación, los objetos en SIMIO pueden ser examinados, apartándolos y posiblemente
modificando su comportamiento. Se examinan y modifican los objetos según un procedimiento para hacer
“subclases”.
Para entender por qué la fila no ha conseguido registrar las peticiones de servicio, se hará una subclase con el
servidor, SERVER, para entender su comportamiento interno. Hacer subclases, subclassing, posibilita ampliar
y modificar un objeto existente o un objeto padre.
Paso 1: Para hacer una subclase de cualquiera de los objetos estándar, haga clic con el botón derecho en el
objeto de la librería y elija la opción “subclass” en el menú (Figura 17.5).
Figura 17.5: Haciendo una Subclase de una Operación

Paso 2: Seleccione el objeto MYSERVER en el panel de navegación. Ahora, se pueden ver todas las
características del SERVER, en la sección Definitions→Element. El objeto tiene definidos 7 elementos
diferentes: 3 STATIONS, 1 FAILURE, y 3 TIMER.
 El elemento STATION se usa para definir una localización con capacidad restringida en la que pueden
habitar 1 o más entidades. Cada STATION define una fila de entrada para las entidades en espera para
conseguir capacidad, EntryQueue, y otra fila para las entidades en proceso, InProcess.
 El elemento FAILURE se usa para definir un tipo de fallo. Los fallos empiezan y acaban según las
etapas Fail y Repair.

 El elemento TIMER dispara una cadena de eventos en función de un intervalo, IntervalType
(calendario, número de eventos o número de entidades procesadas). Estos temporizadores indican
cuándo ocurren los fallos que se hayan definido.
Cuando las entidades llegan al nodo de entrada, se transfieren directamente a la fila de entrada,
“InputBuffer” si hay capacidad libre. Del “InputBuffer”, las entidades se transfieren a la
estación de procesamiento, “Processing”, y cuando están acabadas, se mandan a la estación
correspondiente a la fila de salida, “OutputBuffer”.
Paso 3: Seleccione la pestaña “Processes” para estudiar cómo se comporta el objeto. El objeto servidor está
definido por 11 procesos que dirigen cómo el objeto reacciona ante fallos, cambios en la capacidad,
llegada y salida de entidades, etc. Algunos de los procesos responden directamente a eventos (entidades
entrando en la estación de procesamiento, entrando en la fila de entrada, etc.).
Los dos procesos que nos interesan (Figura 17.6) son: OnEnteredInputBuffer, que se
ejecuta cuando las unidades entran en la fila de entrada, InputBuffer, desde el nodo de entrada
si la fila tiene suficiente capacidad, y OnEnteredProcessing, que se ejecuta cuando las
unidades entran en la estación de procesamiento, ya sea desde el nodo de entrada o desde la fila
de entrada.
Figura 17.6: Procesos OnEntered de las Filas de Entrada y de Procesamiento

Cuando llegan las entidades a la operación, son transferidas a la fila de entrada, y
automáticamente se ejecuta el proceso OnEnteredInputBuffer, que tiene una serie de
etapas predefinidas. Un examen en detalle de estas etapas permitirá identificar ciertos problemas
de ejecución.
 Realización de las asignaciones de estados

 Ejecución del disparador “Entered”. El proceso Execute ejecutará el proceso determinado antes de
seguir.
 Demora si hay tiempo especificado.
 Finalización de la transferencia de la entidad hacia InputBuffer.
 Obtención de una unidad de capacidad.
 Ejecución del disparador “Processing”, que en este caso permitirá conseguir al mozo de almacén.
 Transferencia a la estación de procesamiento Processing, en donde empiezan a dirigir otros
procesos.

Cuando se transfieren las entidades a la estación de procesamiento, se ejecuta el proceso
OnEnteredProcessing para que se realice el procesamiento.
Si la fila de entrada tiene una capacidad de 0, el proceso es el mismo que “OnEnteredInputBuffer”.
Finalización de la transferencia de la entidad hasta la estación Processing.
Demora de la entidad en función del tiempo de proceso especificado por el usuario.
Ejecución de disparador “Processed”, que en la zona de recogida corresponde con la liberación del
mozo.
 La entidad o bien abandonará la operación o bien será transferida a la estación de salida,
OutputBuffer, si su capacidad es mayor que 1.
Paso 4: La primera clave para entender nuestro problema es que el disparador “Processing” no se ejecuta
hasta que la entidad es capaz de conseguir capacidad en SERVER. Examine ahora los procesos Entered y
Exited de la fila de salida, OutputBuffer (Figura 17.8).
Figura 17.7: Procesos OnEntered y OnExited de la Fila de Salida.

Se ejecutará el proceso OnEnteredOutput cuando la entidad haya sido transferida a la estación de
salida, OutputBuffer, y sigue los siguientes pasos.
 Acaba el movimiento hacia la estación.
 La entidad libera capacidad del objeto SERVER.
 Se ejecuta la asignación correspondiente.
 Se transfieren las entidades hacia el nodo de salida, con lo que se invoca el proceso
OnExitedOutputBuffer, que es el que ejecuta el disparador “Exited”.
Paso 5: Se puede observar que el disparador “Processed” con el que se libera al mozo se ejecuta antes de
que se libere capacidad en el servidor, SERVER. Por eso, el cliente que está esperando en la fila de entrada
no puede realizar una solicitud de mozo antes de que el recién liberado mozo evalúe las peticiones ya
realizadas. Para solventar el problema, fije la capacidad de las dos operaciones en “Infinity”, con lo que
se eliminan las restricciones. Así, cada entidad que acceda a una de las dos operaciones ejecutará
inmediatamente el disparador “Processing” y realizará la petición.
Paso 6: Guarde y ejecute el nuevo modelo.
Pregunta 3: Después de observar lo que sucede durante un rato, ¿da servicio el mozo primero a los
clientes en todos los casos?
Paso 7: Haciendo infinita la capacidad resuelve el problema. Sin embargo, hay situaciones en las que la
capacidad no debería ser infinita puesto que el espacio real puede limitar el número de entidades que se
atienden. Por ejemplo, puede que haya más de 1 operario, pero no haya más espacio para atender a
clientes. En la Figura 17.7, el disparador “Exited” se ejecuta después de la etapa Release y puede ser
utilizado para liberar al operario.
 Cambie la capacidad de las operaciones de vuelta a “1”.

 Desactive el disparador “Processed” de cada operación haciendo que su valor sea nulo, o
simplemente elimínelo.
 Elija ReleaseAssociate como el disparador “Exited” para cada una de las operaciones.

Pregunta 4: Después de observar el modelo durante un rato, ¿atiende primero a los clientes en todos los
casos?
Paso 9: El problema vuelve a aparecer, pero en este caso se libera al mozo después de liberar capacidad en la
operación. Los dos eventos suceden a la vez, pero la ordenación hace que se libere capacidad de la
operación antes que al operario. Compruébelo utilizando el rastreador, “Model Trace.”
Paso 10: Para ordenar correctamente los eventos simultáneos, coloque una etapa Delay justo antes
de la etapa Release, con un tiempo infinitesimal, Math.Epsilon (Figura 17.8). Cuando SIMIO se
encuentra con un retardo de este tipo, coloca las etapas al final de la lista de eventos a ejecutar en el
mismo momento de tiempo.
Figura 17.8: Añadiendo un Retardo Infinitesimal

Pregunta 5: Después de observar el modelo durante un rato, ¿atiende el operario a clientes antes en
cualquier situación?
La posibilidad de ampliar o modificar los objetos de SIMIO aparece debido a la naturaleza de los lenguajes
orientados a objetos, y de la especialización o “subclassing.” En la Figura 17.9 se muestra una parte de la
jerarquía de SIMIO en la que los objetos de los niveles inferiores se derivan de los objetos padre. Cuando
una clase se deriva de otra clase, hereda todas sus características (propiedades y variables de estado) así
como sus comportamientos (métodos, procesos y funciones), pero tiene la posibilidad de modificar todas sus
características heredadas así como de añadir alguna nueva.
Objeto
Inteligente
Agente Fijo
Entidad Unión Nodo Operación
Máquina
Transportador Operario Conector Nodo Básico
de Coser
Figura 17.9: Jerarquía de Objetos en SIMIO

La estructura empieza con la clase de objeto inteligente, INTELLIGENT OBJECT (IO), que proporciona a los
objetos la posibilidad de apresar y liberar así como de seguir unos turnos. La clase agente, AGENT, hereda las
propiedades de la clase IO pero añade características y comportamientos adicionales (objetos que pueden
crear y destruir dinámicamente, así como moverse por un espacio continuo o discreto). La entidades
ENTITIES son agentes especiales que tienen la posibilidad de moverse por las uniones (caminos, cintas
transportadoras y conectores) así como moverse dentro y fuera de los objetos fijos. El transportador,
TRANSPORTER, es una entidad más especializada que tiene la capacidad para recoger y depositar entidades.
Pueden hacerlo moviéndose tanto en el espacio libre como por uniones. Se puede crear un nuevo objeto
operario, OPERATOR, que es una especialización de una entidad para que actúe como recurso. Se pueden
modificar y añadir algunas propiedades (Initial Node, IdleCondition, etc.) o ciertos procesos de forma que
la lógica de una entidad se asemeje a la de los recursos y vehículos.
Los objetos fijos, FIXED, representan un sistema entero o pueden representar objetos inteligentes que son
fijos y no se mueven en el espacio. Los objetos LINK, NODE y SERVER tienen las mismas propiedades de la
clase Fixed, pero con más funcionalidad. LINK permite (propiedades y comportamientos) a las entidades para
que entren, salgan o se muevan. De la misma forma, los objetos PATH, CONNECTOR y CONVEYOR son versiones
especiales de la clase LINK. La clase SERVER corresponde con un objeto bastante general que se usa para
restringir y retardar a las entidades en el sistema mientras que la clase SEWINGMACHINE tiene ciertas
características que son únicas de las máquinas de coser (una operación especial). La clase puede hacer lo que
hace un objeto SERVER pero añade o modifica capacidades y comportamientos.
La posibilidad de ampliar y añadir objetos es una característica importante de SIMIO y una que necesita ser
estudiada en detalle. Si se necesita la máquina de coser sólo en una ocasión en un modelo, es posible que no
quiera tomarse el tiempo para crear una clase. Sin embargo, si va a utilizarla muchas veces, disponer de un
objeto que pueda se reutilizable es muy importante y la utilidad se demostrará en los siguientes capítulos.

Capítulo 18
Creando Objetos Nuevos Utilizando Subclases: Objeto
Delay (Retardo)
 Haciendo una subclase de un objeto ya existente
 Añadiendo nuevas propiedades
 Usando un separador, SEPARATOR, para crear una copia de una entidad.
En el capítulo anterior, hemos demostrado la posibilidad de especializar objetos existentes, lo que permite
añadir características y comportamientos adicionales o modificar los ya existentes. A menudo las entidades
necesitan ser retardadas un cierto tiempo antes de continuar hacia su siguiente destino. El objeto servidor,
SERVER, se puede utilizar para realizar esto, pero puede que su complejidad sea excesiva para realizar una
operación simple de retardo. El primer enfoque va a ser ampliar un objeto existente para añadir la posibilidad
de retardar a las entidades que pasan a través de ese objeto.
Sección 18.1: Haciendo una Subclase del Nodo de Transferencia para crear un Nodo de
Retardo
El nodo de transferencia, TRANSFERNODE, es un objeto que se utiliza para direccionar o transferir entidades
desde un objeto (SERVER, SOURCE, etc.) o como localizaciones para transferir entidades dentro de una red de
uniones o un circuito. Proporciona una excelente opción para detener durante un tiempo a una entidad, antes
de que continúe hacia su destino. La lógica para subirse a un transportador, para continuar una secuencia o
para elegir el camino más corto, ya está incluida en el objeto y estas propiedades y comportamientos no
tienen por qué ser reinventadas en un nuevo objeto. Así, un nodo de transferencia va a ser clonado en una
subclase. Este enfoque amplia y modifica un objeto existente o un objeto padre, que pasan a denominarse
objetos especializados o derivados, “derived”.
Paso 1: Primero cree un nuevo proyecto y un nuevo modelo en SIMIO.
Paso 2: Para hacer una subclase a partir de uno de los objetos estándar115, haga clic con el botón derecho en
el objeto y elija “subclass” del menú (Figura 18.1).
Figura 18.1: Haciendo una Subclase de TRANSFERNODE
Paso 3: Se crea una versión derivada de la clase correspondiente al nodo de transferencia en el panel
Navigation con el nombre MYTRANSFERNODE. Haga clic con el botón derecho en la nueva clase y
seleccione la opción Model Properties para que se muestren todas las propiedades.
 Cambie Model Name a DELAYTRANSFERNODE.
115
Puede también hacerlo con un objeto creado por el usuario.
Creando Objetos Nuevos Utilizando Subclases: Objeto Delay (Retardo) 155

 Cambie Icon property a uno más apropiado (un png o bitmap).116 El icono es la imagen que se ve en
la ventana del proyecto. Por ejemplo, el fichero Delay.png (Figura 18.2) será utilizado en este
capítulo.
Figura 18.2: Icono para DELAYTRANSFERNODE
 En la categoría “General”, cambie el color del nuevo nodo DELAYTRANSFERNODE a algo como
marrón117.
Seleccione el nuevo nodo en el panel [Navigation] y tómese un poco de tiempo para mirar qué
procesos y características se han heredado. En la pestaña “Processes” puede ver los procesos que se
incluyen en la Tabla 18.1 y que han sido heredados de la clase padre TRANSFERNODE.
Tabla 18.1: Procesos Heredados Desde TransferNode

Proceso Descripción del Proceso
OnEntered Este proceso se ejecuta cuando el principio,
leading edge, de un objeto (ENTITY,
TRANSPORTER, o AGENT) ha entrado en el nodo.
OnEnteredFromAssociatedObject Este proceso se ejecuta después de que una
entidad ha entrado en el nodo desde otro objeto
(por ejemplo, descarga desde un vehículo).
OnExited Este proceso se ejecuta cuando el final, trailing
edge, de un objeto ha salido del nodo.
OnInitialized Este proceso se ejecuta cuando empieza la
ejecución de la simulación.
OnEnteredParking Este proceso se ejecuta cuando la entidad o el
transportador entra en el parking.
RoutingOutLogic Un proceso que se utiliza para representar la
lógica de direccionamiento de objetos desde el
nodo.
TransfertoLinkFailureLogic Si un objeto no consigue ser transferido a la unión
u objeto correspondiente, el objeto será o
destruido o aparcado (los transportadores no
pueden ser destruidos).
Seleccione la pestaña “Definitions” para acceder a las características del nodo. Los elementos
representan los objetos que cambian o controlan el estado de los objetos a lo largo del tiempo
(estadísticas, temporizadores, controladores, fallos, etc.). Hay dos elementos definidos: una estación
de parking y un grupo de direccionamiento.
 La estación de parking, PARKINGSTATION, se usa para dar cabida a entidades, operarios y

transportadores que utilicen el nodo como aparcamiento. Se discutirá más sobre este elemento en la
siguiente sección.
116
Los iconos son típicamente de 32 píxeles de ancho por 32 de alto. Muchos programas de edición de imágenes pueden crear estos
iconos (Photoshop, Paint o el software libre GIMP (http://www.gimp.org)).
117
No puede cambiar la imagen porque los nodos son objetos especiales que no ocupan espacio en el sistema actual.
 El elemento ROUTINGGROUP se utiliza con una etapa Route para direccionar una entidad hacia su
destino, seleccionándolo de una lista de nodos. El objeto TRANSFERNODE utiliza un elemento
RoutingGroup como lógica interna para determinar dónde irán las entidades que dejan el nodo.
 La nueva subclase hereda también otras propiedades y estados, así como cuatro eventos (Tabla
18.2).118
Tabla 18.2: Eventos heredados del Nodo Padre

Evento Descripción del Evento
CapacityChanged Se cambia la capacidad del nodo
Entered El inicio de un objeto ha entrado en el nodo
Exited El final de un objeto ha salido del nodo
RiderWaiting Una entidad está esperando transporte en este
nodo.
Se han definido dos listas con texto (TransferNodeDestinationType y

AutoTransferOnEntryType) para que se utilicen en los desplegables. La lista
TransferNodeDestinationType se usa para especificar la forma de enviar la entidad a su nodo
destino (las opciones son: Continue, Specific, BySequence, SelectFromList) mientras que la lista
AutoTransferOnEntryType puede utilizarse para mandar automáticamente los objetos que entran
en el nodo al nodo padre externo.
Sección 18.2: Modificando los Procesos y Añadiendo Propiedades en un Nodo Nuevo
En la sección anterior, se ha creado un nuevo nodo a partir de un nodo estándar. Sin embargo, el nodo se
comportará como el nodo original dado que ni se ha modificado ni se ha añadido nada nuevo. El nodo ha de
retardar durante un tiempo los objetos que llegan a él tanto individualmente como con un transportador.
Paso 1: En la pestaña “Definitions” en el nodo Delay, añada una propiedad Expression119, de nombre
DelayTime, que puede utilizarse para especificar el tiempo que se va a retardar una entidad. Especifique
la propiedad Default Value como “0”, Unit Type como “Time”, con Default Units en “minutos” (Figura
18.3). Sitúe la nueva propiedad debajo de la categoría “Process Logic”.
118
Para acceder a lo heredado, haga click en para hacerlo visible.
119
La propiedad Expression permite al usuario incluir cualquier tipo de expresión matemática similar al tiempo de proceso de una
operación, SERVER.

Figura 18.3: Incluyendo una Propiedad Expression
Cada vez que una entidad entra en este nodo de transferencia por su propia cuenta o a través de un
objeto asociado, debe ser retenida durante el tiempo especificado en la expresión incluida como
propiedad. De esta manera, los procesos OnEntered y OnEnteredFromAssociatedObject
tendrán que ser modificados para incluir esta consideración. En este momento, los procesos no son
editables, como se puede apreciar si se selecciona el proceso OnEntered y viendo que las etapas y
los procesos tiene color gris. Después de seleccionar el proceso120, haga clic en el botón Override
( ), como se muestra a continuación, lo que permitirá realizar los cambios. Cuando se ha
modificado el proceso, el símbolo Override se coloca al lado del nombre del proceso para indicar
que ha sido modificado. Se puede utilizar el botón Restore ( ) para restablecer el proceso a su
estado original.
Figura 18.4: Cambiando y Restableciendo un Proceso Heredado
El proceso OnEntered es bastante complejo, y sigue las siguientes etapas:
 Inicie el evento Entered
 Compruebe si debe auto-transferirse, “Auto Transfer to an External Node” (se dan más
explicaciones un poco más adelante)
120
A través de la pestaña “Processes” se accede a todos los procesos.
 Si el nodo hace auto-transferencia, se transfiere la entidad hacia el nodo padre externo.
 En caso contrario, se ejecuta el proceso “EnteredAddOnProcess”, que puede ser especificado por el
usuario.
 Si la entidad está esperando a ser transportada, está aparcada o este nodo no es su nodo destino, sale
de este proceso
 Los nodos pueden tener una capacidad que debe ser apresada (típicamente, la capacidad es infinita).
 La etapa VisitNode se usa para invocar el proceso OnVisitingNode de la entidad, para

indicar que la entidad ha llegado al nodo de destino
 Si esta entidad es un transportador, entonces se transfiere a la conexión de salida, pues sigue una
lógica distinta.
 Si la entidad no es un transportador, se ejecuta el proceso RoutingOutLogic para transferir la

entidad hacia fuera del nodo, siguiendo la lógica correcta (usa la etapa “Route” junto con el
elemento ROUTINGGROUP).
Pregunta 1: ¿Dónde se debe incluir el retardo en este proceso?
Paso 2: En algunos casos, los usuarios pueden querer cambiar el tiempo de retardo en función de alguna
condición en el momento que entran en el nodo. Así, incluya una etapa Delay después de que se ejecute
el proceso “Entered” para permitir que el tiempo de retardo sea fijado en un proceso antes de que
verdaderamente ocurra el retardo. La propiedad Delay Time debería ser fijada en la referencia
DelayTime, cuyo valor podría ser calculado en la etapa anterior (Figura 18.5).121 En la sección
“General”, la propiedad Name puede ser especificada como “DelayTime” para tener una mejor
descripción.
Figura 18.5: Modificando el Proceso OnEntered Para Incluir un Retardo
Paso 3: Repita el procedimiento para el proceso OnEntereredFromAssociatedObject, y añada una

etapa Delay en el mismo sitio. Cuando el proceso haya sido modificado, copie y pegue la etapa en el
lugar apropiado del proceso.
Sección 18.3: Creando un Modelo Para Probar el Nuevo DELAYTRANSFERNODE
Ahora que el nuevo nodo ha sido creado, puede ser utilizado en cualquier modelo en el que el nodo
TRANSFERNODE original se use, con el beneficio añadido de que se consigue retrasar al objeto durante un
tiempo cuando entra en el nodo.
Paso 1: Vuelva al modelo original, seleccionándolo del panel Navigation.
121
Haga click con el botón derecho en la etiqueta de propiedades para especificar la propiedad como referenciada.

Figura 18.6: Volviendo al Modelo Original
El modelo (Figura 18.7) creará una entidad y la duplicará, enviando la original al nuevo nodo
DELAYTRANSFERNODE y la duplicación a un nodo TRANSFERNODE estándar. La variable tiempo en el sistema
se utilizará para ilustrar el comportamiento.
 Incluya una nueva MODELENTITY, de nombre Parts.
 Incluya una SOURCE, de nombre SrcParts que crea Parts.
 Añada un SEPARATOR, de nombre SepCopy, que se puede utilizar o bien para crear copias de
entidades o bien para separar entidades que han sido agrupadas utilizando un Combiner.
 Añada un nuevo DELAYTRANSFERNODE, de nombre TDelay, al que se puede acceder a través del
Project library.
 Añada un TRANSFERNODE, de nombre TNormal
 Añada un SINK, de nombre SnkExit.
 Conecte la fuente SrcParts con el separador utilizando un CONNECTOR.
 Conecte la salida del objeto padre a TDelay y la salida del objeto miembro a TNormal utilizando
TIMEPATHS, cada uno con una duración de 5 minutos.
 Conecte tanto TNormal como TDelay al sumidero con TIMEPATHS, cada uno con una duración de
10 minutos.
Figura 18.7: Modelo para Demostrar el Funcionamiento de DelayTransferNode
Paso 2: Configure todos los elementos fijos con los siguientes parámetros:
 SOURCE: Las entidades deben llegar con un tiempo constante entre llegadas de 5 minutos.
 SEPARATOR: La propiedad Separation Mode debe especificarse como “Make Copies” y la propiedad
Copy Quantity debe fijarse en “1” (Figura 18.8), de forma que se cree una copia de la entidad. Se
copiarán todas las propiedades de la entidad original. Sin embargo, el tiempo o momento de la
creación no tiene por qué coincidir con el de la original. La original sale del nodo ParentOutput
mientras que la copia sale del nodo MemberOutput.
Figura 18.8: Propiedades del Separador

Paso 3: Una nueva característica ha de ser añadida a la entidad Parts para controlar el tiempo en ciertos
puntos del sistema. Seleccione la entidad en la ventana Navigation y añada una nueva variable de estado
discreta, de nombre TimeClock, utilizando la pestaña “Definitions”. Se necesita una variable de estado
puesto que su valor irá cambiando durante la ejecución del modelo.
Paso 4: Añada una etiqueta de estado a la entidad de forma que se visualice la variable TimeClock.
Seleccione el objeto Parts y elija Status Label en la sección Symbols→Attached Animation. Dibuje una
etiqueta de estado cerca de la entidad con una expresión igual a TimeClock (Figura 18.9).
Figura 18.9: Creando una Etiqueta de Estado para Controlar el Estado de una Pieza
Paso 5: Dado que la etiqueta de estado va adjuntada a cada entidad, la etiqueta viajará junto a ella. Por ello,
rote (Ctrl→Mouse), dimensione y mueva la etiqueta de forma que se posicione justo encima de la
entidad (Figura 18.10).
Figura 18.10: Adjuntando la Etiqueta a una Pieza
Paso 6: Guarde el modelo y ejecútelo para comprobar que se comporta correctamente.
Pregunta 2: ¿Se duplica la pieza en el separador de forma correcta?
Pregunta 3: ¿Viaja la etiqueta de estado junto con la pieza? ¿Cuál es el valor de todas las etiquetas?

Paso 7: El valor de la variable de estado TimeClock no ha sido actualizado. En la pestaña Processes, cree un
nuevo proceso, de nombre SetTimeClock. Incluya una etapa Assign que calcula el valor de
ModelEntity.TimeClock como 60*TimeNow122 para obtener el valor del momento de la ejecución en
minutos.
Figura 18.11: Creando un Proceso Genérico Para Fijar la Hora en la Que Ocurre un Evento
Paso 8: Cuando las piezas salen del separador a través del objeto padre o del miembro, se necesita fijar la
variable TimeClock con el tiempo actual. Seleccione el nodo ParentOutput@SepCopy y especifique el
proceso SetTimeClock para el disparador “Exited”, para que se asigne el tiempo actual de simulación a
TimeClock. Realice la misma operación para el disparador “Exited” del nodo
MemberOutput@SepCopy.
Paso 9: Repita el proceso para los disparadores de “Entered” y “Exited” de los nodos de transferencia
TNormal y TDelay.
Paso 10: Guarde el modelo y ejecútelo. Observe los valores de las etiquetas cuando las entidades
dejan el separador así como los valores de entrada y de salida a los nodos de transferencia. Hubiéramos
pensado que los tiempos serían iguales ya que el tiempo de retardo es “0” y los tiempos entre llegadas y
de recorrido por los caminos son números enteros. Puede que sea bueno introducir una parada,
breakpoint, en uno de los nodos, y luego ejecutar un paso para que la entidad abandone un nodo de
transferencia.
Pregunta 4: ¿Son los tiempos de entrada diferentes para las piezas? ¿Por qué?
Parece que hay un pequeño tiempo de retardo en uno de los nodos de transferencia en comparación con
el otro. Las entidades entran en los nodos a la vez (en el minuto 5 en el lado izquierdo de la Figura
18.12) pero parece que salen en momentos algo distintos, como se muestra en el lado derecho de la
Figura 18.12. Sin embargo, los nodos de transferencia no ocupan espacio, y por tanto no debería haber
discrepancias entre los dos nodos. El momento en que una unidad entra en el nodo debería ser el mismo
que en el que sale.
122
TimeNow es una función que devuelve el valor del tiempo en horas en que se encuentra la ejecución.
Figura 18.12: Mostrando las Discrepancias Entre los Tiempos de Entrada y de Salida
La discrepancia viene determinada por el momento en que se dispara el proceso “Exited”. Este
evento no se ejecuta hasta que el borde trasero de la entidad ha dejado el nodo, lo que depende de la
longitud de la entidad y en cómo de rápido se mueve hacia la conexión (función de la velocidad de la
entidad y la del camino). El proceso “Entered” se ejecuta cuando el borde delantero de la pieza
entra en el nodo. Por eso, cuando se calculan etiquetas de tiempo, los procesos se deben disparar en
función sólo del borde delantero.
Paso 11: Fije el proceso “Exited” de los nodos TDelay y TNormal, así como las salidas de SepCopy
en null para desactivar los disparadores. Incluya el proceso SetTimeClock en los disparadores
“Entered” de cada uno de los caminos que salen de los nodos así como en el separador.
Paso 12: Guarde el modelo y ejecútelo para demostrar que las entidades están sincronizadas.
Pregunta 5: ¿Son los tiempos números enteros?
Paso 13: Especifique un tiempo de retardo de 4 minutos para TDelay y vuelva a ejecutar la
simulación. Cada pieza sufre ahora un retardo de 4 minutos antes de seguir su camino.
Paso 14: Cambie el tiempo entre llegadas a 2 minutos y observe qué pasa.
Pregunta 6: ¿Qué pasa cuando llegan muchas entidades al nodo?
 Los objetos derivados se crean en SIMIO haciendo subclases. Los objetos derivados añaden o
cambian las características y los comportamientos de los objetos existentes. En este capítulo, se
han añadido características que ayudan a incluir retardos en los nodos de transferencia.

Capítulo 19
Creando Nuevos Objetos: Objeto Delay bis
 Creando un nuevo objeto desde cero
 Usando estaciones, STATIONS
En el capítulo anterior, un nuevo objeto para retardar a las entidades fue creado, a partir de hacer una
subclase de un TRANSFERNODE estándar. Sin embargo, las entidades se apilaban en ese nodo unas encima de
otras. Tampoco había oportunidad de añadir un símbolo diferente para representar un lugar con retardo (un
horno, por ejemplo), dado que los nodos no ocupan espacio físico. En este capítulo, se creará un nuevo
objeto fijo que es similar a los objetos estándar y que pueden ser usados en otros modelos.
Sección 19.1: Creando un Nodo Delay Desde Cero
Paso 1: Abra el modelo del capítulo anterior.
Paso 2: Incluya en el proyecto un modelo del tipo “New Fixed Class”, utilizando la pestaña “Project Home”,
de nombre DelayObject123. Se puede usar el mismo icono del capítulo anterior o crear uno nuevo. Tener
muchos modelos en el mismo proyecto favorece la creación de submodelos. Por ejemplo, igual
necesitamos 50 máquinas que están compuestas por dos operaciones conectadas en tándem por una cinta
transportadora. Se podría crear un submodelo que tuviera todas las propiedades (2 SERVERS conectados
por un CONVEYOR) y entonces incluir este submodelo 50 veces en el modelo principal.
Para hacer el nuevo objeto DELAYOBJECT, inserte un elemento estación STATION ( ), de nombre
StationDelay. Se puede añadir un elemento STATION en un modelo desde el panel “Elements” de la
pestaña “Definitions”.
Los objetos que contienen o restringen el comportamiento de las entidades (SOURCES, SERVERS, NODES,
SINKS, COMBINERS, SEPARATORS, WORKSTATIONS, etc.) usan elementos STATION para albergar a las
unidades. El elemento STATION se puede usar para definir un lugar de capacidad limitada dentro de un
objeto, donde uno o más entidades pueden coincidir. La etapa Transfer se usa para transferir
entidades hacia dentro y hacia fuera de las estaciones, de forma similar a los nodos.
Los elementos STATION están incluidos en casi todos los objetos de la librería estándar
(Server.InputBuffer, Server.Processing, Server.OutputBuffer, Combiner.ParentInputBuffer,
Separator.MemberOutputBuffer, Workstation.Processing, Vehicle.RideStation,
TransferNode.ParkingStation, etc.)
Un elemento STATION tiene dos filas asociadas: una es la de procesamiento, Inprocess y otra la de
entrada, EntryQueue. EntryQueue. La segunda es la fila donde las entidades esperan hasta que hay
capacidad suficiente para acceder a la fila Inprocess. Si especifica que una operación tiene un
capacidad de proceso de 10 y llega la 11ª entidad, ésta será colocada en la fila de entrada, EntryQueue
(se mantendrá en el nodo de entrada de la operación).
La función que representa la ocupación de la fila de entrada a una operación,

Server.InputBuffer.Contents, ya ha sido utilizada para determinar el número de entidades
123
Haga clic con el botón derecho sobre el nuevo modelo en el panel Navigation para modificar sus propiedades.
que están esperando en la fila de entrada, así como la función que representa la ocupación de la fila de
procesamiento, Server.Processing.Contents. Las estaciones responden a tres eventos
distintos, como se muestra en la Tabla 19.1.
Tabla 19.1: Eventos en una Estación

Evento Descripción
Entered Se ejecuta cuando el borde anterior de las entidades
entra en la estación
Exited Se ejecuta cuando la entidad abandona la estación
CapacityChanged Se ejecuta cuando la capacidad de la estación cambia
Las propiedades de las estaciones se muestran en la Tabla 19.2.
Tabla 19.2: Propiedades de una Estación

Initial Capacity La capacidad de una estación Toma su valor en la propiedad
determina cuando las entidades Initial Capacity que fue
pueden entrar. heredada de la clase.
Entry Ranking rule Regla estática usada para ordenar FIFO, LIFO,
entidades dentro de la estación SmallestValueFirst,
LargestValueFirst
Dynamic Selection Rule Si se especifica, seleccionará de forma Se usa en la estación de
dinámica cuál es la siguiente entidad procesamiento de un SERVER
que va a entrar en la estación cuando
hay excedente de capacidad en la fila
ordenada según las reglas estáticas
Redirect Station Una estación auxiliar a la que se La estación correspondiente a
direccionan automáticamentelas la fila de entrada de un
entidades si la capacidad de la SERVER redirecciona a la
estación es 0. estación de procesamiento.
Paso 3: Especifique las propiedades de la estación según la Figura 19.1. Tiene que especificar también el
valor por defecto de la capacidad inicial en “Infinity”. Haga clic en la flecha descendente
correspondiente a las propiedades heredadas para cambiar el valor a infinito.
Figura 19.1: Especificación de una Estación

Paso 4: Añada la misma propiedad DelayTime de la misma forma que se hizo en el capítulo anterior,
asegurándose que la propiedad Unit Type se fija en “Time” y sus unidades en “Minutes” así como
incluir la nueva propiedad dentro de la categoría “Process Logic”.
Creando Nuevos Objetos: Objeto Delay bis 165

Paso 5: El elemento correspondiente a una estación con retardo garantiza que la entidad tiene sitio donde
estar cuando está sufriendo el retardo. Sin embargo, las entidades también necesitan una forma de entrar
y salir de DELAYOBJECT. La vista externa se utiliza para crear un interfaz visual así como para facilitar
nodos de entrada y salida al objeto. Vaya a la sección “External ” dentro de la pestaña “Definitions” para
crear el interfaz visual.
Paso 6: Se usa un diamante para representar la forma por defecto, aunque se puede especificar cualquier otro
símbolo. La forma debe centrarse en la cuadrícula. Haga clic en la herramienta para dibujar polígonos
(pestaña “Drawing”). Empiece en el punto (0,2) y arrastre hacia el punto (2,0). Cuando empiece a
arrastrar haga simplemente clic en los puntos (2,0), (0,-2), y (-2,0) (Figura 19.2). Cuando haga clic en la
última coordenada, haga clic con el botón derecho para completar el polígono. Fije la altura del objeto en
0.5 metros en la sección “Object” de la pestaña “Drawing”.
Figura 19.2: Creando la Vista Externa de un Objeto Delay
Paso 7: Añada un cuadrado amarillo al símbolo y una línea curva para dibujar la D. Dibuje varios puntos en
la línea curva, haciendo el último clic con el botón izquierdo en el mismo sitio donde empezó. Cambie a
3-D para colocar los dos objetos justo encima del techo del diamante (Figura 19.2124).
Paso 8: Añada los nodos ENTER y EXIT lo que proporciona el mecanismo para que los objetos llegan y
salgan del objeto delay. Haga clic en “External Node” de la sección “Transfers” de la pestaña
“Drawing” para añadir dos nodos externos en los extremos del diamante. Las especificaciones de los
nodos se muestran en la Tabla 19.3.
Tabla 19.3: Especificaciones de un Nodo Externo

Especificación Descripción
Node Class El tipo de nodo debe ser uno de los siguientes: Basic Node, Transfer
Node, Delay Transfer Node, etc.. Se usan típicamente los nodos de
transferencia como nodos de salida, dado que contienen la lógica
para direccionar entidades a su siguiente destino. Se suelen usar
nodos básicos como nodos de entrada.
Input Logic Type Tipo de localización en el que acaba la entidad una vez que entra en
el nodo (Process Station, FacilityNode). Si ha añadido objetos en la
ventana Facility y quiere transferir las entidades a uno de estos
nodos, seleccione FacilityNode.
Station La estación en la que acabará la entidad que está entrando, si se ha
elegido Process Station como Input Logic Type
Node El nodo en el que acabará la entidad que está entrando, si se ha
elegido Facility Node como Input Logic Type
124
Puede crear también un modelo en 3-D model en Google Sketchup que sirva como símbolo por defecto.
Paso 9: Incluya un nodo de llegada, de nombre InputNode, que debe ser un nodo básico, BASIC NODE.
Cuando las entidades entran en este nodo, queremos que sean enviadas automáticamente a
StationDelay. SIMIO lo hace de forma automática.
Figura 19.3: Especificando las Propiedades del Nodo Externo de Entrada
Paso 10: Incluya un nodo de llegada, de nombre OutputNode (Figura 19.4), que debe ser un nodo de
transferencia, TRANSFER NODE, dado que las entidades tendrán que ser transportadas a su nuevo destino.
Cuando las entidades salen de este nodo, queremos que sean transferidas fuera del objeto.
Figura 19.4: Especificando las Propiedades del Nodo Externo de Salida
Paso 11: A diferencia de DelayTransferNode, se ubican las unidades en la estación en una de sus
dos filas. Cuando las entidades entran en el objeto y son retardadas, la entidad puede ser visualizada en
una fila. Incluya una fila de animación encima del símbolo (elija Queue en la pestaña “Animation”). Se
debe asociar QueueState a la fila Contents de la estación StationDelay
(StationDelay.Contents).
Paso 12: Se han definido tanto las propiedades del objeto como su vista externa por defecto. Ahora,
es necesario especificar lo lógica que se va a usar para retardar a las entidades dentro del objeto. Cree un
nuevo proceso, de nombre OnEntered, y especifique el evento que lo dispara, que es
StationDelay.Entered, y que será ejecutado cada vez que una entidad entre en la estación,
STATION. La Figura 19.5 muestra las propiedades del nuevo proceso.
Figura 19.5: Especificando el Evento que Dispara el Proceso de Retardo
Paso 13: Recuerde que el nodo InputNode fue definido como para transferir automáticamente las
entidades a esta estación cuando llegan al nodo (por lo que se ejecutará el proceso OnEntered). La
Figura 19.6 muestra la lógica de este proceso.

Figura 19.6: La Lógica del Proceso OnEntered
 Lo primero que tiene que suceder es que la entidad tiene que acabar la transferencia hacia dentro de
la estación, utilizando una etapa EndTransfer. Este paso también dispara el evento
Transferred.
 Añada una etapa Delay de forma similar a lo realizado en el Capítulo 18, especificando
DelayTime como una propiedad referenciada.
 Cuando la entidad ha sufrido el retardo, necesita ser transferida desde DELAYOBJECT utilizando una
etapa Transfer (Figura 19.7). La entidad en este caso se transfiere hasta el nodo de transferencia
OutputNode, que es un nodo padre externo. El nodo de transferencia incluye toda la lógica para
enviar a la entidad hacia su próximo destino.
Figura 19.7: Propiedades de la Transferencia
Sección 19.2: Usando el Nuevo Objeto DelayObject
DELAYOBJECT puede ser usado ahora como cualquier otro de los objetos estándar de SIMIO. El mismo
modelo será usado para comparar DELAYTRANSFERNODE con DELAYOBJECT.
Paso 1: Vuelva al modelo principal y borre el nodo TNormal. Incluya un nuevo DELAYOBJECT, de nombre
DelOperation (Figura 19.8).
 Conecte la salida con DELAYOBJECT con un TIMEPATH de 5 minutos de recorrido.
 Conecte DelOperation al sumidero con un TIMEPATH de 10 minutos de recorrido.
 Fije el tiempo de retardo de DelOperation en 4 minutos.
 Especifique el disparador “Entered” de InputNode de DelOperation en el proceso SetTimeClock

para grabar el momento en que la entidad entra en el nodo. Repita este paso para el disparador
“Entered” del camino de salida para grabar el momento en que la entidad sale del nodo.

Figura 19.8: Modelo Revisado
Paso 2: Guarde el modelo y ejecútelo observando la diferencia entre el nuevo objeto y el nodo de
transferencia antiguo. Fije el tiempo entre llegadas en 2 minutos para ver las diferencias. Si sus entidades
están boca abajo en la fila, entonces la fila de animación en la vista externa fue dibujada en la dirección
equivocada (debería haber sido de derecha a izquierda).
Sección 19.3: Mejorando el Modelo con Disparadores Definidos por el Usuario
Muchos de los objetos permiten al usuario facilitar el procesamiento mediante la utilización de disparadores
de procesos (durante la inicialización, “Initialized”, cuando entra una entidad, “Entered”, cuando sale,
“Exited”, cuando empieza el procesamiento, “Processing”, cuando acaba, “Processed”, etc.) así como de
asignaciones de valores a variables de estado. Para hacer que un nuevo modelo se comporte de forma similar
a como lo hacen los objetos estándar, es necesario especificar también disparadores y asignaciones.
Paso 1: Seleccione DelayObject del panel [Navigation] y vaya a la sección Definitions→ Properties. Hay
que definir las propiedades asociadas con los disparadores de forma que el usuario las puedan
especificar. Se van a añadir cuatro disparadores (“Initialized”, “Entered”, “Exited”, y “Delayed”)
utilizando una propiedad denominada “Process” que se encuentra en “Element Reference”.
Paso 2: Añada la referencia “Initialized” con las siguientes propiedades, que serán ejecutadas al comenzar
una simulación. Para crear nuevos nombres de categoría basta con escribirlos en los recuadros
correspondientes.
Propiedad Valor
Name InitializedAddOnProcess
Display Name Initialized
Description Se ejecuta al inicializar el objeto
Category Name Add-on Process Triggers
Required Value False
Default Value Empty String
 Añada “Entered” con las siguientes propiedades, que serán ejecutadas en cuanto el objeto entra
en DELAYOBJECT.

Propiedad Valor
Name EnteredAddOnProcess
Display Name Entered
Description Se ejecuta en el mismo momento en el que se entra
en el objeto y antes del retardo
 Añada “Exited” con las siguientes propiedades, que se ejecutarán según el objeto salga de
DELAYOBJECT.
Propiedad Valor
Name ExitedAddOnProcess
Display Name Exited
Description Se ejecuta en el mismo momento en el que se sale del
objeto
 Añada “Delayed” con las siguientes propiedades que se ejecutarán cuando se haya acabado el
retardo.
Propiedad Valor
Name DelayedAddOnProcess
Display Name Delayed
Description Se ejecuta en cuanto se acaba el retardo
Category Name Add-On Process Triggers
Paso 3: Vuelva a la pestaña “Processes” e incluya una etapa Execute en el proceso OnEntered, lo que
permite que se ejecuten los procesos (Figura 19.9). Especifique que el proceso es una propiedad
referenciada EnteredAddOnProcess. La propiedad Action debe especificarse como
“WaitUntilCompleted”, lo que fuerza a que la ficha espere a que el proceso se complete antes de
continuar a la siguiente etapa.
Figura 19.9: Especificando los Disparadores Entered y Delayed

Paso 4: Después de la etapa Delay (Figura 19.9) del proceso OnEntered, incluya otra etapa Execute
para que se ejecute el proceso asociado con el disparador DelayedAddOnProcess con el mismo
valor de la propiedad Action.
Paso 5: Añada el proceso OnInitialized, que se define automáticamente para todos los objetos FIXED
CLASS cuando se selecciona la opción “Select Process”. Incluya una etapa Execute en el proceso
como antes pero especifique la propiedad InitializedAddOnProcess.
Paso 6: Cree un nuevo proceso, de nombre OnExited y especifique la propiedad TriggeringEvent como el
evento StationDelay.Exited. Incluya otra etapa Execute para que se ejecute el proceso según
la propiedad ExitedAddOnProcess definida por el usuario.
Figura 19.10: Añadiendo los Procesos OnInitialized y OnExited Process
Sección 19.4: Mejorando el Objeto Delay con Asignaciones
Los objetos estándar de SIMIO están dotados de la posibilidad de realizar asignaciones sin necesidad
de definir procesos. Estas asignaciones de valores a variables de estado se pueden añadir a nuestro
DELAYOBJECT.
Paso 1: Las asignaciones de variables de estados, state assignments, se especifican utilizando una propiedad
del tipo “repeating group” dado que el número de asignaciones puede variar. Añada una propiedad
Repeat Group, de nombre AssignmentsOnEntering, con propiedades según la Figura 19.11. Escriba
como nombre de categoría State Assignments, de forma que sea similar al nombre incluido en otros
objetos estándar.
Figura 19.11: Añadiendo una Propiedad “Repeating Group”

El grupo repetitivo permite especificar múltiples filas de un conjunto de propiedades (la variable de
estado y una expresión que calcule su valor).
Paso 2: Para crear las propiedades que pueden ser replicadas, seleccione primero la propiedad grupal
AssignmentsOnEntering, e incluya una nueva propiedad de estado State Standard Property, de nombre
AssignmentsOnEnteringStateVariableName, ya que la variable de estado se va a utilizar en las
asignaciones con las propiedades especificadas en la Figura 19.12.
Figura 19.12: Especificando una Propiedad de Variable de Estado
Paso 3: Incluya la expresión que especificará el nuevo valor que será asignado a la variable de estado.
Seleccione la propiedad grupal AssignmentsOnEntering, e incluya una nueva propiedad Expression
Standard Property, de nombre AssignmentsOnEnteringNewValue, con las propiedades especificadas
en la Figura 19.13.
Figura 19.13: Especificando la Propiedad “Expression Value” del Grupo
Paso 4: Repita el proceso para otra propiedad grupal, Repeat Group, de nombre
AssignmentsBeforeExiting, como se muestra en la Figura 19.14, lo que permite mostrar todas las
propiedades. Perciba cómo las propiedades grupales tienen su propia sección de propiedades.

Figura 19.14: Propiedades Asociadas con DELAYOBJECT
Paso 5: Una vez que se han definido las propiedades de Repeating Group, se pueden usar en las etapas
Assign. Incluya dos etapas Assign (Figura 19.15), para poder incluir las asignaciones “OnEntering”
y “BeforeExiting”. Se debe incluir una etapa Assign antes de la ejecución del proceso correspondiente
a la entrada de una entidad, y la otra justo antes de que se transfiera hacia fuera del nodo. En la Figura
19.15 se muestra cómo las propiedades se usan para especificar la propiedad Assignments.
Figura 19.15: Añadiendo Etapas Assign Para Ejecutar las Asignaciones
 Crear sus propios objetos puede mejorar sus modelos, que es una de las grandes ventajas de
SIMIO.
 Sin embargo, si sólo va a utilizar el objeto una única vez en un modelo, puede que no tenga
sentido perder el tiempo en crear el objeto de forma particularizada. La ventaja es que sí se
puede reutilizar el objeto en el mismo o en diferentes modelos.

Capítulo 20
Sistemas dentro de Sistemas: Una Célula de Fabricación
 Creando submodelos para poder reutilizarlos
 Usando una vista externa
En los capítulos previos, se ha explorado la posibilidad de ampliar SIMIO mediante la clonación de objetos
ya existentes (un TRANSFERNODE en el Capítulo 18) en otros objetos especializados (DELAYTRANSFERNODE)
así como la posibilidad de crear objetos totalmente nuevos (DELAYNODE en el Capítulo 19).
La posibilidad de ampliar o añadir nuevos objetos es una característica muy importante de SIMIO. Si
necesita una estación especializada para que se comporte como una máquina de coser, pero sólo necesita
una, es posible que no sea necesaria la creación de un objeto especial. Sin embargo, si va a utilizar las
máquinas de coser en muchos sitios del modelo, y puede que en modelos futuros, entonces, tener la
posibilidad de utilizar objetos reutilizables es muy importante. En este capítulo, exploraremos la posibilidad
de tener modelos dentro de otros modelos (submodelos).
Una operación de fabricación tiene 10 células de trabajo múltiples, en la que cada célula está compuesta por
2 máquinas que están conectadas por una cinta transportadora. Se necesita un operario para cargar las piezas
para que sean procesadas en la primera máquina y luego para descargarlas cuando haya acabado la operación
en la segunda máquina. El sistema de cintas transferirá automáticamente las piezas desde la primera máquina
a la segunda. Algunos de las máquinas pueden realizar operaciones en varias piezas en paralelo. Se da
prioridad a la descarga de piezas de la segunda máquina para garantizar que el tiempo total de proceso es
rápido.
Sección 20.1: Modelo de Una Célula
Antes de hacer un modelo más grande, es mejor crear primero un modelo de una célula. Eventualmente, este
modelo simple se convertirá en un bloque o submodelo para crear el modelo de la planta entera.
Paso 1: Cree un nuevo proyecto en SIMIO. Cambie el nombre del modelo a WorkCell, cambiando Model
Name en Model Properties.
Paso 2: Construya un modelo de acuerdo con lo presentado en la Figura 20.1.
Figura 20.1: Modelo Inicial de Dos Máquinas

 Añada 2 SERVERS, de nombre SrvMachineA y SrvMachineB. El tiempo de proceso debe ser 4
y 3 minutos respectivamente.
 Conecte las dos máquinas con una cinta de 5 metros y una velocidad de 2.5 metros por minuto.
 Añada 1 MODELENTITY, 1 SINK y 1 SOURCE que genera una llegada cada 6 minutos. No se
preocupe de los nombres, pues no serán los definitivos.
 Conecte la fuente a la entrada de SrvMachineA y la salida de SrvMachineB con TIMEPATHS de
10 minutos de duración.
Paso 3: Guarde el modelo y ejecútelo para asegurarse de que las entidades fluyen de forma correcta.
Paso 4: Se necesita un operario para cargar las piezas en la primera máquina, lo que habitualmente le lleva 1
minuto. También se necesita que el operario descargue las piezas de la segunda máquina, lo que le lleva
habitualmente 0.5 minutos. Incluya 1 RESOURCE, de nombre ResOperator. Añada un símbolo adicional
para indicar cuándo está trabajando, y coloree el iris del símbolo de color verde.
Paso 5: Añada el disparador “Processing” en la Máquina A para que aprese al operario, lo retarde durante
un tiempo, y después lo libere. Esta secuencia representa cómo se carga la Máquina A, lo que debe
realizarse antes de que se procese la pieza.
Figura 20.2: Lógica Para Apresar y Liberar un Operario en la Máquina A

Paso 6: La propiedad Delay Time de la etapa Delay debe ser una propiedad referenciada. Haga clic con el
botón derecho en Delay Time y cree una nueva propiedad, de nombre LoadDelayTime.
Figura 20.3: Especificando una Propiedad Referenciada como Tiempo de Retardo

Paso 7: Repita el proceso para la descarga de piezas de la Máquina B, SrvMachineB. La única diferencia es
que el nombre de la propiedad debe ser UnloadDelayTime y que el disparador es “Processed”
(SrvMachineB_Processed). Cuando se haya creado el proceso, copie y pegue las etapas de
SrvMachineA_Processing y cree una nueva propiedad referenciada para Delay Time.
Paso 8: Abra la pestaña “Definitions”, cambie Category de las dos nuevas propiedades a “Process Logic” y
fije Default Unidades en “Minutes.” El valor por defecto debe ser fijado en 1 minuto para
LoadDelayTime y 0.5 minutos para UnloadDelayTime.
Paso 9: Guarde el modelo y ejecútelo comprobando que funciona como debe.
Sección 20.2: Creando un Submodelo
Dado que se ha creado un submodelo que funciona correctamente, es necesario también crear su vista
externa antes de que pueda ser utilizado en otros modelos.
Paso 1: Borre SOURCE, SINK y MODEL ENTITY de este modelo, dado que lo que necesitamos probar es la
lógica de conexión entre las dos máquinas utilizando la cinta transportadora.
Paso 2: Vaya a la pestaña “Definitions” dentro del panel External y añada dos nodos externos, de nombre
InputNode (BASICNODE) y OutputNode (TRANSFERNODE). Incluya un símbolo entre los nodos o cree
una caja roja de 0.5 metros de altura.
Sistemas dentro de Sistemas: Una Célula de Fabricación 175

Figura 20.4: Vista Externa del Objeto WorkCell
Paso 3: El nodo de entrada InputNode debería ser una copia del Node Class de BASICNODE. Generalmente,
las entidades se transfieren desde el nodo de entrada a una estación. Sin embargo, el submodelo no tiene
una estación, por lo que serán transferidas a la entrada de la operación SrvMachineA. La propiedad
Input Logic Type debe ser “FacilityNode” y el nodo Input@SrvMachineA (Figura 20.5). Cuando las
entidades fluyen hacia InputNode de WorkCell, son dirigidas inmediatamente hacia SrvMachineA.
Figura 20.5: El Nodo de Entrada

Paso 4: El nodo de salida es una copia de la clase TRANSFERNODE para permitir que las entidades sean
direccionadas hacia sus destinos una vez que dejan WorkCell (Figura 20.6).
Figura 20.6: El Nodo de Salida

Paso 5: Añada 4 filas de animación para el nuevo objeto (pestaña “Animation”). Una fila animada es para
representar las entidades que están esperando, SrvMachineA.InputBuffer.Contents, y otras
dos para las filas de procesamiento de las máquinas (SrvMachineA.Processing.Contents y
SrvMachineB.Processing.Contents). Finalmente, la última sirve para mostrar los contenidos
de la fila de salida de SrvMachineB (SrvMachineB.OutputBuffer.Contents).125
Figura 20.7: Vista Externa Con las Cuatro Filas
125
Dibuje las filas de derecha a izquierda porque el primer punto que se dibuja es la cabeza de la fila.
Las entidades que entran el nodo externo de salida de WORKCELL serán automáticamente transferidas a la
entrada de SrvMachineA. Cuando las entidades llegan al nodo de salida de SrvMachineB, se necesita
direccionarlas al nodo externo OutputNode que se ha definido en la vista externa. Vuelva a la pestaña
“Facility” y seleccione el nodo Output de SrvMachineB (Output@SrvMachineB). En la categoría
General, cambia la propiedad Auto Transfer on Entry a la opción “To Parent External Node” especificando
OutputNode como el nombre del nodo externo.
Las entidades serán transferidas directamente al nodo externo OutputNode, una vez que acaban en
SrvMachineB.
Figura 20.8: Conectando el Nodo Externo

Paso 6: Guarde el Modelo.
Sección 20.3: Creando un Modelo Utilizando el Submodelo WorkCell
Se ha creado el submodelo WORKCELL y puede ahora ser guardado en una librería y utilizado en cualquier
otro modelo en SIMIO. Vamos ahora a crear nuestro sistema de fabricación utilizando el submodelo
WORKCELL.
Paso 1: En la pestaña Project Home, cree un nuevo modelo del tipo “Fixed Class”.
Paso 2: En el nuevo modelo, incluya 1 SOURCE, de nombre SrcParts, 1 SINK, de nombre SnkExist, y una
nueva célula, de nombre Cell1, a partir del panel Project Library. Conecte la fuente y el sumidero a la
célula con TIMEPATH de 10 minutos de duración (Figura 20.9).
Paso 3: Haga que la llegada de piezas corresponda con un modelo exponencial de media 5 minutos.
Figura 20.9: Modelo de Simulación Basado en el Submodelo WorkCell

Paso 4: Para Cell1, asegúrese que la propiedad LoadDelay es 1 minuto mientras que la propiedad
UnloadDelay es 0.5 minutos.
Paso 5: Guarde el modelo y ejecútelo durante un período de 24 horas y mire los resultados. Las estadísticas
de todas las piezas de la célula son visibles.
Pregunta 1: Desde el punto de vista de la animación, ¿qué observa cuando las piezas acaban en la
Máquina A y están siendo llevadas a la Máquina B?

Sección 20.4: Añadiendo el Objeto WorkCell
Ahora mismo, la entidad está escondida no sólo cuando está en la cinta sino en cualquier otro momento que
no está animado. A pesar de que la animación interna del submodelo no se muestra, podemos enseñar algo
del comportamiento interno si colocamos etiquetas que muestren el número de entidades en varios sitios. Sin
embargo, también nos gustaría saber el número de piezas que se están procesando en la máquina A o B así
como en la cinta o en la fila de entrada de la Máquina B.
Paso 1: SIMIO da la posibilidad de definir almacenes (filas) por parte del usuario. Seleccione el modelo
WorkCell y vaya a la pestaña “Definitions”. En la sección “Elements”, incluya un nuevo almacén
“STORAGE”, de nombre WorkCellInProcess. Podemos dejar la regla de ordenación por defecto, que es
FIFO, “FirstInFirstOut”.
Paso 2: Hay dos etapas de proceso (Insert y Remove) que pueden ser utilizadas para manipular estos
almacenes definidos por el usuario.126 Una vez que la pieza empieza a ser procesada en SRVMACHINEA,
debe ser también incluida en el almacén WorkCellInProcess para indicar que está siendo procesada.
Añada una etapa Insert después de que el operario haya sido liberado, mediante la inclusión de
WorkCellInprocess.Queue en la propiedad Queue State Name. La propiedad Object Type debe
seguir siendo “AssociateObject” puesto que la ficha sigue asociado con la pieza.127
Figura 20.10: Usando una Etapa Include para Añadir Piezas a un Almacén Definido por el Usuario
Paso 3: Una vez que la pieza ha sido procesada y sale de la máquina, elimine la pieza del almacén utilizando
una etapa Remove (Figura 20.11).
Figura 20.11: Usando una Etapa Remove para Eliminar Piezas del Almacén Definido por el Usuario
126
Estas etapas no funcionan con filas definidas en SIMIO (lo que es una limitación importante).
127
La propiedad Rank Placement se puede utilizar para especificar el lugar en el que colocar a la entidad en el almacén, ignorando
entonces la regla general de ordenación.
Paso 4: Vaya a la sección “Definitions→External” del objeto WorkCell y añada otra fila animada por
encima del objeto que sirve para animar, WorkCellInProcess.Queue (igual quiere borrar las filas
Processing.Contents que fueron incluidas con anterioridad).
Paso 5: Vuelva al modelo principal e inserte de forma manual una fila animada para Cell1,
Cell1.WorkCellInProcess.Queue. No aparecerá ningún cambio en la vista externa para los
objetos antiguos.
Paso 6: Para ver que el modelo funciona correctamente, incluya 5 símbolos adicionales para las piezas,
coloreando cada una con uno color diferente. Fije la propiedad Animation→Random Symbol de las
piezas como “True.” Cambie el tiempo entre llegadas a 2, según un modelo exponencial.
Paso 7: Guarde el modelo y ejecútelo, observando que las piezas se mueven incluso cuando están en la cinta.
Sección 20.5: Mostrando Propiedades Resource y Capacity
Actualmente el operario también está escondido dentro de WORKCELL y no puede recibir información sobre
turnos de trabajo. También está escondida la capacidad y el tiempo de proceso de las dos máquinas.
Paso 1: Vuelva al modelo WORKCELL y seleccione el recurso ResOperator. Todos los modelos tienen
propiedades de tipo de capacidad, capacidad, regla de ordenación así como de reglas dinámicas de
selección. A ResOperator hay que asociarle las propiedades a las correspondientes de WorkCell.
Seleccione ResOperator y asocie sus propiedades a las de WorkCell (Figura 20.12). Cuando el usuario
especifica las propiedades de WorkCell, las de ResOperator tomarán el mismo valor.
Figura 20.12: Mostrando las Propiedades de un Recurso al Usuario

Paso 2: Cree una propiedad referenciada para la propiedad ProcessingTime de cada uno de las dos
operaciones, de nombre MachineAProcessingTime y MachineBProcessingTime, respectivamente, y
otras para la propiedad Initial Capacity, de nombre MachineAInitialCapacity y
MachineBInitialCapacity.
Paso 3: En la sección “Definitions→Properties”, incluya las nuevas propiedades en la categoría “Process

Logic”, y fije las unidades por defecto del tiempo de proceso en minutos.
Paso 4: Vuelva al modelo principal, asegurándose de que fija el tiempo de procesos de las dos máquinas en 4
y 3 minutos respectivamente.
Paso 5: Guarde el modelo y ejecútelo observando que nada ha cambiado.
Paso 6: Si sólo fuera a incluir una célula, no parece apropiado emplear el tiempo en crear un submodelo. Sin
embargo, el beneficio de un modelo está en su reutilización continuada, sin tener que rehacer la lógica
del proceso o establecer las propiedades. Otro beneficio estriba en que si la lógica cambia o se necesitan
capacidades adicionales, sólo es necesario incluir los cambios en un único sitio.

Paso 7: Incluya dos nuevos objetos WORKCELL, de nombre Cell2 y Cell3, con el mismo tiempo de proceso de
4 y 3 minutos, pero cambie las capacidades de cada máquina a 2. Fíjese en que se añade
automáticamente una fila animada.
Paso 8: Conecte la fuente y el sumidero con TIMEPATHS de 5 minutos a estas nuevas células y cambie el
ritmo de llegada a dos piezas por minuto.
Paso 9: Guarde el modelo y ejecútelo, observando los resultados.
Paso 10: Ahora cree un Data Schedule, de nombre SchedCell, que tiene un horario de un día en el
que se alternan períodos de 3 horas ociosas, “Off Shift”, y 3 horas ocupadas, “On Shift”. La capacidad
de un período “On Shift” debe ser de 4. Seleccione las tres células y especifique Capacity Type para que
cumpla el horario, WORKSCHEDULE, con la propiedad Work Schedule fijada en SchedCell.
Figura 20.13: Especificando los Horarios de los Centros de Trabajo

Pregunta 2: ¿Qué sucede con las piezas que están en proceso cuando cambia el turno?
 La idea que hay detrás de los submodelos es que uno puede crear su propia clase de objetos.
Cuando se crea una clase, se puede utilizar los objetos nacidos de esa clase muchas veces en el
mismo proyecto o en muchos proyectos diferentes.

Capítulo 21
Más Sobre Submodelos: Una Línea de Camisas
 Haciendo subclases de objetos utilizando un vehículo
 Creando vehículos cuando sean necesarios
 Sistemas continuos de cintas transportadoras
Existen muchos ejemplos en fabricación en que las piezas dan vueltas en un sistema circular esperando a que
haya un sitio libre para ser procesadas. Como ejemplo ilustrativo, un fabricante produce camisas de manga
larga que necesitan pasar por más de 30 estaciones de cosido antes de que se obtenga una unidad. La camisa
pasa entonces por una plancha automática y después se coloca en un sistema de cintas transportadoras donde
esperan dando vueltas a ser dobladas manualmente de una en una por una persona. Las camisas giran sobre
28 bandejas que están espaciadas de forma uniforme. Este sistema asegura que no se arruguen las camisas
recién planchadas, aunque vayan más de una en la misma bandeja. En este capítulo se exploran las
posibilidades de usar un vehículo, que es uno de los objetos más complicados debido a sus múltiples
opciones pensadas para cubrir situaciones muy diversas.128 Crear el circuito cerrado de bandejas va a
plantear desafíos importantes.
Sección 21.1: El Modelo del Sistema
Paso 1: Cree el modelo que contiene el sistema de bandejas, de forma que contenga 4 estaciones de doblado
(Figura 21.1). Incluya 1 SOURCE (SrcPress), 1 SINK (SnkExit), 1 TRANSFERNODE (TStart), 4 SERVER
(SrvFold1, SrvFold2, SrvFold3, y SrvFold4) y 1 MODEL ENTITY (Shirts).
Figura 21.1: El Modelo del Circuito Cerrado
128
Por ejemplo, se pueden modelizar autobuses que siguen una ruta, taxis que dan vueltas o esperan a ser llamados, u otros como
transpaletas.
Más Sobre Submodelos: Una Línea de Camisas 181

 Para las operaciones SrvFold3 y SrvFold4, cambie los nodos de entrada y de salida, InputNode y
OutputNode, de forma que sean posicionados en el interior para que formen un circuito.
 Seleccione las cuatro operaciones y fije las unidades del tiempo de proceso en horas y utilice la
distribución por defecto del tiempo de proceso.
 La plancha es capaz de producir una camisa cada 2 minutos.
 Cree un circuito interior con CONVEYORS que tengan una velocidad deseada de 10 metros por minuto.
Cada segmento debería tener una distancia de 10 metros.
 Use PATHS para conectar las salidas de cada SERVER con el SINK.
Paso 2: Guarde el modelo y ejecútelo observando qué pasa.
Pregunta 1: ¿Qué sucede cuando las entidades llegan a la primera máquina de doblado?
Paso 3: Las camisas se procesan siempre en la primera máquina. Deberían continuar hasta que llegan a una
máquina disponible. No es posible determinar qué máquina doblará una camisa después de la operación
de planchado, esto es, cuando la entidad entra en el circuito de cintas. Cuando una entidad entra en el
nodo de entrada de una máquina, SERVER, si la máquina está disponible ha de ser procesada, pero si la
máquina está ocupada, debe dirigirse a la siguiente.
 Cree un disparador para el proceso “Entered” de Input node de SrvFold1 (Figura 21.2).
 Incluya una etapa Decide para comprobar si se está procesando alguna camisa
(SrvFold1.Processing.Contents==0).
 Si es cierto, la entidad seguirá el comportamiento normal y entrará en la máquina.
 En caso contrario, la máquina de doblado está ocupada y la entidad debe seguir por el circuito.
Incluya una etapa TRANSFER que fuerce a la entidad a ser movida desde su nodo hacia la conexión de
salida (continuar hacia el siguiente SERVER).
Figura 21.2: Forzando a que una Entidad se Salte un Nodo.

Paso 4: Repita el proceso para las 3 máquinas restantes. La forma más fácil es crear los disparadores y luego
copiar y pegar las etapas, modificando solamente la condición para que refleje la máquina adecuada.

Paso 5: Guarde el modelo y ejecútelo. Las entidades continuarán así su camino hasta que encuentren una
máquina disponible y puedan ser procesadas.
Paso 6: Para verificar el proceso, podemos añadir 5 o 6 símbolos adicionales con colores diferentes.
Incremente la variable de estado correspondiente a la imagen en 1 cada vez que la entidad entra (proceso
“On Entering”) en la cinta situada después de la operación SvrFold4.
Sección 21.2: Usando un Vehículo para Mover las Camisas a los Puestos de Doblado
En el sistema real, las camisas van en una bandeja sobre la cinta transportadora. Dan vueltas hasta que algún
operario coge una camisa de la bandeja. Las bandejas van a ser modelizadas como un vehículo129.
Paso 1: El objeto VEHICLE tiene ciertas limitaciones para este problema en particular y necesita ser
modificado. Haga una subclase 130 del objeto VEHICLE para facilitar la creación de un vehículo
especializado según nuestra situación.
Paso 2: Seleccione MYVEHICLE en el panel Navigation. A partir de la pestaña ” Definitions”, sección

“External”, incluya el símbolo del vehículo de la librería (usando el desplegable “Place Symbol” dentro
de la banda). A partir de la pestaña “Animation”, incluya una fila animada y fije la propiedad Queue
State en RideStation.Contents, lo que va a permitir que se puedan ver las camisas que se están
moviendo (Figura 21.3).131
Figura 21.3: Añadiendo una Vista Externa a la Nueva Clase

Paso 3: Incluya un nuevo MYVEHICLE en el modelo para representar a las bandejas, de nombre FormVeh,
utilizando la librería.
 Para FormVeh, fije su capacidad en 1 y el número inicial en el sistema (en la sección “Dynamic
Objetos”) en 0 para permitir una distancia constante entre las bandejas en el sistema de cintas.
 Fije la propiedad Initial Node en el nodo de transferencia TStart.
 Se debe fijar la propiedad Routing Type en “On Demand” con Idle Action igual a “Roam”, lo que
hace que los vehículos se muevan continuamente.
Paso 4: Incluya una nueva SOURCE, de nombre SrcFrm, fijando Entity Type en FormVeh.
 Conecte la fuente al inicio de TStart con un CONNECTOR.
129
Un objeto WORKER se podía haber utilizado también. De hecho WORKER es una super clase de VEHICLE.
130
Haga clic con el botón derecho en la clase del objeto y luego en “Subclass”.
131
Recuerde que al apretar la tecla Shift, se permite cambiar la altura del símbolo.

 El número máximo de llegadas debe ser 2, con un tiempo entre llegadas de 2.5 minutos.
Paso 5: Para el nodo de transferencia TStart, especifique que las camisas necesitan un transportador para ir
a un puesto de doblado, incluyendo las siguientes propiedades.
Figura 21.4: Fijando el Nodo para Forzar a que las Camisas se Muevan en Vehículos
Paso 6: Elimine cualquier asignación referente a múltiples dibujos que haya en la cinta que sigue a
SvrFold4.
Paso 7: Guarde el modelo y ejecútelo para observar qué sucede. Dado que los vehículos son un tipo de
entidad, el proceso Entered creado con anterioridad para redirigir a las camisas si la estación estaba
ocupada, también funciona para los vehículos.
Pregunta 2: ¿Qué pasa cuando los puestos se llenan?
Pregunta 3: ¿Alguna idea de por qué sucede esto?
El problema estriba en que el sistema se bloquea y no puede resolverse con la lógica actual. El
problema surge cuando un vehículo con una camisa llega al nodo TStart. Dado que la pieza tiene como
Destination Type el comando “Continue” y no existe lógica para que no continúe, la entidad es
descargada por el vehículo pero la entidad se atasca en el nodo de transferencia. La entidad no puede ir
a ningún sitio porque se supone que debe ir en un vehículo y el proceso del vehículo no puede acabarse.
Se produce un bloqueo irreversible.
Para resolver el problema, el vehículo no debería descargar las entidades en el nodo TStart. Tampoco
un vehículo puede saltarse el nodo porque tiene que cargar las camisas planchadas que hay que llevar a
los puestos de doblado.
Paso 8: Incluya un disparador Entered en TStart para hacer que el vehículo se salte el nodo en el caso en
que el vehículo ya lleve una camisa. Añada 2 etapas Decide y copie la etapa Transfer de uno de los
otros procesos Entered, como se muestra en la Figura 21.5. La primera etapa Decide utiliza el
operador Is para comprobar si es un vehículo el que entra en el nodo. Si es MYVEHICLE, entonces se
comprueba si va cargado con una camisa, RideStation.Contents. En caso afirmativo, se manda
al vehículo a la salida directamente.

Figura 21.5: Haciendo que los Vehículos se Salten el Nodo
Pregunta 4: ¿Entra el sistema en bloqueo?
Sección 21.3: Permitiendo Llevar Varias Piezas
El modelo actual funciona correctamente y los vehículos dan vueltas cargando camisas planchadas y
dejándolas en los puestos de doblado que están libres. Sin embargo, se podría llevar más de una camisa por
vehículo, mientras que ahora sólo una puede ser cargada, sólo una transportada y sólo una descargada.
Paso 1: Seleccione VehForm y cambia la propiedad Ride Capacity a 4.
Paso 2: Guarde el modelo y ejecútelo, observando el modelo durante un par de horas.
Pregunta 5: ¿Funciona el sistema como se pretendía? ¿Llevan los vehículos más de 1 camisa?
Pregunta 6: ¿Carga el vehículo las camisas en TStart si lleva alguna, pero menos de 4?
Paso 3: La lógica de procesos hace que el vehículo no entre en el nodo TStart si lleva camisas, por lo que no
parará si lleva alguna. Además, una bandeja vacía cargará y dejará más de una camisa, que no es lo que
queremos. Seleccione MyVehicle en el panel Navigation para modificar el comportamiento por defecto
de los vehículos.
Paso 4: Primero, evitemos que el vehículo deje todas las camisas en un puesto. Dado que un objeto no sabe
nada sobre el modelo que lo está usando, añada una nueva variable de estado discreta, de nombre
DontDropoffNodeID, que ayude a impedir que se descarguen todas las unidades. Advierta que ésta no
es una referencia a un nodo sino un ID numérico asociado a un nodo. Cada objeto en SIMIO tiene un ID
y SIMIO proporciona una función ID para acceder a él (por ejemplo, SrvFold1.ID).
Paso 5: Vaya a la pestaña Processes y vea los numerosos procesos utilizados para modelizar el
comportamiento complejo de los vehículos. El proceso OnVisitingNode se ejecuta cada vez que un
vehículo entra en un nodo y es el proceso más complicado de cualquier objeto de SIMIO. Desactive el
proceso de forma que pueda ser modificado. Se desactiva un proceso haciendo clic en el proceso y luego
en el botón en la banda. Los pasos básicos para modificar este proceso se describen a
continuación:

 Se comprueba si el vehículo ha llegado al nodo correcto (zona de descarga, de carga, o reclamado
como recurso) si es que uno ha sido especificado.
 Se compruebe si el vehículo ha llegado a un nodo porque ha sido reclamado y está atendiendo la

petición. Si es así, se dice a la entidad que el vehículo ha llegado al nodo correcto y se espera hasta
que el vehículo es liberado.132
 Se entra en el rutina para descargar entidades; si falla o no hay más entidades, se sigue con la carga
(la descarga se realiza antes que la carga en los nodos).
 Se entra en la rutina para cargar entidades que hayan solicitado los servicios del vehículo.
 Se decide si es un vehículo con una ruta fijada (por ejemplo, un autobús); si es así, se dirige hacia el
próximo destino y sale del nodo.
 Si su ruta no está fijada, se selecciona el siguiente punto de descarga si está transportando entidades
en función de las reglas de ordenación y sale del nodo.
 Si no hay entidades que descargar, se libera al vehículo para que pueda planificar su siguiente visita.
 Si no hay nada que cargar ni descargar, se decide dónde debe aparcar.
 Si el vehículo está siempre en movimiento, o bien sale del nodo o bien espera hasta la siguiente
petición.
Paso 6: Si el nodo que se está visitando es el nodo en el que no se puede descargar, DontDropoffNodeID,
entonces no se puede permitir que haya descargas, pero sí que se pueda cargar entidades. El objetivo es
incluir una etapa Decide antes de la etapa Dropoff. Sin embargo, esto complica la lógica. La forma
más fácil es colocar una nueva etapa Decide entre Dropoff y Wait. Seleccione la etapa Decide
que se encuentra a la parte asociada con la comprobación de si hay entidades que deben ser descargadas.
Mueva la rama True para que corresponda con la nueva etapa Decide. La etapa Dropoff puede
moverse ahora a la derecha de la nueva etapa Decide (Figura 21.7). Especifique que en la etapa
Decide se va a comprobar si CurrentNodeId no es igual que DontDropoffNodeID.
Figura 21.6: Propiedades de la Etapa Decide en el Nodo Don’t Drop Off

Paso 7: La rama False de la nueva etapa Decide debe continuar con la etapa Pickup; alargue el nodo
End.
132
Como se ha mencionado en un capítulo anterior, y mencionado en el nodo OnVisit, los vehículos responden a las etapas
Seize antes de atender a las llamadas para cargar o descargar.
Figura 21.7: Modificando el Proceso OnVisitingNode
Paso 8: Vuelva al modelo principal y borre el disparador “Entered” del nodo TStart, fijando en “null” su
valor.
Paso 9: Si se ejecuta el modelo, la situación de bloqueo volverá a aparecer porque el vehículo no ha sido
informado sobre la imposibilidad de descarga en el nodo correspondiente. En la fuente SrcFrm, utilice
las asignaciones Before Exiting para asignar el valor ID de TStart al vehículo que acaba de ser creado.
Figura 21.8: Asignando el ID del Nodo TStart al Vehículo

Pregunta 7: ¿Recoge el vehículo ahora camisas incluso si ya lleva alguna (puede que necesite alargar la
fila del vehículo para ver más de dos camisas)?
Pregunta 8: ¿Carga en algún momento más de una camisa a la vez? ¿Descarga todas a la vez en el primer
puesto disponible?
Sección 21.4: Permitiendo Una Carga y Una Descarga Cada Vez
Se carga más de una camisa y también se descarga más de una en cada puesto disponible. El vehículo por
defecto está diseñado para descargar y cargar varias entidades en función de su capacidad según la rutina del
proceso OnVisited.
Paso 1: Tanto la secuencia de carga como la de descarga tienen una etapa Decide que permite al vehículo
seguir descargando o cargando hasta que una etapa falla (no se puede descargar o cargar).
Existen tres posibilidades para forzar a que sólo se pueda descargar una entidad cada vez.

1. Haga que tanto las ramas “true” y “false” vayan directamente a la etapa Pickup. Seleccione la
etapa Decide y agarre el final de la rama “true”y posiciónela sobre la etapa Pickup.
2. Borre la etapa Decide y haga que la etapa Wait se una directamente con la etapa Pickup. Si
sigue esta opción, primero mueva la etapa Decide a la izquierda de la etapa Wait y luego mueva
la rama desde la etapa Wait a la etapa Pickup.
3. Fije la propiedad Exclusion de la etapa Decide en el valor “2”, lo que hará que se evite la etapa y
se elija la rama “false” todas las veces.
Figura 21.9: Modificando el Vehículo Para Dejar Sólo Una Entidad

Paso 2: Repita el proceso para la etapa Decide en la línea Pickup-Wait-Decide.
Paso 3: Guarde el modelo y ejecútelo, observando que sólo se carga o descarga una entidad cada vez.
Sección 21.5: Haciendo que la Animación Sea la Correcta
Existen más de 20 bandejas en el circuito continuo del sistema real.
Paso 1: En la fuente SrcForm, incremente el número de bandejas en el sistema a 20 con un tiempo entre
llegadas de 0.25 minutos. Dado que las cintas se mueven a una velocidad constante de 10 metros por
minutos y tienen una longitud de 10 metros, el ritmo de llegadas debería espaciar convenientemente las
bandejas a lo largo del sistema. Puede querer reducir también el tamaño de los vehículos.
Pregunta 9: ¿Observa alguna anomalía en el sistema o al menos en la animación (mueve mucho

SrvFold1 hacia la derecha)?
Paso 2: Desde el punto de vista estadístico, el sistema se comporta de forma correcta, pero desde el punto de
vista visual, parece que los vehículos en alguno de los segmentos del circuito se mueven a velocidades
distintas. El problema estriba en que el circuito cerrado ha sido modelizado con 5 segmentos. Incluso si
el alineamiento de las celdas estuviera fijado en un número de celdas, esto sólo cubre un único
segmento. Los segmentos individuales implican anomalías adicionales según las bandejas cambian de un
segmento a otro, dado que habrá veces que las bandejas tengan que esperar en un nodo a una celda de
animación. Esta acción puede causar acumulaciones. El problema en la animación aparece porque se
están utilizando longitudes lógicas en lugar de las distancias verdaderas.
 Los servidores, SERVERS, se deben colocar cuidadosamente de forma que la entrada de SrvFold1 se
encuentre cerca del punto (0, 0) mientras que las entradas de SrvFold2, SrvFold3, y SrvFold4
deben colocarse cerca de los puntos (0, -10), (-10, -10) y (-10, 0).
 Seleccione el InputNode de SrvFold3; en la sección “General” dentro de las propiedades, abra la

propiedad Size and Location para especificar la dimensión X como –10, la dimensión Z como –10 y
la dimensión Y como 0 (Figura 21.10). La dimensión Y especifica la posición en 3-D (la altura sobre
el nivel del suelo). Normalmente la tercera dimensión es Z, pero no en SIMIO, que es Y.
Figura 21.10: Especificando la Posición Exacta

 Repita este proceso para cada una de los puesto de doblado restantes, utilizando el posicionamiento
exacto (la dimensión Y es 0, todos los objetos en el suelo en 3D).
 Para el nodo TStart, especifique la dimensión X como -5, la dimensión Z como 8.66025 y la
dimensión Y como 10, lo que hará que TStart se sitúe a 10 metros de SrvFold1 y SrvFodl4.
Paso 3: Guarde el modelo y ejecútelo, observando que la animación se comporta correctamente con una
separación constante entre bandejas.
 Modificar los objetos vehículo y trabajador ha sido un ejercicio apasionante porque fueron
diseñados para incluir comportamientos muy complejos. Sin embargo, si se pueden comprender
en toda su extensión, se va a encontrar muy a gusto cuando modifique los objetos estándar.
 Para que la animación se asemeje a la realidad, encontrará que es necesario incluir distancias. La
animación de SIMIO está diseñada para ser precisa desde el punto de vista dimensional.

Capítulo 22
Más Subclases: Modelización Avanzada de Cadenas de
Suministros
 Más sobre hacer subclases de objetos.
 Modificación de procesos existentes.
 Usando las etapas Create y Set Node.
En el Capítulo 12 se demostró cómo realizar la modelización de una cadena de suministro de tres etapas
muy simples. Sin embargo, sólo el centro de distribución DC (Distribution Center) utilizaba un modelo de
gestión de stocks para tomar decisiones. La Figura 22.1 muestra una cadena de suministros más complicada
en la que dos tiendas piden a nuestro centro de distribución DC. Las dos tiendas siguen un modelo de
gestión similar al utilizado por el fabricante, al que lanzan pedidos de reposición. El fabricante puede
utilizar dos proveedores diferentes del mismo producto. Los proveedores utilizan también un modelo de
gestión para satisfacer la demanda del fabricante.
Suministro
Perfecto
Clientes
de Materia
Prima
Pedido
Pedido
Proveedor A WalMart
Fabricante
Flujo de Flujo de
Producto Centro de Producto
Distribución
Proveedor B Target
Figura 22.1: Una Cadena de Suministro Más Complicada
Sección 22.1: Desarrollando un Objeto Especializado para la Cadena de Suministro
En el Capítulo 12, se desarrolló un modelo de gestión de stocks para un único producto y una única etapa de
la cadena de suministros. Se puede utilizar un enfoque similar para cada una de los segmentos de la cadena
de suministros mostrada en la Figura 22.1, si se añade más variables de estado y algo de lógica adicional. A
medida que el sistema se hace más complicado o se requiere que se introduzcan cambios en el modelo o se
diseñen nuevas políticas de gestión, este enfoque no es el más eficiente. Sin embargo, la posibilidad de crear
objetos especializados va a facilitar la modelización de estos sistemas, incluso no añadiendo mucha lógica
adicional.
Paso 1: Abra el modelo del Capítulo 12. Cree un nuevo proyecto, abriendo otro SIMIO. Va a ser
conveniente copiar elementos del modelo anterior mientras se construye el nuevo.
Paso 2: Se utilizan entidades para modelizar tanto el flujo de pedidos como de productos. Incluya las
siguientes tres variables de estado discretas.

Tabla 22.1: Tres Nuevas Variables de Estado Discretas
Variable Descripción
OrderAmt La cantidad de producto que se necesita o que se ha pedido.
DeliverNodeID El nodo de entrada donde el pedido debe ser enviado.
OriginalOrderAmt La cantidad en el pedido original.
Paso 1: Nuestro objetivo es encapsular la lógica y los parámetros que estaban incluidos en el modelo simple
dentro de un objeto que se pueda utilizar más de una vez. Haga una subclase del objeto operación,
SERVER133 y llámelo SUPPLYINVSERVER.
Paso 2: Seleccione el objeto SUPPLYINVSERVER en el panel [Navigation]. En Definitions→Properties,

incluya cinco propiedades Expression Standard Properties, de nombre InitialInventory, ReorderPoint,
OrderUptoQty, ReviewPeriod, y ReviewPeriodTimeOffset. Deben colocarse todas en la categoría
“Inventory”134 y las dos propiedades correspondientes al período de revisión tienen que tener las
unidades en días.
Figura 22.2: Añadiendo las Cuatro Propiedades de Inventario en Nuestro Objeto

Paso 3: En el objeto SUPPLYINVSERVER, incluya una variable de estado discreta, DISCRETE STATE, de
nombre Inventory, que va a representar el nivel actual de inventario de un producto en un segmento, y
otra variable, de nombre WIP, para representar la cantidad total que para un segmento se ha pedido
desde un proveedor. La propiedad Initial State Value debe tomar el valor de “0” tanto para la variable
Inventory como para WIP respectivamente.
Paso 4: Necesitamos incluir en nuestro nuevo modelo los mismos elementos, ELEMENTS, que incluimos en el
modelo simple (Figura 22.3).
 Incluya una estadística TALLY STATISTIC, de nombre TallySL, para seguir el

comportamiento de la variable nivel de servicio.
 Incluya una estadística STATESTATISTIC, de nombre StateStatInv, para seguir el
comportamiento de la variable nivel de inventario.
 Incluya un TIMER, de nombre TimerReview, para modelizar el intervalo de revisión. La
operación de reaprovisionamiento hará la revisión de su posición de inventario135 según la
propiedad ReviewPeriod y empezará a revisar según ReviewPeriodTimeOffset.
133
Veáse el Capítulo 18 para más información sobre cómo hacer subclases de objetos en SIMIO.
134
La primera vez tiene que teclear el nombre de la categoría, “Inventory”, y ya las siguientes veces se puede seleccionar del
desplegable.
135
Recuerde que la posición de inventario es el stock disponible más lo que está pedido y que no se ha recibido.
Más Subclases: Modelización Avanzada de Cadenas de Suministros 191

Figura 22.3: Fijando los Valores de las Estadísticas y el Temporizador
Sección 22.2: Añadiendo la Estación de Pedidos y las Características para Procesarlos
En la sección previa, se han incluido en nuestro nuevo modelo las mismas variables, propiedades y
elementos que contenía el modelo sencillo del Capítulo 12. Recuerde que el modelo incluía 2 sistemas
separados (un sistema de lanzamiento y procesamiento de pedidos y otro para crear piezas para reponer los
stocks).
Paso 1: Nuestro nuevo objeto necesita también recibir pedidos y procesarlos. Se necesita un lugar, estación
(STATION), para albergar las entidades que representan a los pedidos mientras están siendo procesados.
En la sección Definitions→Elements→General, incluya una nueva STATION, de nombre
OrderProcessing.136
Paso 2: Para establecer las capacidades del proceso de pedidos así como para ordenar los pedidos que están
en espera, cree una nueva propiedad referenciada haciendo clic con el botón derecho en las propiedades.
Use los nombres que se muestran en la Figura 22.4.
Figura 22.4: Creando Propiedades Para Permitir que el Usuario Cambie la Ordenación de los Pedidos
Paso 3: Cambie a Definitions→Properties y modifique las nuevas propiedades al incluirlas en la categoría
“Ordering Information”.
Figura 22.5: Todas las Propiedades

Paso 4: Para separar el procesamiento de pedidos y productos, utilice la pestaña “Facility” e incluya un
nuevo recurso, RESOURCE, de nombre ResOrder, para utilizarlo en el sistema de pedidos, mientras que la
capacidad de las operaciones se utilizará para el sistema de producción.
136
Véase el Capítulo 19 para más información sobre STATIONS.
Paso 5: Asociaremos ahora la capacidad de los nuevos recursos y la ordenación con la estación de pedidos.
Para las propiedades Capacity Type y Work Schedule, cree nuevas propiedades, mientras que para el
resto utilice las ya creadas.
Figura 22.6: Propiedades para el Nuevo Recurso

Paso 6: Asegúrese de que cambia la categoría de las nuevas propiedades a “Ordering Information” así como
de que coloca las dos nuevas propiedades por encima de OrderInitialCapacity como se muestra en la
Figura 22.7. Cree una Switch Condition en OrderWorkSchedule, por si el usuario elige incluir turnos de
trabajo en el tipo de capacidad del sistema de pedidos.
Figura 22.7: Modificando el Tipo de Capacidad de un Pedido y las Propiedades de Turnos

Paso 7: Necesitamos añadir un punto de entrada (un nodo de entrada) para los pedidos que llegan a nuestro
sistema de aprovisionamiento, así como un punto de salida de la operación de reaprovisionamiento. En
el objeto SUPPLYINVSERVER, vaya a la sección Definitions→External. Utilizando el desplegable
Drawing→Place Symbol, coloque un símbolo para la operación entre los dos nodos externos y coloree la
parte exterior de verde (Figura 22.8).
Entrada de
Reaprovisio- Pedidos
namiento
Salida
Entrada
Normal
Normal
Figura 22.8: Creando el Interfaz Externo y Añadiendo Nodos de Entrada y de Salida

Paso 8: Mueva los dos nodos externos originales (Input y Output) al tercio inferior del objeto (Figura 22.8).
Incluya dos nodos “External”137 adicionales, de nombre ReorderOutput y OrderInput. El nodo
ReorderOutput es un nodo TRANSFERNODE y debe situarse justo por encima del nodo Input puesto que
los pedidos serán transferidos hacia el proveedor, mientras que el nodo OrderInput es un nodo
BASICNODE, que hay que situar justo por encima del nodo Output, que va a recibir pedidos en tránsito.
Esta disposición va a favorecer el concepto de que los productos fluyen desde el final de la cadena hasta
el principio (de derecha a izquierda) mientras que los pedidos lo hacen en sentido contrario. Las
propiedades de ambos nodos se especifican en la Figura 22.9. Una vez que los pedidos entren en
OrderInput, serán transferidos directamente a la estación OrderProcessing.
Figura 22.9: Especificando las Propiedades de los Nodos ReorderOutput y OrderInput

Paso 9: Añada 4 filas animadas que ayuden a mostrar el contenido de las filas de las 4 STATIONS (Figura
22.10).138 Añada las mismas 6 etiquetas de estado que existían antes para representar el nivel de
inventario (Inventory), el nivel medio de inventario (StateStatInv.Average), y el nivel de
servicio medio (TallySL.Average).
Processing.Contents
InputBuffer.Contents OrderProcessing.Contents
OutputBuffer.Contents
Figura 22.10: Añadiendo Filas Animadas y Etiquetas de Estado

Paso 10: Como parte del sistema de pedidos, se van a necesitar tres propiedades adicionales (Tabla 22.2) a
incluir en la categoría “Ordering Information”. La propiedad OrderProcessingTime debe estar medida
en días, “Days”.
Tabla 22.2: Tres Propiedades Para el Sistema de Pedidos

Propiedad Tipo Descripción Necesaria
Standard Property→Expression Tiempo para procesar un pedido antes de
OrderProcessingTime Sí
que sea atendido
DeliverNodeID Standard Property→Expression El ID del nodo que va a recibir el pedido Sí
Objeto Reference Standard El tipo de entidad a enviar
OrderEntityType Sí
Property→Entity
137
Véase Capítulo 19 y Capítulo 20 para más información sobre cómo incluir nodos externos en la vista externa de un objeto.
138
Para cada fila, fije Alignment en “None” dentro de la pestaña Appearance.
La propiedad OrderEntityType se va a utilizar de forma similar a EntityType del objeto SOURCE. Va a crear
pedidos de reposición en función de un tipo definido por el usuario (permite cambiar los pedidos sin
necesidad de modificar el objeto SUPPLYINVSERVER).
Sección 22.3: Añadiendo la Lógica de Comportamiento del Sistema de Pedidos
Acabamos de definir todas las características del nuevo objeto y ahora tenemos que añadir el sistema de
pedidos. Los pedidos que llegan al nodo OrderInput se mandan directamente a la estación
OrderProcessing. En este punto, es necesario añadir la lógica necesaria para atender los pedidos. Recuerde
que en el Capítulo 19 en el objeto DELAY, las estaciones incluían la entrada y salida de piezas.
Paso 1: Incluya un nuevo proceso, de nombre OnEnteredOrdering, que se ejecute con el disparador
OrderProcessing.Entered (Figura 22.11), y que sirva para procesar los pedidos. El proceso se
explica en los pasos siguientes.
Figura 22.11: El Proceso OnEnteredOrdered

Paso 2: Cuando se transfieren las entidades de un lugar a otro, se tiene que acabar la transferencia para que
se indique que se ha llegado al destino final. Recuerde que la capacidad de la estación OrderProcessing
fue definida con una referencia al proceso de pedidos. También habíamos añadido una expresión para
simular el procesamiento del pedido antes de que se atendiera. Sólo intentaremos atender el pedido si la
cantidad pedida es mayor que 0 y actualizaremos las estadísticas sobre el nivel de servicio. La Figura
22.12 muestra las primeras etapas de la recepción del pedido mientras que la Figura 22.16 muestra las
propiedades asociadas con las etapas correspondientes al procesamiento.
Figura 22.12: Las Primeras Cinco Etapas Correspondientes a la Llegada de Pedidos

 Incluya una etapa End Transfer para finalizar la transferencia de la entidad desde el
nodo externo OrderInput hasta la estación OrderProcessing.
 Incluya una etapa Seize para apresar una unidad de ResOrder (Figura 22.13).

Figura 22.13: Apresando Una Unidad de ResOrder
 Como en el caso de las operaciones normales, queremos dar la posibilidad al usuario de que
ejecute disparadores antes y después de procesar el pedido, por lo que ha de incluir dos
nuevas etapas Execute. Cree dos nuevas propiedades, de nombre
OrderProcessingAddOn y OrderProcessedAddOn (Figura 22.14). En la sección
Definitions→Property, cambie la categoría de esta propiedad a “Add On Process Trigger” y
el nombre a mostrar a “Order Processing” y “Order Processed” respectivamente.
Figura 22.14: Disparadores Processing y Processed

 Incluya una etapa Delay entre dos Execute para representar el procesamiento del pedido
antes de atender el pedido utilizando la propiedad OrderProcessingTime.
Figura 22.15: La Etapa Delay

 Añada una etapa Decide para determinar si la cantidad del pedido es mayor que 0 antes de
atender la orden.
 Actualice el nivel de servicio usando una etapa Tally.
Figura 22.16: Propiedades Asociadas con el Comienzo del Proceso de Pedidos

Paso 3: Las etapas anteriores eran similares a las usadas en el modelo simple del Capítulo 12. Eran las
únicas asociadas con el proceso de los pedidos puesto que el centro de distribución era el único objeto
que interesaba puesto que los pedidos no fluían hacia el cliente. Las etapas correspondientes a llevar las
unidades hasta el cliente se incluyen en la Figura 22.17.
Etapas Copiadas de
OnEnteredProcessing
Figura 22.17: Etapas Usadas Para Cubrir el Pedido y Enviarlo hacia el Cliente
Paso 4: Las primeras tres etapas actualizarán la posición de inventario en la cantidad que está siendo enviada
al cliente. Si la posición no puede cubrir la cantidad solicitada (etapa Decide) entonces cambie el valor
de la cantidad del pedido al nivel actual de inventario. Si hay suficiente inventario (“False”), disminuya
el valor de la posición de inventario en la cantidad correspondiente al pedido. Incluya la etapa Decide
y las dos etapas Assign con las propiedades incluidas en la Figura 22.18.
Figura 22.18: Actualizando la Posición de Inventario

Paso 5: Después de que la posición haya sido actualizada, el pedido tiene que ser enviado a través del nodo
externo Output. Si el “ID” del nodo estaba especificado (ModelEntity.DeliverNodeID >0),
entonces fijaremos el nodo de destino antes de que enviemos el pedido. En caso contrario, enviemos el
pedido, y dejemos que las conexiones dirijan al pedido hacia su destino (Figura 22.19).
Figura 22.19: Enviando el Pedido Hacia los Clientes

Paso 6: Si la capacidad de la fila de salida es mayor que 0, haremos la transferencia; en caso contrario, la
transferencia se hará automáticamente. A imagen y semejanza de la Figura 22.17, copie las etapas
Decide, Assign y las dos Transfer incluidas en “OnEnteredProcessing” (Figura 22.26).
Paso 7: Incluya un nuevo proceso, de nombre “OnExitedOrderingProcess”, que se ejecute con el disparador
OrderProcessing.Exited (Figura 22.20). Copie las tres etapas del proceso
“OnExitedProcessing”. Este proceso ejecutará todas las etapas cuando la capacidad de la fila de salida es
0 y los pedidos se envían directamente al nodo externo. Modifique la etapa Release para liberar el

recurso específico ResOrder en lugar de la capacidad del objeto padre, y cambie “Units Per Object” a
“1”.
Figura 22.20: Proceso Correspondiente a la Salida de la Estación OrderProcessing.

Paso 8: Dado que los pedidos se mandan a través de la fila de salida, tenemos que desactivar
“OnEnteredOutputBuffer” de forma que libere ResOrder en lugar del objeto padre, como sucedía en el
paso previo. Haga clic en el proceso y desactívelo, modificando la etapa Release.
Figura 22.21: Modificando el Proceso OutputBuffer.Entered
Sección 22.4: Añadiendo la Lógica del Sistema de Reposición de Inventario
Hemos definido hasta ahora la lógica relativa al sistema de pedido. Ahora, es necesario implementar el
sistema de reposición de inventario en el nuevo objeto.
Paso 1: Prepare el sistema de revisión periódica mediante la creación de un proceso que responda a las
llamadas del temporizador TimerReview. Desde la pestaña “Processes” de SUPPLYINVSERVER, cree un
nuevo proceso, de nombre InventoryReview. Fije la propiedad Triggering Event para que responda a
un evento TimerReview.Event que hace que se ejecute el proceso cada vez que el temporizador
genera una llamada (Figura 22.22). Este proceso es casi idéntico al creado en el Capítulo 12 (Figura
12.9) por lo que todas las etapas se pueden copiar y pegar; es necesario sin embargo modificar algo las
etapas Create, Assign y Transfer.
Figura 22.22: Proceso de Reposicionamiento

 La etapa Decide realiza una comprobación “ConditionBased” para determinar si el nivel
de inventario es menor que el punto de pedido (Inventory < ReorderPoint )
 Si se necesita reposicionar, use la etapa Create para crear una nueva entidad (Figura
22.23) según la propiedad OrderEntityType.

Figura 22.23: Creando Un Pedido de Reposición a los Proveedores
 Para el pedido recién creado, utilice una etapa Assign para asignar la cantidad y aumente
el valor de WIP en esa cantidad. Adicionalmente, también fijaremos la cantidad original
para permitir que se modelice la fiabilidad de los proveedores así como el nodo de entrada,
si se especifica (Tabla 22.3).
Tabla 22.3: Calculando la Cantidad del Pedido y Actualizando la Variable WIP
ModelEntity.OrderAmt Math.Max(0, OrderUpToQty – Inventory –WIP)
WIP WIP + ModelEntity.OrderAmt
ModelEntity.DeliverNodeID DeliverNodeID
ModelEntity.OriginalOrderAmt ModelEntity.OrderAmt
 Incluya una etapa Execute en la que se ejecutará un disparador cuando el pedido de

reaprovisionamiento sale del objeto para ir hacia los proveedores (Figura 22.24). En la
sección Definitions→Property, cambie la categoría de esta nueva propiedad a “Add-On
Process Triggers” y el nombre a “ReOrder Exited.”
Figura 22.24: Incluyendo un Disparador Definido por el Usuario

 Una vez que la propiedad OrderEntityType está fijada, se necesita enviar la entidad al
proveedor, utilizando una etapa Transfer para que se mueva desde “FreeSpace” al nodo
ParentExternalNode de ReOrderOutput.139
Figura 22.25: Mandando el Pedido de Reposición al Proveedor

Paso 2: Recuerde que en el Capítulo 12, cuando los productos llegaban al centro de distribución y eran
empaquetados, la variable Inventory se incrementaba en la cantidad del pedido recibido, mientras que la
variable WIP se reducía en la misma cantidad, utilizando el disparador “Processed” de la operación
SrvDC. Dado que estamos encapsulando esta misma lógica dentro de nuestro nuevo SUPPLYINVSERVER,
esa misma lógica necesita ser incluida justo después de que se ejecute el disparador “Processed” en
OnEnteredProcessing. Este proceso se ejecuta cuando las piezas han llegado y van a empezar a ser
139
El usuario ha de indicar cuándo los pedidos se transportan desde ReOrderOutput a través de una unión.

procesadas. Seleccione el proceso OnEnteredProcessing en la pestaña “Processes” y haga clic en el
140
botón ( ), para poder modificarlo (Figura 22.26).
Executes Processed
Add-On Trigger
Figura 22.26: El Proceso OnEnteredProcessing

Paso 3: Después de la ejecución del disparador “Processed” (Figura 22.26), la entidad o bien será transferida
a la fila de salida si su capacidad es mayor que 0 (rama “True”) o bien se ejecutarán todas las
asignaciones correspondientes al evento salida antes de ser transferida al nodo de salida externo. En
nuestro modelo en el que se fabrica para inventariar (make-to-stock), el producto se coloca en el
inventario y no se manda al siguiente proceso. Necesita por tanto borrar las etapas que se encuentra
después de la etapa Execute e incluir tres nuevas etapas (Assign, Release, y Destroy) (Figura
22.27).
Nuevas Etapas
Figura 22.27: El Nuevo Proceso OnEnteredProcessing

 La etapa Assign actualiza los valores de Inventory y WIP (Tabla 22.4).
Tabla 22.4: Actualizando las Variables Inventory y WIP

Inventory Inventory + ModelEntity.OrderAmt
WIP WIP - ModelEntity.OriginalOrderAmt
 Dado que la entidad no se envía a la fila de salida (no se ejecutará el proceso

OnEnteredOuputBuffer) o al nodo externo (no se ejecutará el proceso ExitedProcessing), la
capacidad de la operación no se libera nunca. Así, copie la etapa Release del proceso
OnExitedProcessing después de la etapa Assign.
140
Véase el Capítulo 18 y el Capítulo 21 para más información sobre cómo desactivar y restaurar procesos.
 Incluya una etapa Destroy para que elimine la entidad que acaba de llegar puesto que no va a
seguir moviéndose.
Paso 4: La propiedad InitialInventory se utilizaba para establecer la posición inicial del Inventory dentro del
proceso OnInitialized. Desactive el proceso OnInitialized de nuestro nuevo objeto e incluya la misma
etapa Assign que antes (Figura 22.28).
Figura 22.28: Estableciendo la Posición Inicial de Inventario
Sección 22.5: Usando los Nuevos Objetos para Modelizar la Cadena de Suministros
El nuevo objeto SUPPLYINVSERVER ha sido definido y puede utilizarse para crear un modelo (Figura 22.29)
de la cadena de suministros compleja (Figura 22.1). 141
Figura 22.29: Modelo del Sistema Complejo

Paso 1: En “Facility”, añada una nueva MODELENTITY, de nombre Orders. Añada una etiqueta de estado que
esté conectada con la entidad de forma similar a la mostrada en el Capítulo 18, y que muestre la
propiedad Expression, con el valor OrderAmt (Figura 22.29).
141
Debe separar los objetos hasta que la dirección de los caminos muestre la flecha. Tener los caminos y los conectores en el sentido
incorrecto puede generar errores que son difíciles de encontrar. Cuando esté seguro de que las uniones muestran la dirección
correcta, sitúe los objetos otra vez en sus lugares originales.

Paso 2: Incluya 2 SOURCES, de nombre SrcWalmartCust y SrcTargetCust, para que se generen los clientes
que representan las compras diarias (tiempo entre llegadas de 1 día). Como se hizo con anterioridad, fije
las asignaciones Before Exiting State Assignments que marcarán el número de pedidos,
ModelEntity.OrderAmt, en Random.Poisson(40) y Random.Poisson(30)en días, para
las tiendas Walmart y Target respectivamente.
Paso 3: Añada 1 SUPPLYINVSERVER, de nombre SupInvWalmart, que representará la posición de

inventario de Walmart.
 Fije la propiedad Initial Capacity en 2 y la propiedad ProcessingTime en

Random.Triangular(1,2,3)*ModelEntity.OrderAmt en minutos, para modelizar el
procesamiento de los productos en las tiendas y en las estanterías.
 En la categoría Inventory, fije las propiedades Review Period en 5 días, Initial Inventory en 1300,
Reorder Point en 900, y Order Up to Qty en 1100 (Figura 22.30).
 Para cumplimentar la categoría Order Information, es necesario saber que se tarda 0.25 días en
procesar un pedido. Fije Deliver Node ID en Input@SupInvWalmart.ID142 lo que permitirá
que los pedidos que sean enviados al proveedor vuelvan al cliente adecuado.
Figura 22.30: Propiedad del Cliente Walmart

Paso 4: Repita el Paso 3 para el cliente Target, copiando el objeto SupInvWalmart en otro denominado
SupInvTarget, y cambiando sus propiedades según la Figura 22.31.
Figura 22.31: Propiedad del Cliente Target

Paso 5: Conecte las dos fuentes con el nodo OrderInput correspondiente en SupInvWalmart y
SupInvTarget con conectores (Figura 22.29).
142
Recuerde que cada objeto en SIMIO tiene un número de identificación único al que se puede acceder utilizando la función ID.
Paso 6: Necesitas crear el centro de distribución que va a dar servicio a los dos clientes. Copie
SupInvWalmart y llámelo SupInvDC.
 Fije la propiedad ProcessingTime en minutos según la siguiente expresión:

Random.Triangular(5,10,20)*ModelEntity.OrderAmt
Fije la propiedad Initial Inventory en 1700, Reorder Point en 1200 y Order Up to Qty en
1700.
 Fije Delivery Node ID en 0.
Paso 7: Conecte el centro de distribución con cada uno de los dos clientes.
 Para que los productos fluyan hacia las tiendas, conecte el nodo Output de SupInvDC con
los nodos Input de SupInvWalmart y SupInvTarget utilizando TIMEPATHS (Figura
22.29). Se tarda generalmente 4 días en transportar el producto desde el centro de
distribución a cada tienda. Sin embargo, puede tardar un mínimo de 3 y un máximo de 7
días. Fije la propiedad Travel Time en Random.Pert(3,4,7).
 Para que los pedidos fluyan desde las tiendas al centro de distribución, conecte el nodo
ReorderOutput de cada tienda con el nodo OrderInput de SupInvDC con conectores que
representan transmisiones de datos tipo EDI (Electronic Data Information).
Pregunta 1: Con nuestro nuevo objeto, ¿cómo podemos modelizar que se atiendan antes los pedidos de
Walmart que los de Target, si llegan a la vez?
Paso 8: Hemos utilizado un proveedor para aprovisionar el centro de distribución. Copie SupInvDC y
péguelo en un nuevo objeto SUPPLYINVSERVER, de nombre SupInvA (Figura 22.32). Hay que realizar
pocos cambios adicionales.
 Como tiempo de transformación de materias primas en producto, fije la propiedad

ProcessingTime en Random.Triangular(10,20,30)*ModelEntity.OrderAmt
(minutos).
 Fije Initial Inventory en 600, Reorder Point en 300 y Order Up to Qty en 600.
 Fije Delivery Node ID en 0.
Figura 22.32: Conectando un Proveedor con el Centro de Distribución.

Paso 9: De forma similar a lo realizado con las tiendas, conecte el nodo ReorderOutput de SupInvDC con
el nodo OrderInput de SupInvA con un conector que represente el envío de pedidos al proveedor.
Paso 10: Los productos tardan lo mismo en esta etapa de la cadena que en la que conecta con los clientes.
Conecte el nodo Output de SupInvA con el nodo Input de SupInvDC con TIMEPATH que tiene una
propiedad Travel Time que ha de fijarse en Random.Pert(3,4,7)(días).

Paso 11: El primer proveedor tiene un suministro infinito de materia prima (se asume que el material
siempre está disponible). Conecte ReorderOutput de SupInvA directamente con el nodo de entrada a
SupInvA, lo que equivale a que el proveedor pueda pedir la cantidad que necesite de materia prima a su
proveedor perfecto de forma que consigue su posición de inventario deseada.
Paso 12: Guarde el modelo y ejecútelo durante un período de 52 semanas y vea los resultados.
Pregunta 1: ¿Cuál es el nivel de servicio medio en cada uno de los segmentos de la cadena logística?
Pregunta 2: ¿Cuál es el nivel actual y medio de inventario en cada uno de los niveles de la cadena?
Pregunta 3: ¿Cree que el sistema actual es el adecuado, y cuál parece ser el problema?
Sección 22.6: Añadiendo un Segundo Proveedor
Al revisar los resultados, la mayoría de las posiciones de inventario son 0, lo que derivó en niveles de
servicio muy bajos. El punto central es el tiempo total empleado en llevar el producto desde los proveedores
hasta los clientes, así como la variabilidad. Esta situación se puede mejorar mediante la optimización de los
puntos de pedido y de las cantidades máximas en inventario. También se pueden plantear estudios de mejora
para reducir los tiempos de proceso o de transporte. Añadamos un segundo proveedor (Supplier B) que
trabaja contra pedido (make-to-order) y no para almacenar (make-to-stock).
Paso 1: Incluya 1 SERVER, de nombre SrvSupB. Modifique el modelo según la Figura 22.33.
Figura 22.33: Añadiendo el Supplier B

 Conecte ReorderOutput de SupInvDC con el nodo de entrada de SrvSupB con un CONNECTOR.
 Para que fluyan los productos, conecte el nodo Output de SrvSupB con el nodo Input de
SupInvDC con un TIMEPATH. Se tarda Random.Pert(1,2,3) (en días) en entregar producto
desde este proveedor.
 Fije la propiedad ProcessingTime de SvSupB (tiempo de proceso) en

Random.Triangular(8,13,20)*ModelEntity.OrderAmt (minutos)

Paso 2: Hasta ahora, el centro de distribución tiene acceso sólo al primer proveedor. A partir de este
momento, si la cantidad de pedido es mayor que su posición de inventario, el centro de distribución sólo
pedirá lo que tiene el primer proveedor en stock a Supplier A y el resto a Supplier B. Incluya un
disparador “ReOrderExited” que se ejecuta cuando el pedido sale de SupInvDC (Figura 22.34).
Figura 22.34: Proceso ReOrderExited

 Incluya una etapa Decide que ayude a comprobar si la cantidad pedida,
ModelEntity.OrderAmt, es menor o igual que la posición de inventario del primer proveedor,
SupInvA.Inventory. Si lo es (rama “True”), use una etapa Set Node para especificar que el
pedido se debe mandar al primer proveedor (OrderInput@SupInvA).
Figura 22.35: Propiedades de las Etapas Decide y Set Node

 Si la cantidad pedida es mayor que la posición de inventario, utilice la etapa Create para crear una
copia del pedido y fije la cantidad del pedido original en el valor correspondiente a la posición de
inventario (Figura 22.37).
Figura 22.36: Creando una Etapa Create para Copiar el Pedido

 En la asignación, fije la posición de inventario de SupInA en OrderAmt y fije OriginalOrderAmt
en OrderAmt. Mande el pedido a SupInvA, colocando el punto “End” sobre la etapa Set Node
(Figura 22.34).
Figura 22.37: Fijando OrderAmount y OriginalOrderAmount

 Para el nuevo pedido creado, para la copia, fije OrderAmt en la diferencia y actualice
OriginalOrderAmt (Figura 22.38).
Figura 22.38: Creando un Pedido para el Segundo Proveedor

Paso 3: Transfiera el pedido desde “Free Space” a Input@SrvSupB (Figura 22.39).
Figura 22.39: Transfiriendo hacia SrvSupB

Paso 4: Guarde el modelo y ejecútelo durante un período de 52 semanas y vea los resultados obtenidos.
Pregunta 4: ¿Cuál es el nivel de servicio medio en cada uno de los segmentos de la cadena logística?
Pregunta 5: ¿Cuál es el nivel actual y medio de inventario en cada uno de los niveles de la cadena?
 Este modelo proporciona una base para poder incluir múltiples mejoras.
 La información sobre fallos en los pedidos se puede incluir en el recurso ResOrder. Se debe
añadir la posibilidad de parar los flujos de pedidos.
 Se puede incluir fácilmente información sobre costes en los pedidos y en los objetos sobre
modos de transporte (aire, tren, …).
 La fiabilidad de los aprovisionamientos se puede añadir en SUPPLYINVSERVER de forma que se
modelicen errores en los envíos en el selección de productos.
 Un objeto puede ser modificado para trabajar con muchos productos en vez de con uno único.
 Se pueden incluir distintas políticas de gestión de stocks, incluso aplicarlas de forma distinta a
distintos segmentos de la cadena.
 Se podría añadir un evento controlador, MONITOR, para crear un sistema de revisión continuo en
vez del sistema periódico. Incluso los usuarios podrían elegir entre ambos.

Capítulo 23
Más Sobre Subclases: Planificación de Procesos/Gestión de
Proyectos
 Haciendo subclases de TIMEPATHS y TRANSFERNODES
 Usando Propiedades de Listas y de Variables de Estado
 Usando controladores, MONITORS, para observar objetos
 Conectando objetos entre sí
Sección 23.1: Planificación de Procesos
Un nuevo Producto 3 se está introduciendo en el mercado. Para producir 1 unidad de Producto 3 hay que
ensamblar 1 unidad de Producto 1 y 1 unidad de Producto 2. Antes de que se empiece a producir una unidad
de cualquiera de los productos, hay que comprar materia prima y hay que formar a los operarios. También
hay que hacer una inspección en el Producto 2 antes de que sea ensamblado con el Producto 1 para formar el
Producto 3. La tabla que sigue proporciona la lista de actividades o tareas, así como sus relaciones de
precedencia y la duración media de cada actividad.
Actividad Predecesor Duración (días)
A = formar a los trabajadores -- 6
B = comprar material prima -- 9
C = producir Producto 1 A, B 8
D = producir Producto 2 A, B 7
E = test Producto 2 D 10
F = ensamblar Producto 1 y Producto 2 C, E 12
A continuación se muestra el diagrama del proyecto, con el nombre de las tareas y su duración en días:
Figura 23.1: Ejemplo de Planificación de Proyectos

Se tardará en completar un proyecto una media de 38 días y las actividades B, D, E, y F son críticas (“pues
están en el camino crítico”) – lo que significa que si una de ellas tarda más de lo esperado, el tiempo total del
proyecto aumenta. Pero en la realidad, los tiempos de cada actividad no son constantes sino aleatorios o
sujetos a incertidumbre, lo que implica que varias actividades distintas pueden ser críticas. Luego no
Más Sobre Subclases: Planificación de Procesos/Gestión de Proyectos 207

podemos basarnos en valores deterministas sino que tenemos que representar los tiempos con variables
aleatorias.
Las actividades pueden también compartir recursos necesarios para realizar una actividad. Por eso, el
objetivo será determinar el camino crítico así como la probabilidad de que una actividad se encuentre en el
camino crítico.
Finalización Más El momento del tiempo en que acaba una actividad (una entidad deja el
Temprana/Earliest camino).
Finish
Finalización más El momento del tiempo en que puede acabar una actividad sin provocar
Tardía/Latest un cambio en el camino crítico o un retraso en las tareas subsiguientes.
Finish
Holgura/Slack La diferencia en tiempo entre la finalización más temprana y la más
tardía.
Criticidad/Percent Probabilidad de que un camino está en el camino crítico.
CP
En capítulos anteriores hemos demostrado la posibilidad de crear subclases a partir de objetos existentes, lo
que permite añadir características y comportamientos o modificar los actuales. Pero no se han hecho
subclases todavía de los objetos que conectan otros objetos entre sí (caminos, PATHS o TIMEPATHS).
Modelizaremos el problema de gestión de proyectos utilizando caminos en los que se consume tiempo.
Utilizaremos una repetición del modelo para representar un proyecto, por lo que múltiples réplicas serán
utilizadas para caracterizar estadísticamente el proyecto.
Sección 23.2: Creando un Camino TIMEPATH Para Representar Actividades
La posibilidad de crear nuevos objetos es una de las ventajas de SIMIO, y los caminos TIMEPATH son un
objeto atractivo como para utilizarlo para representar las tiempos de las actividades, dado que las entidades
se pueden mover por ellos. Los caminos son los objetos importantes en la determinación de un camino
crítico. Se necesita calcular la influencia de cada camino (finalización más temprana, holgura, criticidad...).
El camino necesita conocer cuando una entidad llega al final y además controlar que sólo una entidad se
mueva por él. Su encapsulación permite que el objeto tenga inteligencia para calcular automáticamente sus
variables de comportamiento, así como que nos permite utilizarlo en distintos modelos de gestión de
proyectos.
Paso 1: Haga una subclase del objeto camino, TIMEPATH y cambie la propiedad Model Name a
PRJTIMEPATH143.
Paso 2: Incluya dos variables DISCRETE STATE, de nombre EarliestFinish y CalculateSlack. La primera se
utilizará para registrar el momento en que la actividad ha acabado, mientras que la segunda se utilizará
para controlar cuándo se puede calcular la holgura.
Paso 3: Para realizar los cálculos del camino crítico, añada 3 estadísticas TALLY, de nombre
TallyEarliestFinish, TallySlack, y TallyPercentCP, utilizando la sección Definitions→Elements.
 Cambie la propiedad Category a “Critical Path” para las tres estadísticas de observación, TALLY.
 Cambie la propiedad Data Item a “Earliest Finish”, “Slack”, y “Percent CP” para cada una de las
estadísticas.
143
Haga clic con el botón derecho en el objeto en el panel [Navigation] y seleccione sus propiedades.
Paso 4: Recuerde que sólo un proyecto será realizado en una repetición. Para modelizar un nodo del que
comienzan muchas actividades, los caminos no deben permitir que circule más de una entidad
simultáneamente y la dirección de movimiento es única. En Definitions→Properties, haga clic en la
flecha para que aparezcan las propiedades heredadas.
 Seleccione la propiedad TravelerCapacity y cambie Default Value de “Infinity” a “1” y la propiedad

Visible a “False”, de forma que el usuario no pueda cambiarla y sea fijada automáticamente.
Figura 23.2: Fijando los Valores por Defecto de TravelCapacity

Paso 5: El camino TIMEPATH define cinco procesos que determinan su comportamiento (Tabla 23.1).
Tabla 23.1: Procesos de un Camino TimePath

Procesos Descripción
OnEntered Proceso que se ejecuta cuando el borde anterior de una entidad, trabajador
o transportador llega al principio de TIMEPATH
OnExited Proceso que se ejecuta cuando el borde posterior de una entidad,
trabajador o transportador llega al final de TIMEPATH
OnIntialized Proceso que se ejecuta al principio de la simulación
OnReachedEnd Proceso que se ejecuta cuando el borde anterior de una entidad, trabajador
o transportador llega al final de TIMEPATH
OnTrailingEdgeEntered Proceso que se ejecuta cuando el borde posterior de una entidad,
trabajador o transportador llega al principio de TIMEPATH
Paso 6: Cuando la entidad llega al final del camino, la actividad se ha terminado y el tiempo más temprano
puede ser calculado. Desactive el “OnReachedEnd” y siga la Figura 23.3 para realizar los cálculos.
Nuevas Etapas
Figura 23.3: Calculando el Tiempo Más Temprano y Clausurando un Camino

 Incluya una etapa Assign para que se fije DesiredDirection en
Enum.TrafficDirection.None, lo que va a clausurar el camino y no permitirá que más
entidades viajen por él. Fije también la variable EarliestFinish en el momento actual, TimeNow,
(Figura 23.4).

Figura 23.4: Cerrando el Camino y Fijando el Tiempo Más Temprano
 Incluya una etapa Tally para añadir una observación en TallyEarliestFinish. Como se muestra en
la Figura 23.5, el valor EarliestFinish está en horas, por lo que es conveniente pasarlo a días
dividiendo por 24.
Figura 23.5: Añadiendo una Observación a EarliestFinish
Sección 23.3: Creando un Objeto Junction Para Modelizar Relaciones de Precedencia
En la sección anterior, hemos modelizado las actividades del proyecto como caminos, TIMEPATHS, y hemos
calculado ciertas estadísticas. Sin embargo, los caminos no pueden hacer que se cumplan las relaciones de
precedencia o empezar nuevas actividades ni determinar cuándo ocurre la última finalización de las tareas
que convergen en un nodo. Las restricciones correspondientes a las relaciones de precedencia tienen que ser
impuestas en nodos, que también permitirán que se inicie el siguiente conjunto de actividades a partir de ese
nodo. Así, el nodo tiene que esperar hasta que acaben todas las actividades precedentes antes de empezar con
todas las siguientes a la vez. Los nodos determinan también cuál ha sido la finalización más tardía,
correspondiente a la última de las actividades precedentes que ha terminado.
Paso 1: Los objetos estándar ni pueden modelizar estas circunstancias fácilmente ni son sencillos como para
modificarlos para que nos sirvan en nuestro propósito. Por eso, vamos a crear un objeto similar al objeto
DELAY del Capítulo 19. A partir de la pestaña “Project Home”, incluya un nuevo modelo, “Fixed Class
Model”, de nombre JUNCTION, que servirá para modelizar los nodos o cruces.
Paso 2: Necesitamos que nuestro cruce actúe tanto como un nodo de finalización como de un nodo de inicio,
así como un nodo intermedio en nuestra red del proyecto. Los nodos de inicio empezarán actividades
mientras que los nodos de finalización acabarán las actividades.
 Incluya 1 LIST con caracteres a partir de la sección Definitions→List→Create, de nombre

ListJunctionType, con tres entidades como se muestra debajo.
Figura 23.6: Definiendo Diferentes Tipos de Listas

 Incluya una nueva propiedad “List Property”, de nombre JunctionType, que va a permitir al usuario
especificar el tipo de cruce, siendo “Junction” el tipo por defecto; colóquela en la categoría “Project
Management” (Figura 23.7).144
Figura 23.7: Especificando una Propiedad List JunctionType

Paso 3: Como cualquier objeto fuente, SOURCE, si el objeto cruce, JUNCTION, es un nodo de inicio, “Start
Node”, necesitará crear entidades para enviarlas por los caminos. En
Definitions→Propertites→Add→Object Reference, añada una propiedad Entity, de nombre EntityType,
asegurándose que las coloca en la categoría “Project Management” que se ha creado en el paso anterior.
También es deseable que se muestre la propiedad si la propiedad JunctionType ha sido fijada en
“StartNode”.
Figura 23.8: Especificando el Nodo de Inicio

Paso 4: Cada cruce tiene que saber el número de actividades precedentes o predecesoras a las que esperar,
así como el número de actividades siguientes o sucesoras que hay que empezar. Incluya 2 propiedades
Standard Expression, de nombre Predecessors y Successors.145
144
Puede cambiar la presentación del objeto lista, puesto que se ha añadido un espacio entre las opciones “StartNode” y “EndNode”.

Figura 23.9: Fijando las Propiedades de los Predecesores y los Sucesores
Paso 5: Incluya 2 variables DISCRETE STATE, de nombre ActivitiesCompleted y LatestFinish, para que se
grabe el número de actividades que se han acabado y la hora en la que ha acabado la última.
Paso 6: Como se hizo en el Capítulo 19 para el objeto DELAY, las entidades entrantes necesitan un lugar en el
que se puedan ejecutar acciones. A partir de Definitions→Elements, incluya una estación, STATION, de
nombre Project, y con todos los valores por defecto.
Paso 7: Definamos ahora una vista externa para el objeto JUNCTION.
 A partir de la sección Definitions→External→Drawing, y utilizando un polígono, dibuje un

diamante rojo (Figura 23.10).
 Incluya un nodo externo, a partir de un nodo básico, BASICNODE, en el lado izquierdo del diamante ,
y en el que se recibirán las actividades, que serán automáticamente enviadas a la estación Project.
 Cree la salida incluyendo un nodo externo, a partir de un nodo de transferencia, TRANSFERNODE, en
el lado derecho del diamante para que direccione las actividades siguientes.
Figura 23.10: Vista Externa del Objeto Junction Objeto, con Nodos de Entrada y de Salida
Paso 8: Ahora que hemos definido la vista externa y que las actividades pueden entrar y salir de nuestro
objeto, tenemos que añadir la lógica sobre las actividades predecesoras y sucesoras. Cree un nuevo
proceso, de nombre “OnEnteringProject”, que se ejecutará cada vez que una actividad entra en la
estación Project; especifique que el evento disparador es “Project.Entered” (Figura 23.11).
145
Actualmente en la Versión 3 no hay posibilidad de conocer el número de caminos o uniones que llegan o salen de los nodos.
Figura 23.11: Proceso que se Ejecuta cuando las Actividades Entran en un Cruce
 Como siempre, la primera tarea que se necesita hacer es finalizar la transferencia de la entidad con
una etapa End Transfer.
 Incremente después el número de actividades que se han acabado en 1.
Figura 23.12: Actualizando el Número de Actividades

 Decida ahora si todas las actividades precedentes han sido finalizadas (ActivitiesCompleted
== Predecessors) (Figura 23.13). Advierta que se ha usado la propiedad Exclusion Expression
para determinar al comienzo de la simulación si esta etapa es necesaria.146 Si el cruce es un nodo de
comienzo, o si sólo tiene una actividad precedente, el resto de las actividades pueden empezar
directamente. Si esto se realiza al comienzo de la simulación, las ejecuciones se pueden acelerar de
modo notable.
Figura 23.13: Decidiendo si Todas las Predecesoras Han Finalizado

 Si todas las actividades precedentes no han sido acabadas, incluya una etapa Destroy para acabar
con la actividad actual.
 Si esta actividad es la última o si el nodo es de comienzo, “Start Node”, tenemos que empezar con el
conjunto de actividades siguientes. Incluya una etapa Create que creará copias de la entidad actual
(fije la propiedad Create Type en “CopyAssociatedObject”). Fije Number of Objects en
146
Si la expresión da el resultado de 1, la entidad fluirá directamente por la rama principal o verdadera. Si da el resultado de 2, la
entidad irá por la rama secundaria o falsa. El resto de resultados hará que se realice la etapa.

Successors-1 dado que ya hay una actividad en el objeto. Advierta que la propiedad Exclusion
Expression ayuda a saltarse esta etapa si sólo hay un sucesor (Figura 23.14).
Figura 23.14: Creando las Actividades Siguientes

 Mediante el uso de una etapa Transfer, la actividad original ha de ser enviada desde “Current
Station” a ParentExternalNode Output mientras que las nuevas actividades han de ser enviadas
desde “Free Space” a ParentExternalNode Output (Figura 23.15).
Figura 23.15: Enviando las Actividades Sucesoras

Paso 9: Si el objeto JUNCTION es un nodo de comienzo, debe inmediatamente crear una actividad para que
comience una rama de la red del proyecto. El proceso “OnInitialized”, que se ejecuta para cualquier
objeto al comienzo de la simulación, se utiliza para incluir esta lógica. Utilizando el desplegable que se
encuentra en Processes→Process→Select Process, elija el proceso “OnInitialized”.
Figura 23.16: Proceso “OnInitialized” Para Comenzar las Actividades

 Incluya una etapa Create que va a crear un nuevo objeto de la propiedad EntityType. Haga clic en
la propiedad Object Instance Name y seleccione la propiedad referenciada. Advierta otra vez el uso
de la propiedad Exclusion Expression para saltarse este paso si no es un “Start Node” (Figura 23.17).
 Si es un nodo de comienzo y se ha creado una actividad, incluya una etapa Transfer para que se
dirija desde “FreeSpace” al nodo Input de ParentExternalNode. Esto hará que se ejecute el
proceso “OnEnteringProject”, lo que generará el número correcto de sucesores sin necesidad de
tener que repetir el código (Figura 23.17).

Figura 23.17: Etapas Create y Transfer del Proceso “OnInitialized”
Sección 23.4: Creando una Pequeña Red para Probar el Nuevo Objeto
Parece que nuestro cruce está preparado para satisfacer relaciones de precedencia y empezar nuevas
actividades. Vuelva al modelo original y cree una red muy sencilla para probarlo. No hagamos hincapié en el
nombre de los objetos.
Paso 1: Incluya una entidad, de nombre Activities, y 4 cruces con sus nombres por defecto. Colóquelos
Figura 23.18: Red Simple para Probar el Objeto JUNCTION

Paso 2: Conecte Junction1 a Junction2 con dos PRJTIMEPATHS, con duraciones de 1 y dos días
respectivamente, y conecte Junction2 a Junction3 y Junction4 con un PRJTIMEPATHS de 1 día de
duración.
Paso 3: Haga que Junction1 sea el nodo de comienzo, “Start Node”, con dos sucesores, Successors,
mientras que Junction2 tiene 2 predecesores, Predecessors, y 2 sucesores, Successors (Figura 23.19).
Figura 23.19: Fijando los Cruces

Paso 4: Guarde el modelo y ejecútelo para ver qué sucede.

Pregunta 6: ¿Se crearon dos actividades en Junction1?
Pregunta 7: ¿Esperó Junction2 a que las dos actividades predecesoras se acabaran antes de empezar el
nuevo grupo de actividades?
Pregunta 8: ¿Empezaron las dos actividades que salen de Junction2?
Paso 5: Parece que sólo una fue creada cuando en realidad las dos fueron mandadas por el mismo camino.
Haga clic en el nodo Output de Junction2 y cambie Outbound Link Preference de “Any” a “Available”,
para que la regla de salida sólo elija un camino que esté disponible.
Paso 6: Guarde el modelo y ejecútelo para ver qué sucede.
Pregunta 9: ¿Empezaron ahora las dos actividades que salen de Junction2?
Paso 7: El usuario ha de cambiar ahora la propiedad por defecto de “Any” a “Available” cada vez que se
encuentren con el mismo problema. Para que no se olvide, vamos a cambiar automáticamente la
propiedad haciendo una subclase del objeto TRANSFERNODE. Haga una subclase de TRANSFERNODE, de
nombre PrjTransferNode.
Paso 8: En Definitions→Properties, haga clic en la flecha “Properties (Inherited)” para mostrar las
propiedades heredadas. Seleccione la propiedad OutboundLinkPreference y cambia el valor por defecto,
Default Value a “Available”, y fije la propiedad Visible en “False”, de forma que el usuario no pueda
cambiarlo de forma accidental.
Paso 9: Vuelva al objeto JUNCTION y seleccione el nodo externo Output en la sección

Definitions→External. Cambie la propiedad Node Class de TRANSFEROBJECT a PRJTRANSFERNODE
(Figura 23.20).
Figura 23.20: Cambiando el Nodo de Salida a PrjTransferNode
Sección 23.5: Construyendo la Red del Ejemplo
Creemos ahora el modelo correspondiente a nuestra red incluida en la sección inicial del capítulo.
Paso 1: Borre todos los cruces del modelo dado que no incluyen el nodo PRJTRANSFERNODE. Incluya 5
nuevos cruces, JUNCTIONS, con sus nombres por defecto (Figura 23.21).

Figura 23.21: Modelo de Ejemplo
Paso 2: Use caminos PRJTIMEPATHS para representar cada una de las actividades, conectando dos cruces. En
la Tabla 23.2 se especifican los nombres de las actividades así como su duración (propiedades Travel
Time y Units).
Tabla 23.2: Nombre y Tiempo de las Actividades

De A Nombre Tiempo Unidades
Junction 1 Junction 2 A Random.Pert(5,6,10) Días
Junction 1 Junction 2 B Random.Pert(6,9,9) Días
Junction 3 Junction 4 C Random.Pert(6,8,16) Días
Junction 2 Junction 3 D Random.Pert(4,5,7) Días
Junction 2 Junction 4 E Random.Pert(6,7,10) Días
Junction 4 Junction 5 F Random.Pert(8,12,16) Días
Paso 3: Use los valores incluidos en la Figura 23.22 para especificar las propiedades Project Management de
cada uno de los cinco cruces, incluyendo las restricciones de precedencia así como el número de
actividades siguientes que han de empezar.
Figura 23.22: Propiedades de los Cinco Cruces

Paso 4: Guarde el modelo y ejecútelo, dejando la duración de la repetición sin especificar, “Unspecified”.
Pregunta 10: ¿Cuántos proyectos se han ejecutado y cuál fue la duración?
Paso 5: Recuerde que decidimos hacer sólo un proyecto por repetición. Incluya por tanto un experimento
que servirá para realizar 1000 veces el proyecto.
Paso 6: Realice el experimento y estudie los resultados en la pestaña “Pivot Grid”.
Paso 7: Filtre la columna “Category” haciendo clic en el icono embudo que se encuentra en la esquina
derecha (Figura 23.23), y seleccione las estadísticas correspondientes al camino crítico, “Critical Path”.

Filtre también la columna “Statistic” para que sólo incluya el valor medio, “Average”, dado que sólo
tenemos una observación por repetición. En la Figura 23.24 se muestra el conjunto reducido de
resultados. La duración del proyecto está entre 27 y 38 días con una media de 33 días.147.
Figura 23.23: Filtrando la Categoría para Mostrar las Estadísticas del Camino Crítico
Figura 23.24: Estadísticas sobre Terminaciones Más Tempranas Utilizando 1000 Repeticiones
Sección 23.6: Añadiendo la Holgura y la Criticidad en los Cálculos
En este punto se puede determinar la fecha de terminación más temprana, Earliest Finish (EF), de todas las
actividades y el tiempo total de finalización del proyecto, pero es difícil de determinar qué actividades
conforman el camino crítico dado que los tiempos son aleatorios. Sin embargo, los valores de la holgura y
del porcentaje de tiempo que una actividad es crítica puede ayudar al gestor del proyecto. Como hemos visto,
la fecha más temprana se puede calcular sin obtener información de otros objetos. Sin embargo, para el
cálculo del valor de la fecha de terminación más tardía, Latest Finish (LF), se requiere la holgura así como el
número de veces que una actividad ha estado en el camino crítico.
El tiempo más tardío sólo se puede saber en los cruces, y se determina cuando acaba la última actividad. Se
necesita que haya comunicación entre dos objetos; y hay dos maneras de enfocar esta comunicación. En el
primer enfoque (Figura 23.25), los cruces, JUNCTIONS, tienen que conocer los caminos, PRJTIMEPATHS, que
llegan a ellos. Las actividades, PRJTIMEPATHS, utilizarán una variable de estado interna al objeto, que
tomará el valor de 1 al llegar al cruce y cuando la última actividad termina. En el segundo enfoque, los
caminos han de conocer los cruces a los que están conectados y controlar una variable de estado interna al
cruce. Vamos a ilustrar ahora este enfoque.
147
Sus números pueden ser un poco diferentes dado que la muestra automática de los números aleatorios en su ordenador puede ser
diferente. Sin embargo, los resultados deben ser estatísticamente similares.
PrjTimePath PrjTimePath
Junction
Monitorizar
Monitorizar
Señal
Señal
Calcular Holgura Junction Calcular Holgura
Figura 23.25: Enfoques para Intercambiar Información entre Dos Objetos

Paso 1: Seleccione el camino PRJTIMEPATH del panel [Navigation].
Paso 2: En la pestaña Definitions→Elements, incluya 1 MONITOR, de nombre MonitorSlack, que se va a

utilizar para calcular la holgura cuando la variable de estado CalculateSlack cambie su valor a 1 (Figura
23.26).
 Fije Monitor Type en “DiscreteStateChange” y State Variable Name en CalculateSlack.

 Cree un nuevo proceso On Event Process para que sea ejecutado cuando el controlador o monitor
cambia de valor.
Figura 23.26: Propiedades para Calculas la Holgura

Paso 3: Cuando la última actividad se acaba, la variable CalculateSlack del cruce asociado tomará el valor
de 1. Como esta variable está siendo controlada por MonitorSlack, en ese momento se ejecutará
“OnEventProcess” (Figura 23.27).
 Incluya una etapa Tally que calcule la holgura (LF-EF), siendo el valor del tiempo más tardío, LF,
el correspondiente al momento actual.
 Una segunda etapa Tally añadirá o un 0 o un 1 a la variable TallyPercentCP para indicar si está
en el camino crítico o no.
Figura 23.27: Calculando la Holgura y Determinando Si Está en el Camino Crítico

Paso 4: El camino PRJTIMEPATH está preparado para calcular las dos nuevas estadísticas en el momento en
que la variable CalculateSlack cambie de valor. El cruce JUNCTION debe ahora ser capaz de modificar la

variable CalculateSlack de todos los caminos precedentes una vez que haya terminado la última
actividad. Seleccione el objeto JUNCTION del panel [Navigation].
Paso 5: Los objetos en SIMIO no saben nada sobre el modelo. Así, tiene que avisar al modelizar a los cruces
de qué caminos están conectados a él. Un cruce puede tener uno o más caminos predecesores. Así, y
para representar más de una actividad, es necesario disponer de listas. Incluya una lista, LIST, de
ListLinkPreference con dos valores (Individual o List).
Figura 23.28: Haciendo la Lista que Contendrá Caminos Precedentes

Paso 6: Incluya una propiedad List Standard Property, de nombre PrecedentLinkType, asegurándose de
que la coloca en la categoría correcta y que el valor por defecto es “Individual” (Figura 23.29).
Figura 23.29: Fijando los Tipos de Precedencias

Paso 7: Incluya dos propiedades adicionales en la categoría “Project Management”. Una servirá para que el
usuario especifique un camino individual y la otra para especificar una lista de caminos. Del desplegable
Object Reference, incluya una propiedad Object Instance Property, de nombre PredecessorsLink y una
propiedad Object List Property, de nombre ListPredecessorsLink. Fije la propiedad de cambio, switch
properties, para que permita que se muestre sólo una de ellas en función del valor de
PrecedentLinkType que había sido especificado con anterioridad (Figura 23.30).

Figura 23.30: Especificando el Objeto y su Lista de Propiedades
Paso 8: Hay que especificar ahora si se trata de un camino en particular o una lista de ellos. Después de que
la última actividad haya acabado (proceso OnEnteringProject del objeto JUNCTION), hay que asignar a la
variable CalculateSlack el valor de 1 para todos los predecesores. Incluya 2 etapas Search, que se van
a utilizar para buscar todos las actividades precedentes, justo después de la etapa Decide. Recuerde que
la etapa Search devuelve una ficha, TOKEN, asociada con el objeto encontrado.
Figura 23.31: Fijando la Variable CalculateSlack de los Caminos Cuando Todas las Actividades se
Hayan Acabado
Paso 9: Una etapa Search se usará para buscar una lista de caminos mientras que la otra se va a utilizar
para buscar un camino en particular dependiendo del valor de PrecedentLinkType. Advierta que no se
ha utilizado una etapa Decide para determinar cuál buscar, puesto que ya se sabía desde el comienzo
de la simulación (al utilizar la propiedad Exclusion Expression).
 En la Figura 23.32 se muestra la etapa Search que buscará en una lista, “ObjectList”, en la que la
propiedad Object List Name se referencia a la propiedad ListPredecessorsLink y la propiedad Limit
se fija en “Infinity” para que se devuelvan todos los caminos que se han encontrado. La expresión
Exclusion Expression ( PrecedentLinkType ==
List.ListLinkPreference.Individual || JunctionType ==
List.ListJunctionType.StartNode) especifica que no se ejecute esta etapa Search si el
tipo es “Individual” o si el cruce es de comienzo, “StartNode”.

Figura 23.32: Buscando una Lista de Caminos
 La Figura 23.33 muestra la etapa Search que buscará un camino en particular; la propiedad Object
Instance Name referencia a PredecessorsLink. La expresión Exclusion Expression
(PrecedentLinkType==List.ListLinkPreference.List || JunctionType
==List.ListJunctionType.StartNode) especifica que no se ejecute esta etapa Search si
el tipo es “List” o si el cruce es de comienzo, “StartNode”.
Figura 23.33: Buscando un Camino en Particular

Paso 10: Las dos ramas “Found” deben llevar a una etapa Assign (Figura 23.31) que cambie el
valor de PrjTimePath.CalculateSlack a 1.
Figura 23.34: Dando Valor a la Variable CalculateSlack

Paso 11: Guarde los cambios y vuelva al modelo.148
Paso 12: Dado que los cruces Junction2 y Junction4 tienen dos actividades precedentes cada uno, se
tendrá que especificar que se necesita una lista. Incluya dos nuevos OBJECTLISTS, de nombre ListJun2
148
Algunas veces, cuando se añaden propiedades a objetos que ya están en el modelo se producen errores que indican que hay algo
sin especificar. Guarde el modelo y vuélvalo a abrir para eliminarlos.
y ListJun4. Para ListJun2, especifique las actividades “A” y “B” y ListJun4 las actividades “C” y “E”
(Figura 23.35).
Figura 23.35: Listas de Actividades para los Cruces Junction2 y Junction4

Paso 13: Para cada cruce, especifique si va a utilizar una lista o valores individuales (Figura 23.36).
El cruce inicial, Junction1, no cambia. Junction3 y Junction5 utilizan un camino individual mientras
que Junction2 y Junction4 utilizan listas.
Figura 23.36: Especificando las Precedencias en los Cruces

Paso 14: Guarde y ejecute el experimento.
Pregunta 11: ¿Qué porcentaje de veces es crítica la actividad A?
Pregunta 12: ¿Cuánto podemos retrasar la actividad A sin que afecte al camino crítico?
Pregunta 13: ¿Cuánto podemos retrasar el comienzo de la actividad C sin que afecte al camino crítico?
Paso 15: Según los resultados obtenidos, es claro que el camino crítico es B D E F dado que estas
actividades tiene los porcentajes más altos de criticidad (Figura 23.37).

Figura 23.37: Resultados del Análisis del Camino Crítico
Sección 23.7: Añadiendo Holgura y Criticidad: Segundo Enfoque
En la sección anterior, se han utilizado los cruces para enviar una señal a los caminos, en los que se realizan
los cálculos sobre holguras y criticidad en función de la terminación más tardía. En esta sección,
utilizaremos un enfoque alternativo y haremos que los caminos monitoricen al cruce al que preceden. En esta
sección se demuestra cómo un objeto puede monitorizar variables de estado de otros objetos, lo que puede
ser muy útil.
Paso 1: Guarde el proyecto con otro nombre.
Paso 2: Seleccione el objeto cruce JUNCTION y elimine las tres propiedades que se han añadido
PrecedentLinkType, PredecessorsLink, y ListPredecessorsLink.
Paso 3: Elimine las dos etapas Search del proceso “OnEnteringProject” e incluya una etapa Assign en la
que se asigna el momento actual (TimeNow) a la variable de estado LatestFinish.
Figura 23.38: Dando Valor a la Variable LatestFinish

Paso 4: Seleccione el objeto PRJTIMEPATH.
Paso 5: En el desplegable Definitions→Properties→Add→Standard Property, incluya una nueva propiedad

STATE, de nombre JunctionLF, que va a permitir especificar la variable a monitorizar. Cambie Category
Name a “Project Management”.

Figura 23.39: Creando una Propiedad de Variable de Estado
Paso 6: Modifique MonitorSlack para monitorizar la propiedad JunctionLF (Figura 23.40).
Figura 23.40: Usando una Propiedad para Monitorizar

Paso 7: Vuelva al modelo y para cada camino, especifique la variable LatestFinish apropiada.
 Por ejemplo (Figura 23.41), la propiedad Junction LF State Variable de los caminos A y B debe ser
Junction2.LatestFinish.
 Para los caminos C y E, D, y F, se debe fijar en Junction4.LatestFinish,

Junction3.LatestFinish, y Junction5.LatestFinish respectivamente.
Figura 23.41: Especificando la Variable de Estado

Paso 8: Guarde el modelo y ejecute el experimento comparando los resultados de los dos sistemas.
Pregunta 14: ¿Obtuvo los mismos resultados?
 Algunas veces, las actividades utilizan recursos compartidos. Los recursos pueden limitar el
número de actividades que se ejecutan en paralelo, lo que puede incidir en la duración total del
proyecto. El uso de recursos compartidos puede incluirse directamente en los caminos,
PRJTIMEPATHS. Sin embargo, decidir qué actividades tienen prioridad puede ser un problema.
 Otro problema a analizar en la gestión de proyectos es cuánto tiempo se puede retrasar el
comienzo de una actividad. Haciendo que una de ellas se retrase puede permitir una mayor
disponibilidad de los recursos críticos, haciendo que la duración total se reduzca.

Capítulo 24
Sistemas Lean: Sistemas Kanban con Operarios
Multidisciplinares
 Cambiando dinámicamente la capacidad de una estación.
 Monitorizando otros objetos
 Usando eventos para generar llegadas en las fuentes
Sección 24.1: Bloqueos Basados en Almacenes: Enfoque Kanban
Una planta de confección que produce camisas de manga larga está compuesta por varias operaciones
secuenciales en serie. Algunas de las operaciones son cuellos de botella. Provocan que se acumule grandes
cantidades de trabajo en curso, sin garantizar que se aumente la capacidad. La compañía está cambiando su
filosofía de producción desde un sistema basado en la previsión (“push system”) a otro basado en la
demanda real (“lean”, tipo de “kanban” que busca el equilibrio de las distintas operaciones). Los puestos
sólo pueden producir si hay hueco para inventario en el siguiente puesto. Este sistema de producción se basa
en un principio de eliminación de desperdicios que dice que no se debe producir en exceso si no hay
hueco.149 La Figura 24.1 muestra el segmento de la línea de producción que vamos a modelizar. Las partes
de la camisa se manda a la primera operación y luego fluyen a través de tres estaciones. El objetivo es limitar
la cantidad de trabajo en curso entre los procesos. El operario que se ocupa de la primera operación ha sido
formado como para que pueda atender la segunda operación. Las operaciones están muy cerca una de la otra.
Inventario Inventario
Manga Estrecha
Estrecha Coser Manga
Manga Manga BH
Figura 24.1: Porción Simple de Tres Operaciones de la Línea de Ensamblaje

Paso 1: Cree un nuevo proyecto de SIMIO. Para el modelo inicial, vamos a asumir que el proceso previo
está esperando a una señal del proceso siguiente para empezar a producir. Vamos a crear una operación
que se cerrará o bloqueará cuando no hay espacio en el almacén siguiente.
Paso 2: Haga una subclase del objeto servidor, SERVER, de nombre BLOCKINGSERVER.
Paso 3: En la sección Definitions→Properties, incluya tres nuevas propiedades que van a ser utilizadas
para identificar los procesos siguientes así como el número máximo de camisas permitidas en la zona de
espera.
 Añada una propiedad State Standard Property, de nombre DownStreamBuffer, y asegúrese

de incluirla en la categoría “Kanban”. Modifique la propiedad Display Name para que sea
149
En un sistema Kanban, las posiciones de inventario están siempre llenas. En este escenario, sólo se produce si hay espacio
disponible, pero el sistema puede vaciarse y el trabajo se acaba. Esta combinación de push y pull se conoce como Syncro MRP. Sólo
se produce si hay espacio y se tiene un pedido.
“Down Stream Buffer.” Esta variable va a permitir que se especifique el nombre del
almacén de la estación siguiente. Fije la propiedad Required Value en “False”.
 Añada una propiedad Expression Standard Property, de nombre MaxBufferSize, y
colóquela en la categoría “Kanban” para especificar el máximo número de unidades que
puede haber en el almacén de la estación siguiente. Cuando se alcance este valor, la
operación dejará de trabajar.
 Añada una propiedad Expression Standard Property, de nombre MinBufferSize y colóquela
en la categoría “Kanban” para especificar el mínimo número de unidades que puede haber
en el almacén de la estación siguiente para desbloquear la operación.
Paso 4: Incluya un MONITOR a partir de la sección Definitions→Elements, de nombre
MonitorDownstreamBuffer, que va a controlar a ver si existe espacio disponible en la operación
siguiente, utilizando una propiedad referenciada.
Figura 24.2: Monitorizando la Operación Siguiente

Paso 5: A partir de la sección Definitions→States, incluya dos variables DISCRETE STATE, de nombre
ShutdownCapacity y Blocked. Se va a utilizar la primera para indicar si la operación debe bloquearse
cuando acaba de procesar una entidad, y la segunda para indicar si la operación está bloqueada o no.
Paso 6: Necesitamos crear un proceso que atienda los eventos que genera MONITOR cuando está
controlando la estación siguiente. A partir de la sección Processes→Process, cree un nuevo proceso, de
nombre OnDownStreamBufferChange. Fije la propiedad Trigger Event en
MonitorDownStreamBuffer.Event.
Figura 24.3: Atendiendo las Señales de la Operación Siguiente

Paso 7: Incluya una etapa Decide que determine si la operación BLOCKINGSERVER tiene que bloquearse. Si
la suma del número de unidades en el almacén siguiente y el número de unidades actualmente en
proceso es mayor o igual que el límite impuesto por la capacidad del almacén, MaxBufferSize, o si la
capacidad de la operación es 0 y el número de unidades en el almacén está todavía por encima del límite
Sistemas Lean: Sistemas Kanban con Operarios Multidisciplinares 227

inferior, MinBufferSize, la operación se bloquea150. En caso contrario, se puede trabajar. La propiedad
Decide Step debe ser “ConditionBased” con la Expression marcada como sigue:151
((DownStreamBuffer + Processing.Contents) >= MaxBufferSize) ||

((Processing.CurrentCapacity == 0) && (DownStreamBuffer + Processing.Contents) >
MinBufferSize)
Paso 8: Si cualquiera de las condiciones es verdadera, necesitamos que la operación deje de trabajar, y lo
hacemos al cambiar la capacidad a 0. Los objetos que tiene capacidad (recursos fijos, FIXED, como
SERVER, COMBINER, RESOURCES, WORKERS, y SEPARATORS así como STATION) tienen una variable de
estado discreta, de nombre CurrentCapacity, con el valor actual de capacidad. Como hacíamos con los
turnos de trabajo, podemos modificar esta variable para cambiar su capacidad disponible. En la Tabla
24.1 se muestran las funciones que se pueden utilizar con estos objetos. Tome nota de que sólo los
recursos fijos pueden devolver el número de unidades que están siendo utilizadas.152
Tabla 24.1: Funciones Disponibles sobre Capacidad

Esta función especifica la capacidad del objeto, valor que no puede ser
Capacity
modificado.
Capacity.Initial Esta función devuelve el valor inicial de la capacidad.
Esta función devuelve el valor que tenía la capacidad antes del último
Capacity.Previous
cambio.
Esta función devuelve el número de unidades de capacidad que no están
Capacity.Remaining
asignadas.
Esta función devuelve el número de unidades de capacidad que están
Capacity.Allocated asignadas. Sólo está disponible para los objetos fijos y no para las
estaciones.
150
Estamos ingnorando aquellas camisas que están moviéndose a la estación siguiente puesto que las operaciones están muy cerca
una de la otra.
151
El operador || es la forma con la que se especifica “O” y el operador && es “Y”.
152
También hay otras funciones asociadas como el mínimo, el máximo, el total, y el número medio de unidades asociadas con un
nivel de capacidad.
 Incluya una etapa Assign que realice 3 asignaciones (Figura 24.2). Si en la operación se están
procesando entidades, no queremos que el puesto deje de funcionar hasta que haya acabado la
entidad sobre la que está trabajando.153 Si fija la capacidad en 0, se parará el procesamiento en el
puesto.
Figura 24.4: Cerrando el Puesto

 Fije la capacidad CurrentCapacity en Processing.Contents, lo que significa que si la
capacidad es 3 y se está procesando una entidad, fije la capacidad en 1 para empezar el cierre o
bloqueo del puesto. Advierta que el proceso “OnCapacityChange” cambiará automáticamente el
valor de Processing.CurrentCapacity para que sea el mismo que la capacidad de la
operación cuando haya un cambio.
 Fije la variable ShutdownCapacity en (Capacity.Allocated > 0), lo que significa que se
está procesando; pero necesitamos cerrar el puesto una vez que el proceso se haya completado.
 Fije la variable Blocked en 1 para indicar que la operación se ha bloqueado. Otros objetos del
modelo pueden utilizar esta información.
Paso 9: Si el almacén siguiente tiene espacio suficiente (rama “False” de la etapa Decide), tenemos que
desbloquear el puesto haciendo que la capacidad, CurrentCapacity, vuelva a su valor inicial,
Capacity.Initial, o a su capacidad actual, y que las variables Blocked y ShutdownCapacity
sean 0 (Figura 24.5). Cuando el sistema no está bloqueado, este proceso todavía puede ser invocado
cuando haya un cambio.
Figura 24.5: Desbloqueando la Operación
153
Vea la sección Comentario para una discussion de cómo cambiar esta limitación.

Paso 10: Finalmente, incluya una etapa Delay de tiempo nulo (Figura 24.6) para que se reordene la
fila de eventos, lo que será necesario cuando se utilice al operario interdisciplinar en una sección
posterior.
Figura 24.6: Retardo para Reordenar la Fila de Eventos

Paso 11: Si se necesita bloquear la operación (ShutdownCapacity es 1), pero se está procesando una
unidad, la actualización de la capacidad tiene que esperar a que se acabe de procesar las entidades. En la
sección Processes→Process, desactive el proceso “OnEnteredProcessing” (Figura 24.7).
Figura 24.7: Modificando el Puesto de Procesamiento

 Justo después de la ejecución del disparador “Processed” (etapa Execute), incluya una
etapa Decide que comprueba si tenemos que convertir la capacidad en 0. Si
ShutDownCapacity es 0 (rama “True”), entonces se continúa con normalidad. En la Figura
24.8, la propiedad Exclusion Expression ha sido especificada
como!DownStreamBuffer.isdefined. Al comenzar la simulación, esta expresión
será evaluada y si el valor resultante es 1, entonces no se va a monitorizar el proceso
siguiente y esta etapa no será ejecutada nunca.
Figura 24.8: Modificando la Capacidad Después de Completar el Procesamiento

 Si hay que anular la capacidad de una operación (rama “False”) incluya una etapa Assign
(Figura 24.9) que reducirá la capacidad de procesamiento de la variable
ShutdownCapacity. Fije la capacidad actual, Processing.CurrentCapacity, en
(Processing.CurrentCapacity>0)*(Processing.CurrentCapacity-1)
que utiliza una condición (se evalúa en 0 o en 1) para asegurar que la capacidad nunca se

hace negativa.154 Fije ShutdownCapacity en (Processing.CurrentCapacity>0),
por lo que tomará el valor 1 si todavía se está procesando, y por tanto, se necesita reducir la
capacidad cuando acabe, o el valor 0 en caso contrario.
Figura 24.9: Actualizando la Capacidad

Paso 12: Finalmente, cree una vista externa del objeto. Como se muestra en la Figura 24.10, el
símbolo original SERVER se coloca entre los nodos de entrada y de salida, después de seleccionarlo del
desplegable Place Symbol en la sección Drawing.
Figura 24.10: Vista Externa de BLOCKINGSERVER

 A partir de la pestaña Drawing, incluya una etiqueta “Floor label” con la palabra “Blocking”
escrita en negrita. En modo 3-D, apriete la tecla Shift y eleve la etiqueta de forma que se
sitúe en lo alto del símbolo.
 A partir de la pestaña Animation, incluya tres filas animadas:
(InputBuffer.Contents, Processing.Contents, y
Outputbuffer.Contents).
 Para poder hacer la verificación del modelo, incluya también cuatro etiquetas de estado. Las
propiedades Expression de cada una de ellas deben ser “Cap”,
Processing.CurrentCapacity, “Block”, y Blocked respectivamente.
Paso 13: Incluya una estadística STATE STATISTIC, de nombre StateStatBlocking, que se usará para
determinar el porcentaje de tiempo en el que la operación BLOCKEDSERVER ha estado bloqueada.
154
Una ventaja de SIMIO es la posibilidad de desarrollar asignaciones complejas.

Figura 24.11: Estadística para Determinar el Porcentaje de Bloqueo
Paso 14: En SIMIO, existen ciertos procesos de decisión sobre asignaciones de recursos (Tabla 24.2).
Estos procesos permiten al modelizador tomar decisiones sobre las peticiones de recursos, las peticiones
de transporte o las peticiones de visitas a un nodo. Los agentes, AGENTS, y los transportadores,
TRANSPORTERS (o vehículos, VEHICLES, y trabajadores, WORKERS) responden a las peticiones de
movimiento mientras que los recursos responden a todas las peticiones. Si los procesos devuelven un
valor menor o igual que 0, la petición será cancelada. La entidad a la que no se va a dar servicio es
colocada en la fila AllocationQueue.
Tabla 24.2: Procesos de Decisión 155 en SIMIO

Procesos de Decisión Descripción
OnEvaluatingAllocation Los procesos se ejecutan cuando se evalúa una petición.
OnEvaluatingRide Los procesos se ejecutan cuando se evalúa una petición de transporte.
OnEvaluatingRiderAtPickup Los procesos se ejecutan cuando se evalúa una carga de transporte por el
transportador.
OnEvaluatingRiderReservation Los procesos se ejecutan cuando se evalúa una reserva de transporte por
el transportador.
OnEvaluatingVisitRequest Los procesos se ejecutan cuando se evalúa una petición de visita.
 Si la operación está bloqueada, las entidades no deberían ser capaces de conseguir capacidad, sobre
todo si la operación está procesando una última entidad. Primero, desactive el proceso
“OnEvaluatingAllocation”. Si la condición es “False” entonces la operación rechazará la petición.
Añada la condición “!Blocked &&” en la expresión (Figura 24.12) para asegurarse que la
operación no está bloqueada.156
Figura 24.12: Asegurando que se Rechazan las Peticiones si la Operación está Bloqueada
Paso 15: Guarde el modelo actual.
155
Los procesos de decision sólo pueden contener las etapas Decide, Search, y Assign, y la asignación Token.ReturnValue=0
rechaza las peticiones.
156
!Blocked es “1” si la operación no está bloqueada (Blocked == 0).
Sección 24.2: Modelizando el Sistema
Se necesita probar el sistema completo. Vamos a comparar este nuevo sistema con almacenes con el sistema
push (Figura 24.13). Específicamente, necesitamos ver cómo los sistemas reaccionan ante reducciones en los
tiempos de proceso (lead time) cuando se incluyen nuevos trabajos o cuando cambia la demanda. Para
simplificar la descripción denominaremos las tres operaciones de procesamiento como Proc1, Proc2, y Proc3
en vez de los nombres verdaderos, que pueden no ser del todo familiares.
Figura 24.13: La Comparación en Paralelo

Paso 1: Incluya una MODELENTITY, de nombre Parts. Añada un símbolo adicional y coloréelo de rojo; será el
utilizado como nuestra pieza de control. Es una pieza que hemos creado para facilitar el seguimiento y la
comparación en términos de producción total o tiempos en el sistema.
Paso 2: Modelicemos primero el sistema Push, incluyendo 3 SERVER, de nombre SrvProc1, SrvProc2, y
SrvProc3. Conéctelos con CONNECTORS.
Paso 3: Modelicemos ahora el sistema balanceado incluyendo 2 BLOCKINGSERVERS, de nombre BSrvProc1

y BSrvProc2 y 1 SERVER, de nombre SrvProc3New. Podríamos haber utilizado otro BLOCKING SERVER
pero así podemos ilustrar cómo nuestro nuevo objeto puede controlar también lo que sucede en otros
tipos de objeto.
Paso 4: Fije el tiempo de proceso para el primer procesamiento en Random.Pert(10, 11, 15)
minutos, para el segundo en Random.Pert(60, 65, 74) minutos, y para el tercero en
Random.Pert(38, 42, 48) minutos para ambos sistemas.
Pregunta 15: ¿Qué operación de procesamiento será el cuello de botella?
Paso 5: Para BSrvProc1, fije la propiedad Max Buffer Size en “8” y Min Buffer Size en “2”. Fije la
propiedad Down Stream Buffer en BSrvProc2.InputBuffer.Contents, para controlar el
almacén del siguiente proceso. Tendrá que incluir este información dado que todas las variables de
estado no tienen por qué estar incluidas en los desplegables.

Figura 24.14: Proceso 1 según el Sistema Kanban
Paso 6: Repita el último paso para el objeto BSrvProc2, pero incluyendo en la propiedad Down Stream
Buffer la variable SrvProc3New.InputBuffer.Contents.
Paso 7: Dado que el resto del sistema de fabricación está fuera de los límites del modelo, nos aseguraremos
que hay suficiente trabajo (cinco piezas) en la primera operación de cada sistema. Incluya una fuente
SOURCE, de nombre SrcParts, que han de responder a un evento para crear llegadas. Cada vez que una
pieza sale de la primera operación, otra llegará, como se muestra en la Figura 24.15. Fije la propiedad
Initial Number of Entities en “5” para inicializar el sistema. Después de estas primeras llegadas, la
propiedad Arrival Mode fijada en “On Event” hará que se cree una nueva llegada cada vez que ocurre el
evento Output@SrvProc1.Exited.
Figura 24.15: Generando una Cantidad Constante de Trabajo en la Primera Operación

Paso 8: Copie el objeto SrcParts, y llame a la copia SrcPartsNew; cambie la propiedad Event Name a
Output@BSrvProc1.Exited.
Paso 9: Conecte las dos Fuentes con sus respectivas primeras operaciones utilizando CONNECTORS.
Paso 10: Ahora que tenemos piezas, necesitamos crear también la pieza que nos va a servir para
comparar. Esta pieza nos va a servir para indicar un cambio en el tipo de pieza, lo que será un buen
indicador del tiempo que se tarda en vaciar el sistema antes de empezar con el nuevo tipo.
 Incluya una fuente, SOURCE, de nombre SrcPartMark, y establezca que tiene que liberar
una entidad cuando se lleven 12 horas de simulación.

Figura 24.16: Estableciendo la Llegada de la Pieza de Control
 Añada una asignación State Assignment que asigna a la variable
ModelEntity.Picture el valor de “1” para indicar que es una pieza diferente y para
cambiar la imagen.
Figura 24.17: Cambiando la Propiedad Imagen

 Para garantizar un efecto idéntico en los dos sistemas, incluya un separador SEPARATOR, de
nombre SepCopier, para que se cree una copia de la entidad de control.
Figura 24.18: Haciendo una Copia Exacta Para Cada Sistema

 Conecte SrcPartMark con SepCopier utilizando conectores y conecte ParentOutput de
SEPARATOR con SrvProc1 y MemberOutput con BSrvProc1.
Paso 11: Cuando las piezas han acabado la última operación, van a ser enviadas a uno de los cuatro
sumideros, dependiendo del sistema del que proceden y de si es o no la entidad de control. Se utilizan
cuatro sumideros para facilitar la obtención de estadísticas. Incluya 4 SINK, de nombre
SnkNormalMark, SnkNormal, SnkNewSystem, y SnkNewSysMark (Figura 24.13).157
 Conecte SrvProc3 con SnkNormalMark con un CONNECTOR, con la propiedad Selection

Weight fijada en ModelEntity.Picture.
 Conecte SrvProc3 con SnkNormal con un CONNECTOR, con la propiedad Selection Weight
fijada en ModelEntity.Picture.
157
En lugar de utilizar dos sumideros para cada sistema, podríamos haber utilizado un sumidero y una estadística TALLY para grabar
el momento en que la entidad de control llega al sumidero.

Paso 12: Repita el último paso para los otros dos sumideros, conectando SnkNewSysMark.
Paso 13: Incluya una etiqueta de estado para mostrar lo que contiene el almacén de la segunda
operación, SrvProc2.Inputbuffer.Contents, dado que las filas animadas no se pueden alargar
lo suficiente (como mucho 8 entidades).
Paso 14: Guarde el modelo y ejecútelo durante un período de 4 días. Eventualmente, deberíamos
montar un experimento puesto que sólo tenemos una observación correspondiente con la entidad de
control.
Pregunta 16: ¿Se bloquean las operaciones cuando los almacenes siguientes llegan al máximo permitido?
Pregunta 17: ¿Cuántas piezas fueron acabadas en cada sistema? ¿Sorprendido?
Pregunta 18: ¿Cuánto tardan en ser procesadas las piezas en cada sistema?
Pregunta 19: ¿Cuál es el tiempo de procesamiento en cada sistema, determinado por el tiempo en el
sistema de la entidad de control?
Pregunta 20: ¿Cuántas piezas hay en InputBuffer de SrvProc2 al final de la simulación?
Pregunta 21: ¿Qué porcentaje de tiempo han estado bloqueadas las operaciones?
Paso 15: Cambie la capacidad del segundo proceso a 2 en cada sistema. Guarde y ejecute el modelo.
Pregunta 22: Compare las respuestas a las mismas preguntas con los nuevos valores, en especial en
cuanto a los porcentajes de bloqueo?
Sección 24.3: El Operario Formado Interdisciplinarmente
Los resultados muestran que la primera operación está bloqueada mucho tiempo, lo que significa que el
operario tiene tiempo para realizar otras tareas. En este momento, ya no nos interesa la comparación entre los
dos sistemas. La parte correspondiente al sistema Push puede ser borrado. Recuerde que el operario de la
primera operación ha sido formado también para atender en la segunda operación, que resulta que es el
cuello de botella.
Paso 1: Guarde el modelo con un nombre distinto y asegúrese que la capacidad de la segunda operación
BSrvProc2 es “2”.
Paso 2: Incluya dos TRANSFERNODES, de nombre TProc1 y TProc2 y posiciónelos debajo de las operaciones
correspondientes (Figura 24.19). Conecte los dos nodos de transferencia entre sí con un TIMEPATH
bidireccional de 10 minutos de duración.

Figura 24.19: Añadiendo el Circuito Para el Operario Multidisciplinar
Paso 3: Incluya 2 WORKERS, de nombre WrkrNotCrossTrained y WrkrCrossTrained. Fije la propiedad
Initial Node en “TProc2” para el operario normal y “TProc1” para el multidisciplinar. Coloree el
operario multidisciplinar de verde para poder distinguirlo del otro operario, mientras se mueve entre las
dos operaciones. El operario normal, WrkrNotCrossTrained, sólo trabajará en la segunda operación
mientras que el operario multidisciplinar, WrkrCrossTrained, puede trabajar tanto en la primera como
en la segunda operación.
Paso 4: Incluya una nueva LIST de objetos, de nombre ListProc2, que contenga el nombre de los dos
operarios (Figura 24.20). La lista será utilizada para seleccionar uno de los operarios cuando la primera
operación está bloqueada.
Figura 24.20: Creando una Lista de Recursos Para la Segunda Operación

Paso 5: Necesitamos incluir la posibilidad de que la segunda operación utilice cualquiera de los dos
operarios. Incluya los disparadores Processing y Exited, y cree dos nuevos procesos, de nombre
“BSrvProc2_Processing” y “BSrvProc2_Exited.”
 Para el proceso “BSrvProc2_Processing”, incluya una etapa Seize para apresar un operario de la
lista ListProc2 (Figura 24.21). El valor por defecto “PreferredOrder” de la propiedad Selection
Goal es el correcto dado que WrkrNotCrossTrained debe ser seleccionado antes si los dos están
disponibles. Asegúrese de que la propiedad Request Visit tiene el valor “To Node” y la propiedad
Node Name el valor “TProc2” para forzar a que los operarios lleguen a la segunda operación antes
de que se empiecen a procesar.

Figura 24.21: Apresando Cualquiera de los Operarios y Asegurando que se Mueven Hacia TProc2
 Una vez que la operación ha sido acabada y la entidad sale de BSrvProc2, incluya una etapa
Release para liberar al operario y colocarlo en la lista de recursos disponibles (Figura 24.22).
Figura 24.22: Liberando a los Operarios

Paso 6: Necesitamos añadir la posibilidad de que la operación BSrvProc1 pueda apresar al operario
multidisciplinar, WrkrCrossTrained, para realizar el trabajo. Incluya los procesos
“BSrvProc1_Processing” y “BSrvProc1_Exited” en los disparadores Processing y Exited.
 Al contrario que lo que sucede en la segunda operación, en la primera operación se apresará un

recurso en particular (WrkrCrossTrained), al que se obliga a visitar el nodo TProc1 antes de
empezar a procesar la entidad (Figura 24.23).

Figura 24.23: Apresando al Operario Multidisciplinar en la Operación 1
 En el proceso “BSrvProc1_Exited”, incluya una etapa Assign que cambie la prioridad
ModelEntity.Priority a “2”, lo que servirá para indicar que la entidad está siendo procesada
en la segunda operación. Finalmente, use una etapa Release para liberar al recurso utilizado
(Figura 24.24).
Figura 24.24: Liberando al Operario Multidisciplinar en la Operación 1

Pregunta 23: ¿Qué observa en relación con el operario multidisciplinar? ¿Se comporta como esperaba?
Paso 8: El problema es que el operario está atendiendo las peticiones según su orden de llegada, lo que
significa que el operario se va a mover alternativamente entre las dos operaciones. Sin embargo,
queremos que el operario esté siempre en la primera operación hasta que la operación se bloquea.

Seleccione el operario WrkerCrossTrained e incluya un proceso, de nombre “WrkerCrossTrained_
EvaluatingSeizeRequest” para que sea ejecutado desde el disparador Evaluating Seize Request (Figura
24.25). El disparador se invoca desde el proceso “OnEvaluatingAllocation” (véase Tabla 24.2 para más
información). Si el valor de Token.ReturnValue es 0, en cambio, la petición será rechazada.
 Si la petición viene de la segunda operación (ModelEntity.Priority==2) y la primera

operación no está bloqueada (BsrvProc1.Capacity>0) o la capacidad actual de BsrvProc2 es
menor que 2, la petición será rechazada. Si la petición viene de la primera operación y el primer
proceso está bloqueado, la petición también debe ser rechazada.
 Incluya una etapa Decide que se basa en una condición con la que se decide aceptar o rechazar la
petición.
(ModelEntity.Priority==2&&(Bsrvproc1.Capacity>0||Bsrvproc2.Capacity<2))
|| (ModelEntity.Priority==1 && Bsrvproc1.Blocked)
 Si se necesita rechazar la petición, fije el valor de retorno del TOKEN en “False”.
Figura 24.25: Rechazando Peticiones para el Operario Multidisciplinar

Paso 9: Guarde el modelo y ejecútelo durante un período de cuatro días
Pregunta 24: ¿Ha estado el operario multidisciplinar trabajando en la primera operación hasta que la
operación se bloquea y se dirige entonces hacia la segunda operación?
Pregunta 25: ¿Cuánto tarda en procesarse las piezas? ¿En comparación con el modelo anterior?
Pregunta 26: ¿Cuál es el tiempo total o lead time, determinado por el tiempo en el sistema de la entidad de
control?
Pregunta 27: ¿Qué porcentaje del tiempo han estado bloqueadas las operaciones? ¿Y en comparación con
el modelo anterior?

 En lugar de esperar a que la operación acabe el proceso, se podría haber utilizado una etapa
Interrupt para parar la operación. De hecho se podía haber añadido una opción para
interrumpir o no, así como decidir qué hacer con la entidad que ha sufrido la interrupción. Para
nuestro escenario, se acabará de procesar la entidad sin realizar la interrupción.
 Tampoco se estudia el número de entidades que se mueven hacia el almacén siguiente. Sin
embargo, una propiedad similar a la empleada podría ser usada. En el objeto correspondiente a la
cadena de suministros del Capítulo 22, el nodo Input del proceso usaba una etapa Decide que
incluía el número que llegaba a dicho nodo de entrada.
 Finalmente, igual desea crear un verdadero sistema Pull. El objeto SUPPLYINVSERVER del
Capítulo 22 puede ser fácilmente modificado. En lugar de tener un período de reposición, un
controlador debe hacer que la revisión sea continua con el nivel de inventario fijado en el
número de Kanbans. También podría incluirse pedidos no atendidos. En este caso, podría llenar
los Kanbans, incluso si no tiene suficiente inventario. Las órdenes de reposición serían las
señales Kanban.
 Se debe añadir una etapa Assign en el proceso “OnInitialized” de BLOCKINGSERVER lo que
habilitará o deshabilitará el controlador si el almacén siguiente, DownstreamBuffer, ha sido
especificado o no (MonitorDownstreamBuffer.Enabled =
DownStreamBuffer.isdefined).
 Advierta que actualmente el estado de bloqueo se comprueba solamente cuando hay un cambio
en el almacén siguiente. Podríamos hacer la comprobación antes de empezar una unidad. Incluya
una etapa Execute antes de la etapa Seize en los procesos “OnEnteredProcessing” y
“OnEnteredInputBuffer” para que se ejecute el proceso “OnDownStreamBufferInput”.
Figura 24.26: Realizando la Comparación Antes de Apresar un Recurso

Capítulo 25
Múltiples Productos: Cadena de Suministro Bis
 Usando vectores de estado en vez de variables
 Buscando en tablas
 Asociando tablas automáticamente a hojas de cálculo
Sección 25.1: Cambiando las Propiedades para Manejar Múltiples SKUs
En el Capítulo 12 se empezó a utilizar una cadena de suministros muy sencilla con un centro de distribución
que realizaba tareas de reposición de un único producto y para una tienda. En el Capítulo 22 encapsulamos el
sistema para poder modelizar muchos segmentos diferentes de una cadena de suministros. En ambos casos se
asumía que existía un único producto o stock keeping unit (SKU). En este capítulo se va a ampliar el modelo
del Capítulo 12 para incluir múltiples tipos de producto. La mayoría de las empresas tienen muchos SKUs
que se almacenan en un centro de distribución. El patrón de SKU cambia con el tiempo (el número de tipos
diferentes de SKU como las cantidades de pedido así como las cantidades máximas en inventario). Por eso,
la habilidad para cambiar rápidamente la información es importante, y se facilita con el uso de las hojas de
cálculo.
Paso 1: Dado que el sistema es exactamente igual excepto por la existencia de muchos SKU, abra el modelo
del Capítulo 12 y guárdelo con otro nombre.
Paso 2: Recuerde que la entidad se utilizaba para representar tanto los pedidos que recibía el centro de
distribución así como los pedidos que se mandaban a los proveedores. Se añadió una variables de estado
discreta, OrderAmt, para especificar la cantidad del pedido. Seleccione la entidad en el panel
[Navigation]. En Definitions →States, incluya una variable DISCRETE STATE, de nombre SKUID, para
indicar el tipo de SKU que se está pidiendo.
Paso 3: Vaya a la sección Definitions →States del modelo principal. La variable DISCRETE STATE puede
tener diferentes dimensiones (Tabla 25.1), aunque por defecto es un único valor, “Scalar.”
Tabla 25.1: Diferentes Dimensiones de la Variables de Estado Discretas

Dimensión Descripción
Scalar/Escalar Es una variable simple a la que sólo se le puede asignar un valor.
Es una variable con un vector de valores en una dimensión, similar a una
Vector/Vector
columna en una hoja de cálculo.
Es una variable con un vector de valores en dos dimensiones, similar a una hoja
Matrix/Matriz
de cálculo completa.
Es una variable con una matriz dinámica que toma sus tamaño y valores de una
Table/Tabla
tabla.
 Cambie la propiedad Dimension de las variables Inventory y WIP a “Vector” con 100 filas para
indicar el máximo número posible de diferentes SKU que el modelo puede manejar.158 (Esto produce
una serie de errores que se resuelven a continuación.)
158
El valor “Table” podría haber sido utilizado, y la tabla haber sido una hoja de cálculo, pero en este caso se requería mantener
varias hojas.
Paso 4: Incluya dos variables DISCRETE STATE con una dimensión “Scalar”, de nombre NumSKUs, para
indicar el número de SKUs en el sistema, y TotalInventory, que es la suma de todos los niveles
individuales de inventario.
Paso 5: En Definitions→Elements, cambie la propiedad State Variable Name de StateStatInv a

TotalInventory en vez de Inventory, dado que una estadística de estado sólo puede controlar una fila
de una variable vectorial. Con este cambio, la variable estadística controlará el nivel de todo el
inventario.
Paso 6: Añada etiquetas de estado para guardar los valores de TotalInventory y de NumSKUs (Figura
25.1). La antigua etiqueta de estado que estaba relacionada con el inventario (la etiqueta a la derecha de
la etiqueta “Current Inv”) dice ahora “Inventory”. Cambie Expression a Inventory[1] para indicar
que se muestra el valor correspondiente a la primera fila.159 Puede añadir 5 etiquetas más a la derecha
para mostrar los valores de las filas segunda a sexta.
Figura 25.1: Actualizando las Etiquetas de Estado.
Sección 25.2: Asociando una Tabla a Una Hoja Excel
Recuerde que en el modelo original se especificaba el inventario inicial, el punto de pedido y la cantidad
máxima en inventario. Con el potencial de disponer de 100 tipos diferentes de SKUs, especificar esta
información a través de propiedades individuales es dificultoso. Se va a especificar la información en una
TABLE.
Paso 1: En la sección Data→Tables, incluya una DATA TABLE, de nombre TableSKU. Incluya 4
propiedades Integer Standard Properties, de nombre ID, InitialInventory, ReOrderPt y
OrderUptoQty y 1 propiedad Real, de nombre Mixture, que va a representar el mix de producto o el
porcentaje de demanda de cada SKU (Figura 25.2). La columna ID se va a usar para referenciar el
número de fila en los vectores de variables Inventory y WIP.
Figura 25.2: Montando una Data Table para Caracterizar cada SKU
Paso 2: En este punto, ya se podría incluir toda la información necesaria. Sin embargo, los datos cambian a
menudo y la información puede encontrarse en nuestro ERP. La posibilidad de relacionar la tabla de
SIMIO con una hoja Excel es muy conveniente. La Figura 25.3 muestra las opciones para interactuar con
una hoja de cálculo. Se pueden importar los datos, “Import From”, tanto de un fichero (CSV, Comma
Separated) como de una hoja Excel. El proceso es manual y tiene que ser realizado cada vez que la hoja
cambia. Con la opción “Bind To”, se asocial la tabla a la hoja Excel o al fichero CSV y la tabla de
SIMIO se actualiza automáticamente al comienzo de la simulación.
159
El uso de [] para indicar el número de fila es muy común en otros lenguajes de programación.
Múltiples Productos: Cadena de Suministro Bis 243

Figura 25.3: Importando, Exportando, y Asociando Datos a una Fichero Externo
 Tanto si está importando como asociando, primero necesita exportar, “Export”, la tabla, para
que se determine correctamente en Excel su estructura o tamaño. Haga clic en el botón
Export para exportar la tabla guardando el fichero CSV como TableSKU.160
 Abra el fichero TableSKU.csv en Excel y guárdelo como un fichero Excel, de nombre
TableSKU.xls o TableSKU.xlsx dependiendo de la versión de Excel.
 Incluya 3 diferentes SKUs con la información que se muestra en la Figura 25.4.
 Guarde el fichero Excel.
Figura 25.4: TableSKU en Excel

Paso 3: Vuelva a SIMIO, y haga clic en el botón Excel dentro de la opción Bind To, lo que abre la ventana
de diálogo que se muestra en la Figura 25.5. Seleccione el fichero Excel en la propiedad File Name.
Tiene la opción de seleccionar una hoja en particular. Haga clic en Ok para asociar la tabla de SIMIO a
la hoja “TableSKU”. En este punto, no se va a importar ningún dato hasta que se ejecute la simulación,
puesto que se trata de una referencia absoluta a un fichero Excel. Si el fichero se cambia de directorio, o
si el modelo se comparte con alguien, la asociación tiene que ser restablecida. 161
:
Figura 25.5: Ventana de Diálogo para Importar o Asociar
160
El sistema sólo exporta a ficheros CSV, ficheros que se pueden abrir en Excel.
161
Para hacer cualquier cambio en la tabla, tiene que quitar la asociación “Remove Binding”.
Sección 25.3: Cambiando los Procesos para Manejar Múltiples SKUs
Hemos modificado las propiedades para manejar múltiples SKUs y hemos creado una tabla para caracterizar
toda la información sobre los SKUs. Necesitamos también modificar los procesos para utilizar correctamente
los cambios sobre el mix de productos. Esencialmente, tenemos que cambiar las variables escalares por
vectores en los sitios en los que antes usábamos las variables Inventory y WIP.
Paso 1: El proceso “OnInitialized” se utilizaba para fijar el valor inicial de inventario pero ahora necesita
modificarse para inicializar los inventarios de cada SKU así como la variable que refleja el inventario
total. La etapa Search se usaba para buscar en las filas de entidades en el Capítulo 9 y en colecciones
de objetos (recursos) en el Capítulo 16, pero también se puede utilizar para buscar dentro de una tabla.
Para cada fila que se encuentre, se asignará al TOKEN el número de fila, de manera similar a la forma en
que la etapa Set Table se usaba para asignar un fila en particular a una entidad (Capítulo 7).
 Incluya una etapa Search y mueva la etapa Assign a la rama “Found”. La etapa Search buscará
en cada fila y nos permitirá asignar el valor inicial de inventario (Figura 25.6).
Figura 25.6: Modificando el Proceso OnInitialized para Inicializar el Inventario de cada SKU
 Haga que la búsqueda se realice en todas y cada una de las filas de la tabla (Tabla 25.2). La
propiedad Return Value es una expresión que se evalúa para cada fila de la tabla. La etapa Search
devuelve entonces la suma de todos los valores.
Tabla 25.2: Buscando en la Tabla

Propiedad Descripción
Collection Type Se dice cómo buscar ( “TableRows”)
Table Name El nombre de la tabla.
La dejamos en blanco para buscar en todas las
Match Condition
filas.
El valor “1” indica que se sumarán todos los
Return Value
valores individuales.
Máximo número de tipos de SKUs que se
Limit permiten, en función del dimensionamiento del
vector.
 Modifique la etapa Assign para asignar el número correcto de la fila así como TotalInventory. El
TOKEN asociado con la rama “Found” se asigna al número de fila encontrado en la tabla. Fije la
propiedad Row como TableSKU.ID y New Value como TableSKU.InitialInventory. En
la propiedad Assignments (More), fije TotalInventory como TotalInventory +
TableSKU.InitialInventory para calcular el inventario como suma de todos los valores
individuales.

Figura 25.7: Asignando los Inventarios Individuales y el Inventario Total
 Incluya una etapa Assign en la rama “Original” para que se asigne el número de SKUs. La suma
de las expresiones Return Value será calculada a partir de ReturnValue del TOKEN (Figura 25.8).
Figura 25.8: Asignando el Valor de la Ficha al Número de SKUs

Paso 2: Recuerde que el proceso “SrvDC_Processed” se usa para actualizar los niveles de inventario después
de que se haya acabado el proceso de fabricación. Modifique la etapa Assign para actualizar los
inventarios individuales de cada SKU. El pedido recibido incluirá el tipo de SKU en la variable SKUID.
El único cambio es la especificación del nivel individual de inventario y de WIP
(Inventory[ModelEntity.SkuID] y WIP[ModelEntity.SkuID]) como se muestra en la
Figura 25.9). Se necesita también una asignación adicional para actualizar el nivel del inventario total.
Figura 25.9: Actualizando los Inventarios cuando Llegan Pedidos de Reposición

Paso 3: Modifique el proceso “SrvOrderProcessing_Processed” para utilizar la variable vectorizada.
 La estadística de observación, TALLY, que se utiliza para guardar el nivel de servicio corresponderá
con el nivel de servicio general para todas las SKU. Modifique la etapa Tally para particularizarla
para cada SKU (Inventory[ModelEntity.SkuID])
Figura 25.10: Actualizando el Nivel de Servicio

 La etapa Assign se utiliza para reducir el nivel de inventario. El inventario total se reducirá en el
mínimo entre el tamaño de pedido y el nivel actual de inventario.
Figura 25.11: Reduciendo el Inventario Total

 El inventario individualmente se actualiza utilizando la fila correcta.
Figura 25.12: Actualizando los Niveles Individuales

Paso 4: Finalmente, se necesita modificar el sistema de reposición para los SKUs de forma individual. Como
para el proceso “OnInitialized”, se va a utilizar una etapa Search para cada SKU, para determinar si se
necesita realizar un pedido.
Figura 25.13: Modificando el Sistema de Reaprovisionamiento

 Copie la etapa Search del proceso“OnInitialized” e inclúyala antes de la etapa Decide.
Modifique la propiedad Limit para que sea NumSkus y cambie la propiedad ReturnValue a
“Empty”.
 Copie todas las etapas en la rama “Found”.
 Cambie la propiedad Expression de la etapa Decide para que incluya el vector Inventory y
el punto de pedido (Inventory[TableSKU.ID]<TableSKU.ReorderPt).
 Modifique la etapa Assign para que se fijen los valores de la variables incluidas en la
Tabla 25.3.

Tabla 25.3: Creando la Cantidad de Pedido y Actualizando el Nivel Individual de WIP
Variable de Estado Descripción
ModelEntity.SKUID TableSKU.ID
ModelEntity.OrderAmt Math.Max(0,
TableSKU[ModelEntity.SKUID].OrderUpToQty -
Inventory[ModelEntity. SKUID]-
WIP[ModelEntity.SKUID])
WIP[ModelEntity.SKUID] Wip[ModelEntity.SKUID]+ModelEntity.OrderAmt
Sección 25.4: Modificando el Sistema
Modifique el sistema actual: incremente las capacidades de las operaciones así como especifique la creación
de pedidos en las tiendas.
Paso 1: Cambie la propiedad Initial Capacity de las tres operaciones, SERVERS, a “5”.
Paso 2: Seleccione la fuente SrcOrders y borre las asignaciones originales sobre la cantidad de los pedidos.
Incluya un disparador “Created” que va a generar los pedidos para cada SKUs (Figura 25.14: Creando
Pedidos desde las Tiendas para cada SKU).
Figura 25.14: Creando Pedidos desde las Tiendas para cada SKU
 Copie la etapa Search del proceso “InventoryReview” y modifique la propiedad StartingIndex para
que tome un valor de “2”, dado que ya tenemos una entidad.
 Copie la etapa Create del mismo proceso y colóquela en la rama “Found”.
 En la rama “Created”, incluya una etapa Assign que determina el tipo de SKU Type
(TableSKU.ID) y la cantidad en función de la mezcla o mix de producto
(Random.Poisson(TableSKU.Mixture)).

Figura 25.15: Calculando la Cantidad de Pedido y el Tipo de SKU
 Después de la etapa Assign, incluya la etapa Transfer para transferir la entidad creada al nodo
Output de SrcOrders.
Figura 25.16: Transfiriendo las Entidades Recién Creadas

 La lógica previa ayudaba a generar pedidos de los tipos de SKU, numerados entre el 2 y el
número de SKUs. Copie la etapa Assign en la rama “Original” y cambie TableSKU a
TableSKU[1] en todos los sitios de forma que se busque explícitamente en la primera fila.
Paso 3: Guarde el modelo y ejecútelo observando lo que sucede.
Pregunta 28: Después de ejecutar el sistema, ¿se actualiza la tabla de datos?
Pregunta 30: ¿Cuál es el nivel de inventario medio y el nivel de servicio?
Paso 4: Abra el fichero Excel otra vez, y añada cinco filas más (Figura 25.17: Añadiendo Cuatro Nuevas
SKU en la Hoja de Cálculo).

Figura 25.17: Añadiendo Cuatro Nuevas SKU en la Hoja de Cálculo
Paso 5: Guarde el modelo y vuélvalo a ejecutar.
Pregunta 31: ¿Se han incluido las nuevas SKUs en el sistema?
Pregunta 33: ¿Cuál es el nivel de inventario medio y el nivel de servicio?
 Los pedidos OrderAmt podrían haber sido también un vector en vez de un escalar.
 Los mismos conceptos de este capítulo se pueden incorporar en el objeto SUPPLYINVSERVER del
Capítulo 22, referenciando la tabla desde una propiedad.
 El proceso “OnInitialized” se puede utilizar para fijar la variable CurrentCapacity de las
tres operaciones para incluir el número de productos, NumSKUs.

Índice
A
Add Additional Symbol
E
 ModelEntity, 63 Efficiency Table, 38
 Server, 60 Elements, 42
Add-On Process Elements (Elementos)
 Trigger Reached End, 99  Failure (Fallo), 91
Add-On Process Triggers (Disparadores), 44  Material (Material), 66
Allocation Request  Monitor (Controlador), 75
 Seize, 244  Output Statistic (Estadística de Salida), 67
Allocation Requests, 236  Process (Proceso), 173
Animation, 6  RoutingGroup (Grupo de Destinos), 161
Animation (Animación)  State Statistic (Estadística de Estado), 67
 Circular Gauge, 77  Station (Estación), 154
 Status Label, 86  Storage (Almacén), 182
 Status Labels, 72  Tally Statistic (Estadística de Observación), 46
 Status Pie, 66  Timer (Temporizador), 69, 104
 Status Plot, 39 Entities Per Arrival, 92
Event (Evento), 80
B Experiment (Experimento)
 Response, 108
BasicNode (Nodo Básico), 28  Response Chart, 110
 Scenarios, 108
C  Subset Selection, 110
Experiment Scenarios, 15
Candidate, 38 Expression Editor, 5
 .Node.NumberRoutingIn, 38 External Node, 170
 .Server.Inputbuffer.Contents, 38 External View, 170
 .Server.Processing.Contents, 38  InputNode, 179
Changeovers (Cambios), 65  OutputNode, 179
Combiner
 Match Members, 37
Combiner (Agrupador, Combinador), 36
F
Conector (Conector), 29 Failure
Conveyor (Cinta Transportadora)  Active Function. See Elements Failure
 Accumulating, 56 Function Table, 39
 Entity Alignment, 57
 Non-Accumulating, 56
Create Symbol, 74
G
Google 3D Warehouse, 13
D
Data Table
I
 Row Specification, 23 Input Location Functions, 133
Debugging (Buscar Errores), 85
 Break Point Button, 139
 Breakpoint, 86
K
 Dashboard Window, 86 Kanban Approach, 230
 Model Trace, 85
 Status Label, 86
 Watch, 86
L
Detached Queue, 33 Level State (Variable de Nivel), 75
Draw Queue, 40 List (Lista), 65
Drawing  Node, 95
 Create Symbol. See Create Symbol  Objects, 118
Drawn to Scale, 13  Strings, 65
Índice 251
M  Bidirectional, 32
 Selection Weight Property, 19
Material (Material), 66  Travel Time, 38
Math (Matemática), 91 Pivot Grid, 15, 221
 Epsilon, 140 Priority
 If, 91  InitialPriority Property, 22
 Is, 147  Priority State Variable, 22
 Max, 105 Process
 Min, 105  Create Process, 46
Model (Modelo), 2  OnInitialized, 77
ModelEntity  Override (Desactivar), 162
 Initial Desired Speed, 27  Processed, 63
 Initial Sequence, 31  Processing, 49
ModelEntity (Entidad), 2  Restore (Restablecer), 162
Modelo Process Steps (Etapas de Proceso)
 Model Properties, 2  Assign (Asignar), 45
Modelos  Create (Crear), 107
 Aeropuerto, 12  Decide (Decidir), 47
 Aeropuerto Bis, 18  Delay (Retrasar), 49
 Almacén, 152  Destroy (Destruir), 205
 Cadena de Suministro con Múltiples Productos, 246  EndTransfer (Acabar Transferencia), 172
 Cadena de Suministros Simple, 102  Execute (Ejecutar), 155
 Cadenas de Suministros Avanzada, 194  Fire (Disparar), 82
 Carril de Transferencia, 56  Insert (Insertar), 182
 Célula de Fabricación, 27  Interrupt (Interrumpir), 84
 Célula de Fabricación bis, 51  Release (Liberar, Soltar), 50
 Clínica de Cuidados Intensivos, 88  Remove (Retirar), 84
 Clínica de Cuidados Intensivos bis, 94  Remove (Sacar), 182
 Clínica Veterinaria, 117  Ride (Transportar), 148
 Clínica Veterinaria bis, 126  Route (Dirigir, Enviar), 161
 Clínica Veterinaria Tres, 131  Search (Buscar), 83, 146
 Ensamblaje de Tarjetas de Memoria, 35  Seize (Apresar, Agarrar), 49
 Ensamblaje de Tarjetas de Memoria bis, 44  Set Node (Fijar Nodo), 84
 Ensamblaje de una Maqueta, 62  Set Table (Fijar Tabla), 55
 Gasolinera, 78  Tally (Contar), 46
 La Tienda de Helado, 3  Transfer (Transferir), 84
 Línea de Camisas, 185  UnBatch (Desagrupar), 48
 Objeto Delay (Retardo), 159  Wait (Esperar), 81
 Objeto Delay bis, 168 Project Management (Gestión de Proyectos)
 Planificación de Procesos/Gestión de Proyectos, 211  Critical Path (Camino Crítico), 211
 Sistemas Kanban con Operarios Multidisciplinares,  Earliest Finish (Finalización Más Temprana), 212
230  Latest Finish (Finalización Más Tardía), 212
 Sucursal de un Banco, 141  Percent CP(Critical Path) (Criticidad), 212
 Tanque Simple, 74  Slack (Holgura), 212
 Una Célula de Fabricación, 178 Properties (Propiedades)
Monitor (Controlador, Monitorizador), 70  Element Reference, 173
Multiple SKUs, 246  Object Reference, 126
 Repeat Group, 176
O  Standard Property, 22
Property, 23
OptQuest, 112
 Constraints, 114
R
P Ranking y selección, 111
Rate Table, 20
Paneles Reference Property, 38
 [Project Library], 7 Referenced Property, 127
 [Standard Library], 3 Reneging (Abandonar una Fila), 83
 Navigation Panel, 2 Repeating Property Editor, 36
Paths (Caminos), 19  Bill of Materials, 66

 Release, 120 Statistics (Estadísticas)
 Seize, 119  Observation-Based, 41
 State Variable Assignment, 40  State Statistic, 42
Reports, 15  Tally
Resource (Recurso), 49 Stopping Condition, 93
 Initial Capacity, 49  Tally Statistic, 41, See Elements Tally
Responses, 15  Time-persistent, 41
 Response Results, 16 Subclassing (Clonar), 154
Results (Resultados), 8  Delay Objeto, 159
 Categories, 9  Derived/Specialized, 159
Capacity, 9  Server, 154, 195, 230
Content, 9  TimePath, 212
FlowTime, 9  TransferNode, 159
HoldingTime, 10  Vehicle, 187
ResourceState, 9 Symbol, 35
Throughput, 9
 Pivot Grid/Table, 9, 14
 Resource utilization, 10 T
Run Setup, 6 Tables
 Data Table, 22
S  Sequence Table, 30
TimePath (Camino con Duración o Retardo), 4
Schedules, 30 Timer Element. See Elements Timer
Seize (Apresar) TransferNode (Nodo de Transferencia)
 Request Visit Property, 136  Entity Destination Type, 31, 37
Separator (Separador), 42  Inherited Properties, 160
Server (Servidor, Operación), 4  Outbound Link Rule, 24
 Current Symbol Index, 60  Ride On Transporter, 32
 InputBuffer.Contents, 6  Selection Expression, 38
 Processing.Contents, 6  TransferNode Properties, 19
 ProcessTime, 39
 Reliability Logic, 59
 Static Ranking Rule, 129 V
SIMIO Vehicle (Vehículo), 32
 Crear un modelo nuevo, 2  Idle Action, 32
 Inicio, 1  Initial Desired Speed, 32
Sink (Sumidero), 4  Initial Node(Home), 32
Sistemas Lean, 230  ParkingStation.Contents, 33
SMORE, 109
 Ride Capacity, 32
Source (Fuente), 4
 Task Selection Strategy, 150
 Add-On Process Triggers, 54
View, 6
 Entities Per Arrival, 29
 2-D, 6
 Initial Capacity, 15
 3-D, 6
 Source, 5
 Table Reference Assignment, 54
 Time Varying Arrival Rate, 21 W
Standard Property, 22
Work Schedules, 24, 30
 Integer, 22
Work Schedules (Horarios, Turnos)
 List, 224
 Work Cycle, 30
 Real, 38 Worker (Operario, Trabajador), 135
 State, 176  Dynamic Selection Rule, 137
 String, 121 Workstation (Estación de Trabajo), 62
State Variable, 23  Other Requirements, 67
 Before Existing State Assignment, 36
 Discrete State, 36
Station (Estación) Z
 EntryQueue, 168 Zero-Time Events, 139
 Inprocess Queue, 168
Índice 253

Modelizacion y Simulacion Libro de Practicas Con Simio - Edited

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Modelizacion y Simulacion Libro de Practicas Con Simio - Edited

Diunggah oleh

Hak Cipta:

Format Tersedia

Modelización y Simulación: Libro

de Prácticas con SIMIO

Jeffrey Allen Joines

Raleigh, North Carolina

Spanish Electronic Book ISBN: 978-0-9829782-4-5

Published by SIMIO, LLC, (http://www.simio.com)

Modelización y Simulación: Libro de Prácticas con SIMIO

iv Modelización y Simulación: Libro de Prácticas con SIMIO

STEPHEN D. ROBERTS es el A. Doug Allison Distinguished Professor in the Edward P.

vi Modelización y Simulación: Libro de Prácticas con SIMIO

1ª Parte: ¿Qué hace a este libro diferente?

2ª Parte: ¿Quién se beneficia de la Enseñanza Activa?

Prefacio: Aprendizaje Activo vii

3ª Parte: ¿Por qué enfatizar en la “Modelización”?

4ª Parte: Organización del libro

5ª Parte: Estilos y Formatos Utilizados en este Libro

Prefacio: Aprendizaje Activo ix

Jeff Joines (JeffJoines@ncsu.edu)

North Carolina State University

F. Javier Otamendi (franciscojavier.otamendi@urjc.es)

Universidad Rey Juan Carlos

x Modelización y Simulación: Libro de Prácticas con SIMIO

Sección 1.1: El inicio

Figura 1.1: Abriendo la ventano de SIMIO

Introducción a SIMIO: La Tienda de Helados 1

Figura 1.2: Creando un nuevo modelo

Pregunta 1: ¿Cuál es el nombre por defecto de MODELENTITY?

Sección 1.2: La Tienda de Helados

Llegada Elección del Pago del Salida del

Figura 1.3: Flujograma de la Tienda de Helados

Introducción a SIMIO: La Tienda de Helados 3

Note cambios en la barra

Figura 1.4: Comenzando a Modelizar

Pregunta 5: ¿Cuál es el nombre en la librería estándar del nodo de salida?

Figura 1.5: Propiedades de una Fuente

Pregunta 6: ¿Qué unidades de tiempo están asociadas al tiempo entre llegadas?

Paso 5: Complete su modelo añadiendo información a los dos servidores, SERVERS:

 Para el objeto PEDIR:

Introducción a SIMIO: La Tienda de Helados 5

Figura 1.6: Determinando el Tiempo de Ejecución

Paso 9: Haga clic en la pestaña “View” y seleccione “3-D”.

Sección 1.3: Potenciando la Animación

6 Modelización y Simulación: Libro de Prácticas con SIMIO

Introducción a SIMIO: La Tienda de Helados 7

Pregunta 11: Enseñe la simulación a sus amigos. ¿Cuál es su reacción?

Sección 1.4: Viendo Resultados

Aunque la animación llama la atención, el objetivo de la simulación es comprender las características

Figura 1.8: Viendo Resultados

8 Modelización y Simulación: Libro de Prácticas con SIMIO

Paso 4: Los atributos se pueden mover a derecha e izquierda en la pantalla.

Paso 7: La utilización de recursos, Resource utilization, incluye tanto la utilización programada,

Pregunta 13: ¿Cuál es la utilización de la capacidad del objeto Pedir?

Pregunta 14: ¿Cuál es el número medio (contents) en el InputBuffer de Pedir?

Pregunta 17: ¿Cuál es la utilización del objeto Pagar?

Introducción a SIMIO: La Tienda de Helados 9

Si ha estado construyendo el modelo con nosotros, puede haber notado lo siguiente:

 El botón de deshacer/rehacer de SIMIO, undo/redo, es muy conveniente. En el caso de caminos,

10 Modelización y Simulación: Libro de Prácticas con SIMIO

El modelo de simulación debe ser ejecutado para un período de 24 horas.

Sección 2.1: Desarrollando el modelo

Modelizando Distancias y Desplazamientos: Un Aeropuerto, 11

Sección 2.2: Utilizando la Biblioteca de Diseño 3D de Google

Figura 2.2: CheckIn