Redundancia de WinCC en grupo de trabajo: configuración de DCOM

# Configuración de redundancia en caliente WinCC 7.5 en grupo de trabajo: Guía paso a paso

Una planta cerámica utiliza un sistema SCADA basado en Siemens WinCC 7.0 desde 2013. La infraestructura hardware consta de servidores HP ProLiant DL380p Gen8 con Windows Server 2008R2 y controladores S7-300/400. El objetivo: actualizar a WinCC 7.5 SP2 Update 15 en Windows Server 2012R2 sin hardware nuevo, implementar redundancia en caliente entre dos servidores en modo grupo de trabajo, y garantizar conmutación transparente en la estación cliente.

Clonamos el sistema en dos servidores idénticos tras una actualización intermedia. Una red backbone dedicada (10.10.10.x) gestiona el latido entre servidores, mientras la red principal (192.168.0.x) se encarga de la sincronización de datos y comunicación con PLC. El cliente ejecuta WinCC Runtime Advanced con cambio automático de servidor.

Configuración de servidores y red

| Componente | Servidor 1 | Servidor 2 | Cliente |

|------------|------------|------------|---------|

| Nombre | SCADASERVER1 | SCADASERVER2 | SCADACLIENT0 |

| SO | Windows Server 2012R2 | Windows Server 2012R2 | Windows Server 2012R2 |

| WinCC | 7.5 SP2 Upd15 | 7.5 SP2 Upd15 | 7.5 SP2 Upd15 (Cliente) |

| SQL | 2016 SP3 | 2016 SP3 | 2016 SP3 |

| Red principal | 192.168.0.1 | 192.168.0.2 | 192.168.0.3 |

| Backbone | 10.10.10.1 | 10.10.10.2 | — |

La backbone usa una conexión directa para monitorear el estado del compañero, mientras la sincronización de etiquetas y archivos se realiza por la red principal.

Paso 1: SIMATIC Shell para comunicación entre servidores

WinCC 7.5 tiene la comunicación remota desactivada por defecto. En SIMATIC Shell, activa:

• Terminal Bus (red principal 192.168.0.x) — para clientes y PLC.
• Configuración de redundancia (backbone 10.10.10.x) — para latido.

Asigna IPs en el Editor de Redundancia y Shell. Los servidores se reconocieron mutuamente y el estado se mostró correctamente.

Paso 2: Configuración DCOM en grupo de trabajo

Al iniciar Runtime, apareció el error RedundancyAgent: Initialization of Remote Communication failed. El problema: DCOM en modo grupo de trabajo requiere configuración manual de autenticación sin dominio.

2.1. Servicios bajo Administrador

Cambia la cuenta para CCRedundancyAgent-Service:

• Abre services.msc.
• Inicio de sesión → Esta cuenta → .\Administrador (mismas contraseñas en ambos servidores).

LocalSystem carece de identidad de red para DCOM.

2.2. Permisos DCOM

dcomcnfg → Servicios de componentes → Mi equipo → Propiedades:

Seguridad COM → Permisos de acceso (Límites y Predeterminado):

• Todos: Permitir acceso local/remoto.
• ANONYMOUS LOGON: Permitir acceso local/remoto.

Permisos de inicio y activación (Límites):

• Administradores: todos Permitir.
• Todos: todos Permitir.
• ANONYMOUS LOGON: todos Permitir.

Inicio y activación (Predeterminado):

• SYSTEM, Administradores, Administrador: todos Permitir.

ANONYMOUS LOGON es necesario para iniciar conexiones, seguido de verificación de cuenta.

2.3. Propiedades predeterminadas

• Habilitar COM distribuido: ✓
• Nivel de autenticación predeterminado: Conectar.
• Nivel de suplantación predeterminado: Identificar.

2.4. LocalAccountTokenFilterPolicy

UAC filtra el token de Administrador local. Desactívalo:

New-ItemProperty -Path "HKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System" `
    -Name "LocalAccountTokenFilterPolicy" -Value 1 -PropertyType DWORD -Force

Reinicia WinCC Runtime.

2.5. Archivo hosts para resolución de nombres

DCOM depende de nombres NetBIOS. Agrega en C:\\Windows\\System32\\drivers\\etc\\hosts en ambos servidores:

10.10.10.1 SCADASERVER1
10.10.10.2 SCADASERVER2
192.168.0.1 SCADASERVER1
192.168.0.2 SCADASERVER2

Desactiva NetBIOS sobre TCP/IP en adaptadores de red principal (mantenlo activado en backbone).

Paso 3: Editor de redundancia WinCC

Crea el proyecto de redundancia:

• Nuevo proyecto en Servidor1.
• Editor de Redundancia → Agregar Servidor → especifica SCADASERVER2.
• Parámetros de conexión: tiempo de espera latido 5s, retraso conmutación 10s.
• Sincroniza Runtime en Servidor2 (Servidor1 como principal).

Etiquetas, archivos y scripts se replican automáticamente. Verifica estado: Maestro/Espera.

Paso 4: Configuración del cliente

En SCADACLIENT0:

• Instala WinCC Runtime Advanced.
• Agrega ambos servidores al proyecto.
• Runtime → Selección automática de servidor: prioridad Servidor1, reserva Servidor2.

Probamos la conmutación: al apagar Servidor1, el cliente cambió a Servidor2 en 15 segundos sin pérdida de datos.

Paso 5: Implementación en producción

Tras pruebas en laboratorio, lo desplegamos en la planta. Copias de seguridad antes de cada cambio. La sincronización con PLC en vivo transcurrió sin problemas. Monitorea logs WinCC_Sys_XX.log de cerca.

Lecciones clave:

• En modo grupo de trabajo, DCOM es el cuello de botella: 80% del tiempo en permisos y tokens.
• La backbone es esencial para latido, no para datos.
• Archivo hosts + ajustes NetBIOS resuelven 90% de problemas de resolución de nombres.
• Prueba conmutación en laboratorio con PLC reales.
• Aplica cambios simultáneamente en ambos servidores.

Esfuerzo total: 2 semanas en lab, 3 días en producción. Costo de migración inferior a configurar dominio.

— Editorial Team