Cómo funciona el motor de simulación
Entendiendo el Motor de Simulación
ProcessMind usa un motor de simulación de eventos discretos (DES) para modelar tus procesos. Entender cómo funciona te ayuda a configurar simulaciones de forma efectiva e interpretar los resultados con precisión.
¿Qué es la Simulación de Eventos Discretos?
En la simulación de eventos discretos, el estado del sistema solo cambia en eventos específicos: el reloj salta de evento en evento y entre ellos no ocurre nada. Este enfoque es ideal para procesos de negocio porque:
- Las actividades tienen tiempos de inicio y fin claros
- Los recursos se asignan y liberan en momentos concretos
- Los casos llegan y finalizan en puntos definidos
¿Por qué Eventos Discretos?
A diferencia de la simulación continua (usada para física o dinámica de fluidos), los procesos de negocio no requieren modelado segundo a segundo. Una solicitud de crédito no pasa progresivamente de ‘enviada’ a ‘aprobada’, cambia de estado solo en eventos concretos.
Bucle Principal de Eventos
El motor de simulación sigue un ciclo sencillo pero potente:
1. Inicializar: Establecer condiciones iniciales
2. Obtener Siguiente Evento: Seleccionar el evento programado más próximo en la cola de prioridad
3. Avanzar el Tiempo: Mover el reloj de simulación al momento del evento
4. Procesar Evento: Ejecutar el evento (iniciar actividad, completar, etc.)
5. Programar Nuevos Eventos: Según lo ocurrido, añadir nuevos eventos
6. Repetir: Continuar hasta el final o alcanzar el máximo de eventos (2,000,000)
7. Salida: Generar el event log completo
Tipos de Eventos
La simulación genera y procesa varios tipos de eventos:
| Tipo de Evento | Qué ocurre |
|---|---|
| Case Arrival | Un nuevo caso inicia el proceso en un start event |
| Activity Start | Un caso comienza la ejecución de una actividad (asignación de recursos) |
| Activity Complete | Un caso finaliza una actividad (libera recursos) |
| Gateway Evaluation | Un punto de decisión elige qué camino tomar |
| Case Complete | Un caso alcanza un end event |
Generación y Llegada de Casos
Los casos ingresan a la simulación mediante Start Events en tu modelo BPMN. El patrón de llegada está controlado por la distribución de generación de casos.
Patrón de Llegada por Defecto
Por defecto, los casos llegan siguiendo una distribución de Poisson con una tasa de 1 caso por hora. Así se generan llegadas aleatorias y realistas, como en muchos procesos de negocio.
Personalizar Llegadas
Puedes establecer distintos patrones de llegada utilizando las distribuciones descritas en la documentación de Distributions .
Flujo de Casos en el Proceso
Sequence Flows
Cuando un caso finaliza un elemento, sigue inmediatamente el sequence flow de salida. Si solo hay un camino, el caso lo toma automáticamente.
Comportamiento de los Gateways
Los gateways controlan cómo se dividen y se unen los casos:
| Tipo de Gateway | Comportamiento |
|---|---|
| XOR (Exclusive) | Se selecciona un solo camino usando una selección aleatoria ponderada por probabilidad. Las probabilidades se manejan como pesos relativos y se normalizan automáticamente. |
| AND (Parallel) | Todos los caminos de salida se toman al mismo tiempo. El caso se divide en tokens paralelos. |
| OR (Inclusive) | Selección aleatoria de caminos garantizando al menos uno. |
| Event-Based | Selección aleatoria entre los eventos disponibles. |
Configuración de Probabilidades
En los gateways XOR debes asignar probabilidades a cada camino de salida. Son pesos relativos:
- Si defines 70, 20 y 10, se normaliza a 70%, 20%, 10%
- Si pones 7, 2 y 1 es el mismo resultado
- Todas las salidas requieren probabilidad; las no asignadas toman el resto
Ejecución de Actividades
Cuando un caso llega a una tarea (actividad), el motor sigue esta secuencia:
1. Comprobar Disponibilidad de Recursos
¿El recurso necesario tiene capacidad disponible?
2. Encolar si es Necesario
Si los recursos no están disponibles, el caso entra en la cola de espera. ProcessMind utiliza el orden FIFO (First In, First Out) y los casos se procesan según su llegada.
3. Asignar Recursos
Cuando hay disponibilidad, las unidades necesarias de recurso se reservan para este caso.
4. Obtener Tiempo de Proceso
El motor toma un valor de la distribución elegida para el tiempo de proceso. Así se define cuánto durará la actividad.
5. Programar Evento de Finalización
Se agrega un evento de finalización a la cola de eventos en current_time + processing_time.
6. Liberar Recursos
Cuando ocurre el evento de finalización, los recursos se liberan y quedan disponibles para otros casos.
Tiempo Mínimo de Proceso
Para garantizar timestamps únicos y un comportamiento realista, todas las actividades duran mínimo 1 segundo. Incluso con duración cero, las actividades tardan al menos ese tiempo.
Probabilidad de Omitir
Puedes configurar una probabilidad de salto (0-100%) en las actividades. Cuando una actividad se omite:
- El caso avanza al siguiente elemento de inmediato
- No se consumen recursos
- No transcurre tiempo (excepto el mínimo de 1 segundo)
- La actividad aparece en el log con duración mínima
Esto refleja escenarios reales donde ciertos pasos pueden omitirse ocasionalmente.
Gestión del Tiempo
Reloj de Simulación
La simulación mantiene un reloj virtual que avanza de un evento al siguiente. Si el próximo evento es a las 10:35 y la hora actual son las 10:30, el reloj salta a las 10:35.
Unidades de Tiempo
Todos los tiempos se convierten a unidades coherentes de manera interna. Puedes especificar duraciones en:
- Segundos
- Minutos
- Horas
- Días
- Semanas
- Meses
Periodicidad y Franjas Horarias
Los parámetros pueden variar según el momento de la simulación. Por ejemplo:
- Distintas tasas de llegada en días hábiles y fines de semana
- Tiempos de proceso diferentes en turnos de mañana y tarde
- Capacidad de recursos distinta en horas pico
Consulta la documentación de Periodicity para más información.
Gestión de Recursos
Pool de Recursos
Cada recurso tiene una capacidad definida que indica cuántos casos puede atender al mismo tiempo.
Gestión de Colas
Cuando la demanda supera la capacidad, los casos esperan en una cola. ProcessMind usa el orden FIFO (First In, First Out) para procesar los casos en orden de llegada.
Generación del Event Log
Mientras se ejecuta la simulación, cada actividad se registra en el event log de salida:
| Campo | Descripción |
|---|---|
| Case ID | Identificador único para cada caso (generado secuencialmente) |
| Activity | Nombre del elemento BPMN |
| Start Timestamp | Momento en que la actividad inicia |
| Complete Timestamp | Momento en que la actividad finaliza |
| Resource | Qué recurso ejecutó la actividad |
| Attributes | Atributos del caso en ese momento |
Este log cumple con los formatos estándar de event log y puede analizarse con todas las herramientas de ProcessMind.
Límites de Simulación
| Límite | Valor | Propósito |
|---|---|---|
| Max Events | 2,000,000 | Evita simulaciones descontroladas |
| Min Duration | 1 second | Garantiza timestamps únicos |
Comienza Pequeño, Luego Escala
Al configurar una nueva simulación, comienza con un periodo corto (unos días o semanas) para validar tu configuración. Cuando el modelo funcione bien, escala a periodos más largos.