Deux types de redondance

Le module BMENUA0100 prend en charge les types de redondance suivants :

  • Architecture Hot Standby, qui décrit les UC redondantes.

  • Redondance de serveur OPC UA, qui décrit l'utilisation de modules BMENUA0100 redondants.

La redondance de serveur OPC UA, qui est gérée par les modules BMENUA0100, est conforme à la norme OPC UA de redondance de serveur non transparente en mode de basculement à chaud.

Ces deux types de redondance peuvent être combinés. Les modèles suivants sont pris en charge :

  • Un PAC autonome contenant deux modules BMENUA0100.

  • Deux PAC à redondance d'UC (Hot Standby) contenant chacun un ou deux modules BMENUA0100.

Redondance OPC UA

Dans une architecture OPC UA de redondance de serveur non transparente en mode de basculement à chaud, il incombe au client OPC UA d'établir les sessions et de gérer les communications avec les serveurs redondants. Les sessions à établir comprennent une session active avec le serveur primaire et une session inactive avec le serveur secondaire (redondant). Le client doit configurer ces deux sessions pour inclure les mêmes éléments surveillés.

Il incombe également au client OPC UA de vérifier l'état des deux serveurs via la variable SERVICE_LEVEL et de commuter la communication vers le serveur qui présente le meilleur état d'après la valeur de cette variable.

La norme OPC UA stipule que l'activation des communications s'effectue en réglant le mode de surveillance des différentes sessions sur la valeur correcte. Le mode de surveillance des serveurs est contrôlé par le client OPC UA et la procédure de réglage de ce mode dépend de l'implémentation du client. Pour plus d'informations sur le réglage du mode de surveillance, reportez-vous à la documentation du client.

Ce principe est général et s'applique à toute architecture, y compris à l'architecture de redondance d'UC (Hot Standby).

Le schéma suivant représente un client OPC UA connecté à une paire de serveurs OPC UA redondants (chacun étant intégré dans un module BMENUA0100). Le client a désigné comme serveur actif celui qui présente la valeur SERVICE_LEVEL la plus élevée :

Redondance d'UC

Dans une configuration de redondance d'UC (Hot Standby), deux (2) modules BMENUA0100 au maximum peuvent être installés dans chaque rack local principal Hot Standby. Chaque module BMENUA0100 est configuré avec une adresse IP statique unique. Les modules BMENUA0100 conservent leurs adresses IP respectives et n'échangent pas d'adresses IP lors d'un basculement ou d'une permutation Hot Standby.

NOTE : Sur un système redondant, vérifiez que les modules BMENUA0100 des PAC primaire et secondaire :

Le système n'effectue pas automatiquement ces vérifications.

Le DDT du module BMENUA0100 inclut la variable SERVICE_LEVEL, qui fournit à la CPU des informations concernant l'état du serveur OPC UA dans le module BMENUA0100. Le client OPC UA est informé de l'état du serveur OPC UA via la variable SERVICE_LEVEL, laquelle est disponible en tant que variable OPC UA.

NOTE : Incluez toujours la fonction élémentaire READ_DDT en vue de mettre à jour le DDT de chaque module BMENUA0100. Dans une configuration Hot Standby, ajoutez READ_DDT à une section de code qui s'exécute lorsque l'UC est en mode redondant. Cette conception envoie les informations de diagnostic de BMENUA0100 échangeables entre les UC primaire et secondaire. L'application peut utiliser ces informations pour exécuter une vérification de la cohérence des services et configurations de la cybersécurité pris en charge pour les modules BMENUA0100 des UC primaire et secondaire.

Si le DDT T_M_ECPU_HSBY de l'UC redondante et son élément CMD_SWAP sont rendus disponibles en tant que variables IHM dans un système SCADA, l'application SCADA peut déclencher une permutation en écrivant dans la variable OPC UA mappée appropriée dans le BMENUA0100.

Dans un système redondant, le module BMENUA0100 qui gère les communications OPC UA avec le système SCADA peut être celui qui est situé dans le rack local secondaire (redondant). C'est pourquoi vous devez sélectionner l'attribut Echange sur l'automate redondant pour toutes les variables d'application scrutées pour assurer la cohérence des valeurs des variables entre les PAC primaire et redondant.

De plus, pour maintenir la cohérence, les applications des deux PAC redondants doivent être synchronisées.

Dans de rares cas (principalement si le bit ECPU_HSBY_1.PLCX_ONLINE est défini sur false manuellement ou par programme), l'un des PAC du système redondant peut être en mode attente (Wait). Dans ce mode, ce PAC (secondaire) n'est pas synchronisé avec le PAC primaire et les variables lues par ce PAC sont inexactes. L'état du PAC de réponse peut être surveillé via les champs suivants du DDT du T_M_ECPU_HSBY :

  • T_M_ECPU_HSBY_1.LOCAL_HSBY_STS.WAIT

  • T_M_ECPU_HSBY_1.LOCAL_HSBY_STS.RUN_PRIMARY

  • T_M_ECPU_HSBY_1.LOCAL_HSBY_STS.RUN_STANDBY

  • T_M_ECPU_HSBY_1.LOCAL_HSBY_STS.STOP

Le système redondant permet aux deux PAC de fonctionner durant l'exécution de différentes applications. Pour assurer la cohérence des variables entre les PAC primaire et redondant, la configuration des données des deux PAC doit être cohérente, comme indiqué par le champ DDT T_M_ECPU_HSBY :

  • T_M_ECPU_HSBY_1.DATA_LAYOUT_MISMATCH = false

NOTE : Lorsque la redondance OPC UA est configurée, il est recommandé de vérifier par programme les DDT des modules afin de s'assurer de la cohérence des services pris en charge et des configurations de cybersécurité entre les modules BMENUA0100.
NOTE : Dans les sections suivantes de cette rubrique, le contenu provient du document suivant :

OPC Unified Architecture Specification Part 4: Services, Release 1.04, abrégé ci-après en OPC UA Part 4 suivi de la référence de la section. Le texte issu de ce document et traduit en français est en italique.

Prise en charge OPC UA pour serveurs, clients et réseaux redondants

OPC UA permet la redondance des serveurs, clients et réseaux. OPC UA fournit les structures de données et les services qui permettent de réaliser la redondance de façon standardisée.

La redondance des serveurs permet aux clients de disposer de plusieurs sources pour obtenir les mêmes données. La redondance des serveurs peut être obtenue de plusieurs façons, certaines nécessitent l'interaction du client, d'autres non. Les serveurs redondants peuvent être mis en place sur des systèmes sans redondance de réseaux ou de clients. Les serveurs redondants peuvent aussi coexister sur des systèmes avec redondance de réseaux et de clients...

La redondance de client permet à des clients configurés de façon identique de fonctionner comme un client unique, mais tous les clients n'obtiennent pas les données à un moment donné. En principe, il n'y a aucune perte d'information en cas de basculement de client. Les clients redondants peuvent être mis en place sur des systèmes sans redondance de réseaux ou de serveurs. Les clients redondants peuvent aussi coexister sur des systèmes avec redondance de réseaux et de serveurs...

La redondance de réseau permet à un client et un serveur de disposer de plusieurs chemins de communication pour obtenir les mêmes données. Les réseaux redondants peuvent être mis en place sur des systèmes sans redondance de serveurs ou de clients. Les réseaux redondants peuvent également coexister sur des systèmes avec redondance de client et de serveur... OPC UA Part 4, section 6.6.1.

Redondance de serveurs

Les deux principaux modes de redondance de serveurs sont : transparent et non transparent.

En redondance transparente, le basculement des responsabilités du serveur d'un serveur à l'autre est transparent pour le client. Le client ne détecte pas le basculement et n'a aucun contrôle sur le fonctionnement du basculement. De plus, le client n'a pas à effectuer des actions supplémentaires pour continuer à envoyer ou recevoir des données.

En mode non transparent, le basculement d'un serveur à l'autre et les actions pour continuer à envoyer et recevoir des données sont effectués par le client. Le client doit connaître le serveur redondant défini et doit effectuer les actions nécessaires pour bénéficier de la redondance de serveurs.

L'objet ServerRedundancy... indique le mode pris en charge par le serveur. Le type ServerRedundancyType et ses sous-types TransparentRedundancyType et NonTransparentRedundancyType ... fournissent des informations sur le mode de redondance pris en charge. OPC UA Part 4, section 6.6.2

Comme indiqué ci-dessus, le serveur OPC UA intégré au module BMENUA0100 prend en charge la redondance de serveur non transparente en mode de basculement à chaud.

Mode de basculement à chaud du serveur OPC UA

En mode de basculement à chaud, le ou les serveurs secondaires peuvent être actifs, mais ne peuvent pas se connecter aux points de donnés réels. Par conséquent, un seul serveur peut consommer des données de l'application Control Expert. La variable ServiceLevel ... indique la capacité du serveur à fournir ses données au client. OPC UA Part 4, section 6.6.2.4.4

Lors d'un basculement, une action du client OPC UA est nécessaire, le serveur OPC UA intégré au BMENUA0100 devient inactif :

Fonctionnement du basculement du client

Chaque serveur gère une liste des identifiants URI (ServerUris) de tous les serveurs inclus dans l'ensemble de serveurs redondants (Redundant Server Set).

NOTE : Un ensemble Redundant Server Set inclut les serveurs OPC UA configurés pour assurer la redondance dans l'application Control Expert.

La liste est fournie avec le mode de basculement (Failover) dans l'objet ServerRedundancy. Pour permettre aux clients de se connecter à tous les serveurs de la liste, chaque serveur de la liste doit fournir la description de l'application (ApplicationDescription) pour tous les serveurs de l'ensemble Redundant Server Set via le service FindServers. Le client a besoin de ces informations pour convertir l'URI du serveur (ServerUri) en informations permettant la connexion aux autres serveurs de l'ensemble Redundant Server Set. Par conséquent, un client doit se connecter à un seul serveur redondant pour trouver les autres serveurs via les informations fournies. Un client doit conserver les informations sur les autres serveurs de l'ensemble Redundant Server Set. OPC UA Part 4, section 6.6.2.4.5.1

Exemples d'options du client en mode de basculement à chaud :

  • Lors de la première connexion, en plus des actions sur le serveur actif :

    • Connexion à plusieurs serveurs OPC UA.

    • Création de souscriptions et ajout d'éléments surveillés (Monitored Item).

  • Lors d'un basculement :

    • Activation de l'échantillonnage des souscriptions.

    • Activation de publication.

Les clients qui communiquent avec un ensemble de serveurs Redundant Server Set non transparent requièrent de la logique supplémentaire pour gérer les défaillances de serveur et enclencher le basculement sur un autre serveur de l'ensemble Redundant Server Set. La figure suivante présente les étapes de la première connexion d'un client à un ensemble Redundant Server Set.

Le serveur initial peut être déterminé via la fonction de découverte standard ou via une liste de serveurs dans l'ensemble Redundant Server Set. Dans tous les cas, le client a besoin de vérifier à quel serveur de l'ensemble il doit se connecter. Les actions particulières dépendent du mode de basculement fourni par le serveur et du mode de basculement utilisé par le client.

Une fois connecté à un serveur redondant, le client doit connaître les modes de basculement pris en charge par le serveur puisque cela détermine les options disponibles concernant le comportement du client. Un client peut toujours traiter avec un serveur en utilisant un mode de basculement inférieur (un client peut se connecter à un serveur qui fournit la redondance de type Hot Redundancy et choisir de le traiter comme s'il s'exécutait en mode Warm Redundancy ou Cold Redundancy. Ce choix appartient au client. Dans le cas du mode de basculement HotAndMirrored, le client ne doit pas utiliser le mode de basculement Hot ou Warm car cela générerait une charge superflue sur les serveurs. OPC UA Part 4, section 6.6.2.4.5.1

Mode de basculement à chaud du client  OPC UA

En mode de basculement à chaud (Warm), le client doit se connecter à un ou plusieurs serveurs de l'ensemble Redundant Server Set principalement pour surveiller le niveau de service (ServiceLevel). Un client peut se connecter et créer des souscriptions et des éléments MonitoredItem sur plusieurs serveurs, mais les fonctions d'échantillonnage et de publication peuvent être actives sur un seul serveur.. Cependant, le serveur actif renvoie des données réelles, tandis que les autres serveurs de l'ensemble Redundant Server Set vont renvoyer une erreur correspondante pour les MonitoredItem dans la réponse de publication (Publish), par exemple Bad_NoCommunication. L'unique serveur actif peut être identifié par lecture de la variable ServiceLevel sur tous les serveurs.

Le serveur ayant le plus haut niveau de service (ServiceLevel) est le serveur actif. Pour le basculement, le client active l'échantillonnage et la publication sur le serveur qui présente le plus haut niveau de service (ServiceLevel). La figure 30 représente les étapes effectuées par un client lors de la communication avec un serveur en utilisant le mode de basculement à chaud (Warm).

OPC UA Part 4, section 6.6.2.4.5.3