Generadores multiples 21/08/2012 GPSS nos permite tener múltiples generadores de transacciones a la vez. Debemos tener especial cuidado con esto, evitando que una transacción ejecute un bloque GENERATE (además del que la creó) ya que la simulación se detendrá inmediatamente. Si bien los generadores pueden provocar la creación de transacciones en el mismo tiempo de reloj, esto no significa que su movimiento será paralelo: siempre existe solo una transacción activa, y las restantes transacciones que deben moverse en este momento de reloj estarán esperando en la CEC. Siempre. El uso de múltiples generadores puede servirnos para, por ejemplo, tener distintos tiempos de nacimiento e inicializaciones de transacciones pero la misma lista de bloques, con lo cual podemos evitarnos repetir los mismos bloques. También podemos disponer de una transacción Reloj, que nos ayudará a determinar cuando termina la simulación. Siguiendo con el bloque GENERATE, vale la pena recordar aquí que nos ofrece un parámetro con el límite de creación. Esto signifca que, si se utiliza, solo se crearán tantas transacciones como indique este parámetro, y no más. Esto es muy diferente al valor del Termination Count seteado en el bloque START (y a los posibles decrementos en los bloques TERMINATE). No es lo mismo indicar un límite de creación que indicar un límite de terminación. Más bloques del GPSS Creación y destrucción de transacciones: Las instrucciones GENERATE y TERMINATE son complementarias entre sí y sirven para crear y destruir las transacciones. El par SPLIT/ASSEMBLE también es un par complementario. SPLIT forma un conjunto de ensamble a partir de la transacción original/master y un número dado de gemelos idénticos/twins. ASSEMBLE lo que hace es unir las transacciones del mismo set. Modificación del estado de las entidades permanentes: SEIZE/RELEASE y PREEMPT/RETURN son pares complementarios para usar con las facilidades. Las facilidades alcanzadas pueden ser apropiadas/preempteadas sobre una base de prioridad. Hay un testeo para ver si se da permiso a la entrada de las transacciones. ENTER/LEAVE es el par complementario de los storages. El bloque ENTER puede impedir el paso de la transacción si el storage está lleno. 1
El par QUEUE/DEPART trabaja con las colas y el bloque queue nunca impide el ingreso de una transacción. Recordar que el bloque cola es una entidad estadística, no detiene realmente a las transacciones. JOIN/REMOVE: Las transacciones pueden asociarse mediante grupos (groups). Los bloques JOIN/REMOVE son pares complementarios usados para modificar a los miembros de un grupo. Un bloque JOIN suma la transacción activa a un grupo de transacciones o suma un número a un grupo numérico. En el caso más simple la transacción que pasa por el bloque JOIN se vuelve miembro del grupo que se referencia en el primer campo del bloque:: JOIN Desk: la transacción pasa a formar parte del grupo de transacciones llamado Desk. Si el bloque contiene un segundo operando el bloque actúa en modo numérico y el valor numérico se incluye en el grupo numérico especificado por el primer operando del bloque. Manejo explícito de atributos Atributos de las transacciones: Bloques: MARK, PRIORITY, ASSIGN. El tiempo de creación de una transacción es almacenado en el atributo mark. Cada vez que una transacción entra al bloque MARK el tiempo de reloj actual reemplaza el mark time que tiene la transacción. La prioridad de la transacción puede ser seteada al nacer con el atributo priority y puede ser modificada durante la simulación por medio de un bloque PRIORITY. Podemos consultar la prioridad de una transacción mediante el sna PR. El bloque PRIORITY nos ofrece la opción BUFFER (parámetro B), con la cual la transacción cuya prioridad está siendo modificada volverá inmediatamente a la CEC. Esto hace que vuelva a competir con otras transacciones de la CEC para convertirse en la siguiente transacción activa. Este mismo efecto lo logramos con el bloque BUFFER. O sea que BUFFER = PRIORITY PR,BU Cuando necesitamos definir nuestros propios parámetros para nuestras transacciones, utilizamos el bloque ASSIGN. Este bloque sirve tanto para definir parámetros, como para actualizarlos. Los parámetros pueden ser nombrados, o simplemente numéricos. Veamos algunos ejemplos: ASSIGN 1,10 -> asigna en el parámetro 1 de la transacciones activa el valor 10 ASSIGN camiseta, 10 -> asigna en el parámetro camiseta de la transacciones activa el valor 10 ASSIGN camiseta, FN$numero_camiseta -> asigna en el parámetro camiseta de la transacciones activa el valor retornado por la función numero_camiseta 2
ASSIGN camiseta,p$1 -> asigna en el parámetro camiseta de la transacciones activa el valor del parámetro 1 de la transacción activa. Atributos del sistema: Bloque SAVEVALUE. La entidad savevalue está asociada con una variable que puede tomar cualquier valor. El valor de la entidad puede ser asignado o modificado por un bloque SAVEVALUE. El bloque puede tener dos operandos el primero es el número de la entidad y el segundo el valor a adicionar/sustraer o almacenar en el savevalue. El ejemplo que da el HELP del GPSS es: SAVEVALUE Account, 99. En este caso la entidad savevalue llamada Account toma el valor de 99 a causa del bloque SAVEVALUE. Es importante no confundir las entidades o atributos del GPSS con sus bloques asociados porque a veces (como en este último caso) el bloque lleva el mismo nombre de la entidad, para distinguir esto uso para el bloque las letras en mayúsculas y para la entidad en minúsculas. SNA's GPSS nos ofrece un conjunto de atributos numéricos de cada entidad, que se acceden mediante SNA. Algunos SNAs requieren indicar explícitamente la entidad a la cual hacemos referencia, mientras que otros no, pues es evidente. Veamos la siguiente expresión: SEIZE Fac Fac no es un SNA, es una referencia directa a la facilidad. No necesitamos utilizar un SNA, porque el bloque SEIZE requiere precisamente una facilidad, y no espera otra cosa. ASSIGN 1,(AC1 + FN$func + X$valor + V$unaVariable P$1) Aquí tenemos varios SNAs en una única expresion. Para empezar, observemos que el SNA AC1 (tiempo de reloj actual) no requiere indicar la entidad, pues se sabe que se refiere al único relojr existente en una simulación. En los otros casos, se utiliza una función, un savevalue, una variable y un parámetro de la transacción activa (observar que no hay que hacer referencia a la transacción activa, pues también es única): en todos los casos indicamos explícitamente cual es la entidad sobre la cual queremos realizar la consulta. Un último caso: ASSIGN 1,unaVariable 3
Esto no provoca la evaluación de la variable! Lo único que hace es retornar el identificador interno de esta entidad (un valor entero mayor o igual a 10000), con lo cual el parámetro 1 de nuestra transacción tendrá ahora el ID de la VARIABLE unavariable. Podría estar bien, podría estar mal, depende del caso. Pero siempre tenemos que tener bien claro que estamos haciendo. Retardo de las transacciones: Retardos planificados: el bloque ADVANCE se utiliza para especificar un retardo de un determinado tiempo para una transacción. Puede ser utilizado para simular el tiempo de servicio o el tiempo de proceso y naturalmente, es un bloque que nunca impide el paso de una transacción. Una vez que la transacción entra al ADVANCE se recalcula el tiempo de reloj para saber el BDT de la transacción y la transacción es ubicada en la FEC. Juguemos un poco con un modelo también de cola simple como el anterior: un peluquero puede atender un solo cliente por vez, los clientes entran al negocio y esperan si el peluquero está ocupado, los clientes son atendidos en orden de llegada. Modelizar el sistema de modo tal de conocer el nivel de servicio que se tiene y la utilización del peluquero. Entidades de GPSS STORAGES Una entidad de tipo STORAGE tiene asociada un número de unidades (capacidad del storage) que pueden ser ocupadas o liberadas por las transacciones. La capacidad del storage es fija, y se determina mediante el uso del bloque STORAGE: nombrestorage STORAGE capacidad Por ejemplo: bandejas STORAGE 20 almacen STORAGE 150 Las transacciones poseen 4 bloques para interactuar con los storages: ENTER A,B: ocupa B lugares en el storage A. Si B no se define, tomará el valor 1 por defecto LEAVE A,B: libera B lugares del storage A. SAVAIL: coloca al storage en estado disponibles SUNAVAIL: coloca al storage en estado no diponible (ninguna transacción podrá hacer un ENTER). Al igual que sucede con las facilidades, cuando un storage esta completo y una transacción intenta ejecutar un bloque ENTER, se le privará el acceso al storage y por lo tanto quedará en espera hasta que alguna otra transacción libere espacio suficiente. 4
A diferencia de lo que sucede con las facilidades, una transacción puede ocupar lugares de los storages pero no está obligada a liberarlo. Recordemos que si una transacción ocupa una facilidad, y luego intenta ejecutar un bloque TERMINATE, causará un STOP ya que una transacción que posee una facilidad no puede terminar. por qué es diferente con los STORAGES? Porque las transacciones no poseen los storages, no quedan dentro del storage, sino que simplemente ocupan lugares del mismo. Recordemos también que los storages nos entregan estadísticas distintas de las facilidades. Por ejemplo, si un storage tiene 10 posiciones, las estadísticas que recibiremos serán del storage en general y no sobre el uso de cada una de sus posiciones. Con esto, observamos claramente que no es lo mismo usar un STORAGE de 10 posiciones o 10 facilidades. Mientras que las facilidades se evalúan individualmente, las posiciones de los storages se evalúan como un todo. 5
Arribo de un cliente espera Peluque ro ocupado? Servicio No Atiende al próximo cliente (orden) partida del un cliente Si Cliente esperand o? No Peluquero desocupado Aquí es posible entender más fácilmente lo que son las entidades permanentes y las temporarias de las que hablamos: 1. La peluquería y el peluquero son entidades permanentes, están presentes durante todo el tiempo que dura la simulación. El peluquero es una Facility, una entidad que puede servir tan sólo a un cliente por vez. La peluquería es un lugar de espera, provee la queue (cola) donde esperan los clientes. 2. Los clientes son las entidades transitorias, estas entidades pueden dejar el modelo durante la simulación. Los clientes arriban al azar y se van cuando terminan de ser atendidos. El único compromiso es que aparecen sólo cuando la peluquería está abierta, los clientes son las transacciones. Las transacciones se mueven todo lo que les es posible/ as far as, un cliente entra a la peluquería y es atendido de manera inmediata siempre; si el peluquero está ocupado, la facilidad permanece ocupada todo el tiempo que dura el servicio. Para hacer correr el modelo debemos darle distribuciones de los tiempos de arribo y de los tiempos de servicio. Pasemos a otro ejemplo: 4 transacciones entran al sistema a intervalos de cada 3 unidades de tiempo comenzando en la unidad 1, tratan de alcanzar la 6
facilidad MACH la ocupan durante 4 unidades de tiempo y tratan de entrar al storage Buffe (de capacidad 2) del que salen después de 9 unidades de tiempo, dejan el storage y terminan. * * Simple queue model Simulation * * * ********************************************************************** Buffe storage 2 GENERATE 3,,1,4 ;Create next customer. QUEUE wait ;Begin queue time. SEIZE mach ;Own or wait for barber. DEPART wait ;End queue time. ADVANCE 4 ;Service time. ENTER Buffe ;arrives to storage RELEASE mach ;End service time. ADVANCE 9 ;Service time in storage entity LEAVE buffe ;Give up storage TERMINATE 1 ;Customer leaves. GPSS World Simulation Report - Modelo clse4.5.1 Thursday, September 22, 2005 08:09:53 START TIME END TIME BLOCKS FACILITIES STORAGES 0.000 27.000 10 1 1 NAME VALUE BUFFE 10000.000 MACH 10002.000 WAIT 10001.000 LABEL LOC BLOCK TYPE ENTRY COUNT CURRENT COUNT RETRY 1 GENERATE 4 0 0 2 QUEUE 4 0 0 3 SEIZE 4 0 0 4 DEPART 4 0 0 5 ADVANCE 4 0 0 6 ENTER 4 0 0 7 RELEASE 4 0 0 8 ADVANCE 4 0 0 9 LEAVE 4 0 0 10 TERMINATE 4 0 0 FACILITY ENTRIES UTIL. AVE. TIME AVAIL. OWNER PEND INTER RETRY DELAY MACH 4 0.630 4.250 1 0 0 0 0 0 QUEUE MAX CONT. ENTRY ENTRY(0) AVE.CONT. AVE.TIME AVE.(-0) RETRY WAIT 1 0 4 1 0.259 1.750 2.333 0 STORAGE CAP. REM. MIN. MAX. ENTRIES AVL. AVE.C. UTIL. RETRY DELAY BUFFE 2 2 0 2 4 1 1.333 0.667 0 0 7
Ejemplo, otro, análisis de tiempos: Cuando el programa comienza lo primero es generar la XAC como hay un offset de 1 la transacción es enviada a la FUT con BDT=1. Cuando comienza la simulación, C1 se pone en 1 que es el valor más pequeño de FUT, XAC1 se mueve de FUT a CUR y el GPSS comienza a scanear la CUR, encuentra XAC1 y la mueve del GENERATE al QUEUE, cuando XAC1 deja el bloque GENERATE se calcula el tiempo de nacimiento de la próxima transacción XAC2= 4, XAC2 es puesta en FUT con BDT=4. XAC1 se mueve, alcanza el bloque SEIZE y el bloque ADVANCE calculando su BDT en 5. Ahora 5 es mayor que C1 y XAC1 es puesta en FUT con BDT= 5. La CUR está vacía y el reloj se actualiza a 4, el valor más pequeño de FUT y XAC2 se mueve de FUT a CUR, el GPSS encuentra a XAC2 y la mueve del bloque GENERATE al QUEUE, se calcula el tiempo de nacimiento de la próxima que es XAC3= 7 y se la pone en la FUT. XAC1 tiene un BDT de 5 por lo cual XAC2 espera por un cambio de estado de MACH, quedando temporariamente inactivada. El scan termina para el tiempo 4 y el reloj se actualiza a C1= 5 porque este es el tiempo menor que encontramos en la FUT y XAC1 se mueve nuevamente a la CUR, el scan encuentra a XAC2 inactiva, examina XAC1 y la mueve del ADVANCE al ENTER y luego al RELEASE lo cual reactiva XAC2, XAC1 es puesta en la FUT con BDT=5+9 = 14, recomienza el scan encuentra XAC2 activa y la mueve al SEIZE, DEPART y ADVANCE blocks, el tiempo de ADVANCE se adiciona nº1 nº2 nº3 nº4 1 4 7 10 13 16 19 22 25 27 t Queve Facility Mach Buffer 14 18 23 27 nº1 nº2 nº3 nº4 8