Nodos de modelo y modelado jerárquico

​

Visión general

Un Nodo de modelo es un componente que incrusta otro modelo de simulación dentro del modelo actual. En lugar de duplicar componentes en muchos modelos, defines un submodelo una vez (una celda de producción, una línea de ensamblaje, un departamento) y lo incrustas donde lo necesites. Los cambios en el submodelo se propagan a todos los lugares donde se usa. Esta es la arquitectura para plantas complejas: modela una sola celda con rigor, compón un departamento a partir de copias de esa celda, compón una planta a partir de copias del departamento. Sin el modelado jerárquico, una operación compleja implica miles de componentes en un solo lienzo. Con él, obtienes una descomposición limpia que refleja cómo está organizada realmente tu operación. Si eres nuevo construyendo modelos, empieza por Resumen de la simulación: esta página cubre la capa de composición que se apoya sobre los fundamentos de los componentes.

​

Cuándo usar Nodos de modelo

• Estructura física repetida: tu planta tiene cinco celdas de producción idénticas. Modela una y luego incrústala cinco veces mediante Nodos de modelo.
• Plantillas reutilizables: subprocesos estándar (inspección de calidad, empaque, kitting) que aparecen en muchos modelos. Defínelos una vez y reutilízalos en cada modelo de la fábrica que los importe.
• Escala: una vez que un modelo supera entre 50 y 100 componentes, la descomposición jerárquica se vuelve la única forma de mantenerlo navegable.
• División de equipo: una persona es dueña del submodelo a nivel de línea, otra es dueña de la composición a nivel de planta. Los Nodos de modelo les permiten trabajar en paralelo.

​

Cómo se agrega un Nodo de modelo

Un Nodo de modelo coloca un modelo distinto que ya existe en la misma fábrica. Agregar uno toma dos pasos: importar el modelo y luego arrastrarlo al lienzo.

1. Importa el submodelo. En el panel izquierdo del Modelador, abre la vista Vista general y busca la sección Submodelos. Haz clic en el + en el encabezado de la sección (o en la fila Importar Modelo cuando aún no se ha importado nada) y elige uno de los otros modelos de la fábrica. Aparece como una fila en la sección.
2. Colócalo en el lienzo. Abre el botón Submodelo en el dock del lienzo. Lista los modelos que has importado; arrastra uno al lienzo. Aparece un Nodo de modelo que hace referencia a ese submodelo.

El botón Submodelo del dock solo aparece una vez que el modelo ha importado al menos un submodelo. Para quitar una importación, usa el × (Quitar del modelo) de la fila en la sección Submodelos. Está deshabilitado mientras un Nodo de modelo siga usando ese submodelo.

​

Configurar un Nodo de modelo

Un Nodo de modelo es una referencia delgada: la mayor parte de lo que hace vive en el submodelo. Selecciona el nodo en el lienzo para abrir sus Propiedades:

​

Conexiones mapeadas

Los mapeos de entrada y salida son la capa de conexión. Cuando dibujas una conexión hacia un Nodo de modelo, ProDex pregunta qué entrada del submodelo debe recibir los ítems: eliges una de las Fuentes del submodelo. Cuando dibujas una conexión desde un Nodo de modelo, eliges cuál de los Sumideros del submodelo envía ítems al componente aguas abajo. Las secciones Mapeos de Entrada y Mapeos de Salida en las propiedades del nodo muestran cada mapeo y te permiten cambiarlo. La validación exige esto: un mapeo de entrada debe apuntar a una Fuente dentro del submodelo, y un mapeo de salida a un Sumidero. Las entidades que llegan por un mapeo de entrada ingresan al submodelo en esa Fuente; las entidades que llegan al Sumidero mapeado cruzan de vuelta hacia el padre. Puedes cambiar la estructura interna del submodelo sin romper el padre: mientras las Fuentes y Sumideros mapeados sigan existiendo dentro, el modelo padre sigue funcionando.

​

Recursos compartidos

Un Recurso puede compartirse entre un padre y un submodelo con una entrada de Mapeos de Recursos (Agregar Mapeo de Recurso). Cada entrada empareja el recurso que pide el submodelo con el recurso del padre del que debe alimentarse en su lugar: el alias apunta desde el recurso interno del submodelo hacia afuera, a un recurso del padre. Los recursos sin mapear permanecen locales al submodelo: si no lo mapeas, el submodelo usa su propio recurso. El modelo mental útil es de adentro hacia afuera, por instancia: cada entrada de mapeo reemplaza uno de los recursos internos del submodelo por un recurso del padre. Como el enlace vive en la instancia del Nodo de modelo (no en el submodelo), el mismo submodelo instanciado cinco veces puede vincular cada instancia a un recurso padre distinto: cinco celdas que comparten una cuadrilla de mantenimiento, o cada una alimentándose de su propio grupo de operadores. Usa recursos compartidos para operadores o equipos que sirven físicamente a varias celdas.

​

Temas conectados

Los Temas pueden conectarse a través del límite padre/hijo con Mapeos de Temas. La conexión es siempre bidireccional: no hay configuración por dirección. Un evento emitido dentro del submodelo en un tema conectado se recibe en el padre, y viceversa.

​

Variables de estado con alias

Las Variables de Estado pueden recibir un alias: una variable de estado declarada a nivel del padre puede referenciarse desde dentro del submodelo bajo un nombre distinto con Mapeos de Variables de Estado. El alias es de lectura/escritura bidireccional: ambos lados ven y escriben el mismo valor subyacente. Una variable anidada con alias delega al padre: en los conjuntos de datos de resultados no emite una fila de valor inicial propia en t=0; la variable del padre es la única fuente de verdad. Esto mantiene los submodelos desacoplados (referencian sus propios nombres internos) a la vez que les permite participar en el estado a nivel del padre.

​

Las constantes y tablas de búsqueda no necesitan mapeo

Las Constantes y las tablas de búsqueda están delimitadas a la fábrica. Tanto el padre como el submodelo las referencian de forma independiente: no hay mapeo para esto en un Nodo de modelo. Cada modelo agrega las que usa en sus propias secciones Constantes y Tablas de búsqueda de la Vista general, de modo que el padre y el submodelo pueden usar la misma constante a nivel de fábrica sin coordinarse.

​

Rutas de componentes calificadas

Los componentes dentro de un Nodo de modelo se direccionan mediante una ruta calificada que usa :: como separador. Un componente con id lathe dentro de un ModelNode con id cell_a se referencia como cell_a::lathe en cualquier lugar fuera de su submodelo padre (la misma forma que verás en el SQL de origen de las vistas de gráficos y en las columnas de los conjuntos de datos). Todos los segmentos son ids de componente, no nombres visibles. El separador :: está reservado, así que ningún id de componente puede contenerlo. Los ids de componente están espaciados de nombres por modelo: el mismo id puede existir legítimamente tanto en el padre como en un submodelo (lathe en el nivel superior y cell_a::lathe dentro de una celda son componentes distintos). La calificación con :: es lo que los distingue. Esto se aplica en tres lugares:

• Consultas de origen de las vistas de gráficos. Los identificadores de componente en entity_movements, process_activity, resource_activity y otros dataframes usan la forma calificada: es lo que verás en component_lookup.component_id, process_id, resource_id, variable_name y el component_id en las filas de eventos/hooks. Filtrar por el nombre visible tal como aparece en el Modelador (digamos, component = 'Lathe') omite cada instancia dentro de un Nodo de modelo. Usa component = 'cell_a::lathe', o compara con LIKE.
• Liberaciones de material en la programación. Una liberación de material programada puede apuntar a un Búfer dentro de un submodelo, pero no a una Fuente: una Fuente dentro de un submodelo recibe entidades a través de su Nodo de modelo padre, así que una liberación dirigida a ella falla la validación aunque el Editor de Programación la liste. En el desplegable de componentes del Editor de Programación, los componentes dentro de Nodos de modelo se listan después de un divisor, debajo de los de nivel superior.
• Referencias entre límites en las funciones de consulta de componentes del DSL: pasa el id calificado cuando el componente que consultas vive en un submodelo.

Escribir hooks y listeners dentro del submodelo usa ids de componente locales: el prefijo calificado solo es necesario al cruzar el límite padre-hijo. Los submodelos siguen siendo reutilizables; no necesitan saber qué nombre les dio su padre. Para estructuras profundamente anidadas, las rutas se encadenan: plant_1::line_3::cell_2::lathe.

​

Compatibilidad del Nodo de modelo con el sistema de eventos

Los Nodos de modelo pueden tener Event Listeners (basados en temas) y funcionan por completo: escuchan cualquier tema en el padre o conectado al submodelo, y ejecutan assign / emit / etc. como cualquier otro listener. Útiles para la coordinación a nivel de Nodo de modelo que no está atada a un solo componente interno. La sección Event Listeners aparece en las propiedades del nodo una vez que el modelo tiene al menos un tema. Los Nodos de modelo no admiten Event Hooks. Un Nodo de modelo no tiene eventos de ciclo de vida, así que sus propiedades no muestran sección de Event Hooks, y la validación rechaza cualquier hook en un Nodo de modelo. Para reaccionar a algo que ocurre dentro del submodelo, coloca el hook en el componente dentro del submodelo y conecta un tema hacia afuera.

​

La validación recorre los límites

Cuando validas el modelo padre, la validación recorre cada modelo anidado referenciado por un Nodo de modelo. Los errores dentro de un submodelo suben hasta el padre con el prefijo de la ruta del nodo de modelo, así que una expresión rota en el torno de cell_a aparece en el padre como un error atribuido al modelo anidado en lugar de pasar en silencio. Corrige el error en el submodelo; el padre se revalida automáticamente.

​

Referencia en vivo, no una copia

Un Nodo de modelo referencia su submodelo en vivo. Cualquier cambio que hagas en el submodelo se refleja de inmediato en cada Nodo de modelo que lo referencia: no hay fijación de versión a nivel del Nodo de modelo. Si necesitas conservar una revisión específica de un submodelo, pídele a Dexter que copie el submodelo antes de cambiarlo.

​

Crear Nodos de modelo con Dexter

El editor visual no es el único punto de entrada. Pídele a Dexter que componga una jerarquía por ti: puede construir los submodelos, colocar Nodos de modelo en el padre y conectar sus mapeos de conexión, recursos y temas. El submodelo debe estar guardado en la fábrica antes de que un Nodo de modelo pueda referenciarlo. Dexter también puede trabajar en un subsistema a la vez: extraer un submodelo en cualquier nivel de la jerarquía, cambiarlo y volver a aplicarlo, de modo que un modelo a escala de planta se mantenga editable pieza por pieza.

​

Modelos anidados en los datos de resultados

La jerarquía se aplana en el momento de la simulación, pero los cruces de límites siguen siendo visibles en los dataframes de resultados:

• Cada cruce de límite registra cuatro filas en entity_movements: padre → fuente anidada (sintética), fuente anidada → primer componente interno (real), último componente interno → sumidero anidado (real), y sumidero anidado → padre (sintética). Filtra frontier_synthetic = false cuando solo quieras los saltos reales: excluir las filas sintéticas igual deja dos filas donde un modelo plano registraría una.
• continued_to_parent vive en entity_lifecycle: en las filas terminadas en un sumidero de salida anidado, distingue una terminación real dentro del submodelo de una entidad que cruza de vuelta hacia el padre. Filtra NOT COALESCE(continued_to_parent, FALSE) al contar terminaciones reales. (No confundas los dos conjuntos de datos: los cruces de movimiento están en entity_movements, las terminaciones de ciclo de vida en entity_lifecycle.)
• entity_id cambia en cada Combinador, Separador y Transformador. Si un submodelo envuelve una transformación, la entidad que sale no es la entidad que entró: lleva un atributo de identidad de negocio estable (un número de orden, un número de serie) si necesitas rastrear una unidad a través del límite.
• Las variables de estado con alias no emiten fila de valor inicial en t=0 (delegan al padre), y los temas conectados registran dos filas por emisión (origen + entrega conectada).

​

Patrones comunes

Plantilla de celda. Un submodelo de “celda de producción” se crea una vez con el equipo canónico. El modelo de la planta lo instancia cinco veces mediante Nodos de modelo, cada uno apuntando al mismo submodelo. Composición de departamentos. Construye un modelo de “fabricación” y un modelo de “ensamblaje” por separado, y luego compónlos en un modelo de planta con conexiones entre sus salidas y entradas. Detalle progresivo. Empieza con un modelo de planta a grandes rasgos, unos pocos Nodos de modelo, cada uno representando un departamento como una caja negra. A medida que necesites más fidelidad, agrega detalle dentro del submodelo de un departamento. El padre no cambia.

​

Consejos

• Trata los submodelos como bibliotecas. Una vez que un submodelo es estable, evita editarlo a la ligera: los cambios se propagan a cada instancia.
• Nombra con claridad las Fuentes y Sumideros del submodelo. Son lo que eliges al mapear conexiones; los nombres claros evitan errores de conexión.
• Mantén el nivel superior delgado. Un modelo de planta bien organizado es en su mayoría Nodos de modelo con un poco de conexión entre ellos. Si tu nivel superior tiene cientos de componentes directos, estás perdiendo el beneficio.
• Todos los segmentos de ruta son ids, no nombres visibles. Si tienes dudas sobre un id, revisa las columnas del conjunto de datos: los nombres visibles con espacios no aparecen en las rutas con ::.
• Anidar no oculta la procedencia. Los valores marcados como Datos, Indicado o Asumido en el panel de Evidencia conservan esa marca dentro de los submodelos exactamente igual que en el nivel superior, y una revisión de supuestos cubre cada modelo anidado: una suposición enterrada tres niveles abajo igual sale a la superficie.
• Las programaciones alcanzan el interior. Una liberación de material puede apuntar a un Búfer dentro de un submodelo.