El desafío
por Thomas J. Schriber (Universidad de Michigan), Daniel T. Brunner (Dan Brunner Associates) y Jeffrey S. Smith (Universidad de Auburn).
Tal y como se presentó en la Conferencia de Simulación de Invierno de 2017
Este artículo proporciona a los profesionales y consumidores de simulación una base sobre cómo funciona el software de simulación de eventos discretos. Los temas incluyen sistemas de eventos discretos; entidades, recursos, elementos de control y operaciones; ejecuciones de simulación; estados de entidades; listas de entidades; y su gestión. Se describen las implementaciones de estas ideas genéricas en AutoMod, SLX, ExtendSim y Simio. El documento concluye con varios ejemplos de "por qué es importante" para los modeladores saber cómo funciona su software de simulación, incluyendo la discusión de AutoMod, SLX, ExtendSim, Simio, Arena, ProModel, y GPSS/H.
1 Introducción
A menudo se adopta un enfoque de "caja negra" en la enseñanza del software de simulación de eventos discretos. Se estudian las características externas del software, pero los fundamentos en los que se basa sólo se tratan brevemente o se ignoran por completo (por falta de tiempo). Es posible que no se estudien en absoluto las decisiones tomadas a la hora de implementar la base y el impacto de estas decisiones en la ejecución del modelo paso a paso. De este modo, el modelador podría no ser capaz de reflexionar cuando se enfrente al desarrollo de buenos enfoques para modelar situaciones complejas, al uso de herramientas interactivas para llegar a comprender las condiciones de error que surgen durante el desarrollo del modelo y al uso de herramientas interactivas para verificar que la lógica del sistema complejo se ha modelado correctamente. El objetivo aquí es describir los fundamentos lógicos de la simulación de eventos discretos e ilustrar este material en términos de varias implementaciones de software de simulación de eventos discretos.
En las secciones 2, 3 y 4 comentamos la naturaleza de la simulación de eventos discretos; las construcciones básicas de simulación, como entidades, recursos, elementos de control y operaciones; y la ejecución del modelo. En la Sección 5 se analizan cuatro implementaciones específicas de reglas de gestión de entidades. Por último, la Sección 6 explora varios aspectos de "por qué importa". A lo largo de este documento, los términos que definimos aparecen en negrita la primera vez que se utilizan. Los términos específicos de las herramientas se escriben en mayúsculas o, en su caso, en MAYÚSCULAS.
Este artículo es una versión revisada de otro similar que apareció inicialmente en las Actas de la Conferencia de Simulación de Invierno de 1996 (Schriber y Brunner 1996). Desde 1996 se ha presentado en la conferencia una versión del artículo de 1996, con actualizaciones ocasionales, como la modificación del conjunto de lenguajes tratados en detalle. Por ejemplo, la ponencia de 1996 cubría las reglas de gestión de listas de entidades y "por qué es importante" para SIMAN (Arena), ProModel y GPSS/H. (En Schriber y Brunner (1998) se puede encontrar una versión ampliada del documento de 1996 que contiene figuras, diagramas de flujo y explicaciones adicionales).
La solución
2 Simulación de eventos discretos desde el punto de vista del flujo de transacciones
La "visión del mundo del flujo de transacciones" suele servir de base para la simulación de eventos discretos. En esta visión del mundo, un sistema se visualiza como si consistiera en unidades discretas de tráfico que se mueven (fluyen) de un punto a otro del sistema mientras compiten entre sí por el uso de recursos escasos (de capacidad limitada). Las unidades de tráfico se denominan a veces "transacciones", dando lugar a la expresión "flujo de transacciones". Numerosos sistemas se ajustan a la descripción anterior. Entre ellos se encuentran los sistemas de fabricación, manipulación de materiales, servicios, atención sanitaria, comunicación y procesamiento de la información, así como otros sistemas generales de colas.
Fundamentalmente, una simulación de eventos discretos es aquella en la que el estado de un modelo cambia sólo en un conjunto discreto, pero posiblemente aleatorio, de puntos temporales simulados, denominados tiempos de evento. A menudo hay que manipular dos o más unidades de tráfico en un mismo momento. Este movimiento "simultáneo" del tráfico se consigue manipulando unidades de tráfico en serie en ese punto temporal. Esto conlleva complejidades lógicas porque plantea cuestiones sobre el orden específico en tiempo real en el que deben procesarse dos o más unidades de tráfico en un momento simulado determinado.
Los retos a los que se enfrenta un modelador se intensifican para el diseñador de un lenguaje de modelado. El diseñador debe tener en cuenta de forma generalizada los requisitos lógicos de la simulación de eventos discretos. Existen opciones y compromisos. Como resultado, aunque los lenguajes de simulación de eventos discretos son similares en términos generales, pueden diferir en detalles sutiles pero importantes. En este artículo pretendemos ampliar esta noción y ofrecer ejemplos concretos. Antes de hacerlo, sin embargo, las siguientes secciones proporcionan conceptos generales adicionales de simulación.
3 Entidades, recursos, elementos de control y funcionamiento
El término entidad se utiliza aquí para designar una unidad de tráfico (una "transacción") dentro de un modelo. Las entidades instigan y responden a eventos. Un evento es un suceso instantáneo que cambia el estado de un modelo (o sistema). En un modelo de sistema de pedidos, por ejemplo, la llegada de un pedido (un acontecimiento) puede simularse introduciendo una entidad en el modelo. Existen dos tipos posibles de entidades, denominadas aquí entidades externas y entidades internas. Las entidades externas son aquellas cuya creación y movimiento están explícitamente organizados por el modelador (ejemplo: llegada de un pedido a un punto de procesamiento de pedidos). Por el contrario, las entidades internas son creadas y manipuladas implícitamente por el software de simulación. Por ejemplo, las entidades internas pueden utilizarse en algunos lenguajes para desencadenar fallos simulados de las máquinas e implementar horarios de las máquinas, mientras que las entidades externas pueden utilizarse para simular el uso de máquinas para el procesamiento de piezas.
El término recurso designa un elemento del sistema que presta un servicio (como un taladro, un vehículo de guiado automático, un trabajador o un espacio en un búfer de entrada). Las entidades suelen utilizar recursos (por ejemplo, una entidad de trabajo en curso reclama espacio en una memoria intermedia de entrada y, a continuación, captura un vehículo de guiado automático para trasladar la entidad a la memoria intermedia de entrada). Los recursos suelen tener una capacidad limitada, por lo que las entidades compiten por su uso y a veces deben esperar para utilizarlos, experimentando retrasos como resultado (colas). El término elemento de control designa una construcción que admite otros tipos de retardo o alternativas lógicas basadas en el estado de un sistema. Los elementos de control pueden adoptar la forma de interruptores, contadores, valores de datos del usuario y valores de datos del sistema integrados en la herramienta de modelado. Las condiciones complejas pueden evaluarse con expresiones aritméticas y/o booleanas que examinan el estado de los elementos de control pertinentes.
Una operación es un paso (o una serie de pasos) realizado por o sobre una entidad mientras se desplaza por un sistema. Las operaciones aplicables a un barco en un puerto podrían incluir: llegar al puerto; solicitar un amarre; capturar un amarre; solicitar un remolcador; capturar un remolcador; ser arrastrado al amarre; liberar el remolcador; cargar carga; solicitar un remolcador; ser arrastrado fuera del amarre; liberar el amarre; ser arrastrado a mar abierto; liberar el remolcador; partir.
4 Resumen de la ejecución del modelo
Un proyecto de simulación implica la ejecución de experimentos. Los experimentos se diferencian por el uso de alternativas en la lógica del modelo y/o en los datos de entrada. Por ejemplo, en el modelo de un sistema de producción se pueden probar reglas alternativas de secuenciación de piezas y/o variar el número de distintos tipos de máquinas (recursos). Del mismo modo, se puede variar el número de muelles de carga y descarga de un puerto para evaluar su impacto en el rendimiento del sistema. Cada experimento consta de una o varias réplicas (ensayos). Una réplica es una simulación que utiliza la lógica y los datos del modelo del experimento, pero su propio conjunto único de números aleatorios, por lo que produce resultados estadísticos únicos que pueden analizarse como parte de un conjunto de tales réplicas (todas ellas independientes). Una réplica consiste en inicializar el modelo, ejecutarlo hasta que se cumpla una condición de finalización de la ejecución e informar de los resultados. Esta fase se denomina ejecución.
Durante una ejecución, el reloj de simulación (un valor de datos almacenado y gestionado internamente) sigue el paso del tiempo simulado. El reloj avanza (automáticamente) en pasos discretos (normalmente de tamaño desigual) durante la ejecución. Una vez realizadas todas las acciones posibles en un momento simulado determinado, el reloj avanza hasta el momento del siguiente evento más antiguo. Entonces se llevan a cabo las acciones apropiadas en este nuevo tiempo simulado, etc. En esencia, la ejecución de un recorrido adopta, por tanto, la forma de un bucle de dos fases: "Estas dos fases se repiten una y otra vez hasta que se produce una condición de fin de ejecución (normalmente un tiempo simulado especificado por el modelador, un número de entidades procesadas u otra condición). Estas dos fases se denominan aquí, respectivamente, fase de movimiento de la entidad (EMP) y fase de actualización del reloj (CUP).
4.1 Estados de las entidades
A medida que se ejecuta la simulación, las entidades migran de un estado a otro mientras se mueven por el modelo. Los cinco estados que se suelen utilizar son:
Activo- El estado de la entidad que se mueve actualmente es el estado activo. Por "entidad que se mueve actualmente" entendemos la entidad que está ejecutando actualmente la lógica de decisión en el modelo. Sólo se mueve una entidad en cada instante del tiempo del reloj de pared. Esta entidad se mueve hasta que encuentra un retraso de un tipo u otro. Entonces migra a un estado alternativo.
Listo- Durante una fase de movimiento de una entidad puede haber más de una entidad lista para moverse, y sin embargo las entidades sólo pueden moverse (estar en estado activo) de una en una. El estado listo es el estado de las entidades que esperan entrar en el estado activo durante la fase actual de movimiento de entidades.
Retrasado en eltiempo - El estado retrasado en el tiempo es el estado de las entidades que esperan a que se alcance un tiempo simulado futuro conocido para poder (re)entrar en el estado preparado. Una entidad "parte" se encuentra en un estado temporizado, por ejemplo, mientras espera el tiempo simulado futuro en el que finalizará una operación que se está realizando sobre ella.
Condición retrasada- El estado de condición retrasada es el estado de las entidades retrasadas hasta que se produzca alguna condición especificada, por ejemplo, una entidad "parte" podría esperar en el estado de condición retrasada hasta que llegue su turno para utilizar una máquina. Las entidades de condición retrasada se transfieren automáticamente del estado de condición retrasada al estado listo cuando las condiciones especificadas lo permiten.
Dormido - A veces es deseable o necesario poner las entidades en un estado desde el cual no se activará ninguna salida automáticamente por cambios en las condiciones del modelo. A este estado lo llamamos estado latente. Las entidades en estado latente dependen de la lógica proporcionada por el modelador para transferirlas del estado latente al estado listo. Por ejemplo, las entidades de solicitud de trabajo pueden ponerse en estado latente hasta que una entidad operadora decida qué solicitud de trabajo va a sacar a continuación, con la consiguiente transferencia de la entidad de solicitud de trabajo al estado listo. En este caso, es posible que no se conozcan las condiciones específicas en vigor al seleccionar la ficha de trabajo hasta que llegue el momento de que la entidad operadora seleccione una ficha de trabajo.
4.2 Estructuras de gestión de entidades
En nuestro modelo genérico, gestionamos las entidades designando una Entidad Activa y una serie de listas de entidades. La entidad activa (la entidad en estado activo) se mueve sin parar hasta que se encuentra con un paso (intento) que la hace migrar a otro estado de entidad (la transfiere a otra lista) o la elimina del modelo. Una entidad lista se convierte entonces en la siguiente entidad activa. Finalmente, no hay más entidades listas en el momento actual. El PEM finaliza y comienza un CUP. Las siguientes listas se utilizan para organizar las entidades. (La dinámica del movimiento de entidades entre estas listas se ilustrará en una secuencia de diapositivas de PowerPoint durante la conferencia de la Conferencia de Simulación de Invierno que se impartirá en relación con este tutorial).
Lista de Eventos Actuales- Las entidades en el estado listo se mantienen en una sola lista que llamamos lista de eventos actuales (CEL). Las entidades migran a la CEL desde la lista de eventos futuros, las listas de retrasos y las listas gestionadas por el usuario (cada una de ellas se describe más adelante). Además, las entidades clonadas de la entidad en estado activo suelen comenzar su existencia en la CEL. Las entidades CEL se clasifican generalmente en orden FIFO (primero en entrar, primero en salir). Algunas herramientas de software proporcionan un atributo de Prioridad de entidad incorporado que se utiliza para ordenar Entidades en la CEL por prioridad (con empates resueltos utilizando FIFO).
Lista de eventos futuros - Las entidades en el estado de retraso temporal pertenecen a una lista única en la que se insertan al principio de su retraso temporal. Esta lista, llamada aquí lista de eventos futuros (FEL), se ordena normalmente por el tiempo de movimiento creciente de la entidad. El tiempo de movimiento es el tiempo simulado en el que está previsto que una entidad intente moverse de nuevo (el final del tiempo de tratamiento de un paciente en una clínica o el final del tiempo de procesamiento de una pieza en un sistema de fabricación, por ejemplo). En el momento de la inserción de la entidad en la FEL, el tiempo de movimiento de la entidad se calcula sumando el valor del reloj de simulación a la duración conocida (muestreada) del retardo basado en el tiempo. Una vez finalizada la PGA, el CUP ajusta (avanza) el valor del reloj al tiempo de movimiento de la entidad de mayor rango (menor tiempo de movimiento) de la FEL. A continuación, esta entidad se transfiere de la FEL a la CEL, pasando del estado de retraso temporal al estado de preparado y preparando el escenario para que comience la siguiente PGA. La declaración anterior asume que no hay otras entidades en la FEL cuyo tiempo de movimiento coincida con el valor actualizado del reloj. En el caso de vínculos de tiempo de movimiento, algunas herramientas transferirán todas las entidades vinculadas al tiempo de la FEL al CEL durante un único CUP, mientras que otras herramientas adoptan un enfoque de "sólo una transferencia de entidad por CUP". Los lenguajes que proporcionan entidades internas suelen utilizar la FEL para soportar los requisitos temporales de estas entidades. (La FEL incluye entonces entidades internas y externas).
Listas de retardo- Las listas (puede haber muchas) de entidades en estado de condición-retardo se denominan listas de retardo. Estas entidades están esperando (por ejemplo, esperando su turno para utilizar una máquina) hasta que se resuelva su retraso para que puedan ser transferidas automáticamente al estado listo en la CEL. Las listas de espera, que suelen ser creadas automáticamente por el software de simulación, se gestionan utilizando uno de los dos tipos de espera. Si un retraso se puede relacionar fácilmente con los eventos del modelo que podrían resolver el retraso, entonces se puede utilizar la espera relacionada para gestionar la lista de retrasos. Por ejemplo, supongamos que el estado de una máquina pasa de ocupado a inactivo. En respuesta, el software puede eliminar automáticamente la siguiente entidad en espera de la lista de retrasos correspondiente y ponerla en estado listo en el CEL. La espera relacionada es el método más utilizado para gestionar los retrasos condicionales. Si la condición de retraso es demasiado compleja para relacionarla fácilmente con los eventos que podrían resolverla, puede utilizarse la espera sondeada. Con la espera sondeada, el software comprueba rutinariamente si las entidades pueden transferirse de una o más listas de retrasos al estado listo. Las condiciones de retraso complejas para las que puede ser útil la espera sondeada incluyen combinaciones booleanas de cambios de estado, por ejemplo, un puesto de atraque está vacío y un remolcador está inactivo.
Listas gestionadas por el usuarioLas listas(puede haber muchas) de entidades en estado de espera se denominan listas gestionadas por el usuario. El modelador debe tomar medidas para establecer dichas listas y normalmente debe proporcionar la lógica necesaria para transferir entidades a y desde las listas. Excepto en el caso de puntos de servicio muy simples de una línea y un servidor en un sistema, el software subyacente no tiene forma de saber por qué las entidades se han puesto en listas gestionadas por usuarios en primer lugar y, por lo tanto, no tiene ninguna base para eliminar automáticamente las entidades de dichas listas.
5 Implementación en cuatro herramientas
Las herramientas elegidas aquí para comentar los detalles de implementación son AutoMod (Phillips 1997); SLX (Henriksen 2000; Schulze 2008); ExtendSim (Imagine That Incorporated 2015; Krahl 2012); y Simio (Kelton et al., 2014). Una versión anterior de este documento (Schriber y Brunner 1996) cubría SIMAN (Arena) (Kelton et al., 2014), ProModel (ProModel Corporation 2015) y GPSS/H (Henriksen y Crain 2000) con un detalle similar. Creemos que estas herramientas son representativas, pero evidentemente no son exhaustivas (véase Swain 2015 para un estudio bienal de las muchas herramientas disponibles).
5.1 AutoMod
La lista de eventos actuales se denomina Lista de Eventos Actuales (CEL) en AutoMod (ver Tabla 1). Cargas Clonadas, Cargas que dejan la FEL debido a una actualización del reloj, y Cargas ordenadas fuera de las Listas de Ordenes son colocadas inmediatamente en la CEL. La regla de inserción es ordenar primero por prioridad (la prioridad es un atributo incorporado de cada Carga) y luego FIFO dentro de la prioridad. Cuando la CEL se vacía, se comprueba la Lista de Retraso de Condiciones (véase más adelante), y las cargas pueden transferirse desde allí a la CEL. Esto continúa hasta que la CEL está vacía y no se pueden transferir más cargas, momento en el que se termina el EMP y se inicia un CUP.
La Lista de Eventos Futuros (FEL) de AutoMod es como las listas de eventos futuros de otras herramientas. Las cargas llegan a la FEL en estado diferido mediante la ejecución de una sentencia WAIT FOR. AutoMod permite especificar unidades de tiempo (día, hora, minuto, segundo) en una sentencia WAIT FOR. El CUP de AutoMod elimina múltiples Cargas de la FEL si están empatadas para el tiempo de movimiento más temprano, insertándolas una a una en su lugar apropiado en la CEL. También hay entidades internas en AutoMod, llamadas Cargas Lógicas, que hacen cosas como esperar en la FEL para activar descansos de turno programados.
Las Listas de Retraso (DL's) son listas de Cargas esperando reclamar capacidad proporcionada por cualquiera de los cinco elementos de capacidad finita (Recurso, Cola, Bloque, Contador o Límite de Tráfico de Proceso; ver Tabla 1). Cada elemento de capacidad finita del modelo tiene asociado un DL. La espera que se produce en estos cinco casos es una espera relacionada. Cada vez que se libera capacidad, una carga de la cabecera del DL del elemento se coloca provisionalmente en el CEL (pero se deja un marcador de posición en el DL). Cuando esa carga se encuentra durante la EMP, intenta reclamar la capacidad solicitada. Si falla (por ejemplo, porque quiere dos unidades pero sólo hay una libre), se devuelve a la DL en su lugar original (éste es un comportamiento por defecto que el modelador puede anular. Véase la sección 6.2 para un análisis más general). Inmediatamente después de esta evaluación, si todavía hay capacidad no utilizada, la siguiente carga (si la hay) en el DL correspondiente se coloca en el CEL. El procesamiento de la carga activa continúa, seguido de la evaluación de la siguiente carga colocada provisionalmente. Y así sucesivamente, de forma provisional, para cada carga siguiente (si la hay) durante la PGA.
Para la espera condicional aparte de los cinco casos descritos anteriormente, AutoMod tiene una sentencia WAIT UNTIL que da lugar a una espera sondeada. Las condiciones WAIT UNTIL se pueden componer utilizando operadores booleanos. Si una carga ejecuta una WAIT UNTIL y la condición es falsa, la carga se coloca en una única lista global de AutoMod denominada Lista de condiciones de espera (CEL). Una vez vaciada la CEL, pero antes de que se actualice el reloj de simulación, todas las cargas de la CDL se mueven a la CEL (en realidad, la CDL "se convierte" en la CEL) si se ha producido un cambio de estado en al menos un elemento del mismo tipo general (por ejemplo, una cola) por el que esté esperando alguna carga de la CDL (este mecanismo es principalmente de "sondeo", en el que el proceso de sondeo se activa por un cambio de estado de al menos un elemento del mismo tipo general).
Si la CEL no está vacía, la PGA se reanuda. Si la condición por la que espera una carga de la CEL aún no se cumple, AutoMod mueve esa carga de la CEL de nuevo a la CDL. En algunos casos, la CDL puede vaciarse varias veces durante una PGA hasta que, finalmente, la CEL se haya vaciado sin haber provocado un cambio de estado relacionado con ninguna carga en la CDL. Entonces se produce un CUP. Debido al potencial de migración repetitiva de listas con WAIT UNTIL, el vendedor de AutoMod alienta el uso de Listas de Orden u otros mecanismos de control explícitos para manejar esperas complejas.
AutoMod implementa el estado de espera con Listas de Pedidos, que son listas de Cargas gestionadas por el usuario. Después de que una Carga se inscribe en una Lista de Pedidos (ejecutando una Acción ESPERAR A SER PEDIDA), sólo puede ser eliminada por otra Carga (u otro elemento activo del modelo, como un Vehículo) que ejecute una Acción PEDIR. Una Acción de PEDIDO puede especificar una cantidad de Cargas, o una condición que debe cumplirse para una Carga dada si esa Carga va a ser pedida, o ambas. Las cargas pedidas con éxito se colocan inmediatamente en el CEL (de una en una según cómo se eligieron de la Lista de Pedidos, y clasificadas en el CEL por prioridad, con los empates de prioridad resueltos FIFO). Las listas de pedidos pueden mejorar el rendimiento con respecto a la espera de CDL, ya que las listas de pedidos nunca se escanean, excepto cuando se solicita explícitamente. Las Listas de Pedidos de AutoMod ofrecen varias características interesantes, entre las que se incluyen: la posibilidad de que una Carga ordenante realice un pedido pendiente si no se satisface la cantidad del PEDIDO; la posibilidad de que se ordene a una Carga de una Lista de Pedidos que continúe a la siguiente Acción en lugar de a un Proceso (esta característica es útil para el handshaking de control); y la posibilidad de tener una función llamada para cada Carga de la Lista de Pedidos (utilizando la Acción PEDIDO...SATISFACCIÓN).
AutoMod tiene varias construcciones de manejo de materiales que están integradas con el movimiento de Cargas. Para los sistemas de vehículos existen otros tres tipos de listas (no incluidas en la Tabla 1). Las cargas en Listas de Cargas Listas (LRL) (una lista por sistema de vehículos) están a la espera de ser recogidas por un vehículo. Las cargas reclamadas (pero aún no recogidas) por un vehículo residen en la Lista de Vehículos Reclamados (VCL) del vehículo. Las cargas reclamadas que han sido recogidas residen en la Lista de Vehículos a Bordo (VOL) del vehículo. El vehículo se convierte entonces en la "carga" activa y se mueve entre las listas de AutoMod (FEL, CEL, y posiblemente DL's) en lugar de las Cargas mismas.
5.2 SLX
SLX es un lenguaje jerárquico en el cual las primitivas incorporadas están en un nivel más bajo que la mayoría de los otros lenguajes de simulación, facilitando al usuario (o desarrollador) la definición del comportamiento de muchos elementos del sistema. Esta filosofía de diseño permite al usuario (o desarrollador) de SLX crear herramientas de modelado de alto nivel cuyas construcciones tienen un comportamiento modificable definido con precisión. En la Tabla 2 se indican los equivalentes de los términos genéricos para los usuarios de SLX de bajo nivel. Por ejemplo, SLX utiliza Variables de Control para actuar como Elementos de Control. El modificador "control" puede adjuntarse a una Variable de cualquier tipo de datos (entero, real, cadena, etc.). Una Variable de Control puede ser global, o puede ser una Variable local declarada en la definición de Clase de un Objeto. (Una Variable declarada en una Clase es un atributo en otras herramientas).
SLX tiene dos tipos de Objetos: Activos y Pasivos. Los dos se distinguen por la presencia de acciones - Declaraciones ejecutables - en la definición de Clase de un Objeto Activo (incluso sin acciones, los Objetos Pasivos son útiles por derecho propio, funcionando como estructuras de datos complejas definidas por el usuario). La Tabla 3 muestra cómo las herramientas de alto nivel basadas en SLX pueden explotar las capacidades de definición de SLX.
La lista de eventos actuales se denomina Cadena de Eventos Actuales (CEC) en SLX. Los miembros de la CEC reciben el interesante nombre de Puck. ¿Qué es un Puck? SLX disocia el concepto de un Objeto Activo (con sus datos locales asociados) de un Puck, que es la "entidad móvil" que ejecuta las acciones, lleva sus propios datos de programación de entidades y migra de lista en lista. El efecto de esta disociación es que un único objeto puede "poseer" más de un Puck. Todos los Pucks pertenecientes a un mismo Objeto comparten los datos locales del Objeto (atributos). Por ejemplo, una aplicación de esta característica de "paralelismo local" (en comparación con el "paralelismo global" que ofrecen las acciones "clonar" o "dividir" en otros lenguajes) es el uso de un segundo Puck para simular un tiempo de balk mientras el Puck original está esperando alguna condición. (Si la condición se produce antes de que haya transcurrido el tiempo de balk, no se produce balking; en caso contrario, sí se produce balking).
La activación de un nuevo Objeto crea un Puck y lo lanza a la acción. En muchos casos nunca se crean Pucks adicionales para ese Objeto, y la combinación de un Objeto Activo y su Puck forma el equivalente a una entidad (los Objetos pasivos no tienen acciones y por lo tanto no poseen Pucks). Los Pucks recién activados, los Pucks que abandonan la FEC debido a una actualización del reloj y los Pucks reactivados (ver más abajo) se colocan en la CEC, ordenados FIFO por prioridad. El CEC está vacío cuando termina un PEM.
La Cadena de Eventos Futuros (FEC) de SLX es como las listas de eventos futuros de otras herramientas. Los pucks llegan a la FEC en estado diferido mediante la ejecución de una sentencia ADVANCE. El CUP SLX eliminará varios Pucks de la FEC si están empatados para el tiempo de movimiento más temprano, insertándolos uno a uno en su lugar apropiado en la CEC. Dado que la funcionalidad del núcleo SLX no incluye tiempos muertos ni siquiera la generación repetitiva de Pucks (llegadas programadas), toda la actividad en el FEC SLX se desarrolla según lo especificado por el desarrollador del modelo SLX. En términos más generales, si un usuario está utilizando un modelo (o está utilizando un constructor de modelos) que contiene primitivas de nivel superior definidas por un desarrollador, lo más probable es que todo tipo de cosas estén sucediendo entre bastidores, ocultas a la vista del usuario de nivel superior. Las Listas de Retraso (DL's) en SLX son listas de Pucks esperando (vía WAIT UNTIL) por cambios de estado en cualquier combinación de Variables de Control y el valor del reloj de simulación. Un Puck en espera de una condición compuesta que involucre dos o más Variables de Control se lista en más de una DL. Todas las construcciones de nivel superior definidas por los desarrolladores pueden utilizar este mecanismo. Cada Variable de Control (que puede ser una Variable local, en cuyo caso hay una por cada Objeto de la Clase) tiene asociada una DL independiente.
Una DL se clasifica por orden de inserción. Todos los pucks de un DL se eliminan cada vez que la Variable de Control asociada cambia de valor y se insertan de uno en uno en el CEC. Los Pucks eliminados que esperan condiciones compuestas también se eliminan provisionalmente de cada una de las otras Listas de Retraso a las que pertenecen. A medida que estos Pucks se encuentran en la CEC durante el EMP, los que no pasan su WAIT UNTIL se devuelven a la(s) Lista(s) de Retraso para aquellas Variables de Control que todavía contribuyen a la falsedad de la condición. Para las condiciones que incluyen una referencia de reloj, el Puck se inserta si es necesario en la FEC, sujeto a una eliminación anticipada de la FEC si la condición se convierte en verdadera debido a otros cambios de Variable de Control. Este mecanismo de espera relacionado de bajo nivel basado en Variables de Control es el enfoque SLX por defecto para modelar todos los tipos de estados simples o compuestos de condición retardada.
SLX maneja el estado de espera de una manera única. En lugar de mover el Puck del estado activo a una lista gestionada por el usuario y suspenderlo, todo en la misma operación, SLX divide esta operación en dos partes. En primer lugar, el Puck suele unirse a un Conjunto. Pero unirse a un Conjunto no suspende automáticamente al Puck. Un Puck puede pertenecer a cualquier número de Sets. La pertenencia a un conjunto sólo proporciona a cualquier otro Puck acceso a los Pucks miembros. Para pasar al estado inactivo, un Puck ejecuta una sentencia WAIT. Entonces queda suspendido indefinidamente, fuera de cualquier lista particular, hasta que otro Puck identifica al Puck en espera y ejecuta una sentencia REACTIVATE para él. A menudo, este otro Puck está escaneando un Conjunto para encontrar el Puck a REACTIVAR, pero un Conjunto no es exactamente lo mismo que una lista gestionada por el usuario en nuestra terminología. Un Puck en estado latente puede no ser miembro de ningún Set (siempre que se haya almacenado un puntero al mismo en algún lugar) o de uno o más Sets. Un desarrollador SLX puede definir fácilmente una construcción de lista gestionada por el usuario, utilizando Sets, WAIT, y REACTIVATE como bloques de construcción, que imite a los de otros lenguajes u ofrezca sus propias características únicas.
5.3 ExtendSim
ExtendSim (originalmente llamado Extend) utiliza una arquitectura basada en mensajes para la simulación de eventos discretos. Se utilizan varios tipos de mensajes para programar eventos, impulsar elementos (entidades) a través de un modelo, aplicar la lógica incorporada a un modelo y forzar el cálculo. Los emisores y receptores de mensajes son Bloques (Operaciones), incluido el Bloque Ejecutivo (controlador maestro). En ExtendSim, lo que se programa es la ejecución de los Bloques (cuando un Bloque se ejecuta, por ejemplo, puede desencadenar el envío de mensajes de un Bloque a otro, con el efecto de mover un Elemento a lo largo de su ruta basada en Bloques en un modelo). La tabla 4 resume los equivalentes de ExtendSim para los términos introducidos en la discusión genérica anterior.
Un bloque es la construcción básica de modelado en ExtendSim. Cada bloque tiene un icono, conectores de paso de mensajes, capacidad de diálogo y código de definición de comportamiento. Los Bloques de Residencia pueden contener elementos mientras transcurre el tiempo simulado, mientras que los Bloques de Paso no pueden (los elementos pasan a través de los Bloques de Paso en tiempo simulado cero). Los modelos pueden construirse seleccionando Bloques preprogramados de las bibliotecas de Bloques de ExtendSim. El modelador también puede modificar el código fuente de los bloques de la biblioteca (todos los bloques de la versión base de ExtendSim son de código abierto). Finalmente, el modelador puede crear Bloques personalizados desde cero (Bloques programados por el usuario) utilizando las herramientas de desarrollo que proporciona ExtendSim.
ExtendSim utiliza una matriz de tiempo para programar futuras ejecuciones de bloques. Para un modelo dado, la Matriz de Tiempos contiene uno o más elementos para cada Bloque. Un elemento de la Matriz de Tiempos registra el tiempo futuro para el que se ha programado la ejecución de ese Bloque. La posibilidad de que un bloque tenga más de un elemento de la matriz de tiempo es una mejora de la versión 7 del lenguaje (la versión actual es la 8). Esta característica puede ser útil cuando un bloque tiene varios eventos distintos, como por ejemplo en el modelado de transportadores.
Los Bloques que no están actualmente programados para una futura ejecución se "apagan" temporalmente registrando valores de tiempo arbitrariamente grandes para ellos en la Matriz de Tiempos. Los Bloques de Residencia que pueden contener varios Elementos gestionan internamente los tiempos de evento correspondientes, guardando en la Matriz de Tiempos sólo el más antiguo de los tiempos de evento del Bloque. Esta es una lista de eventos de dos etapas, ya que los Bloques pueden contener listas enlazadas optimizadas que sirven como sus propias listas de eventos futuros. La ejecución de un Bloque puede resultar en la programación de futuras ejecuciones de Bloques. Por ejemplo, si se pasan mensajes que hacen que un elemento entre en un bloque de residencia de capacidad unitaria diseñado para retener el elemento hasta que haya transcurrido una cantidad de tiempo simulado, la entrada de la matriz de tiempo de ese bloque tendrá el valor correspondiente.
El número de Bloques en un modelo dado es constante, lo que significa que la Matriz de Tiempos es de tamaño fijo y relativamente pequeño. Debido a su pequeño tamaño, la Matriz de Tiempos se busca para encontrar la hora del evento inminente; no se mantiene ordenada. Esto hace que sea sencillo para un bloque cambiar la hora de un evento, ya que no es necesario buscar en la lista de eventos. La Matriz de Próximas Horas se utiliza para gestionar la ejecución de los Bloques cuya ejecución se ha programado a través de la Matriz de Horas. La Matriz de Próximas Horas se rellena justo antes de una Fase de Ejecución de Bloque (el equivalente de ExtendSim a una PEM) de la siguiente manera. En cada CUP, se busca en la matriz de tiempos la hora futura más temprana en la que se ha programado la ejecución de un bloque. Los identificadores para el Bloque correspondiente (o Bloques, en caso de empate temporal) se colocan en la Matriz de Tiempos Próximos. Comienza entonces la Fase de Ejecución de Bloques (BEP), en la que el Ejecutivo envía un mensaje al Bloque más cualificado de la matriz de Próximas Horas para iniciar su ejecución.
La Matriz de Eventos Actuales se utiliza para gestionar la reanudación de la ejecución de Bloques cuya ejecución se ha suspendido temporalmente durante el transcurso de una Fase de Ejecución de Bloques. Por ejemplo, supongamos que un Bloque envía un mensaje, y que el Bloque receptor responde (devuelve el control) inmediatamente al Bloque emisor (aunque el Bloque receptor aún tenga que realizar procesamiento adicional en el tiempo simulado en cuestión). En este caso, el identificador del bloque receptor se añade a la matriz de eventos actuales. Cuando el bloque emisor termina de ejecutarse, el Ejecutivo envía un mensaje al bloque más cualificado de la matriz de eventos actuales para reanudar su ejecución. Finalmente, la matriz de eventos actuales se vacía. Entonces, el Ejecutivo se dirige de nuevo a la Matriz de Próximas Veces, enviando un mensaje al Bloque más cualificado para que comience su ejecución.
Durante una Fase de Ejecución de Bloque, los Bloques pueden programarse para ejecutarse en el tiempo simulado actual (es decir, durante la BEP en curso). Aquí también entra en juego la matriz de eventos actuales para gestionar la ejecución de los bloques en estos casos. Por ejemplo, si un bloque con capacidad limitada no se llena como resultado de la ejecución de otro bloque, el bloque no lleno introduce su identificador en la matriz de eventos actuales. El Ejecutivo enviará más tarde (pero en el mismo tiempo simulado) un mensaje al Bloque para que comience a ejecutarse. A continuación, el Bloque intentará atraer hacia sí los Elementos (si los hay) que han estado esperando para entrar en el Bloque (en ExtendSim, los Elementos pueden ser tanto atraídos como empujados a través de un modelo). Cuando la Matriz de Eventos Actuales y la Matriz de Próximos Tiempos se vacían, la Fase de Ejecución del Bloque de ExtendSim llega a su fin. Entonces tienen lugar las siguientes CUP y BEP, repitiéndose hasta que se cumple una condición de fin de simulación. Las listas de Retraso consisten en Elementos retrasados en Bloques de Residencia, esperando su turno para ser arrastrados o empujados a su(s) siguiente(s) Bloque(s). El paso de mensajes se utiliza para llevar a cabo la extracción y el empuje cuando las condiciones del modelo lo permiten. ExtendSim proporciona una gestión de espera relacionada de estos elementos basada en las alternativas especificadas por el usuario de primero en entrar, primero en salir (FIFO), último en entrar, primero en salir (LIFO), prioridad, atributo, renegación, coincidencia y basada en ecuaciones. La espera de la resolución de condiciones compuestas se consigue normalmente en ExtendSim combinando adecuadamente Bloques y explotando la arquitectura basada en mensajes de ExtendSim. Vemos esto como una forma de espera relacionada, porque es un cambio en un valor subyacente el que desencadena una reevaluación de la condición que provocó la espera en primer lugar.
Debido a la arquitectura de mensajería de ExtendSim, la espera por sondeo no suele ser necesaria. Se envía un mensaje cuando cambia un valor y cualquier condición se evalúa en ese momento. La espera de un evento basado en un reloj puede conseguirse utilizando un Bloque que programe eventos, por ejemplo, Turno; Tabla de consulta; Ecuación. Estos Bloques envían un mensaje a horas programadas. Sin embargo, la espera por sondeo está disponible con el uso del Bloque Puerta y la selección de su opción "Comprobar demanda en cada evento".
El modelador puede trabajar con Bloques programados por el usuario para crear y gestionar listas de diseño propio. El código de los Bloques personalizados puede escribirse para alcanzar los objetivos del modelador en este sentido, del mismo modo que el código de los Bloques preprogramados de ExtendSim se ha escrito para especificar el comportamiento de dichos Bloques. ExtendSim proporciona funciones que pueden ser utilizadas por los Bloques para compartir listas (arrays) con otros Bloques, apoyando aún más la gestión personalizada de listas en los modelos.
5.4 Simio
Simio es un lenguaje orientado a objetos en el que todas las construcciones del modelo son objetos de Simio derivados del mismo objeto base. La mayoría de los usuarios de Simio utilizarán principalmente objetos de la biblioteca estándar de Simio para construir modelos. Entidades, Recursos, Servidores, Estaciones de trabajo, Fuentes, Sumideros, Nodos y Conectores son los objetos de la biblioteca estándar más utilizados. Por debajo, Simio se basa en Procesos que se componen de Pasos de Proceso individuales ejecutados por Fichas. Los comportamientos de los objetos de la biblioteca estándar se implementan (por parte del diseñador de objetos) mediante procesos. Aunque la mayoría de los modelos se construirán utilizando estos Objetos de alto nivel, los usuarios (y desarrolladores) tienen acceso completo a los procesos de Simio y pueden desarrollar modelos completos así como Objetos reutilizables utilizando los procesos de Simio. Además, los usuarios pueden aumentar el comportamiento de los Objetos existentes utilizando Procesos adicionales y/o Subclasificando Objetos existentes. Los propios modelos de Simio son en realidad Objetos que pueden incrustarse en otros modelos. La estructura de objetos de Simio facilita el desarrollo de bibliotecas de objetos personalizadas que pueden simplificar el proceso de modelado en distintos ámbitos de aplicación.
En la Tabla 5 se indican los equivalentes de los términos genéricos para los usuarios de Simio. Tenga en cuenta que cualquier objeto de Simio puede actuar como recurso estableciendo la propiedad "Objeto Recurso" en True. El objeto Resource de la biblioteca estándar es análogo a un recurso en el contexto de este documento. La relación entre los objetos entidad de Simio y las fichas es similar en concepto a la relación entre el objeto activo y los discos en SLX. En concreto, a medida que los objetos interactúan (por ejemplo, un objeto Entidad que se desplaza a través de un objeto Servidor para hacer cola y acceder a un recurso de capacidad finita), uno o varios tokens asociados a estos objetos ejecutan los procesos (secuencias de pasos) que conforman el comportamiento de los objetos. La capacidad de tener múltiples tokens ejecutando diferentes procesos en nombre del mismo objeto proporciona flexibilidad de modelado.
Las propiedades y los estados de los objetos son elementos de control de Simio. Tanto las propiedades como los estados son atributos de los objetos. Las propiedades se definen al inicio de una ejecución y no cambian durante la misma, mientras que los estados pueden definirse y modificarse en cualquier momento durante la ejecución de un modelo. Las propiedades se utilizan normalmente durante la construcción del modelo y la experimentación, mientras que los estados se utilizan normalmente durante la ejecución del modelo para controlar el flujo y/o realizar un seguimiento e informar de las estadísticas. Los eventos son un poco más abstractos en Simio que en otros paquetes. En Simio, los eventos se caracterizan por un tiempo de ejecución (el tiempo de simulación en el que se produce el evento), una referencia a una llamada a procedimiento (que se ejecutará cuando se produzca el evento) y una referencia a un Objeto (que proporciona datos adicionales al procedimiento, cuando sea necesario). El objeto de referencia de un evento puede o no ser una entidad visible para el usuario o un token asociado. Para eventos asociados con el movimiento de Entidades, el Objeto del evento se refiere a un Token asociado con la Entidad y el procedimiento del evento ejecuta un paso del proceso (llamado evento "token llegado a un paso"). La mayoría de los eventos que ocurren durante la ejecución de un modelo serán de este tipo. Ejemplos de otros eventos internos incluyen eventos de fin de ejecución, eventos de estados que cruzan un umbral, eventos de colisión de entidades, etc. Simio también admite eventos definidos por el usuario que pueden dispararse, esperarse y utilizarse para desencadenar procesos.
Durante la ejecución del modelo, una vez que se produce el CUP y Simio entra en el EMP, todos los eventos programados para el tiempo de simulación actual se eliminan del montón de eventos futuros (FEH) y se colocan en la lista de eventos actuales (CEL). La estructura de datos heap se utiliza para los eventos futuros debido a su eficiencia computacional. Simio ejecuta todos los eventos de la CEL (secuencialmente) antes de avanzar el tiempo de simulación hasta el siguiente evento. Los eventos en el CEL se priorizan por Tipo de evento (normal, temprano y tardío). Los procedimientos de eventos pueden crear otros eventos (eventos futuros, así como eventos programados para el tiempo de simulación actual), actualizar el estado del sistema, activar el registro de estadísticas y finalizar la ejecución del modelo. Las colas de asignación son listas de entidades en espera de recursos. Cuando un recurso está disponible, Simio pasa por un proceso de reasignación estándar por el que la "primera" Entidad en la Cola de Asignación (determinada por la regla de clasificación de colas) se colocará al frente de la CEL y la Entidad que liberó el recurso se procesará por pasos hasta que alcance un retraso (ya sea un retraso de tiempo, un retraso de condición o un almacenamiento especificado por el usuario). En este proceso, la última Entidad que libera es procesada hasta que alcanza un retardo y la última Entidad a la que se le asignó capacidad de recurso es la primera en comenzar a procesar (en el mismo tiempo de simulación). Simio implementa el estado latente utilizando elementos de Almacenamiento o Estación. Un elemento de Almacenamiento implementa una cola lógica donde los Objetos pueden ser "colocados" por el usuario para su posterior eliminación. Los elementos de almacenamiento no tienen ubicación física y un objeto determinado puede residir simultáneamente en varios almacenamientos. Por otro lado, un elemento Estación define una ubicación física de capacidad limitada en la que pueden almacenarse objetos de entidad para su posterior retirada y procesamiento.
6 Por qué es importante
En las secciones 6.1 a 6.5 describimos situaciones que revelan algunas diferencias prácticas en las particularidades de implementación entre Arena (que utiliza el lenguaje y el procesador SIMAN), ProModel, GPSS/H, AutoMod, SLX, ExtendSim y Simio. Ninguno de los enfoques alternativos mencionados es intrínsecamente "correcto" o "incorrecto". El modelador simplemente debe ser consciente de la alternativa vigente en el software de simulación utilizado y trabajar con ella para obtener el resultado deseado. De lo contrario, es posible modelar mal una situación y quizás no darse cuenta de ello. En la sección 6.6, comentamos la necesidad de conocer el funcionamiento interno del software para hacer un uso eficaz de las herramientas de comprobación de modelos. Por último, en la sección 6.7, señalamos que el conocimiento de los componentes internos ayuda a comprender la supervisión del rendimiento.
6.1 Intentar recuperar un recurso inmediatamente
Supongamos que un trabajo de un taller flexible libera una máquina (para la que hay otros trabajos esperando) y, como siguiente paso, decide volver a capturar esa máquina. ¿Volverá el trabajo a capturar la máquina inmediatamente, o en su lugar la capturará un trabajo en espera (aunque esté menos cualificado o igual de cualificado)? Lo que interesa aquí es el orden de los acontecimientos que siguen a la liberación de un recurso. Existen al menos tres alternativas: (1) Junto con la liberación del recurso se produce la elección inmediata del siguiente usuario del recurso, sin que la entidad liberadora haya realizado aún su siguiente paso; (2) La elección del siguiente usuario del recurso se aplaza hasta que la entidad liberadora se haya convertido potencialmente en un contendiente; y (3) Sin prestar atención a otros contendientes, la entidad liberadora recaptura el recurso ocioso inmediatamente. Arena, ExtendSim y Simio (el comportamiento por defecto) implementan (1). ProModel implementa (2). GPSS/H y AutoMod implementan (3) por defecto. En SLX, utilizando una Variable de Control como estado del recurso, el resultado es también (3). (En algunas de las herramientas, los modeladores pueden implementar construcciones de recursos de nivel superior o utilizar instrucciones adicionales para que los modelos se comporten según la elección del modelador a este respecto).
6.2 El primero de la fila sigue retrasado
Supongamos que dos entidades con condición de demora están esperando en una lista de demora porque no hay unidades de un determinado recurso ociosas. Supongamos que la primera entidad necesita dos unidades del recurso, mientras que la segunda sólo necesita una. Supongamos ahora que una unidad del recurso queda libre. Las necesidades de la primera entidad de la lista aún no pueden satisfacerse, pero las de la segunda sí. ¿Qué ocurrirá? Hay al menos tres alternativas posibles: (1) Ninguna entidad reclama la unidad de recurso ociosa; (2) La primera entidad reclama la unidad de recurso ociosa y espera una segunda unidad; y (3) La segunda entidad reclama la unidad de recurso ociosa y pasa al estado listo. Al igual que en la sección 6.1, cada una de estas alternativas entra en juego en las herramientas aquí consideradas. Arena (SEIZE) y ProModel (GET o USE) implementan (1) y (2) respectivamente, por defecto. AutoMod (GET o USE), GPSS/H (ENTER o TEST) y SLX (WAIT UNTIL en una Variable de Control) implementan (3) por defecto. ExtendSim también implementa (3) por defecto. Pero ExtendSim da al modelador la opción de implementar localmente (1) para los recursos especificados por el modelador. Para ello, el modelador activa la opción "Asignar recursos únicamente al elemento mejor clasificado" para cada uno de los recursos. Simio permite al modelador seleccionar la opción (1) o (2) utilizando la propiedad Número de objetos y la opción "repetición de apropiaciones de recursos" con el paso Apropiaciones.
6.3 Ceder el control temporalmente
Supongamos que la entidad activa quiere ceder el control a una o más entidades en Estado Preparado, pero luego necesita volver a ser la entidad activa antes de que el reloj de la simulación haya avanzado. Este escenario podría darse, por ejemplo, si la entidad activa ha abierto un interruptor que permite a un conjunto de otras entidades moverse más allá de un punto en el modelo, y luego necesita volver a cerrar el interruptor después de que el movimiento hacia adelante de las otras entidades se haya completado. A modo de ejemplo, consideremos un caso en el que un grupo de cajas de helado de sabores idénticos debe transferirse desde un punto de acumulación a un transportador que conduce a una operación de envasado de un sabor por caja.
En Arena, el efecto puede lograrse aproximadamente con un RETRASO que pone a la entidad activa en un estado de tiempo retardado durante un tiempo simulado arbitrariamente corto pero distinto de cero. En ProModel, se puede utilizar "WAIT 0" para volver a poner la entidad activa en el FEC. La entidad será devuelta más tarde (tiempo de reloj de pared, pero en el mismo tiempo simulado) por el CUP al estado activo. En GPSS/H, la Xact activa (Transacción) puede ejecutar un Bloque YIELD para migrar inmediatamente del estado activo al estado listo (posicionado el último en su clase de prioridad) y forzar un reinicio de la exploración CEC. Los Xacts CEC de rango superior tienen entonces la oportunidad de activarse antes de que el Xact cedente vuelva a activarse en el mismo tiempo simulado. SLX (YIELD), AutoMod (Wait For 0) y Simio (Delay step with Math.Epsilon) proporcionan soluciones en las que el Puck (SLX), Load (AutoMod) o Token (Simio) activo se desplaza a la parte posterior de su clase de prioridad en la CEC, donde espera a convertirse de nuevo en la entidad activa antes de que se haya adelantado el reloj. En ExtendSim, "ceder y luego reanudar eventualmente" forma parte de la arquitectura. Se envía un mensaje a través del conector de Bloque apropiado cuando un Elemento entra o sale de un Bloque. Este mensaje se propaga a otros Bloques conectados, quizás cambiando el estado del sistema o moviendo Elementos de un Bloque a otro como resultado. Cuando el bloque de origen recibe la respuesta, continúa procesando el elemento original.
6.4 Condiciones que afectan al reloj
Cada lenguaje proporciona una capacidad de retardo de tiempo para la espera FEL. Esto funciona bien cuando una entidad necesita esperar hasta que se alcance un valor de reloj conocido. Pero, ¿qué pasa si una entidad necesita esperar una condición compuesta que involucre al reloj, como "esperar hasta que un búfer de entrada especificado esté vacío o sean exactamente las 5:00 PM"? Un enfoque típico para esto es clonar una entidad ficticia ("sombra") para hacer la espera basada en el tiempo. La gestión de estas entidades ficticias puede resultar engorrosa, especialmente en el caso de reglas muy complejas. ProModel no utiliza la espera por sondeo, por lo que una entidad ficticia sería el mejor enfoque disponible. (De lo contrario, la condición no se comprobaría hasta que el otro componente de la condición compuesta tuviera un cambio de valor). ExtendSim tampoco utiliza la espera por sondeo, por lo que se aplica una situación similar para ExtendSim, y se puede utilizar cualquier Bloque que pueda programar eventos. Con Simio, los objetos entidad pueden tener varios tokens asociados, cada uno de los cuales espera un componente diferente de la condición compuesta. Esto es similar en concepto al uso de una entidad ficticia, pero no requiere una entidad adicional.
Cuando existe un mecanismo de espera por sondeo, si una única entidad trata de esperar una condición compuesta en la que interviene el reloj, puede surgir un problema interesante. Esto se debe a que el siguiente tiempo de sondeo puede no coincidir con el tiempo de reloj objetivo. Arena y AutoMod detectan la verdad de las condiciones compuestas a través de sus mecanismos de sondeo endof-EMP. GPSS/H también detecta la verdad a través de su versión de espera por sondeo (refusalmode TEST). Pero en ausencia de algo que espere en el FEL hasta exactamente las 5:00 PM (es decir, el enfoque recomendado anteriormente para ProModel, ExtendSim y Simio), las tres herramientas están sujetas a la posibilidad de que el primer EMP que encuentre la condición verdadera ocurra cuando el reloj tenga un valor mayor que las 5:00 PM. Esto puede ser problemático si la exactitud de las 5:00 PM es importante.
SLX reconoce el reloj como un objetivo wait-until relacionado. Un WAIT UNTIL que utilice un valor de reloj futuro de forma que contribuya a la falsedad de la condición hará que el Puck se programe en el FEL para forzar un EMP a la hora precisa referenciada. Esto resuelve el problema de la hora mayor que la deseada. Tenga en cuenta que este Puck también puede estar esperando en una o más listas de espera.
6.5 Espera en modo mixto
Supongamos que muchas entidades están esperando para capturar un recurso en particular, mientras que una entidad controladora creada por el usuario está esperando la condición compuesta "el estado del turno es 'fuera de turno' y el número de espera es inferior a seis y el recurso no está actualmente en uso" para tomar alguna acción (como apagar el recurso, en lenguajes que permiten a las entidades definidas por el usuario apagar recursos; o mostrar un mensaje de estado). ¿Cómo podemos garantizar que la entidad controladora podrá "adelantarse" a las entidades en espera en el momento simulado adecuado (antes de que se recupere el recurso ocioso)?
Una forma de manejar esto sería a través de las prioridades de entidad en los lenguajes que ofrecen esta característica. Sin embargo, como se describe a continuación, esto podría no funcionar incluso si el controlador tiene una prioridad relativamente alta. La cuestión clave es el método utilizado para implementar la espera. Si es "relacionada" para las entidades que esperan capturar el recurso y "sondeada" para la entidad controladora que espera la condición compuesta (esto es lo que queremos decir con el término "espera de modo mixto"), las cosas pueden complicarse. Cada vez que el recurso se libera, se seleccionará una nueva entidad de una lista de retardo inmediatamente en Arena y a través de la CEL en AutoMod, en ambos casos precediendo a la comprobación de fin de EPM para condiciones de espera sondeadas (y por tanto ignorando la prioridad de entidad del controlador). Hay maneras de evitar esto si se desea, como el uso de un tipo diferente de operación para forzar una espera de sondeo para las entidades que deseen utilizar el recurso.
En GPSS/H, utilizando un controlador Xact de alta prioridad en un Bloque de PRUEBA en modo de rechazo, el controlador espera en la parte delantera de la CCA. La Facilidad RELEASE desencadena un reinicio del escaneo y el controlador hace su trabajo. En ProModel no hay espera por sondeo pero puede haber espera relacionada en condiciones compuestas que impliquen Variables. Las variables tendrían que ser definidas y manipuladas para cada elemento de la condición booleana y, para asegurar la igualdad de competencia, las entidades que esperan para capturar el recurso también podrían tener que utilizar WAIT UNTIL en lugar de GET o USE. Otra posibilidad con ProModel sería hacer que la entidad que libera el recurso realice algunas comprobaciones de estado inmediatamente (convirtiéndose en un sustituto del controlador). Esto es posible gracias al método de selección diferida utilizado por ProModel (véase el apartado 6.2).
En la espera relacionada de SLX, un Puck que espera una condición compuesta será registrado en las listas de retraso de aquellas (y sólo aquellas) Variables de Control que están contribuyendo a la falsedad de la condición. La arquitectura SLX (en la que sólo las Variables de Control globales o locales y el reloj pueden ser referenciados en cualquier tipo de espera condicional al nivel más bajo) asegura que ya habrá Variables subyacentes a los cambios de estado que están siendo monitorizados. El modelador las define como Variables de Control.
Al igual que con ProModel y SLX, ExtendSim utilizaría la espera relacionada para detectar y responder inmediatamente a un cambio en la condición compuesta. Debido a que el cambio de estado del Recurso se emite inmediatamente como un mensaje antes de que el Recurso sea reasignado, este mensaje puede utilizarse para controlar la secuencia y la lógica de la selección de Elementos. Un Recurso no se asigna a menos que haya tanto espacio aguas abajo para un Elemento como disponibilidad de Recursos, por lo que el bloqueo de la ruta de salida de una Cola impedirá la asignación de Recursos.
En Simio, los Objetos Recurso pueden tener su propia lógica implementada mediante Procesos Adicionales, por lo que no es necesario utilizar "entidades controladoras" para implementar el mecanismo de control. En este caso, los procesos adicionales "Fuera de turno" y "Liberado" pueden utilizarse para comprobar la compleja condición que implica el estado de turno, el tamaño de la cola y el estado del Recurso. Tenga en cuenta que esto es equivalente a la espera relacionada en el sentido de que la condición sólo se comprobará cuando el recurso salga de turno y/o cuando se libere una unidad de capacidad.
6.6 Verificación interactiva del modelo
Ahora comentaremos brevemente por qué un conocimiento detallado de "cómo funciona el software de simulación" apoya la comprobación interactiva del comportamiento del modelo de simulación. En general, los modelos de simulación pueden ejecutarse de forma interactiva o por lotes. Las ejecuciones interactivas son útiles cuando se comprueba (verifica) la lógica del modelo durante su construcción y cuando se solucionan los problemas de un modelo si se producen errores de ejecución. El modo por lotes se utiliza para realizar ejecuciones de producción.
Las ejecuciones interactivas ponen una lupa sobre una simulación mientras se ejecuta. El modelador puede seguir la entidad activa paso a paso y visualizar las listas de eventos actuales y futuros y las listas de retardos y gestionadas por el usuario, así como otros aspectos del modelo. Estas actividades aportan información valiosa sobre el comportamiento del modelo para el modelador que conoce los conceptos subyacentes. Sin este conocimiento, el modelador podría no aprovechar al máximo las herramientas interactivas del software o, peor aún, ni siquiera utilizarlas.
6.7 Problemas de rendimiento
Los experimentos de simulación pueden consumir mucho tiempo del ordenador. En igualdad de condiciones (incluida la habilidad del constructor del modelo), los requisitos de tiempo de ordenador dependen del diseño y la implementación del software utilizado para construir modelos. El rendimiento es una cuestión lo suficientemente importante como para motivar a algunos programas de simulación (por ejemplo, ExtendSim, SLX y Simio) a suministrar perfiles de rendimiento que, por ejemplo, pueden producir histogramas que muestren dónde se gasta el tiempo de la CPU durante la ejecución del modelo.
Agradecimientos
Gran parte de la información contenida en este documento ha sido facilitada por el personal de los proveedores. Los autores agradecen el apoyo de Deb Sadowski; Vivek Bapat; Charles Harrell (ProModel); Kenneth Farnsworth y Tyler Phillips (AutoMod); Robert C. Crain y James O. Henriksen (GPSS/H y SLX); David Krahl (ExtendSim); y David T. Sturrock y C. Dennis Pegden (ambos originalmente con Arena/SIMAN, y ahora con Simio).