S88.02 : une nouvelle avancee dans le controle flexible des procedes de fabrication par lots Article S88.02 pour MESURES N?714 AVRIL 1999 L'ISA L'Instrumentation Society of America est une association multinationale d'origine americaine sans equivalent par sa taille (40000 membres, mais seulement une centaine en France) et par son influence dans tous les domaines du controle de procede, des techniques de mesure et d'action sur le process jusqu'a l'integration des ressources de production dans la " supply chain " en passant par les reseaux de terrain, le graphisme des boucles de regulation... L'origine culturelle de l'ISA fait de cette association le lieu privilegie de rencontre des specialistes du controle des procedes. L'industrie manufacturiere s'y reconnait moins, mais l'ISA tend a devenir un element federateur de la couche " executive " du systeme d'information. L'ISA est une organisation complexe, et on peut noter parmi ses principales activites : 22 divisions technologiques et scientifiques correspondant aux nombreux domaines d'intervention de l'ISA Un programme de formation elabore, mais supporte essentiellement aux USA La revue mensuelle INTECH De nombreuses publications techniques Le site web HYPERLINK http://www.isa.org www.isa.org Animation d'expositions et de conferences. La conference technique ISA TECH (se deroulera cette annee a Duesseldorf a l'occasion d'INTERKAMA du 18 au 20 octobre) Les comites " SP " (Standards and Practices) qui elaborent les standards (plus de 100 publications) Les sections locales qui gerent les structures a l'exterieur des Etats-Unis. La section ISA France est dirigee par Rolland COLLAY, de l'ecole des Mines de Saint-Etienne (collay@emse.fr). Les comites SP de l'ISA Il existe une vingtaine de comites SP actifs a l'ISA. Le but de ces comites est de produire des documents de standardisation visant a materialiser, formaliser, mettre en valeur un savoir-faire ou une technique. Il s'agit de faciliter l'application de ces techniques et d'en assurer la diffusion. L'ISA est agree ANSI de telle sorte que ces standards sont des normes de fait aux Etats-Unis. Les standards sont generalement soumis a l'IEC qui les approuve et les publie en tant que norme internationale ISO. La creation de ces comites est issue d'initiatives diverses apres enquete d'utilite et de non-recouvrement avec les travaux d'autres organisations. Les specialistes de toutes nationalites concernes par l'objet du comite sont invites a y participer. Chaque comite est dirige par un president et nomme ses membres votants parmi les plus assidus selon des regles definies par le comite lui-meme selon ses buts (Par exemple, la communaute des utilisateurs doit representer un ratio determine). Les comites utilisent generalement 2 moyens de communication : Reunions periodiques " physique " Internet (repertoire sur le site FTP de l'ISA, liste de diffusion) Tous les documents produits par l'activite du comite sont mis a disposition des membres (Brouillons successifs du standard, etudes des groupes de travail, comptes-rendus des rencontres) L'activite peut se derouler selon plusieurs axes : Reunions de travail Redaction des documents conformement aux decisions prises lors des reunions Commentaire des documents par tous les membres Creation de groupes de travail ou delegation de taches pour traiter des aspects particuliers Developpement de maquettes pour valider les travaux ... On peut citer parmi les SP actifs la participation de l'ISA dans la " Fieldbus Fundation " pour les bus de terrain (SP50), le pilotage des procedes par lots (SP88) et l'integration systeme executif / entreprise (SP95). Le comite ISA SP88 Le comite SP88 est forme d'un large groupe d'experts du monde entier, collaborant de facon interactive a travers Internet. Il se reunit tous les 2 mois pour traiter les commentaires adresses par les membres et mettre a jour les documents de travail. Dirige par Lynn CRAIG (Consultant delegue par ROHM & HAAS, directeur de Manufacturing Automation Associates, HYPERLINK mailto:lcraig@bellatlantic.net lcraig@bellatlantic.net ), le comite travaille egalement avec d'autres groupes, notamment : Le comite ISA SP95 qui doit produire un standard pour la communication entre les systemes de planification et de controle de la fabrication. D'une portee beaucoup plus large que SP88 (tous les types de procedes sont vises), les 2 standards devraient se rejoindre sur plusieurs points. le groupe IEC SC65A/WG11 qui collabore a la construction du standard au sein de l'IEC et controle sa conformite aux regles organisationnelles et semantiques de la norme L'OPC qui s'appuie sur le standard pour definir un sous-ensemble d'OPC, " OLE for Batch Control ". On doit egalement citer le WBF (World Batch Forum), l'EBF (European Batch Forum) et le JBF (Japan Batch Forum) dont les membres sont largement representes et qui ont forme des groupes de travail sur le sujet. Le NAMUR a egalement contribue au developpement du standard. Le groupe compose a partir de personnalites issues de corporations souvent concurrentes a reussi a trouver un equilibre remarquable. L'ouverture d'esprit et la franchise sont de regle, et l'assiduite benevole trouve sa motivation dans une ambiance constructive et decontractee. Objectifs Le comite SP88 avait pour objectif de definir le controle de procedes par lots de facon a offrir la flexibilite necessaire pour adapter et optimiser l'outil de production sans programmation. Le but, au-dela de son aspect " evangeliste ", est de permettre aux utilisateurs de mieux definir leurs besoins, et aux editeurs de produire des solutions adaptees et compatibles entre elles. On distingue generalement 3 types de procedes, dont les definitions sont generalement propres a chaque auteur : Les procedes de type Continu qui ont une phase principale de production relativement longue par rapport aux autres (demarrage, arret). Le volume de la production est relativement proportionnel a la duree de cette phase et ne depend qu'indirectement de la taille des equipements. La matiere premiere " entre " dans l'unite, le produit fini en ressort sans discontinuite. Les matieres susceptibles d'etre produite par une unite de ce type ont des caracteristiques voisines. La production d'energie, la plupart des procedes mis en ?uvre dans le raffinage et la chimie de base sont de ce type. Les procedes de type Discontinu ou Batch qui opere selon un cycle au cours duquel des quantites determinees de matiere sont transformees en produit fini. La taille des equipements determine directement la production du cycle, et le produit fabrique depend autant de la procedure executee par le cycle que des fonctions elementaires de chaque equipement. Il s'agit souvent d'ateliers " flexibles ". La chimie des specialites, l'agroalimentaire et la pharmacie representent l'essentiel de ces procedes. Les procedes de type Discret qui utilisent et elaborent des elements de matiere. Il s'agit en fait de l'application des concepts precedents applicables aux industries de " process " au domaine manufacturier. Il n'est pas facile d'en donner une definition precise, car on y regroupe des domaines aussi varies que la fabrication mecanique par assemblage ou transformations successives, la construction (automobile, aeronautique, immobiliere...) On les distingue pourtant nettement en raison de la rupture tres nette des communautes culturelles respectives du Process et du Manufacturier. On retrouve cette rupture au niveau des ERPs qui pour la plupart sont concus de facon preferentielle pour certains types de production comme au niveau des systemes de controle qui s'appellent plutot SNCC dans un cas, automates programmables dans l'autre. A l'origine, le groupe SP88 s'est focalise sur les procedes discontinus, et le titre meme de la norme s'y refere. Il est toutefois apparu tres nettement au cours des discussions que la restriction de l'etude au domaine specifique du " Batch " ne faisait qu'enteriner l'isolement des differentes communautes du monde de la production. On s'est rapidement apercu que la classification des procedes peut etre envisagee de maniere beaucoup plus detaillee... ou au contraire oubliee lorsque l'on s'attache a identifier objectivement les problemes poses par chacun d'eux. Le systeme de production fait partie d'un systeme principal qui est l'entreprise. Il serait evidemment plus simple et efficace de le considerer d'une maniere standardisee. Le pas a ete franchi par la technologie des systemes de controle : s'il est encore rare de trouver des SNCC dans le manufacturier, les automates abondent dans le process... Et les specificites techniques fondamentales de ces systemes tendent a s'estomper. Ceci est beaucoup moins vrai pour l'aspect humain, qui presentent un haut niveau de segregation lie au " metier ". Le groupe SP88 reste actuellement compose principalement de specialistes du procede Batch, mais les travaux du groupe SP95 ont largement ouvert les domaines d'action de l'ISA qui doit a present tenir compte de cette nouvelle approche. Ainsi, l'EBF (European Batch Forum) a lance un groupe de travail " WG-3 - Extensions to S88 Part 1 " pour la generalisation de l'approche S88 a tous les types de procedes. ANSI/ISA S88.01 : Models and Terminology - Rappel des principes de base Ce standard ANSI/ISA a ete publie en 1995. Approuve par l'IEC, il a ete edite en tant que norme ISO 61512-01 en 1997 accompagne d'une traduction francaise. Cette premiere partie avait pour objectif la definition des termes utilises et l'enonce des principes du controle des procedes batch au travers de modeles de base (Procedural, Physique et Procede). Il ne s'agissait pas de produire une norme d'implementation et d'interoperabilite, mais plutot d'etablir les fondements necessaires pour un programme plus ambitieux de standardisation des fonctions offertes par les systemes. Pas de grandes revelations, mais une " mise a plat " des principes du controle des procedes de fabrication par lots a partir de la mise en commun du savoir-faire des specialistes. La participation active de la communaute des " utilisateurs " etait evidemment un gage de reussite. Cette norme fait donc naturellement l'objet d'un large consensus, meme si un certain nombre d'aspects n'a pas ete traite en detail, et si sa lecture peut paraitre difficile. Avant meme sa publication officielle, la sensibilisation du marche et la percee des PC et de Windows NT a cote des systemes traditionnels a permis l'emergence de nouveaux acteurs (GSE, SEQUENCIA par exemple). Tous se sont inspires de la nouvelle norme. Par sa nature, le standard SP88.01 permet des interpretations tres libres. Il se prete difficilement a une evaluation de la conformite des applications et des systemes, et n'assure donc pas leur interoperabilite. Il est assez paradoxal de constater que la seule traduction de la norme IEC 61512-01 est en langue francaise alors que nous ne sommes que tres peu engages dans le standard S88. Meme les pays non anglophones impliques activement (Allemagne, Danemark, Japon...) n'ont pas publie de traduction. Agee de 5 ans, la norme pourrait evoluer. L'European Batch Forum a cree un groupe de travail pour la generalisation du modele SP88 au pilotage des autres types de procede (continus et discrets). Nous presentons ici un bref rappel des elements de base de la norme. Modele physique Hierarchie operationnelle des recettes Hierarchie procedurale de la recette Modele general SP88 Procedure (s) Combine avec Process Cell (s) Genere une fonctionnalite procede pour supporter Process Unit Procedure (s) Unit (s) Process Stage Operation (s) Unit (s) Process Operation Phase (s) Unit (s) Process Action Phase (s) Equipment Module (s) Process Action Le modele du procede comporte 4 types de fonctionnalites. C'est la vision generale de la recette telle qu'elle est definie par les services de developpement (Recette Generale et Site). Le controle procedural defini dans la recette maitre et execute par la recette de controle met en ?uvre des entites executables correspondantes. Elles peuvent etre appliquees a tous les niveaux pour produire les fonctions recherchees. SP88.02 : Data Structures and Guidelines for Languages Loin de cesser apres la publication du standard S88.01, l'activite du groupe SP88 se poursuit depuis fevrier 1995 avec la seconde partie du standard. Soumise a l'approbation de l'IEC en mars pour une revue publique de 3 mois, elle devrait etre publiee au cours de l'annee. Les objectifs sont a present beaucoup plus concrets. Il s'agit de definir : Un modele de donnees qui doit servir de base pour la realisation d'interfaces entre les sous systemes concernes par la creation et l'execution des recettes (mais pas entre les entites procedurales de la recette et des equipements) Une specification d'interface basee sur ce modele et utilisant des tables relationnelles Un langage de description graphique des recettes. Si la premiere partie du standard expose des principes academiques, la seconde partie est resolument pragmatique. Elle permettra de juger objectivement de la conformite des applications, tout au moins dans les domaines concernes. La presentation ci-dessous propose une interpretation francaise libre en lieu et place de la terminologie anglaise de la norme Modele de donnees La premiere section de la norme expose un modele de donnees qui complete les principes enonces dans la S88-01. Ce modele est decrit selon la notation UML. Grace a cette approche orientee objet, le modele est a la fois simple, compact, coherent et generalement recursif. Les elements de la recette (procedure, equipements, parametres) sont definis selon un modele qui repond aux prescriptions SP88.01 sans s'y limiter (par exemple, les phases, operations, procedures unitaires et recette maitre sont decrit au moyen du meme element sans limitation de profondeur de leur imbrication). Il definit les objets de base suivants : L'entite " Recette " qui se decompose 2 series de subtypes : La categorie d'entite qui peut etre la recette elle-meme, un composant de la recette, un " bloc de construction " utilisable pour creer les composants de la recette Le type de recette qui peut etre General, Site, Maitre ou Controle Cette entite est composee d'entites de second ordre : Les Requisitions d'equipement definissent les besoins en equipements pour l'entite recette consideree Les Parametres supportent les elements de la formule (Parametres d'entree, de sortie, Procede). Ils peuvent etre structures. Les Elements de structure procedurale decrivent les etapes, liens et transitions utilises pour decrire l'aspect procedural de la recette Les Autres informations permettent a l'utilisateur de completer la recette par des elements documentaires specifiques (prescriptions legales, directives de securite relatives aux materiaux ou aux procedes, prescriptions d'emballage, schemas...) L'entite Equipement composee d'entites de second ordre : Les Proprietes d'equipement permettent de choisir ou de verifier les capacites de l'equipement en regard des requisitions d'equipement de l'entite de recette. Les Elements proceduraux d'equipement assurent la liaison entre l'element de procedure de la recette et l'element de procedure execute par l'equipement Les Relations entre equipements definissent les contraintes physiques relatives des equipements : Connexion temporaire ou permanente, precedence de ressource, contraintes d'enchainement vis-a-vis des matieres... L'entite Entree programmee de Batch et ses elements complementaires definit le programme de fabrication. Les informations liees a cette entite vont permettre de creer ou d'affecter la recette de Controle en vue ou au cours de son execution. L'entite Entree d'information de production et ses elements complementaires collecte les donnees issues de l'execution de la recette ou communes a plusieurs fabrication. L'entite Rapport de Batch et ses elements complementaires definit et genere les editions de documents relatifs a l'execution de la fabrication Ce modele est normatif. Les interfaces conformes a la norme devront utiliser les noms d'objet et d'attributs ainsi que les relations proposees. Structures de donnees La seconde section de la norme traite de l'echange d'information entre systemes. C'est une specification d'interface relativement exhaustive basee sur le modele de donnees de la section precedente. Cette interface doit permettre en particulier : l'echange de la " Master recipe " et des equipements, Le declenchement de la creation de la " Control recipe " L'alteration de la " Control recipe " en cours d'execution, L'acces a l'information dynamique de la recette en cours d'execution, La production d'un historique standardise Elle propose une methode d'implementation basee sur des tables relationnelles SQL. La methode est classique : elle repose sur la responsabilite mutuelle des applications pour l'alimentation des tables et l'utilisation des donnees. Les protocoles d'echange et de maintenance des tables ne sont pas specifies. Toutes les tables sont decrites et fournies avec les scripts de creation SQL. On dispose donc d'une base tres complete et pratiquement prete a l'emploi pour assurer le dialogue entre les applications. Toutefois, le contenu de certains champs n'a pas ete normalise (formules de calcul des parametres, equations des conditions de transitions...). La categorie " Autres Informations " et les extensions hors norme necessitent bien entendu un agrement particulier entre les applications. Informations communes : Base d'echange et listes d'enumeration Les donnees globales relatives a la base d'echange informent les applications sur son origine et les references de sa structure (Schema de base fourni par la norme et extensions specifiques). La norme definit toutes les chaines de caracteres standards utilisees sous la forme de listes d'enumeration numeriques qui faciliteront l'interpretation des valeurs independamment des termes ou la langue utilises. Par exemple, le niveau des equipements est defini par une liste d'enumeration de 7 valeurs (1= Entreprise, 2=Site, ... 7=Module de controle) Une trentaine de listes definissent environ 160 chaines de caracteres. Echange d'informations de la recette maitre Cette structure assure l'echange de la recette maitre. On pourra donc creer la recette au moyen d'un outil totalement independant de l'application d'execution de la recette. Le modele objet recursif est totalement implemente dans la norme. Echange d'informations des equipements Cette structure supporte l'information utile pour decrire non seulement les capacites, caracteristiques et relations de l'equipement, mais egalement l'interface avec l'element de procedure d'equipement qui lui est associe. Grace a ce type d'echange, il est par exemple possible : de disposer de la definition de tous les elements de procedure definis le systeme de controle, de permettre a une application de planification avancee de selectionner celui qui repond aux criteres de capacite et d'optimisation, de connecter les elements proceduraux de la recette aux elements proceduraux de l'equipement lors de la creation de la recette de controle. Echange d'informations du programme de fabrication Cette structure permet d'alimenter le systeme d'execution des recettes. Les donnees transmises comprennent toute l'information necessaire pour creer la recette de controle executable a partir de la recette maitre : Identification de la recette, de l'ordre de fabrication, du lot... Information d'execution telles que les horodates de debut et fin, priorites, precedences, mode initial, taille du batch Les donnees du programme de fabrication s'appliquent a tout element de la recette, aussi bien a la recette elle-meme qu'a chacun de ses elements de procedure. Elles comprennent donc egalement les requisitions d'equipements et les parametres particuliers applicables pour l'execution du batch. Ce type d'echange permet aux autres applications de piloter l'execution de la fabrication. Echange d'informations de production Cette structure enregistre l'information de production en relation avec l'execution des elements proceduraux et les equipements. Les executions multiples et les decalages horaires sont pris en compte. Ces donnees pourront trouver leur place dans une base d'information de procede. Directives du langage. Cette section propose de definit un langage de description graphique des recettes. Le Procedural Function Chart ou PFC est derive du SFC des normes IEC 60848 et 1131-3. Symboles Les symboles proposes sont les suivants : Elements de la procedure, similaires aux etapes d'un SFC. Ils informent egalement sur le niveau de l'element (Procedure, Procedure unitaire, Operation, Phase) et l'encapsulation eventuel d'un sous-niveau. Debut et Fin de la procedure. Ces elements n'existent pas dans les SFC. Allocation des ressources. Ce symbole represente les ressources necessaires (Equipements, personnel, matieres) ou les criteres de selection pour permettre l'execution des elements de procedure successifs. Synchronisation des elements de procedure Transitions entre elements de procedures. Elles peuvent etre implicites : l'element suivant est active par la fin de l'execution de l'element precedent. Aucun symbole ne represente ce type de transition (lien direct). Les transitions explicites definissent les conditions de fin d'execution de l'element precedent et autorisent l'activation de l'element suivant. Structures de base de la procedure Les regles proposees autorisent les routages suivants : Debut et Fin de selection de sequences (Divergence en convergence en OU) Debut et Fin de sequences simultanees (Divergence en convergence en ET) En conclusion Le modele de donnees, issu d'une longue maturation, illustre bien la premiere partie de la norme en materialisant les concepts litteraires. Concernant l'aspect Interfacage de la norme, on pourrait regretter que seule l'interface SQL ait ete developpee. Il n'est toutefois pas du ressort des organismes normatifs tels que l'ISA ou l'IEC de " defricher " les technologies, et le choix SQL est parfaitement justifie. La technologie des SGBDR peut etre implementee dans toutes les circonstances et n'est pas (encore) totalement obsolete dans ce domaine. Le groupe SP88, en developpant cette interface, a voulu consolider la coherence du modele de donnees et presenter un exemple pour le developpement d'autres interfaces basees sur des technologies plus recentes. Dans la foulee de cette initiative, le groupe OPC for Batch Control pourrait produire une version COM/DCOM de cette interface. L'OMG pourrait egalement s'y interesser en developpant une version CORBA. Il est dommage que l'on n'ait pu parvenir a un accord pour developper ou imposer un langage de description des formules mathematiques et equations booleennes (par exemple la norme IEC 1131-3). Concernant l'aspect Langage de la norme, le Langage PFC permet de specifier les recettes les plus complexes. Il peut apparaitre inutilement sophistique pour les cas les plus simples, mais il appartiendra aux editeurs de le rendre utilisable dans toutes les circonstances. La norme ne s'interesse pas a la conception meme des applications, mais exclusivement aux interfaces. On ne trouvera pas donc pas de regles pour le traitement des actions associees aux etapes. Le langage n'est pas le vecteur des echanges d'information, traites par la seconde partie, et n'a donc pas a traiter de tels details. Sa definition vise donc essentiellement a faciliter la communication entre les hommes et le systeme d'information a l'aide de symboles et de regles. Un utilisateur pourra decrire ou executer la recette a l'aide d'outils produits par des editeurs differents : l'adoption du langage normalise par ces editeurs permettra de presenter de facon similaire la recette dans tous les cas. En conclusion : Les utilisateurs beneficieront d'une integration plus simple, d'un outil d'etalonnage precis de la couverture fonctionnelle des solutions. Les vendeurs trouveront une specification tres complete pour la realisation d'applications de gestion des recettes maitres, d'automates d'execution de ces recettes, de reporting. Il est probable que sa publication va favoriser l'emergence de solutions nouvelles compatibles entre elles. Souhaitons un accueil favorable et constructif a cette seconde partie du standard SP88, issue d'un large consensus et fruit d'un travail benevole considerable. ASTRID et S88 La methode ASTRID a ete presentee recemment dans MESURE (janvier 1999). On peut rappeler quelques points pour eclaircir ce que sont S88 et ASTRID l'un vis-a-vis de l'autre : La terminologie n'est pas comparable. C'est dommage, car l'adoption d'un langage commun est indispensable pour assurer la comprehension mutuelle des interlocuteurs. La conformite d'ASTRID a ce niveau pourrait facilement etre obtenue. La norme S88.01 est beaucoup moins precise dans son implementation : Sans la seconde partie, il est difficile d'affirmer qu'un systeme est ou n'est pas conforme. L'existence des outils de developpement de Jean-Michel RAYON et la diffusion totalement controlee de la methode ont largement contribue a faire d'ASTRID un " standard de facto " relativement abouti dans la communaute de ses utilisateurs. La structure generale hierarchique ASTRID ne decrit qu'un seul niveau procedural, la Fonction. La methode ne definit rien pour l'objet fonctionnel " Recette " charge d'animer les fonctions. Le modele S88 est tres elabore. Il definit les objets proceduraux sur 3 niveaux. Ces objets sont repartis librement dans la " recette " (manipules par l'ingenieur procede) ou dans l' " equipement " (manipules par l'automaticien). Les differents niveaux peuvent etre " contractes " ou " etendus " pour offrir la structure exactement necessaire. La norme S88 definit plusieurs niveaux de recette, depuis la recette generale issue du laboratoire jusqu'a la recette executable valable pour l'atelier. Toutefois, meme la seconde partie de la norme n'aborde pas la facon de gerer la coherence de ces recettes. S'attachant au seul processus de conception du produit, elle ignore d'ailleurs les autres processus executifs (modelisation pour la planification MRP ou l'ordonnancement par exemple) ASTRID presente quelques caracteristiques particulieres qui posent probleme lors des tentatives d'integration de la methode : decouplage du comportement et de l'interface de la fonction, regles ergonomiques du systeme de supervision.. Au chapitre des similitudes, on notera : La " Fonction ", element procedural superieur d'ASTRID, peut etre assimilee a la " Phase ", ultime element du modele procedural S88. La " Ressource " et l' " Organe " ASTRID sont similaires aux " Control Module " S88. ASTRID definit ainsi une implementation possible du controle des equipements alors que la norme S88 ne fait qu'enoncer des principes. Meme la seconde partie ne donne aucune directive, considerant que ce domaine est du ressort de l'implementation. Enfin, la methode ASTRID, qui definit un canevas d'etude de ses objets fonctionnels, ne propose pas de langage de description des procedures, alors que la norme S88.02 propose un langage graphique. En conclusion, ASTRID pourrait s'integrer totalement dans un systeme conforme a la norme S88, et cette derniere ne contredit jamais les concepts d'ASTRID. ASTRID ne s'attaque pas aux memes problemes que la norme en s'attachant a la definition d'un controle robuste des equipements, alors que la norme ne se preoccupe que des modeles physique, procede et procedural du controle batch. Il est rassurant de constater la clairvoyance des concepteurs de la norme et le pragmatisme des promoteurs ASTRID qui se rejoignent sur la meme frontiere. Bien que hautement souhaitable, il est peu probable que le controle des equipements fasse un jour l'objet d'une norme : de nombreuses solutions comparables a ASTRID, proposees par les vendeurs ou developpees par les utilisateurs existent depuis longtemps, et l'on n'a jamais cherche a normaliser la facon de programmer un automate ou un SNCC... Noter : passage corrige le 15 mars 2004 Noter : passage corrige le 15 mars 2004 Le modele physique est une decomposition hierarchique des elements du procede. La norme definit 7 niveaux dont seul les 4 derniers concernent la recette " executable " Le " Process Cell " correspond a l' " atelier " pour lequel la recette est definie. Les elements " Unit " et " Module Equipement " representent les ressources qui pourront etre mobilisee lors de l'execution de la recette. Les systemes de planification avancee pourront affecter ces ressources selon les criteres d'optimisation et les contraintes subies. Les modules de Controle ne sont pas concernes par le controle procedural. Le modele physique represente l' " ossature " sur laquelle s'appuie le systeme de controle. La remise en cause de ce modele correspond a une phase d'ingenierie des installations, et non a une phase operationnelle. Il doit donc etre elabore avec soin, car il conditionne la flexibilite du procede pour la mise en ?uvre de produits differents. General Recipe Modele Physique (Origine : ISA-S88.01-1995) Au-dela de la decomposition classique des elements de procedure, le point le plus original de la norme est leur repartition entre Recette et Equipement. Seuls les elements de la recette peuvent etre construits et manipules pour definir une nouvelle strategie de fabrication. Ils " appartiennent " au fabricant. Les elements appartenant a l'equipement appartiennent a l'automaticien. Leur repartition est donc definie en fonction du degre de flexibilite recherche. Tous les niveaux de cette hierarchie ne sont pas obligatoirement definis. Le cas limite correspond a une recette qui effectue un simple chargement initial de parametres. Differents niveaux de la recette ont ete definis. Cette hierarchie correspond a une " Vision Ingenierie " qui traduit la genericite attendue dans les processus de creation des recettes. La synchronisation des 3 niveaux superieurs est un probleme complexe qui n'a pas encore ete aborde : jusqu'ici, seules les Master et Control Recipes sont developpees dans la norme. Cette vision est sans rapport avec les differents domaines d'utilisation des recettes en exploitation. La synchronisation de la recette executable par le systeme de controle avec la definition des procedes du systeme de planification ou le modele d'utilisation des ressources de l'outil d'ordonnancement ne sont pas abordes par la norme. PHASE Entete Formule Besoins Equipements Autres informations Logique de la procedure PHASE Entete Formule Besoins Equipements Autres informations Logique de la procedure OPERATION Entete Formule Besoins Equipements Autres informations Logique de la procedure OPERATION Entete Formule Besoins Equipements Autres informations Logique de la procedure PROCEDURE D'UNITE Entete Formule Besoins Equipements Autres informations Logique de la procedure PROCEDURE D'UNITE Entete Formule Besoins Equipements Autres informations Logique de la procedure RECETTE MAITRE Entete Formule Besoins Equipements Autres informations Logique de la procedure Types de recettes (Origine : ISA-S88.01-1995) Separation Procedure Recette de Controle / Controle de l'Equipement (Origine : ISA-S88.01-1995) Vue d'ensemble du modele (Origine : Batch Control Part 2 : Data Structures and Guidelines for Langages - Draft 13 February 1999) Imbrication des elements de construction de la recette (Origine : Batch Control Part 2 : Data Structures and Guidelines for Langages - Draft 13 February 1999) Exemple de procedure avec allocations initiales (Origine : Batch Control Part 2 : Data Structures and Guidelines for Langages - Draft 13 February 1999) Enterprise Site Area Process Cell Unit Equipment Module Control Module May contain May contain May contain May contain May contain May contain May contain May contain Site Recipe Maser Recipe Control Recipe Product-specific processing information Site-specific information Process Cell-specific information Batch ID, batch size, in-process, operator and/or system-generated information includes May be transformed into May be transformed into Is the basis for includes includes includes