Saltar al contenido principal

​
¿Qué es la simulación de eventos discretos?

La simulación de eventos discretos (DES) modela un sistema como una secuencia de eventos (Events) que suceden en puntos específicos en el tiempo. En un contexto de manufactura, cada evento representa algo concreto: una entidad (Entity) llegando a un proceso (Process), un recurso (Resource) volviéndose disponible, un lote completándose. ProDex ejecuta DES usando el motor SimPy por debajo. No interactúas con SimPy directamente — construyes modelos visualmente en un lienzo, y ProDex maneja la ejecución de la simulación. La idea clave de DES: puedes modelar operaciones complejas, variables e interdependientes con precisión sin necesitar un prototipo físico o ejecutar el sistema real. Cambia la capacidad de un recurso, ajusta una distribución (Distribution) de tiempo de procesamiento, agrega un búfer (Buffer) — y observa los efectos descendentes en segundos.

​
Construyendo un modelo

Los modelos se construyen como un grafo dirigido en el lienzo del Modelador. Los componentes son nodos; las conexiones son aristas que definen el flujo de entidades.

​
Barra superior

La barra superior del modelo (Model) expone los controles que actúan sobre el modelo como un todo:
  • Selector de modelo — abre un menú desplegable con el modelo activo (marca de verificación), + New Model, Rename y un Delete rojo.
  • Selector de calendario (Schedule) — elige contra cuál calendario corre el modelo. El menú desplegable lista Default (no schedule), cada calendario definido (el activo con marca de verificación), + New Schedule y un Delete rojo. Cuando el calendario activo es Default (no schedule) el siguiente campo es la entrada de Duration (un selector de tiempo DDD:HH:MM:SS que establece cuánto dura la simulación); cuando un calendario distinto de Default está activo, esa entrada se reemplaza por un ícono de edición (lápiz) que abre el editor de calendarios.
  • Save (ícono de disco) — guarda una Instantánea (Snapshot) de la configuración actual. Tooltip: “Save current work as snapshot.” El diálogo (titulado Create Snapshot, con un pequeño ícono de cámara, subtítulo “Save the current state of your model to return to it later.”) toma un Snapshot Name (requerido) y una Description opcional, con un botón primario Create Snapshot.
  • Historial de Instantáneas (ícono de reloj) — abre un selector Search snapshots que lista las Instantáneas existentes agrupadas por recencia. Elegir una la carga al lienzo (con un toast “Snapshot loaded successfully”).
  • Undo / Redo — historial completo de edición para la sesión actual.

​
Tipos de componentes

Source (Fuente) Genera entidades y las inyecta en el modelo. Configura:
  • Qué tipo de entidad producir
  • Lógica de llegada — elige una distribución de un menú desplegable de 10 opciones (Fixed, Normal, Exponential, Uniform, Lognormal, Weibull, Triangular, Erlang, Beta, Gamma). Los campos de parámetros de distribución se renderizan como un selector de tiempo DDD:HH:MM:SS, y cada uno tiene un toggle </> que lo cambia al editor de expresiones (Expressions) DSL.
  • Valores iniciales de atributos, establecidos por atributo a través de un menú desplegable Strategy. Existen seis estrategias canónicas — Fixed, DSL Expression, Round Robin, Random Choice, Random (muestrea de una distribución de probabilidad) y Weighted (renderiza una tabla Value/Weight). El menú desplegable se filtra por el tipo del atributo — los atributos Number solo ven Fixed / Random / DSL Expression; los tipos categóricos (Boolean / Text List / Number List) ven Fixed / Round Robin / Random Choice / Weighted; los atributos Text ven Fixed / DSL Expression. Ver Entidades y atributos para la matriz completa tipo-por-estrategia.
  • Event Hooks
Una Fuente también puede ser solo de evento — omite la lógica de llegada por completo y haz que libere entidades solo cuando es disparada por una acción Release Entity desde un Event Hook o una liberación de material del calendario. El validador permite esto a propósito; ver Validación. Process (Proceso) Donde sucede el trabajo. Las entidades entran, pasan tiempo siendo procesadas y salen. Configura:
  • Entity Type — alcanza el resto del panel a un tipo de entidad específico
  • Tiempo de procesamiento como una distribución (mismo menú desplegable de 10 opciones que Source) o expresión DSL
  • Requisitos de recurso — una tabla multi-fila (+ Add Row) especificando qué recursos y cuántos de cada uno
  • Estación (Station) — opcionalmente coloca el proceso dentro de un contenedor de estación por referencia
  • Event Hooks — process started, process completed
Resource (Recurso) Un pool de capacidad del que los Procesos extraen. Los Recursos no son nodos arrastrables del lienzo como lo son las Fuentes y los Procesos — son pools alcanzados a modelo gestionados en el panel lateral y referenciados desde la tabla de requisitos de recurso de un Proceso. Configura:
  • Capacidad (número de unidades disponibles)
  • Disciplina de asignación — FIFO (First In, First Out), LIFO (Last In, First Out) o Priority
  • Tiempos de cambio — duraciones por-(de proceso, a proceso) aplicadas cuando el recurso cambia entre procesos (+ Add Row para cada uno)
  • Event Hooks — más comúnmente usados para reaccionar a tópicos de turno con la acción Set Capacity (ver el patrón de programación de turnos)
Las claves de cambio son procesos, no tipos de entidad. Un recurso que maneja dos productos a través del mismo proceso no incurre en cambio; cambiar entre dos procesos (incluso en el mismo tipo de entidad) sí. Si tu modelo de cambio está indexado por tipo de entidad hoy, reelabóralo alrededor de los procesos que realmente demandan la configuración.
Sink (Sumidero) El punto de salida. Las entidades que llegan a un sumidero se consumen y se cuentan. Configura:
  • Entity Type — requerido; solo las entidades del tipo coincidente pueden entrar al sumidero.
  • Event Hooks — Los Sumideros disparan entity terminated.
Buffer (Búfer) Un área de espera entre componentes. El encabezado del panel está etiquetado Buffer. Configura:
  • Entity Type
  • Capacidad, con un toggle explícito Infinite para colas no acotadas
  • Queue Discipline — FIFO (First In, First Out), LIFO (Last In, First Out) o Priority
  • Release Mode — Push (auto-release) (libera tan pronto como el componente descendente esté listo) o Hold (manual release) (libera solo en una acción Release Entity, útil para patrones pull-based / kanban)
  • Event Hooks — Los Búferes y Estaciones son los únicos componentes de flujo que emiten entity entered y entity exited
Router (Enrutador) Divide el flujo de entidades basado en un Logic Type configurable:
  • Round Robin — cicla a través de las salidas en orden
  • Conditional — reglas IF/THEN sobre atributos de entidad, estado de simulación o consultas de componente; soporta una Default Route configurable
  • Probabilistic — divisiones porcentuales con un filtro Entity Type; los pesos se normalizan automáticamente a probabilidades (no tienes que hacer que sumen 1). Sin Default Route — cada entidad coincide con una ruta ponderada.
  • Type-based — mapea cada tipo de entidad a un destino
Cada fila de regla Conditional o Probabilistic expone un toggle See expression / AI explanation para que puedas cambiar entre el DSL en bruto y una explicación en lenguaje natural. Ver Lenguaje de expresiones para la sintaxis dentro de las condiciones. Combiner (Combinador) Agrupa múltiples entidades de entrada en una sola entidad de salida. Ver Combinadores, separadores y transformadores para la lógica de tamaño de lote, asignaciones de salida multi-entidad (SUM(weight), MAX(priority), ALL(qc_passed)) y la interacción basada en linaje con las Estaciones. Separator (Separador) Divide una entidad de entrada en múltiples entidades de salida. Configura una Input Entity, una tabla Output Batch donde cada fila empareja un tipo de entidad de salida con una expresión de conteo (por ejemplo IF(tube_count >= 5, 2, 1)), y Asignaciones de Atributos por-tipo-de-salida con Strategy = Fixed | DSL Expression. Ver Combinadores, separadores y transformadores para el contexto multi-entidad en el hook batch created. Transformer (Transformador) Produce una nueva entidad de salida de un tipo diferente — útil cuando una materia prima se convierte en un producto diferente después de un paso de proceso. Ver Combinadores, separadores y transformadores. Station (Estación) Un contenedor con restricción de capacidad para componentes que representa un espacio físico o centro de trabajo. La capacidad se configura como una tabla por-tipo-de-entidad (por ejemplo Tube = 500, Tray = 100) para que la misma estación pueda contener diferentes números de diferentes elementos a la vez.
La capacidad de la Estación se rastrea por linaje de entidad, no por rendimiento. Cuando un Combinador o Separador opera dentro de una estación, las ranuras de capacidad están atadas a la entidad de entrada y solo se liberan cuando todos los descendientes han salido. Un Separador que produce tres salidas por entrada puede bloquear una estación con lo que parece baja utilización. La capacidad representa espacio físico, no tasa de flujo.
Model Node (Nodo de modelo) Embebe otro modelo de simulación dentro de este. Usa esto para construir modelos jerárquicos — define un subproceso una vez y reúsalo a través de múltiples modelos padre. Los Nodos de Modelo no aparecen en la paleta izquierda como un componente arrastrable; en su lugar, importa un archivo de modelo a través de la opción de importación de la barra superior para que aparezca en el panel Models a la izquierda, luego arrástralo desde allí al lienzo. Ver Nodos de modelo y modelado jerárquico para conexiones mapeadas, recursos compartidos, tópicos puenteados, variables de estado con alias y la sintaxis de ruta calificada parent::child.
Cada componente de flujo lleva una sección Event Hooks en su panel de configuración — Source, Process, Resource, Sink, Buffer, Router, Combiner, Separator, Transformer, Station. Cada hook se suscribe ya sea a un evento de ciclo de vida a nivel de componente (process started, entity created, entity terminated, etc.) o a un tópico publicado en otro lugar, y ejecuta una acción cuando se dispara (Assign, Emit, Pause, Resume, Release Entity, Set Capacity). Así es como la lógica de turnos, kanban, contrapresión y cualquier coordinación entre componentes se conectan. Ver Sistema de eventos para la lista completa de eventos por tipo de componente y el contrato de acción.

​
Conexiones

Dibuja conexiones entre las salidas y entradas de los componentes para definir cómo fluyen las entidades. Una conexión de un Proceso a un Búfer significa que las entidades que salen de ese proceso hacen cola en ese búfer antes de seguir.

​
Expresiones y el DSL

La mayoría de los campos numéricos y lógicos en la configuración de componentes aceptan ya sea un valor literal o una expresión escrita en el DSL (lenguaje específico de dominio) de ProDex. Las expresiones te permiten hacer modelos dinámicos y orientados a datos. Ver El lenguaje de expresiones para la referencia completa de funciones, variables incorporadas, contextos de expresión y patrones comunes. Usos comunes:
  • Tiempo de procesamiento como una distribución — por ejemplo, una distribución Triangular con Lower Bound 2, Mode 5, Upper Bound 10
  • Lógica de enrutamiento: IF(ENTITY_TYPE == "TypeA", "path_1", "path_2")
  • Requisito de recurso basado en atributo de entidad: IF(priority == "high", 2, 1)
  • Búsqueda desde una tabla: LOOKUP(cycle_times_table, ENTITY_TYPE)
Útiles incorporados:
  • SIM_TIME / NOW — tiempo actual de simulación
  • SIM_DURATION — duración total configurada de la ejecución
  • ENTITY_TYPE — tipo de la entidad actual
  • ENTITY_AGE — tiempo que la entidad ha estado en el sistema
  • BUFFER_LEVEL(buffer_name) — número actual de entidades en un búfer
  • BUFFER_CAPACITY(buffer_name) — capacidad configurada de un búfer
  • RESOURCE_AVAILABLE(resource_name) — unidades disponibles de un recurso
  • STATION_WIP(station_name) — trabajo en progreso en una estación
Los campos de tiempo usan un widget DDD:HH:MM:SS por defecto. Escribir 5 en la casilla de día te da 5 días, no 5 minutos. El pequeño ícono </> junto a cada campo de tiempo cambia la entrada al editor de expresiones DSL; úsalo cuando el valor deba depender del estado de la simulación, un atributo de entidad o una constante.
Cada campo de expresión tiene un toggle See expression / AI explanation. Haz clic en él en cualquier valor en modo DSL (un peso de Router Probabilístico, una condición de Resource Listener, un conteo de salida de Separator) para cambiar entre el DSL en bruto y una explicación en lenguaje natural escrita por Dexter. La explicación es el mismo artefacto que los usuarios ven en los popovers ? de gráficos — así es como confirmas que una expresión hace lo que crees que hace.
Las distribuciones se eligen del menú desplegable de 10 opciones, no se escriben como llamadas a funciones DSL. El selector en cada campo numérico expone el conjunto completo: Fixed, Normal, Exponential, Uniform, Lognormal, Weibull, Triangular, Erlang, Beta, Gamma. Cada campo de parámetro es un selector de tiempo DDD:HH:MM:SS con un toggle </>, así que cualquier parámetro puede ser él mismo una expresión DSL. Ver Distribuciones para la lista completa y las convenciones de parámetros.

​
Biblioteca

La biblioteca alberga los datos de referencia compartidos de los que tus modelos extraen. Todos los elementos de la biblioteca están alcanzados a una fábrica (Factory) y disponibles a través de cada modelo en ella. Verás “Library” en dos lugares que ambos se refieren a los mismos datos: el ícono Data en el riel global izquierdo (la superficie de gestión, donde creas y editas) y la pestaña Library dentro del panel izquierdo del Modelador (la vista en contexto para arrastrar entidades y componentes al grafo mientras construyes). El contenido es el mismo. Dentro del Modelador, la pestaña Metrics junto a Library superpone valores de KPI en vivo sobre los componentes en el lienzo después de una ejecución (Run) — útil para detectar dónde ocurre realmente la desaceleración sin salir de la vista de grafo.

​
Entidades

Las entidades son los elementos que fluyen a través de tu simulación — materias primas, trabajo en proceso y productos terminados. Cada entidad referenciada en una Fuente, Transformador o BOM debe definirse primero en la biblioteca. Cada tipo de entidad lleva un conjunto de atributos tipados (Boolean, Number, Text, Text List, Number List). En cualquier contexto de expresión de entidad única referencias un atributo por su nombre simple (priority, weight) — sin prefijo self.. Los atributos establecidos en una entidad persisten con ella a través de todo el flujo y pueden ser inspeccionados, mutados por Transformadores o agregados en Combinadores. El tipo de entidad está disponible en expresiones como ENTITY_TYPE. Ver Entidades y atributos para el sistema completo de tipos de atributos y las seis estrategias de asignación (Fixed, DSL Expression, Round Robin, Random Choice, Random, Weighted) usadas dondequiera que una entidad se cree o actualice.
Las entidades están alcanzadas a fábrica, no a modelo. Renombrar, retipear o eliminar una entidad en la biblioteca afecta a cada modelo en la misma fábrica que la referencia. Si necesitas una variante de una sola vez para un solo modelo, crea una nueva entidad en lugar de mutar una existente.

​
Constantes

Las constantes son parámetros nombrados, alcanzados a fábrica, que puedes referenciar por nombre en cualquier campo de expresión a través de todos los modelos. Cada constante tiene un nombre, descripción, tipo (Text, Number o Boolean) y un valor. Los nombres usan SCREAMING_SNAKE_CASE por convención — la misma convención aplica a los nombres de tablas de búsqueda y nombres de variables de estado — así que son fáciles de identificar dentro de una expresión. Referencia una constante por nombre directamente: 
PROCESSING_TIME_MINUTES * SHIFT_EFFICIENCY_FACTOR
Las constantes son la herramienta correcta para cualquier valor que aparece en múltiples lugares o que quieras barrer en un experimento. Cambia una constante una vez y cada componente que la referencia se actualiza automáticamente.

​
Tablas de búsqueda (Lookup Tables)

Las tablas de búsqueda son tablas clave-valor nombradas consultables en expresiones: 
LOOKUP(cycle_times, ENTITY_TYPE)
Cada tabla tiene un nombre y un conjunto de filas con claves de cadena y valores numéricos o de cadena. Si una clave no se encuentra, LOOKUP retorna un cero específico al tipo (0, "" o FALSE) — envuelve la llamada en un IF() si necesitas un fallback diferente. Ver Constantes y tablas de búsqueda para detalles. Usos comunes: tiempo de procesamiento por tipo de producto, tasas de rendimiento por material, pesos de enrutamiento por clase de orden, o cualquier dato que varía por un atributo categórico de la entidad siendo procesada.

​
Variables de estado

Las Variables de estado son valores mutables a nivel de modelo que persisten a través de las entidades — turno actual, contador de uptime de máquina, nivel de inventario, señal de demanda, promedio móvil. Léelas en cualquier expresión por su nombre simple; escríbelas vía una acción Assign en un Event Hook o una acción programada. Usa una Variable de estado cuando el valor pertenece al sistema en lugar de a una entidad específica. Para datos por entidad, usa un atributo de entidad en su lugar.

​
Tópicos

Los tópicos son canales pub/sub nombrados. Un componente publica un mensaje vía una acción Emit; cualquier componente suscrito a ese tópico reacciona vía un Event Hook. Los tópicos son cómo los componentes no relacionados se coordinan sin estar cableados por conexiones de flujo. Las Constantes, Tablas de búsqueda, Variables de estado y Tópicos se gestionan todos en el mismo modal de cuatro pestañas abierto haciendo clic en Lookups en la parte inferior del panel Library del Modelador (junto al botón Entities). Las pestañas del modal son Constants, Lookup Tables, State Variables y Topics — misma superficie, cuatro tipos de datos. Ver Sistema de eventos para patrones como kanban, contrapresión y capacidad impulsada por turnos.

​
Sistema de eventos

Más allá de las conexiones de flujo, ProDex soporta coordinación entre componentes vía Tópicos, Variables de estado, Event Hooks y Event Listeners. Estos te permiten modelar producción pull-based, contrapresión, cambios de capacidad impulsados por turnos y cualquier comportamiento que no sea expresable con un simple grafo de flujo. Un modelo construido solo con Fuentes, Procesos y Sumideros captura aproximadamente el 40% de lo que la plataforma puede hacer. El Sistema de eventos es cómo modelas el resto — reglas operativas que abarcan múltiples componentes, estado que persiste a través de las entidades y reacciones a eventos de ciclo de vida como cambios de turno o umbrales de búfer.

​
Hooks vs. Listeners

Las dos primitivas de reacción lucen similares pero viven en lugares diferentes:
  • Event Hooks — en línea, configurados directamente en el panel de un componente de flujo (cada Source, Process, Buffer, etc. tiene una sección Event Hooks). Un hook se dispara solo cuando el componente en el que vive emite el evento de ciclo de vida correspondiente, o cuando el tópico al que se suscribe publica.
  • Event Listeners — objetos de primera clase por derecho propio, desacoplados de cualquier componente único. Un listener tiene su propio alcance y expresión de condición, y se ejecuta cuando su disparador se dispara en cualquier lugar del modelo. Recurre a un listener cuando la reacción tiene que abarcar múltiples componentes o cuando la misma lógica debe aplicarse a través de muchos lugares.
Ver Sistema de eventos para la referencia completa, incluyendo patrones como kanban, contrapresión y capacidad impulsada por turnos.

​
Calendarios

Un modelo corre en tiempo abstracto a menos que esté emparejado con un calendario. Los calendarios anclan la simulación al tiempo del mundo real: las liberaciones de material se disparan en momentos específicos, las transiciones de turno se disparan en momentos específicos, y los resultados se vuelven comparables directamente con lo que realmente sucedió en tu piso. Un modelo puede tener múltiples calendarios definidos y eliges uno en la barra superior. Cada Instantánea (Snapshot) guardada mientras un calendario particular está activo correrá contra ese calendario cuando se agregue a un experimento. Usos típicos: escenarios línea base vs. estrés, replay histórico, planes alternativos de turno. Ver Calendarios para la referencia completa — liberaciones de material, acciones programadas (Assign Variable y Emit Event solamente), el patrón de programación de turnos y semántica de Start Time / End Time.

​
Ejecutando una simulación

Los controles de ejecución (Run) en la parte inferior del lienzo te dan tres botones:
  • Run simulation (botón verde de reproducir, tooltip “Run simulation”) — corre la simulación hasta completarla. Hace doble función como indicador de validación.
  • Step (ícono de skip-forward) — avanza un evento a la vez, útil para depurar una cadena de eventos o verificar una decisión de enrutamiento. Habilitado solo mientras una simulación está en vuelo.
  • Playback speed (tooltip “Playback speed”) — controla qué tan rápido se reproduce la animación del lienzo. Este es un control de visualización, no un control de velocidad del motor — el motor de simulación subyacente siempre corre a velocidad completa.
El botón Run-simulation hace doble función como indicador de validación. Verde significa que el modelo es válido y está listo para correr. Cuando la validación falla el botón se vuelve rojo; pasar el cursor sobre él muestra el conteo de errores, el texto del error y una acción Fix with Assistant que entrega la falla a Dexter para una propuesta de un clic que puedes aceptar o refinar. Debajo del lienzo, una línea de tiempo horizontal muestra cada liberación de material, transición de turno y acción programada. Con la selección Default (no schedule), el eje es impulsado por el campo Duration en la parte superior del lienzo — por defecto 00:00–08:00 (8 horas), y cambiar Duration cambia el eje. Elige un calendario distinto de Default y el eje cambia a fechas de reloj de pared y marcas reflejando el Start Time / End Time del calendario y los eventos en él. Usa la línea de tiempo para confirmar que el calendario se alinea con lo que esperas antes de correr.

​
Controles del lienzo

La parte inferior derecha del lienzo expone una pila vertical de controles de vista: Zoom In (+), Zoom Out (–), Fit View (auto-ajusta todos los nodos), Auto format layout (ícono de varita-destellos, reorganiza nodos) y Find node (⌘F / Ctrl+F). Cada ejecución crea un registro de Ejecución (Run) con un conjunto completo de resultados, enlazado de vuelta a la Instantánea contra la que se ejecutó. Puedes correr el mismo modelo múltiples veces y comparar ejecuciones en las secciones Resultados y Experimentos.

​
Leyendo tus resultados

Los resultados están definidos por los KPIs y Gráficos adjuntos a tu modelo. Ver la guía Resultados y análisis para un desglose completo.

​
Consejos y mejores prácticas

  • Empieza simple. Una Fuente → Proceso → Sumidero es suficiente para validar tu configuración antes de agregar complejidad.
  • Usa constantes para cualquier valor que podrías querer cambiar entre ejecuciones. Esto hace que el análisis de escenarios sea mucho más fácil.
  • Nombra todo claramente. Los nombres de componentes aparecen en los resultados y registros de eventos — los nombres descriptivos hacen que los resultados sean mucho más fáciles de interpretar.
  • Usa estaciones para agrupar componentes relacionados. Los modelos grandes se vuelven difíciles de navegar sin organización.
  • Observa el botón de reproducir. Verde significa válido, rojo significa que hay un bloqueador específico — ver Validación para lo que se verifica. El botón Fix with Assistant en el popover de estado rojo entrega el error a Dexter para una propuesta de un clic.
  • Guarda Instantáneas en momentos clave. Las Instantáneas capturan la configuración completa de un modelo y son lo que los Experimentos comparan. Guarda una antes de cambios significativos o como línea base para comparación.