Un zoom sur le SRC

Le SRC est l’outil de conduite des dispatchings régionaux depuis le début des années 2010.

Ses spécifications ont été réalisées en interne en s’appuyant sur le retour d’expérience du CRC.

• Ergonomie :
  • Une attention particulière a été portée à la cohérence des conventions au niveau de toute l’application (icones, couleurs, types de tracé, clignotements et mode d’appel des images.
  • La taille des caractères, leurs couleurs, l’impact du fond d’écran sur la lisibilité ont fait l’objet de maquettage
  • La densité des images a fait l’objet de réflexions pour trouver un juste compromis entre le fait de vouloir disposer d’un maximum d’informations sur une image et la lisibilité de cette image, notamment en période de stress.
  • Un retour d’expérience de l’exploitation sous contrôle du CRC à Saint Quentin a amené a privilégier la répétitivité des gestes plutôt que l’utilisation de raccourcis contextuels, qui trop nombreux perdent l’opérateur, notamment en période de stress.

• Synthèse des alarmes ;

L’expérimentation de la synthèse d’alarme en temps réel par système expert a montré son efficacité mais aussi sa fragilité aux multiples données de description du système de protection. La plus-value par rapport à un système plus simple et plus robuste n’a pas été jugée suffisante pour que ce système soit reconduit. Par contre un système simple de synthèse permet de réduire considérablement le nombre d’alarmes affichées (et donc à acquitter) facilite la prise en compte des défauts sans risque d’erreurs.

• La télécommande.

L’expérimentation de Saint Quentin a montré l’intérêt des télécommandes par listes et par ordres de fonction. Néanmoins, il a été mis en évidence qu’il fallait se limiter aux ordres et aux topologies les plus courants, pour éviter une complexité des dialogues de télécommande. Il a été en effet jugé plus pertinent et plus efficace de traiter les cas particuliers par ordres élémentaires pour simplifier les dialogues des cas plus généraux et plus courants.

• Le dimensionnement:
  • En termes de téléinformations et d’ouvrages a fait l’objet d’études s’appuyant sur les structures prévisionnelles de réseaux
  • En termes de flux plusieurs catégories de flux ont été examinés. Les flux nominaux, les flux d’incidents de moyennes ampleurs, les flux de grande ampleur en associant à chaque type de flux des exigences différentes en matière de temps de réponse. Pour les flux de grande ampleur plusieurs cas différents ont été examinés : un incident généralisé (beaucoup d’informations remontent au moment de l’incident puis le réseau étant hors tension, la période qui suit est calme.) des incidents type tempête au cours desquels les événements se succèdent sur de longues périodes, les incidents de type réseaux de transmission qui peuvent amener à des situations très chargées suite à des battements des informations remontées.
  • En termes d’activité opérateur qui ajoute, en général, à un événement externe des actions opérateurs fréquentes voire a des sollicitations multiples du type répétition d’une demande d’image, suite à une durée plus longue des temps de réponse du système.

La réalisation a été confiée à un industriel et le processus qui a abouti à la réception du système n’a pas été moins laborieuse que ceux conduits pour les systèmes réalisés en interne.

Les points durs dans la réalisation

Au-delà de la réalisation du logiciel selon les exigences fonctionnelles du cahier des charges, plusieurs points ont été particulièrement délicats à satisfaire :

• La tenue des performances. Les exigences en matière de performance ont amené à reprendre à plusieurs reprises la conception de sous-ensembles et la modélisation de certaines données.
• Le basculement transparent de calculateur, bien que déjà réalisé sur des systèmes antérieurs a été délicat à mettre au point, la mécanique de synchronisation de deux machines amenant à un goulot d’étranglement altérant les performances du SRC.
• Le volume de logiciels qui a rendu délicat les cohérences des diverses corrections et s’est traduit par l’apparition de récessions lors des montées de versions.