Conectividad PLC

Qué significa conectividad PLC

La conectividad PLC consiste en extraer los datos que ya viven dentro de los autómatas de la planta y ponerlos a disposición de otros sistemas: un historiador, un broker MQTT, una base de datos, la nube. El PLC lleva años leyendo temperaturas, contando piezas y registrando alarmas; el problema es que esa información se queda encerrada en la capa de control, visible solo desde el HMI de la máquina o desde el software de programación del fabricante.

Nuestro servicio conecta PLCs de cualquier fabricante y protocolo a la capa de datos unificada de Captia, para que la información de la capa de control quede disponible de forma fiable. Eso incluye equipos Siemens, Rockwell, Schneider, Omron, Mitsubishi o Beckhoff, y también controladores antiguos que solo hablan un protocolo serie. La pieza clave no es la marca del autómata, sino el método: leer sus variables desde fuera, sin modificar el programa que gobierna la máquina.

Conviene distinguir este trabajo de la programación del propio autómata. Cuando lo que hace falta es escribir o modificar la lógica de control, el servicio adecuado es el de programación PLC, SCADA y HMI. La conectividad opera una capa por encima: el programa sigue siendo el que es y nosotros nos limitamos a leer lo que produce.

Extraer datos sin tocar el programa de control

La objeción más habitual en planta es razonable: la máquina funciona y nadie quiere que un proyecto de datos la pare. Por eso el principio de partida es no modificar el programa de control. Casi todos los PLCs modernos exponen sus variables por un canal de comunicaciones independiente del ciclo de scan: un servidor OPC-UA embebido, un puerto Modbus TCP, el protocolo S7 en los Siemens o EtherNet/IP en los Rockwell. Leer por ese canal no requiere cargar código nuevo en el autómata ni detenerlo.

El trabajo real está en el detalle: identificar qué variables interesan (no todas; un PLC puede tener miles), documentar su significado con el equipo de mantenimiento, fijar frecuencias de muestreo que no saturen la CPU del autómata y dar a cada señal un nombre estable dentro de la capa de datos. Un dato sin contexto (¿esta temperatura es del horno 2 o del 3? ¿está en grados o en décimas?) genera más problemas de los que resuelve, así que el modelado de la información forma parte del servicio, no es un extra.

Cuando el PLC es muy antiguo y no ofrece ningún canal utilizable, existen alternativas: pasarelas hardware que traducen el protocolo propietario, lectura de señales en paralelo o, como último recurso, plantear la actualización del equipo. Esa decisión se toma caso a caso y con el coste sobre la mesa.

Protocolos habituales: OPC-UA, Modbus, S7 y otros

Cada fabricante ha resuelto las comunicaciones a su manera, y una planta con historia acumula varias generaciones de protocolos. Estos son los que más aparecen en los proyectos:

• OPC-UA. El estándar actual de interoperabilidad industrial. Aporta modelo de datos con tipos y jerarquía, cifrado y autenticación. Muchos PLCs recientes lo llevan embebido; para el resto se usa un servidor OPC-UA intermedio.
• Modbus TCP / RTU. Veterano y omnipresente, sobre todo en variadores, analizadores de red y equipos auxiliares. Simple de leer, pero sin semántica: el mapa de registros hay que documentarlo a mano.
• S7 (Siemens). Protocolo propietario de la familia S7-300/400/ 1200/1500. Permite leer bloques de datos directamente, lo que resulta útil en instalaciones Siemens donde activar OPC-UA no es viable.
• EtherNet/IP y CIP. El equivalente en el ecosistema Rockwell / Allen-Bradley, con acceso a tags por nombre en los ControlLogix y CompactLogix.
• Buses y protocolos heredados. Profibus DP, DF1, Hostlink y similares en equipos con veinte o treinta años de servicio, que suelen requerir pasarela.

Aguas arriba, lo habitual es publicar todo lo leído en un broker MQTT con una estructura de topics coherente para toda la planta. Ese patrón, y su relación con el unified namespace, lo tratamos en el servicio de integración MQTT y en el recurso sobre OT/IT bridge y unified namespace.

Seguridad: acceso de solo lectura por diseño

Conectar la capa de control a una red de datos plantea una pregunta de seguridad legítima. Nuestro criterio es configurar el acceso como solo lectura siempre que el proyecto lo permita: el conector consulta variables, pero no tiene capacidad de escribir consignas ni de alterar el estado de la máquina. En OPC-UA eso se apoya en usuarios con permisos restringidos; en otros protocolos, en la selección de funciones de lectura y en la segmentación de red.

La arquitectura acompaña ese criterio. El software que dialoga con los PLCs se ejecuta en un equipo dentro de la red OT, y es ese equipo el que publica los datos hacia fuera a través de una frontera controlada, de modo que ningún sistema externo habla directamente con un autómata. Este patrón de recogida y publicación en el borde de la red es el que describimos en el servicio de ingesta edge. Si la planta dispone de políticas propias de ciberseguridad OT, el despliegue se adapta a ellas en lugar de imponer las nuestras.

Conectar el PLC a la nube: qué implica de verdad

Conectar un PLC a la nube no es enchufar el autómata a internet, y de hecho eso es precisamente lo que hay que evitar. La secuencia razonable tiene tres pasos: leer las variables en local por el protocolo que el equipo ofrezca, consolidarlas y contextualizarlas en la capa de datos de planta, y publicar hacia la nube solo lo que tenga un uso definido, con cifrado y autenticación en el tramo de salida.

Con los datos ya disponibles, los destinos habituales son historiadores y cuadros de mando, sistemas de gestión y analítica. Cerrar el ciclo con los sistemas corporativos, por ejemplo llevar contadores de producción al ERP, es objeto del servicio de integración ERP. El valor de todo lo anterior es sencillo de enunciar: que un dato que hoy solo se ve en el panel de la máquina pase a estar disponible, con su contexto, para cualquier sistema que lo necesite.