Qué es OPC UA y cuándo usarlo

OPC UA define dos patrones de comunicación que se complementan. En el modelo cliente/servidor, un servidor OPC UA, que puede residir en el propio autómata, en una pasarela o en un PC industrial, expone un espacio de direcciones con nodos. Un cliente se conecta, navega por ese espacio, lee y escribe valores, invoca métodos y crea suscripciones para recibir notificaciones cuando un valor cambia o se produce un evento. Es un patrón de petición y respuesta con sesión, adecuado cuando una aplicación necesita explorar y consultar un equipo concreto.

El modelo de publicación/suscripción (PubSub, descrito en la parte 14 de la especificación) desacopla emisores y receptores: los publicadores envían mensajes a un middleware sin saber quién los recibirá. La especificación distingue un middleware sin intermediario, que se apoya en la propia red (por ejemplo, UDP en unidifusión o multidifusión), y otro basado en un intermediario o broker, que usa protocolos de mensajería como MQTT. Está pensado para escenarios de muchos a muchos, como distribuir datos de muchas máquinas hacia varias aplicaciones o hacia la nube.

Además, la especificación incluye servicios de descubrimiento para localizar servidores disponibles en una red, lectura de datos históricos y eventos que notifican información relevante según criterios del cliente.

La pieza que más diferencia a OPC UA es su marco de modelado de información. El espacio de direcciones no es una lista plana de variables, sino un grafo de nodos tipados y relacionados: objetos, variables, métodos, tipos y referencias entre ellos. Un servidor puede exponer un objeto «Prensa 3» de un tipo «Prensa hidráulica», con variables de presión y temperatura que incluyen unidad de ingeniería y rango, un método para iniciar un ciclo y eventos de alarma.

Sobre el modelo base, otras organizaciones sectoriales construyen sus propios modelos, las llamadas especificaciones complementarias (companion specifications), que definen tipos comunes para una familia de equipos. Si dos fabricantes implementan la misma especificación complementaria, un cliente puede tratar sus máquinas de forma homogénea sin conocer los detalles de cada una.

• Ventaja: el consumidor del dato puede descubrir la estructura navegando, sin depender de una tabla de direcciones externa.
• Ventaja: unidades, rangos y descripciones viajan con el dato, lo que reduce errores de interpretación.
• Limitación: un modelo rico hay que diseñarlo y mantenerlo; un servidor que solo expone variables planas aporta poco frente a un protocolo de campo.
• Limitación: no todos los equipos implementan las especificaciones complementarias de su sector, ni con la misma completitud.

A diferencia de muchos protocolos industriales antiguos, OPC UA incorpora seguridad en su diseño. La parte 2 de la especificación (modelo de seguridad) enumera objetivos como autenticación de clientes, servidores y usuarios, autorización según la necesidad de conocer, confidencialidad, integridad, auditabilidad y disponibilidad. En la práctica, la OPC Foundation describe mecanismos como la autenticación de aplicaciones mediante certificados X.509, la firma de mensajes para verificar su origen e integridad, el cifrado y el control de usuarios.

• Que el estándar ofrezca seguridad no significa que esté activa: muchos equipos permiten conexiones sin firma ni cifrado, y es una configuración que conviene revisar.
• La gestión de certificados (emisión, confianza, caducidad, revocación) es trabajo operativo continuo; si nadie la asume, acaba desactivándose la seguridad «para que funcione».
• Los permisos deben limitarse: un cliente de monitorización no necesita escribir consignas.
• OPC UA no sustituye a la segmentación de red ni al resto de medidas de ciberseguridad de la planta; es una capa más.

• Recoger estados, contadores y alarmas de máquinas de varios fabricantes en un MES o un sistema de indicadores de eficiencia.
• Alimentar un histórico o una plataforma de analítica con variables de proceso contextualizadas por equipo.
• Enviar recetas o parámetros de orden desde el MES al equipo mediante métodos o escrituras controladas.
• Publicar telemetría hacia la nube a través de un broker, con PubSub, sin abrir conexiones entrantes a la planta.
• Poner una pasarela OPC UA delante de equipos con protocolos antiguos para ofrecer una interfaz homogénea a las aplicaciones.

Ejemplo ilustrativo: una planta con inyectoras de dos marcas quiere calcular disponibilidad y rendimiento por turno. Si ambas exponen un servidor OPC UA, una aplicación puede suscribirse a estado de máquina, contador de ciclos y alarma activa en cada una. Si además implementan una especificación complementaria común, el mismo código sirve para las dos; si no, hará falta una capa de traducción por modelo.

OPC UA no es obligatorio para toda integración industrial. Si solo necesitas leer un puñado de variables de un único autómata para un cuadro de mando sencillo, un protocolo de campo bien documentado puede ser suficiente. Si los equipos no lo soportan de forma nativa, añadir pasarelas tiene coste y es otro elemento que mantener. Y en control de movimiento con requisitos de tiempo muy estrictos se utilizan buses de campo y tecnologías específicas que quedan fuera de este artículo.

1. ¿Hay equipos de varios fabricantes que necesitan exponer datos a varias aplicaciones? Ahí OPC UA aporta más.
2. ¿Los equipos lo soportan de forma nativa o habrá que añadir pasarelas? Inventaria antes de diseñar.
3. ¿Existe una especificación complementaria para vuestro tipo de equipo, y la implementan vuestros modelos?
4. ¿Necesitas explorar y actuar sobre equipos (cliente/servidor) o distribuir datos a muchos consumidores (PubSub)?
5. ¿Quién gestionará certificados, usuarios y permisos durante la vida de la instalación?
6. ¿Se va a escribir en planta? Si es así, define validaciones y responsables antes de conectar nada.

Si la mayoría de respuestas apuntan a heterogeneidad de equipos y varias aplicaciones consumidoras, OPC UA suele ser una base sólida. Si el caso es pequeño y cerrado, puede bastar una solución más sencilla, siempre que se documente bien qué significa cada dato.