Rémi Pannequin et André Thomas CRAN – CNRS UMR 7039

Présentation au sujet: "Rémi Pannequin et André Thomas CRAN – CNRS UMR 7039"— Transcription de la présentation:

1 Proposition d’une plateforme d’expérimentation sur le contrôle par le produit
Rémi Pannequin et André Thomas CRAN – CNRS UMR 7039 Equipe « Systèmes Contrôlés par le Produit » Bonjour Présentation travaux de thèse de Rémi … Titre présentation Labo/équipe

2 Plan de la présentation
Contexte et problématique État de l’art Fonctions de la plateforme Spécification de la plateforme Application à un cas industriel Conclusion et perspectives

3 Champ de recherche Synchronisation (Plossl 97) Flux de produits
Flux d’informations Flux d’informations Synchronisation Flux de matière Depuis 50 ans… GI : synchro… C’est flux d’info/decision qui pilote flx physique

4 Champ de recherche Synchronisation (Plossl 97)
Flux de produits Flux d’informations Identification Automatique Auto-ID (McFarlane et al. 03) Points de synchronisation Synchronisation par RFID La synchro est automatique avec cette technologie …mais on gère de la même manière… Synchro a des nbrs déterminés de points (lecture) conduit à « matérialiser » le concept holonique : clic Produit Porteur d’un Tag

5 Acteur du contrôle de la production
Champ de recherche Synchronisation (Plossl 97) Flux de produits Flux d’informations Identification Automatique RFID (McFarlane et al. 03) Points de synchronisation Contrôle Holonique Holon = produit + information Flux d’holons Produit capable d’informer Par contre si on implémente le concept holonique ;;; Le produit est intégré ds le SI ET INTERAGIR avec lui… donc il contrôle sa propre production C’est un nouveau concept de gestion … et si de nouveaux concepts de gestion sont en train émerger …il sera donc nécessaire de valider les modèles de prise de décision.. Acteur du contrôle de la production

6 Objectif scientifiques :
Problématique Besoin: Évaluer une architecture de contrôle par le produit avec réalisme (taille) en tenant compte de différentes situations Etude analytique Difficile… Étude expérimentale Objectif scientifiques : Méthodologie pour la création de modèles d'ateliers virtuels réalistes Spécifier une architecture modulaire Réalisme … malgré la taille… malgré la diversité des situations d’application de cette architecture de contrôle sur la démarche analytique : Préciser pourquoi elle ne convient pas * peu d’outils mathématiques pour représenter et étudier symboliquement les systèmes distribués (ref Wegner 97) * pas de résolution possible pour des systèmes d’échelle réaliste Introduction sur émulation : pour des prbl de cts on ne dispose pas des usines (!!) pour expérimenter : donc ateliers virtuels… mais comment les créer??? Pour pouvoir étudier le contrôle de ces flux, Garder la séparation entre ceux-ci… Et donc pouvoir modéliser et « activer virtuellement » d’une part le flux physique sans intelligence et d’autre part les flux info et décision Réalisme des modèle (facteur d’échelle)

7 Émulation et simulation
But de la simulation Observer l’évolution du système face à un scénario prédéfini Boucle ouverte Le système de décision est inclus dans le modèle Modélisation délicate Souvent simplifiées Système réel Modélisation … c’est la différence même entre émulation et simulation … Simulation = boucle ouverte : pas tt à fait vrai mais l’idée est on donne des paramètres , on lance , on regarde décisions off line Emulation = activation ss contrôle permanent décisions on line Simulation Scénario prédéfini performances

8 Émulation et simulation
But de l’émulation Reproduire l’interaction avec l’environnement Boucle fermée Seul le système opérant est modélisé Modélisation facilitée Modularité Utilisation du système de contrôle réel Interaction permanente Le syst de contrôle « croit » qu’il commande le vrai système physique Et si on change de regle … on change pas tout .. Donc intérêt de la modularité Emulation Scénario prédéfini performances

9 Caractérisation de la problématique
Expérimentation sur un modèle du réel Tout n’est pas représenté L’expérience est elle valable ? Quels aspects modéliser ? Conserver les aspects de la réalité qui posent des problèmes de pilotage, et que l’on étudie Problèmes censés être résolus par le contrôle par le produit Conduit à une description fonctionnelle de l’émulateur

10 État de l’art (1/2) Émulation de parties opératives
Machines CN, robots,… Comparaison sur un cas d’école Brenan 2000, Cavalieri 2000 Cas industriel simple IMS-NoE SIG4 (Cavalieri, 2003) Service de benchmarking Base globale (sur Internet) de cas industriels MAST (Marik & Vrba, 2005) Intégration d’autonomie et de communication aux équipements simulés (simulation par agents) Évolution des notions sur l’émulation Étape 1 : émulation de parties opérative (travaux du cran en particulier… [Corbier 1989] et autres, outil Spex) On émule la dynamique (d’une machine outils, d’un processus, d’un robot) pour valider un système de contrôle. Étape 2: émulation spécifique de lignes de productions : découplage modèle d’émulation et système de contrôle (transparence au réseau). Pas de modularité émulation/contrôle : un cas de test (cas académique), comparaison sur ce cas de plusieurs systèmes de contrôle (généralement deux) [Brenan 2000] [Cavalieri 2000] Étape 3 : création d’un service de benchmarking global (Internet) : les industriels y déposent des cas de tests, les chercheurs appliquent leurs architectures de contrôle. Bibliothèque mondiale de cas industriels… IMS NoE Spécial Interest Group 4 Cavalieri 2003 … leur obj est très ambitieux, au moment du début de nos travaux : pas fonctionnel Étape 3bis : création d’un outils de simulation multi-agent : MAST(Multi-Agent Simulation Tools). Les composants physiques qui sont simulés comprennent intrinsèquement leurs capacités de contrôle et de communication (puisque se sont des agents…). [Marik, et Vrba 2005] : développement conjoint d’un machine holonique (contrôle et process dans une même entité) Développé par Rockwell automation : simulateur qui embarque des objets mul agents … mais décision et pysique sont ds le mê modèle…

11 État de l’art (2/2) : notre position…
Maintenir la séparation entre Émulation du système opérant Système de contrôle Constitution d’une base de modèles Capitaliser les travaux d’une équipe / d’un labo Modularité émulation/contrôle basée sur des composants d’émulation génériques Interface universelle pour accéder aux modèles Limites et critiques qui ont conduit à nos choix… sur MAST… on cherche à maintenir la séparation entre flux info et physique et donc on sépare les modèles On cherche à mettre en œuvre la notion de service de benchmark, mais à l’échelle d’une équipe (ou d’un labo), et pas globalement (sig4 = bibliotheque mondiale!). La modularité modèle d’émulation du process et système de contrôle se fait grâce à une modélisation du process physique basée sur des composants abstraits, et donc génériques. Donc idem IMS cavalieri … mais à l’échelle du labo.

12 Fonctionnalités du dispositif expérimental
Séparer des flux de natures différentes Matière, information, décision Le produit synchronise les flux Représenter tous les routages possibles Choix autonome par le produit de sa route Émuler les événements du cycle de vie du produit Naissance, …, mort Assemblage, désassemblage

13 Architecture du dispositif expérimental
Émulation du système opérant Est constituée d’un ensemble de primitives de modélisation basées sur une décomposition systémique S’appuie sur une structure de modèles d’émulation générique Système de contrôle Supporte le système de décision et les flux d’information Mis en oeuvre par un système multi-agents Interface Assure la modularité entre émulation et contrôle Repose sur la définition de la structure des messages Systémique : temps espace forme La structure des messages constitue un standard … qui assure la modularité

14 Primitives d’émulation
Modélisation basée sur une analyse systémique Temps, espace et forme (Le Moigne,1977) Plus générique que les modèles des équipements Temps Espace Forme Non contrôlé Contrôlée Fixée => Espace-Temps Routage, manipulation, … => Forme-Temps Usinage, peinture, … => Temps Stockage, attente, … « blocs » de base du modèle basés sur … Tradi ..; on modélise des équipmts … possible si cet équipmt est partie prenante ds le contrôle Mais si on veut séparer les deux syst ..; il être modulaire … mettre en place des « objets purement logistique »

15 Structure des modèles d’émulation
Le modèle d’émulation est constitué de transformations et est traversé par des produits Informent sur changements d’état Reçoivent des ordres de pilotage : régler, opérer Les produits génèrent des événements Paramètres de contrôle : Espace source, espace destination Paramètres de contrôle: Programme de fabrication

16 Structure des messages
Modèle d'émulation Manufacturing Control <<Agent>> Événement <<Message XML>> Cible +Nom 1 Nature Paramètres +Valeur Horodatage +Unité * TypeNature <<Enumération>> Report Request type TypeCible Produit Forme Espace Horodatage du message Cible : ressource ou produit qui émet/reçoit le message <Event> <Target type="shapeTransform">CU23</Target> <Nature type="request">setup</Nature> <Parameters> <Parameter name="ProgramID" value="3"/> </Parameters> <Date unit="min">30,25</Date> </Event> Nature : nom identitifiant l’événement L’architecture de notre platefomre repose sur un syst émulé, sur un syst de contrôle et sur une interface qui on l’a vu s’appuie sur une structure type des messages entre les deux syst… (voici cette struture) « XX » représente, en UML, le « prototype » : à savoir, une « super classe » qui permet de définir un type donnée de manière générique Ex d’event : ex..; en syntaxe XML (manière normalisée de représenter des informations structurées) À la transformation de forme CU23 (ressource), On fait une demande de setup Qui utilisera le programme N°3 Et cet event se fait à la minute 30,25…. Type d’événement : Ordre (Request) Compte-rendu (Report)

17 Infrastructure du système de contrôle
Utilisation d’un système multi-agents Souplesse dans les interactions entre produit et agent de contrôle Encapsulation d’un outil ou décideur externe Comportements intelligents Normes FIPA Foundation for Intelligent Physical Agents Protocoles d’interaction Développement avec la plateforme JADE Là j’ai mis deux slides à la place de une seule… faut dire que la session porte sur les agents… Nous utilisons un système multi-agent pour faire le contrôle : pourquoi ? souplesse, donc posibilité d’expérimenter des relations entre agents (« comportements sociaux ») Assez facile d’encapsuler un outil ou une personne : intégrer l’environement décisionel du système de contrôle *Possibilité* d’obtenir des comportements intelligents : ils ne viennent pas comme ça, mais avec un autre outil on est sur qu’il n’apparaitraient pas… Parmis les différents type de SMA, on utilise les normes de la fipa FIPA: maintenant un TC de l’ieee : vas voir sur leur site ( FIPA: née de la volonté d’appliquer les système multi-agent à des système réels (acteurs principaux: les télécoms, et aussi –mais moins- des marchands de logiciels d’entreprise) Dans les normes de la FIPA, en particulier, on s’appuie sur la définission de protocol d’interraction (vois slide suivante). Enfin, on utilise la plateforme JADE pour le développement des agent. JADE met en œuvre une grande partie des normes FIPA.

18 Organisation du système de contrôle
Chaque composant émulé est représenté par un agent Produits et transformations de forme et d’espace Ceux-ci : exposent leurs attributs répondent aux ordres de contrôle D’autres agents effectuent le contrôle Perception des changements des attributs Emission d’ordres Un agent est responsable du transfert des messages entre système opérant et contrôle Exposition des attribut grace à un message de declaration envoyé à tous les agents de contrôle. Perception des changements des attributs grace au protocole FIPA-SUBSCRIBE, transmission des ordres grace à l’un des protocoles REQUEST. NB: sur le dernier point: si l’agent de transmission est légérement modifié, il permet d’accéder au système opérant réel…

19 Présentation d’un cas industriel
Fabriquant de meubles Emploie 4000 personnes CA 450 millions d’euros Simulation d’un atelier 70 références pièces / jour Gammes variées et non linéaires Complexité des flux Problématique industrielle: Gestion des encours Routage des pièces Utiliser des RFID ?

20 Modélisation Zone de test Pièces débitées à percer Pièces à emballer
Perçage 1 finies Perçage 2 Débit en-cours tampon tampon Perçage 3 tampon Emballage Existence d’un modèle de simulation de l’atelier. Reprise de ce modèle, définition par l’industriel d’une zone pilote. L’émulation est appliquée sur la zone pilote, le reste du modèle constitue l’environnement De la zone pilote. Modélisation sous Arena, implémantation des composants d’émulation sous la forme d’une bibliothèque Arena. TODO: ajouter une copie d’écran du modèle Arena (partie émulée)

21 Résultats et conclusion
Le système émulé reproduit des comportements observés Expressivité des primitives de modélisation Limites de la validation Validation de portions du système physique Difficile de reproduire les décisions Système à événements discrets (Arena) – Vs - Système temps continu (MAS) Synchroniser les échéanciers Simuler en « temps réel » Le comportement du système d’émulation reproduit effectivement des comportements observés ds réalité À ce jour : c’est tt en terme de validation… Il faudrait prendre une situation passée et la faire reproduire par la plateformpe ..; or … si c’est envisageable pour la partie physique, on imagine cependant la difficulté pour reproduire l’état initial et les processus réels de décision!! Problème du temps :? Système à événement discret (arena) vs Système en temps réel (système agent) = difficulté de synchronisation? => Utiliser HLA our synchroniser les deux modèles à événements discrets => Mettre le simulateur en mode temps réel pour que tout soit en temps réel Nos choix : tt en tps continu mais prbl de tps de run!! Validation du modèle?

22 Perspectives Compléter la base de modèles
Résoudre le problème du temps : utilisation de HLA Développer des systèmes intelligents/auto-organisés Compléter la base de modèle Techniquement : Implémenter les composant d’émulation dans d’autres simulateur que Arena. Résoudre le problème du temps : utilisation de HLA Améliorer le modèle de communication émulation/contrôle, en utilisant des standards industriels comme les web-services. Développer des systèmes intelligents/auto-organisés, pour piloter les différents modèle d’émulation : Mettre réellement en œuvre le contrôle par le produit.

23 Merci de votre attention …
Un temps pour les questions… Compléter la base de modèle Techniquement : Implémenter les composant d’émulation dans d’autres simulateur que Arena. Résoudre le problème du temps : utilisation de HLA Améliorer le modèle de communication émulation/contrôle, en utilisant des standards industriels comme les web-services. Développer des systèmes intelligents/auto-organisés, pour piloter les différents modèle d’émulation : Mettre réellement en œuvre le contrôle par le produit.