Fallos de comunicación entre PLC y SCADA: síntomas, causas y cómo diagnosticarlos

En esta página

• Síntomas y qué indican
• Tabla de diagnóstico
• Capa física
• Capa de red
• Capa de protocolo: Modbus, PROFINET y OPC UA
• Capa de aplicación
• Diagnóstico paso a paso
• Soluciones para que no vuelva a pasar
• Lo que cambia en una fábrica agroalimentaria
• Cómo lo trabajamos en ER Ingeniería
• Preguntas frecuentes
• Fuentes

Síntomas de una pérdida de comunicación y qué indican

Pocas veces empieza con una caída completa. Lo normal son señales pequeñas:

• Variables congeladas. El valor no se mueve aunque el proceso sí. Muchos drivers conservan el último valor leído al caer la conexión, y si la pantalla no enseña la calidad del dato, el operador ve una cifra creíble que ya no es real.
• Calidad «Bad» o «Uncertain». En OPC UA cada valor viaja con un código de estado: Good es un valor de buena calidad, Uncertain uno de calidad dudosa y Bad uno que no se puede usar [4]. El código concreto suele decir más que la alarma.
• Alarmas de comunicación intermitentes. Aparecen y se reponen solas. Si coinciden con el arranque de un motor grande, un cambio de turno o un lavado, la hora es la mejor pista.
• Huecos en los históricos. La tendencia une dos puntos con una recta o faltan registros de un lote, y, sin un búfer previo, ese hueco ya no se rellena.
• Escrituras que no llegan. Una consigna o una receta sale del SCADA y el autómata no la ejecuta, o la ejecuta tarde.
• Valores absurdos pero estables. Un número enorme o negativo donde debería haber una temperatura. El dato llega, pero se interpreta mal: lo vemos en la capa de aplicación.

Tabla de diagnóstico: síntoma, causa probable y comprobación

Capa física: cable, conectores y ruido eléctrico

Es la primera que hay que descartar y la que más se salta. Causas típicas: conectores RJ45 montados en obra que se aflojan con la vibración, entradas de cable a cajas de campo sin estanqueidad, humedad que se queda dentro tras los lavados y pantallas de cable sin conectar o conectadas de forma distinta a la que indica el fabricante del bus.

El ruido eléctrico tiene un patrón reconocible: los errores suben cuando arranca un motor grande o acelera un variador. Si el cable de datos comparte canaleta con las salidas de los variadores, el problema no se arregla tocando el software.

Cómo se comprueba: contadores de errores del puerto (tramas con CRC o FCS erróneo) en el switch o en el diagnóstico de puertos del autómata. Si suben, comprobador de cable y latiguillo de fábrica en lugar del sospechoso. Si los errores siguen al latiguillo, el fallo está en él.

Capa de red: switches, bucles, IP duplicadas y VLAN

Un switch no gestionado en un armario de planta funciona, pero no da contadores por puerto ni permite copiar tráfico para capturarlo.

Bucles. Un latiguillo que une dos tomas del mismo switch, o dos switches unidos por dos caminos sin un protocolo que gestione la redundancia, crea un círculo por el que las tramas de difusión dan vueltas sin fin. Suele pasar tras una ampliación o una reparación con prisa: todo el tramo cae a la vez y no vuelve hasta que se quita el cable que cierra el círculo. Con redundancia (STP o anillo), un cable cortado no tumba el tramo, aunque mientras la red se recompone puede haber caídas breves.

IP duplicadas. Un repuesto configurado con la IP de un equipo que sigue conectado, el portátil de un técnico externo, una pantalla nueva con su IP de fábrica. Dos equipos se turnan para comunicar: la MAC de esa IP cambia de una consulta a otra, y un arping o una captura muestran dos equipos que responden a la misma IP.

Segmentación. La guía del NIST para la seguridad de la tecnología operacional describe la segmentación de la red de planta por zonas, física con switches distintos o lógica con VLAN [6]. Además de proteger, evita que el tráfico de difusión de la oficina llegue a los autómatas.

Capa de protocolo: Modbus, PROFINET y OPC UA

Modbus: un timeout y una excepción dicen cosas distintas

La especificación de Modbus separa dos casos que en la pantalla se confunden. Si la petición no llega al esclavo, o llega con un error de paridad o de CRC, no hay respuesta y el cliente acaba registrando un tiempo de espera agotado. Si llega bien pero el equipo no puede atenderla, devuelve una respuesta de excepción: el código de función más 80 hexadecimal y un código con el motivo [1].

Traducido: un timeout es que no llegó respuesta. Apunta a cable, red, pasarela, equipo apagado o parámetros que no casan (dirección de esclavo, velocidad, paridad), porque el esclavo no contesta a una trama que no es suya ni a una que llega con errores [1]. Una excepción dice que el equipo recibió la petición y por qué no la atiende: el 01 y el 02 suelen ser de configuración, el 04 es una avería del equipo y el 0A y el 0B señalan a la pasarela o a lo que tiene detrás. Los códigos que más orientan:

Subir el tiempo de espera del driver puede quitar la alarma sin quitar la causa: los datos siguen llegando tarde, y en una línea serie donde el maestro pregunta a los esclavos de uno en uno, cada espera retrasa las peticiones que van detrás.

PROFINET: el tiempo de vigilancia

PROFINET IO une el autómata con su periferia y sus variadores. El SCADA suele hablar con el autómata por S7 u OPC UA, así que este fallo le llega de rebote: como alarma de fallo de estación, si el autómata la notifica, o como lecturas que dejan de ser válidas.

El watchdog de PROFINET es el tiempo que el controlador o el dispositivo IO aceptan sin recibir datos. Si se supera, el dispositivo pone valores sustitutivos y el controlador lo registra como fallo de estación. En el software de Siemens se fija como múltiplo entero del tiempo de actualización [2].

El búfer de diagnóstico del controlador dice qué dispositivo cayó y cuándo. En anillos, MRP, el protocolo de redundancia de la norma IEC 62439-2, tiene una reconfiguración típica de 200 ms y admite hasta 50 dispositivos por anillo, y Siemens pide un watchdog de 256 ms o más cuando se acoplan varios anillos [2]. Un watchdog más corto que la reconfiguración convierte un corte que el anillo debería absorber en una parada.

OPC UA: suscripciones que se pierden

Con OPC UA, el SCADA suele suscribirse a las variables. El servidor envía los cambios en cada intervalo de publicación y, si pasan varios ciclos seguidos sin cambios, un mensaje de mantenimiento (keep-alive). Si pasan demasiados ciclos sin que el cliente pida publicaciones, se agota el contador de vida y la suscripción se cierra [3].

Las suscripciones están pensadas para sobrevivir a un corte de la conexión y de la sesión [3], pero hay un escenario típico: la conexión vuelve y un grupo de variables sigue congelado, porque el corte duró más que la vida de la suscripción o porque el cliente abrió una sesión nueva sin transferirla ni crearla otra vez. La especificación prevé una cola de retransmisión para recuperar notificaciones perdidas con el servicio Republish [3]; que el cliente la use depende de cómo esté configurado.

Capa de aplicación: variables, sondeo y relojes

Sondeo excesivo. Pedir todas las variables cada segundo carga el procesador de comunicaciones del autómata y el driver. Una temperatura de depósito no necesita la frecuencia de una báscula en plena pesada.

Direcciones dispersas. Una lectura Modbus de registros admite de 1 a 125 registros contiguos [1]. Si las variables están repartidas por la memoria del autómata, hacen falta muchas peticiones pequeñas por ciclo; agrupadas en una zona de intercambio contigua, bastan muchas menos.

Latido (heartbeat). Un contador que el autómata incrementa y el SCADA vigila: si deja de cambiar, los datos son viejos aunque la conexión parezca abierta. Al revés también sirve: el autómata vigila un latido del SCADA y, si se para, deja de aceptar consignas remotas y pasa a un estado seguro definido.

Relojes. Con un reloj distinto en autómata, servidor e historiador, los eventos salen desordenados. NTP es el protocolo estándar para sincronizar relojes en red [7], y el NIST recuerda que la sincronización horaria es necesaria para correlacionar eventos y registros [6].

Tipos de datos. Los valores absurdos suelen ser un entero con signo leído como sin signo, o un real que viaja en dos registros y se recompone con el orden de palabras cambiado. Se confirma comparando el valor en línea del autómata con el del SCADA.

Cómo diagnosticar un fallo de comunicación entre PLC y SCADA, paso a paso

1. Acota el alcance. ¿Un equipo, una línea o toda la planta? ¿Siempre, a ratos, a ciertas horas? Si cae todo a la vez, mira red o servidor; si cae un equipo, su cable, su puerto o su configuración.
2. Lee lo que ya dice el sistema. Calidad de las variables, error del driver (timeout o excepción, y cuál), búfer de diagnóstico del autómata y eventos del servidor.
3. Mira los contadores. En el switch gestionado: errores CRC, tramas descartadas, caídas de enlace y difusión por puerto. En el autómata: diagnóstico de puertos y estaciones. Ponlos a cero, espera a que se repita y compara.
4. Captura el tráfico. Wireshark, el analizador de red libre, interpreta Modbus/TCP, PROFINET IO y OPC UA [8]. En una red con switch, un portátil conectado a un puerto cualquiera solo ve su propio tráfico y el de difusión: hace falta un puerto espejo (port mirroring o SPAN) en un switch gestionado, o un tap de red. El puerto espejo debe ser al menos tan rápido como el que copia y no reenvía tramas dañadas, así que los errores de CRC se ven en los contadores, no en la captura [5].
5. Aísla, con cuidado. Conecta un portátil directo al equipo con un cliente de pruebas solo en lectura, por un segundo puerto libre o en una parada si hay que sacarlo de la red. Antes, mira qué enclavamientos entre autómatas pasan por esa red: desconectarlo los corta. Si así comunica bien durante horas, el problema está en la red o en la carga; si falla igual, en el equipo o su configuración.
6. Cambia una cosa cada vez. Si cambias tres a la vez y el fallo desaparece, no sabrás cuál era.

Soluciones para que no vuelva a pasar

Encontrar la causa resuelve la avería de hoy. La siguiente se previene con la arquitectura:

Lo que cambia en una fábrica agroalimentaria

Con lavados frecuentes, la humedad entra por conectores y prensaestopas no estancos, y los fallos aparecen tras la limpieza. En fábricas de piensos, el polvo se acumula en armarios y switches mal cerrados. En bodega, la red carga con todo en vendimia, cuando menos se puede parar: los cambios de red se prueban fuera de campaña.

En cualquier fábrica de alimentos, los huecos en el histórico dejan incompleto el registro del lote. Qué pide la ley está en nuestro artículo sobre trazabilidad alimentaria.

Si la causa es la edad del sistema (autómatas sin repuestos, un SCADA en un sistema operativo sin soporte, drivers que nadie puede actualizar), el diagnóstico acaba en un plan de migración. Cómo se hace sin parar la producción está en la guía de modernización de SCADA y PLC.

Cómo lo trabajamos en ER Ingeniería

Llevamos desde 1981 en instalaciones eléctricas y automatización, y hemos automatizado 45 fábricas agroalimentarias entre fábricas de piensos, bodegas y plantas de alimentación. Cuando una planta pierde comunicación, lo diagnosticamos por capas y en la fábrica. Es lo que cubre nuestro servicio de automatización de bodegas y fábricas de piensos, desde el cuadro eléctrico hasta el software.

Para los datos tenemos SuitER, nuestro software industrial: su módulo SuitER Server conecta la red de autómatas con la red de gestión, recoge los datos en tiempo real y los guarda en base de datos. Para las plantas que ya funcionan, está nuestro servicio técnico SatER.

Fuentes

1. Modbus Organization. (2012). MODBUS Application Protocol Specification V1.1b3 (apdo. 7 y función 03). modbus.org (PDF)
2. Siemens AG. (2022). SIMATIC PROFINET with STEP 7: Function Manual (11/2022, A5E03444486-AM; apdos. 3.1 y 6.4). cache.industry.siemens.com (PDF)
3. OPC Foundation. (s. f.). OPC 10000-4: OPC Unified Architecture Part 4: Services (v1.05.07, 5.14.1.1). reference.opcfoundation.org
4. OPC Foundation. (s. f.). OPC Unified Architecture Part 4: Services (v1.04, 7.34.1 StatusCode). reference.opcfoundation.org
5. Wireshark Foundation. (s. f.). CaptureSetup/Ethernet. wiki.wireshark.org
6. Stouffer, K. et al. (2023). Guide to Operational Technology (OT) Security (NIST SP 800-82r3; apdos. 6.2.1.3 y 6.2.12). csrc.nist.gov
7. Mills, D., Martin, J., Burbank, J. y Kasch, W. (2010). RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification. IETF. rfc-editor.org
8. Wireshark Foundation. (s. f.). Display Filter Reference: Modbus/TCP (y las de PROFINET IO y OpcUa Binary Protocol). wireshark.org