Sistema simple de simulación Go

Introduccion

La simulación es un método para realizar experimentos, el sistema real estudiado es reemplazado por un modelo. En dicho modelo, puede perder situaciones individuales y muchas de ellas. Las estadísticas recopiladas pueden ayudar a sacar conclusiones acerca de los procesos en el sistema, así como también esbozar las rutas de optimización.

El modelado de simulación a menudo se considera como un tipo de pruebas experimentales, pero al mismo tiempo es menos costoso, le permite cambiar rápidamente los parámetros y observar el sistema simulado en dinámica.

Ya alrededor de medio siglo en el modelado de simulación, se han utilizado modelos de computadora. Se han creado muchos programas y marcos diferentes para su desarrollo, entre los cuales, en mi opinión, los más desarrollados son las herramientas para modelar sistemas de colas (QS). Uno de los programas más conocidos y simples para la simulación de QS - GPSS World (Sistema de simulación de propósito general - un sistema de modelado de propósito general) se puede encontrar con más detalle en los enlaces [1] , [2] .

El concepto de este programa fue la base del marco de simulación en Go.

Simulación en GPSS

Un modelo en GPSS es una secuencia de bloques (comandos) que describe los objetos simulados entre los que se mueven las transacciones. Cuando una transacción ingresa al bloque, se generan eventos que conducen a un cambio en el estado del objeto modelado o a un cambio en el estado / parámetros de la transacción.

Los bloques principales del orden de diez: GENERAR, TERMINAR, ASIGNAR, ASEGURAR, LIBERAR, COLA, AVANZAR, SALIR, INICIAR. Hay alrededor de tres docenas de bloques en total. Los bloques tienen parámetros, que pueden ser números, nombres de funciones, etiquetas en el programa de simulación, nombres de variables. Se pueden encontrar más detalles sobre los bloques, por ejemplo, aquí .

Los objetos en GPSS tienen un conjunto de atributos numéricos estándar (NAV) y atributos lógicos estándar (ALS). Por ejemplo, para una cola, uno de los NAV es la longitud actual, y un ejemplo de ALS para algunos equipos será VERDADERO u ocupado (FALSO).
En algunas versiones de GPSS hay una visualización del proceso de modelado, pero a menudo está ausente. En función de los resultados de la simulación, se genera un informe en GPSS, que indica el NAV y ALS para todos los objetos.

Ir a la implementación

Implementación en Go es el desarrollo de un conjunto de objetos similares en función a los bloques GPSS. El primero fue Pipeline creado: el objeto dentro del cual se realiza la simulación.

Basado en un map contiene una lista de componentes para describir el sistema simulado. Dado que, durante la simulación, las transacciones deben pasar por una secuencia de bloques en un orden estricto, en el método de agregar componentes de Append , se implementó el procedimiento de agregar con indicación simultánea de los destinos de las transacciones. El nombre del componente se utiliza como clave de map , por lo que cada componente debe tener un nombre único.

Después de agregar todos los componentes, puede iniciar la simulación utilizando el método de Start . En su interior, se implementa un bypass cíclico de todos los componentes durante un tiempo de simulación determinado. Al final de la simulación, puede imprimir un informe que contenga NAV y ALS.

El segundo elemento importante son los componentes reales para describir la simulación. Se implementaron los siguientes: Generador - genera transacciones, Avanzado - crea demoras en la ruta de la transacción, Cola - colas de transacciones, Instalación - un dispositivo que es capturado exclusivamente por la transacción por un tiempo, Agujero - un "agujero" en el que las transacciones fallan al final de la ruta. Por supuesto, este conjunto no es suficiente para crear modelos de simulación complejos, sino suficiente para resolver la solución y compararla con los resultados del GPSS. Todos los componentes implementan la interfaz IBaseObj, que cubre la funcionalidad mínima requerida.

Cada componente tiene una cola de transacciones. Directamente como una cola, se usa solo en la cola, para otros componentes es solo un repositorio. La cola se implementa en función del map . En el proceso de modelado, los componentes pasan a su vez y verifican la preparación (cumplimiento de una determinada condición) de la transacción para su transmisión al siguiente componente. La transferencia se realiza a través del método AppendTransact del siguiente componente. Si la transferencia es exitosa, la transacción se elimina de la cola, respectivamente, el siguiente componente la toma a su vez. Dado que se definen varios destinatarios para cada componente, si no fue posible enviar una transacción a un destinatario, intentamos enviarla a otro.

Para generar variables aleatorias al determinar el tiempo de aparición de la transacción y crear retrasos, se utilizan las funciones PRNG en Go.

Dado que al modelar, al mismo tiempo, puede haber muchas transacciones que se mueven entre diferentes componentes, surgió la idea de usar gorutinas dentro de los componentes. La canalización, que pasa a través de los componentes, inicia el controlador HandleTransacts para cada uno de ellos, dentro del cual se crea la rutina. Una vez que se han completado todas las rutinas, el contador de tiempo del modelo se incrementa y se llama HandleTransacts .

El último objeto clave es la transacción en sí. Tiene un identificador, hora de nacimiento y muerte, el propietario (en qué componente se encuentra ahora), una serie de parámetros para calcular el NAV y el NAV.

En la fig. 1 es un diagrama estructural de la interacción de los principales objetos del marco durante el modelado.


Fig. 1. Diagrama estructural generalizado de la interacción de los objetos principales en la simulación.

Ejemplo de simulación

Suponga que necesita simular el trabajo de un peluquero. Este es un famoso ejemplo de GPSS. Los visitantes van al azar, con una frecuencia de 18 ± 6 minutos, su número no se conoce de antemano. Tenemos un peluquero, él pasa 16 ± 4 minutos en un corte de pelo. Entonces, ¿a cuántas personas cortará por un día de trabajo? ¿Cuántas personas estarán en la fila? ¿Cuál es el tiempo promedio que toma un corte de pelo y cuánto tiempo esperan las personas en la fila? Muchas preguntas y una simulación simple. El diagrama de bloques en la Fig. 2)


Fig. 2. El esquema estructural de modelar una peluquería

El código para construir el modelo será el siguiente.

 barbershop := NewPipeline("Barbershop", true) //   clients := NewGenerator("Clients", 18, 6, 0, 0, nil) //   chairs := NewQueue("Chairs") //  master := NewFacility("Master", 16, 4) //  hole := NewHole("Out") //  barbershop.Append(clients, chairs) //       barbershop.Append(chairs, master) //      barbershop.Append(master, hole) //     barbershop.Append(hole) //        barbershop.Start(480) //    <-barbershop.Done //   barbershop.PrintReport() 

Sirvió a 25 clientes, el 26 al momento de la finalización de la simulación todavía estaba en la silla del maestro. La cola no era más de 1 persona, 11 personas no esperaron (pase cero) e inmediatamente se cortaron el pelo. En promedio, las personas pasaron 2.58 minutos en la cola, y de los que estaban esperando (no un pase cero), 4.47 minutos. El 89.17% de su tiempo, un peluquero, intensamente cortado.

Por supuesto, si realiza otra simulación, los resultados cambiarán. Pero durante una serie de simulaciones, el nivel general de la carga del asistente y el número de clientes atendidos serán visibles. Una simulación similar en GPSS produce resultados similares.

Otro ejemplo. Hay una oficina, tiene 10 empleados y un baño. La gente quiere ir al baño cada 90 ± 60 minutos, ir al baño durante 5 ± 3 minutos, ir al baño durante 15 ± 10 minutos, volver a la oficina durante 5 ± 3 minutos. Realizaremos la simulación durante 9 horas (8 horas de trabajo + 1 hora de almuerzo), en la fig. 3 es un diagrama estructural.


Fig. 3. Diagrama estructural del modelo de empleo del inodoro: a la izquierda con un inodoro, a la derecha con dos

A la izquierda hay un modelo con un inodoro, a la derecha con dos. El siguiente es el código del modelo.

 waterclosetsim := NewPipeline("Water Closet Simulation", false) office := NewGenerator("Office", 0, 0, 0, 10, nil) wantToToilet:= NewAdvance("Wanted to use the toilet", 90, 60) pathToWC := NewAdvance("Path to WC", 5, 3) queue := NewQueue("Queue to the WC") pathFromWC := NewAdvance("Path from WC", 5, 3) wc := NewFacility("WC", 15, 10) pathToOffice:= NewAdvance("Path from WC", 5, 3) waterclosetsim.Append(office, wantToToilet) waterclosetsim.Append(wantToToilet, pathToWC) waterclosetsim.Append(pathToWC, queue) waterclosetsim.Append(queue, wc) waterclosetsim.Append(wc, pathFromWC) waterclosetsim.Append(pathFromWC, wantToToilet) waterclosetsim.Start(540) <-waterclosetsim.Done waterclosetsim.PrintReport() 

Había hasta 4 personas en la fila, 8 veces una persona se metió inmediatamente en el inodoro, durante el día laboral el inodoro se usó al 87.04%. Lo más significativo, en mi opinión, es que las personas esperan aproximadamente media hora (31 minutos) en la fila para ir al baño. Quizás esto se deba al hecho de que solo hay un inodoro, y quizás al hecho de que, en promedio, las personas se sientan en él durante 14,69 minutos.

Después de agregar otro baño, vi que la cola se redujo a 3 personas, 29 veces las personas entraron inmediatamente al baño. Pero lo más importante, la expectativa disminuyó casi tres veces.

Conclusión

El marco creado en la rodilla es bastante simple y aún limitado. Planea aumentar su funcionalidad al nivel de GPSS. El valor práctico del marco es la capacidad de ensamblar rápida y fácilmente un modelo de simulación en Go y obtener resultados.

El código está publicado en GitHub .