Recommandations pour une gestion de configuration

Principe

Le cas des applications multiples partageant un référentiel commun est un mode de fonctionnement satisfaisant pour la gestion de configuration. Il permet en une fois de modifier une configuration et de voir se répercuter la modification sur les systèmes consommateurs. C’est la mutualisation de la configuration, qui permet d’éviter les discordances entre la réalité terrain et la vision que plusieurs systèmes peuvent en avoir.
Ce principe met en évidence l’importance du rôle d’un “ configurateur ”, administrateur de la configuration et garant du référentiel. Pour atteindre son objectif, le configurateur doit utiliser une application de gestion de la configuration qui permette de s’assurer de la maîtrise des évolutions du référentiel dans le temps.

Contraintes et inconvénients

Contrainte 1 : Ce principe nécessite une organisation dans la production des systèmes utilisateurs. Il faut en effet que les spécifications de l’application de gestion de configuration et en particulier de la base de données de configuration soient définies avant le développement des applications utilisatrices. Ce cas est encore très rare pour des raisons historiques.
Contrainte 2 : Si la modification du référentiel nécessite l’arrêt / relance d’un système, ce principe peut devenir contraignant dans la mesure où des modifications de référentiel utiles pour un système ne le sont peut être pas pour un autre. Ce problème reste mineur.

Applications multiples et référentiels multiples

Le SIER en est l’exemple le plus frappant.

Principe

Ce cas est le plus fréquent car il est la conséquence d’une évolution historique des applications de gestion de trafic. En effet, les premiers systèmes de gestion de trafic ont commencé par traiter l’acquisition / supervision de leurs équipements, d’où le développement de premières applications informatiques. Plus tard, dans bien des cas, les données générées par les stations de recueil ont fait naître des besoins d’analyse statistique, qui ont été traités en développant un système d’archivage complémentaire. D’autres systèmes ont continué a être mis en place parallèlement, comme la GMAO, la prévision, la diffusion d’information au public, etc. ,qui sont venu “ compléter ” les systèmes existants.
La plupart du temps, pour des raisons de simplification et de coûts, un référentiel spécifique a été développé pour chacun de ces systèmes. En effet, une fois développés, les systèmes antérieurs ne pouvaient plus modifier leur structure de référentiel, sauf à reprendre globalement le codage de toutes les fonctions existantes.
Cela reste valable aujourd’hui: le référentiel est la base de l’application SAGT. Il faut considérer qu’une modification de structure d’un référentiel existant (par exemple, modification de la description des équipements) est une opération très coûteuse, risquée et nécessitant une procédure très rigoureuse de reprise de l’application consommatrice.
Certains sites SAGT traitent jusqu’à plus de 50 applications sur 150 machines réparties sur 4 sites (cas de Sirius en Ile de France).

Contraintes et inconvénients

Les difficultés sont multiples. Voici les principaux écueils :
• Chaque application disposant d’une configuration, un gestionnaire de configuration doit être désigné pour chaque application, ou au mieux, un seul gestionnaire de configuration doit se former à chacun des systèmes, avec pour objectif d’assurer la logique de l’ensemble. Ceci nécessite une bonne connaissance du fonctionnement interne de chacune des applications.
• Une modification du terrain doit être répercutée “ n ” fois, autant que de systèmes impactés. Cela rend très difficile la gestion de configuration , dans la mesure où la traçabilité d’une modification a des effets sur plusieurs systèmes. Il est difficile de garantir qu’aucune application n’a été oubliée ou mal traitée quand des SAGT sont répartis sur plusieurs sites géographiques.
• Dans le pire des cas, la modélisation adoptée dans tel ou tel référentiel peut rendre impossible la mise en cohérence des différentes applications. (Par exemple, la définition de tronçons pour la prévision de trafic est incompatible avec la définition des tronçons utilisés pour la représentation des points de comptage pour le superviseur).
• L’opération de synchronisation des référentiels doit parfois se faire dans un ordre déterminé, pour que les différentes interfaces puissent continuer à fonctionner.
STERIA / CERTU 46 Mai 2000
Référentiels de données dans les SAGT Recommandations pour une gestion de configuration

Application unique et référentiels multiples

CORALY dans son échange inter-SAGT et le SIER dans son partage sur plusieurs sites s’inscrivent dans ce cas de figure.
Ce cas de figure correspond aux applications de coordination de l’exploitation entre plusieurs SAGT. Le système de coordination va alors utiliser les référentiels des différents SAGT en imposant une interface de communication. Le système n’adresse pas directement les bases des systèmes à coordonner, mais procède à une synchronisation des référentiels en spécifiant le mode d’échange. Une application d’interfaçage assure le protocole d’échange. En pratique, chacun des n sites à coordonner doit donc disposer d’une passerelle entre le système existant et le système de coordination, au format imposé ce site.
Ce principe est applicable dans la mesure où les données utilisées par le site de coordination sont des données de haut niveau (référentiel de coordination). Il n’a pas besoin de connaître tous les détails des configurations, le site de coordination impose donc ce qu’il souhaite obtenir et sollicite les sites “ fils ” pour l’alimenter.
Ce mode de fonctionnement est correct. Il a pour avantage de forcer une unification des structures des référentiels transmis par chacun des sites. Il participe dans une certaine mesure à une mise en cohérence de haut niveau. En effet, il impose une uniformisation des notions métiers et une synchronisation de l’évolution des référentiels.

AXES DE RESOLUTION DES PROBLEMES

Les axes de résolution précisés ci-dessous doivent être adaptées à chaque cas particulier et ne constituent bien sûr pas des remèdes miracles aux écueils évoqués précédemment.

Solution de partage de référentiel

Le partage de référentiel est une solution consistant à fédérer l’ensemble d’un référentiel autour d’une application de gestion de référentiel, qui distribue celui-ci sur des applications clientes qui utilisent des données communes.

Solution organisationnelle

Comme nous l’avons évoqué précédemment, la solution organisationnelle pour gérer au mieux les problèmes de gestion de référentiel partagé passe par la mise en œuvre des mesures suivantes : Bien séparer les responsabilités entre le service maintenance et l’exploitation.
Le service maintenance doit être positionné comme responsable unique par rapport à l’évolution du référentiel, chargé de la responsabilité de maintenir le référentiel. C’est ce même référentiel qui est utilisé communément par la GMAO et les SAGT. Les référentiels concernés ici sont le référentiel terrain et et le référentiel équipements.
• Une organisation particulière doit être mise en œuvre quand les services techniques en charge de la maintenance sont des sous-traitants externes. Il faut dans ce cas préciser dès le début de la prestation les modalités de reporting des actions faites sur le terrain, afin de s’assurer d’une bonne maîtrise de l’état « terrain » et « équipements ».
Une fois les référentiels terrain et équipement mis à jour, le responsable du système SAGT doit évaluer les impacts sur les référentiels métier et coordination.
Dans l’expression des nouveaux besoins des utilisateurs et le développement de nouveaux systèmes, ou lors de l’évolution de systèmes existants, l’interfaçage avec le référentiel doit être considéré avec précision et constituer un des critères de choix fondamentaux.
• A chaque modification de référentiel, une sauvegarde doit être effectuée. La mise en exploitation d’une nouvelle version est accompagnée de la définition de cette version en y associant les différences par rapport à la précédente, ainsi que les causes qui ont conduit à faire évoluer le référentiel.

Solution fonctionnelle

La solution fonctionnelle consiste à prévoir dans les applications en développement le principe de référentiel partagé. Dans ce cas, il est indispensable de spécifier et développer une application de gestion de configuration qui intégrera les règles de GC qui auront été préconisées par l’exploitant.

Solution technique

La technique utilisée pour mettre en œuvre la solution de référentiel partagé peut prendre la forme suivante :
Le “ lien logique ” correspond à une requête distante d’un des systèmes à un serveur centralisant la base de données. La requête se fait pour le système utilisateur de façon similaire à une requête locale. Seule la connexion à la base a permis de spécifier que la base est localisée sur une machine tierce accessibles via TCP/IP. Cette technique est utilisable sur réseau TCP/IP à partir de la plupart des SGBD du marché (Oracle, Informix, SQLServer, …)
Le point faible de cette solution est que si la base centrale est en panne, l’ensemble des systèmes liés sont bloqués. Pour traiter ce problème, il est possible de dupliquer la base de données. La base centrale reste maître, les bases des autres systèmes sont alimentées par des mises à jours transmises par réseau (sous forme de “ snapshots ” ou de fichiers). L’intégrité du référentiel central reste assurée puisqu’il est reproduit sur les différents systèmes.