Cómo resolver tormentas del Watchdog de WAN y desconexiones de clientes en buses de terminal de PCS 7 enrutados

En las arquitecturas distribuidas de SIMATIC PCS 7 que abarcan redes de área amplia (WAN) o VLAN enrutadas, los clientes OS pesados (thick clients) se desconectan esporádicamente de los servidores OS, lo que provoca que los gráficos de WinCC se pongan grises y se redibujen continuamente. Este comportamiento es impulsado por los mecanismos internos de watchdog de Simatic Shell: cuando los clientes se separan de los servidores a través de subredes enrutadas con firewalls, cada cliente emite pings ICMP rápidos y latidos (heartbeats) de multidifusión (multicast)/unidifusión (unicast) cada 4 a 5 segundos a cada servidor del multiproyecto. Si la latencia supera los 20 o 50 ms o las tablas de estados del firewall descartan los sockets RPC/DCOM inactivos, WinCC declara un fallo del servidor. Para resolver estos fallos de estabilidad, implemente clientes web dedicados (WinCC WebNavigator / WebUX) para sitios remotos de larga distancia, utilice Servicios de Escritorio Remoto (Remote Desktop Services) o implemente tunelización VPN de Capa 2 con tiempos de expiración TCP de firewall ajustados.

Índice de contenidos

Causa raíz: Mecanismos de Watchdog de Simatic Shell y latencia WAN

La arquitectura del bus de terminal de SIMATIC PCS 7 está diseñada principalmente para redes de área local (LAN) Industrial Ethernet de campus locales, donde la latencia de ida y vuelta es inferior a 1 ms y la pérdida de paquetes es cero.

Para monitorear el estado de salud del servidor y coordinar la conmutación por error (failover) de redundancia, WinCC utiliza Simatic Shell y el servicio CCServerWatchdog:
1. Cada estación transmite latidos UDP en la dirección de multidifusión 224.0.2.0 (Puerto 5227).
2. En sistemas enrutados de múltiples subredes, las estaciones recurren a barridos de pings ICMP de unidifusión y consultas de apretón de manos (handshake) TCP cada 4 a 5 segundos a cada servidor conocido en la lista de servidores.
3. Debido a que todos los clientes en un centro de despacho central monitorean todos los servidores remotos (incluso aquellos pertenecientes a plantas separadas), decenas de clientes hacen ping simultáneamente a los servidores remotos a través de enlaces WAN, generando cientos de solicitudes ICMP por minuto.
4. Si un solo paquete de ping del watchdog es descartado por un enrutador intermedio o se retrasa más allá del umbral de tiempo de espera interno, WinCC asume que el servidor OS primario está muerto.

Por qué el enrutamiento WAN no administrado causa congelamientos de la interfaz de usuario y redibujos de pantalla

Cuando el temporizador del watchdog expira, el cliente OS entra en una rutina de recuperación de fallos:
* El fenómeno de la pantalla gris: El cliente inicia una desconexión de emergencia, volviendo grises todos los elementos de proceso dinámicos y mostrando Server Disconnected.
* Bucles de reconexión cíclicos: El cliente intenta inmediatamente vincularse al servidor redundante asociado. Ejecuta llamadas a procedimientos remotos de Microsoft (RPC), abre conexiones de sockets TCP a Microsoft SQL Server (Puerto 1433) y vuelve a leer el árbol de imágenes de WinCC.
* Distorsión de la interfaz de usuario (UI): Debido a que este ciclo de desconexión/reconexión ocurre repetidamente (a menudo varias veces por minuto durante una congestión transitoria de la WAN), la interfaz de usuario del cliente restablece continuamente su caché gráfica, desplazando las barras de herramientas de los menús y bloqueando la entrada del operador.

Análisis de recorrido de firewalls y multidifusión (multicast)

La implementación de cortafuegos (firewalls) empresariales de Palo Alto, Fortinet o Cisco entre sitios de plantas remotas y una sala de control central introduce puntos específicos de fallo de protocolos:

Protocolo / PuertoFunción en PCS 7Punto común de fallo en Firewall / WANICMP (Echo Request)Ping de actividad de la estación de Simatic ShellLa protección contra inundaciones o los filtros de limitación de tasa bloquean los pings rápidos, provocando desconexiones falsas.UDP 5227Descubrimiento y coordinación de Simatic ShellLos enrutadores WAN empresariales bloquean la multidifusión IP (224.0.2.0), interrumpiendo el descubrimiento de estaciones.TCP 1433Replicación de base de datos en tiempo real de SQL ServerLos firewalls de inspección de estados descartan las sesiones de bases de datos inactivas sin enviar paquetes TCP RST.TCP 135 y Puertos Dinámicos AltosComunicaciones DCOM / RPC de MicrosoftLa negociación dinámica de puertos RPC falla a través de NAT estricta o inspección de paquetes sin enrutar.

No se admite el ajuste de la tasa de ping dentro de WinCC; la frecuencia de sondeo está codificada de forma rígida en los binarios de tiempo de ejecución compilados.

Método: Selección e implementación de una arquitectura remota aprobada

Para eliminar los bloqueos de comunicación WAN y las tormentas de watchdog, elija una de las tres arquitecturas aprobadas por Siemens:

Opción 1: SIMATIC WinCC WebNavigator / WebUX (Recomendado para larga distancia)

Reemplace los clientes OS pesados en centros de despacho remotos por clientes web:
1. Instale WinCC WebNavigator o WinCC WebUX en el servidor OS del sitio.
2. Publique los gráficos de proceso utilizando el asistente Web View Publisher.
3. Conecte a los operadores de despacho remoto mediante HTTPS estándar (Puerto 443) o un túnel cifrado de intranet corporativa.
4. Ventaja: La comunicación HTTP/HTTPS tolera alta latencia (hasta 500 ms), elimina las tormentas de watchdog ICMP y opera limpiamente a través de firewalls empresariales sin abrir puertos DCOM.

Opción 2: Servicios de Escritorio Remoto de Microsoft (Servicios de Terminal Server de PCS 7)

Implemente un cliente OS local configurado como Host de Sesión de Escritorio Remoto (RDSH) en el sitio de la planta:
1. Instale un cliente OS en el bus de terminal local de la planta.
2. Habilite los Servicios de Escritorio Remoto con la licencia de Terminal Server de PCS 7.
3. Los operadores en la sala de despacho central se conectan al cliente local mediante Microsoft RDP (Puerto 3389).
4. Ventaja: Los datos de proceso y las consultas de watchdog permanecen en la LAN gigabit local; solo los datos de teclado, video y mouse atraviesan la WAN.

Opción 3: Tunelización VPN de Capa 2 (VXLAN / MPLS VPLS) para Clientes Pesados

Si se deben mantener clientes OS pesados en todos los sitios:
1. Implemente un túnel VPN en puente de Capa 2 (como VXLAN o MPLS) entre sitios para presentar un dominio de difusión único.
2. En Simatic Shell, configure todas las estaciones con la configuración de Proxy de Multidifusión coincidente y valores TTL idénticos (TTL >= 4).
3. En los firewalls empresariales, desactive la limitación de velocidad de inundación ICMP para los rangos de IP del bus de terminal de PCS 7.
4. Establezca los tiempos de espera de sesiones inactivas TCP del firewall para el Puerto 135 y el Puerto 1433 en al menos 120 minutos para evitar la terminación de sockets.

Verificación

Para verificar que se restablece la estabilidad del bus de terminal:

En la estación de despacho central, abra Simatic Shell en el Explorador de Windows. Verifique que todos los servidores OS remotos aparezcan en el árbol de navegación con iconos azules activos.
En el registro de tráfico del firewall corporativo / Palo Alto, verifique que las conexiones TCP en los puertos 135, 1433 y 5227 permanezcan establecidas sin indicadores DROP o RESET.
En WinCC Runtime, observe las pantallas del operador continuamente durante 60 minutos:
- Confirme cero eventos de desconexión de pantalla gris.
- Confirme que los banners de alarma se actualizan dentro de 1 segundo de su ocurrencia.
Revise el archivo de diagnóstico de WinCC (Win_Sys_01.log) ubicado en <Project_Dir>\Diagnostics. Confirme la ausencia de advertencias del tipo CCServerWatchdog: Server failure detected.

Limitaciones y precauciones operativas

Límites de latencia para clientes pesados: Los clientes OS pesados de PCS 7 requieren una latencia de red de ida y vuelta estrictamente inferior a 20 ms. Si la latencia de su WAN supera los 20 ms, los clientes pesados experimentarán fallos de sincronización intermitentes independientemente del ajuste del firewall.
Exigencias de ancho de banda: Cada cliente OS pesado requiere un ancho de banda mínimo sostenido de 100 Mbps con baja fluctuación (jitter). Conectar varios clientes pesados a través de una WAN compartida de baja velocidad satura rápidamente el rendimiento disponible.
Separación de buses de planta: Nunca ponga en puente el bus de planta/sistema (comunicación AS-OS) a través de enlaces WAN; el puente WAN debe restringirse completamente al bus de terminal.

Preguntas frecuentes del ingeniero

¿Puedo modificar el intervalo de ping de Simatic Shell en el Registro de Windows?
No. La frecuencia de sondeo de 4 a 5 segundos está incrustada en los componentes del sistema C++ compilados y no se puede alterar mediante modificaciones en el registro.

¿Por qué los clientes en el Sitio X hacen ping a los servidores en el Sitio A que ni siquiera muestran?
Porque todos los clientes OS pertenecen a la misma configuración de multiproyecto. Simatic Shell consulta a todos los servidores definidos dentro de los paquetes de datos de servidor distribuidos (*.pck) para verificar la topología global del proyecto.

¿Aumentar el tiempo de vida (TTL) en Simatic Shell resuelve las desconexiones de la WAN?
Aumentar el TTL permite que los paquetes de multidifusión atraviesen más saltos de enrutador, lo que permite el descubrimiento de estaciones a través de subredes. Sin embargo, no mitiga la latencia de la red ni la pérdida de paquetes.

Referencias técnicas

Entrada ID 109742323 de Siemens Industry Online Support: Manual de configuración y comunicación de PC de SIMATIC Process Control System PCS 7
Manual de configuración de PC de SIMATIC PCS 7 (N.º de documento A5E00278782)
Entrada ID 109809264 de Siemens Industry Online Support: ¿Qué puertos usa PCS 7 y qué reglas de firewall se requieren?