Blog

OPC UA: guía práctica para conectar máquinas, SCADA y MES

16 de octubre de 2026 · GILVI Automation

En casi cualquier planta conviven máquinas de fabricantes distintos, PLC de marcas distintas y un SCADA, un MES o un ERP que tienen que entenderse con todos ellos. OPC UA (Open Platform Communications Unified Architecture) permite que sistemas de distintos fabricantes intercambien información mediante una interfaz estándar, sin depender de drivers propietarios para cada combinación, siempre que ambos extremos implementen OPC UA.

En esta guía veremos qué es OPC UA, cómo conectar un PLC con un SCADA o un MES, cuándo tiene sentido usar MQTT, cómo se protege la comunicación y qué errores conviene evitar en una instalación industrial.

OPC UA en un minuto

• Es un estándar abierto de comunicación industrial, publicado como norma internacional IEC 62541 y mantenido por la OPC Foundation. La primera versión es de 2006. La actual es la 1.05; sus últimas partes revisadas (1.05.07) se publicaron en abril de 2026.
• No depende del fabricante ni del sistema operativo: funciona en PLC, PC industriales, servidores Linux o Windows y en la nube.
• No solo puede transportar valores: permite modelar su significado mediante objetos, variables, tipos, unidades, alarmas, métodos y relaciones.
• Trae la seguridad de serie: certificados, firma, cifrado, usuarios y permisos.
• Tiene dos formas de comunicar: cliente-servidor (la habitual entre PLC y SCADA o MES) y publicación-suscripción (PubSub), pensada para muchos destinatarios y para la nube.

Dónde encaja: la pirámide de automatización

La forma clásica de ordenar los sistemas de una fábrica es la pirámide de automatización, basada en el modelo ISA-95 (norma IEC 62264). Cada nivel maneja un tipo de información distinto y a un ritmo distinto. Los ritmos de la tabla son orientativos: ISA-95 no los fija, y cada planta tiene los suyos.

Entre el nivel 0 y el 1 mandan los buses de campo en tiempo real (PROFINET, EtherNet/IP, EtherCAT). Del nivel 1 hacia arriba es donde OPC UA se ha convertido en el estándar de facto: saca los datos del PLC hacia el SCADA y el MES, y permite que máquinas de distintos fabricantes hablen entre sí. El ERP también puede consumir datos por OPC UA, pero en una arquitectura real no suele leer directamente de los PLC: lo hace a través del MES o de una capa de integración.

En las arquitecturas más modernas la pirámide se aplana: en lugar de que cada nivel hable solo con el de al lado, todos publican y consumen datos de un punto común (lo que se conoce como Unified Namespace). Incluso así, OPC UA sigue siendo la forma más habitual de sacar los datos de las máquinas.

Del OPC clásico a OPC UA

Antes de los estándares, cada aplicación necesitaba un driver para cada marca de PLC: tres PLC y tres aplicaciones suponían nueve conexiones distintas que mantener. El primer OPC (hoy llamado OPC clásico: OPC DA, HDA y A&E, de finales de los 90) resolvió parte del problema, pero dependía de Windows y de DCOM, una tecnología difícil de configurar y problemática con los cortafuegos.

Cómo funciona: cliente y servidor

El modo más común es el cliente-servidor. El PLC (o un PC junto a la máquina) tiene un servidor OPC UA que publica sus datos. El SCADA, el MES, un histórico o una aplicación en la nube se conectan como clientes.

Lo que un cliente puede hacer está definido por los servicios del estándar:

• Explorar (Browse): recorrer el servidor y descubrir qué contiene, sin conocer de antemano las direcciones.
• Leer y escribir: valores de variables, como una consigna o un contador.
• Suscribirse: recibir solo los cambios, sin tener que preguntar continuamente.
• Llamar a métodos: ejecutar funciones de la máquina, como cargar una receta o arrancar una orden.
• Eventos y alarmas: recibir alarmas con su prioridad, su estado y su reconocimiento.
• Históricos: leer datos y eventos pasados, si el servidor los guarda.

Para encontrar los servidores existe un servicio de descubrimiento: el cliente pregunta y el servidor le indica sus direcciones (endpoints) y los niveles de seguridad que admite.

El modelo de información

La gran diferencia de OPC UA frente a otros protocolos es que no publica una lista de registros sin contexto, sino un modelo de la máquina. Todo lo que hay en el servidor son nodos relacionados entre sí:

• Objetos: la máquina, sus grupos y sus componentes.
• Variables: los valores, con su tipo de dato, su calidad y su marca de tiempo. Si el modelo lo incluye, también sus unidades y su rango (por ejemplo, con el tipo normalizado AnalogItemType); no todas las variables los llevan.
• Métodos: funciones que se pueden ejecutar desde fuera.
• Eventos y alarmas: lo que pasa en la máquina, con su gravedad.
• Tipos: plantillas reutilizables. Si se define el tipo «Llenadora», todas las llenadoras de la planta se presentan igual.

Para un MES o un cuadro de mando, la diferencia es enorme: los datos llegan con nombre y estructura (y con unidades, si se han modelado), y una máquina nueva del mismo tipo se integra sin volver a mapear nada.

Suscripciones, muestreo y banda muerta

Preguntar continuamente por cientos de variables (polling) satura la red y el PLC. Con una suscripción, el cliente le dice al servidor qué variables le interesan y con qué condiciones, y el servidor solo envía lo que cambia. Hay tres parámetros clave:

• Intervalo de muestreo: cada cuánto mira el servidor el valor (por ejemplo, 100 ms).
• Intervalo de publicación: cada cuánto envía al cliente los cambios acumulados (por ejemplo, 1 s).
• Banda muerta (deadband): cuánto tiene que cambiar un valor para que se considere un cambio. Evita enviar el ruido de una medida analógica.

Ajustar bien estos tres valores es lo que separa una integración fluida de una que satura el PLC. Un contador de producción no necesita leerse cada 100 ms, y una temperatura de horno no necesita enviar cada décima de grado.

PubSub y MQTT

Desde la versión 1.04, OPC UA incluye un segundo modelo de comunicación: publicación-suscripción (PubSub). El publicador envía sus datos sin saber quién los recibe, y cualquier número de suscriptores los consume. Hay dos variantes:

• Con broker: los mensajes se distribuyen mediante MQTT o AMQP. OPC UA PubSub admite tanto codificación JSON como binaria (UADP), según la arquitectura y los equipos. Es la opción natural para enviar datos a la nube, a plataformas de análisis o a muchos consumidores a la vez.
• Sin broker: los datos viajan por la red de planta en UDP multicast con codificación binaria (UADP). Es muy eficiente y es la base de la comunicación entre controladores.

¿Cliente-servidor o PubSub? En planta, para SCADA y MES, cliente-servidor sigue siendo lo habitual y lo que admiten casi todos los equipos. PubSub sobre MQTT tiene sentido cuando hay muchos consumidores, cuando los datos van a la nube o cuando se monta una arquitectura de datos centralizada.

Seguridad

OPC UA se diseñó con la seguridad integrada, pero solo protege si se configura. Muchos equipos salen de fábrica con el acceso anónimo y sin cifrado para facilitar la puesta en marcha, y así se quedan. La protección se organiza en capas:

• Canal seguro con certificados: cada aplicación (el servidor del PLC, el SCADA, el MES) tiene su certificado X.509, y solo se comunican las que confían entre sí.
• Modo de seguridad: None (sin protección), Sign (mensajes firmados: no se pueden alterar) o SignAndEncrypt (firmados y cifrados: además, nadie los puede leer). En producción, lo recomendable es SignAndEncrypt con una política actual, como Basic256Sha256 o las de la familia Aes. Las políticas antiguas (Basic128Rsa15 y Basic256) están obsoletas.
• Usuario: además de la aplicación, se identifica a la persona o al sistema, con usuario y contraseña o con certificado. El acceso anónimo debería estar desactivado.
• Permisos: quién puede leer, quién puede escribir y quién puede ejecutar cada método. Un cuadro de mando no necesita escribir consignas.
• Gestión de certificados: los certificados caducan. Hay que saber cuándo y renovarlos antes, o la comunicación se corta. En instalaciones grandes se centraliza con un servidor de gestión (GDS).

OPC UA no sustituye a una red bien diseñada: la red de planta separada de la de oficinas, cortafuegos entre zonas y solo los puertos necesarios abiertos, como recomienda la serie IEC 62443 de ciberseguridad industrial.

Especificaciones de sector (companion specifications)

Que dos máquinas hablen OPC UA no garantiza que se entiendan: cada fabricante podría organizar sus datos a su manera. Para evitarlo, la OPC Foundation publica junto con asociaciones de fabricantes (como VDMA o EUROMAP) especificaciones de sector, que fijan cómo debe presentarse cada tipo de equipo. Ya hay modelos normalizados para más de 60 tipos de equipos industriales. Algunas de las más usadas:

Para un fabricante de maquinaria, seguir la especificación de su sector es un argumento de venta: el cliente integra la máquina en su MES casi sin trabajo adicional.

OPC UA frente a otros protocolos

Ojo: no son alternativas equivalentes. OPC UA es un estándar de interoperabilidad (modelo de información, servicios y seguridad); MQTT es un protocolo de transporte que puede llevar datos de OPC UA o de cualquier otra cosa; Modbus TCP y PROFINET son protocolos de comunicación con la periferia y entre equipos de control. La tabla compara para qué se usa cada uno, no cuál es mejor.

No compiten entre sí: en una planta moderna conviven. PROFINET dentro de la máquina, OPC UA para sacar los datos de la máquina y MQTT, a menudo con OPC UA PubSub, para llevarlos a la nube.

OPC UA no sustituye a la comunicación determinista de control. El modo cliente-servidor no está pensado para cerrar lazos de control de milisegundos ni para gobernar periferia y accionamientos: eso sigue siendo cosa de PROFINET, EtherNet/IP o EtherCAT. OPC UA FX, junto con TSN, está ampliando el alcance de OPC UA hacia ese terreno, pero hoy, en la gran mayoría de las máquinas, el control en tiempo real sigue en el bus de campo.

OPC UA en los PLC más habituales

Si el PLC no tiene servidor OPC UA (equipos antiguos, por ejemplo), se puede usar una pasarela: un software o un equipo que habla el protocolo nativo del PLC por un lado y ofrece un servidor OPC UA por el otro. Es una solución muy habitual en proyectos de retrofit.

Licencias, versiones de firmware y funciones cambian con cada versión. Compruébalo siempre en la documentación del fabricante antes de presupuestar.

Ejemplo: conectar un S7-1500 por OPC UA

Sin convertir esto en un tutorial de TIA Portal, estos son los pasos de una integración típica con una CPU S7-1500:

1. Activar el servidor OPC UA en las propiedades de la CPU, comprobar que su versión de firmware admite las funciones que se van a usar y asignar la licencia de runtime que corresponda al tamaño de la CPU.
2. Definir la interfaz: crear una interfaz de servidor propia con solo las variables que necesita el SCADA o el MES, en lugar de publicar todo el programa.
3. Configurar la seguridad: políticas de seguridad admitidas, certificado del servidor, usuarios y acceso de invitado desactivado.
4. Anotar el endpoint: la dirección del servidor, del tipo opc.tcp://<IP del PLC>:4840.
5. Probar con UaExpert: conectarse, aceptar los certificados, explorar la interfaz y comprobar lecturas, escrituras y suscripciones.
6. Conectar el SCADA o el MES como cliente, con la misma política de seguridad, y ajustar los intervalos de muestreo y publicación.

La interfaz de datos es un contrato

Activar OPC UA en un PLC es relativamente sencillo: en muchos casos es marcar una casilla. Diseñar una interfaz OPC UA mantenible no lo es. La estructura publicada debería tratarse como una API industrial: una vez que la consume un SCADA, un MES u otro sistema, cambiarla puede romper integraciones que ya funcionan.

El trabajo de ingeniería está en decidir:

• Qué datos se publican y cuáles no.
• Qué estructura tienen y cómo se agrupan.
• Cómo se nombran, con una nomenclatura común a todas las máquinas.
• Unidades y rangos de cada valor analógico.
• Permisos: quién lee, quién escribe y quién ejecuta métodos.
• Frecuencias de muestreo y publicación.
• Versionado y compatibilidad: cómo añadir datos en la siguiente versión de la máquina sin romper lo que ya hay.
• Especificación de sector: si existe una para ese tipo de máquina, seguirla.
• Mantenimiento: documentación, certificados y responsables.

Esa es la diferencia entre «tener OPC UA» y tener una integración que dura años.

Caso práctico: un SCADA sin driver para el PLC

Cómo plantear un proyecto OPC UA

1. Para qué se quieren los datos. Indicadores de producción, trazabilidad, mantenimiento, energía… El objetivo decide qué datos y con qué frecuencia.
2. Inventario de máquinas. Marca y modelo de cada PLC, versión de firmware y si tiene servidor OPC UA o hará falta una pasarela.
3. Diseño de la interfaz de datos. Qué variables, con qué nombres, unidades y estructura. Si existe una especificación de sector (PackML, Machinery…), seguirla.
4. Licencias. Comprobar qué licencias de runtime necesita cada equipo y añadirlas al presupuesto.
5. Red y seguridad. Dónde está cada equipo, qué cortafuegos hay que atravesar, qué modo de seguridad, qué usuarios y quién gestiona los certificados.
6. Configurar los servidores y publicar solo lo definido en la interfaz.
7. Probar con un cliente genérico (por ejemplo, UaExpert) antes de conectar el SCADA o el MES: así se separan los problemas del servidor de los del cliente.
8. Integrar y ajustar los intervalos de muestreo, la publicación y las bandas muertas viendo la carga real del PLC y de la red.
9. Documentar la interfaz, los certificados y sus fechas de caducidad, y los usuarios.

Errores frecuentes

• Publicar todo el programa del PLC. Miles de variables internas que nadie usa, más carga y un servidor imposible de mantener.
• Dejar el acceso anónimo y sin cifrado «porque así funcionó en la puesta en marcha».
• Olvidar los certificados: un día caducan y la comunicación se cae sin que nadie sepa por qué.
• Leer todo cada 100 ms «por si acaso», en lugar de ajustar cada variable a lo que necesita.
• No sincronizar la hora de PLC y servidores (NTP). Las marcas de tiempo de alarmas e históricos dejan de cuadrar.
• Cambiar nombres sin avisar: si se renombra o se mueve una variable del PLC, el MES deja de encontrarla. La interfaz de datos es un contrato.
• No contar las licencias en el presupuesto.

Hacia dónde va OPC UA

• OPC UA FX (Field eXchange): la OPC Foundation está llevando OPC UA hasta el nivel de campo. Las especificaciones de comunicación entre controladores de distintos fabricantes ya están publicadas, y se trabaja en la comunicación con dispositivos: periferia, accionamientos y sensores.
• TSN (Time-Sensitive Networking): Ethernet estándar con tiempos garantizados, que combinado con OPC UA PubSub permite comunicación determinista.
• Arquitecturas de datos centralizadas: OPC UA para sacar los datos de las máquinas, con su modelo, y MQTT para distribuirlos a toda la empresa.

Preguntas frecuentes

Documentación de referencia

• OPC Foundation · OPC 10000-1 (IEC 62541-1): visión general y conceptos
• OPC Foundation · OPC 10000-2: modelo de seguridad
• OPC Foundation · OPC 10000-7: perfiles y políticas de seguridad
• OPC Foundation · OPC 10000-14: PubSub (MQTT, AMQP, UDP)
• Siemens · Comunicación OPC UA con S7-1200 y S7-1500 (TIA Portal)
• ISA · Serie IEC 62443 de ciberseguridad industrial

Nuestra experiencia

En GILVI Automation usamos OPC UA en proyectos de captación de señales y de integración de datos:

• Maquinaria farmacéutica: captación de señales del PLC hacia un SCADA Wonderware InTouch por OPC UA, porque no había driver de comunicación disponible para ese caso.
• Fabricante de maquinaria: extracción de datos de máquina por OPC UA para su explotación fuera del PLC.

Si necesitas conectar tus máquinas a un SCADA o a un MES, o quieres que tus máquinas salgan de fábrica con una interfaz OPC UA bien diseñada, cuéntanos tu proyecto. Más información en Digitalización industrial e integración IT/OT.