• Aucun résultat trouvé

4.6 Validation de ce meta-modele

5.1.2 Presentation detaillee

Relations entre les trois parties

L'entree du superviseur est un plan de fabrication L, c'est-a-dire une suite d'ordres de lancement l 2 L de lots avec leurs dates et les equipements requis. Les recettes de contr^ole sont traduites sous la forme de deux types de messages, Uc,Ud 2U, qui repre-sentent l'ensemble des requ^etes envoyees par le superviseur aux organes de commande.Les messagesUc sont des consignes envoyees aux regulateurs continus, et les messagesUd sont des evenements qui provoquent des changements d'etats des automates programmables in-dustriels. Ces automates, connectes au procede, recon gurent physiquement l'installation

5.1. PR 

ESENTATION DES TRAVAUX 123

Procédé Uc = Gcq(Xc,Uc) Σp Σe Σu p Λ Modèle de référence cn cn-1 X = F (X , P)S Uc Ud Uc U d Controleurs locaux Générateur d’événements Xdm, Xcm Xcm Xcm Superviseur Controle

Fig. 5.1: Supervision basee sur un modele hybride [Andreu96]

lors du changement de con guration par des ouvertures et des fermetures de vannes. Les regulateurs continus et les automates programmables industriels fonctionnent en boucle fermee.

Les regulateurs continus ont acces aux variables d'etat continuesxcm mesurees par des capteurs. Ils reconstituent l'etat continu, xc = Fc(xcm), et generent periodiquement les commandes continues: uc =Gcq(xc;Uc).

Les automates programmables industriels detectent les variations de variables d'etat discretes mesurees xdm et les franchissements de seuils par les variables d'etat continues

xcm. Par un ensemblede fonctions logiques combinatoires (B), ils determinentl'occurrence d'evenementse =B(xdn;1

;xdm;xcm),xdn;1 etant l'etat discret precedent. A partir des eve-nements, l'etat discret suivant est obtenu, xdn =Fd(xdn;1

;e), et les commandes discretes sont deduites et appliquees au cycle suivant: ud = Gd(xdn). Une requ^ete du superviseur (message Ud) peut ainsi donner lieu a l'application de plusieurs commandes discretes: la requ^ete est anee.

La supervision n'a pas les m^emes contraintes temps reel strict que la commande locale. Elle n'accede donc pas directement aux variables d'etat continues du procede. La fonction

generateur d'evenements est chargee de detecter les evenements d'etat provoquant un changement de phase ou de con guration tels que les franchissements de seuil. A chaque changement de con guration (c'est-a-dire a chaque changement d'etat discret Xd pour le modele utilise par la supervision), le generateur d'evenements doit ^etre reprogramme. En se basant sur le reseau de Petri decrivant la recette, cette reprogrammation est systema-tique. En e et, a partir de l'etat discret courant Xd, c'est-a-dire du marquage du reseau de Petri qui indique la con guration active, nous pouvons deduire l'ensemble des evene-ments e a observer par le generateur d'evenements (P). e correspond a l'ensemble des evenements a observer, et p a pour signi cation l'ensemble des evenements detectes.

La partie supervision

La supervision doit assurer le bon fonctionnement du procede, en le surveillant. La surveillance repose sur la detection des deviations par comparaison entre le comportement attendu et le comportement e ectif. Cette comparaison repose donc sur la confrontation des observations issues du generateur d'evenements, avec les resultats de la simulation. La simulation est fondee sur le(( modele de reference )) qui, a son image, est hybride. La resolution des equations est supposee ne pas poser de probleme.

Pour chaque transition de seuil sensibiliseepar l'etat discret courant, le systemed'equa-tion algebro-di erentielle est utilise pour evaluer la date au plus t^ot (d1) et la date au plus tard (d2) de franchissement de seuil. Chaque fois qu'un evenementd'etat est detecte par le generateur d'evenements,il est transmis a la supervision qui veri e si sa date d'occurrence est compatible avec la fen^etre temporelle [d1;d2]. Si c'est le cas, l'etat discret suivant est calcule, Xdn = Fd(Xdn;1

;P), le nouveau systeme d'equations algebro-di erentielles est genere par l'evolution du marquage, et le generateur d'evenements est reprogramme. Si l'occurrence de l'evenement se produit en dehors de la fen^etre temporelle, la transition correspondante n'est pas franchissable, et l'etat discret suivant ne peut pas ^etre atteint.

Les reseaux de Petri utilises

La classe de reseau de Petri utilisee dans chaque partie depend des besoins de mo-delisation: prise en compte explicite de l'aspect temporel, manipulation de structures de donnees, etc. Ainsi les reseaux de Petri utilises pour modeliser les recettes sont les re-seaux de Petri temporels a objets. La structure du reseau correspond a la procedure de la recette et les objets manipules sont d'une part les objets (( lot )), et d'autre part les objets ((ressource )). Les reseaux de Petri temporels a objets sont egalement utilises pour la description des fonctions. Au plus bas niveau, la classe de reseaux de Petri utilisee est le reseau de Petri interprete de commande ou le grafcet.

5.1. PR 

ESENTATION DES TRAVAUX 125

franchissable ? Autre transition Recherche transition Vérification condition Tir de la transition Vérification franchissable Etat stable (attente évén. ext.) non Anomalie non oui oui non oui Cycle interne

Fig. 5.2: Principe du joueur de reseau de Petri [Andreu96]

Le joueur de reseau de Petri utilise est decrit par la gure 5.2. L'etat stable d'un reseau est un marquage pour lequel seules des transitions associees a des evenements externes sont franchissables. Le joueur se place donc en attente de l'occurrence d'un evenement externe. Quand un evenement externe se produit, le joueur cherche la transition a laquelle il est associe, et teste si elle est franchissable. Si la transition est franchissable, il la franchit, ainsi que toutes celles rendues franchissables par le nouveau marquage, jusqu'a atteindre un etat stable. Par contre, si la transition ne peut pas ^etre tiree, le joueur detecte une anomalie et reste dans l'etat stable.