Cómo construir una cara de motor reutilizable con UDT y lógica HMI en OLLA Lab

Una cara de motor reutilizable es un objeto HMI único vinculado a un modelo de datos de motor estructurado en lugar de a etiquetas nombradas individualmente. En la práctica, una plantilla de cara puede servir para muchos motores, mientras que el mapeo basado en UDT reduce los errores manuales de etiquetas y puede hacer que la validación de pre-comisionamiento sea más fiable.

Copiar un gráfico de motor cincuenta veces no es reutilización. Es duplicación con mejor estética.

Cuando el control de motores escala, el mapeo de etiquetas planas se convierte en un riesgo para la puesta en marcha, ya que cada objeto copiado crea otra oportunidad para un cambio de nombre incorrecto, un enlace de estado roto o un comando de arranque apuntando al dispositivo equivocado. IEC 61131-3 proporciona la abstracción correcta a través de Tipos de Datos Definidos por el Usuario (UDT), y ISA-101 respalda objetos HMI reutilizables construidos en torno a modelos de información consistentes en lugar de gráficos ad hoc.

Un punto de referencia interno delimitado de OLLA Lab mostró el mismo patrón. En 1,200 escenarios de puesta en marcha de motores simulados, los usuarios que pasaron del mapeo de etiquetas booleanas planas a instancias de UDT estructuradas completaron la integración de lógica a HMI un 73% más rápido, con errores de mapeo cruzado reducidos a casi cero [Metodología: n=1,200 tareas de integración de cara de motor en OLLA Lab, comparador de referencia = etiquetas booleanas planas mapeadas manualmente, ventana de tiempo = 1 de enero de 2026 al 15 de marzo de 2026]. Esto respalda la afirmación de que los datos estructurados mejoraron la eficiencia de la integración en la tarea simulada definida aquí. No respalda una afirmación general sobre todas las plataformas PLC, todas las HMI o todos los resultados de puesta en marcha en campo.

En este artículo, "Listo para simulación" significa algo específico: un ingeniero puede probar, observar, diagnosticar y endurecer la lógica de control frente al comportamiento real del proceso antes de que llegue a un proceso en vivo. La sintaxis por sí sola es más barata que una llamada de servicio, pero no por mucho.

Los UDT son necesarios para el escalado de HMI porque convierten el comportamiento repetido del dispositivo en una estructura consistente y direccionable. Sin esa estructura, cada motor se convierte en un paquete de etiquetas personalizado y cada cara se convierte en un ejercicio de mapeo manual.

IEC 61131-3 define tipos de datos derivados, incluidas las estructuras, para que los datos de control relacionados puedan agruparse en un único objeto lógico. En el control de motores, ese objeto suele contener comandos, estados, alarmas, permisivos y valores de configuración. El beneficio de ingeniería no es estilístico. Es la reducción de la varianza en el mapeo.

Por lo tanto, una cara reutilizable debe definirse operacionalmente como un objeto gráfico vinculado a una instancia de motor estructurada, donde el objeto lee y escribe miembros de esa instancia sin ediciones de etiquetas codificadas por dispositivo. Si cambiar la estructura base o el comportamiento de la cara actualiza todas las instancias de manera consistente, el diseño es reutilizable. Si un ingeniero todavía tiene que renombrar veinte referencias internas a mano, es solo copiar y pegar con papeleo.

Etiquetas planas vs. datos estructurados

Las etiquetas planas escalan linealmente de la peor manera posible: multiplicando las oportunidades de error humano.

Patrón de etiquetas planas

• `Motor1_Start`
• `Motor1_Stop`
• `Motor1_RunFb`
• `Motor1_OL`
• `Motor1_Auto`
• `Motor1_FaultReset`

Patrón de UDT estructurado

• `Motor[1].Cmd_Start`
• `Motor[1].Cmd_Stop`
• `Motor[1].Sts_Running`
• `Motor[1].Alm_Overload`
• `Motor[1].Mode_Auto`
• `Motor[1].Cmd_Reset`

La distinción es simple:

• Las etiquetas planas se organizan por convención de nombres.
• Los datos estructurados se organizan por modelo de datos.

Las convenciones de nombres siguen siendo importantes, pero no sustituyen a la arquitectura. Un desorden disciplinado sigue siendo un desorden.

¿Qué estándares respaldan este enfoque?

La base de los estándares está establecida, aunque los detalles de implementación varían según el proveedor.

- IEC 61508 es relevante en el límite de riesgo: no le dice cómo dibujar una cara de motor, pero refuerza el principio más amplio de que los errores de diseño sistemáticos deben reducirse mediante métodos de ingeniería disciplinados.

• IEC 61131-3 define elementos de lenguaje de programación y conceptos de tipado de datos utilizados en el desarrollo de PLC, incluidos los tipos de datos estructurados.
• ISA-101 respalda prácticas de diseño de HMI que favorecen la consistencia, la claridad y el comportamiento de objetos reutilizables sobre pantallas decorativas únicas.

La afirmación del artículo es, por tanto, estrecha y defendible: las caras respaldadas por UDT son un patrón de diseño de sistema de control práctico alineado con los estándares de automatización establecidos y una práctica de escalado más segura.

Un UDT de motor estándar debe agrupar los datos necesarios para comandar, monitorear, alarmar y configurar un objeto de motor. Los miembros exactos varían según el proceso, pero la estructura debe reflejar el comportamiento observable del motor y las necesidades de la HMI, no solo la conveniencia del programador.

A continuación, se presenta una base compacta y reutilizable.

| Nombre del miembro | Tipo de datos | Dirección / Uso | |---|---|---| | `Cmd_Start` | BOOL | Comando de arranque de HMI a PLC | | `Cmd_Stop` | BOOL | Comando de parada de HMI a PLC | | `Cmd_Reset` | BOOL | Reinicio de falla de HMI a PLC | | `Mode_Auto` | BOOL | Selección de modo de HMI a PLC | | `Permissive_OK` | BOOL | Resumen de permisivos de PLC a HMI | | `Sts_Running` | BOOL | Retroalimentación de marcha de PLC a HMI | | `Sts_Stopped` | BOOL | Estado de parada de PLC a HMI | | `Sts_Faulted` | BOOL | Resumen de fallas de PLC a HMI | | `Alm_Overload` | BOOL | Alarma de sobrecarga de PLC a HMI | | `Alm_FailToStart` | BOOL | Falla de secuencia de PLC a HMI | | `Fb_Contactor` | BOOL | Retroalimentación de entrada de PLC | | `Cfg_StartDelay` | DINT o TIME | Preajuste de retardo de arranque | | `Cfg_StopDelay` | DINT o TIME | Preajuste de retardo de parada | | `Runtime_Seconds` | DINT | Acumulación de tiempo de marcha | | `Speed_Ref` | REAL | Referencia de velocidad analógica, si aplica | | `Current_Amps` | REAL | Indicación de corriente de motor analógica |

Esta estructura funciona porque separa la función por rol:

• Los Comandos son solicitudes del operador o de supervisión.
• Los Estados son indicaciones del estado de la máquina.
• Las Alarmas son indicadores de condiciones anormales.
• Los Valores de configuración son parámetros ajustables.
• Las Retroalimentaciones son confirmaciones del dispositivo o de campo.

Esa separación importa cuando las caras se vuelven más que botones bonitos. Una cara de motor es una interfaz de operador para un objeto con estado, no una pegatina colocada sobre bits aleatorios.

Ejemplo de definición de UDT

TYPE UDT_Motor_Standard : STRUCT Cmd_Start : BOOL; // Comando desde la cara HMI Cmd_Stop : BOOL; // Comando desde la cara HMI Cmd_Reset : BOOL; // Comando de reinicio de falla Mode_Auto : BOOL; // Selección de modo automático Permissive_OK : BOOL; // Todos los permisivos de arranque saludables Sts_Running : BOOL; // Retroalimentación de marcha Sts_Stopped : BOOL; // Estado de parada Sts_Faulted : BOOL; // Resumen de fallas Alm_Overload : BOOL; // Disparo por sobrecarga térmica Alm_FailToStart: BOOL; // Secuencia de arranque fallida Fb_Contactor : BOOL; // Retroalimentación física del contactor Cfg_StartDelay : DINT; // Preajuste de retardo de arranque (ms) Cfg_StopDelay : DINT; // Preajuste de retardo de parada (ms) Runtime_Seconds: DINT; // Acumulador de tiempo de marcha END_STRUCT END_TYPE

¿Qué debe incluirse en el UDT del motor y qué no?

El UDT debe incluir datos que pertenezcan al objeto del motor en sí. No debe convertirse en un cajón de sastre para lógica de proceso no relacionada.

Incluir

• Comandos del operador
• Estado del dispositivo
• Indicadores de alarma y falla
• Resúmenes de permisivos
• Configuración a nivel de dispositivo
• Valores analógicos a nivel de dispositivo cuando sea relevante

Evitar

• Banderas de secuenciación a nivel de línea no relacionadas
• Lógica de enclavamiento global que pertenece a otro lugar
• Valores cosméticos solo para HMI sin significado de ingeniería
• Etiquetas duplicadas que replantean el mismo estado con diferentes palabras

Un UDT inflado derrota el propósito. La reutilización depende de límites claros.

Se vincula un UDT a una cara de HMI pasando la etiqueta estructurada raíz a la cara y resolviendo todas las referencias internas en relación con ese objeto. A la cara no debería importarle si está mirando a `Motor_01` o `Motor_47`; solo debería importarle que el objeto suministrado se ajuste a la estructura esperada.

Conceptualmente, esto es parametrización de objetos. En el trabajo práctico de controles, es cómo una cara se convierte en muchas sin volverse frágil.

El proceso de vinculación de 3 pasos en OLLA Lab

OLLA Lab es útil aquí como un entorno de validación delimitado. Permite a los ingenieros ensayar la lógica de mapeo, inspeccionar los miembros de las etiquetas y probar la causa y el efecto antes de tocar una implementación de HMI o SCADA en vivo.

Cree etiquetas como:

• `Motor_01`
• `Motor_02`
• `Motor_03`

Vincule la instancia de la cara a `Motor_01`. Los elementos internos de la cara hacen referencia entonces a:

• `Cmd_Start`
• `Cmd_Stop`
• `Sts_Running`
• `Alm_Overload`

1. Definir el UDT en el Diccionario de Etiquetas Cree la estructura del motor con los miembros requeridos para comando, estado, alarma y configuración.
2. Instanciar objetos de motor Cada instancia utiliza el mismo UDT de motor como tipo de datos.
3. Mapear la cara a la etiqueta raíz en relación con el objeto raíz vinculado, no como etiquetas totalmente codificadas.

Aquí es donde OLLA Lab se vuelve operacionalmente útil. El Panel de Variables y el Diccionario de Etiquetas hacen visible la estructura, que es exactamente lo que necesita al verificar si un bit de comando, un bit de estado o un miembro de alarma está aterrizando realmente donde usted cree que está.

¿Qué significa "vinculación dinámica" en términos de ingeniería práctica?

La vinculación dinámica significa que la cara se escribe una vez y se suministra con un objeto de motor diferente cada vez que se instancia. La lógica interna y los estados visuales siguen siendo los mismos; solo cambia el objeto raíz referenciado.

En términos prácticos, eso le da:

• un comportamiento de botón de arranque,
• un comportamiento de botón de parada,
• un modelo de visualización de alarma,
• una lógica de color de estado,
• muchas instancias de motor.

Esa es la diferencia entre arquitectura de plantillas y dibujo de pantallas. Una escala. La otra acumula arrepentimiento.

La lógica de escalera debe organizarse de modo que el UDT refleje el comportamiento real del dispositivo, no solo la intención de la HMI. Un bit de comando de arranque en la cara no debe tratarse como prueba de que el motor arrancó. El peldaño debe seguir evaluando permisivos, enclavamientos, condiciones de secuencia y retroalimentación.

Un patrón de control de motor compacto suele incluir:

• una ruta de solicitud de arranque,
• una ruta de parada,
• comprobaciones de permisivos,
• una condición de sellado o marcha mantenida,
• validación de retroalimentación física,
• detección de fallas,
• enclavamiento de alarmas o generación de resúmenes.

A continuación se muestra un ejemplo mínimo en forma conceptual.

| Permissive_OK Cmd_Start Cmd_Stop_NC Alm_Overload_NC | |----] [------------] [-----------] [------------] [---------( ) Motor_Run_Cmd

| Motor_Run_Cmd Fb_Contactor | |----] [-------------] [------------------------------------( ) Sts_Running

| Motor_Run_Cmd NOT Fb_Contactor Start_Timer_DN | |----] [--------------] [-----------------] [----------------( ) Alm_FailToStart

La distinción importante es esta:

• Comando es lo que solicitó el operador.
• Estado es lo que probó el equipo.
• Alarma es lo que concluyó la lógica cuando la prueba falló.

Muchas caras malas difuminan esos tres en un icono verde alegre. La planta suele notarlo primero.

Usted valida la lógica de la cara probando si cada acción de la HMI produce la respuesta de escalera correcta y si cada estado de la escalera produce la indicación de HMI correcta tanto en condiciones normales como anormales. La validación no es "el botón cambió de color". La validación es causa y efecto trazables.

En OLLA Lab, eso significa usar:

• el Editor de Lógica de Escalera para inspeccionar la lógica de control,
• el Modo de Simulación para ejecutar y detener la lógica de forma segura,
• el Panel de Variables para observar los miembros de comando, estado y alarma en vivo,
• el comportamiento del escenario para comparar el estado de la escalera con la respuesta del equipo simulado.

Este es el lugar correcto para cometer errores, porque el simulador no energiza un contactor, inunda un pozo húmedo ni arranca el transportador equivocado. Las plantas en vivo son famosamente menos indulgentes.

La lista de verificación de validación mínima

Antes de considerar que la lógica de la cara está lista para la revisión de implementación, verifique al menos lo siguiente:

• La acción de arranque de la HMI establece el miembro de comando correcto.
• La instancia de motor correcta responde.
• Ninguna instancia de motor adyacente cambia de estado.

• La acción de parada de la HMI borra la condición de marcha correctamente.
• El comportamiento de parada coincide con la filosofía de control.

• `Sts_Running` cambia solo con prueba válida o lógica definida.
• La indicación de marcha no se controla directamente desde el bit de comando a menos que el diseño requiera explícitamente esa simplificación.

• Las condiciones de sobrecarga y falla al arrancar se muestran en la cara correcta.
• El comportamiento de reinicio de alarma es consistente con la lógica de escalera y la filosofía de la planta.

• El comportamiento manual/automático o local/remoto es visible y se aplica correctamente.

• Las acciones de la cara de `Motor_01` no afectan a `Motor_02`.
• La lógica de plantilla compartida no crea un estado de ejecución compartido por accidente.

Esa verificación final es menos glamorosa que los gráficos 3D, pero más útil a las 2:00 a. m.

1. Mapeo de comandos de arranque
2. Mapeo de comandos de parada
3. Indicación de estado
4. Indicación de alarma
5. Manejo de modos
6. Aislamiento de instancias

Prueba del comando de parada "normalmente cerrado"

La ruta de parada debe probarse explícitamente porque la semántica de parada a menudo se malinterpreta en simulaciones solo de HMI.

En muchos esquemas de control de motores, la condición de parada lógica se representa como una ruta de permisivo normalmente cerrada en escalera, lo que significa que la ruta de marcha permanece saludable hasta que una solicitud de parada, disparo, ruptura de cadena de parada de emergencia o enclavamiento la abre. Por lo tanto, el botón de parada de la HMI no "enciende la parada" de la misma manera que un botón de arranque enciende el arranque. Por lo general, interrumpe la condición de marcha mantenida o cae la ruta de comando.

Al validar este comportamiento:

• confirme que la acción de parada de la HMI rompe la condición de peldaño correcta,
• confirme que el estado del motor cae de acuerdo con la retroalimentación y la temporización de la secuencia,
• confirme que una parada de emergencia física o una cadena de seguridad cableada no se está simulando como un simple bit de HMI si la intención del diseño es diferente.

Esa distinción importa. Una parada de HMI es un comando de operador. Una cadena de parada de emergencia es una función de seguridad. No son intercambiables porque la pantalla se vea ordenada.

La evidencia correcta es un registro de ingeniería compacto, no una galería de capturas de pantalla.

Si desea demostrar competencia en el diseño de caras reutilizables, documente el trabajo en esta estructura:

Ejemplo: "Tres motores de transportador usando un UDT de motor estándar y una cara de HMI reutilizable".

Ejemplo: "Cada cara comandará solo su instancia de motor vinculada, mostrará una retroalimentación de marcha verdadera y mostrará alarmas de sobrecarga y falla al arrancar sin contaminación entre instancias".

Ejemplo: vincule `Motor_02.Sts_Running` a la cara de `Motor_01` y muestre la discrepancia resultante.

Ejemplo: repare la vinculación del objeto raíz y vuelva a probar todos los miembros de la cara.

Ejemplo: "Los miembros de estado deben derivarse de la prueba del dispositivo, no reflejarse desde los bits de comando".

Esto es lo que parece la evidencia de "Listo para simulación" en la práctica: no solo que escribió lógica, sino que la probó contra el comportamiento esperado y anormal, encontró un defecto y lo corrigió con un razonamiento trazable.

1. Descripción del sistema Defina el objeto del motor, el rol del proceso y el número de instancias.
2. Definición operativa de "correcto" Establezca los criterios de aceptación observables.
3. Lógica de escalera y estado del equipo simulado Muestre la lógica de peldaño relevante y el comportamiento del motor simulado correspondiente. Incluya bits de comando, bits de retroalimentación, permisivos y condiciones de alarma.
4. El caso de falla inyectada Introduzca deliberadamente una falla de mapeo o secuencia.
5. La revisión realizada Documente la corrección exacta.
6. Lecciones aprendidas Establezca qué falló, por qué falló y qué regla de diseño evita ahora la recurrencia.

OLLA Lab apoya este flujo de trabajo brindando a los ingenieros un entorno basado en web para construir lógica de escalera, inspeccionar etiquetas estructuradas, simular el comportamiento de E/S y comparar la lógica de control contra el estado del equipo virtual antes de la implementación. Eso importa porque los errores de integración de UDT-cara suelen ser baratos en la simulación y caros en la puesta en marcha.

Dentro del rol delimitado del producto, las capacidades útiles son específicas:

• el Editor de Lógica de Escalera apoya la construcción de la lógica del motor en sí,
• el Diccionario de Etiquetas apoya la creación y revisión de datos de motor estructurados,
• el Panel de Variables expone la visibilidad a nivel de miembro para comandos, estados, valores analógicos y alarmas,
• el Modo de Simulación permite la validación segura de causa y efecto,
• los flujos de trabajo basados en escenarios apoyan pruebas realistas en lugar de alternar bits abstractos.

Esto no debe exagerarse. OLLA Lab es un entorno de ensayo y validación para tareas de automatización de alto riesgo. No es un sustituto para FAT, SAT, revisión de seguridad funcional o competencia de puesta en marcha en sitio específica de la planta. Pero es exactamente el lugar correcto para practicar la disciplina de mapeo que los sistemas en vivo castigan.

Los errores más comunes son arquitectónicos, no gráficos.

Modos de falla comunes

Esto destruye la reutilización y multiplica las ediciones manuales.

• Vinculación a etiquetas individuales en lugar de a un objeto raíz

El motor no arrancó porque se presionó el botón. El equipo se basa molestamente en la evidencia.

• Uso de bits de comando como indicadores de estado

Esto hace que el objeto sea difícil de reutilizar en diferentes contextos.

• Mezcla de lógica a nivel de dispositivo y a nivel de línea en un mismo UDT

Las suposiciones de la cara se rompen cuando el modelo de datos se desvía.

• Nombres de miembros inconsistentes entre instancias

Una cara que funciona solo en el camino feliz no está validada.

• Ignorar las pruebas de estado anormal

Son funciones diferentes con diferentes implicaciones de riesgo.

• Tratar la parada de HMI y la parada de seguridad como la misma cosa

La corrección práctica

La corrección es el modelado de objetos disciplinado:

• defina un estándar de motor,
• vincule una cara a ese estándar,
• valide una instancia a fondo,
• luego replique mediante instanciación, no mediante edición manual.

Así es como debería funcionar el escalado en la ingeniería de controles: un patrón verificado, muchas repeticiones seguras.

Las caras de motor reutilizables dependen de datos estructurados, no de mejores hábitos de copiar y pegar. El movimiento de diseño central es vincular un objeto HMI a una instancia de UDT de motor para que los comandos, estados, alarmas y valores de configuración viajen como un objeto coherente.

Ese enfoque está respaldado por los principios de modelado de datos de IEC 61131-3 y por el énfasis de ISA-101 en el comportamiento consistente de los objetos HMI. También coincide con la realidad de campo: la mayoría de las fallas de cara no son fallas de dibujo, sino fallas de mapeo, prueba y disciplina de estado.

Utilizado correctamente, OLLA Lab proporciona un lugar delimitado para practicar esa disciplina. Los ingenieros pueden definir UDT, instanciar objetos de motor, vincular caras, ejecutar simulaciones, inyectar fallas y verificar que el motor virtual correcto responda antes de que cualquier proceso en vivo esté involucrado. Ese es el punto de la simulación en la formación en automatización: no el ensayo de sintaxis, sino la exposición controlada a errores que serían costosos en otros lugares.

Link UP: Domine la arquitectura más amplia en nuestro Centro de Maestría en Lógica de Escalera. Link ACROSS: Vea "Sellado" vs. "Enclavamiento": Por qué los ingenieros profesionales eligen cuidadosamente el comportamiento del peldaño detrás de los comandos de motor mantenidos. Link ACROSS: Lea Las reglas no escritas de la documentación de PLC: Convenciones de nombres que salvan vidas para la disciplina de nombres que respalda el escalado de UDT. Link DOWN: ¿Listo para probar esta arquitectura? Abra el Preajuste de Máquina de Estado de Mezclador Automatizado en OLLA Lab y practique la vinculación de etiquetas estructuradas al comportamiento del equipo simulado.

- Up (Pillar Hub): Explore la guía del pilar - Across: Artículo relacionado 1 - Across: Artículo relacionado 2 - Down (Commercial/CTA): Construya su próximo proyecto en OLLA Lab

- ANSI/ISA-101.01-2015 Diseño de HMI para automatización de procesos - Descripción general de seguridad funcional IEC 61508 - Informe del taller de gemelos digitales del NIST (NIST AMS 100-49) - Perspectivas de la industria manufacturera de Deloitte 2024