Une bonne analyse fonctionnelle, c'est la FAT la moins chère de votre projet

Sur beaucoup de projets DCS, le cahier des charges fonctionnel est rédigé tôt, approuvé, puis discrètement dépassé par la configuration. Au moment de la FAT, plus personne ne sait très bien lequel des deux a raison.

Nous travaillons dans l'autre sens. L'analyse fonctionnelle est assez précise pour configurer à partir d'elle, et assez précise pour tester à partir d'elle. Quand la configuration est terminée, le document devient le script de test — et la FAT vérifie le système par rapport à un texte que tout le monde a déjà lu et approuvé.

Pourquoi la précision est rentable

Chaque ambiguïté d'une analyse fonctionnelle sera tranchée par quelqu'un : le programmeur à son bureau, le testeur pendant la FAT ou l'opérateur au démarrage. Plus c'est tard, plus c'est cher. Une phrase comme « la pompe s'arrête si le niveau est bas » laisse beaucoup de questions ouvertes : quel niveau, avec quelle temporisation, la pompe redémarre-t-elle seule, y a-t-il une alarme, et que fait la séquence pendant ce temps ? Une bonne analyse fonctionnelle répond à ces questions avant que le premier module soit configuré.

Ce que contient chacune de nos analyses fonctionnelles

Un SFC ou un GRAFCET par séquence

Chaque séquence est dessinée en SFC (ou en GRAFCET) avec :

• chaque action écrite dans son étape : quelle vanne, quelle pompe, quelle consigne ;
• chaque condition de transition écrite en entier, temporisations et instruments compris ;
• les états initial et final clairement identifiés.

SFC · Phase batch

Écrit ainsi, le diagramme se lit aussi bien par l'ingénieur procédé que par le programmeur et le testeur — et chaque transition devient un pas de test.

La liste des paramètres

Chaque valeur réglable — consignes, temporisations, seuils, limites d'alarme — est listée avec son unité, sa plage et sa valeur par défaut. La liste sert de référence pour la configuration et pour les tests, puis pour l'exploitation, le jour où quelqu'un demande pourquoi une temporisation a telle valeur.

La base alarmes et verrouillages

Une ligne par alarme ou par verrouillage, avec sa cause, son effet, sa priorité et ses règles de shunt et de réarmement. La base est la source unique pour la configuration, les protocoles de test et la documentation opérateur. La tenir dans un tableau structuré, plutôt qu'éparpillée dans des paragraphes de texte, est ce qui rend possible un test systématique.

Ce qui se passe en cas de défaut, d'abandon et de reprise

C'est la partie qui manque le plus souvent, et celle qui pose le plus de problèmes au démarrage. Pour chaque séquence, l'analyse précise :

• ce qui se passe quand un équipement tombe en défaut pendant une étape — une pompe qui déclenche, une vanne qui ne s'ouvre pas ;
• ce que fait un abandon, et dans quel état il laisse les équipements ;
• comment, et à partir d'où, la séquence peut reprendre : depuis le début, depuis l'étape interrompue, ou seulement après des vérifications par l'opérateur.

Pas seulement le fonctionnement nominal : c'est dans les cas dégradés qu'une installation passe ses pires nuits.

Comment l'analyse devient le script de la FAT

Une fois ces éléments en place, le protocole de test s'écrit presque tout seul :

1. chaque transition du SFC donne un pas de test : établir la condition, vérifier le changement d'étape et les actions ;
2. chaque ligne de la base alarmes et verrouillages donne un test : créer la cause, vérifier l'effet, la priorité et le réarmement ;
3. chaque cas de défaut, d'abandon et de reprise donne un test de situation anormale ;
4. la liste des paramètres donne les valeurs à contrôler dans la configuration.

La traçabilité est intégrée d'office : chaque test renvoie à une ligne de l'analyse. Pendant la FAT, chaque écart est clair — soit la configuration ne respecte pas le document, soit le document doit évoluer — et les deux cas sont consignés.

Faire vivre le document

Une analyse fonctionnelle n'est utile que si elle reste vraie. Les modifications découvertes pendant les tests, la mise en service ou des évolutions ultérieures sont reportées dans l'analyse, avec un indice de révision et une courte description de ce qui a changé. La configuration et le document restent alignés, et le prochain ingénieur qui rejoint le projet — ou qui modifie l'installation des années plus tard — part d'une référence fiable. Pour les modifications sur un système DeltaV en service, comparer les exports de configuration avant et après chaque modification boucle la boucle (voir notre article sur les exports FHX).

En résumé

Un SFC ou un GRAFCET avec des actions et des conditions complètes, une liste des paramètres, une base alarmes et verrouillages, et les cas de défaut, d'abandon et de reprise écrits noir sur blanc : voilà ce qui fait d'une analyse fonctionnelle la FAT la moins chère de votre projet. Découvrez nos prestations de configuration et de documentation DeltaV.