Pilotage de la production

Dans la foulée de la norme S88.01 traitant du contrôle des procédés discontinus, le projet de norme S88.02 propose un modèle de données pour interfacer les applications et échanger les recettes et un langage de description de la Recette, le PFC (pour « Procedure Function Charts ») qui repose sur le modèle de données. Ce langage vise la réduction de la courbe d’apprentissage des nouveaux systèmes et l’amélioration de la communication entre l’Homme et le Système. Cette présentation présente un aperçu du développement et des règles d’utilisation du PFC ainsi que les bénéfices attendus par leur adoption dans l’industrie.

Par opposition aux procédés de type Discret (manufacturier) et continus (énergie, pétrochimie…), on distingue les procédés de type Discontinu ou Batch par les caractéristiques suivantes :

Ils opèrent selon un cycle au cours duquel des quantités déterminées de matière sont transformées en produit fini,

La taille des équipements détermine directement la production du cycle,

Le produit fabriqué dépend de la Procédure exécutée par le cycle appuyé par les fonctions élémentaires de chaque équipement.

Il s’agit souvent d’ateliers « flexibles » ou multi-produits.

La chimie, l’agroalimentaire et la pharmacie représentent l’essentiel de ces procédés. La dernière contrainte de flexibilité ajoutée à la complexité relative du contrôle de base des équipements a amené le développement d’une réflexion particulière sur la stratégie de contrôle de ces ateliers : la norme S88.01

La norme IEC 61131-3 définit des langages de programmation adaptés au contrôle de base des équipements du procédé. Essentiellement conceptuelle, la norme ANSI/ISA S88.01 / IEC 61512-1 (que nous appellerons « S88 » dans la suite de l’exposé) apporte un niveau supérieur au contrôle de procédé : la flexibilité de l'allocation des ressources et de la stratégie de contrôle. Elle découple les domaines et les responsabilités du contrôle de base des équipements vis-à-vis de la spécification du procédé de fabrication et de l'allocation des ressources (la Recette). Elle peut également s’appliquer à d’autres types de procédés (voir les travaux EBF WG3).

La norme S88.01 sépare le contrôle en deux domaines de responsabilité :

Le contrôle des équipements

La Recette

Le premier domaine est celui de l’Automatique. Le contrôle de l’équipement est par définition indépendant du produit à fabriquer. Il fournit les ressources fonctionnelles de base pour construire la stratégie de fabrication (transformations, transferts d’énergie et de matières).

Le second domaine est celui du Procédé. Il utilise les ressources fonctionnelles des équipements pour accomplir la stratégie de fabrication du produit.

La frontière entre ces domaines définit directement le degré de flexibilité de l’atelier et attribue les responsabilités correspondantes à l’Automaticien d’un côté, au gestionnaire et à l’ingénieur procédé de l’autre.

La Recette est composée de 5 éléments :

Entête

Procédure

Formule (Paramètres, Entrées et Sorties Procédé)

Exigences Equipements

Autres Informations

Le contrôle procédural de la norme S88.01 repose sur 4 niveaux hiérarchiques :

Procédure

Procédure Unité

Opération

Phase

Une Procédure est composée de Procédures Unité elles-mêmes composées d’Opérations… Des niveaux peuvent être omis, des niveaux complémentaires peuvent être ajoutés. Ces éléments procéduraux sont appelés de façon générique :

Elément Procédural Recette ou RPE pour la stratégie de fabrication

Elément Procédural Equipement ou EPE pour le contrôle des équipements

On pourra définir des Procédures Recette, Procédure Equipement, Procédures Unité Recette, Procédures Unité Equipement, Opérations Recette, Opérations Equipement, Phases Recette et Phases Equipement.

La séparation entre le domaine de la Recette et le domaine de l’Equipement est du ressort de l’implémentation. Toutefois, la plupart des systèmes de pilotage de Recettes imposent un couplage au niveau de la Phase. (Figure 1)

La norme S88.01 propose 3 types de Recettes selon le niveau de détail et l’utilisation :

Recette Générale

Recette Site

Recette Maître

Seule la dernière peut donner naissance à une Recette exécutable, la Recette Contrôle. Les autres Recettes ont d’autres objectifs liés à la création des produits et à la planification. Le rapport ISA TR88.0.03 préconisait le développement d’un langage adapté aux trois types de Recettes, mais cet objectif a été abandonné entre temps. La situation au niveau des Recettes de niveau supérieur est loin d’être claire, et ce problème est placé dans les priorités d’action du groupe SP88 pour les prochains projets de norme.

La norme S88.01 définit le terme Procédure comme « la stratégie pour exécuter un procédé », mais les règles pour spécifier cette Procédure ne sont pas définies. C’est une lacune importante de la première partie de la norme : elle était intentionnelle du fait des opinions variées au sein du comité à cette époque. Le comité SP88 reconnaissait qu’il s’agissait d’un problème important et adopta les 2 résolutions suivantes :

Etablissement d’un rapport sur les formats possibles de représentation des Procédures,

Définition d’une méthode pour la description de la Recette dans la seconde partie de la norme.

Le rapport technique ISA-TR88.0.03 fut publié en 1997. Le travail sur la seconde partie se poursuivit après la publication de ce rapport, et une méthode normalisée pour décrire la logique procédurale des Recettes est exposée dans la section 6 du projet de norme S88.02^[1] « Procedure Function Charts ».

La notation PFC a été développée en utilisant des éléments des trois formats discutés dans le rapport technique : Liste, Gantt et SFC (Sequencial Function Charts). A première vue, la notation PFC est proche du SFC, mais plusieurs aménagements ont été développés pour tenir compte des spécificités d’exécution et de documentation du contrôle procédural vis-à-vis du contrôle séquentiel.

La méthode choisie pour la description de la Recette ne prend en compte que la Procédure : L’en-tête, les Exigences Equipements, la formule et les autres informations ne sont pas traités. Par définition, la Procédure supporte la structure de la Recette à laquelle se rattachent obligatoirement les autres catégories d’information. Ces informations ne sont pas normalisées au-delà de la nécessité d’ « indiquer clairement et de façon consistante pour une application donnée leur relation avec la Procédure ».

Les bénéfices attendus d’une méthode normalisée de description de la Procédure sont :

Permettre l’échange des Recettes entre systèmes (en validant les structures de données proposées dans la norme S88.02)

Réduire la courbe d’apprentissage des utilisateurs d’un système à l’autre

Fournir une base commune de dialogue entre les utilisateurs et les fournisseurs

L’aspect normatif de la notation PFC n’impose pas son utilisation exclusive. Il est reconnu que des méthodes alternatives pourront être préférées en fonction des caractéristiques de la Procédure (taille, complexité, exigences particulières de l’utilisateur…).

Un langage est un ensemble de symboles et de règles utilisés pour communiquer. Dans le cas des systèmes d’information, ils permettent à l’homme de dialoguer avec la machine pour décrire la tâche que la machine doit exécuter et en contrôler son exécution.

La définition précise des objectifs et des contraintes est essentielle pour guider le développement. La liste suivante est partiellement mentionnée en annexe du projet ISA-dS88.02  :

Simple à suivre : il s’agit d’un langage de spécification destiné à être utilisé par des non-informaticiens et non-automaticiens

Facile à construire : peu d’exigences de syntaxe et de symboles à apprendre

Limites clairement définies : symboles graphiques normalisés de Début et de Fin

Description de l’ordre d’exécution non ambiguë : séquence, parallélisme, sélection, convergence…

Expression des relations de coordination : transfert de matières et synchronisations

Support des Niveaux hiérarchiques : symboles uniques, mais différenciés pour tous les niveaux de la Procédure

Support multi-niveaux : mise en évidence de la décomposition possible d’un élément de Procédure

Applicable aux Recettes Maître et Contrôle. Le traitement des Recettes de haut niveau n’est pas retenu pour le PFC.

Indépendant du média : utilisable aussi bien pour une implémentation « papier-crayon » qu’avec un ordinateur capable d’animations graphiques colorées.

Le langage doit permettre de fournir tous les détails nécessaires pour décrire de façon non ambiguë la stratégie de fabrication. A ce titre, il doit donc supporter le modèle d’échange de données défini dans les sections 4 et 5 de la norme S88.02.

La capacité d’extension est induite par l’exigence d’une description non ambiguë. Dans les cas les plus simples, la Procédure peut ne comporter qu’un seul Elément Procédural Recette (RPE) ou une simple liste exécutée séquentiellement. Dans les cas complexes, des logiques conditionnelles et des contraintes de temps peuvent intervenir.

Sur la base des objectifs et contraintes ci-dessus, le comité reconnu que le rapport technique fournissait une analyse précise des options possibles, incluant la plupart des méthodes utilisées par les systèmes de contrôle batch du marché. Ces méthodes sont les suivantes :

C’est la forme la plus simple pour la représentation d’une séquence linéaire (Figure 2). La liste présente l’avantage d’être facile à visualiser.

Historiquement, la plupart des Procédures Recettes ont été décrites de cette façon. Ces Recettes présentaient à l’opérateur une liste numérotée d’étapes à exécuter. S’il est convenable pour des situations simples, ce format n’est pas utilisable dans des cas plus complexes : les parallélismes et séquences complexes avec logique conditionnelle sont très difficiles à décrire clairement avec ce format. L’exemple de la Figure 3 montre à quoi pourrait ressembler une approche textuelle. Il s’agit d’une proposition de langage d’échange « BxL » pour l’échange de données de Recette (non retenu à ce jour). Cette forme évoluée bien adaptée pour la communication entre ordinateurs n’est à l’évidence pas utilisable pour un dialogue efficace avec un être humain… ^[2]

Les diagrammes de Gantt sont très utiles pour décrire la progression des activités dans le temps. Ils peuvent également montrer de niveaux multiples d’activités. Outils de base de la planification, ils sont relativement bien adaptés pour la description de Procédures Recettes qui consistent en une ou plusieurs Procédures Unité opèrent de façon plus ou moins indépendante avec des points de coordination.

Le diagramme de la Figure 4 présente quelques particularités :

Le déroulement vertical qui se prête mieux à un nombre d’activités successives plus important que les activités parallèles et qui suit la logique du format liste ou du SFC

Les liens de coordination entre Procédures Unité

Le découpage des Procédures Unité en Opérations

Une base de temps relative et non absolue du fait que l’instant de lancement des activités et leur durée ne sont pas connus de manière déterministe avant leur exécution

Toutefois, lorsqu’une logique conditionnelle complexe doit être introduite, le diagramme de Gantt perd son efficacité. Les systèmes de planification utilisent alors les diagrammes de Pert pour traiter ce type d’information et gérer les situations complexes avec des prédécesseurs et des successeurs multiples. Si les diagrammes de Pert sont efficaces pour les systèmes de planification sophistiqués, ils ne sont guère adaptés à la conduite d’une unité de fabrication.

La troisième méthode discutée dans le rapport technique est le Sequential Function Chart (SFC) défini par la norme IEC 61131-3 et basé sur la norme IEC 60848 (GRAFCET). C’est un langage largement répandu et bien accepté. Il offre des moyens puissants pour spécifier la logique conditionnelle, ce qui manque aux précédentes méthodes de type Liste ou Gantt. On note que la plupart des systèmes batch actuels utilisent le SFC pour décrire les Procédures. La Figure 5 montre l’exemple d’une Opération qui active des Phases.

Le graphe SFC décrit bien la logique conditionnelle souvent nécessaire au niveau de l’Opération. Au niveau supérieur de la Procédure toutefois, cette capacité a peu d’intérêt. La Figure 6 montre deux Procédures Unité actives simultanément. Dans ce cas, on ne dispose pas d’information concernant les flux matières, la synchronisation entre les Procédures Unité et leur déroulement général relatif dans le temps. Par exemple, la Procédure Unité Réaction n’est pas supposée démarrer avant que la Procédure Unité Préparation n’ait atteint une certaine situation. Le graphe ne montre pas cela parce qu’il doit placer toutes les Procédures Unité dans la même structure séquentielle parallèle.

Chaque approche présente des avantages et des inconvénients, et le rapport ne conclut pas sur une recommandation. Deux autres problèmes n’ont pas été mentionnés par le rapport, bien qu’ils soient critiques pour la description de la Recette : l’utilisation de niveaux multiples dans la hiérarchie et la séparation entre les Eléments Procéduraux Equipement et Recette.

Chaque constructeur de système ou éditeur de solutions pour le contrôle batch a développé son propre langage. Cette diversité des approches qui provoque la confusion des utilisateurs a été un élément moteur pour le développement du PFC. Les acteurs majeurs ont participé à l’élaboration de ce langage. Chacun s’est battu pour conserver les atouts de sa propre solution dans la norme.

Pendant cette évaluation, d’autres travaux ont été étudiés. On doit signaler par exemple les travaux remarquables de Karl-Erik Arzen et Charlotta Johnsson sur le « High Level Grafchart ». Ils proposent une évolution sans compromis du Grafcet vers une forme objet et démontrent son application dans le contrôle discontinu ^{[3] [4] [5] [6]}.

Les travaux de révision de la norme IEC 60848-1988 pour permettre de spécifier de multiples niveaux de graphe offraient également un champ de réflexion intéressant ^{[7] [8] [9]}

La notation résultante du Procedure Function Chart s’est inspirée du High-Level Grafchart et des modifications proposées pour la norme IEC 60848.

Cette évaluation concluait donc qu’aucune méthode existante ne convenait pour répondre à tous les objectifs et contraintes énoncés à tous les niveaux et pour tous les degrés de complexité des Procédures. Par contre, il était reconnu que chacune des méthodes discutées dans le rapport technique avait des caractéristiques intéressantes qui, combinées entre elles, pouvaient contribuer à définir une nouvelle méthode efficace. Il était également reconnu qu’une méthode similaire à celle proposée par la révision des macro-étapes de la norme IEC60848 permettrait de supporter les niveaux multiples dans la Recette.

La notation PFC a été développée et révisée sur une période de 4 années marquées par des faux départs et des marches arrières. Chaque fois que de nouveaux membres se joignaient au comité, de nouvelles discussions et de nouvelles alternatives surgissaient. Il s’avéra impossible de développer une méthode satisfaisante dans l’esprit de chacun. Compromis et concessions ont été le terrain du consensus sur la méthode de description retenue.

En guise de parcours simplifié du processus de développement de la notation PFC, il peut être utile de considérer quelques éléments qui ont guidé sa genèse :

L’influence du format Liste est visible dans le principe des Transitions Implicites (discutées plus loin) qui permet de décrire une simple liste d’Eléments Procéduraux.

La capacité du diagramme de Gantt à représenter la notion de durée et la synchronisation apparaît dans la possibilité de dessiner des éléments procéduraux de longueur fonction de leur durée relative.

L’influence du SFC est évidente : Utilisation de sélections de séquences et de séquences simultanées, alternance Transition – Etape – Transition.

Bien que le terme "Macro Etape" ne soit pas utilisé, le concept mis en avant par le projet de révision de la norme IEC60848 est reflété dans la notation PFC.

La séparation entre la logique de la Recette et celle de l’Equipement a conduit à définir une spécification particulière pour l’activation et l’évaluation des Transitions.

Il existe une différence fondamentale entre la logique procédurale de la Recette et la logique séquentielle de l’entité d’équipement. La logique d’équipement, quel que soit le langage, doit toujours être responsable de la conclusion de son traitement. La décision de l’entité d’équipement peut être basée sur des signaux externes sans filtrage interne, par contre, la capacité de la logique d’équipement à traiter ses tâches ménagères ou d’autres activités lors d’une demande de fin d’exécution est critique. C’est la ligne de raisonnement qui à conduit à définir un comportement différent de la relation RPE-Transition du PFC de la relation Etape-Transition du SFC.

Les spécificités Process telles que l’allocation des ressources, les transferts de matières, la synchronisation et les activités asynchrones sont prises en compte par la notation PFC.

La Procédure Recette doit montrer l’orchestration de Procédures Unité relativement indépendantes même lorsqu’elles se décomposent en éléments de niveau inférieur (Opérations, Phase).

 

 

La notation présentée ici est définie dans le projet de norme ISA-dS88.02 dans son état au moment où ce papier est rédigé. Il est possible que cette notation soit modifiée avant que ce projet ne soit confirmé comme norme ANSI/ISA et IEC à l’issue du processus d’approbation actuellement en cours. Les indications fournies devront donc être confrontées à la publication officielle en cas de référence future.

L’objectif de cette présentation n’est pas de proposer une référence complète du langage PFC qui devrait fait l’objet de publications ultérieures. Il s’agit d’une brève vue d’ensemble de la notation au travers de quelques exemples.

Les symboles utilisés dans la notation PFC sont les suivants :

Le plus bas niveau hiérarchique de la Procédure Recette est la Procédure Opération qui décrit les enchaînements des Phases Recette, elle-même couplées (au besoin) aux Phases Equipement. Ce cas limite où la Recette détermine les enchaînements procéduraux au plus bas niveau de la hiérarchie S88 correspond au niveau de couplage exclusif de la plupart des moteurs d’exécution batch.

La Figure 8 montre comment décrire une Opération simple de 2 Phases en utilisant les symboles PFC. Les symboles de Début et Fin indiquent où commence et où se termine l’exécution du PFC. Le diagramme est développé verticalement du début à la fin. Les liens directs connectent les différents symboles et déterminent l’ordre d’exécution du diagramme.

Les Phases Recette correspondent à des Phases Equipement qui peuvent être implémentées en logique programmée dans un contrôleur de procédé (processeur SNCC ou Automate). Ces 2 Phases sont représentées différemment pour mettre en évidence l’utilisation des Transitions Implicites et Explicites.

La Phase Remplir utilise une Transition Implicite. Elle est programmée de telle sorte qu’elle passe à l’état « Terminé » lorsqu’elle atteint son objectif (dans ce cas : atteindre le niveau de 4 mètres). Cet objectif a été défini en utilisant un paramètre transmis à la Phase au lieu d’une condition de Transition. La Phase suivante Purger doit démarrer dès que la Phase Remplir atteint son objectif. On considère dans ce cas qu’il n’est pas nécessaire de représenter une Transition entre ces 2 Phases : les Phases s’enchaînent naturellement par le seul jeu de leur exécution. Lorsqu’une Transition n’est pas décrite parce qu’elle correspond à la fin de l’élément procédural précédent sans aucune autre condition, elle est appelée Transition Implicite. La notion de Transition est maintenue dans le but de respecter la règle Etape-Transition-Etape de la norme IEC 61131-3.

Figure 9 –Transition Implicite

La Figure 9 développe le concept de Transition Implicite. Par définition, la Transition Implicite est une convention qui autorise à ne pas représenter dans le PFC la condition « Elément Procédural Equipement Terminé ». Dans la plupart des applications batch, les Eléments Procéduraux Equipement sont programmés par l’automaticien pour être lancés par la Procédure Recette et poursuivent leur exécution en utilisant les paramètres de formule appropriés chargés avant l’exécution. Ceci est un problème critique du contrôle batch : l’Elément Procédural Equipement contrôle toujours lui-même sa fin d’exécution, même si une Transition Explicite du PFC la requiert. Ce mécanisme est naturel pour l’auteur de la Recette.

Il s’agit d’une différence majeure avec le SFC : lorsqu’une Transition est évaluée vraie, les étapes précédentes sont immédiatement terminées, et il n’existe aucune opportunité pour poursuivre les « tâches ménagères ». Une interruption soudaine des Eléments Procéduraux Equipement n’est pas adaptée aux applications batch, et on remarquera que beaucoup de systèmes utilisent une forme altérée du SFC pour contourner ce problème.

Dans le cas de l’exemple précédent, on aurait pu représenter une condition « Vraie » ou « Niveau atteint » ou « Phase de remplissage terminée ». Si une telle information est ressentie comme nécessaire, elle pourra être décrite à l’aide d’une Transition Explicite.

Figure 10 –Transition Explicite

Une Transition Explicite suit la Phase Recette Purger. Cette Phase est programmée dans l’équipement pour vider le réacteur. Après que cette Phase ait été lancée, la logique de la Phase Equipement ne fermera la vanne de purge que lorsque l’ordre lui en aura été donné par l’exécution du PFC lorsque la Transition « Niveau <= 1 mètre » sera devenue vraie. La Phase ferme la vanne, effectue les actions nécessaires et passe à l’état « Terminé ». Le PFC franchit alors la Transition, atteint le symbole Fin, et conclut l’exécution de l’Opération

On voit que dans ce cas (enchaînement simple entre 2 éléments procéduraux) l’utilisateur a le choix d’utiliser une Transition Explicite ou Implicite avec les mêmes effets. La possibilité de choisir le type de Transitions implique une coordination entre l’automaticien qui développe la logique des Eléments Procéduraux Equipement et l’ingénieur qui décrit le procédé de fabrication.

La description des conditions attachées aux Transitions Explicites n’est pas imposée par la norme. Les applications peuvent utiliser des notations particulières ou faire référence à la norme IEC 61131-3.

La norme n’impose pas de couleurs pour le diagramme ni de façon de représenter les paramètres. Ils doivent simplement être accessibles à partir de l’élément procédural correspondant.

Les premiers projets imposaient l’utilisation d’un seul symbole de départ et d’arrivée par graphe. L’utilisation de graphes à entrées et sorties multiples est désormais permise pour décrire des Procédures parallèles asynchrones avec évolutions multiples. C’est une nouvelle différence importante avec le SFC.

A la différence du SFC, il n’y a pas d’étape initiale. Celle-ci est unique dans le cas du SFC, alors que la notation PFC autorise l’exécution simultanée de plusieurs éléments procéduraux au lancement de la Procédure. Ceci est possible grâce au symbole de Début.

Ces symboles ne sont pas exécutés et ne supportent pas d’informations. Ils représentent seulement des positions.

La Figure 11 représente une Procédure Unité qui détermine les enchaînements des Opérations. A ce niveau, l’élément procédural peut contenir un PFC de niveau inférieur (Opération Recette manipulant des Phases ) ou référencer directement une Opération Equipement.

Le signe « + » placé dans le coin supérieur droit de l’élément procédural indique l’encapsulation d’un PFC de niveau inférieur. Par exemple, l’Opération Initialise référence une Opération Equipement, il ne contient donc pas de Phases Recette. Toutes les autres Opérations encapsulent des PFCs, et donc des Phases.

L’utilisation de Transitions Implicites après les Opérations Initialise et Charge permet une représentation concise : la première partie du graphe se lit comme une liste.

Les Transitions Explicites sous le symbole de sélection (barre horizontale) sont évidement obligatoires.

Les besoins de descriptions de la Procédure Unité et de la Procédure Opération ne sont pas très différents. Par contre, la représentation de la Procédure Recette diffère sensiblement des 2 précédentes.

La Procédure Recette orchestre l’exécution d’activités asynchrones (par exemple les Procédures Unité) qui ont des points de synchronisation, des transferts de matières et des Exigences Equipements.

En tant que plus haut niveau de la Procédure, il est nécessaire de fournir le maximum d’information au plus au niveau d’abstraction possible. La Figure 12 présente un exemple d’une Procédure Recette simple.

Figure 12 – Procédure Recette PFC

Le symbole d’allocation de ressources représente un élément procédural qui contient les Exigences Equipements (et autres ressources telles que personnel, matières, énergie) pour la Procédure Unité qui le suit. Il s’agit des règles d’allocation constituées par exemple d’une liste des équipements utilisables pour l’exécution de cette Procédure Unité. L’exécution de l’élément doit entraîner l’allocation des ressources nécessaires (en particulier les Modules Equipement) par un arbitrage manuel ou calculé par un système d’ordonnancement. La forme du symbole et son objectif sont normalisés, par contre le contenu est laissé à l’appréciation de l’implémentation.

Lorsqu’une Transition Explicite suit le symbole d’allocation, elle représente les conditions de lancement de la Procédure Unité. Dans notre exemple, la Procédure Unité Préparation démarre dès que l’élément d’allocation est exécuté, tandis que la Procédure Unité Réaction exige un acquittement de l’opérateur pour démarrer.

Lorsque les 2 Procédures Unité sont terminées, le symbole de fin de séquences simultanées (convergence ET) permet au graphe d’atteindre le symbole Fin et l’exécution de la Recette se termine.

La Figure 12 semble indiquer que les 2 Procédures Unité fonctionnent simultanément. Cette représentation est incomplète : en généralisant, toutes les Procédures Unité devraient être placées dans le même jeu de séquences parallèles. De plus, les points de synchronisation et les mouvements de matières ne sont pas représentés. La première solution qui vient à l’esprit pour tenter de résoudre ce problème serait de décrire les Procédures Unités en série comme dans une liste (Figure 13). Cette méthode ne convient pas, car elle impose des points de synchronisation tels que la première Procédure Unité soit terminée avant que la seconde puisse démarrer. Elle ne résout pas non plus le problème de la description des transferts de matières.

Figure 13- Procédure Recette "Série"

Le défi consistait donc à trouver une méthode capable de représenter une large structure de séquences simultanées. L’application des diagrammes de Gantt sur un axe vertical avec une échelle de temps relative le permettait.

On a tout simplement allongé les éléments procéduraux comme sur un diagramme de Gantt. La Figure 14 montre la même Procédure Recette « étirée » pour montrer les relations et points de synchronisation.

On peut noter que ni l’instant absolu de l’exécution d’un élément procédural ni sa durée ne sont connus dans la Recette (des informations statistiques de durée pour la planification et les calculs de coût prévisionnels pourraient éventuellement être récupérées). La longueur de l’élément procédural est donc purement relative et n’a pas de rôle fonctionnel.

La taille des 2 Procédures Unité est telle qu’elle permet de montrer que la Procédure Unité Préparation est d’abord lancée et qu’à un moment donné de son exécution, le processus d’allocation de la Procédure Unité Réaction est exécuté. Ensuite, lorsque l’opérateur a validé les conditions de démarrage, la Procédure Unité Réaction est démarrée. Plus tard, un peu avant la fin de la Préparation et un peu après le démarrage de la Réaction, un transfert matières s’effectue entre la cuve et le réacteur respectivement alloués à la Préparation et à la Réaction. Le transfert se poursuit pendant quelque temps et la Réaction se poursuit. Lorsque les 2 Procédures sont terminées, la Recette se termine.

Bien que relativement vague sur les événements, la Figure 14 fournit plus d’information que la Figure 12. On peut aller plus loin en montrant plusieurs niveaux sur le même PFC comme sur la Figure 15. Les symboles des Procédures Unité ont été dilatés et les PFC qu’elles encapsulent sont représentées à l’intérieur. On voit à présent que les 2 Procédures Unité Préparation et Réaction ont chacune 4 Opérations. On peut observer que le point de synchronisation S1 concerne le prélèvement d’échantillon dans la cuve de préparation tandis que le transfert de matière T1 est effectué par les Opérations Transfert du Réacteur (Procédure Unité Préparation) et Transfert de Préparation (Procédure Unité Réaction)

La notation PFC a pour objet de favoriser l’échange des données de Recette entre systèmes et de rendre plus facile l’apprentissage d’un nouveau système batch. Toutefois, il est reconnu qu’aucun paradigme n’est définitif et que l’évolution et l’innovation se poursuivront. Par conséquent, la norme permet d’étendre la notation PFC. La seule exigence est que les extensions soient clairement définies.

La Procédure est le ciment qui unit les différentes catégories d’information de la Recette au sein de chaque élément procédural. La norme n’impose pas la représentation de ces informations. Les exemples ont montré une représentation possible des paramètres de la formule et des conditions des transitions. La description de l’en-tête de Recette et des « Autres Informations » peuvent faire l’objet de larges divergences dans l’implémentation.

La notation Procedure Function Chart propose une méthode normalisée et indépendante du fournisseur pour la description de la Procédure de la Recette. Cette indépendance est assurée par le fait que la méthode a été développée sur la base de multiples méthodes et normes connues ou utilisées et en diffère suffisamment de telle sorte qu’aucun fournisseur n’est avantagé. Un panel large et diversifié de fournisseurs et d’utilisateurs a conduit son développement et cette notation représente un consensus accepté par toutes les parties. Il est attendu de la notation PFC qu’elle

Supporte une méthode normalisée pour les échanges de données entre systèmes

Permette une communication efficace entre les acteurs pendant toutes les phases des projets

Raccourcisse la courbe d’apprentissage des auteurs de Recettes, et des opérateurs lorsqu’ils ont à mettre en œuvre différents systèmes

Cette présentation a été réalisée à partir de larges extraits d’une présentation de David Emerson^[10].

Jean Vieille

Consultant

4, rue des Ecrivains BP46 - 67061 Strasbourg cedex (France)

Au delà des aspects purement techniques de leur mise en oeuvre, l’application des normes S88 et S95 facilite une vision globale et proactive de la gestion du cycle de vie du système de production des entreprises manufacturières.

Ce cycle de vie s’accorde sur 3 rythmes fondamentaux : l’ingénierie des ressources de production, l’ingénierie des produits et le programme de fabrication. Le découplage des contraintes de ces 3 cycles est une condition essentielle pour la réactivité du système de production de l’entreprise.

Cette présentation propose une vision coordonnée de ces cycles sous l’éclairage des normes ISA.

Si l’amélioration de la productivité demeure un objectif incontournable (pour combien de temps encore ?) pour la justification du capital investi, la prise en compte des besoins du consommateur en tant qu’élément de la valeur ajoutée arrive à présent au devant de toutes les préoccupations de l’Entreprise. Le principal moteur de cette évolution est la croissance exponentielle du commerce électronique qui libère totalement la liberté de choix du consommateur.

La survie et la performance de l’Entreprise reposent maintenant pour l’essentiel sur sa capacité de réaction aux besoins du marché et du client.

Il en résulte une concentration de l’Entreprise sur son cœur de métier pour répondre de la manière la plus appropriée possible à ces besoins ou ces attentes. Les logiques de gestion des stocks et d’investissement prévisionnel en ressources de production s’effacent au profit d’une politique du Juste-à-Temps dans laquelle la mobilisation des ressources n’est plus une contrainte, mais une tâche logistique au même titre que l’approvisionnement des matières ou la livraison des produits.

Idéalement, l’Entreprise qui veut introduire un nouveau produit (ou adapter un produit existant) doit développer ce produit « à capacité infinie » et mobiliser le moment venu les ressources nécessaires dans son propre système de production ou sur un marché en pleine ouverture d’externalisation (outsourcing) des ressources de production. Si la situation ne semble pas idéale du point de vue des coûts, elle est justifiée par le fait que le client est prêt à payer plus cher le produit qui arrive le plus vite pour satisfaire ses attentes et parce que le raccourcissement de la durée de vie du produit ne permet plus de justifier les investissements nécessaires en capital. Pour reprendre le discours de Michael Saucier, Le cas limite est l’ « Entreprise de Produit » en contact avec le consommateur qui paiera la totalité de la valeur ajoutée. Elle conçoit les produits et organise leur fabrication pour les délivrer dans les conditions de délais, coût et qualité attendues par le marché et les clients, mais elle ne « possède » aucune des ressources nécessaires pour produire.

D’un autre côté, les Entreprises pourront réorienter l’exploitation de leur ressources de production pour les mettre à la disposition d’un marché dans lequel puiseront les « Entreprises de Produit ». Ces « Entreprises de Production » vont intervenir dans les processus de fabrication selon les « fonctions processus » qu’elle peuvent offrir, leur capacité et leur disponibilité. Ce schéma, qui pousse à l’extrême le principe de la sous-traitance, est déjà classique dans certaines industries (Internet, Semi conducteurs, electro-ménager…)

Dans ces conditions, le système de production est un maillon essentiel d’une « Entreprise virtuelle » composée d’entités multiples « Produits » et « Production ». Pas seulement parce qu’il génère une part importante de la valeur ajoutée (même si elle tend à diminuer), mais surtout parce qu’il se trouve sur le chemin critique des processus fondamentaux d’activité de la chaîne logistique. Ce découplage des fonctions de production impose un pilotage efficace :

Sur le plan tactique (traitement des ordres de production)

Comme sur le plan stratégique (amélioration et mise sur le marché de nouveaux produits)

 

L’ingénierie traditionnelle, enfermée dans une dépendance planifiée des cycles de conception du produit, de l’outil de production et de la planification opérationnelle de la production, doit évoluer pour s’adapter à ces nouvelles exigences.

Nous examinerons les apports des normes ISA S88 et S95 dans la mise en œuvre de l’Entreprise ainsi remodelée.

Ces réflexions s’adressent d’abord aux industries de processus et s’appuient sur les idées qui prévalent au sein des groupes ISA SP88 et SP95, partagées par d’autres auteurs.

En observant l’exemple d’un cycle en « V » représentatif de l’ingénierie traditionnelle, on observe que :

Les spécifications du processus sont un préalable nécessaire pour développer le système de production qui ne peut être qualifié qu’en fin de projet « one-shot »

L’ensemble du système de production doit être préalablement conçu pour répondre au design initial du processus : toute variation du processus peut entraîner une remise en cause du système. En généralisant, si le système de production est conçu pour plusieurs processus, tous les éléments de cette flexibilité doivent être définis préalablement à l’implantation.

Mise à part une précédence chronologique, il n’existe aucune interactivité avec la phase opérationnelle de la vie de l’installation : on ne peut démarrer la production que lorsque toutes les fonctions nécessaires ont été implémentées, le procédé est conçu « pour durer », sa remise en cause est coûteuse et passe par un cycle de complet d’ingénierie.

La sous-traitance représente un premier pas vers le concept évoqué dans l’introduction. Mais elle est définie de façon statique lors de l’ingénierie globale Produit+Ressource : elle intervient souvent dans les processus secondaires où elle est traitée « à capacité infinie ».

Dans cette étude, les contraintes qui lient le système de production aux fournisseurs ne sont pas remise en cause, et n’apparaîtront pas.

Nous venons de voir que l’ingénierie traditionnelle des installations s’appuyait sur les besoins spécifiques et exclusifs du produit à fabriquer.

La vision binaire précédente (construction du système pour le produit, fabrication du produit) ne permet pas à l’Entreprise de répondre à ses nouveaux défis. Nous devons mettre en oeuvre un modèle de conception et de comportement du système de production qui corresponde à de nouvelles exigences. En décomposant l’ingénierie traditionnelle en deux éléments, on définit trois cycles de

base qui rythment la vie du système de production.

L’ingénierie du produit qui décrit le produit et ses règles génériques de fabrications :

Elle réagit aux besoins du marché en mobilisant la fonction R&D.

Elle présente des phases de création et d’exploitation de durée très variables : souvent très courtes pour les biens de consommation, très longues pour les produits pharmaceutiques.

L’enjeu peut être stratégique lorsqu’il s’agit d’aborder de nouveaux marchés, mais devient de plus en plus tactique lorsque l’Entreprise doit réagir à l’évolution constatée de la demande.

Elle représente le processus de gestion des actifs physiques du système de production et correspond à un cycle de vie caractérisé par :

Une phase de construction relativement lourde qui mobilise des capitaux importants

Une phase d’exploitation très longue (parfois plusieurs dizaines d’années)

Une justification dans une démarche stratégique globale à long terme de l’Entreprise.

Un sous-cycle de la Maintenance qui affecte les performances, le coût d’exploitation et la disponibilité.

Des spécifications en terme de capabilités, mobilisation de main d’œuvre et consommation d’énergie

Ses caractéristiques sont très variables selon le type de production (continue, discontinue, discrète), avec une période relativement courte en regard des deux cycles précédents. Il se déroule de manière successive pendant toute la durée d’existence du produit en s’appuyant sur l’ingénierie du produit et sur les ressources de production pour piloter les flux de matières.

Les objectifs fixés par la planification doivent être accomplis par le système de production dans les meilleures conditions de performance (qualité, coût, respect des délais).

Considérons à présent la façon dont ces cycles interagissent face aux besoins du marché.

Si les procédés de fabrication sont à l’origine de la conception initiale du système de production, l’Entreprise devra être capable de le faire évoluer dans des conditions optimales  lorsqu‘elle mettra en œuvre de nouveaux processus:

Soit par une évolution cohérente de ses propres ressources,

Soit en organisant efficacement la mobilisation de ressources externes.

Dans le premier cas, on cherchera à créer un environnement favorable aux projets d’ingénierie en minimisant les effets de l’évolution sur les ressources non concernées. Le cycle de vie sera déterminé par les contraintes traditionnelles de l’ingénierie.

Dans le second cas, le processus de fabrication se déroulera partiellement ou totalement à l’extérieur de l’entreprise. Le système est beaucoup plus réactif, tandis que la gestion des flux logistiques et informatifs devient critique.

Sur la figure ci-dessous, on met en évidence certaines dépendances :

La demande Stratégique du Marché pilote l’Ingénierie Produit

L’ingénierie Produit détermine l’ingénierie des Ressources de Production

La planification opérationnelle répond à la demande réelle ou prévisionnelle et détermine le Programme de Production, lui-même représentatif de l ‘état actuel de la production vis-à-vis du demandeur (le Client)

 

Le programme de production s’appuie sur L’ingénierie du Produit (Comment fabriquer) et sur l’ingénierie des Ressources (quelles sont les ressources disponibles ?), il est contraint par les deux.

Nous allons modifier le schéma précédent en distribuant les rôles dans 2 entités coopératives sur le modèle de Michael Saucier : l’Entreprise de Produit et l’Entreprise de Production. Ce schéma ne présume pas nécessairement d’une scission juridique de l’Entreprise qui se séparerait de son outil de production, mais établit une nouvelle relation entre le domaine du Produit et le domaine de la Production. Interne, externe ou réparti, le système de Production est découplé du domaine du Produit et devient un élément responsable de sa propre performance.

Les entreprises qui ont basé leur relation client sur l’interactivité « électronique » nous démontrent spectaculairement les effets d’une stratégie résolument orientée vers le consommateur. Elle n’est possible que si l’Entreprise, devenue sensible aux désirs actuels du consommateur, se donne les moyens d’y répondre dans les meilleures conditions. Le découplage de la fonction de production et la mise en place d’une relation de type Client - Fournisseur dans les échanges devient le seul moyen de parvenir à la réactivité nécessaire.

La demande stratégique, mue par les désirs du Consommateur, pilote l’ingénierie du Produit.

Le programme de production s’appuie sur des ressources externes disponibles sur le marché auprès de multiples entreprises de Production. Ces ressources sont mobilisées concurremment pour les besoins du programme de production. L’optimisation du capital investi dans ces ressources est sans objet.

L’ingénierie des ressources de production n’est plus sur le chemin critique de la réponse à la demande du marché

L’ingénierie des Ressources de Production s’appuie sur les besoins génériques du marché. (animé par les Entreprises de Produit)

Le programme de production consolide les ordres en provenance de multiples clients « Produit ».

Le savoir-faire de l’ingénierie Produit (protégé), transmis avec l’ordre de production, n’est pas capitalisé (il peut être protégé).

On peut comparer les contraintes de ces 2 types d’Entreprises avec celles d’une Entreprise intégrée classique (mixte).

Concentre ses investissements R&D

Gère une demande direct du consommateur et du marché

Organise la chaîne logistique globale du produit

Le rendement du capital investi est directement proportionnel à la valeur ajoutée et à la quantité fabriquée par produit. Cette valeur ajoutée n’est pas générée par l’activité de production mais par la qualité de la relation avec le client et le marché.

 

L’Entreprise traditionnelle « mixte » doit quant à elle conjuguer tous ses talents pour trouver les compromis qui valoriseront ses investissements et lui permettront de satisfaire le marché et le client.

En regardant les Ressources de Production sous l’angle des fonctions de base de Processus qu’elles assurent, nous pouvons isoler du processus de fabrication du produit les fonctions opérationnelles assurées par ces ressources :

Les ressources fonctionnelles ne sont plus exclusives d’un produit ni d’une entreprise, elles assurent des « fonctions d’équipement » génériques

Ces « fonctions d’équipement» doivent correspondre aux « fonctions de processus » nécessaires pour mettre en œuvre les Processus de fabrication

La complexité de la fonction d’équipement est variable (S88 : de la phase élémentaire à la procédure complète) et peut être considérée à plusieurs niveaux selon les besoins.

On retrouve ici l’un des fondements de la norme S88 qui sépare la Recette du contrôle des Equipemente et la notion de segment produit/processus de la norme S95.

On doit également considérer une approche plus souple de l’ingénierie qui ne doit plus figer les systèmes dans des configurations devenue éphémères. L’imagination prolifique du marketing et de la R&D ne doit plus s’opposer à la rigidité implicite des projets d’ingénierie en adoptant une démarche itérative de développement et d’amélioration :

des produits : création et modification des processus

et des systèmes de production : reconfiguration des ateliers, ajout et suppression des ressources, évolution des capacités et des services des équipements

 

Les spécifications fonctionnelles forment ainsi un point de convergence / divergence et une interface entre l’ingénierie du produit et l’ingénierie des ressources de production. Les cycles d’ingénierie sont ainsi découplés et décomposés en entités plus facile à gérer.

 

L’un des fondements de la norme S88 est le découplage des fonctions de l’équipement et du processus de fabrication. Elle s’accorde donc parfaitement avec notre propos, même si la norme limite elle-même son champ d’application normal aux processus « batchs ».

Ce concept prend tout son sens si l’on intègre le contrôle de l’équipement dans l’ingénierie globale. Le modèle physique S88 (ou sa généralisation S95) propose une décomposition hiérarchique de l’installation. A chaque niveau, l’automaticien peut attacher des « Eléments Procéduraux d’Equipement ». Ces fonctionnalités génériques du système de production, confinées dans leur environnement respectif, forme le « langage orienté processus » du système de production dégagé de ses responsabilités vis-à-vis de la méthode d’élaboration du produit fini.

Cette décomposition statique va évoluer avec l‘actif physique (modification, installation, démantèlement des équipements) sans remettre en cause l’ensemble du système.

La norme S88 se concentre sur l’exécution du programme de Production par un atelier déterminé ou « cellule de processus ». Elle n’a pas été conçue a priori pour une production distribuée dans laquelle plusieurs ateliers participeraient à l’élaboration globale du produit.

Toutefois, son modèle procédural pourrait très bien évoluer vers une forme plus souple faisant intervenir plusieurs cellules de processus.

La recette Maître décrit la méthode de fabrication adaptée à l’atelier

Les recettes « Générale » et « Site » doivent permettre de présenter le processus d’une façon générique (sans référence aux ressources particulières de productions) tout en portant l’ensemble de l’information nécessaire qui, combinée avec les données spécifiques des ressources cibles, permettra de générer la recette « Maître » appropriée.

Le langage procédural PFC (S88.02) permet de décrire la recette maître et les couplages avec les éléments procéduraux d’équipement (mais n’est pas encore adapté aux recettes générale ou de site)

Un modèle hiérarchique des ressources qui impose une modularisation ordonnée du système de production. (précisé par ASRID)

Les ressources intègrent les fonctions de processus utilisables par les recettes

La norme S88.02 propose une interface d’échange des recettes Maître et de Contrôle et du programme de production destiné à la cellule de production. (basée sur des tables SQL)

Les prochains travaux pourraient porter sur les sujets suivants :

Couplage normalisé avec les équipements

Transformation Recette Générale / Site -> Recette Maître

Compatibilité avec la norme S95

Définition d’une interface XML

La norme S95 s’attache à la formalisation des échanges autour du système de production vers les autres domaines de l’Entreprise.

Conçue pour s’appliquer à tous les types de production, elle n’impose pas de modèle d’organisation de l’Entreprise ni d’architecture du système de production. Elle suggère toutefois un modèle physique de l’Entreprise extrapolé à partir de la norme S88 et une définition des fonctions et des flux d’informations basée sur le modèle PRM (Purdue University Reference Model) publié par l’ISA.

Ingénierie du Produit

La définition du processus de fabrication fait appel à des « Segments de Produit » qui contiennent toutes les exigences en ressources de production. Ces segment sont définis avec une granularité adaptée à la planification et au contrôle des coûts.

Le modèle de définition des ressources est banalisé pour toutes les ressources : matières et énergie, personnel, équipements.

Pas de structure imposée, mais le modèle permet d’échanger des éléments hiérarchisés

L’organisation du système de production par Segments de Processus correspond bien au concept de « Ressource fonctionnelle de production ».

La mise à disposition en temps réel des Capabilités du système de production permet une programmation réaliste : disponibilité et utilisation, maintenance et pannes, installation et désinstallation d’équipements…

Le programme de production contient des « Segments de Produit » qui seront exécutés par des « Segments de Processus » compatibles.

On peut synthétiser les domaines de ces normes de la façon suivante :

Définition de la « Recette Générale » pour l’Entreprise de Produit dans le cas des processus batch (extension possible aux processus discret et continus ?)

Organisation de la cellule de processus et intégration de ses ressources fonctionnelles

Gestion des « Recettes maîtres » exécutables par les Cellules de Processus sélectionnées. Ces Recettes Maîtres pour l’entité de Production peuvent n’êtres que des « Recettes Partielles » du produit destiné à la consommation.

Contrôle des flux d’information entre les systèmes de production (Entreprises de Production) et leurs donneurs d’ordre (Entreprises de Produit)

Contrôle des flux d’information entre les systèmes de production et les domaines connexes (Maintenance, Qualité)

 

Les points de communication existent, et une consolidation devrait permettre de faire converger les terminologies et les modèles.

Mue par une compétition exacerbée et par la dictature du consommateur devenu impérative avec le développement du commerce électronique, L’Entreprise invente une nouvelle répartition des rôles et des activités que les systèmes d’information doivent supporter.

La pyramide « intégrée » CIM a définitivement éclaté, des structures extrêmement réactives et coopératives voient le jour pour répondre à une demande devenue par nature imprévisible, bousculant certains axiomes de l’ingénierie et de la planification prévisionnelle.

L’intelligence des concepteurs, des intégrateurs et des Entreprises nous a déjà mis sur la voie : Les systèmes sont à présent conçus sur des bases ouvertes et modulaires qui devraient permettre une mutation adaptée à ces exigences.

Des travaux de standardisation importants sont en cours aussi bien dans le domaine normatif traditionnel qu’au sein d’associations professionnelles :

Ils doivent être complétés, consolidés et soumis au verdict de la mise en œuvre.

Parmi ces travaux, la production des comités ISA SP88 et SP95 matérialise des initiatives d’un niveau moins académique que pragmatique avec un souci d’application immédiate.

Il faut impérativement faciliter le passage de la conception des produits à la réalité industrielle.

La cohérence entre les données de base fournies par la R&D, les données de planifications de l’ERP et les données d’exécution du système de contrôle est un enjeu fondamental, encore loin d’être bien compris par toutes les parties.

Le modèle S88 propose une vision de la « Recette » sous plusieurs angles selon le stade de la conception et son utilisation (Recettes Générale, Site et Maître), mais ne les définit pas formellement et ne propose aucune règle de transformation. La communauté des ERP ignore généralement tout de la norme S88 qui n’a pas encore réussi à franchir son domaine originel du contrôle de procédé.

La norme S88 est focalisée sur les processus batchs et doit prouver son universalité ou évoluer pour assurer la représentation de toutes les fonctions opérationnelles de la production. De plus, l’entité supérieure réellement prise en compte par la norme S88 est l’atelier (Process Cell), vision réductrice du problème.

De son côté, la norme S95 présente toutes les caractéristiques d’ouverture nécessaires dans ce contexte, et reste neutre dans la description des fonctions du procédé.

La seconde partie de la norme S95 définit des attributs standards pour porter l’information, mais les propriétés citées ne sont comprises que dans le cadre d’un agrément entre les parties.

Elément opérationnel et dynamique de l’Entreprise, ossature des flux d’information de la chaîne logistique autour de la fonction de production, le programme de production s’appuie directement sur les éléments plus statiques de l’ingénierie du produit et des ressources et représente l’ensemble de la problématique mise en évidence ici.

L’entreprise « sans délais » est déjà sur la voie, et l’on peut devrait observer une évolution à plusieurs niveaux :

Les contraintes de l’industrie pharmaceutique imposent de formaliser les phases du cycle de vie des systèmes de contrôle-commande. Cette approche devrait se généraliser pour garantir la qualité des systèmes. Elle ne suffit toutefois pas à garantir la qualité « fonctionnelle » du système sans une implication profonde de l’utilisateur dans la réalisation du cahier des charges.

Nous présenterons ici la démarche et la méthode utilisées pour l’automatisation d’un atelier polyvalent pharmaceutique (Rhodia à Holmes Chapel, Royaume Uni). Le cahier des charges comporte de nombreux aspects, mais nous nous limiterons ici à la spécification opérationnelle du système de conduite.

La construction de l’installation est presque terminée, les bornes d’entrée/sortie sont en cours de câblage lorsqu l’on réalise que le projet est en retard. Dès les premiers tests, il est clair qu’il sera impossible de terminer à temps, des milliers d’erreurs ou d’omissions apparaissent. Le projet passe en mode panique.

L’intégrateur se met à travailler sans compter ses heures, essayant d’obtenir des informations, testant le logiciel applicatif, recherchant les erreurs, essayant de s’y retrouver dans l’énorme liste de commentaires et de modifications. Finalement, le logiciel est livré avec un minimum de fonctionnalités indispensables pour permettre le démarrage.

D’où vient le problème?

Ce n’est certainement pas la faute du système de contrôle : les systèmes modernes sont puissants, ils peuvent faire tout ce que l’ingénieur automaticien est susceptible de lui demander, s’il est programmé correctement.

Il ne faut pas beaucoup de temps pour programmer le système, si l’on sait ce qu’il faut programmer

Si nous demandons aux programmeurs ce qu’il s’est passé, ils nous diront probablement :

For heureusement, tous les projets ne tournent pas à la catastrophe. Les méthodes de gestion de projet utilisée en informatique sont à présent mises en œuvre dans les projets d’automatisation, avec pour résultat un suivi rigoureux et une meilleure maîtrise des coûts et des délais.

Les contraintes particulières de l’industrie pharmaceutiques qui doivent satisfaire les exigences cGMP (Current Good Manufacturing Practices) de la FDA (Federal Drug Administration) ont amené l’ISPE (International Society for Pharmaceutical Engineering) à se pencher sur le problème en développant les règles du GAMP (Good Automated Manufacturing Practices) basées sur l’ISO 9000-3.

Le cahier des charges (URS ou User Requirement Specification) est l’étape initiale du cycle de vie d’un système d’automatisation dans laquelle l’utilisateur final exprime ses besoins. Malgré cette position déterminante dans le succès d’un projet, il ne fait pas toujours l’objet de soins aussi attentifs que la conception et la réalisation qui doivent souvent pallier l’insuffisance de l’expression des besoins de l’utilisateur.

En distribuant les rôles entre l’utilisateur et l’intégrateur et en établissant des procédures adaptées, il est possible de concevoir un système avec un minimum d’implication de l’utilisateur.

Mais la démission de l’utilisateur dans l’expression initiale du besoin au profit d’une validation a posteriori des spécifications fonctionnelles réalisées par l’intégrateur ne garantit pas que l’utilisateur obtient ce qu’il aurait voulu. En l’absence d’une expression détaillée des besoins, c’est la spécification fonctionnelle que servira de base à la qualification opérationnelle de l’installation. L’utilisateur doit alors se contenter de vérifier les contre-sens fonctionnels à la lecture d’une documentation volumineuse et indigeste sur laquelle il s’engage.

Evidemment, une telle démarche conduit à de nombreuses modifications lors de la mise en service afin que les besoins essentiels, exprimés ou non soient couverts par les fonctionnalités du système.

C’est pourquoi il est important que le cahier des charges décrive de façon exhaustive, détaillée et indépendante du système toutes les fonctions attendues de ce système.

Le cahier des charges remplit trois fonctions :

Spécification du système

C’est sa fonction la plus évidente. Suffisamment détaillé et précis, expression conforme des besoins de l’utilisateur, il est le support efficace de spécification et de la conception du système.

Support pour la recette du système

Si la recette du système n’est confrontée qu’au spécifications de l’intégrateur, il subsiste une marge d’interprétation qui peut conduire à des surprises lors du démarrage. Il est essentiel que les tests de qualification s’appuient sur le cahier des charges qui fait abstraction des contraintes de l’implémentation pour exprimer le besoin réel. L’utilisateur qui a rédigé le cahier des charges doit pouvoir s’assurer de la conformité de l’installation livrée.

Documentation du système en exploitation

Le langage utilisé pour la description fonctionnelle au niveau du cahier des charges est naturel pour l’exploitant. Il a d’ailleurs participé à sa rédaction. Il est donc naturel d’utiliser ce document comme aide à l’exploitation.

Ce point est très important : il justifie à lui seul le travail important qu’il faut fournir pour obtenir un document de qualité. C’est une garantie de cohérence totale tout au long du cycle de vie.

Ceci impose bien sûr une gestion rigoureuse des changements.

Deux catégories de personnes détiennent la connaissance des fonctionnalités attendues du système automatisé et seront confrontées aux comportements spécifiés:

Les ingénieurs procédé

Les exploitants

L’automaticien n’apparaît pas ici. Pourtant, dans de nombreux projets, il est le rédacteur exclusif du cahier des charges. On peut invoquer les raisons suivantes :

Refus des premiers de s’impliquer dans une tâche qui leur semble hors de leur compétence.

Très grande expérience des seconds qui peuvent produire des spécifications complètes qui seront comprises par leurs pairs lors de la réalisation.

Il est vrai que dans certains cas, l’automaticien a toutes les compétences requises grâce à son expérience dans le métier et sur les équipements considérés. Mais ceci est de plus en plus rare, et l’on a même des difficultés à trouver des automaticiens capables de maîtriser l’ensemble du système : instrumentation, câblage, partie opérative, interface homme-machine, acquisition et traitement des données…

En pratique, il faut bien reconnaître qu’une certaine expérience du contrôle de procédé est indispensable pour mener à bien une telle tâche, et que l’automaticien doit intervenir de toute manière pour garantir la cohérence des spécifications.

Dans un tel contexte, il est encore plus important de poser des règles précises pour la construction et la rédaction du cahier des charges. En se basant sur des standards et des normes, on dispose de bases solides que l’on complètera par des directives permettant d’assurer la cohérence.

Les procédés Batchs sont réputés pour être parmi les plus difficiles à contrôler parce qu’ils disposent de multiples états stables et parce que le procédé est rarement figé.

L’idée originale a été de séparer totalement le contrôle des équipements du contrôle du procédé. La norme ISA S88 / IEC 61512 a normalisé le contrôle des procédés Batchs, et la séparation du contrôle des équipements du contrôle de procédé est un de ses fondements.

On considère une installation industrielle comme le fruit de l’assemblage d’éléments mécaniques relativement standards. Dans notre cas, en réunissant réservoirs, échangeurs, sécheurs, tuyauteries, pompes, vannes…, on peut réaliser n’importe quel type de procédé. En réunissant ces éléments en sous-ensembles homogènes, on peut leurs associer des fonctionnalités élémentaires totalement indépendantes du procédé de fabrication. C’est le Contrôle des Equipements.

Pour exécuter et automatiser un procédé de fabrication, on fait appel aux services de base des équipements en décrivant des procédures qui seront exécutées manuellement ou automatiquement : c’est le Contrôle du Procédé.

Dans notre cas, le procédé lui-même n’était même pas connu au moment de la conception du système !

Le cahier des charges se limite au contrôle des équipements : le contrôle du procédé fait l’objet de projets indépendants selon les produits à fabriquer. L’incidence de la mise en œuvre d’un nouveau produit doit avoir des répercussions minimales sur le contrôle des équipements : généralement, il s’agira simplement de s’adapter à la nouvelle configuration matérielle (ajout de nouveaux équipements, modification d’équipements existants).

Il est bien, difficile de suivre une approche cartésienne, du général au détail pour définir l’ensemble d’un système automatisé. Une démarche analytique, a priori moins élégante, s’avère beaucoup plus facile à appréhender.

RHODIA (à l’époque Rhône Poulenc), a mis au poins la méthode ASTRID dont l’un des objectifs est de proposer un processus systématique pour définir des objets indépendants de petite surface.

C’est également l’une des bases de la norme S88. ASTRID y apporte des règles et des mécanismes simples pour rendre le découpage fonctionnel facile et compréhensible par des non-automaticiens.

On peut présenter les 2 approches par le schéma suivant :

Les objets physiques (S88 : Equipment Modules, Control Modules ; ASTRID : Ressources) représentent les plus petites entités matérielles reconnues par le système. On leur associe des comportements génériques valables en toutes circonstances.

Les objets fonctionnels sont définis à partir des services jugés nécessaires qui vont mettre en œuvre un certain nombre d’objets physiques.

Au niveau supérieur du Contrôle de Procédé (modèle procédural), on décrira les enchaînements des objets fonctionnels nécessaires pour que l’atelier fabrique le produit demandé (manuellement ou automatiquement).

La méthode propose une démarche simple et rigoureuse :

Mise en évidence des entités physiques (groupements élémentaires d’équipements) sur les schémas : les Ressources

Spécification des Ressources

Définition des fonctions élémentaires par analyse des flux

La démarche est donc résolument « Bottom-Up ». En partant de l’instrument, on peut représenter le schéma suivant

La documentation du cahier des charges comprend :

Philosophie du Contrôle-Commande : pour situer le projet et les contraintes, besoins généraux et les données de base du projet.

Description des objets génériques : Chaque objet physique ou fonctionnel est défini en termes génériques pour être utilisé par de multiples instances

Description des instances des objets : chaque objet est défini en associant un objet générique à un équipement

Les alarmes et verrouillages de sécurités « non contextuels » traités sur une base combinatoire et pouvant dépendre du procédé de fabrication.

Documentation complémentaire : Tous les détails de la sémantique de la description, des mécanismes de base, pour assurer la cohérence et la compréhension des spécifications

La méthode, basée sur des éléments très concrets du procédé lui-même et faisant largement appel à la conception orientée objet, a été mal perçue au départ par l’équipe système de conduite de l’engineering et du site.

Ceci nous a obligé à pousser très loin la formalisation des règles sémantiques utilisées pour la description fonctionnelle et la description des mécanismes de base de coopération entre objets. Cette documentation devrait toutefois être réutilisable pour d’autres projets, et elle a permis de préciser de nombreux points non documentés de la méthode.

L’établissement d’une spécification fonctionnelle utilisateur détaillée demande un travail très important en lui-même : c’est autant de temps de gagné pour la réalisation. Dans notre cas, la réalisation par des non-automaticiens et en plusieurs équipes a sensiblement allongé le temps de rédaction des spécifications avec de nombreuses reprises pour assurer la cohérence de la documentation (mise en page, style des expressions, noms des variables, répartition fonctionnelle entre objets…)

La méthode a été remarquablement acceptée par l’équipe chargée de la spécification fonctionnelle. Cette équipe était composée de trois chefs de quart d’exploitation et de deux ingénieurs procédé, guidés par une expertise adéquate.. Il n’a pas été possible de mobiliser des automaticiens pour cette tâche.

Les spécifications se sont révélée extrêmement claires et dépouillées par rapport à ce que l’on aurait pu craindre d’une équipe d’automaticiens : seuls les problèmes réalistes sont traités, les simplifications sont admises et validées par la qualité même des rédacteurs. De plus, la méthode définit des mécanismes qui prennent en charge un grand nombre de verrouillages de sécurités

L’utilisateur connaît parfaitement ce qu’il peut attendre du système et n’en demandera pas autre chose. Les tests de qualification seront exécutés face aux besoins exprimés et non aux besoins compris, ce qui doit éliminer un certain nombre de modifications lors de la mise en service.

Le cahier des charges accompagne toute la vie du système de conduite. Sa maîtrise par les concepteurs du procédé et l’exploitant est déterminante aussi bien lors de la construction que pendant l’exploitation des installations.

Les spécialistes du procédé et de l’exploitation sont les acteurs principaux de la rédaction du cahier des charges du système de conduite avec le support de l’automaticien. Il est important de prendre de la distance avec l’implémentation, ce qui est très difficile pour le spécialiste.

Dans notre cas, les apports essentiels de la méthode ASTRID et de la norme S88 ont permis une prise en charge totale de la spécification par les véritables acteurs du cahier des charges et une simplification notoire. Le découplage avec l’automaticien s’est révélé très enrichissant. L’astuce a fait place au pragmatisme et à la simplicité.

L’intégration des systèmes de production et de gestion est loin d’être un sujet nouveau, mais elle demeure un challenge face à un bilan peu convainquant :

La rigidité de l’intégration « dure » des modèles CIM des années 70 a laissé des traces, et les découplages d’aujourd’hui offrent des solutions aux interfaces floues et difficiles à maintenir.

La maturité technologique des systèmes d’information est longue à venir, même si les progrès sont rapides. La puissance des systèmes augmente rapidement, mais les méthodes n’en tirent pas toujours le meilleur parti.

Mais les aspects techniques n’offrent plus aujourd’hui de difficultés majeures. Les différence culturelles entre les métiers de la production et de la gestion, la diversité des contraintes et des approches d’un type d’industrie à l’autre sont la source des principaux problèmes.

C’est ce constat qui a été à l’origine du développement de la norme ANSI/ISA S95.

Dans la suite de l’exposé, l’ensemble du système d’information du système de production est appelé « Contrôle ». Ce terme correspond à l’usage anglophone et reste compréhensible en Français.

L’entreprise doit continuellement :

Répondre aux changements du marché

Répondre aux changement de la technologie

Réduire les craintes du changement

Réduire les perturbations sur l’activité ou la perception par les partenaires des perturbations engendrées par le changement

Gérer les coûts

Comment faire face à ces contraintes ?

Deux facteurs sont particulièrement importants :

Une bonne information est un préalable pour de bonnes décisions. La qualité de l’information réside autant dans son contenu qui doit être adapté à l’usage que dans la façon dont elle est obtenue est diffusée

Le personnel doit être attentif et intéressé aux performances de la production

Rôle du système d’information :

Le système d’information intégré doit permettre :

De gérer efficacement les données : Validité, Format, agrégation en méta-données, Collecte et traitements automatisés, Mise à disposition dans un temps compatible avec les besoins (« temps réel »)

D’optimiser le coût total de possession : Ressources, Actifs, Capitaux

De réduire les risques :Amélioration de la flexibilité, de la compétitivité, Adaptation plus facile au changement

Problème !

L’interface entre système de production et de gestion réunit des communautés disparates :

La communauté du Contrôle de Production maîtrise la complexité des problèmes de l’atelier, Les autres fonctions de l’Entreprise lui sont pour la plupart étrangères

La communauté de la gestion industrielle est à l’aise dans ses problèmes de planification et de comptabilité, les système de contrôle de production lui apparaissent plutôt comme une boite noire.

Face à cette situation, on identifie besoins suivants :

Réduire le temps nécessaire pour les utilisateurs pour atteindre la pleine production de nouveaux produits.

Permettre aux vendeurs de développer les outils appropriés pour intégrer les Systèmes de Contrôle dans l’Entreprise.

Permettre aux utilisateurs de mieux identifier leurs besoins.

Réduire le coût de l’automatisation des processus de gestion de la production.

Optimiser la "Chaîne d’Approvisionnement" de l’utilisateur.

Réduire l’effort d’ingénierie du cycle de vie

L’ambition de la norme S95 est de réduire les difficultés de l’intégration du système de contrôle de la production. Face à ces problèmes, les objectifs sont les suivants :

Etablir un vocabulaire commun aux différentes stratégies de production

Proposer une vue commune des problèmes

Construire un modèle commun

Définir les structures de données

Obtenir rapidement ces spécifications

La norme S95 s’adresse à ceux qui sont :

concernés par la conception, la réalisation et l’exploitation des installations de production

responsables de la spécification d’interfaces entre les systèmes de contrôle de procédés quels qu’ils soient et les autres systèmes de l’entreprise

concernés par la conception, la création, le marketing et l’intégration de produits utilisés pour réaliser ces interfaces

Application

La norme :

Peut être utilisée pour améliorer la capacité d’intégration existante des Systèmes de Contrôle dans le Système d’Entreprise.

Peut être appliquée sans considération du degré d’automatisation.

Favorise une bonne intégration des Systèmes de contrôle dans le Système d’Entreprise
pendant tout le cycle de vie de ces systèmes.

Cette norme n’a pas pour objectif :

d’affirmer qu’il n’existe qu’une seule voie pour l’intégration des Systèmes de Contrôle dans le Système d’Entreprise

de forcer les utilisateurs à abandonner leurs pratiques courantes pour gérer l’intégration

de restreindre ou de contraindre les développements des systèmes d’intégration

Comment une telle norme peut-elle couvre un large spectre de systèmes de production : fabrication sur stock ou à la commande, conception à la commande, Kanban, fabrication répétitive, continue ou batch ?

Pour répondre à cet objectif, la norme :

considère les processus de gestion séparément des processus de fabrication

définit l’information sans imposer les processus de traitement de l’information.

Pour conduire ses travaux, le groupe SP95 s’est appuyé sur un modèle d’entreprise élaboré.

Le PRM a été développé à le fin des années 80 à l’université de Purdue (USA) par un consortium de vendeurs, d’utilisateurs et d’universitaires. Ce projet était conduit par le Dr. Theodore Williams, membre du comité SP95 et ancien président de l’ISA. Il définit plusieurs modèles utilisés pour décrire l’ensemble d’une entreprise de production, des éléments du rapport final sont inclus dans la norme S95.01.

Le modèle hiérarchique de la planification et du contrôle

propose un découpage conventionnel par niveau des fonctions de l’entreprise vues de la production dans un contexte opérationnel. Il a permis de positionner clairement l’interface et a établit la base des travaux du groupe SP95.

Figure 4 - modèle hiérarchique de la planification et du contrôle

Sur ce modèle, la norme S95 définit l’interface entre les niveaux 3 et 4 :

Figure 5 Domaines S95

Domaine S95.01 : Modèles & Terminologie

La première partie de la norme définit :

L’Étendue du domaine de contrôle manufacturier

L’Organisation de l’actif physique de l’Entreprise manufacturière.

Les Fonctions concernées par l’interface entre les domaines du Contrôle et de Gestion de l’Entreprise

L’Information qui est partagée entre les fonctions de Contrôle et les fonctions d’Entreprise

Domaine S95.02 : Structures de Données et Attributs

La seconde partie de la norme définit:

Les attributs des objets décrits dans la partie 1

Les structures de données pour échanger l’information objet définie dans la partie1

Points particuliers :

Indépendance vis à vis de la technologie du support de l’information

Pas de protocole imposé

Pas de format imposé pour les données

Domaine S95.03 : Modèles des activités de production

La troisième partie de la norme définit les modèles des activités à l’intérieur du niveau 3 du modèle hiérarchique PRM :

Plusieurs modèles sont utilisés pour décrire les concepts de l’intégration :

Chaque modèle précise une vue particulière du problème de l’intégration

Ces modèles révèlent des niveaux de détail croissants

Modèle Hiérarchique des Activités

Modèle des Flux de données entre Fonctions

Catégories d’Information

Modèles Objets

Le Domaine détermine sur qui repose la responsabilité. On distingue le domaine du Contrôle des autres domaines de l ’Entreprise.

Une fonction appartient au domaine du Contrôle si elle :

Est utile aux opérateurs pour faire leur travail

Est critique pour assurer la conformité à la réglementation.

Est critique pour la sûreté des installations

Affecte la phase opérationnelle de la vie de l ’installation (par opposition à sa conception, sa construction ou son démantèlement)

Identification des flux

Le modèle des flux d’information permet définir les échanges et leur contenu.

Les flux d’information sont classés par catégories. Les diagrammes de VENN sont utilisés pour illustrer les recouvrement entre les différentes catégories d’information.

Les objets suivants ont été définis :

La capacité est définie dans le temps et selon ses caractéristiques :

La norme S95.02 propose les attributs suivants (pour l’objet « Capacité de Production »

Développé par le consortium W3C, le langage XML étend aux données les caractéristiques du langage HTML de description de pages. Alors que le langage HTML est dédié à la communication entre la machine et l’homme, le langage XML permet aux ordinateurs de dialoguer entre eux. Indépendant des systèmes, il s’affirme de plus en plus comme le medium de communication privilégié de la Supply Chain.

Le comité SP95 a démontré l’utilisation du langage XML pour l’implémentation pratique de la norme S95., L’exemple partiel ci-dessous, basé sur les schémas BIZTALK,  concerne la capacité de production. Ces "Schémas" peuvent être interprétés facilement et permettent d’enrichir les messages en toute transparence.

Développée dans un esprit pragmatique par des acteurs diversifiés, la norme S95 offre une voie vers la maturité de la communication avec le système de production. Après les interfaces dédiées et propriétaires des systèmes MES ou des extensions manufacturing des ERPs, elle présente une vision complète et un cadre précis pour la définition et la mise en oeuvre des interfaces.

Lors de la découverte de l'électricité, des séances d'électrisation volontaires démontraient sa réalité et sa puissance. Rien de tel pour l'Automatique qui n'est pas une science fondamentale de notre univers physique, mais un élément primordial de la vie de tous les jours.

L'Automatique a toujours fait partie de notre vie. Dès que l'on influence la façon dont une activité est modifiée par un événement extérieur sans intervention manuelle, on fait de l'Automatique : Le piège qui se referme sur l'animal attiré par un appât, le réservoir de la chasse d'eau qui se remplit sans déborder après chaque utilisation, c'est de l'Automatique.

Ce dernier quart de siècle a vu la naissance de nouveaux métiers dédiés à l'Automatique, rapidement impliqués dans l'évolution des technologies de l'information : Contrôle de Procédé, Régulation Automatique, Cybernétique, Robotique, Productique, Domotique… Nous n'utiliserons ici que le terme "Automatique", sensé couvrir tous ces métiers.

Au début, les électriciens et les micro-mécaniciens (voire les horlogers), assuraient le développement et la maintenance des systèmes de contrôle des équipements de production. Les électriciens sont devenus des Automaticiens et les micro-mécaniciens des Régleurs ou Instrumentistes. Les uns ont câblé des relais électromécaniques puis développé et programmé les Automates Programmables. Les autres ont étalonné les capteurs et actionneurs analogiques, réglé les dispositifs de calcul pneumatiques, hydrauliques, électroniques puis conçu et configuré les Système Numériques de Contrôle Commande. Aujourd'hui, on ne parle plus que d'Automaticiens. La technologie et le départ à la retraite des pionniers achèvent lentement la convergence des deux types de systèmes.

Au seuil du nouveau millénaire, la technologie a connu des progrès spectaculaires :

Les microprocesseurs toujours plus puissants ont pris le relais des systèmes pneumatiques, hydrauliques, électromécaniques ou électroniques analogiques.

Les réseaux informatiques offrent des capacités de communication en constante augmentation, à comparer aux tubes de cuivre ou plastique et aux liaisons électriques utilisés autrefois pour véhiculer l’information.

La régulation du niveau d'eau d'une chaudière au Vietnam assurée par deux hommes, l'un surveillant la colonne transparente de l'indicateur de niveau, l'autre manœuvrant la vanne d'eau, les deux communiquant par le son du gong ne peut être comparée au contrôle complexe des chaudières de nos centrales modernes.

Pourtant, ces progrès n'ont pas encore transformé radicalement la conduite, la sûreté et la flexibilité des installations et ont même eu des conséquences néfastes sur la façon de concevoir l’automatisme :

Les dispositifs mis à disposition de l'opérateur pour superviser le fonctionnement des unités ont une efficacité ergonomique souvent inférieure aux tableaux de commande d'autrefois.

Les comportements de l’automatisme dans les situations anormales sont difficilement compensés par l'opérateur mal informé par une information surabondante et insuffisamment traitée.

La conception rigide de l’automatisme limite la flexibilité inhérente du système physique de production et les évolutions du procédé nécessitent des modifications profondes de l’automatisme.

L'ingénierie du système de contrôle-commande, libérée de la plupart des contraintes matérielles par le logiciel, a perdu beaucoup de sa rigueur. Les modifications ne sont pas gérées et la qualité du système se dégrade rapidement.

Ces remarques ne s'appliquent bien sûr pas à tous les systèmes existants, mais la situation ainsi décrite est largement majoritaire. Parmi les causes de cette situation, le décalage entre l'évolution de la technologie et son assimilation pratique par les hommes. Pour y faire face, la réduction du temps de travail offre l'occasion de consacrer une part beaucoup plus significative à la formation continue.

La technologie continuera à évoluer, et il est difficile d'imaginer les moyens utilisables pour construire les automatismes de demain. Les grands axes sont tracés et nous sommes au début d'une révolution culturelle plus importante que la technologie elle-même : La fin de ce millénaire a vu la naissance de l'Automatique industrielle et des technologies de l'information qui ont permis son développement. Le début du prochain millénaire sera celui de sa maturité.

L’automatisme ne sera plus une entité autonome, mais fera partie intégrante du système de production. On distinguera le contrôle des équipements du contrôle du procédé de fabrication lui-même, les entités de contrôle communiqueront entre elles de façon simple et standardisée

Le rôle de l'automaticien au sens strict va décroître. Il ne sera plus seul pour concevoir et maintenir les composants d'automatisme du système de production. L'Automatique devient partie intégrante des métiers qu'il supportait autrefois

Grâce à l’Automatique, l'opérateur ne sera plus un exploitant critique et insatisfait, mais un acteur fondamental du système de production dans ses phases de conception, d'exploitation et de maintenance et un participant responsable aux objectifs de l'entreprise.

Cette révolution a commencé, les travaux en cours fournissent déjà une matière importante utilisable :

La norme IEC 61158 (réseaux de communication et bus de terrain), au-delà des conflits d'intérêt qu'elle a fait naître, apporte au concept de "Bus de Terrain" des notions de communication évoluée qui préfigurent l'ossature de la communication à l'intérieur du système de production

L'OPC (OLE for Process Control, interopérabilité des applications distantes) agissant en dehors de la normalisation, vise à fournir l'ensemble des services nécessaires pour assurer le transfert de l'information entre composants. Elle s'appuie sur la technologie Microsoft, mais son succès est tel que l'OAG travaille sur une implémentation compatible CORBA.

La norme IEC 61131-3 (Langages de programmation pour l’Automatique) définit des langages puissants qui libèrent la créativité des concepteurs de composants d'automatisme de base

La norme IEC 61512 / ANSI-ISA S88 (Contrôle des procédés par lots), développée initialement pour les procédés discontinus, propose un modèle conceptuel qui sépare le contrôle des équipements (indépendant du produit à fabriquer, basé sur les ressources physiques du système de production) du procédé lié au produit à fabriquer. On peut considérer ses concept comme un niveau supérieur de l'automatisme capable de piloter les composants élémentaires attachés aux équipements.

La norme ISA S95 (intégration Système d’Entreprise – Système de contrôle) prend acte de la spécificité du système de production et propose un modèle d'intégration qui facilitera entre autres la communication de l’automatisme avec l'Entreprise dans son ensemble.

On peut schématiser le chemin à accomplir par la figure suivante :

Le système de production automatisé peut être analysé sous les 3 composantes suivantes :

La capabilité est l'aptitude à exploiter les ressources de l'unité pour fabriquer le produit désiré : Capacité et Fonctionnalités. L'Automatique en est le vecteur indispensable, la plupart des processus de production ne peuvent être exécutés entièrement manuellement.

La flexibilité est l'aptitude du système de production à exploiter des procédés de fabrication différents sans reconception du système. L'exploitation manuelle est idéale sous cet angle. Dans le meilleur des cas, l'Automatique "classique" restreint les facultés inhérentes du système de production. Dans le pire des cas, l'installation est "mono-produit".

La complexité de l'Automatique est le prix à payer pour supporter la capabilité et la flexibilité du système de production.

L'Automatique intégrée doit assurer la flexibilité et supporter la capabilité inhérente du système de production d'une façon simple.

L'Automatique atteint l'âge de raison. Elle n'est plus le domaine réservé de l'automaticien débordé par des responsabilités hors de son propos, le facteur perturbant des démarrages, le siège des dysfonctionnements. L'Automatique s'intègre réellement dans l'ingénierie, chaque acteur du projet y prend sa part de responsabilité.

L'Automaticien va-t-il disparaître ? L'informatique, qui a évolué beaucoup plus rapidement, nous montre une spécialisation accrue de métiers. Seuls ceux qui font un effort considérable pour se maintenir à niveau avec l'état de la technologie survivent. L'Automatique est un domaine beaucoup plus calme, mais cette spécialisation est déjà dans les faits : ergonomie du poste de conduite, réseaux, sûreté de fonctionnement, câblage, instruments, réglage… L'Automaticien homme-orchestre capable d'intervenir dans tous les aspects du système a déjà disparu.

A coté de ces spécialistes "technologiques", on ne trouvera plus d'ingénieurs d'applications capables d'appréhender toutes les contraintes du procédé, mais au contraire des spécialistes du procédé capables de définir les besoins d'Automatique et de les mettre en œuvre.

Aujourd'hui déjà, les systèmes qui donnent satisfaction sont ceux dont les applications ont été réalisées sous la responsabilité directe du site de production, et non délégués sans directives et contrôles précis aux intervenants extérieurs. La rédaction des spécifications et la validation prennent une part de plus en plus importante dans les projets. L’industrie pharmaceutique, par ailleurs relativement peu automatisée, est pionnière dans ce domaine avec des projets rigoureusement encadrés par les recommandations FDA ou GAMP. Le groupe de travail "Spécification

de la conduite des Systèmes de Production » de l’EXERA travaille également sur ce sujet.