Ce qui a plus ou moins bien marché dans le projet SRC

Ce qui a bien marché :

  •    L’organisation à RTE avec un projet national et un projet par région chargé de piloter le peuplement de la base de données, l’aménagement des locaux, la formation des dispatcheurs et la migration.
 
  •    La gestion des relations avec le fournisseur qui a été poussée à un haut niveau de formalisation et de mémorisation, condition sine qua non pour ne pas être asphyxié par le volume d’informations. Les échanges de toute nature (fiche d’anomalie, fiche de demande d’évolution, fiches questions/réponses, fournitures documentaires, PV, etc.) ont été gérés en configuration. Un gestionnaire de faits technique (1) , partagé avec le fournisseur, même été mis en place. Il ne sera pas de trop pour gérer les 7500 anomalies découvertes de 2003 à 2009. De plus, pendant les phases difficiles, les relations courantes entre les chefs de projet respectifs ont été complétées par des relations entre leurs managements respectifs et entre les directions de RTE et THALES.
  •     La gestion des données d’une façon générale :
  1. Le système de configuration, malgré un retard à la livraison, a donné satisfaction par la suite,
  2. Le volume de travail représenté par le peuplement initial de la base de données a été maîtrisé : la majeure partie des données alphanumériques du SIRC a pu être importée et le travail de constitution de l’imagerie a été réduit grâce à la génération automatique des images de poste et de cellule.
  • le formalisme du cahier des charges s’est révélé extrêmement efficace. La numérotation initiale de 10 en 10 a permis de gérer sans problème les adjonctions. La couverture des recettes en a été améliorée (lien tests-exigences). D’une façon générale la gestion des modifications en a été facilitée, ce qui a permis de tenir à jour le cahier des charges tout au long du projet et de le conserver en tant que référence contractuelle. On peut toutefois s’interroger sur le niveau de détail du dit cahier des charges, il a été un plus pour obtenir les fonctionnalités souhaitées, mais il a été consommateur en ressources RTE pour sa création et son suivi.
  • Les moyens d’essai fournis par RTE :
 
  1. L’utilisation du Simulateur d’entrainement des dispatcheurs (SIDERAL) en tant que simulateur de réseau électrique a permis de valider efficacement la fonction télécommande si bien qu’il n’y aura pas de mauvaises surprises sur site.
  2. La mise au point de la connexion à ARTERE, identifiée au départ comme un point délicat a été conduite sans difficulté grâce aux émulateurs fournis (EMC, EMA)(2) et à l’utilisation du réseau d’essai ARTERE pour les tests d’interfonctionnement.
  • La formation des dispatcheurs avec là encore l’utilisation du simulateur d’entrainement des dispatchers(SIDERAL) pour simuler le comportement du réseau électrique.

Ce qui a moins bien marché :

  • La réalisation du SCADA proprement dit. Le nombre très élevé d’anomalies laisse à penser que le fournisseur a préféré  présenter en recette des versions insuffisamment validées, plutôt que de risquer des pénalités pour retards. De plus le contrat ne prévoyait pas de tests d’endurance en usine (ils ont été ultérieurement ajoutés par voie d’avenant). Autant THALES parviendra à corriger rapidement les anomalies fonctionnelles, autant les anomalies liées à la conception du système seront particulièrement difficiles à corriger. Bien souvent, il sera nécessaire de mettre en place une instrumentation spécifique pour relever des traces et avancer dans l’analyse. Les problèmes les plus marquants ont été les suivants :
 
  1. Les performances,
  2. La robustesse,
  3. Des cas de désynchronisation du maître et de l’esclave,
  4. Des fuites mémoires (3),
  5. Des retards à l’affichage d’alarmes, des figeages d’écran,
  6. Des pertes de données opérateur lors de la mise en service d’une nouvelle base de données.

A l’exception des aspects performance et robustesse, tous ces problèmes ont été rencontrés sur le site pilote, ce qui montre que l’environnement de tests et la composition des plates-formes de tests n’étaient pas suffisamment représentatifs d’un site.

  • L’intégration des fonctions avancées dans les matériels de fournisseur. Là aussi, la découverte de nombreuses anomalies liées à la conception du système perturberont le déroulement de cette étape :
  1. Récurrence irrégulière ou arrêt intempestif de la chaîne cyclique,
  2. Mauvaise remontée dans le SRC des alarmes élaborées par la chaîne cyclique,
  3. Etc.
  • Le travail de paramétrage dans la base SRC et dans les bases propres aux calculs de réseau aura d’une façon générale été sous-estimé. Il sera amplifié par un changement des règles de nommage des ouvrages dans le SRC.

 

(1) Logiciel de suivi de problèmes permettant de suivre l’avancement de la résolution de ces problèmes. C’est CLEARQUEST qui a été utilisé sur le SRC.

Retour

 

(2) EMC : émulateur Casoar, EMA Emulateur ARTERE.

Retour

 

[3] Les process censés rendre la mémoire après utilisation ne le font pas, ce qui provoque au bout d’un certain temps de fonctionnement un épuisement de la mémoire disponible et une dégradation des performances par l’abus de swap.

Retour

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *