Retour à l'accueil

Redondance WinCC en groupe de travail : configuration DCOM

Cas de mise en œuvre Hot Standby Siemens WinCC 7.5 en groupe de travail sur équipement ancien. Configuration détaillée DCOM, SIMATIC Shell, réseau backbone et basculement client. Solution pour productions sans infrastructure domaine.

Hot Standby WinCC sans domaine : cas réel
Advertisement 728x90

# Configuration de la redondance Hot Standby WinCC 7.5 en Workgroup : Guide étape par étape

Une usine de céramique exploite un système SCADA sous Siemens WinCC 7.0 depuis 2013. La configuration matérielle repose sur des serveurs HP ProLiant DL380p Gen8 avec Windows Server 2008R2 et des automates S7-300/400. L'objectif : passer à WinCC 7.5 SP2 Update 15 sur Windows Server 2012R2 sans nouveau matériel, mettre en place une redondance Hot Standby sur deux serveurs en mode workgroup, et assurer un basculement transparent sur la station client.

Nous avons cloné le système sur deux serveurs identiques après une mise à niveau intermédiaire. Un réseau backbone dédié (10.10.10.x) gère le heartbeat entre serveurs, tandis que le réseau principal (192.168.0.x) s'occupe de la synchronisation des données et de la communication avec les automates. Le client utilise WinCC Runtime Advanced avec commutation automatique des serveurs.

Configuration des serveurs et du réseau

| Composant | Serveur 1 | Serveur 2 | Client |

Google AdInline article slot

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

| Nom | SCADASERVER1 | SCADASERVER2 | SCADACLIENT0 |

| OS | Windows Server 2012R2 | Windows Server 2012R2 | Windows Server 2012R2 |

Google AdInline article slot

| WinCC | 7.5 SP2 Upd15 | 7.5 SP2 Upd15 | 7.5 SP2 Upd15 (Client) |

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

| Réseau principal | 192.168.0.1 | 192.168.0.2 | 192.168.0.3 |

Google AdInline article slot

| Backbone | 10.10.10.1 | 10.10.10.2 | — |

Le backbone utilise une connexion directe pour surveiller l'état des partenaires, tandis que la synchronisation des tags et archives se fait via le réseau principal.

Étape 1 : SIMATIC Shell pour la communication serveur

WinCC 7.5 désactive par défaut la communication distante. Dans SIMATIC Shell, activez :

  • Terminal Bus (réseau principal 192.168.0.x) — pour les clients et automates.
  • Paramètres de redondance (backbone 10.10.10.x) — pour le heartbeat.

Attribuez les adresses IP dans l'éditeur de redondance et Shell. Les serveurs se sont reconnus mutuellement, et l'état s'affiche correctement.

Étape 2 : Configuration DCOM en mode Workgroup

Le lancement du Runtime a généré l'erreur RedundancyAgent: Initialization of Remote Communication failed. Problème : en mode workgroup, DCOM nécessite une configuration manuelle d'authentification sans domaine.

2.1. Services sous Administrateur

Modifiez le compte pour le service CCRedundancyAgent-Service :

  • Ouvrez services.msc.
  • Connexion → Ce compte → .\\Administrateur (mots de passe identiques sur les deux serveurs).

LocalSystem n'a pas d'identité réseau pour DCOM.

2.2. Permissions DCOM

dcomcnfg → Services aux composants → Mon ordinateur → Propriétés :

Sécurité COM → Permissions d'accès (Limites & Par défaut) :

  • Tout le monde : Accès local/distant Autoriser.
  • CONNEXION ANONYME : Accès local/distant Autoriser.

Permissions de lancement et d'activation (Limites) :

  • Administrateurs : tout Autoriser.
  • Tout le monde : tout Autoriser.
  • CONNEXION ANONYME : tout Autoriser.

Lancement et activation (Par défaut) :

  • SYSTEM, Administrateurs, Administrateur : tout Autoriser.

CONNEXION ANONYME est requis pour initier les connexions, suivi de la vérification du compte.

2.3. Propriétés par défaut

  • Activer COM distribué : ✓
  • Niveau d'authentification par défaut : Connexion.
  • Niveau d'impersonation par défaut : Identifier.

2.4. LocalAccountTokenFilterPolicy

UAC filtre le jeton Administrateur local. Désactivez-le :

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

Redémarrez WinCC Runtime.

2.5. Fichier hosts pour la résolution de noms

DCOM repose sur les noms NetBIOS. Ajoutez dans C:\\Windows\\System32\\drivers\\etc\\hosts sur les deux serveurs :

10.10.10.1 SCADASERVER1
10.10.10.2 SCADASERVER2
192.168.0.1 SCADASERVER1
192.168.0.2 SCADASERVER2

Désactivez NetBIOS sur TCP/IP sur les adaptateurs du réseau principal (gardez activé sur le backbone).

Étape 3 : Éditeur de redondance WinCC

Créez le projet de redondance :

  • Nouveau projet sur Serveur1.
  • Éditeur de redondance → Ajouter serveur → spécifiez SCADASERVER2.
  • Paramètres de connexion : délai heartbeat 5 s, délai de basculement 10 s.
  • Synchronisez Runtime sur Serveur2 (Serveur1 principal).

Les tags, archives et scripts se répliquent automatiquement. Vérifiez l'état : Master/Standby.

Étape 4 : Configuration client

Sur SCADACLIENT0 :

  • Installez WinCC Runtime Advanced.
  • Ajoutez les deux serveurs au projet.
  • Runtime → Sélection automatique du serveur : priorité Serveur1, repli Serveur2.

Nous avons testé le basculement : l'arrêt de Serveur1 a commuté le client vers Serveur2 en 15 secondes sans perte de données.

Étape 5 : Déploiement en production

Après tests en labo, déploiement en usine. Sauvegardes avant chaque modification. Synchronisation avec automates en service sans accroc. Surveillez attentivement les journaux WinCC_Sys_XX.log.

Points clés :

  • En mode workgroup, DCOM est le goulot d'étranglement : 80 % du temps sur permissions et jetons.
  • Le backbone est essentiel pour le heartbeat, pas pour les données.
  • Fichier hosts + ajustements NetBIOS résolvent 90 % des problèmes de résolution de noms.
  • Testez le basculement en labo avec automates réels.
  • Appliquez toutes les modifications de façon synchrone sur les deux serveurs.

Effort total : 2 semaines en labo, 3 jours en production. Coût de migration inférieur à la mise en place d'un domaine.

— Editorial Team

Advertisement 728x90

Lire ensuite