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