FHX DeltaV : comparer, relire et tracer chaque modification de configuration

Sur une installation en exploitation, le risque d'une modification DeltaV tient rarement à la modification elle-même. Il tient à ce que personne n'a remarqué : un paramètre changé par erreur, une ancienne version d'un module réintroduite, une correction rapide faite pendant un arrêt et jamais documentée.

Les exports FHX offrent un moyen simple et robuste de voir exactement ce qui change, avant et après une modification. Pas de logiciel particulier ni de suppositions : simplement un usage discipliné d'un fichier que tout système DeltaV sait produire. Voici comment nous l'utilisons sur nos projets.

Qu'est-ce qu'un fichier FHX ?

Un fichier FHX est un export texte de la configuration DeltaV : modules, blocs fonctionnels, paramètres, séquences et leurs réglages, écrits sous forme de texte lisible. Conséquence très pratique : n'importe quel outil de comparaison de texte peut montrer les différences entre deux exports, ligne par ligne. Répondre à la question « qu'est-ce qui diffère entre ces deux versions ? » ne dépend plus de la mémoire ni des notes de quelqu'un.

Nous exploitons cette propriété de quatre façons.

1. Comparer deux exports pour voir ce qui a vraiment changé

Comparer un export récent avec la sauvegarde précédente montre la différence réelle entre deux instants, module par module et paramètre par paramètre. C'est le moyen le plus rapide pour :

• confirmer qu'une modification contient ce qui a été demandé — et rien d'autre ;
• détecter des changements faits hors du périmètre prévu, par exemple un réglage de régulateur ajusté sur site ;
• reconstituer l'historique d'un système quand la documentation manque ou n'est plus à jour.

  MODULE  FIC-101
- PID1  GAIN         1.2
+ PID1  GAIN         1.5
  PID1  RESET        30 s
- SEUIL ALARME HAUTE 85 %
+ SEUIL ALARME HAUTE 90 %

La comparaison fonctionne d'autant mieux que les exports sont faits avec méthode : toujours le même périmètre, des noms de fichiers cohérents et un dossier daté, pour pouvoir toujours mettre côte à côte deux exports du même objet.

2. Relire une modification avant qu'elle n'atteigne le système en service

Sur une installation en exploitation, nous préparons et vérifions les modifications à l'écart du système en service chaque fois que c'est possible — sur une copie hors ligne ou sur une machine virtuelle — puis nous exportons le résultat. Avant tout import, cet export est comparé à la configuration actuelle et relu :

• la différence correspond-elle à la demande de modification, point par point ?
• des paramètres, des seuils d'alarme ou des réglages de verrouillage sont-ils touchés alors qu'ils ne devraient pas l'être ?
• la modification est-elle cohérente avec l'analyse fonctionnelle et la liste des paramètres ?

Cette relecture peut être faite par un second ingénieur qui n'a pas réalisé la modification — exactement ce qu'exige le principe des quatre yeux. La mise en œuvre est ensuite planifiée avec l'exploitation, comme toute autre modification sur une installation en service.

3. Préparer des modifications en masse de façon cohérente

Certaines modifications concernent des dizaines d'objets semblables : le même texte d'alarme sur toutes les pompes, le même paramètre sur tous les modules de vannes, une nouvelle convention de nommage. Les reprendre un par un à la souris est long et source d'erreurs. Comme l'export est du texte, des modifications semblables peuvent être préparées de façon homogène puis vérifiées par comparaison : chaque objet modifié doit présenter la même différence attendue — et rien d'autre.

C'est la comparaison qui rend la démarche sûre. Une modification en masse qu'on ne peut pas relire ligne par ligne n'a pas sa place sur une installation en service.

4. Garder un historique propre : quoi, quand et pourquoi

Un export daté avant et après chaque modification, rangé avec la référence de la demande de modification, constitue un historique lisible par tous :

• quoi — la comparaison entre les deux exports ;
• quand — les dates des exports et de la mise en œuvre ;
• pourquoi — la demande de modification, l'écart ou le point de punch list qui l'a déclenchée.

Quand un auditeur, un client ou un collègue demande pourquoi un seuil d'alarme a été déplacé, la réponse prend quelques minutes au lieu de quelques jours.

Pourquoi c'est essentiel pour la gestion des modifications

La gestion des modifications (MOC) d'un système de contrôle consiste à savoir que ce qui est configuré est bien ce qui a été approuvé. Un usage discipliné des exports FHX soutient chaque étape :

• analyse d'impact — la comparaison montre toute l'étendue d'une modification, pas seulement la partie dont on se souvient ;
• approbation — les relecteurs approuvent une différence concrète, pas sa description ;
• mise en œuvre — l'export pris après la modification enregistre la configuration telle qu'elle est désormais ;
• audit — l'archive des exports et des demandes de modification répond encore aux questions des années plus tard.

Dans les environnements réglementés, en pharma GMP notamment, cette traçabilité n'est pas facultative. Mais en chimie ou en oil & gas aussi, c'est elle qui permet à une équipe de modifier une installation en service en toute confiance.

En résumé

Les exports FHX transforment les modifications de configuration en quelque chose que l'on peut voir, relire et archiver. Utilisés avec un peu de méthode, ils rendent la gestion des modifications plus sûre et les audits plus sereins. Besoin d'un ingénieur supplémentaire pour des modifications sur un système DeltaV en service ? Découvrez nos prestations d'ingénierie DeltaV.