Cómo gestionar las extensiones de proveedores de PLC: UDT frente a USER_DEFINED en IEC 61131-3

La norma IEC 61131-3 estandariza los lenguajes de programación de PLC, no el comportamiento completo del tiempo de ejecución entre proveedores. Las estructuras de datos complejas, como las UDT, DUT y los tipos definidos por el usuario específicos de cada proveedor, siguen dependiendo de la implementación, especialmente en lo que respecta al diseño de memoria y al acceso a bloques. OLLA Lab proporciona un entorno de simulación acotado para practicar el mapeo de datos, la estructuración de etiquetas y la validación de lógica antes de la implementación específica del proveedor.

El cumplimiento de la norma IEC 61131-3 no es lo mismo que la portabilidad del código. La norma define familias de lenguajes y semánticas fundamentales, pero deja detalles importantes de tiempo de ejecución y memoria como dependientes de la implementación, que es precisamente donde suelen fallar las migraciones multiplataforma.

Una corrección práctica ayuda aquí: la mayoría de las migraciones fallidas no son causadas por el peldaño (rung) que arranca un motor. Son causadas por la estructura que lo envuelve. En un estudio comparativo interno de Ampergon Vallis, el 68% de los fallos de migración multiplataforma simulados estaban asociados con discrepancias en estructuras de datos definidas por el usuario anidadas, conflictos de relleno (padding) o suposiciones sobre el modelo de direccionamiento, en lugar de errores de sintaxis de lógica de contactos (ladder) [Metodología: n=512 tareas de migración simuladas que involucran estructuras de múltiples etiquetas y remapeo de E/S, comparador base = aceptación de ladder solo por sintaxis, ventana temporal = enero de 2025 a febrero de 2026]. Esto respalda una afirmación limitada: el modelado de datos es un punto de fallo principal en los ensayos de migración. No demuestra una tasa industrial universal.

Esa distinción es importante porque la sintaxis es fácil de admirar y difícil de implementar. El diseño de memoria es el problema más silencioso, y suele ser el que espera en la puesta en marcha.

La norma IEC 61131-3 estandariza los lenguajes de programación, no el comportamiento idéntico del proveedor. Define lenguajes como Diagrama de Contactos (LD), Diagrama de Bloques de Funciones (FBD), Texto Estructurado (ST), Diagrama de Funciones Secuenciales (SFC) y conceptos de tipos relacionados, pero permite un comportamiento dependiente de la implementación en áreas que afectan la ejecución, el almacenamiento y la interoperabilidad.

En la práctica, "dependiente de la implementación" no es una nota al pie. Es el lugar donde los proveedores toman decisiones diferentes sobre:

• alineación y relleno de datos,
• orden de bytes y convenciones de almacenamiento,
• acceso a memoria optimizado frente a absoluto,
• tratamiento del compilador de estructuras y tipos anidados,
• comportamiento retentivo,
• implementaciones de bloques de funciones específicas de la biblioteca.

Es por esto que dos controladores pueden describirse como conformes a la norma IEC 61131-3 y aun así no estar de acuerdo en cómo se almacena o direcciona una estructura compleja.

De ello se deriva una definición de ingeniería útil: la lógica portátil no es la lógica que compila en dos lugares; es la lógica cuyas suposiciones de datos, suposiciones de ejecución y suposiciones de interfaz sobreviven a ambos compiladores. Ese es un listón más alto de lo que implica la mayoría del lenguaje de marketing.

¿Qué deja abierto la norma realmente?

La norma deja espacio para la implementación específica del proveedor en varias áreas relevantes para las estructuras de datos y la interoperabilidad. Dependiendo de la edición y la documentación del proveedor, esto suele incluir:

• representación interna de tipos de datos,
• empaquetado y alineación de estructuras,
• métodos de acceso para variables y bloques,
• detalles de comportamiento de tareas y escaneo,
• extensiones de biblioteca y tiempo de ejecución.

El resultado es sencillo. Una declaración de tipo puede parecer estándar mientras que el comportamiento de memoria subyacente no lo es.

¿Por qué esto importa en un sistema en vivo?

Importa porque las interfaces externas no negocian con sus suposiciones. Un mapa de registros Modbus, un cliente OPC UA, una pantalla HMI o un intercambio entre PLC pares esperan una interpretación estable de los datos. Si un lado rellena un campo `BOOL` o reordena una estructura para un acceso optimizado, la lógica puede compilar, pero los datos del proceso pueden desplazarse por debajo.

Ese es el tipo de error que sobrevive a una revisión de código y aparece durante la puesta en marcha.

La diferencia clave no es solo el nombre. Es cómo cada proveedor vincula los tipos personalizados a la memoria, las reglas de acceso y el comportamiento de las herramientas.

Diferentes ecosistemas utilizan términos distintos para ideas ampliamente similares:

Desglose de terminología por proveedor

- Rockwell Automation (Studio 5000):

• Utiliza User-Defined Data Types (UDTs).
• Las UDT son fundamentales para el modelado de etiquetas en Logix.
• El comportamiento de la memoria y la alineación de los miembros siguen las reglas del compilador específicas del proveedor.
• Los integradores a menudo encuentran suposiciones de alineación al intercambiar datos empaquetados con sistemas que no son de Rockwell.

- Siemens (TIA Portal):

• Utiliza tipos de datos PLC y UDTs en el lenguaje de ingeniería común.
• El "acceso optimizado a bloques" puede cambiar la forma en que se organizan los datos internamente.
• Esto mejora la eficiencia dentro del entorno de Siemens, pero puede romper flujos de trabajo que dependen de desplazamientos absolutos fijos.
• Si un sistema externo espera direcciones fijas de estilo antiguo, el acceso optimizado no es útil.

- Plataformas basadas en Codesys, incluyendo Beckhoff y WAGO en muchas implementaciones:

• Comúnmente utilizan DUTs (Data Unit Types) declarados con `TYPE ... END_TYPE`.
• La sintaxis está estandarizada en estilo, pero el empaquetado en tiempo de ejecución y el comportamiento del destino siguen dependiendo de la plataforma y el compilador.
• La portabilidad entre destinos sigue siendo condicional, no automática.

- Otros entornos de proveedores:

• Pueden utilizar términos como `STRUCT`, `USER_DEFINED`, tipos de registro personalizados o modelos de objetos específicos de la plataforma.
• La diferencia de nomenclatura es menos importante que el comportamiento de almacenamiento y acceso resultante.

¿Cuál es la distinción operativa que los ingenieros deben tener en cuenta?

La distinción operativa es esta: un tipo definido por el usuario no es solo una conveniencia de nomenclatura; es un contrato sobre la forma de los datos, el orden de los miembros y las expectativas de acceso. Si dos sistemas no están de acuerdo con ese contrato, la lógica en torno a los datos se vuelve poco fiable incluso cuando el ladder en sí es perfectamente ordinario.

Aquí es donde los ingenieros suelen confundir la compatibilidad del lenguaje con la capacidad de despliegue. La primera es textual. La segunda es física.

El relleno de memoria rompe la lógica estandarizada al desplazar la ubicación esperada de los campos dentro de una estructura. La lógica puede seguir siendo sintácticamente válida, pero cualquier interfaz que asuma un diseño de byte o palabra diferente puede leer el valor incorrecto.

Considere esta declaración simplificada:

TYPE Motor_Control_DUT : STRUCT Start_Cmd : BOOL; ( puede tener relleno dependiendo del proveedor ) Speed_Ref : REAL; ( 32 bits ) Fault_Code : INT; ( 16 bits ) END_STRUCT END_TYPE

Esta declaración parece sencilla. No es universalmente sencilla en la memoria.

Un compilador puede colocar `Start_Cmd` en una ubicación de bit empaquetada y colocar `Speed_Ref` inmediatamente después del siguiente límite válido. Otro puede alinear el `REAL` en un límite de 32 bits e insertar relleno después del `BOOL`. Un tercero puede optimizar la estructura dentro de un bloque de una manera que hace que los desplazamientos absolutos sean inseguros para los consumidores externos.

Un modo de fallo concreto

Un modo de fallo común aparece en las comunicaciones basadas en registros.

• Un controlador emisor expone una estructura a un mapa Modbus TCP.
• El ingeniero asume que `Start_Cmd`, `Speed_Ref` y `Fault_Code` ocupan desplazamientos consecutivos esperados.
• El controlador receptor importa o reconstruye la misma estructura conceptual utilizando sus propias reglas de compilador.
• El `REAL` aterriza en un desplazamiento diferente porque la primera plataforma rellenó el campo `BOOL`.
• El lado receptor ahora lee datos de referencia de velocidad corruptos o interpreta parte del valor de punto flotante como un código de fallo.

El ladder puede ser "correcto" y la máquina puede seguir comportándose incorrectamente. Esa es la consecuencia práctica de la desalineación de datos.

¿Por qué los tipos anidados empeoran esto?

Las estructuras anidadas multiplican el riesgo porque cada estructura hija puede introducir su propio comportamiento de alineación. Un objeto de motor simple puede ser manejable. Un objeto de skid de proceso que contiene comandos, permisivos, alarmas, valores analógicos, parámetros PID y palabras de estado se vuelve mucho más frágil.

El patrón de fallo es predecible:

• una suposición incorrecta en el nivel de la estructura padre,
• una regla de alineación oculta en una estructura hija,
• un mapeo externo construido sobre desplazamientos absolutos,
• un largo día de puesta en marcha.

Las diferencias prácticas aparecen en cómo los ingenieros definen, acceden e intercambian datos estructurados.

Rockwell Automation

Las UDT de Rockwell se utilizan mucho para modelos de equipos reutilizables, pantallas HMI y organización de etiquetas adyacentes a AOI. En la práctica, los ingenieros a menudo diseñan en torno a estructuras de etiquetas Logix que son limpias dentro del ecosistema de Rockwell pero requieren un remapeo deliberado cuando se exponen a sistemas de terceros.

Las implicaciones prácticas incluyen:

• fuerte consistencia interna para proyectos Logix,
• uso frecuente en patrones de objetos de motor, válvula y dispositivo,
• cuidado necesario al mapear a protocolos externos o consumidores que no son de Rockwell,
• suposiciones de alineación y empaquetado que deben verificarse, no adivinarse.

Siemens

Siemens introduce una distinción importante entre el acceso de estilo estándar y el acceso optimizado a bloques. El acceso optimizado puede mejorar el uso de la memoria y el rendimiento interno, pero reduce la transparencia de las direcciones para los sistemas externos que esperan desplazamientos fijos.

Las implicaciones prácticas incluyen:

• manejo interno eficiente de datos estructurados,
• menor fiabilidad de las antiguas suposiciones de direcciones absolutas,
• necesidad de decidir explícitamente si tiene prioridad la interoperabilidad externa o la optimización interna,
• precaución adicional al integrar HMI, historiadores o PLC pares que esperan direcciones estables.

Codesys y plataformas relacionadas

Las DUT al estilo Codesys ofrecen un modelo de declaración de tipos familiar y flexible. Son potentes para la ingeniería estructurada, las bibliotecas reutilizables y la abstracción de máquinas. Sin embargo, no son una garantía de que otro destino almacenará la misma estructura de forma idéntica.

Las implicaciones prácticas incluyen:

• sintaxis de declaración de tipos clara,
• portabilidad dentro de las suposiciones acotadas de la plataforma,
• diferencias de tiempo de ejecución específicas del destino que siguen siendo relevantes,
• necesidad de verificación explícita al cruzar los límites del proveedor.

La migración de PLC de "copiar y pegar" suele fallar porque el software de control industrial está acoplado al comportamiento del hardware, los modelos de memoria, las convenciones de E/S, las suposiciones de escaneo y las herramientas del proveedor. La lógica es solo una capa del sistema.

Una migración normalmente requiere que los ingenieros reconcilien al menos cinco cosas:

- Sistemas de tipos: las convenciones de UDT, DUT, struct y bloques difieren. - Modelos de direccionamiento: los diseños absolutos, simbólicos, optimizados y expuestos por protocolo difieren. - Comportamiento de las instrucciones: los temporizadores, contadores, bloques PID y funciones de biblioteca no siempre son semánticamente idénticos. - Vinculación de E/S: los dispositivos de campo, el escalado y los bits de diagnóstico son específicos de la plataforma. - Suposiciones de puesta en marcha: la secuencia de arranque, el comportamiento de reinicio de fallos y el manejo de permisivos a menudo están codificados en patrones nativos del proveedor.

Así que la versión honesta es esta: no existe una "migración de copiar y pegar" industrial en la que valga la pena confiar en un proceso en vivo. Solo existe la traducción, la verificación y la reducción de riesgos.

Simulation-Ready debe definirse de forma operativa, no aspiracional. Un ingeniero listo para la simulación puede probar, observar, diagnosticar y endurecer la lógica de control frente al comportamiento realista del proceso antes de que esa lógica llegue a un proceso en vivo.

Para el trabajo de estructuras de datos multiplataforma, eso significa que el ingeniero puede:

• definir etiquetas estructuradas y miembros anidados claramente,
• rastrear la causa y el efecto entre el estado del ladder y el estado del equipo,
• verificar el comportamiento esperado en condiciones normales y anormales,
• identificar dónde las suposiciones de datos dependen de reglas de empaquetado o acceso específicas del proveedor,
• revisar la lógica o el mapeo después de un fallo inyectado,
• documentar qué significa "correcto" antes de la implementación.

Eso es diferente de simplemente ser capaz de escribir un peldaño. La sintaxis es necesaria. No es la línea de meta.

Este marco se alinea con la literatura de ingeniería más amplia sobre validación basada en simulación, el uso de gemelos digitales en sistemas industriales y la verificación previa a la implementación como medida de reducción de riesgos en entornos de automatización complejos (por ejemplo, Fuller et al., 2020; Jones et al., 2020; y los principios de la norma IEC 61508 sobre reducción sistemática de riesgos).

OLLA Lab ayuda al proporcionar a los ingenieros un entorno acotado para ensayar el diseño de etiquetas estructuradas, la simulación y la validación consciente de fallos antes de pasar a las restricciones del IDE específicas del proveedor. No es un traductor de código universal, y no debe tratarse como tal.

Su valor aquí es más limitado y más creíble: permite a los ingenieros practicar el hábito de ingeniería que el trabajo de migración realmente requiere.

Lo que OLLA Lab está haciendo en este flujo de trabajo

Dentro del alcance documentado del producto, OLLA Lab proporciona:

• un editor de lógica ladder basado en web,
• modo de simulación para ejecutar y detener la lógica,
• un Panel de Variables para monitorear y ajustar etiquetas, E/S, valores analógicos y estados relacionados,
• ejercicios industriales basados en escenarios,
• contextos de simulación al estilo de gemelos digitales para validar el comportamiento frente a equipos modelados.

Para el caso de uso de este artículo, el Panel de Variables es lo más importante porque permite a los ingenieros definir e inspeccionar variables estructuradas en un entorno agnóstico al hardware antes de enfrentarse a las reglas de compilación y mapeo específicas del proveedor.

Qué significa "agnóstico al proveedor" aquí

Agnóstico al proveedor no significa implementación sin proveedor. Significa que el entorno de práctica no está obligando al estudiante a aprender las reglas de memoria de Rockwell, Siemens y Codesys todas a la vez mientras aprende también causalidad, secuenciación y arquitectura de etiquetas.

Esa separación es útil porque los principiantes y los ingenieros junior a menudo fallan por dos razones a la vez:

• aún no entienden el comportamiento del control,
• y ya están enterrados en detalles específicos de la plataforma.

El flujo de trabajo consiste en modelar primero el comportamiento del control, luego modelar la forma de los datos y, finalmente, validar la causalidad bajo simulación.

### Paso 1: Definir la lógica de control cruda

Construya la lógica ladder en el editor utilizando el conjunto de instrucciones requerido para el escenario:

• contactos y bobinas,
• temporizadores y contadores,
• comparadores y bloques matemáticos,
• elementos analógicos y PID cuando sea relevante.

En esta etapa, céntrese en la secuencia y la causalidad. Una cadena de permisivos de arranque de motor debe comportarse correctamente antes de preocuparse por cómo un proveedor específico rellenará una estructura hija.

### Paso 2: Construir las etiquetas estructuradas en el Panel de Variables

Utilice el Panel de Variables para crear un modelo de etiquetas anidadas que refleje el objeto del equipo o proceso. Por ejemplo:

• `Motor_Status.Running`
• `Motor_Status.Faulted`
• `Motor_Command.Start`
• `Motor_Command.Stop`
• `Motor_Analog.Speed_Ref`
• `Motor_Alarm.Overload`

Aquí es donde OLLA Lab se vuelve operativamente útil. El ingeniero puede practicar la disciplina de nomenclatura, agrupar miembros relacionados con la lógica y observar cómo el estado del peldaño se mapea al estado del equipo.

### Paso 3: Simular y observar los cambios de estado

Ejecute la simulación y alterne las entradas mientras observa las salidas y las variables.

Compruebe:

• transiciones esperadas,
• permisivos fallidos,
• comportamiento de la alarma,
• respuesta analógica,
• temporización de la secuencia,
• discrepancia entre el estado previsto y el comportamiento real de la etiqueta.

Una buena sesión de simulación responde a una pregunta sencilla: cuando el proceso cambia, ¿la lógica cambia por la razón correcta?

### Paso 4: Inyectar una condición anormal

Introduzca un caso de fallo como:

• retroalimentación de prueba fallida,
• disparo por alto-alto analógico,
• pérdida de permisivo durante la ejecución,
• confirmación de arranque retrasada,
• estado de comando obsoleto.

El propósito es verificar que la estructura y la lógica sigan teniendo sentido cuando el proceso deja de cooperar.

### Paso 5: Revisar la lógica y documentar las suposiciones de mapeo

Ajuste el ladder, la agrupación de etiquetas o el manejo de estados después de que aparezca el fallo. Luego registre qué suposiciones son portátiles y cuáles necesitarán un tratamiento específico del proveedor más adelante.

Ese paso final es la diferencia entre la práctica y la evidencia.

Un ingeniero junior debería construir un cuerpo compacto de evidencia de ingeniería que demuestre razonamiento, validación y revisión. Las capturas de pantalla son artefactos de apoyo. No son el argumento.

Utilice esta estructura:

Establezca qué significa el comportamiento correcto en términos observables. Ejemplo: "La bomba arranca solo cuando la habilitación principal, el disparo por baja succión están claros y el comando de arranque remoto son verdaderos; los fallos se enclavan hasta que se reinician".

1. Descripción del sistema Defina la máquina o el objeto de proceso, su propósito, estados principales y E/S clave.
2. Definición operativa de "correcto"
3. Lógica ladder y estado del equipo simulado Muestre los peldaños relevantes y los cambios de estado simulados correspondientes en etiquetas, salidas o equipos modelados.
4. El caso de fallo inyectado Describa la condición anormal introducida y por qué es importante operativamente.
5. La revisión realizada Explique qué cambió en la lógica, la estructura de etiquetas o el manejo de secuencias después de observar el fallo.
6. Lecciones aprendidas Registre la conclusión de ingeniería, especialmente donde el modelado de datos, la secuenciación o las suposiciones de interfaz crearon riesgo.

Este formato es útil en la formación porque demuestra juicio de puesta en marcha, no solo alfabetización en diagramas. Los empleadores no necesitan más capturas de pantalla de bits verdes. Necesitan evidencia de que el ingeniero puede pensar cuando el proceso no está de acuerdo.

La validación de gemelos digitales es útil cuando se define como la comprobación del comportamiento frente a un modelo de máquina o proceso realista antes de la implementación. No es útil cuando se trata como un escenario 3D decorativo adjunto a una lógica no probada.

En un entorno de formación acotado como OLLA Lab, la simulación al estilo de gemelos digitales ayuda a los ingenieros a comparar:

• estado del ladder,
• estado de E/S,
• comportamiento analógico,
• progresión de la secuencia,
• y respuesta del equipo modelado.

Esa comparación importa porque los fallos de puesta en marcha suelen ser relacionales. El peldaño se ve bien de forma aislada. La secuencia del proceso no.

La investigación sobre gemelos digitales industriales y la ingeniería basada en simulación ha respaldado constantemente el valor de la validación virtual para reducir el riesgo de integración en etapas tardías, mejorar la comprensión del sistema y apoyar la formación de operadores o ingenieros cuando se define correctamente el alcance (Fuller et al., 2020; Tao et al., 2019). La guía de seguridad funcional también refuerza el principio más amplio de que los fallos sistemáticos deben encontrarse lo antes posible mediante un diseño y una verificación disciplinados en lugar de descubrirlos en la planta (IEC 61508; exida, 2024).

La traducción al campo es sencilla: si un fallo puede encontrarse antes de la puesta en marcha, ese es el momento correcto para encontrarlo.

Los ingenieros deben tratar a OLLA Lab como un entorno de ensayo, luego realizar una traducción y verificación explícitas específicas del proveedor antes de la implementación.

Utilice esta lista de verificación de entrega:

• confirme el sistema de tipos y las convenciones de nomenclatura de la plataforma de destino,
• verifique el comportamiento de empaquetado y alineación de la estructura,
• decida si los sistemas externos requieren direccionamiento fijo,
• revise la configuración de acceso a bloques optimizado frente a estándar,
• mapee explícitamente los datos expuestos por protocolo,
• valide el escalado analógico y las unidades de ingeniería,
• compare el comportamiento del temporizador, contador y PID frente a la semántica del destino,
• vuelva a ejecutar los casos de fallo en el entorno del proveedor,
• documente cualquier suposición que haya cambiado durante la traducción.

Este es el camino disciplinado desde la simulación hasta la implementación. Es más lento que las ilusiones y más rápido que una mala puesta en marcha.

- IEC 61131-3: Controladores programables — Parte 3 - Familia de normas de seguridad funcional IEC 61508 - Recursos de validación y seguridad funcional de exida - Recomendación de señalización de estado NAMUR NE 107 - Gemelo digital en la industria: estado del arte (DOI)