Simulación de Sistema de Eventos Discretos.

Discrete-Event System Simulation Banks Carson II Nelson Nicol

Introducción a la Simulación.

El comportamiento del sistema a lo largo del tiempo. A partir de la simulación, los

datos se recopilan como si se observara un sistema real. Estos datos generados por
simulación se utilizan para estimar las medidas de rendimiento del sistema.
Este capítulo analiza inicialmente cuándo usar la simulación, sus ventajas y desventajas y
las áreas reales de su aplicación. Luego se exploran los conceptos de sistema y modelo.
Finalmente, se proporciona un resumen de los pasos para construir y utilizar un modelo de
simulación de un sistema.

1) Cuando la simulación es la herramienta apropiada.

La disponibilidad de lenguajes de simulación para propósitos especiales, de

capacidades de computación masiva a un costo por operación decreciente y de los avances
en las metodologías de simulación han hecho de la simulación una de las herramientas
más utilizadas y aceptadas en la investigación de operaciones y el análisis de sistemas. Las
circunstancias bajo las cuales la simulación es la herramienta apropiada para usar han sido
discutidas por muchos autores, de Naylor et al. [1966] a Shannon [1998]. La simulación se
puede utilizar para los siguientes fines:

1. La simulación permite el estudio y la experimentación de las interacciones internas

de un sistema complejo o de un subsistema dentro de un sistema complejo.
2. Se pueden simular cambios informativos, organizativos y ambientales, y se puede
observar el efecto de estas alteraciones en el comportamiento del modelo.
3. El conocimiento adquirido durante el diseño de un modelo de simulación podría
ser de gran valor para sugerir una mejora en el sistema bajo investigación.
4. Cambiar las entradas de la simulación y observar las salidas resultantes puede
producir información valiosa sobre qué variables son las más importantes y cómo
interactúan las variables.
5. La simulación se puede utilizar como un dispositivo pedagógico para reforzar las
metodologías de solución analítica. 6. La simulación se puede utilizar para
experimentar con nuevos diseños o políticas antes de la implementación,
6. a fin de prepararse para lo que pueda pasar.
7. La simulación se puede utilizar para verificar soluciones analíticas.
8. Simular diferentes capacidades para una máquina puede ayudar a determinar sus
requisitos.
9. Los modelos de simulación diseñados para la capacitación hacen posible el
aprendizaje, sin el costo y la interrupción de la instrucción en el trabajo.
10. La animación puede mostrar un sistema en operación simulada para que se pueda
visualizar el plan.
 11. Un sistema moderno (fábrica, planta de fabricación de obleas, organización de
servicios, etc.) es tan complejo que sus interacciones internas solo pueden ser
tratadas a través de la simulación.

2) Cuando la simulación no es apropiada.

Esta sección se basa en un artículo de Banks y Gibson [1997], que ofrece diez reglas
para evaluar cuándo la simulación no es apropiada. La primera regla indica que la
simulación no debe usarse cuando el problema puede resolverse por el sentido común. Se
da un ejemplo de una instalación de etiquetas para automóviles que atiende a clientes que
llegan al azar a una tarifa promedio de 100 / hora y reciben una tarifa promedio de 12 /
hora. Para determinar el número mínimo de servidores necesarios, la simulación no es
necesaria. Solo calcule 100/12 = 8.33, lo que indica que se necesitan nueve o más
servidores.
La segunda regla dice que la simulación no debe usarse si el problema puede
resolverse analíticamente. Por ejemplo, bajo ciertas condiciones, el tiempo de espera
promedio en el ejemplo anterior se puede encontrar usando las herramientas disponibles
en www.bcnn.net.
La siguiente regla dice que la simulación no debe usarse si es menos costoso
realizar experimentos directos. Se da el ejemplo de un restaurante de comidas rápidas,
donde era menos costoso organizar a una persona que toma pedidos utilizando un
terminal portátil y comunicación de voz para determinar el efecto de agregar otra estación
de pedido en el tiempo de espera del cliente.
La cuarta regla dice no usar la simulación si los costos exceden los ahorros. Hay
muchos pasos para completar una simulación, como se discutirá en la Sección 12, y estos
deben hacerse a fondo. Si un estudio de simulación cuesta $ 20,000 y los ahorros podrían
ser de $ 10,000, la simulación no sería apropiada.
Las reglas cinco y seis indican que la simulación no debe realizarse si los recursos o
el tiempo no están disponibles. Si se estima que la simulación cuesta $ 20,000 y solo hay $
10,000 disponibles, la sugerencia es no aventurarse en un estudio de simulación. De
manera similar, si se necesita una decisión en dos semanas y una simulación tomaría un
mes, no se recomienda el estudio de simulación.
La simulación toma datos, a veces muchos datos. Si no hay datos disponibles, ni
siquiera estimaciones, no se recomienda la simulación. La siguiente regla se refiere a la
capacidad de verificar y validar el modelo. Si no hay suficiente tiempo o si el personal no
está disponible, la simulación no es apropiada.
Si los gerentes tienen expectativas irrazonables, si piden demasiado demasiado
pronto, o si se sobreestima el poder de la simulación, la simulación podría no ser
apropiada.
Por último, si el comportamiento del sistema es demasiado complejo o no se puede
de fi nir, la simulación no es apropiada. El comportamiento humano a veces es
extremadamente complejo de modelar.
3) ventajas y desventajas de la simulación

La simulación es intuitivamente atractiva para un cliente porque imita lo que

sucede en un sistema real o lo que se percibe para un sistema que está en la etapa de
diseño. Los datos de salida de una simulación deben corresponder directamente con las
salidas que podrían registrarse desde el sistema real. Además, es posible desarrollar un
modelo de simulación de un sistema sin suposiciones dudosas (como la misma
distribución estadística para cada variable aleatoria) de modelos con resolución
matemática. Por estas y otras razones, la simulación es frecuentemente la técnica de
elección en la resolución de problemas.

A diferencia de los modelos de optimización, los modelos de simulación se “ejecutan” en

lugar de resolverlos. Dado un conjunto particular de características de entrada y modelo,
el modelo se ejecuta y se observa el comportamiento simulado. Este proceso de cambio
de entradas y características del modelo da como resultado un conjunto de escenarios que
se evalúan. Una buena solución, ya sea en el análisis de un sistema existente o en el diseño
de un nuevo sistema, se recomienda para la implementación.
La simulación tiene muchas ventajas, pero algunas desventajas. Estos están listados por
Pegden, Shannon y Sadowski [1995]. Algunas ventajas son estas:

1. Se pueden explorar nuevas políticas, procedimientos operativos, reglas de decisión,

flujos de información, procedimientos organizacionales, etc., sin interrumpir las
operaciones en curso del sistema real.
2. Los nuevos diseños de hardware, diseños físicos, sistemas de transporte, etc.
pueden probarse sin comprometer recursos para su adquisición.
3. Las hipótesis sobre cómo o por qué ocurren ciertos fenómenos pueden
comprobarse su viabilidad.
4. El tiempo puede comprimirse o expandirse para permitir una aceleración o
desaceleración de los fenómenos bajo investigación.
5. Se puede obtener información sobre la interacción de las variables.
6. Se puede obtener información detallada sobre la importancia de las variables para
el rendimiento del sistema. 7. Se puede realizar un análisis de cuellos de botella
para descubrir dónde trabajar, proceso, información,
7. Los materiales, y así sucesivamente, se están retrasando excesivamente.
8. Un estudio de simulación puede ayudar a comprender cómo funciona el sistema en
lugar de cómo piensan los individuos que funciona el sistema.
9. Las preguntas de “¿Qué pasa si?” Pueden ser respondidas. Esto es particularmente
útil en el diseño de nuevos sistemas.
Algunas desventajas son estas:

1. La construcción de modelos requiere una formación especial. Es un arte que se

aprende con el tiempo y a través de la experiencia. Además, si dos modelos están
construidos por diferentes individuos competentes, pueden tener similitudes, pero
es muy poco probable que sean iguales.
2. Los resultados de la simulación pueden ser difíciles de interpretar. La mayoría de
las salidas de simulación son esencialmente variables aleatorias (generalmente se
basan en entradas aleatorias), por lo que puede ser difícil distinguir si una
observación es el resultado de interrelaciones del sistema o de aleatoriedad.
3. El modelado y análisis de simulación puede llevar mucho tiempo y ser costoso.
Escatimar recursos para modelar y analizar podría dar como resultado un modelo o
análisis de simulación que no es suficiente para la tarea.
4. La simulación se usa en algunos casos cuando una solución analítica es posible, o
incluso preferible, como se discutió en la Sección 2. Esto puede ser particularmente
cierto en la simulación de algunas líneas de espera donde están disponibles
modelos de colas de forma cerrada.

En defensa de la simulación, estas cuatro desventajas, respectivamente, se pueden

compensar de la siguiente manera:

1. Los proveedores de software de simulación han estado desarrollando paquetes

que contienen modelos que solo necesitan datos de entrada para su operación.
Tales modelos tienen la etiqueta genérica "simulador" o "plantilla".
2. Muchos proveedores de software de simulación han desarrollado capacidades de
análisis de resultados dentro de sus paquetes para realizar análisis muy completos.
3. La simulación se puede realizar más rápido hoy que ayer y lo será aún más mañana,
debido a los avances en hardware que permiten la ejecución rápida de escenarios y
debido a los avances en muchos paquetes de simulación. Por ejemplo, algunos
programas de simulación contienen construcciones para modelar el manejo de
materiales que utilizan transportadores como carretillas elevadoras,
transportadores y vehículos guiados automatizados.
4. Los modelos de forma cerrada no pueden analizar la mayoría de los sistemas
complejos que se encuentran en la práctica. Durante los muchos años de
consultoría realizada por dos de los autores, no se encontró ningún problema que
pudiera haberse resuelto mediante una solución de formato cerrado.

4) áreas de aplicación.

Las aplicaciones de simulación son vastas. La Winter Simulation Conference (WSC)

es una excelente manera de aprender más sobre lo último en aplicaciones y teoría de
simulación. También hay numerosos tutoriales en los niveles principiante y avanzado. WSC
está patrocinado por seis sociedades técnicas y el Instituto Nacional de Estándares y
Tecnología (NIST). Las sociedades técnicas son la Asociación Americana de Estadística
(ASA), la Asociación de Maquinaria de Computación / Grupo de Interés Especial en
Simulación (ACM / SIGSIM), el Instituto de Ingenieros Eléctricos y Electrónicos: Sistemas,
Hombre y la Sociedad de Cibernética (IEEE / SMCS), el El Instituto de Ingenieros
Industriales (IIE), el Instituto de Investigación de Operaciones y Ciencias de la
Administración: Sociedad de Simulación (INFORMS-SIM), y la Sociedad Internacional de
Modelado y Simulación (SCS). Se puede obtener información sobre la próxima CSM en
www.wintersim.org. Los programas de CSM con documentos completos están disponibles
en www.informs-cs.org/wscpapers.html. A continuación, se enumeran algunas
presentaciones, por área, de un CSM reciente:

Aplicaciones de Fabricación
 Metodología para seleccionar el método de detección de cuellos de botella
más adecuado
 Automatización del desarrollo de modelos de fabricación de astilleros.
 Emulación en procesos de ingeniería de fabricación.
 Diseño de mantenimiento optimizado para la gestión de productividad de la
mejora del rendimiento en la fabricación en una industria de autopartes
 Línea de fabricación de diseños en las plantas japonesas de fabricación de
automóviles
Fabricación de obleas
 Un cambio de paradigma en la asignación de lotes a herramientas
 Programación de una línea de ensamblaje de paquetes de múltiples chips
con procesos de reentrada
 Decisiones de asignación de capacidad de nivel de ejecución para el
montaje: instalaciones de prueba
 Gestión de WIP y tiempo de ciclo con la ayuda de Loop Control
Procesamiento de negocios
 Una nueva política para el problema de asignación de solicitud de servicio
 Procesos de supervisión de ejecución y esquemas de ajuste
 Comercialización en tienda de tiendas minoristas
 Pronóstico de ventas para pequeñas tiendas minoristas
Ingeniería de la Construcción y Gestión de Proyectos.
 Programación de Bar-Benders limitados en varios sitios de construcción
 Construyendo Proyectos Repetitivos
 Operaciones de tránsito para mejorar la planificación de proyectos de
construcción de carreteras
 Plantilla para modelar la construcción del eje del túnel
 Herramienta de apoyo a la decisión para la planificación de la construcción
de túneles
Logística, Transporte y Distribución.
 Políticas operativas para un sistema de transporte de barcazas
 Plan de dispensación de suministros médicos de emergencia en caso de
bioterrorismo
  Análisis de una red de transporte de correo complejo
 Mejora del rendimiento de las terminales de contenedores
 Despacho de grúas de patio basado en datos en tiempo real
 Unidad de carga de inventario de dispositivos en operaciones de aerolínea
 Sistemas de inventario con actualización de políticas basadas en pronósticos
 Asignación de muelle en un centro de distribución de alimentos
 Políticas operativas para un sistema de transporte de barcazas
Aplicaciones militares
 Distribución Logística Multinacional Intra-Teatro.
 Examinar la sostenibilidad futura de las operaciones de las fuerzas
canadienses
 Estudio de viabilidad para la sustitución del sistema automático de
lanzamiento de granadas MK19. Fuerzas conjuntas para operaciones
asimétricas.
 Planificación de la misión de vehículos aéreos no tripulados multi-objetivo
 Desarrollo de Federaciones Dirigidas por Requisitos Operacionales
Cuidado de la salud
 Intervenciones para reducir el tiempo de espera de citas y la tasa de no
presentación de pacientes
 Apoyando el pensamiento inteligente para mejorar el rendimiento del
hospital
 Veri fi cación de Lean Improvement para el proceso de la sala de
emergencias
 Reducción del hacinamiento en el departamento de emergencias
 Modelado de inventario de productos farmacéuticos perecederos
 Implementación de un centro de procedimientos ambulatorios
 Política de control de enfermedades infecciosas
 Balance de la sala de operaciones y los recursos postanestésicos
 La eficacia en función de los costos de las pruebas de detección del cáncer
colorrectal
Aplicaciones Adicionales
 Gestión de acciones de recursos laborales con control de retroalimentación
múltiple
 Analizando el impacto del tamaño del agujero en poner en el golf
 Aplicación de filtros de partículas en la simulación de dispersión de fuego
salvaje
 Relación depredador-presa en un hábitat cerrado
 Sistemas de producción de lechones intensivos
 Estimación de demoras en tiempo real en centros de llamadas
 Planes de preparación para la influenza pandémica para una universidad
pública
 Para un artículo sobre el futuro de la simulación que aparece en el Boletín
informativo de ICS (Banks, 2008), dieciséis simuladores, incluidos expertos bien conocidos
en el campo, respondieron a la siguiente pregunta: “¿Qué resultados notables
observaremos en el software de simulación en ¿A largo plazo, digamos, después de tres
años? ” Las respuestas que se muestran a continuación aparecieron en el artículo de
referencia:

• Una vez que los proveedores de software hayan adoptado nuevas ideas y
metodologías fundamentales, como el modelado basado en agentes (lo que ocurrirá
dentro de unos pocos años), el progreso en el modelado de simulación será impulsado por
las ganancias en el poder de cómputo. Por ejemplo, en un determinado punto podremos
simular el funcionamiento detallado de grandes cadenas de suministro e instalaciones de
fabricación.
El modelado de simulación será más una actividad de "ensamblaje" que una
actividad de "construir desde cero". Los componentes inteligentes y parametrizados se
utilizarán para ensamblar modelos en lugar de definir mucha lógica detallada.
• Se avanzará en la resolución de problemas difíciles. Para proporcionar
herramientas para problemas realmente difíciles, los desarrolladores de software de
simulación tendrán que volver al tablero de dibujo y reconsiderar seriamente la pregunta
fundamental: "¿Quién proporciona el poder y quién proporciona la visión?" Es esencial
obtener esta combinación adecuada para seguir avanzando. Cuando un desarrollador de
software intenta proporcionar tanto poder como visión, los usuarios finales se enfrentan a
los paradigmas del desarrollador. Esto funciona bien para problemas fáciles, pero mal para
problemas difíciles. Para todos los problemas realmente difíciles, los usuarios saben más
sobre los problemas que los desarrolladores de software. La solución obvia es que los
desarrolladores proporcionen colecciones bien pensadas de verdaderas primitivas, junto
con formas de combinar y empaquetar estas primitivas.
• El software de simulación se integrará más estrechamente con el software de
control.
• Los modeladores tendrán un modelo único que se comparte entre las
aplicaciones dentro de la organización. • Las aplicaciones de simulación no se limitarán a
las aplicaciones de diseño, sino que también se utilizarán para
tomar decisiones operativas diarias dentro de una organización.
• Se accederá al modelado de simulación en servidores potentes con interfaces
basadas en web.
• Estará disponible un modelo mejor y más sencillo de las actividades humanas
(por ejemplo, la incorporación de modelos basados en agentes en modelos de eventos
discretos).
• Se puede esperar un desarrollo de proyectos de simulación más colaborativo.
• Los estándares de interfaz y la incorporación de servicios web permiten que el
software de simulación no solo funcione entre sí como una federación integrada, sino que
también estandarice y simplifique la forma en que se adoptarán otras aplicaciones con el
software de simulación.
 • Las técnicas de resolución analítica (como la programación lineal) se integrarán
con las capacidades de simulación.
• Los resultados "notables" se derivarán de los avances en otras áreas de la
tecnología informática y la ingeniería de software. Pero nada superará el paradigma
orientado a objetos que fue introducido en el desarrollo de software general por SIMULA
67, que emana de la comunidad de software de simulación.

5) Algunas aplicaciones recientes de simulación.

En esta sección, presentamos algunas aplicaciones recientes de simulación. Estos

han aparecido en la literatura indicada para que pueda encontrar estos casos y conocer
más detalles sobre ellos.

TÍTULO: "El ejército turco utiliza la simulación para modelar y optimizar su sistema de
suministro de combustible" AUTOR (S): I. Sabuncuoglu, A. Hatip
REPORTADO: Noviembre-diciembre 2005 en Interfaces.
RETO: Análisis del sistema de suministro de combustible del ejército turco.
TÉCNICA (S): (1) El rendimiento medido de los sistemas existentes y propuestos en varios
escenarios, (2) desarrolló un modelo de optimización de simulación basado en un
algoritmo genético para optimizar el rendimiento del sistema, (3) realizó experimentos de
simulación exhaustivos.
AHORRO: Millones de US $.

TÍTULO: “PLATO ayuda a Athens a ganar oro: Modelado de conocimiento de los Juegos
Olímpicos para el cambio organizativo y la gestión de recursos”
AUTOR (S): D.A. Beis, P. Poucopoulos, Y. Pyrgiotis, K.G. Zografos
REPORTADO: Enero-Febrero 2006 en Interfaces.
DESAFÍO: Desarrollar un proceso sistemático para planificar y diseñar las operaciones del
lugar. Desarrolle una rica biblioteca de modelos que sea directamente transferible a
futuros comités de organización olímpica y otros eventos orientados al deporte.
TÉCNICA (S): Técnicas y herramientas de modelado del conocimiento y gestión de recursos
basadas en simulación y otras metodologías de análisis de decisiones.
AHORRO: Más de US $ 69.7 millones.

TÍTULO: “Schlumberger usa la simulación para realizar licitaciones y ejecutar encuestas

sísmicas terrestres” AUTOR (S): P.W. Mullarkey, G. Butler, S. Gavirneni, D.J. Morrice
REPORTADO: marzo-abril 2007 en Interfaces
DESAFÍO: Mida de forma rápida y precisa el costo de las prospecciones sísmicas.
TÉCNICA (S): Se desarrolló una herramienta de simulación para evaluar el impacto del
tamaño de la tripulación, el área de la encuesta, la región geográfica y las condiciones
climáticas en los costos y la duración de la encuesta.
AHORROS: US $ 1.5 a US $ 3.0 millones anuales.
TÍTULO: “La investigación de operaciones ayuda a reformular la estrategia de operaciones
en la compañía de registro estándar” AUTOR (S): S.L. Ahire, M.F. Gorman, D. Dwiggins, O.
Mudry
REPORTADO: Noviembre-Diciembre 2007 en Interfaces.
RETO: Minimice los costos totales para ofrecer precios competitivos en el mercado de
impresión tradicional altamente competitivo.
TÉCNICA (S): (1) Regresión para estimar costos y atributos de tiempo, (2) modelado de
optimización para determinar la estrategia de enrutamiento de pedidos, (3) modelado de
simulación de la red de producción-distribución.
AHORRO: Más de US $ 10 millones anuales.

TÍTULO: “La simulación implementa un programador de fuerza laboral impulsado por la

demanda para la industria de servicios” AUTOR (S): M. Zottolo, O.M. Ulgen, E. Williams ¨
REPORTADO: Actas de la Winter Simulation Conference 2007, eds. S. Henderson, B. Biller,
M.-H. Hsieh, J. Shortle, J.D. Tew y R.R. Barton.
REALIZADO POR: PMC (www.pmcorp.com)
CLIENTE: Mayor empresa de electrodomésticos de Estados Unidos.
DESAFÍO: Como resultado de un proceso de programación manual, e ineficiente, que lleva
mucho tiempo, el cliente experimentó un exceso y falta de programación de los grupos de
trabajo, se proporcionaron niveles de servicio incoherentes y los administradores de sitios
abrumados.
TÉCNICA (S): (1) Modelo de simulación construido para programar diferentes grupos de
trabajo de acuerdo con los cambios en la demanda del cliente durante el día y los tiempos
de servicio, (2) estándares de trabajo determinados, (3) interfaz desarrollada para datos de
entrada, así como almacenamiento y publicación de horarios, (4) empleados
implementados y capacitados en el uso de la herramienta de programación.
AHORRO: estimado en US $ 80 millones para las instalaciones de los clientes en los EE. UU.

TÍTULO: “La simulación mejora la clasificación de final de línea y la programación de

recolección de manejo de materiales en el fabricante del dispositivo”
AUTOR (S): N. Kale, M. Zottolo, O.M. Ulgen, E. Williams ¨
REALIZADO POR: PMC (www.pmcorp.com)
CLIENTE: Importante empresa de alquiler de vehículos en Estados Unidos.
REPORTADO: Actas de la Winter Simulation Conference 2007, eds. S. Henderson, B. Biller,
M.-H. Hsieh, J. Shortle, J.D. Tew y R.R. Barton.
RETO: determinar el método más eficiente para distribuir varios tipos de aparatos
terminados (SKU) en un sistema de clasificación de 12 carriles para minimizar el manejo de
materiales y la cantidad de carretillas elevadoras necesarias para recogerlos. Esta tarea de
clasificación y sus tareas asociadas de manejo de materiales tenían una complejidad que
merecía un análisis de simulación de eventos discretos debido a la mezcla volátil de
productos, la gran cantidad de SKU y los altos costos generales.
TÉCNICA (S): Modelo de simulación construido y experimentación realizada con respecto a
(1) asignación de diferentes SKU a los diferentes carriles, (2) estrategia y cantidad de
picking, (3) tamaños de lote de SKU.
AHORROS: un estimado de US $ 100,000 anuales para una inversión de capital única de US
$ 50,000.

6) Sistemas y Entorno del Sistema

Para modelar un sistema, es necesario comprender el concepto de un sistema y el

límite del sistema. Un sistema se define como un grupo de objetos que se unen en alguna
interacción regular o interdependencia hacia el logro de algún propósito. Un ejemplo es un
sistema de producción de automóviles. Las máquinas, los componentes y los trabajadores
operan conjuntamente a lo largo de una línea de montaje para producir un vehículo de
alta calidad.
Un sistema a menudo se ve afectado por cambios que ocurren fuera del sistema. Se
dice que tales cambios ocurren en el entorno del sistema [Gordon, 1978]. En los sistemas
de modelado, es necesario decidir el límite entre el sistema y su entorno. Esta decisión
puede depender del propósito del estudio.
En el caso del sistema de fábrica, por ejemplo, los factores que controlan la llegada
de pedidos pueden considerarse fuera de la influencia de la fábrica y, por lo tanto, parte
del entorno. Sin embargo, si se considera el efecto de la oferta sobre la demanda, habrá
una relación entre la producción de la fábrica y la llegada de los pedidos, y esta relación
debe considerarse una actividad del sistema. De manera similar, en el caso de un sistema
bancario, podría haber un límite en la tasa de interés máxima que se puede pagar. Para el
estudio de un solo banco, esto se consideraría como una restricción impuesta por el medio
ambiente. Sin embargo, en un estudio sobre los efectos de las leyes monetarias en la
industria bancaria, el establecimiento del límite sería una actividad del sistema [Gordon,
1978].

7) Componentes de un Sistema

Para comprender y analizar un sistema, es necesario definir varios términos. Una

entidad es un objeto de interés en el sistema. Un atributo es una propiedad de una
entidad. Una actividad representa un período de tiempo de longitud especi fi cada. Si se
está estudiando un banco, los clientes podrían ser una de las entidades, el saldo en sus
cuentas corrientes podría ser un atributo y hacer depósitos podría ser una actividad.
La colección de entidades que componen un sistema para un estudio puede ser
solo un subconjunto del sistema general para otro estudio [Ley, 2007]. Por ejemplo, si se
está estudiando el banco mencionado anteriormente para determinar el número de
cajeros necesarios para pagar y recibir, el sistema se puede definir como la parte del banco
que consiste en los cajeros regulares y los clientes que esperan en la fila. Si el propósito del
estudio se amplía para determinar el número de cajeros especiales necesarios (para
preparar cheques de caja, para realizar transacciones comerciales, etc.), la definición del
sistema debe ampliarse.
El estado de un sistema se define como la colección de variables necesarias para
describir el sistema en cualquier momento, en relación con los objetivos del estudio. En el
estudio de un banco, las posibles variables de estado son el número de cajeros ocupados,
el número de clientes que esperan en línea o que reciben servicio, y la hora de llegada del
siguiente cliente. Un evento se define como un suceso instantáneo que podría cambiar el
estado del sistema. El término endógeno se usa para describir actividades y eventos que
ocurren dentro de un sistema, y el término exógeno se usa para describir actividades y
eventos en el entorno que afectan al sistema. En el estudio del banco, la llegada de un
cliente es un evento exógeno, y la finalización del servicio de un cliente es un evento
endógeno.
La Tabla 1 enumera ejemplos de entidades, atributos, actividades, eventos y
variables de estado para varios sistemas. Sólo se muestra una lista parcial de los
componentes del sistema. Una lista completa no puede ser desarrollada a menos que se
conozca el propósito del estudio. Dependiendo del propósito, varios aspectos del sistema
serán de interés, y luego se puede completar la lista de componentes.

Tabla 1.1 Ejemplos de sistemas y componentes

Sistema Entidades Atributos Actividades eventos Variable de estado

Saldo de la Número de cajeros
Haciendo
Bancario Clientes cuenta llegada Salida ocupados; número de
depósitos
corriente clientes esperando
Llegada a la Número de corredores que
estación; esperan en cada estación;
Riel rápido Corredores Origen; destino De viaje
Llegada al número de pasajeros en
destino tránsito
Speed;
Estado de las máquinas
capacity; Soldadura;
Producción Maquinas Ruptura (ocupado, inactivo o
breakdown estampado
inactivo)
rate.
Comunicacione Longitud; Llegada a Número en espera de ser
Mensajes Transmitiendo
s destino destino transmitido
Niveles de inventario;
Inventario Almacén Capacidad Retirando Demanda
demandas atrasadas

1.7) Sistemas discretos y continuos.

Los sistemas se pueden categorizar como discretos o continuos. “En la práctica,

pocos sistemas son totalmente discretos o continuos, pero como un tipo de cambio
predomina en la mayoría de los sistemas, generalmente será posible clasificar un sistema
como discreto o continuo” [Law y Kelton, 2000]. Un sistema discreto es aquel en el que las
variables de estado cambian solo en un conjunto discreto de puntos en el tiempo. El banco
es un ejemplo de un sistema discreto, ya que la variable de estado, el número de clientes
en el banco, cambia solo cuando llega un cliente o cuando se completa el servicio
proporcionado. La Figura 1.1 muestra cómo la cantidad de clientes cambia solo en puntos
discretos en el tiempo.
 Número de clientes esperando en línea o siendo atendidos

Figura 1.1 Variable de estado del sistema discreto

Un sistema continuo es aquel en el que las variables de estado cambian

continuamente con el tiempo. Un ejemplo es la cabeza de agua detrás de una presa.
Durante y durante algún tiempo después de una tormenta de lluvia, el agua fluye hacia el
lago detrás de la presa. El agua se extrae de la presa para controlar las inundaciones y
generar electricidad. La evaporación también disminuye el nivel del agua. La Figura 1.2
muestra cómo cambia la variable de estado, la altura del agua detrás de la presa, para este
sistema continuo.
Jefe de agua detrás de la presa

Figura 1.2 Estado del sistema continuo

variable.

1.8) Modelo de un sistema

A veces es interesante estudiar un sistema para comprender las relaciones entre

sus componentes o para predecir cómo funcionará el sistema bajo una nueva política. A
veces es posible experimentar con el sistema en sí, pero no siempre. Puede que aún no
exista un nuevo sistema; Puede ser solo en forma hipotética o en la etapa de diseño.
Incluso si el sistema existe, puede ser poco práctico experimentar con él. Por ejemplo,
puede no ser sabio o posible duplicar la tasa de desempleo para determinar el efecto del
empleo en la inflación. En el caso de un banco, reducir la cantidad de cajeros para estudiar
el efecto en la longitud de las líneas de espera puede enfurecer tanto a los clientes que
mueven sus cuentas a un competidor. En consecuencia, los estudios de sistemas a menudo
se realizan con un modelo de un sistema.
Tuvimos un trabajo de consultoría para la simulación de un puerto rediseñado en el
oeste de Australia. Con $ 200 millones para un muelle de carga / descarga, no es
recomendable invertir esa cantidad solo para encontrar que el muelle no es adecuado
para la tarea.
Un modelo se define como una representación de un sistema con el fin de estudiar
el sistema. Para la mayoría de los estudios, es necesario considerar solo los aspectos del
sistema que afectan el problema bajo investigación. Estos aspectos están representados en
un modelo del sistema, y el modelo, por definición, es una simplificación del sistema. Por
otro lado, el modelo debe ser suficientemente detallado para permitir extraer
conclusiones válidas sobre el sistema real. Es posible que se requieran diferentes modelos
del mismo sistema a medida que cambian los objetivos de la investigación.
Al igual que los componentes de un sistema eran entidades, atributos y actividades,
los modelos se representan de manera similar. Sin embargo, el modelo contiene solo
aquellos componentes que son relevantes para el estudio. Los componentes de un modelo
se discuten más ampliamente en el Capítulo 3.

1.9) Tipos de modelos

Los modelos pueden clasificarse como matemáticos o físicos. Un modelo

matemático utiliza la notación simbólica y las ecuaciones matemáticas para representar un
sistema. Un modelo de simulación es un tipo particular de modelo matemático de un
sistema.
Los modelos de simulación pueden clasificarse además como estáticos o dinámicos,
deterministas o estocásticos, y discretos o continuos. Un modelo de simulación estática, a
veces llamado simulación de Monte Carlo, representa un sistema en un momento
determinado en el tiempo. Los modelos de simulación dinámica representan sistemas a
medida que cambian con el tiempo. La simulación de un banco a partir de las 9:00 a.m. a
las 4:00 p.m. Es un ejemplo de una simulación dinámica.
Los modelos de simulación que no contienen variables aleatorias se clasifican como
de- terminísticos. Los modelos deterministas tienen un conjunto conocido de entradas que
resultarán en un conjunto único de salidas.
Las llegadas deterministas se producirían en el consultorio de un dentista si todos
los pacientes llegaron a la hora programada para la cita. Un modelo de simulación
estocástica tiene una o más variables aleatorias como entradas. Entradas aleatorias
conducen a salidas aleatorias. Dado que los resultados son aleatorios, solo pueden
considerarse como estimaciones de las características reales de un modelo. La simulación
de un banco generalmente involucraría tiempos de llegada al azar y tiempos de servicio al
azar. Por lo tanto, en una simulación estocástica, las medidas de salida (el número
promedio de personas que esperan, el tiempo de espera promedio de un cliente) deben
tratarse como estimaciones estadísticas de las verdaderas características del sistema.
Los sistemas discretos y continuos fueron definidos en la Sección 1.6. Los modelos
discretos y continuos se definen de manera análoga. Sin embargo, un modelo de
simulación discreta no siempre se usa para modelar un sistema discreto, ni un modelo de
simulación continua siempre se usa para modelar un sistema continuo. Algunos
fabricantes de software modelan discretamente los tanques y tuberías, aunque sabemos
que el flujo de fluidos es continuo. Además, los modelos de simulación pueden ser mixtos,
tanto discretos como continuos. La elección de utilizar un modelo de simulación discreto o
continuo (o tanto discreto como continuo) es una función de las características del sistema
y el objetivo del estudio. Por lo tanto, un canal de comunicación podría modelarse
discretamente si las características y el movimiento de cada mensaje se consideraran
importantes. A la inversa, si el flujo de mensajes en conjunto sobre el canal fuera
importante, modelar el sistema usando simulación continua podría ser más apropiado. Los
modelos considerados en este texto son discretos, dinámicos y estocásticos.

1.10) Simulación de sistema de evento discreto

Este libro trata sobre la simulación de sistemas de eventos discretos: el modelado

de sistemas en los que la variable de estado cambia solo en un conjunto discreto de
puntos en el tiempo. Los modelos de simulación se analizan mediante métodos numéricos
y no analíticos. Los métodos analíticos emplean el razonamiento deductivo de las
matemáticas para "resolver" el modelo. Por ejemplo, el cálculo diferencial se puede usar
para determinar la política de costo mínimo para algunos modelos de inventario. Los
métodos numéricos emplean procedimientos computacionales para "resolver" modelos
matemáticos.
En el caso de los modelos de simulación, que emplean métodos numéricos, los
modelos se “ejecutan” en lugar de resolver; es decir, se genera una historia artificial del
sistema en función de los supuestos del modelo, y se recopilan observaciones para
analizarlas y estimar las medidas reales de rendimiento del sistema. Dado que los modelos
de simulación del mundo real son bastante grandes, y dado que la cantidad de datos
almacenados y manipulados es tan vasta, las ejecuciones generalmente se realizan con la
ayuda de una computadora. Sin embargo, se puede obtener mucha información
simulando modelos pequeños manualmente.
En resumen, este libro trata sobre la simulación de sistemas de eventos discretos
en los que los modelos de interés se analizan numéricamente, generalmente con la ayuda
de una computadora.

1.11) Pasos en un estudio de simulación.

La Figura 1.3 muestra un conjunto de pasos para guiar a un constructor de modelos

en un estudio de simulación exhaustivo y sólido. Figuras similares y discusión de pasos se
pueden encontrar en otras fuentes [Shannon, 1975; Gordon, 1978; Law y Kelton, 2000]. El
número al lado de cada símbolo en la Figura 1.3 se refiere a la discusión más detallada en
el texto. Los pasos en un estudio de simulación son los siguientes:

Formulación del problema. Cada estudio debe comenzar con una declaración del
problema. Si los responsables de la formulación de políticas o aquellos que tienen el
problema proporcionan la declaración, el analista debe asegurarse de que el problema que
se describe se entienda claramente. Si el analista está desarrollando una declaración del
problema, es importante que los responsables de las políticas entiendan y estén de
acuerdo con la formulación. Aunque no se muestra en la Figura 1.3, hay ocasiones en que
el problema debe reformularse a medida que avanza el estudio. En muchos casos, los
creadores de políticas y los analistas son conscientes de que existe un problema mucho
antes de que se conozca su naturaleza.

Establecimiento de objetivos y plan global del proyecto. Los objetivos indican las
preguntas a responder por simulación. En este punto, se debe hacer una determinación
respecto a si la simulación es la metodología apropiada para el problema tal como se
formuló y los objetivos como se indicó. Suponiendo que se decida que la simulación es
apropiada, el plan general del proyecto debe incluir una declaración de los sistemas
alternativos a considerar y un método para evaluar la efectividad de estas alternativas.
También debe incluir los planes para el estudio en términos de la cantidad de personas
involucradas, el costo del estudio y la cantidad de días necesarios para completar cada fase
del trabajo con los resultados anticipados al final de cada etapa.

Conceptualización del modelo. La construcción de un modelo de un sistema es

probablemente tanto arte como ciencia. Pritsker [1998] proporciona una larga discusión
de este paso. “Aunque no es posible proporcionar un conjunto de instrucciones que
conduzcan a construir modelos exitosos y apropiados en cada caso, hay algunas pautas
generales que se pueden seguir” [Morris, 1967].
El arte del modelado se ve reforzado por la capacidad de abstraer las características
esenciales de un problema, de seleccionar y modificar los supuestos básicos que
caracterizan el sistema y, luego, de enriquecer y elaborar el modelo hasta obtener una
aproximación útil. Por lo tanto, es mejor comenzar con un modelo simple y construir hacia
una mayor complejidad. Sin embargo, la complejidad del modelo no necesita exceder la
requerida para lograr los propósitos para los cuales está diseñado el modelo. La violación
de este principio solo se agregará a la construcción de modelos y los gastos de
computadora. No es necesario tener un mapeo uno a uno entre el modelo y el sistema
real. Sólo se necesita la esencia del sistema real.
Es recomendable involucrar al usuario modelo en la conceptualización del modelo.
Esto mejorará la calidad del modelo resultante y aumentará la confianza del usuario del
modelo en la aplicación del modelo.
Figura 1.3 Pasos en un estudio de simulación.
 Número de modelos de simulación. El Capítulo 6 describe los modelos de colas que
pueden resolverse analíticamente. Sin embargo, solo la experiencia con sistemas reales, en
lugar de problemas con los libros de texto, puede “enseñar” el arte de construir modelos.)

Recopilación de datos.
Existe una interacción constante entre la construcción del modelo y la recopilación
de los datos de entrada necesarios [Shannon, 1975]. A medida que cambia la complejidad
del modelo, los elementos de datos requeridos también pueden cambiar. Además, dado
que la recopilación de datos toma una porción tan grande del tiempo total requerido para
realizar una simulación, es necesario comenzar lo antes posible, generalmente junto con
las etapas iniciales de la construcción del modelo.
Los objetivos del estudio determinan, en gran medida, el tipo de datos que deben
recopilarse. En el estudio de un banco, por ejemplo, si el deseo es aprender sobre la
longitud de las líneas de espera a medida que cambia el número de cajeros, los tipos de
datos necesarios serían las distribuciones de los tiempos entre llegadas (en diferentes
momentos del día). las distribuciones en tiempo de servicio para los cajeros y las
distribuciones históricas en las longitudes de las líneas de espera en diferentes
condiciones. Estos últimos datos se utilizarán para validar el modelo de simulación. (El
Capítulo 9 analiza la recopilación de datos y el análisis de datos; el Capítulo 5 analiza las
distribuciones estadísticas que ocurren con frecuencia en los modelos de simulación.
Véase también una excelente discusión de Vincent [1998]).

Traducción del modelo.

Dado que la mayoría de los sistemas del mundo real dan como resultado modelos
que requieren una gran cantidad de almacenamiento y cálculo de información, el modelo
debe ingresarse en un formato reconocible por computadora. Utilizamos el término
"programa", aunque es posible lograr el resultado deseado en muchos casos con poca o
ninguna codificación real. El modelador debe decidir si programará el modelo en un
lenguaje de simulación como GPSS / H © (que se analiza en el Capítulo 4) o para usar
software de simulación de propósito especial. Para la fabricación y manejo de materiales,
el Capítulo 4 trata sobre Arena®, AutoMod ©, CSIM, Extend ©, Micro Saint, ProModel®,
Dened / Quest®, Taylor Eneterprise Dynamics (ED), y Testigo ©. Los lenguajes de
simulación son potentes y flexibles.
Sin embargo, si el El problema se puede resolver con el software de simulación, el
tiempo de desarrollo del modelo se reduce considerablemente. Además, la mayoría de los
paquetes de software de simulación han agregado características que mejoran su
flexibilidad, aunque la cantidad de flexibilidad varía mucho.
Verificado? La verificación corresponde al programa de computadora preparado
para el modelo de simulación. ¿Funciona correctamente el programa de computadora?
Con los modelos complejos es difícil, si no imposible, traducir un modelo con éxito en su
totalidad sin una gran cantidad de depuración. Si los parámetros de entrada y la estructura
lógica del modelo están representados correctamente en la computadora, se ha
completado la verificación. En su mayor parte, el sentido común se utiliza para completar
este paso. (El Capítulo 10 discute la verificación de modelos de simulación, y Balci [1998]
también analiza este tema ampliamente).

¿Validado? La validación es la determinación de que un modelo es una

representación precisa del sistema real. La validación generalmente se logra a través de la
calibración del modelo, un proceso iterativo de comparación del modelo con el
comportamiento real del sistema y el uso de las discrepancias entre los dos, y las
perspectivas ganado, para mejorar el modelo. Este proceso se repite hasta que la precisión
del modelo se considera aceptable. En el ejemplo de un banco mencionado
anteriormente, se recopilaron datos sobre la longitud de las líneas de espera en las
condiciones actuales. ¿El modelo de simulación replica este sistema de medidas? Este es
un medio de validación. (El Capítulo 10 trata sobre la validación de modelos de simulación,
y Balci [1998] también trata este tema ampliamente).
Diseño experimental. Las alternativas a simular deben ser determinadas. A
menudo, la decisión sobre qué alternativas simular puede ser una función de ejecuciones
que se hayan completado y analizado. Para cada diseño de sistema que se simule, se
deben tomar decisiones sobre la duración del período de inicialización, la duración de las
ejecuciones de la simulación y el número de réplicas que se deben realizar de cada
ejecución. (Los capítulos 11 y 12 tratan temas relacionados con el diseño experimental, y
Kleijnen [1998] trata este tema ampliamente).
Ejecuciones de producción y análisis. Las ejecuciones de producción y su análisis
posterior se utilizan para estimar las medidas de rendimiento para los diseños de sistemas
que se están simulando. [Los capítulos 11 y 12 analizan el análisis de los experimentos de
simulación y el capítulo 4 analiza el software para ayudar en este paso, incluidos Au- toStat
(en AutoMod), OptQuest (en varios programas de simulación), SimRunner (en ProModel) y
el analizador de resultados de Arena .]
¿Más carreras? Basándose en el análisis de las ejecuciones que se han completado,
el analista determina si se necesitan ejecuciones adicionales y qué diseño deberían seguir
esos experimentos adicionales.
Documentación y reporting. Hay dos tipos de documentación: programa y
progreso. La documentación del programa es necesaria por numerosas razones. Si el
programa va a ser usado nuevamente por el mismo o por diferentes analistas, puede ser
necesario entender cómo funciona el programa. Esto creará confianza en el programa, de
modo que los usuarios modelo y los responsables de la formulación de políticas puedan
tomar decisiones basadas en el análisis. Además, si el programa debe ser modificado por
el mismo analista o un analista diferente, esto puede ser facilitado en gran medida por la
documentación adecuada. Una experiencia con un programa inadecuadamente
documentado suele ser suficiente para convencer a un analista de la necesidad de este
importante paso. Otra razón para documentar un programa es que los usuarios del
modelo pueden cambiar los parámetros a voluntad para determinar las relaciones entre
los parámetros de entrada y las medidas de rendimiento de salida, o para determinar los
parámetros de entrada que "optimizan" algunas medidas de rendimiento de salida.
 Musselman [1998] analiza los informes de progreso que proporcionan la historia
escrita importante de un proyecto de simulación. Los informes de proyectos dan una
cronología del trabajo realizado y las decisiones tomadas. Esto puede resultar de gran
valor para mantener el proyecto en curso.
Musselman sugiere informes frecuentes (mensuales, al menos) para que incluso
aquellos que no participan en la operación diaria puedan mantenerse al tanto. La
conciencia de estos otros generalmente puede mejorar la finalización exitosa del proyecto
emergiendo malentendidos temprano, cuando el problema se puede resolver fácilmente.
Musselman también sugiere mantener un registro del proyecto que proporcione un
registro completo de los logros, solicitudes de cambio, decisiones clave y otros elementos
de importancia.
Por el lado de los informes, Musselman sugiere entregas frecuentes. Estos pueden
o no ser el resultado de grandes logros. Su máxima es que "es mejor trabajar con muchos
hitos intermedios que con una fecha límite absoluta". Las posibilidades antes del informe
final incluyen una especificación modelo, demostraciones de prototipos, animaciones,
resultados de capacitación, análisis intermedios, documentación del programa, informes
de progreso y presentaciones Él sugiere que estos entregables deben ser cronometrados
juiciosamente durante la vida del proyecto.
El resultado de todo el análisis debe informarse de manera clara y concisa en un
informe final. Esto permitirá a los usuarios del modelo (ahora, los tomadores de
decisiones) revisar la formulación final, los sistemas alternativos que se abordaron, el
criterio por el cual se compararon las alternativas, los resultados de los experimentos y la
solución recomendada para el problema. Además, si las decisiones deben justificarse a un
nivel más alto, el informe final debe proporcionar un vehículo de certificación para el
usuario modelo / tomador de decisiones y agregar credibilidad al modelo y al proceso de
construcción del modelo.

Implementación.
El éxito de la fase de implementación depende de qué tan bien se hayan realizado
los once pasos anteriores. También depende de qué tan a fondo el analista haya
involucrado al usuario modelo final durante todo el proceso de simulación. Si el usuario
del modelo se ha involucrado a fondo y comprende la naturaleza del modelo y sus
resultados, la probabilidad de una implementación vigorosa aumenta [Pritsker, 1995]. Por
el contrario, si el modelo y sus supuestos subyacentes no se han comunicado
correctamente, la implementación probablemente se verá afectada, independientemente
de la validez del modelo de simulación.
El proceso de construcción del modelo de simulación que se muestra en la Figura
1.3 se puede dividir en cuatro fases. La primera fase, que consta de los pasos 1 (Fórmula
del problema) y 2 (Establecimiento del objetivo y diseño general), es un período de
descubrimiento u orientación. La declaración inicial del problema generalmente es
bastante "borrosa", los objetivos iniciales generalmente tendrán que restablecerse, y el
plan del proyecto original por lo general deberá afinarse. Estas re calibraciones y
aclaraciones pueden ocurrir en esta fase, o quizás después o durante otra fase (es decir, el
analista puede tener que reiniciar el proceso).
 La segunda fase está relacionada con la creación de modelos y la recopilación de
datos e incluye los pasos 3 (Conceptualización del modelo), 4 (Recopilación de datos), 5
(Traducción del modelo), 6 (Verificación) y 7 (Validación). Se requiere una interacción
continua entre los pasos. La exclusión del usuario modelo durante esta fase puede tener
graves implicaciones en el punto de implementación.
La tercera fase se refiere a ejecutar el modelo. Implica los pasos 8 (Diseño
experimental), 9 (Ejecuciones de producción y análisis) y 10 (Ejecuciones adicionales). Esta
fase debe tener un plan bien concebido para experimentar con el modelo de simulación.
Una simulación estocástica de evento discreto es, de hecho, un experimento estadístico las
variables de salida son estimaciones que contienen errores aleatorios y, por lo tanto, se
requiere un análisis estadístico adecuado. Dicha filosofía difiere mucho de la del analista
que realiza una única ejecución y extrae una inferencia de ese único punto de datos.
La cuarta fase, la implementación, implica los pasos 11 (Documentación y
presentación de informes) y 12 (Implementación). La implementación exitosa depende de
la participación continua del usuario modelo y la finalización exitosa de cada paso del
proceso. Quizás el punto más crucial en todo el proceso sea el paso 7 (Validación), porque
un modelo no válido llevará a resultados erróneos, que si se implementan podrían ser
peligrosos, costosos o ambos.