Skip to main content

​
Visión general

Los Combinadores, Separadores y Transformadores son los tres componentes del Modelador que reorganizan el flujo de entidades en lugar de simplemente enrutarlas o retrasarlas. Son la forma de modelar ensamblaje, desensamblaje, agrupación, kitting, empaque y cualquier operación donde las entidades que entran no son las mismas que las que salen. (¿Nuevo en el modelado de flujo? Empieza por el Resumen de la simulación para ver cómo encajan estos componentes en el grafo de flujo de un modelo.) Estos componentes parecen simples (una caja con entradas y salidas), pero cada uno tiene un comportamiento específico que vale la pena entender antes de construir una operación de ensamblaje o desensamblaje, especialmente en torno a cómo interactúan con la capacidad de Estación, el traspaso de atributos, la identidad de entidad y el contexto multi-entidad del DSL.

​
Cuándo un Combinador es la herramienta equivocada

No todo lote necesita un Combinador. Un Combinador consume sus entradas y acuña una entidad de salida nueva: el ciclo de vida por unidad de cada entrada termina en la costura del lote, y el análisis por unidad aguas abajo (tiempos de espera, conteos de unidades distintas, rendimiento) tiene que unirse a través de esa costura. Cuando los ítems simplemente viajan juntos por un tramo pero siguen siendo significativos individualmente, el patrón recomendado es un Búfer con el Modo de Liberación en Retención (liberación manual) y una acción release condicional, en lugar de un par Combinador/Separador: las entidades liberadas conservan su identidad de principio a fin, así que no hay que reensamblar nada después.
Recurre a un Combinador (con o sin un Separador aguas abajo) cuando el lote en sí es lo que se está procesando: un palet o kit con su propio enrutamiento, tiempos de procesamiento y atributos. Usa un Búfer de retención y liberación cuando solo necesitas “esperar hasta que se acumulen suficientes, y luego dejarlos ir juntos”: una acción release en el hook buffer contents changed del Búfer se dispara una vez que el conteo acumulado supera tu umbral. Consulta el Sistema de eventos para la acción release y sus campos de cantidad y filtro.

​
Combinador

Un Combinador fusiona múltiples entidades de entrada en una sola entidad de salida. Úsalo para modelar ensamblaje (partes → producto), agrupación (ítems individuales → palet), kitting (componentes → kit), o cualquier operación donde varios ítems se convierten en uno.

​
Lotes de entrada

El Lote de Entrada del Combinador tiene exactamente dos modos, elegidos desde un selector Estático / Expresión DSL en sus propiedades:
  • Estático: una lista de tipos de entidad de entrada, cada uno con una cantidad. Un tube, una tray y una label significa “espera hasta tener uno de cada antes de ensamblar”. Esta es la forma canónica de ensamblaje: distintas cantidades de distintos tipos de entrada alimentando una salida. Las entidades en espera se consumen FIFO por tipo de entrada cuando se cierra el lote.
  • Expresión DSL: una expresión booleana de disparo evaluada cada vez que llega una entidad. Cuando la expresión devuelve true, cada entidad acumulada se combina en una salida. Úsala cuando la composición del lote depende del estado en tiempo de ejecución.
El modo Expresión DSL tiene dos campos: Tipos de Entidad de Entrada (los tipos de entidad que acepta el Combinador) y Expresión de Activación de Lote (el disparador booleano). El disparador corre en contexto multi-entidad sobre las entidades actualmente acumuladas, así que puedes escribir disparadores como COUNT(1) >= MIN_BATCH AND SUM(weight) >= LOAD_THRESHOLD.

​
Contexto multi-entidad para atributos de salida

Una asignación de atributo de salida del Combinador corre en contexto multi-entidad: varias entidades de entrada están en alcance a la vez. Las referencias de atributo desnudas como weight son ambiguas (¿de cuál entrada?), así que deben envolverse en funciones de agregación:
Las asignaciones de atributos de salida usan el desplegable estándar Estrategia, igual que las Fuentes, Transformadores y salidas del Separador; qué estrategias ofrece depende del tipo del atributo (ver Estrategias de asignación). El patrón de agregación mostrado arriba usa Expresión DSL. El conjunto completo de agregación disponible aquí es SUM, MEAN, MAX, MIN (polimórfico: los valores de texto se comparan en orden lexicográfico), COUNT, ANY, ALL, MODE (los empates se resuelven a favor del primer valor visto) y N_UNIQUE. Consulta Funciones de agregación para las firmas y los argumentos con nombre filter:= / type:=.
Una agregación lee su atributo a través de cada entrada acumulada. Si solo algunos de los tipos de entrada del Combinador definen el atributo, la expresión se rompe: declara el atributo (con un valor predeterminado sensato) en cada tipo de entidad que acepta el Combinador.

​
Eventos del Combinador

Un Combinador emite tres eventos de ciclo de vida (etiquetas de la UI):
  • entity consumed: se dispara para cada entidad de entrada consumida (contexto de una sola entidad, la entrada)
  • batch assembled: se dispara cuando se cierra el lote (contexto multi-entidad, todas las entradas)
  • entity created: se dispara cuando se emite la entidad de salida (contexto de una sola entidad, la salida)
El Entity Type Filter (opcional) de un hook solo es válido en entity consumed (para poder reaccionar solo al consumo de un tipo de entrada específico).

​
Lotes parciales al final de la simulación

Una simulación puede terminar con entidades esperando en un Combinador que aún no alcanzó su umbral de lote. Durante la corrida, esas entidades se comportan exactamente como se espera: el lote nunca se cierra, así que no se acuña ninguna entidad de salida y nada llega a un Sumidero aguas abajo. Lo importante para tu análisis es que nunca contribuyen al throughput combinado: la entidad ensamblada que las habría transportado nunca se crea.
Un lote parcial que queda abierto al final de la simulación nunca produce su salida. Para simulaciones cortas con tamaños de lote grandes, esto puede afectar de forma material las cifras de throughput combinado. Elige una duración que permita que el último lote esperado se cierre, o diseña el modelo para que un lote no completado salga a la superficie como un evento explícito, en lugar de confiar en dónde caen las entidades de entrada sobrantes en los resultados.

​
Separador

Un Separador divide una entidad de entrada en múltiples entidades de salida. Úsalo para modelar desensamblaje (kit → componentes), desagrupación (palet → ítems individuales), o cualquier operación de “una entra, muchas salen”.

​
Entidad de entrada y lote de salida

El panel de configuración del Separador tiene dos controles de nivel superior:
  • Entidad de Entrada: un único desplegable de tipos de entidad definidos en el modelo. El Separador solo acepta entidades de este tipo.
  • Lote de Salida: una tabla de tipos de entidad de salida. Cada fila es un tipo de entidad más una expresión DSL que devuelve la cantidad de ese tipo a emitir por entrada. Una fila component con 4 significa “emite 4 entidades de tipo component por entrada”. Las cantidades variables pueden leer atributos de entrada: input_quantity.
Las expresiones de conteo de salida corren en contexto de una sola entidad, con los atributos de la entidad de entrada en alcance (weight, priority, etc.).

​
Atributos de salida

Cada tipo de entidad de salida obtiene su propia sección de asignaciones de atributos debajo del Lote de Salida, una por tipo de salida. Cada asignación usa el desplegable estándar Estrategia. Las asignaciones de atributos de salida corren en contexto de una sola entidad con los atributos de la entidad de entrada en alcance: las referencias a weight, priority, etc. leen la entrada, y la asignación produce valores para la entidad de salida que se está creando. Un patrón común: dividir una cantidad entre las salidas de forma pareja (weight / output_count) o copiar una clasificación de la entrada a cada salida.
Las salidas del Separador no heredan automáticamente los atributos de entrada. Cada atributo de salida que te importe debe asignarse explícitamente, casi siempre con Expresión DSL referenciando el atributo de entrada por nombre. Omitir una asignación le da a ese atributo de salida el valor predeterminado del tipo (0, "" o FALSE), no el valor de la entrada.

​
Eventos del Separador

Un Separador emite tres eventos de ciclo de vida:
  • entity consumed: se dispara cuando se consume la entrada (contexto de una sola entidad, la entrada)
  • entity created: se dispara para cada entidad de salida (contexto de una sola entidad, la salida). Solo este evento acepta un Entity Type Filter (opcional).
  • batch created: se dispara una vez que se producen todas las salidas (contexto multi-entidad, todas las salidas)

​
Interacción con la capacidad de la Estación

El linaje del Separador dentro de una estación suele malentenderse. El modelo correcto:
  • La entidad de entrada consume un slot de capacidad al entrar a la estación.
  • El Separador divide esa entrada en varias entidades de salida. Las salidas son descendientes de la entrada: comparten el linaje de la entrada.
  • El único slot se libera solo cuando todos los descendientes han salido de la estación. Si se produjeron tres salidas, el slot permanece ocupado hasta que las tres hayan salido.
Las salidas no consumen cada una su propio slot. Comparten el slot del ancestro mediante la regla de rastreo de linaje. Así que una estación con capacidad 5 puede alojar 5 entradas del Separador a la vez sin importar cuántas salidas produzca cada una, pero el slot de cada entrada permanece ocupado más tiempo si produce más salidas (porque la condición de “todos los descendientes han salido” tarda más en cumplirse).
Las claves de capacidad de la Estación tienen sentido solo para los tipos de entidad que entran. La ocupación se rastrea contra los tipos que entran a la estación: los tipos de salida creados internamente comparten el slot de su ancestro, así que una entrada de capacidad con clave en un tipo interno nunca entra en juego. Define la clave de capacidad sobre los tipos que realmente entran.

​
Transformador

Un Transformador consume su entidad de entrada y emite una entidad completamente nueva en su lugar, usualmente de un tipo distinto, aunque el tipo de salida también puede ser el mismo que el de la entrada (ver el patrón mutador de estado más abajo). El conteo de entidades no cambia (una entra, una sale), y la salida es genuinamente nueva: una entidad fresca que solo lleva los atributos que asignas explícitamente. Usa un Transformador de tipo distinto para modelar operaciones donde lo que se está trabajando se convierte en una cosa distinta después del procesamiento: materia prima → WIP, WIP → producto terminado, pieza en bruto → pintada, componente → componente inspeccionado.

​
Asignación de atributos en la salida

Un Transformador emite una entidad nueva de un tipo distinto, con su propia sección de Asignación de Atributos. Cada asignación usa el desplegable estándar Estrategia: elige Expresión DSL cuando el valor se calcula. Las asignaciones corren en contexto de una sola entidad con los atributos de la entidad de entrada accesibles y pueden referenciar:
  • Los atributos de la entidad de entrada: útil para transportar contexto hacia adelante
  • El estado de la simulación: SIM_TIME para marcar cuándo ocurrió la transformación
  • Variables de estado y constantes: para aplicar valores específicos de turno u operación
Los atributos de salida del Transformador no heredan de la entrada. Ningún atributo se transporta automáticamente. Cada atributo de salida que quieras debe asignarse explícitamente, típicamente como Expresión DSL referenciando el atributo de entrada por nombre (weight, priority, customer_id). Las asignaciones faltantes toman el valor cero del tipo por defecto, lo cual es pérdida silenciosa de datos.

​
Transformadores del mismo tipo: el patrón mutador de estado

El tipo de entidad de entrada y de salida en un Transformador pueden ser el mismo tipo. Esta es la forma canónica de mutar los atributos de una entidad a mitad de flujo. El ejemplo clásico es un bucle de reproceso: un Transformador del mismo tipo cuya asignación de salida define
le permite a un Enrutador aguas abajo limitar el bucle con una condición como rework_count < MAX_REWORK. Dos requisitos previos hacen que el patrón funcione:
  • Inicializa el contador en la Fuente. Cada tipo de entidad que puede entrar al bucle debe asignar el atributo (por ejemplo, rework_count = 0) en su Fuente, para que el primer incremento tenga un valor inicial definido.
  • Reasigna cada atributo que quieras conservar. Un Transformador del mismo tipo sigue siendo un Transformador: la salida es una entidad nueva, y los atributos no asignados vuelven a los valores por defecto del tipo, no a los valores de la entrada.

​
Eventos del Transformador

Un Transformador emite dos eventos de ciclo de vida:
  • entity consumed: la entrada siendo consumida
  • entity created: la salida siendo emitida
Ambos corren en contexto de una sola entidad. No hay evento de lote: el Transformador es estrictamente de 1 entra, 1 sale.

​
Cuándo usar un Transformador en lugar de un Proceso

Si todo lo que necesitas es “la entidad se retrasa X minutos, opcionalmente ocupando un recurso”, usa un Proceso. Usa un Transformador cuando:
  • El enrutamiento aguas abajo de la entidad depende de su tipo (se envía a distintos procesos según el tipo)
  • El análisis de resultados agrupa por tipo de entidad (throughput por producto, no agregado)
  • La entidad conceptualmente se convierte en algo distinto como parte de la operación
  • Necesitas mutar un atributo a mitad de flujo (el patrón mutador de estado del mismo tipo, arriba)
Un Transformador no consume tiempo de procesamiento por sí mismo: si la transformación toma tiempo real, combínalo con un Proceso previo.

​
Contextos del DSL en estos componentes

Cuatro de las siete superficies multi-entidad de la plataforma viven en Combinadores y Separadores: las asignaciones de atributo de salida del Combinador, la Expresión de Activación de Lote del Combinador, batch assembled del Combinador, y batch created del Separador. Las otras tres están en otros puntos del grafo de flujo: la cantidad de una acción release en un Búfer, buffer contents changed del Búfer, y station contents changed de la Estación. Cualquier otra superficie del DSL es sin entidad o de una sola entidad. Consulta Contextos de expresión.

​
Ubicación en una Estación

El Combinador, el Separador y el Transformador deben vivir dentro de una Estación: elígela en el campo Estación del componente. La validación falla para cualquiera de ellos sin una (la misma regla aplica a los Procesos). La Estación es lo que te da la contabilidad de ocupación y el comportamiento de capacidad basado en linaje descritos arriba.
Cuando la Estación contenedora no es una restricción física real, deja su capacidad en null (ilimitada) en lugar de inventar un número finito arbitrariamente grande. Una capacidad finita crea comportamiento de bloqueo incluso cuando el número parece seguro por lo alto que es.

​
Identidad de entidad a través de estos componentes

Los tres componentes acuñan una entidad nueva: la identidad a nivel de motor de la salida es distinta de la de la entrada. Eso es invisible cuando solo te importa el throughput agregado, pero rompe el rastreo por unidad (tiempo de espera por orden de trabajo, conteos de unidades distintas, rendimiento por lote) a menos que mantengas un atributo de identidad de negocio estable a través de cada transformación:
  1. Declara el atributo (work_order, lot_number, serial_no, …) en cada tipo de entidad de la cadena.
  2. Estámpalo en la Fuente que introduce la unidad.
  3. Reasígnalo en cada salida de Combinador, Separador y Transformador por la que pasa la unidad: como cualquier otro atributo de salida, no se transporta por sí solo.
La validación no verifica que una identidad sobreviva de principio a fin, así que enhebrar el atributo a través de cada costura es tu responsabilidad. Perder la identidad en una costura es el error más común que rompe el análisis en torno a estos componentes.
Los atributos Lista de Texto y Lista de Números no pueden asignarse mediante Expresión DSL. Cualquier identidad o valor que enhebres a través de un Combinador, Separador o Transformador con una expresión debe vivir en un atributo Texto o Número: los tipos lista rechazan la estrategia Expresión DSL en la validación, aunque el desplegable Estrategia la liste. Esto sorprende a quienes recurren a Lista de Texto porque un valor resulta ser una de unas pocas cadenas conocidas.

​
Event Hooks y Listeners

Los tres componentes llevan tanto una sección Event Hooks como una sección Event Listeners separada en el panel de configuración, igual que cualquier otro componente de flujo. Los listeners reaccionan a emisiones de temas y siempre corren en contexto sin entidad. Consulta el Sistema de eventos para el patrón completo.

​
Patrones

Celda de ensamblaje: Fuentes → Búferes → Combinador dentro de una Estación → Sumidero. Cada Fuente alimenta un tipo de componente distinto; el Lote de Entrada Estático del Combinador pide un tube, una tray y una label; la Estación modela la restricción del espacio de trabajo físico. Empaque de kits: Proceso (recoger componentes) → Combinador (agrupar en kit) → Proceso (sellar/etiquetar) → Sumidero. El Combinador produce la entidad kit; los procesos aguas abajo operan sobre kits. Desensamblaje para reproceso: Enrutador (envía aquí los candidatos a reproceso) → Separador (divide el kit de vuelta en componentes) → búferes de componentes individuales. Los atributos de cada salida se asignan explícitamente (rework_reason, original_kit_id). Línea de pintura: Fuente (piezas en bruto) → Proceso (pintar) → Transformador (raw_part → painted_part) → Proceso (inspeccionar) → Enrutador (enrutar por qc_passed). El cambio de tipo después de pintar permite que los procesos aguas abajo se especialicen en painted_part.

​
Consejos

  • Los Combinadores son donde vive la agregación. Si estás tratando de calcular una suma o un máximo a través de un grupo de entidades en cualquier otro lugar, probablemente estás peleando contra el modelo: reestructura para que la agregación ocurra en una salida de Combinador.
  • La capacidad basada en linaje es la razón por la que las estaciones con Combinadores o Separadores pueden comportarse de forma contraintuitiva. Los slots se consumen al entrar y se liberan cuando salen todos los descendientes de linaje, no según el tamaño del lote ni la aritmética del conteo de salidas.
  • Transformador sobre Proceso cuando el tipo importa aguas abajo. Los Procesos cambian el estado; los Transformadores cambian la identidad. Usa cada uno para su propósito.
  • El traspaso de atributos nunca es automático en Transformadores o Separadores. Cada atributo de salida deseado debe asignarse explícitamente.
  • El modo DSL del Combinador es para lotes con forma en tiempo de ejecución. Si tu tamaño de lote es constante, el modo Estático con una cantidad fija por tipo es más claro y más rápido.
  • Protege el atributo de identidad. Reasigna work_order (o cualquiera que sea tu clave de unidad) en cada salida de transformación; una costura olvidada corta la trazabilidad por unidad para todo lo que sigue aguas abajo.
  • Agrupa con un Búfer en modo de retención cuando los ítems permanecen individuales. Los viajes de ida y vuelta Combinador+Separador cuestan identidad y agregan joins al análisis; un release condicional en un Búfer no.