Cómo habla OPC UA Captia Connect
Connect se comporta como cliente OPC UA. El servidor es el otro lado: normalmente va embebido en el PLC, en el controlador de la máquina o en el SCADA que ya está instalado. Esa asimetría condiciona todo lo demás. Connect no publica nada en la red de planta ni obliga a instalar software en el autómata; se conecta a un endpoint que ya existe, lee lo que se le ha autorizado a leer y se lleva el dato al edge.
Transporte y endpoint
La conexión se establece contra una URL de endpoint del servidor, del tipo opc.tcp://direccion:puerto, sobre el binario TCP del estándar y con 4840 como puerto por defecto de la especificación. Antes de leer nada, el cliente pide al servidor la lista de endpoints que ofrece: cada uno declara una política de seguridad y un modo de mensaje, y ahí es donde se decide con qué garantías se va a hablar. Si el equipo publica varios endpoints, el criterio de Connect es tomar el más protegido de los que el servidor realmente acepta, no el primero de la lista.
La conexión es saliente desde el nodo Connect hacia el servidor y se queda dentro de la red de planta. Hacia fuera, el nodo no abre puertos entrantes: el enlace con la plataforma lo establece Tailscale como conexión saliente segura. Esta es la diferencia práctica que interesa a quien mantiene la red: integrar OPC UA con Connect no exige publicar el PLC en internet ni abrir un NAT hacia el autómata.
Modelo de datos: address space, nodos y suscripción
Un servidor OPC UA no expone una lista plana de direcciones, expone un address space: un grafo de nodos con identificador, tipo, nombre legible y relaciones entre ellos. Connect lo navega, es decir recorre esa jerarquía y presenta lo que hay, en lugar de exigir que alguien dicte de antemano una lista de direcciones. En la práctica esto acorta la puesta en marcha: la conversación con el responsable de automatización deja de ser «pásame el mapa» y pasa a ser «de todo esto, qué queremos».
Con los nodos elegidos, Connect se suscribe. La suscripción es el modo de trabajo natural del estándar y funciona por notificación: el servidor avisa cuando el valor de un nodo monitorizado cambia, en lugar de que el cliente pregunte una y otra vez. Frente al sondeo, esto reduce el tráfico sobre la red de planta y la carga sobre la CPU del autómata, que es el recurso que de verdad hay que cuidar en un equipo en producción.
Seguridad
OPC UA lleva la seguridad dentro del propio protocolo, no delegada a una capa externa, y se articula en tres decisiones que hay que tomar en cada implantación: la política de seguridad del canal, que determina si los mensajes viajan firmados, firmados y cifrados o en claro; la confianza de certificados, porque cliente y servidor se identifican con certificado y cada uno debe aceptar el del otro; y la autenticación de usuario, con la cuenta de solo lectura que corresponda. La recomendación operativa es corta: canal firmado y cifrado, certificado del cliente aceptado de forma explícita en el servidor y credenciales sin permiso de escritura. Connect adquiere, no manda consignas.
| Parámetro | Qué se decide | Criterio de partida |
|---|---|---|
| Endpoint | Dirección opc.tcp del servidor y puerto, tomados de la lista que publica el equipo | El endpoint más protegido de los que el servidor acepta de verdad |
| Seguridad del canal | Política de seguridad, modo de mensaje y confianza mutua de certificados | Mensajes firmados y cifrados, con el certificado del cliente aceptado de forma explícita |
| Identidad | Usuario con el que el cliente se autentica en el servidor | Cuenta dedicada de solo lectura, nunca la de ingeniería del equipo |
| Selección de nodos | Qué nodos del address space se monitorizan y con qué intervalo de publicación | Solo las señales que soportan una decisión, con el intervalo que esa decisión exige |
Qué equipos exponen OPC UA
En una planta, OPC UA aparece en tres sitios y conviene distinguirlos porque el trabajo de integración es distinto en cada uno.
El primero son los PLC y controladores modernos con servidor embebido. El servidor ya está en el equipo, a menudo con licencia incluida y desactivado de fábrica. Aquí el trabajo es de configuración: habilitar el servidor, definir qué variables se publican y crear la cuenta de lectura.
El segundo son los sistemas SCADA existentes. Cuando la planta ya tiene un SCADA con las señales agregadas y nombradas, su servidor OPC UA suele ser el mejor punto de toma: evita duplicar el trabajo de mapeo que alguien hizo hace años y respeta la nomenclatura que la operación ya usa. La contrapartida es que el dato llega con la granularidad y la agregación que el SCADA aplica, no con la del proceso.
El tercero son las máquinas de fabricante con OPC UA en la interfaz de datos, habitual en equipos de proceso reciente. Suelen exponer un conjunto cerrado de variables, que es lo que hay, y sobre eso se trabaja.
Fuera de esos tres casos está el parque que no habla OPC UA: autómatas antiguos, analizadores de red, variadores y contadores. Para ese parque la vía es Modbus, por TCP o por RTU sobre RS-485, y lo normal es que en la misma planta convivan las dos. El servicio que hace esa toma de datos extremo a extremo es conectividad de PLC.
De nodo OPC UA a serie temporal
Lo que devuelve un nodo OPC UA no es un número suelto. Es un valor con su tipo declarado, su marca de tiempo de origen y un código de estado que dice si la lectura es buena, dudosa o mala. Connect conserva las tres cosas durante la normalización, y esa conservación es justo lo que separa un histórico defendible de una tabla de números.
El tipo viaja declarado por el servidor, así que no hay que adivinar si un registro es entero con signo o coma flotante ni aplicar factores de escala a mano. Es la ventaja estructural de OPC UA frente a un protocolo de registros y ahorra la clase de error que aparece semanas después, cuando una temperatura sale multiplicada por diez.
El timestamp de origen es el instante en que la señal fue leída en planta, no el instante en que el dato llegó al servidor de la plataforma. Importa por el buffering: cuando la conectividad se corta y se restablece, un bloque de lecturas atrasadas llega de golpe desde la persistencia local del edge. Fechado por hora de llegada, ese bloque comprimiría la serie y falsearía la dinámica. Fechado por origen, cada muestra cae en su sitio.
El código de estado permite distinguir un cero real de un cero que en realidad es un sensor caído. Una serie que no arrastra la calidad de la lectura acaba alimentando alarmas falsas y modelos entrenados sobre huecos.
Sobre eso, el trabajo de normalización es de identidad: un nodo llamado ns=2;i=1043 se puede leer perfectamente, pero nadie sabrá qué decisión soporta. Cada señal se asocia a su activo, su línea o su zona, y se le fija unidad y nombre estables. Ese es el paso que convierte la adquisición en un histórico consultable, y el que describe en general la guía de sistema de adquisición de datos.
| Lo que entrega el nodo | Qué se hace con ello | Para qué sirve después |
|---|---|---|
| Valor con tipo declarado | Se conserva el tipo sin conversiones manuales ni factores de escala | Evita errores de escala y de signo que aparecen semanas después |
| Timestamp de origen | Se usa como marca de tiempo de la muestra, por delante de la hora de llegada | El histórico conserva la separación real entre muestras tras un corte de red |
| Código de estado de la lectura | Se arrastra junto al valor en lugar de descartarse | Permite distinguir un cero real de una lectura mala o de un sensor caído |
| Identificador de nodo del address space | Se asocia a activo, línea o zona, con nombre y unidad estables | Hace la señal consultable por quien no conoce el address space |
Cuándo OPC UA no es la vía adecuada
OPC UA es el estándar que más ordena una integración OT, y aun así hay cuatro escenarios en los que insistir con él cuesta tiempo y no aporta nada.
El equipo no tiene servidor OPC UA. Es el caso más común y no tiene vuelta: un autómata de hace quince años, un analizador de red o un variador no lo van a exponer. Forzarlo obliga a comprar una pasarela intermedia que traduce desde otro protocolo, lo que añade un elemento que mantener y un punto de fallo a cambio de nada, porque Connect ya lee ese equipo directamente por Modbus.
El servidor está en el equipo pero no hay licencia o el fabricante no lo habilita. Ocurre. En ese caso la decisión es económica, no técnica, y suele salir más a cuenta leer por la vía que el equipo ya ofrece.
El dato lo genera un dispositivo IIoT que publica por su cuenta. Sensores alimentados por batería, gateways y equipos que empujan telemetría hacia un broker encajan con MQTT, que es pub/sub y no exige que el dispositivo mantenga un servidor. Poner un servidor OPC UA en un sensor para que Connect lo lea es construir el problema al revés.
El dato no está en planta. Si la señal vive en un ERP, en un MES, en una aplicación cloud o en una exportación de laboratorio, OPC UA no pinta nada: la vía son las integraciones estándar por API REST, webhooks o CSV.
Y un límite que no es del protocolo sino del encargo: OPC UA no arregla un modelo de datos que nadie ha definido. Que las variables tengan tipo no significa que tengan sentido. Si el address space está lleno de nombres heredados y variables auxiliares, alguien tiene que decidir cuáles importan. Ese trabajo es de contexto, no de protocolo, y es el que describe el recurso de contextualización de datos industriales.
Convivencia con el resto de la instalación
La planta normal no habla un protocolo, habla los que le fueron cayendo. Connect está pensado para esa realidad: adquiere en paralelo por todas las vías disponibles y las lleva al mismo modelo de series temporales, de modo que en el histórico una señal de un PLC moderno por OPC UA, un consumo leído a un contador por IEC 870-5-102 y una temperatura sacada de un variador por Modbus quedan al mismo nivel. Nadie tiene que saber de qué protocolo vino un dato para poder usarlo.
La convivencia más frecuente es OPC UA junto a MQTT. No compiten: OPC UA cubre la maquinaria y el SCADA, donde hay servidor y modelo de información, y MQTT cubre la sensórica añadida y los gateways, que publican por su cuenta. Cuál conviene en una arquitectura nueva, y con qué criterio se decide, es la discusión del recurso OPC UA frente a MQTT, que es donde está desarrollada.
La migración típica va en la otra dirección de lo que se suele suponer. Rara vez se sustituye Modbus por OPC UA en el parque existente: lo que ocurre es que los equipos nuevos entran ya con OPC UA y el parque antiguo se queda como está mientras dure. Por eso la recomendación es no plantear la integración como un proyecto de homogeneización de protocolos, que es caro y no lo pide nadie, sino como una capa de adquisición que acepta lo que hay. Cuando esa capa existe, cambiar un equipo deja de ser un problema de datos.
Sobre esa base ya trabajan los módulos de la plataforma, y el proyecto de ingeniería que la implanta es integración OT e IT.