Sur beaucoup de projets d'automatisme, la logique tourne pour la première fois face à quelque chose qui ressemble à un procédé … pendant la mise en service. L'équipe de site attend, le planning est tendu et les opérateurs découvrent leurs écrans. La mise en service virtuelle avance ce moment de plusieurs mois.

Nous faisons tourner la vraie configuration du système de contrôle — DeltaV ou Siemens — avec les synoptiques, sur une machine virtuelle VMware reliée à une simulation simple du procédé. Rien n'est encore câblé, et c'est tout l'intérêt. Mais une machine virtuelle seule ne prouve rien : ce qui compte, c'est ce qu'on y teste. Voici les cinq domaines que nous passons systématiquement en revue avant de tirer le premier câble, et pourquoi chacun d'eux est payant en FAT, en SAT et au démarrage.

Ce que contient la machine virtuelle

Trois couches qui dialoguent entre elles, exactement comme elles le feront sur site :

  • Les synoptiques opérateur — les vues, faceplates et la navigation qu'utilisera la salle de contrôle ;
  • La configuration du système de contrôle — la vraie configuration DeltaV ou le vrai programme d'automate Siemens, pas une maquette écrite pour l'essai ;
  • Une simulation du procédé — des niveaux, débits, températures et retours d'équipements qui réagissent à la logique, pour que les séquences puissent réellement avancer.
Machine virtuelle
Synoptiques opérateur identiques à la salle de contrôle Configuration du contrôle DeltaV · Siemens — le vrai programme AI PID AO Simulation du procédé niveaux · débits · températures Image VMware — hors ligne, sans matériel
Les trois couches de la machine virtuelle : synoptiques, vraie configuration et simulation du procédé.

Le modèle du procédé n'a pas besoin d'être un simulateur dynamique haute fidélité. Son rôle est de faire avancer la logique : une cuve se remplit quand une vanne s'ouvre, une pompe répond à son ordre de marche, une température monte quand le chauffage est actif. Le niveau de détail est convenu au début du projet, unité par unité.

1. Les séquences, pas à pas

Chaque séquence est déroulée de son étape initiale à son étape finale, et chaque transition est confrontée à l'analyse fonctionnelle. Concrètement :

  • chaque condition de transition est volontairement rendue vraie et fausse, pas seulement une fois sur le chemin nominal ;
  • chaque action de chaque étape est vérifiée : quelle vanne s'ouvre, quelle pompe démarre, quelle consigne est écrite ;
  • chaque temporisation est contrôlée, y compris son comportement quand on quitte l'étape avant la fin ;
  • les arrêts momentanés, reprises et sauts d'étape, s'ils existent, laissent les équipements dans un état défini.

Une séquence REMPLISSAGE → CHAUFFE → TRANSFERT paraît simple sur le papier. Sur la machine virtuelle, on trouve vite la condition manquante qui la fait passer en TRANSFERT alors que le chauffage est encore actif.

2. Les situations anormales

La plupart des problèmes de séquence sur site n'apparaissent pas en marche normale. Ils apparaissent quand quelque chose tourne mal. Nous provoquons donc volontairement des défauts dans la simulation :

  • une pompe déclenche en marche (P-101 perd son retour de marche) ;
  • une vanne n'atteint pas sa position ouverte dans le temps attendu ;
  • un instrument passe en mauvaise qualité ou hors gamme ;
  • l'opérateur suspend, abandonne ou relance la phase au milieu d'une étape ;
  • une utilité est perdue — air instrument, alimentation d'un package — puis revient.

Pour chaque cas, la question est la même : que fait ensuite la séquence, que voit l'opérateur, et comment l'unité revient-elle dans un état sûr, prêt à redémarrer ? Si la réponse n'est pas écrite dans l'analyse fonctionnelle, c'est une question de conception. Il coûte bien moins cher d'y répondre au bureau qu'en pleine nuit pendant le démarrage.

3. Les verrouillages et permissifs

Les verrouillages protègent les personnes et les équipements : ils méritent leur propre campagne de tests, distincte des séquences. Avec la base alarmes et verrouillages comme référence, nous vérifions chaque ligne :

  • la cause déclenche bien l'effet, avec la temporisation prévue s'il y en a une ;
  • le réarmement est celui décrit : automatique, manuel ou après acquittement ;
  • les permissifs bloquent le démarrage quand ils le doivent, et l'opérateur voit lequel manque ;
  • les shunts (bypass), quand ils sont autorisés, sont visibles et limités à ce que prévoit la conception.

Le résultat est un relevé ligne par ligne montrant que chaque verrouillage fait ce que dit la base. Ce relevé sert de point de départ aux essais formels de la FAT.

4. Les alarmes

Les alarmes sont testées autant pour leur contenu que pour leur fonctionnement. Chaque alarme doit apparaître avec la bonne priorité et un message qu'un opérateur comprend sans ouvrir de manuel. Nous regardons aussi ce qui se passe pendant une perturbation : un seul déclenchement ne doit pas noyer l'opérateur sous une avalanche d'alarmes en cascade. Les scénarios de défaut simulés sont l'endroit idéal pour repérer ces avalanches et les corriger — règles de suppression, meilleur regroupement, ou simplement suppression des alarmes dont personne n'a besoin.

5. Les synoptiques

Enfin, les synoptiques sont testés comme les opérateurs les utiliseront : navigation entre les vues, faceplates, tendances, accès aux alarmes et surtout ce que voit l'opérateur quand quelque chose tourne mal. Dérouler les scénarios anormaux avec un futur opérateur ou un chef de quart au clavier est l'une des séances les plus utiles du projet. La machine virtuelle devient alors un outil de formation des opérateurs bien avant le démarrage : le premier jour, les écrans leur sont déjà familiers.

Ce que cela change en FAT, en SAT et au démarrage

Chaque défaut trouvé sur la machine virtuelle est une surprise de moins par la suite. La FAT n'est plus le premier passage complet de la logique : elle confirme quelque chose qui a déjà été éprouvé. En SAT et au démarrage, l'équipe peut se concentrer sur ce qui ne se simule pas : le câblage terrain, les instruments, les équipements mécaniques et le procédé réel. Après le démarrage, la machine virtuelle reste utile pour former les nouveaux opérateurs et tester les modifications hors ligne avant de les charger sur l'installation en service.

En résumé

La mise en service virtuelle n'est pas une démonstration. C'est une campagne de tests structurée — séquences, cas anormaux, verrouillages, alarmes et synoptiques — menée sur la vraie configuration tant que les modifications coûtent peu. Pour voir comment nous la mettons en place sur les projets DeltaV et Siemens, consultez notre page sur la mise en service virtuelle ou nos prestations d'ingénierie DeltaV.

Une nouvelle unité, une extension ou une migration en vue ?

Décrivez-nous votre projet : nous vous montrerons comment une machine virtuelle s'y intégrerait.

Demander une démo