Bytinkers · PLC/IEC 61131-3

UDT y AOI en PLC: modularidad, rendimiento y mantenibilidad en automatización

Los UDT (User-Defined Data Types) y las AOI (Add-On Instructions) permiten encapsular datos y lógica como “bloques reutilizables”. El resultado: proyectos más ordenados, reducción de errores, menor tiempo de puesta en marcha y una base sólida para escalar la automatización.

Introducción

En muchos proyectos PLC, los tags se crean “a mano” y la lógica se duplica por todas partes. Eso complica el troubleshooting, ralentiza el commissioning y vuelve frágil el mantenimiento. Los UDT y las AOI resuelven ese caos con un enfoque modular: ordenan los datos, encapsulan funciones y permiten estandarizar equipos y celdas.

Adoptarlos implica un cambio de mentalidad: pensar en objetos de planta (motores, bombas, tanques, ejes, recetas, etc.) con su estructura de datos y su comportamiento, en lugar de listas sueltas de tags y rungs copiados.

UDT: concepto y ventajas

Un UDT es un tipo de dato definido por el usuario que agrupa miembros relacionados (por ejemplo, PV, SP, EnAuto, Alarma, Estado). A partir de ese molde creas múltiples instancias coherentes, con nombres y documentación consistentes.

  • Orden y consistencia: todas las instancias comparten la misma estructura (evita “tags huérfanos”).
  • Mejor mapeo HMI/SCADA: el frente de HMI se vuelve casi automático cuando los datos están normalizados.
  • Documentación acelerada: descripciones heredadas y convenciones de nombrado reducen tiempo de documentación.
  • Escalabilidad: arrays de UDT permiten manejar decenas o cientos de equipos con patrones uniformes.

Ejemplo conceptual: Tank_UDT con miembros: PV, SP, LevelHi, LevelLo, FillValve.Cmd/FBk, DrainValve.Cmd/FBk, Alarms, Mode, Interlocks, Timestamp.

AOI: concepto y ventajas

Una AOI encapsula lógica reutilizable y se usa “como una instrucción nativa”. Define parámetros de entrada/salida (Input/Output/InOut), variables internas y rungs propios. Luego instancias la AOI donde la necesites, con su propia memoria y estado.

  • Reutilización real: un diseño, múltiples instancias (motor estándar, bomba, eje, PID extendido, etc.).
  • Mantenibilidad: un único punto de verdad para la lógica estándar mejora control de cambios y revisión.
  • Rendimiento: el paso de parámetros y la encapsulación suelen ser más eficientes y ordenados que llamadas genéricas a subrutinas repetidas.
  • Integración HMI: es más fácil construir faceplates/plantillas HMI coherentes por instancia.

Nota de ciclo de vida: las AOI conviene versionarlas y “sellarlas” (firma) cuando estén validadas. Evita cambios online sin proceso; usa entornos de prueba.

UDT vs AOI: comparación rápida

Aspecto UDT (User-Defined Data Type) AOI (Add-On Instruction)
Qué son Estructuras de datos personalizadas. Bloques de lógica reutilizables con parámetros.
Beneficio principal Orden, consistencia y mapeo claro a HMI. Encapsulación de funciones y estandarización de control.
Cuándo usar Cuando un “objeto” de planta requiere un layout de datos repetible. Cuando la misma lógica/algoritmo se repite en varios equipos.
Impacto HMI/SCADA Faceplates más simples; binding consistente. Faceplates por instancia; estados/diagnósticos homogéneos.
Rendimiento Sin lógica; depende de su uso (tamaño/arrays). Suele ser eficiente vs subrutinas duplicadas; depende del diseño.
Versionado y firma No aplica firma; versiona por convención/nombre. Soporta revisión/firma; control de cambios y protección de fuente.
Reutilización Altísima para datos; base de estandarización. Altísima para lógica; base de bibliotecas de control.
Limitaciones UDT demasiado grandes dificultan el diagnóstico. AOI “gordas” complican el scan y el mantenimiento.
Ejemplos Motor_UDT, Tank_UDT, Recipe_UDT. AOI_MotorStd, AOI_Pump, AOI_ValveDiag.

Implementación paso a paso

  1. Inventario y normalización: lista parámetros y estados por objeto (nombre, tipo, unidades, límites, alarmas).
  2. Diseño UDT: crea miembros claros (Cmd, Fb, Mode, Alarms, Diag, Timestamp). Evita “mega-UDT”.
  3. Diseño AOI: define interfaz (Input/Output/InOut), validaciones y estados; agrega diagnósticos mínimos (bits y códigos).
  4. Instanciado: crea arrays/listas de UDT; llama la AOI por cada equipo. Consistencia en tagging y descripciones.
  5. HMI/SCADA: prepara faceplates/plantillas que lean/escriban según tu estándar (nombres, unidades, alarmas).
  6. Pruebas: simula E/S, casos normales y de fallo; verifica tiempos de ciclo y memoria.
  7. Versionado y firma: exporta L5X, gestiona revisiones y considera firma/protección para liberaciones.

Buenas prácticas y antipatrones

  • UDT por objeto real: que el layout represente cómo piensas/operas el equipo.
  • AOI centrada: una responsabilidad clara por AOI (evita funciones “todológicas”).
  • InOut con criterio: úsalo cuando la semántica lo justifique; preferir Input/Output claros.
  • Alarmas/diag: bits y códigos consistentes; evita “mensajes mágicos”.
  • Convenciones de nombres: prefijos/sufijos estables (Cmd, Fb, OK, Err).
  • Antipatrones: UDT gigantes, AOI monolíticas, duplicación de lógica, ausencia de límites/validaciones.

Mini caso práctico

Una línea de envasado tenía 40 motores con rungs copiados y nombres inconsistentes. Se diseñó Motor_UDT y una AOI_MotorStd (arranque/parada, enclavamientos, fallas y diagnóstico). El commissioning del siguiente proyecto bajó un 35% en horas, y el equipo de mantenimiento reportó una caída notable en tiempos de diagnóstico por tener estados y alarmas uniformes.

Conclusión

UDT y AOI convierten la programación PLC en un proceso modular y escalable. Con datos normalizados y lógica estandarizada, reduces errores, aceleras la puesta en marcha y facilitas el mantenimiento en el largo plazo.


FAQ

¿Empiezo por UDT o por AOI?

Comienza por UDT para ordenar datos y después encapsula comportamiento repetible en AOI. Ese orden facilita diseño HMI y pruebas.

¿Cuándo usar parámetros InOut?

Úsalos cuando realmente necesites pasar una referencia bidireccional. En la mayoría de los casos, Input/Output claros son más mantenibles.

¿Cómo versiono y firmo mis AOI?

Gestiona revisiones en el nombre/propiedades, exporta .L5X a tu repositorio y usa la firma al liberar versiones validadas.

¿Hay impacto en rendimiento frente a subrutinas?

Una AOI bien diseñada evita duplicación y suele ofrecer un paso de parámetros más claro/eficiente que rungs repetidos. Mide siempre tiempos de scan en tu CPU objetivo.

¿Cómo acelero la documentación?

Combina UDT con convenciones y descripciones heredadas; genera plantillas de faceplates HMI y scripts de etiquetado para replicar más rápido.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *