Automatisation : l’analyse fonctionnelle, clé de la réussite d’un projet !

L‘automatisation est souvent un non-sujet dans l’industrie pharmaceutique parce que l’on y présuppose que le fournisseur saura bien délivrer le système, et y compris celui que l’on aura insuffisament spécifié. A rebours de ces idées reçues, cet article montre comment la réalisation d’une analyse fonctionnelle précise, menée avec les acteurs de terrain avec la contribution de l’Assurance Qualité et d’Hygiène, Sécurité et Environnement (HSE), contributeurs majeurs, assure le succès, les démarrages les plus courts, la mise sur le marché la plus rapide, la maintenance la plus réduite.

1. L’inventaire des ateliers

Nombreux sont les acteurs de la production pharmaceutique qui ont constaté, souvent impuissants, les difficultés créées par un système de conduite défaillant. Les problèmes afférents, parfois très pénalisants et leur (s) cause(s) profondes, paradoxalement, sont souvent difficiles à établir. Voici un florilège non exhaustif de ces problèmes :

• Démarrage différé pour un nouveau produit, avec pour conséquence un retard de mise sur le marché

• Système impropre à exécuter ce que la production attendait. Avant réalignement, qui ne vient parfois jamais, les opérateurs pilotent en mode manuel, c’est à dire télécommandé(1) et, pratiquement, il existe alors autant de recettes de fabrication que d’équipes de travail ou même d’individus. Par exemple, quel chimiste expérimenté n’a jamais vu un opérateur reprendre manuellement le contrôle de température d’un réacteur dans une phase délicate comme une cristallisation ou une réaction exothermique ? Qui n’a jamais vu, après une défaillance d’un capteur, terminer le cycle de production entier en mode manuel ?

• Génération de non qualité, en particulier due au point précédent, d’autant que la plupart des systèmes ne permettent pas de tracer précisément ce qu’ont réellement fait les opérateurs en mode manuel. La libération d’un lot peut alors prendre un tour très compliqué car, comme on le sait, l’analyse en laboratoire ne trouve que ce qu’elle cherche…

• Encore plus grave, la génération de risques de type HSE. Une programmation mal contrôlée peut aboutir de fait à l’existence d’une combinaison logique inextricable dans le système et, en cas de défaut d’un capteur, à créer une situation de danger effective et non a priori détectée. Que l’on songe aux accidents survenus récemment sur des avions de ligne par exemple. Le génie chimique n’en est pas non plus à l’abri.

• Heureusement les soucis sont souvent moins graves mais néanmoins pénalisants, eu égard par exemple à la productivité attendue : combien d’opérateurs ont eu par exemple la très mauvaise surprise de découvrir qu’un équipement, qu’ils pensaient pourtant en situation d’être utilisé, était verrouillé par le système pour des raisons incompréhensibles dans la logique de l’opérateur. Et en effet c’est la plupart du temps l’opérateur qui a raison dans sa logique contre le système. Une analyse mal faite conduit à allouer des équipements ou des parties d’équipements trop largement et à empêcher un parallélisme des tâches de l’opérateur, source de baisse de productivité parfois très importante.

« Celui qui ne sait d’où il vient ne sait pas non plus où il va. »
Cet aphorisme souvent entendu a, dans le cas d’un automatisme deux types de conséquences :

• Ne pas savoir d’où l’on vient se manifeste directement par l’impossibilité de prédire le comportement précis du système une fois en fonctionnement. On objectera qu’on aura pourtant dûment qualifié le système. Certes, mais quasiment jamais pour prendre en compte les situations de dysfonctionnement potentielles. « C’est impossible d’aller jusque-là » s’écrient ceux qui ne possèdent ni l’expérience ni la méthodologie pour traiter correctement le problème. L’insuffisance de la spécification se manifestera donc par de très redoutables approximations, flous, impasses et imprédictibilité de comportement dans la vie réelle.

• Se tromper peut-être fécond à condition d’apprendre de ses échecs. L’histoire des systèmes informatiques nous montre que c’est rarement le cas, et l’automatisation est une branche spécifique de l’informatique. Après un échec on change souvent de fournisseur, sans remettre en cause le déroulement du projet qui est très majoritairement la véritable cause des problèmes.

« Donnez et vous recevrez » (La Bible, Luc) : la proposition contraposée, comme diraient les logiciens, étant : celui qui ne donne rien ne recevra rien. Cet autre aphorisme-là s’applique redoutablement et fréquemment à l’automatisation. Une insuffisance d’information peut compromettre les plus grands et parfois les plus coûteux des projets. Je me rappelle ces deux exemples emblématiques.

Soit donc un nouvel atelier de chimie à automatiser, avec un système spécifique à développer comme toujours dans un atelier de chimie où seuls quelques skids arrivent avec leur automatisme propre. Soit aussi l’ambition d’utiliser le système de conduite de manière à ce qu’il puisse apporter une aide précise et rapide à la libération des lots. Soit alors la question posée par l’automaticien au responsable Assurance Qualité assigné au projet : « quels sont les paramètres critiques à prendre en compte dans la conduite ? ». Et soit alors cette réponse, qui traduit un mélange subtil d’incompétence et une forme d’exonération de ses responsabilités : « moi, je ne rentre pas là-dedans, tout ce que je demande c’est que le système soit BPF ». Cela se passait à l’aube de ce siècle mais il n’est pas sûr que ce type de réponse, malgré la mise en place progressive de l’analyse de risques, ne se rencontrerait plus aujourd’hui. Comment s’étonner alors que le système qui en soit résulté n’ait jamais été capable de fournir plus que quelques enregistrements à examiner en superposant sur le papier une règle transparente… comme 20 ans plus tôt.

Parfois, plutôt qu’un refus, c’est une autre réponse, toute aussi annonciatrice de moments douloureux : « On verra au démarrage… » Et en effet on voit… Je me rappelle cet exemple emblématique, celui de la mise en place d’un très gros système dans un atelier de chimie tout neuf, pilotant plus de 20 000 entrées / sorties. Le recueil du besoin avait été tellement lacunaire que ce ne sont pas moins d’une quinzaine de programmeurs, assis à côté des opérateurs, qui ont dû entièrement réécrire le programme sur une durée d’environ 6 mois.

« Le fournisseur n’a pas demandé un euro de plus pour cette prestation » m’annonça-t-on en forme d’exonération. Certes, mais soyons certains qu’il avait pris grand soin, connaissant son client, d’intégrer ces coûts à l’avance. Et n’oublions pas le temps de mise sur le marché du produit, un blockbuster de la société, autrement plus dommageable que le coût des programmeurs. En effet, au démarrage…on avait vu !
La critique est aisée dira-t-on et l’art est difficile, on le sait. Pour autant elle reste pertinente. Mais il faut se garder de stigmatiser l’automaticien ou du moins de le désigner comme responsable unique des problèmes qui surviennent. On l’a vu, l’absence d’une connaissance suffisante du process à automatiser est une situation courante : développement du process insuffisant, rétention de l’information souvent inconsciente, mais surtout, surtout, manque de méthodologie.

« Ce qui se conçoit bien s’énonce clairement » (Boileau).
La maxime s’applique à plusieurs titres au recueil des besoins de l’utilisateur. Les choses commencent le plus souvent bien lorsqu’il s’agit de décrire le comportement du système, c’est à dire en l’absence de survenue de défaut, soit assez rapide à décrire. Mais il en va tout autrement dès qu’il s’agit de décrire le comportement attendu en présence de défaut. C’est là le point d’achoppement le plus fréquent, c’est là que l’on entend le plus souvent la phrase terrible « on verra au démarrage », c’est là que l’on s’apprête à rentrer dans un labyrinthe inextricable au moindre défaut, avec des passages en mode manuel intempestifs, non tracés et qui se terminent parfois par des pertes de production et souvent par des appels à l’astreinte lorsqu’il n’est pas encore trop tard.
Il faut savoir que, pour une application bien faite, le volume du programme destiné à traiter les défauts est plus du double de celui qui traite le comportement standard. On comprend alors combien une analyse lacunaire peut hypothéquer l’avenir d’un système.

Alors, pourquoi nombre de recueil des besoins sont-ils quasi muets sur le traitement des défauts ? Simplement parce que, sans une méthodologie adéquate, cette expression du besoin peut devenir en effet un casse-tête.

Le point d’orgue revient aux systèmes censés être utilisés en R&D. Avec ces systèmes l’opérateur doit tout à la fois pouvoir exécuter à peu près toutes les combinaisons possibles de transferts entre les équipements à sa disposition, doit pouvoir construire des recettes facilement, et pouvoir bien sûr piloter manuellement, en qualité et en sécurité son installation. Un challenge que l’on sait relever, mais qui, pour une équipe d’automaticiens inexpérimentés, peut virer au cauchemar. J’ai ainsi vu un atelier investir 4 millions d’euros, puis 5, pour …. atteindre 7 millions d’euros en ayant entre-temps changé de fournisseur, mais sans pour autant réussir davantage à obtenir ce qu’il voulait. Ce chantier était devenu une punition pour les intervenants qui étaient appelés à y travailler. À peine une spécification paraissait-elle enfin figée que le client demandait une nouvelle modification. Un cas emblématique de non savoir-faire en termes d’analyse du besoin, activité autrement connue sous le nom d’Analyse Fonctionnelle.

« Il faut que tout change pour que rien ne change » (Le guépard)
Faible relation avec l’automatisation pensera-t-on. Pourtant, si l’on observe les grands projets depuis une vingtaine d’années que voit-on ?

• Une augmentation des coûts, parfois vertigineuse
• Une convergence avec les standards informatiques (infrastructure, composants logiciels)
• Une débauche technologique à épater les directeurs industriels en visite ou quelque secrétaire d’État à l’Industrie • Mais, sur le plan fonctionnel, bien trop souvent, la reconduction des mêmes erreurs, signalées plus haut.

Tout cela un peu comme si l’on croyait que changer la technologie de la cuisine améliorerait nécessairement la qualité du plat qui en sortira. On change tout, technologiquement, mais, en fin de compte, la fiabilité et la productivité qui en résultent ne sont pas au rendez-vous. Pire encore ! On a vu s’affirmer, depuis une quinzaine d’années, une nouvelle quête du Graal : celle du dossier de lot électronique, cent fois promis mais presqu’autant de fois manquant au rendez-vous. Or à l’origine de ces échecs fréquents et extrêmement coûteux se trouve essentiellement une énorme lacune d’analyse du procédé automatisé : j’ai vu un grand projet à 50 millions d’euros ne produire aucun résultat pour la très simple raison que le socle de la plupart des systèmes de génération de dossier de lot électronique récupère les données issues des systèmes de conduite. Si ceux- ci génèrent des informations non fiables comme des flots de fausses alarmes, non priorisées de surcroît, alors, ces données seront inexploitables et l’échec sera cuisant et à la mesure des faux espoirs suscités.

 

2. Réaliser une analyse fonctionnelle de qualité

Mais tout d’abord interrogeons-nous sur cette question : qu’est-ce qu’une analyse fonctionnelle de qualité ?

Au sens premier du terme pour la production pharmaceutique, cosmétique ou agroalimentaire pour ne citer que ces activités, c’est satisfaire aux critères qualité. Entre autres mais parmi les plus essentiels citons :

• La prise en compte précise et complète de ce que l’on appelle les paramètres critiques, sans pour autant bien sûr que l’Assurance Qualité en communique la liste officielle, en précisant le caractère contextuel dudit paramètre :

– Dans quelle étape de la fabrication intervient-il ? Ce qui permet de savoir quand on désactive la détection des situations hors spécifications, évitant ainsi la génération de fausses alarmes.
– Quels seuils d’acceptabilité de la valeur du paramètre dans la ou les étapes afférentes ?

• La traçabilité de l’ensemble des opérations exécutées par l’opérateur, y compris lorsqu’il passe en mode dit « manuel ».
• La capacité à monitorer les équipements mais aussi ses paramètres ou états critiques, y compris lorsque le système se trouve à l’état de repos, que l’on songe par exemple qu’après une étape de stérilisation et en attendant le début de fabrication d’un nouveau lot il convient de maintenir la vigilance sur toute intervention, y compris manuelle (télécommande) qui pourrait dégrader l’état sanitaire.
• Enfin, si ce document peut directement devenir une fiche de tests lors de la qualification opérationnelle, alors, on aura fait un pas décisif vis à vis des ressources nécessaires pour qualifier le système et aussi sur le temps de qualification lui-même et éventuellement le time-to-market.

Au sens second du terme qualité, il s’agit de produire un document exempt de toute ambiguïté pour le programmeur, facile à programmer et à tester. Si l’on peut y associer des règles de production du code informatique simples et claires ce sera aussi un grand progrès.

Après ce long préambule, nécessaire pour sensibiliser sur la criticité du sujet, passons si l’on peut dire, aux travaux pratiques.
La méthode que nous allons exposer n’est probablement pas la seule qui permette de mener la tâche à bien. Cependant, forgée par une large équipe pluridisciplinaire et très expérimentée (dont je n’étais pas mais dont j’assume avec plaisir l’héritage), intégrant les retours de dizaines de projets, cette méthode a permis de couvrir avec succès l’automatisation de procédés d’une haute complexité de façon précise, rapide, partagée avec les utilisateurs, de l’opérateur aux responsables Assurance Qualité ou HSE.

 

3. L’analyse fonctionnelle sans peine

3.1 Tout commence avec le P&ID (Process and Instrumentation Diagram)

Soit donc un schéma P&ID, un ou plusieurs opérateurs ou agents de maîtrise appelés à conduire le procédé et… une boîte de surligneurs de couleurs variées.

 

 

Nous choisissons, à des fins pédagogiques, un sous-ensemble de P&ID pour illustrer sans lourdeur la méthodologie.

V1 à V8 sont des vannes de sectionnement (ce dernier adjectif est important, les vannes de régulations ne pouvant faire office d’actionneurs d’interruption du flux fiables). Ce sont des vannes automatiques ou manuelles. P1 est une pompe centrifuge, qui ne peut non plus être considérée comme pouvant interrompre le flux.

Nous prenons un surligneur et nous commençons à suivre le flux, changeant de couleur à chaque rencontre d’un organe de sectionnement ou de délimitation du flux. On englobe l’organe de sectionnement, ci-dessous les vannes V1 et V2.

 

 

 

Nous venons de délimiter un premier élément, nommé module d’équipement (Anglais : Equipment Module) nommé EM1.

Et l’on continue ainsi…

 

 

… jusqu’à achèvement du processus.

 

 

3.2 Décrire le comportement des modules d’équipement

Une fois cette étape achevée l’étape suivante consiste à déterminer, pour chaque module d’équipement, quel doit être son comportement par rapport aux fonctions qu’il peut avoir à accomplir mais aussi lors de la survenue de défauts. Considérons par exemple le module EM2, un réacteur. Il participera principalement à trois fonctions, le remplissage via la vanne V1, la vidange via la vanne V3, la rétention du contenant pendant que s’opérera la réaction. Le comportement en défaut différera selon la fonction. Par exemple une discordance sur la vanne de fond sera à traiter comme un défaut majeur en remplissage ou en réaction alors que le défaut sera mineur en situation de vidange de ce réacteur.

Dans le détail, on déterminera pour chaque module d’équipement (chaque élément « coloré ») quelles sont les conditions à satisfaire pour pouvoir être utilisé par une fonction (ex : aucun actionneur / capteur en défaut, mode automatique activé, état sanitaire satisfaisant)

Cette étape achevée nous disposons, comme on le ferait dans un jeu de Lego, de tous les éléments pour spécifier le comportement des fonctions de génie chimique.

3.3 Décrire le comportement des fonctions de génie chimique

L’allocation des modules d’équipement par les fonctions :

Sur le schéma ci-contre sont figurées trois fonctions. Intéressons-nous à la fonction F3 qui opère le transfert entre les équipements B et C. Pour cela elle doit allouer EM3, EM4 et EM5, allocation figurée par le symbole. Cette allocation est exclusive.

Notons que si, alors que F3 est en cours, l’opérateur voulait démarrer la fonction F2, alors il ne le pourrait : pour cela F2 devrait pouvoir allouer EM2, déjà allouée. Ce mécanisme naturel d’exclusion (on dit d’interlock) est d’une grande simplicité et d’une toute aussi grande clarté et robustesse par rapport à ce que l’on nomme les tableaux d’interlocks.

La description du comportement des fonctions :

Lorsque l’on a ainsi hiérarchisé les éléments la fonction joue exactement le rôle d’un chef d’orchestre qui conduit ses musiciens, les modules d’équipement. Ils possèdent chacun leur partition, la fonction ne fait que les synchroniser en leur communiquant de manière très concise le signal du début de chaque séquence qu’ils doivent exécuter. Que l’on prenne dans l’exemple donné le cas de F3 et l’on s’apercevra que les ordres transmis vers chacun des modules d’équipement sont simplissimes, du genre marche / arrêt. Et ceci est loin d’être un cas particulier.

Il résulte de ceci que la programmation est également très simplifiée parce que très standardisée mais aussi parce qu’elle est « orthogonale », c’est à dire que le volume du programme est réduit au maximum du fait de la structure « bottom-up » capteur/actionneur => Module d’Équipement => Fonction => Recette. Par suite, le programme résultant est d’une grande facilité à dépanner (à 3 heures du matin, un atout très appréciable pour l’équipe de maintenance).

Il ne reste plus qu’à assembler ces fonctions en une ou plusieurs recettes avec la même facilité. La décomposition fine en modules d’équipements génère aussi une propriété supplémentaire : cette fine granularité permet d’allouer exactement ce qui est nécessaire et suffisant en termes de ressources de type génie chimique, rendant ainsi l’installation au maximum disponible, ce qui n’est pas le cas avec les approches conventionnelles qui allouent des équipements englobant des larges sections, avec souvent des délimitations contre-productives du fait de ce manque de granularité.

La structure finale est donc pyramidale et permet de voir comment s’y associe la représentation vis à vis de l’opérateur que l’on va maintenant aborder dans le chapitre « Interface Homme Machine ».

 

 

4. Interface Homme Machine

Quelle est la meilleure représentation que l’opérateur peut avoir de son environnement et des fonctions ou recettes qu’il a à exécuter ?
Une question très rarement adressée, comme si les choses allaient de soi. Je me souviens de mes débuts d’ingénieur, lorsque soumettant à un ergonome de terrain, le dessin d’un graphisme particulièrement léché, il me répondit : « oui ! c’est beau, très beau… et pourtant je ne pense pas que ce soit cela dont l’opérateur de conduite a besoin ». Une sentence cathartique que je n’ai pas oubliée.

Dans les salles de contrôle, combien de représentations qui reflètent platement le schéma P&ID et obligent les opérateurs à faire défiler les écrans pour suivre le déroulement de l’exécution d’une fonction ? Pourtant de quoi a besoin l’opérateur ? La réponse est simple : de conduire recette et fonctions commodément.
Ceci se traduit donc par quelques vues :

• Vision de la recette pour situer les fonctions en cours d’exécution : l’opérateur y passera moins de 20 % du temps d’interaction.
• Vision de la fonction en cours d’exécution avec ses paramètres clés : temps d’exécution, consignes, valeurs réelles, présence de défaut. Les écrans actuels permettent de représenter plusieurs fenêtres de fonctions simultanément lorsque nécessaire. L’opérateur consacrera au moins 80 % de son temps d’interaction à ces pages-là.

• Et seulement en cas de problèmes d’élégantes pages de type P&ID qui lui permettront de visualiser où se localise le problème. L’opérateur les utilisera d’une façon anecdotique mais la maintenance y passera la majorité de son temps de connexion.

 

5. La mise en œuvre matérielle

La mise en œuvre, d’un point de vue du support matériel ne demande que des moyens très réduits : un automate standard fait aujourd’hui l’affaire pour traiter un atelier conséquent. Un superviseur parmi ceux que l’on trouve dans la plupart des ateliers conviendra pour la partie IHM. Paradoxalement les grands systèmes que l’on rencontre en chimie ne s’adaptent guère à cette approche : conçus prioritairement pour l’industrie du « continu » (pétrole, gaz, énergie) ces systèmes ne réalisent que moins de 5 % de leurs chiffres d’affaire respectifs dans l’industrie du batch (discontinu). Pour cette raison, et malgré les dénégations énergiques de leurs promoteurs, ils y sont conceptuellement mal adaptés, quelle que soit la méthode. Si on arrive à « en faire quand même quelque chose » c’est au prix d’investissements et d’astuces qui laissent perplexes devant les approches alternatives.

 

Conclusion

La méthodologie décrite est mise en œuvre dans la pharmacie, la chimie, l’agroalimentaire ou la cosmétologie avec une vaste majorité de succès avérés. L’application des règles présentée, très simples, est essentielle. Comme en toute chose, c’est un prérequis du succès.
La réduction des coûts est spectaculairement au rendez-vous, souvent de bien plus de 50 % par rapport aux grands systèmes mentionnés au chapitre précédent. La qualité de l’application obtenue est-elle aussi largement bénéficiaire ?

Partager l’article

Automatisation Bovee Vague 63

Jean-Pierre BOVÉE – NRJCUT

Une carrière commencée dans la recherche publique (CNRS, INRA), puis privée (Elf Bio Recherches), poursuivie ensuite dans l’univers de la production industrielle (Rhône-Poulenc, Aventis, Sanofi). Outre le domaine de l’automatisation au sens large de la production, une connaissance et une pratique de l’optimisation des coûts de l’énergie en tant qu’expert global groupe pour les deux activités. Travaille actuellement comme consultant, principalement pour l’industrie pharmaceutique.

jpbovee@lilo.org

Bibliographie

Regard S88/S95 sur les cycles de vie du système de contrôle (Jean VIEILLE) : conférence du French Batch Forum Janvier 2000

En suivant le fil … d’Astrid (Jean-Pierre Bovée) : conférence du French Batch Forum Janvier 2000 ISA88 (Standard international pour la conduite automatisée de la production par lot) : https://fr.wikipedia.org/wiki/ISA88#ASTRID/ DeltaNodes – https://www.isa.org/

Méthodologie de programmation associée à celle de conception exposée dans l’article : Conception et programmation orientées objet, Bertrand Meyer (2000). (ISBN 2-212-09111-7).

Théorie des Graphes (qui sous-tend les propriétés de la méthodologie exposée dans l’article) : Théorie des graphes Problèmes, théorèmes, algorithmes Claudine Schwartz, Olivier Cogis – Collection Collection ISBN 978-2-84225-189-5

Glossaire

P&ID : Process and Instrumentation Diagram, c’est à dire le schéma de l’équipement, vu du côté génie chimique, de ce que l’on doit automatiser. Les capacité et leur instrumentation y sont repérées.

Fonction : Une action élémentaire du génie chimique telle que : transférer, réaliser une réaction, chauffer, agiter, réguler. La quasi-totalité des opérations et des recettes de génie chimique peuvent se définir par rapport à ces opérations élémentaires.

EM : Equipment Module, ou module d’équipement. Une entité pourvue d’un programme autonome qu’une fonction alloue comme on utiliserait un élément de lego pour édifier un objet précis.

HSE : Hygiène, Sécurité, Environnement. Un des émetteurs avec l’Assurance Qualité des exigences critiques à prendre en compte pour un procédé donné.

AQ : Assurance Qualité, entité dont les exigences plus supposées qu’actées en écrit sont parfois alléguées en forme d’excuse pour justifier d’inutiles complexités.

IHM : Interface Homme Machine. Aujourd’hui des écrans / clavier / souris en salle de contrôle, au pied du réacteur, sous forme de tablettes durcies et parfois, mais à déconseiller formellement, sur l’écran du smartphone.