Modelador

​

Resumen

El Modelador es donde se construye un modelo de simulación: un grafo dirigido de componentes en un lienzo, más las entidades, expresiones, datos de referencia, y lógica de eventos que lo hacen comportarse como tu operación. Esta página es la referencia de trabajo para esa superficie — los controles en la parte superior de la página, cada tipo de componente y su configuración, el lenguaje de expresiones, el panel izquierdo, y cómo se ejecuta realmente un modelo. Si nunca has construido un modelo, recorre Tu primera simulación una vez primero. Y nunca tienes que manejar el lienzo a mano: Dexter construye y edita modelos de forma conversacional, ya sabe qué modelo tienes abierto, y se combina libremente con ediciones manuales.

​

Qué es la simulación de eventos discretos

La simulación de eventos discretos (DES) representa una operación como una secuencia de instantes en los que algo cambia — llega una orden, una máquina termina un ciclo, un recurso queda libre. Entre eventos no pasa nada, así que el tiempo simulado salta de un evento al siguiente; por eso un modelo de un mes de producción corre en segundos. Cambia una capacidad, una distribución, o un búfer, y ves los efectos aguas abajo de inmediato, sin tocar el sistema real. Construyes el modelo visualmente y el motor de simulación de ProDex lo ejecuta directamente. El lienzo es la fuente de verdad — no hay código de motor que escribir.

​

Construir en el lienzo

Un modelo es un grafo dirigido: los componentes son nodos, las conexiones son aristas, y las entidades fluyen a lo largo de las aristas. Arrastra componentes desde el dock en la esquina inferior izquierda del lienzo (el botón de flecha debajo lo expande y colapsa), suéltalos en el lienzo, conecta el conector de salida de cada componente al conector de entrada del siguiente, y haz clic en cualquier componente para abrir sus ajustes en la vista Propiedades del panel izquierdo. El modelo mínimo viable es Fuente → Proceso → Sumidero. Todo lo demás — búferes, enrutadores, estaciones, lógica de eventos — se gana su lugar a medida que tus preguntas lo exigen.

​

La barra superior

• Selector de modelo — cambia el modelo abierto; su menú también tiene Nuevo Modelo, Renombrar, y Eliminar.
• Selector de programación — elige qué impulsa los tiempos: Predeterminado (sin programación) o cualquier programación definida para el modelo. Su menú también tiene Nuevo Programa, además de Editar y Eliminar para la programación seleccionada. Con una programación con nombre activa, la Hora de Inicio y Hora de Finalización propias de la programación impulsan la ejecución.

El menú ⋯ a la derecha de la barra tiene el resto:

• Duración — se muestra mientras Predeterminado es la programación activa; establece la duración de la ejecución (DDD:HH:MM:SS).
• Regla de asignación de recursos — cómo compiten los Procesos por los Recursos cuando una solicitud aún no puede satisfacerse. Consulta Regla de asignación de recursos.

​

Tipos de componentes

Cada panel de componente de flujo también lleva una sección Event Hooks y una sección Event Listeners — la lógica de reacción cubierta en El sistema de eventos más abajo.

​

Fuente

Por donde las entidades entran al modelo.

• Tipo de entidad — qué entidad produce esta Fuente.
• Lógica de llegada — el tiempo entre llegadas (el tiempo entre llegadas, no una tasa), tomado del selector de distribución o de una expresión DSL.
• Valores iniciales de atributos — por atributo, una Estrategia: Fijo, Expresión DSL, Round Robin, Aleatorio (elige de las opciones del atributo), Distribución (muestrea una distribución), o Ponderado (una tabla de valor/peso). El menú desplegable se reduce a las estrategias válidas para el tipo del atributo — consulta la matriz de tipo por estrategia. Ten en cuenta que una asignación DSL en una Fuente se ejecuta antes de que la entidad exista, así que no puede leer los otros atributos de la nueva entidad.
• Eventos — dispara entity created por cada entidad producida.

Una Fuente de solo evento es válida a propósito: deja la lógica de llegada vacía y la Fuente no produce nada por sí sola, liberando entidades solo cuando una acción release o una liberación de material de la programación la dispara. Cuando una programación está activa, sus liberaciones de material corren en paralelo con la lógica de llegada propia de la Fuente — ambas se disparan — así que decide deliberadamente qué mecanismo (o ambos) impulsa cada punto de entrada.

​

Proceso

Un paso que toma tiempo y puede consumir recursos.

• Tipo de Entidad — limita el resto del panel a un tipo de entidad.
• Tiempo de Procesamiento — una distribución o expresión DSL.
• Requisitos de Recursos — una tabla multi-fila (Agregar Fila) de recurso → cantidad en número entero. Conectar un nodo de Recurso a uno de los conectores naranjas de recurso en la parte superior o inferior del Proceso también agrega una fila; una conexión a los conectores de flujo laterales del Proceso no lo hace. El interruptor Retener de cada fila mantiene ese recurso con la entidad después de este proceso, así que el siguiente proceso que lo necesite lo usa sin una nueva solicitud. Pídele a Dexter que convierta una cantidad en una expresión; un requisito cuya cantidad se evalúa en 0 se omite para esa entidad — el mecanismo detrás de los patrones de capacitación cruzada y sustitución.
• Estación — opcionalmente coloca el Proceso dentro de una Estación.
• Eventos — process started, process completed.

​

Recurso

Un pool de capacidad — trabajadores, máquinas, herramientas — del que se nutren los Procesos. Arrastra un Recurso desde el dock como cualquier otro componente, y luego conéctalo a un conector naranja de recurso en cada Proceso que lo use (o elígelo en la tabla de requisitos del Proceso).

• Capacidad — número de ranuras paralelas.
• Disciplina de Asignación — FIFO (Primero en Entrar, Primero en Salir), LIFO (Último en Entrar, Primero en Salir), o Prioridad (una clave DSL con orden ascendente/descendente).
• Tiempos de Cambio — una tabla de filas (de proceso, a proceso) → duración. Se permiten pares del mismo proceso. En el panel, cada duración es un tiempo fijo; pídele a Dexter cuando un cambio deba ser una distribución o una expresión DSL. Una expresión puede leer los identificadores exclusivos de cambio de las entidades saliente y entrante — sus tipos y sus atributos — así un solo tiempo de cambio puede variar según el par (entidad saliente, entidad entrante) en lugar de depender solo del proceso.
• Eventos — slot freed, slot working. Una acción set capacity que reacciona a temas de turno es el patrón de programación de turnos estándar; el mismo mecanismo modela averías, ventanas de mantenimiento y cambios de personal.

​

Regla de asignación de recursos

Un Proceso adquiere todo lo que necesita a la vez: solo arranca cuando cada recurso de su tabla de requisitos tiene una ranura libre, y mientras espera no bloquea nada más allá de los recursos que la entidad ya retiene de un proceso anterior. Cada Recurso ordena las solicitudes en espera según su Disciplina de Asignación. La Regla de asignación de recursos en el menú ⋯ decide qué pasa cuando la solicitud al frente de la fila aún no puede satisfacerse:

• Permitir adelantar (pass) — el valor predeterminado. Una solicitud que puede obtener todos sus recursos puede adelantar a una bloqueada.
• Respetar precedencia (no pass) — las solicitudes bloqueadas mantienen su lugar en la cola, incluso si eso deja capacidad libre inactiva.

La regla se guarda con el modelo. Cuando el modelo se ejecuta como modelo de nivel superior, también se aplica a cada submodelo dentro de él. Cambiarla puede alterar los tiempos de espera y el rendimiento, así que compara ejecuciones con ambos ajustes si eso importa para tu decisión.

​

Búfer

Un área de espera entre componentes.

• Tipo de Entidad, y Capacidad con un interruptor explícito de Infinito.
• Disciplina de Cola — FIFO, LIFO, o Prioridad.
• Modo de Liberación — Push (liberación automática) envía entidades aguas abajo tan pronto como hay espacio; Hold (liberación manual) las retiene hasta que una acción release se dispara — el patrón kanban/pull.
• Eventos — entity entered, entity exited, contents changed. Los Búferes y las Estaciones son los componentes que emiten el par entrada/salida por entidad; los Procesos señalizan mediante process started/completed en su lugar.

​

Enrutador

Divide el flujo de entidades entre las conexiones salientes según su Tipo de Lógica: Los Enrutadores disparan entity routed por cada entidad. Cada fila de regla Condicional o Probabilística tiene un interruptor Ver expresión / Explicación IA que alterna entre el DSL en bruto y una explicación en lenguaje sencillo — la forma más rápida de confirmar que una regla hace lo que crees que hace.

​

Combinador, separador y transformador

Los componentes de loteo, cubiertos en profundidad en Combinadores, separadores y transformadores:

• Combinador — combina múltiples entradas en una sola salida (ensamblaje). Los lotes se forman a partir de cantidades estáticas por entrada o de una expresión de lote dinámica evaluada en cada llegada. Las asignaciones de atributos de salida se ejecutan en contexto multi-entidad, así que aplican las agregaciones — SUM, MEAN, MAX, MIN, COUNT, ANY, ALL, MODE, N_UNIQUE sobre el lote (p. ej. SUM(weight), MAX(priority), ALL(qc_passed)). Un atributo agregado debe existir en cada tipo de entrada — dale un valor por defecto a las entradas que no lo llevan naturalmente en lugar de dejarlo ausente.
• Separador — divide una entrada en varias salidas: una tabla de Lote de Salida empareja cada tipo de entidad de salida con una expresión de conteo, con asignaciones de atributos por salida (Fijo o DSL).
• Transformador — una entrada, una salida. Cambiar el tipo de entidad es solo la mitad de su trabajo: configurar el mismo tipo de entrada y salida es la forma estándar de mutar atributos a mitad de flujo (incrementar un contador de retrabajo, marcar un resultado de control de calidad).

Los tres normalmente se colocan dentro de una Estación en lugar de estar solos.

​

Estación

Un contenedor con capacidad restringida que representa un espacio físico o centro de trabajo. La capacidad es una tabla por tipo de entidad (p. ej., Tubo = 500, Bandeja = 100), así que una estación puede contener distintas cantidades de distintos elementos a la vez; deja un tipo sin límite cuando la estación no sea la restricción. Las Estaciones también agrupan componentes relacionados, lo que mantiene navegables los modelos grandes — y emiten entity entered, entity exited, y contents changed (contexto multi-entidad sobre el contenido actual, el lugar habitual de los medidores de WIP).

​

Sumidero

El punto de salida. Tipo de Entidad es requerido — solo las entidades coincidentes pueden entrar — y las entidades que llegan se consumen, se cuentan, y disparan entity terminated.

​

Nodo de modelo

Incorpora otro modelo de la misma fábrica como un solo componente — la clave del modelado jerárquico. Primero importa el modelo: en la sección Submodelos del panel izquierdo, haz clic en + (o Importar Modelo) y elige otro modelo de la fábrica. Los modelos importados luego aparecen bajo el botón Submodelo del dock; ábrelo y arrastra un modelo al lienzo. Cada instancia mapea sus conexiones externas a las fuentes y sumideros internos del submodelo, y puede asignar alias a recursos, temas y variables de estado por instancia; los componentes anidados se referencian con rutas calificadas parent::child. Consulta Nodos de modelo y modelado jerárquico.

​

Conexiones

Arrastra desde el conector de salida de un componente hasta el conector de entrada de otro para definir el flujo. Las entidades se mueven a lo largo de una conexión cuando el componente aguas abajo puede aceptarlas — o, en los Búferes en modo Hold, cuando se liberan explícitamente. Dos reglas de topología que conviene saber de entrada: las conexiones no pueden empezar ni terminar en una Estación (conecta los componentes de adentro en su lugar), y las reglas de un Enrutador se adjuntan a sus conexiones salientes. La Validación impone el conjunto completo de reglas mientras editas.

​

El sistema de eventos

Las conexiones de flujo describen cómo se mueven las entidades; el sistema de eventos describe cómo reacciona el modelo. Dos primitivas, ambas configuradas en el panel de cada componente de flujo:

• Los Event Hooks se disparan con los eventos de ciclo de vida propios del componente — los eventos entity created / process completed / contents changed listados por componente más arriba. El contexto de expresión del hook sigue al evento: entidad única para ciclos de vida por entidad, multi-entidad para eventos de lote y de contents changed, sin entidad para eventos de ranura de recurso.
• Los Event Listeners se disparan cuando se emite un tema suscrito en cualquier parte del modelo — y siempre corren en contexto sin entidad: un listener puede leer variables de estado, constantes, tablas de búsqueda y consultas de componente, pero nunca los atributos de la entidad que emitió. Cuando la lógica entre componentes necesita datos por entidad, el patrón es: un hook escribe lo que necesita en el estado y emite; el listener lee el estado.

Ambos aceptan una condición booleana opcional y una lista de acciones: assign (escribe una variable de estado), emit (publica en un tema), release (solo Fuentes y Búferes), pause / resume (solo Fuentes y Búferes), y set capacity (solo Recursos). Así es como se conecta la lógica de turnos, el kanban, la contrapresión, y cualquier otro comportamiento que abarque varios componentes — consulta Sistema de eventos para el contrato completo de eventos y acciones por componente.

​

Expresiones y el DSL

La mayoría de los campos numéricos y lógicos aceptan un literal o una expresión en el DSL de ProDex, que es como los modelos se vuelven dinámicos y orientados a datos: condiciones de enrutamiento sobre atributos, necesidades de recursos por entidad, duraciones que dependen del estado. Identificadores disponibles en todas partes: SIM_TIME (tiempo actual de simulación) y SIM_DURATION (la duración configurada de la ejecución, no el tiempo restante). En contextos de entidad: ENTITY_TYPE (el identificador del tipo de la entidad) y ENTITY_AGE. En hooks y listeners: SELF, el id del componente que lo aloja — lo que hace que las reglas se puedan copiar y pegar entre componentes. Consultas de componente, utilizables en cualquier contexto: BUFFER_LEVEL(id), BUFFER_CAPACITY(id), RESOURCE_AVAILABLE(id), RESOURCE_CAPACITY(id), STATION_WIP(id) — y LOOKUP(table, key1, key2, ..., default:=value) consulta una tabla de búsqueda por una o más claves. Qué campos corren en qué contexto — y el catálogo completo de funciones y agregaciones — vive en El lenguaje de expresiones. Las distribuciones se eligen de un menú desplegable de diez opciones (Fijo, Normal, Exponencial, Uniforme, Lognormal, Weibull, Triangular, Erlang, Beta, Gamma), no se escriben como llamadas DSL. Cada parámetro de cada distribución acepta un número literal o una expresión DSL por muestra, así que cualquiera de ellos puede variar según la entidad o el estado. Consulta Distribuciones para las convenciones de parámetros y cuál usar.

​

El panel izquierdo

El panel a la izquierda del lienzo tiene dos vistas:

• Vista general — lo que el modelo usa, en seis secciones: Entidades, Variable, Temas, Constantes, Tablas de búsqueda, y Submodelos. El lápiz del encabezado de cada sección (Ver y gestionar todo) abre el diálogo de gestión completo, y la fila + Agregar… al final de la sección agrega un elemento existente al modelo o crea uno nuevo (los Submodelos usan el + del encabezado en su lugar). La × de una fila quita el elemento de este modelo sin eliminarlo; está deshabilitada mientras algo en el modelo aún lo referencie. Debajo de las secciones, una lista de Eventos se llena a medida que corre la simulación, y durante la reproducción las filas de Variable muestran valores en vivo.
• Propiedades — los ajustes del componente que seleccionaste en el lienzo. La flecha de retroceso regresa a la Vista general.

Las entidades, constantes, tablas de búsqueda y submodelos pertenecen a la fábrica: cada uno se define una vez, y cada modelo agrega los que usa. Las variables de estado y los temas pertenecen al modelo en sí.

​

Entidades

Los elementos que fluyen a través de tu simulación: materias primas, WIP, productos terminados. Un tipo de entidad debe agregarse al modelo antes de que una Fuente, Transformador u otro componente pueda usarlo — usa + Agregar entidad en la sección Entidades, o abre el lápiz para crear, editar y explorar tipos de entidad y haz clic en Add to model. Cada tipo de entidad lleva atributos tipados (Boolean, Number, Text, Text List, Number List), referenciados por su nombre simple en contextos de una sola entidad — sin prefijo self.. Los atributos persisten con la entidad a lo largo de todo el flujo. Ten en cuenta que los dos tipos de lista son conjuntos de elección discretos — a pesar del nombre, cada uno contiene un solo miembro de sus choices declarados, no una colección. Solo aceptan un valor fijo o muestreado; una asignación calculada por DSL se rechaza en la validación. Si un nodo aguas abajo necesita calcular o transportar el valor, haz que el atributo sea un Number o Text escalar en su lugar.

​

Constantes

Parámetros con nombre y alcance de fábrica — Text, Number, o Boolean — referenciados por su nombre simple en cualquier expresión: PROCESSING_TIME_MINUTES * SHIFT_EFFICIENCY_FACTOR. Los nombres deben usar SCREAMING_SNAKE_CASE y no pueden reutilizar una palabra reservada ni el nombre de otra constante o tabla de búsqueda. Las constantes son el lugar correcto para cualquier valor que aparezca en varios sitios o que quieras variar entre ejecuciones: cámbialo una vez, y cada campo que lo referencia se actualiza.

​

Tablas de búsqueda

Tablas indexadas que se pueden consultar desde cualquier expresión — LOOKUP(CYCLE_TIMES, ENTITY_TYPE) — con nombres en SCREAMING_SNAKE_CASE, una o más columnas clave y valores Text/Number/Boolean. Una clave ausente devuelve el default:= que pases, o un cero específico del tipo (0, "", FALSE) si no lo haces. Usos típicos: tiempo de ciclo por producto, rendimiento por material, peso de enrutamiento por clase de orden. Consulta Constantes y tablas de búsqueda.

​

Variables de estado

Valores mutables a nivel de modelo que persisten a través de las entidades: el turno actual, un nivel de inventario, un promedio móvil. Léelas por su nombre simple en cualquier contexto; escríbelas con una acción assign en un hook, un listener, o una acción programada. Los nombres siguen la misma regla de SCREAMING_SNAKE_CASE. Usa una variable de estado cuando el valor pertenece al sistema; usa un atributo de entidad para datos por entidad.

​

Temas

Canales de pub/sub con nombre: un componente publica con una acción emit, y cualquier componente cuyo Event Listener esté suscrito al tema reacciona — coordinación sin una conexión de flujo entre ellos. Constantes, Tablas de búsqueda, Variables de estado y Temas comparten un mismo diálogo de Búsquedas de cuatro pestañas; el lápiz de la sección correspondiente en la Vista general lo abre en esa pestaña.

​

Programaciones

Un modelo corre en tiempo abstracto hasta que lo emparejas con una programación, que ancla la ejecución al tiempo de calendario real: las liberaciones de material inyectan entidades específicas en momentos específicos (en paralelo con la lógica de llegada de la Fuente, no en su lugar), y las acciones programadas disparan assign y emit en momentos específicos — las acciones de control de componentes siguen siendo exclusivas de los hooks. Un modelo puede tener varias programaciones — una semana base, un escenario de estrés, una repetición histórica — y eliges la activa en el selector de programación en la parte superior de la página.

​

Ejecutar una simulación

Los controles de ejecución están en la parte inferior del lienzo:

• Ejecutar simulación (botón de reproducir) — ejecuta el modelo hasta completarlo.
• Avanzar rápidamente al final (ícono de avance) — salta la reproducción en el lienzo directo al final de la ejecución; disponible una vez que la ejecución produjo datos para reproducir.
• Velocidad de reproducción — controla solo la animación en el lienzo. El motor siempre corre a velocidad completa.

El botón de reproducir también funciona como el indicador de validación: verde significa listo; ámbar significa que el modelo tiene advertencias pero aun así se ejecuta; rojo significa un bloqueador específico que detiene la ejecución. Pasa el cursor sobre un botón ámbar o rojo para ver el conteo, los mensajes exactos, y un botón Corregir con Dexter que se los envía a Dexter para que los arregle. El Modelador autoguarda mientras trabajas, así que no hay un paso de guardado manual: la validación se vuelve a ejecutar contra ese estado guardado después de cada edición — revisando el tipado del DSL, la compatibilidad del flujo de entidades, los hooks, las programaciones, y los modelos anidados — y el botón de reproducir siempre refleja el modelo actual. Debajo del lienzo, una línea de tiempo horizontal muestra cada liberación de material, transición de turno, y acción programada. Con Predeterminado seleccionado, el eje sigue el ajuste de Duración; con una programación activa, cambia a fechas de calendario real que abarcan la Hora de Inicio y Hora de Finalización de la programación. Revísala antes de ejecutar para confirmar que la programación coincide con lo que esperas. Las ejecuciones corren contra el modelo de trabajo en vivo — ajusta, ejecuta, repite. Para comparar configuraciones, ejecuta cada variante y compara las ejecuciones; para medir la variabilidad, replica una ejecución con varias semillas. Cada ejecución crea una ejecución cuyos KPIs y gráficos se calculan en un segundo paso después de que la simulación termina — una ejecución que muestra pendiente no está rota, solo sigue calculando. Lee la salida en Resultados y análisis. La parte inferior derecha del lienzo tiene los controles de vista: Acercar / Alejar, Ajustar vista, Auto formatear diseño (reorganiza los nodos), Buscar nodo (⌘F / Ctrl+F), y 3D.

​

Vista 3D

3D (o la tecla V) cambia el lienzo a una vista 3D de planta del mismo modelo; Vista 2D, o V de nuevo, regresa a la vista anterior. El dock, los controles de ejecución, y la selección de componentes funcionan igual en 3D. Arrastra con clic izquierdo para orbitar, mantén Espacio o arrastra con clic derecho para desplazar, usa la rueda para hacer zoom, y arrastra con Shift para seleccionar varios componentes. El Modelador recuerda qué vista usaste por última vez para cada modelo.

​

Consejos y buenas prácticas

• Empieza simple. Fuente → Proceso → Sumidero valida tu configuración antes de agregar complejidad.
• Usa constantes para cualquier cosa que vayas a cambiar entre ejecuciones — los barridos de escenarios se convierten en ediciones de un solo campo.
• Nombra todo en los términos del operador. Los nombres de los componentes aparecen en los resultados, los registros de eventos y los gráficos; los buenos nombres se pagan solos cada vez que lees una salida.
• Usa estaciones para agrupar componentes relacionados — los modelos grandes se vuelven difíciles de navegar sin estructura.
• Observa el botón de reproducir. Verde significa válido; rojo indica un bloqueador específico, y Corregir con Dexter se lo entrega a Dexter.
• Copia antes de cambios grandes. Pídele a Dexter que copie el modelo en los hitos, para que puedas seguir ejecutando la configuración anterior y comparar contra ella.