|
Redondance
|
Principe
Lorsqu’un poste de supervision est
défaillant, l’opérateur se trouve "dans le noir" et ne peut plus assurer la
conduite du procédé. Les données ne sont plus enregistrées dans les historiques,
et on perd la traçabilité.
Le traitement
MULTIPOSTES
(1) permet de concevoir une application d'ensemble traitée sur
plusieurs postes comme une application UNIQUE,
en affectant les traitements à tel ou tel poste. Cette répartition améliore les
performances en partageant les temps de traitement et limite les risques: la
défaillance d'un poste n'affecte pas le traitement des données des autres
postes. La configuration se fait depuis un seul poste, et l'application est
automatiquement diffusée à tous les postes du réseau.
Le fonctionnement en
REDONDANCE permet, lorsqu'un poste est défaillant ou lorsque la
communication avec un équipement est interrompue, de basculer automatiquement,
sans intervention de l'opérateur, les traitements correspondants sur un autre
poste. Lorsque l'élément défaillant redevient actif, un dialogue entre poste
principal et poste de secours permet de rétablir automatiquement un
fonctionnement normal et de rendre cohérentes les données des deux postes.
|
Fonctionnement
Définir au niveau de chaque variable élémentaire quel est le poste assurant le
traitement normal et quel est le poste assurant le traitement en secours
conduirait à alourdir inutilement les applications. Grâce à sa structure
originale de base de données utilisant un découpage par blocs de données
(feuilles de calcul), TOPKAPI Vision permet d'effectuer les déclarations de
traitement en principal et en secours par blocs de données, induisant un
surcroît de paramétrage négligeable par rapport à une application classique,
tout en préservant la souplesse d'adaptation aux différents besoins.
Concrètement, lors de la déclaration d'un équipement (automate), il suffit
d'indiquer (voir figure ci-contre) quel est le poste assurant le dialogue avec
cet équipement à titre principal et à titre de secours (2).
Les blocs de données (feuilles de calcul) associées à cet équipement seront
traités par le poste principal (situation normale) ou par le poste secondaire
(défaillance du réseau d'acquisition ou du poste principal).
Il est néanmoins possible d'adresser indifféremment toute variable au sein de
n'importe quel bloc de données de l'application.

Par
exemple :
Le poste P1 acquiert et traite les données de l'automate A1 en
tant que poste principal, et le poste P2 joue le rôle de poste de secours 1
Le poste P3 acquiert et traite les données de l'automate A2
Au sein du bloc de données de l'automate A2 (poste P3), il est
fait référence au mot M23 de l'automate A1. Le poste P3 demande la valeur de ce
mot au poste P1 ou P2 qui est en service opérationnel, et traite la donnée.
La déclaration globale au niveau des équipements, qui simplifie
grandement le paramétrage, ne nuit ainsi en rien à la souplesse et à
l'efficacité du système puisque l'acquisition des données sur le bus de terrain
passe par construction obligatoirement par le poste P1 ou le poste P2.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Fonctions et services
Configuration
Hormis la déclaration du poste principal et secondaire pour chaque équipement
décrite ci-dessus, il n'y a rien à faire de particulier au stade de la
configuration: l'application se configure comme une application normale. A la
sauvegarde, l'opérateur est invité à choisir entre une sauvegarde locale
(sauvegarde intermédiaire) et une diffusion sur tous les postes du réseau en vue
d'une prise en compte immédiate. Dans ce dernier cas les postes du réseau sont
relancés pour une prise en compte des modifications; cette relance s'effectue de
façon décalée de sorte qu'il y a toujours un poste actif et qu'aucune donnée ne
sera perdue.
Exploitation
En fonctionnement normal, le poste principal assure seul le traitement. Les
données sont bien UNIQUES et non générées en parallèle par deux postes pour
garantir une totale cohérence. Le poste secondaire peut être utilisé comme poste
de conduite et se comporte en client du poste principal.
Le poste principal informe en permanence le poste secondaire des modifications:
variables automates, consignes internes, acquittements, informations
d'historiques, etc. de sorte que le poste secondaire dispose en permanence d'une
base de données identique à celle du poste principal, et se trouve prêt à
prendre le relais (3).
Les autres postes du réseau qui se comportent en clients pour les données
traitées par ces postes s'adressent automatiquement au poste en mesure de leur
fournir les données, ce qui rend le basculement totalement transparent pour
l'utilisateur.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Conception des architectures
Le système permet la redondance tant des postes de conduite que des réseaux
d'acquisition et des automates.
L'architecture du système doit être conçue en fonction des niveaux de sécurité
attendus, des effets induits par la défaillance de chacun des composants et de
la probabilité de défaillance de ces composants.
REDONDANCE
SUPERVISION
Dans un système classique où un seul poste traite les données, la défaillance de
ce poste rend le système totalement aveugle.
Une première étape consiste donc à
rendre le poste de supervision redondant, d'autant plus que cette opération
n'est pas très coûteuse en termes de temps de mise en œuvre.
Dans l'exemple ci-dessous, il faut tenir compte de la possibilité de disposer de
plusieurs postes de supervision sur le même réseau d'automates, en fonction du
protocole utilisé. Le poste secondaire interroge en effet à un rythme ralenti
les automates pour avertir d'éventuels défauts de communication.
REDONDANCE RÉSEAU D'AUTOMATES
Dans l'exemple ci-dessus, il peut y avoir un ou plusieurs réseaux d'automates.
S'il y en a plusieurs, une défaillance d'un réseau n'affecte pas toute
l'installation; dans le cas contraire, le système est totalement aveugle. On
peut par exemple concevoir alors le schéma ci-contre.
AUTOMATES
REDONDANTS
Lorsque les automates sont également redondants, on aura le schéma ci-contre.
Dans tous les cas, n'hésitez pas à solliciter AREAL pour valider vos
architectures.
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - -
Particularités télégestion
Lorsque les équipements ne sont pas reliés en permanence au superviseur
(télégestion), un éventuel basculement de poste pour cause de défaillance
d'acquisition ne se produit pas dans les mêmes conditions.
APPELS ENTRANTS
Lorsqu'un équipement distant appelle le système de supervision, l'appel peut
aboutir sur le poste secondaire dans des conditions normales de fonctionnement,
par exemple lorsque toutes les lignes du poste principal sont occupées.
Sur appel entrant d'un équipement aboutissant sur le poste principal , celui-ci
traite normalement les données.
Sur appel entrant d'un équipement aboutissant sur le poste secondaire, celui-ci
traite les données (comme s'il intervenait en secours), puis les deux postes
synchronisent leurs données.
Les équipements distants doivent être paramétrés pour permettre l'appel du
deuxième poste dans des conditions satisfaisantes (appels d'un ou plusieurs
modems sur le poste principal, prise en compte de lignes groupées, nombre de
tentatives avant appel du second poste).
APPELS SORTANTS
Le poste principal et le poste secondaire dialoguent en permanence pour
s'assurer qu'ils se "voient". Si le poste secondaire ne "voit" plus le poste
principal, il se déclare poste principal et exécute directement les ordres qui
lui sont transmis.
Si le poste principal ne parvient pas à établir la liaison avec un équipement
distant, après un certain nombre de tentatives, le poste secondaire est
automatiquement déclaré poste principal pour cet équipement (équivalent d'une
rupture de liaison pour un équipement local), et il traite les demandes de
connexion pour cet équipement ainsi que les données reçues.
(1) En tant que fonctionnalité intégrée à l'option redondance de TOPKAPI [retour]
(2) Pour la version 16 bits, les données sont regroupées par port d'acquisition,
c'est à dire en pratique par groupe d'équipements appartenant à un même réseau.
Il convient d'en tenir compte, car cela crée quelques contraintes dans la
conception des architectures réseau.[retour]
(3) En version 16 bits, la réplication des données d'historiques n'est pas
permanente mais doit être programmée dans l'application.[retour]
|