La sûreté de fonctionnement a certainement été une préoccupation majeure du SDART : il était hors de question de détériorer la situation antérieure, et on pouvait légitimement se demander si l’utilisation de nouvelles techniques informatiques permettrait de relever le défi.

Le SDART a donc fixé des exigences de niveau élevé, en termes de fiabilité (au travers du taux de défaillance, typiquement de l’ordre de quelques pannes par an pour l’ensemble du système de téléconduite) et de maintenabilité (au travers du temps moyen de réparation du système, typiquement de l’ordre de quelques heures). S’agissant de la sécurité, c’est-à-dire la capacité du système à ne pas conduire à des accidents inacceptables, les exigences se déclinaient ainsi : pas de transmission d’information erronée sans le savoir ; pas d’ordre intempestif, à défaut ne rien faire.

Les réponses ont porté sur les différents éléments de la chaine de téléconduite, selon une approche globale de l’ensemble du système.
Si on admettait de ne pas doubler les calculateurs de postes asservis (les PA), on a dû recourir au doublement des calculateurs de niveau supérieur (les PC de PCG, de même que les calculateurs régionaux et ceux du centre national).

L’autotest des équipements informatiques

Le recours à l’autotest a apporté un gain important dans la sûreté de fonctionnement.
Les tests pratiqués automatiquement par les équipements eux-mêmes concernaient leurs fonctions vitales, et avaient pour objectif de déclencher une alerte auprès de l’exploitant pour l’informer d’un dysfonctionnement et de la nécessité de procéder à une réparation. Dans le cas des équipements doublés au PC, outre la fonction d’alerte de l’exploitant, la détection d’un défaut grave provoquait l’arrêt de l’équipement incriminé et le basculement automatique sur l’équipement de secours.

On peut mentionner quelques exemples d’autotests.

Le test des commandes de changement de position d’organe.
Comment s’assurer que la télécommande d’un organe fonctionnera correctement lorsqu’on en aura besoin, alors que cet organe (disjoncteur ou actionneur) est rarement actionné ? Une réponse consiste à injecter périodiquement un ordre bref, de durée suffisante pour tester en retour sur la bobine du relais de déclenchement que l’ordre a été émis, puis d’envoyer immédiatement l’ordre inverse avant que l’organe n’ait eu le temps de prendre ces ordres en compte. Une défaillance du dispositif de commande sera ainsi détectée et la réparation effectuée avant que son utilisation réelle ne soit requise.

Le test global d’un calculateur.
Il est évidemment illusoire de prétendre tester en permanence l’ensemble des fonctions d’un calculateur. Des études en ont d’ailleurs prouvé l’impossibilité, tant les causes de pannes sont nombreuses, à commencer par celles qui peuvent affecter l’outil de test lui-même…
Une solution retenue sur les premiers PC de PCG consistait à implanter un programme extrêmement simple au niveau de priorité le plus bas de la machine : ce programme réalisait une boucle permanente d’activation / désactivation d’un signal externe (en l’occurrence l’allumage de voyants sur le pupitre du calculateur). En cas de surcharge prolongée du calculateur, signe d’un dysfonctionnement grave, ce signal externe n’était plus activé, et un équipement externe, appelé « bac de commutation », chargé de surveiller ce signal, détectait ainsi la panne du calculateur, et pouvait lancer le calculateur de secours.
Ce dispositif, très simple et très fiable, perdure aujourd’hui.

Ces principes généraux ont été conçus dès l’origine du SDART, et progressivement améliorés par la suite. Ils sont encore en application dans leurs grandes lignes.

Le test des équipements avant leur mise en service

Il va de soi que le meilleur autotest n’aura les effets attendus que si l’équipement testé a été mis en service dans un état de bon fonctionnement.
Pour s’en assurer, il faut s’être préalablement assuré en amont que l’équipement «prototype » qui préfigure l’ensemble des équipements d’un même modèle, est bien conforme aux spécifications, tant sur le plan technique, fonctionnel, que des performances attendues.

C’est pourquoi le SDART a accordé une grande place aux essais sous leurs différentes formes, dans le cadre d’un processus rigoureux de validation des systèmes et de tests des équipements de série (généralement réalisés par les constructeurs eux-mêmes selon un plan de qualité convenu entre le constructeur et son client)

On notera que le SDART a été l’occasion pour les constructeurs informatiques concernés, de faire des essais dans des domaines qu’ils connaissaient peu jusque-là : essais en température, essais de « compatibilité électro magnétique », essais de résistance aux chocs électriques,…)

On peut aussi noter le soin particulier porté à l’interface entre les équipements informatiques et les organes du réseau électrique. A cet effet, la filerie préexistante a été progressivement modifiée en suivant une politique de « paliers techniques » pour des raisons de rigueur technique tout en recherchant l’optimisation économique, la grande difficulté consistant à déterminer le meilleur moment pour passer d’un palier à un autre.

L’utilisation de simulateurs

L’emploi de simulateurs s’est révélé indispensable pour effectuer les différents essais de qualification des prototypes.
Si les tests « manuels » sont suffisants pour réaliser des essais de fonctions élémentaires, il est nécessaire de disposer d’un outil permettant de soumettre l’équipement testé aux différentes situations ou séquences d’évènements susceptibles de se produire dans son environnement réel.
Pour cela, différentes formes de simulateurs d’environnement ont été réalisés, allant des simulateurs reproduisant les comportements « normaux » du réseau de téléconduite aux simulateurs permettant de simuler différents types de pannes.

Ces simulateurs se sont révélés très efficaces pour tester des fonctions complètes, et notamment des séquences d’avalanches d’événements pour vérifier le bon fonctionnement et la tenue en performance des systèmes face à des situations complexes.

On notera, à titre de preuve, que le système de téléconduite s’est très bien comporté lors des tempêtes de fin 1999, malgré les avalanches d’informations à traiter dans des temps très courts.

Des simulateurs de comportement du réseau ont aussi été développés pour remplir une autre fonction, l’entrainement des personnels d’exploitation. Ces simulateurs permettent de générer des scénarios prévus à l’avance par un instructeur pour tester les réactions du stagiaire et le former aux bonnes pratiques. Là aussi, ces outils se sont révélés très intéressants, et ils sont aujourd’hui largement utilisés pour la formation du personnel.