Soutenance mémoire
Le niveau de l’exécution
Le second niveau, Niveau de l’exécution, contient les applications permettant la gestion des produits de leur entrée dans le système à leur sortie. Ce niveau est de plus en plus composé du seul Manufacturing Execution System (MES) [Huang, 2002]. Nous opterons pour la définition de [Barkmeyer et al., 1999] : Un MES est un ensemble de composants matériels et logiciels permettant la gestion et l’optimisation des activités de production du lancement de la commande aux produits finis. Tout en maintenant des données précises et à jour, le MES guide, initie, répond et rapporte les évènements de l’usine au moment où ils se produisent. Un MES fournit des informations critiques aux modules d’aide à la décision à travers l’entreprise. Notons que le MES ne se substitue pas au système informatique d’entreprise (SIE) qui regroupe des fonctions de gestion de l’entreprise (comptabilité, logistique, GPAO etc.) Le MES vient compléter le SIE en assurant des fonctions de contrôle/commande (SCC) qui permettent le pilotage en temps réel des ateliers de fabrication. Malgré toute l’utilité pouvant être retirée de ce complément, force est de constater que le MES est encore mal connu, ce qui freine son implantation quasi-systématique, au même titre que les ERP. L’un des principaux travaux du MESA, association américaine à but non lucratif a été, outre la création du terme de MES, l’établissement d’une liste détaillée de fonctionnalités, connues comme les « 11 fonctions du MES ». Cette classification est d’un grand intérêt pour délimiter clairement le domaine du MES et évaluer la couverture des différentes offres. Ces 11 fonctions sont :
1. Gestion des ressources : Cette fonction suit le statut des ressources et met à jour un historique détaillé.
2. Ordonnancement : Cette fonction fournit le jalonnement des activités indépendantes basé sur des priorités, attributs, caractéristiques et/ou gammes associés aux produits concernés pour respecter les objectifs de performance définis par l’utilisateur.
3. Cheminement des produits et des lots : Cette fonction dirige le flux de produits selon le plan de production et l’ordonnancement détaillé.
4. Gestion des documents : Cette fonction contrôle, gère et restitue diverses informations relatives aux produits, dont les gammes, les plans, les procédures opératoires standards, etc.
5. Collecte et acquisition de données : Cette fonction collecte et met à jour les informations de production utilisées pour le suivi des produits, les historiques de production, etc.
6. Gestion du personnel : Cette fonction permet un suivi « à la minute près » du statut du personnel (présence, production, préparation de matériel, etc.)
7. Gestion de la Qualité : Cette fonction permet une analyse des produits et des processus de production pour assurer une qualité suffisante de la production.
8. Gestion du procédé : Cette fonction est totalement décrite dans les descriptions de la Gestion de la Qualité (7) et du Cheminement des produits et des lots (3). Cette distinction n’est réalisée que pour préciser qu’un système différent peut être utilisé pour réaliser cette fonction.
9. Gestion de la maintenance : Cette fonction historie, dirige, assure la périodicité et gère la disponibilité des outils nécessaires aux opérations de maintenance.
10. Traçabilité produit et généalogie : Cette fonction permet une visibilité sur la disposition spatiale et temporelle de chaque opération.
11. Analyse des performances : Cette fonction permet un suivi « à la minute près » des résultats courants des opérations de production (utilisation des ressources, disponibilité des ressources, temps de production unitaire, conformité à l’ordonnancement prévu, etc.) et une comparaison à l’historique et aux objectifs de performance.
Les systèmes pilotés par le produit
Avec le développement conjoint des technologies d’identification par ondes radio (RFID – Radio Frequency Identification), une application de plus en plus fréquente est liée au concept de produits intelligents. Un produit intelligent est muni d’un système d’autoidentification (Auto-ID) appelé étiquette (tag), qui permet de le relier aux informations du réseau de commande du système de production. Un produit intelligent se doit d’avoir tout ou partie de ces cinq caractéristiques [Wong et al., 2002] :
1. Il possède une identification unique
2. Il est capable de communiquer efficacement avec son environnement
3. Il peut retenir et conserver des données le concernant directement
4. Il utilise un langage pour communiquer ses besoins, ses possibilités etc.
5. Il est capable de participer à la prise de décision concernant son devenir
L’intérêt de l’utilisation de cette technologie est discuté dans [García et al., 2003] au niveau de la production, du stockage, de la distribution ou encore de la vente au détail :
– Possibilité d’adapter facilement le processus de production au produit, sans les limitations physiques du code-barres (accessibilité, distance de lecture). Les systèmes de production deviennent ainsi vraiment flexibles ;
– Stockage de toutes les informations nécessaires sur la même étiquette, sans avoir besoin de ré-étiqueter les produits en fonction des besoins spécifiques du stockage, de la livraison ou après un assemblage entre différents produits.
– Possibilité de gérer facilement des palettes mixtes, contenant plusieurs références de produits ;
– Les inventaires sont grandement facilités, voire totalement automatisés, etc.
Le développement des systèmes contrôlés par le produit [Morel et al., 2003][Pannequin et Thomas, 2006b] permet de créer des systèmes de production partiellement voire totalement réactifs. Le pilotage de tels systèmes se dirige donc vers des architectures où la plupart des éléments sont autonomes. Ceci permet des stratégies de pilotage très performantes, mais empêche d’avoir une vision globale de l’activité du système, ce qui rend difficile la prise de décision des niveaux supérieurs en relation avec le niveau de la commande. Parallèlement, l’adéquation des structures hétérarchiques avec la simulation de flux pour leur mise au point nous pousse à envisager l’utilisation de la simulation dans un contexte plus large. Nous proposons donc que l’outil d’aide à la décision évoqué en I.1.1 soit réalisé à l’aide de techniques de simulation de flux.
Quest
Quest, de par sa structure, permet de modéliser le système étudié en se calquant sur sa géométrie [Hugan, 1994]. Pour se faire, l’utilisateur positionne sur une surface plane représentant le sol de l’atelier les représentations géométriques 3D des éléments constitutifs de celui-ci à leur position exacte. Ce progiciel est particulièrement orienté vers la modélisation de systèmes manufacturiers, comme ont pu l’être Witness ou Automod II avant lui[Fegan et al., 1991]. Les éléments dont nous parlons sont donc des machines, des stocks ou des convoyeurs par exemple. Pour les éléments mobiles (opérateurs, chariots autoguidés AGV, etc.), un circuit peut, de plus, être ajouté pour permettre un déplacement précis et réaliste (Figure 7). Quest utilise une méthode orientée objet pour la définition des éléments. L’utilisateur commence par définir une classe d’éléments ayant une logique et une géométrie commune. Cette classe a différents paramètres et est instanciée un nombre de fois déterminé à l’avance. Chacune de ces instances, qui est alors un élément, sera placée dans le modèle géométrique. Ces éléments sont ensuite reliés aux autres éléments par des connexions logiques (Figure 8). Les connexions relient deux éléments entre eux. La liaison entre deux éléments autorise la circulation des pièces entre ces deux éléments. Les pièces ne pourront pas aller d’un élément à un autre si une des sorties du premier élément n’est pas reliée à une des entrées du deuxième élément. C’est dans cet environnement, constituant le modèle physique de l’atelier, que se déplacent les produits, appelés parts. À chaque élément est associé un ensemble de logics. Les logics, qu’il est possible de traduire en français par logiques, sont des programmes qui régissent le fonctionnement des éléments. On peut distinguer deux parties dans un élément Quest :
– L’entrée dans laquelle est exécutée la process logic ;
– La sortie dans laquelle est exécutée la route logic.
La process logic contrôle l’entrée des pièces et applique les transformations définies dans les processus sur les pièces. La route logic est exécutée sur chaque pièce qui sort de la process logic. Cette logique sert à choisir la destination de sortie de la pièce. On peut schématiser un élément standard suivant le principe de la Figure 9, où les inputs et les outputs représentent les différents points d’entrée et de sortie de parts dans l’élément. Dans le cas général ces deux logics sont activées séquentiellement, mais dans le cas où il n’est pas souhaitable d’attendre que l’élément suivant soit libre avant d’accepter une nouvelle pièce, il est possible de les exécuter simultanément. A ces deux logiques principales, il est possible d’ajouter d’autres logiques spécifiques :
– La request logic, utilisée pour appeler des pièces dans un système en flux tiré;
– La queueing logic, servant à régir la loi de stockage d’un stock (FIFO, LIFO, etc.). Cette logique n’est disponible que sur les classes de stocks ;
– L’init logic, exécutée une fois au début de la simulation ;
– etc.
Ces logiques sont toutes définies au niveau des éléments. Dans certains cas, il est utile de définir des logiques au niveau du modèle global :
– L’init logic est l’équivalent de celle que l’on trouve sur les éléments, mais est exécutée par le modèle, lors du lancement de son exécution ;
– La sim logic est exécutée à intervalles réguliers par le modèle ;
– La term logic est exécutée lorsque l’on arrive à la fin du temps de la simulation (elle n’est donc pas exécutée si l’on interrompt la simulation avant le temps programmé) ;
– L’action logic est exécutée juste avant ou juste après chaque évènement du simulateur.
Pour permettre une modélisation rapide, toutes ces logics ont un comportement établi par défaut. Il est toutefois possible de les personnaliser pour augmenter la fidélité du comportement du simulateur par rapport à celui du système étudié en réécrivant le programme associé en langage SCL (Simulation Control Language). Ce langage de simulation propriétaire permet d’une part le contrôle des éléments de la simulation, et d’autre part l’interfaçage avec l’utilisateur et le monde extérieur. Un second langage est disponible sous Quest : le BCL (Batch Control Language). Ce langage est utilisé pour contrôler Quest. On peut, à l’aide de celui-ci :
– Lire un modèle ;
– Modifier un modèle (ajout, suppression, modification d’éléments) ;
– Exécuter une simulation ;
– Interroger les résultats de simulation ;
– Enregistrer un modèle ;
– Contrôler les caméras ;
De nombreuses méthodes existent pour exécuter du code BCL dans Quest :
– Depuis le SCL ;
– Par une boite de dialogue ;
– Par un bouton personnalisé ;
– En chargeant un modèle Quest avec un script BCL : il est possible, au chargement d’un modèle Quest, de lui imposer un script BCL à exécuter ;
– En chargeant Quest avec une Socket : il est possible de lancer le logiciel avec un port sur lequel écouter. Toute donnée reçue sur ce port sera une commande BCL exécutée par le logiciel.
On peut alors trouver de nombreuses applications à ces fonctionnalités :
– Génération automatisée de modèles ;
– Création d’un modèle d’optimisation contrôlé par un programme externe ;
– Modifications du modèle en cours de simulation en SCL ;
– Envoi de données depuis un programme externe.
Comme on peut le constater, les points forts de Quest sont, d’une part, sa puissante animation graphique, et d’autre part sa forte compatibilité avec les systèmes de production. Ce dernier point assure une prise en main plus conviviale pour les non-experts. Les principaux points faibles de Quest se situent au niveau des faibles possibilités de communication avec l’extérieur et au niveau de la programmation avancée en SCL et BCL, qui requièrent un haut niveau d’expertise pour affiner le comportement des éléments et plus généralement des modèles.
Quelques exemples de développements de la simulation en ligne
Les auteurs précédents ont monté une plate-forme expérimentale pour tester la validité de leur approche. Cette plate-forme (voir [Gonzalez et Davis, 1997]) permet la commande et la simulation du système en modélisant explicitement les interactions entre contrôleurs pour décrire les mécanismes de transition d’états qui gouvernent l’évolution d’un système distribué. De ce fait, ils se basent en grande partie sur les échanges de messages sur le réseau pour déterminer l’état du système. De nouveau, cette approche élimine beaucoup de systèmes de l’utilisation de la simulation en ligne. Dans [Rogers et Flanagan, 1991], les auteurs utilisent une simulation en ligne pour aider les contrôleurs aériens à diminuer les problèmes de trafic et augmenter la sécurité. Les données temps-réel provenant des centres de contrôle aérien sont utilisées pour construire une base de données indiquant l’état actuel du réseau de transport. Ces seules données sont utilisées pour initialiser les simulations (appelées faster-than-real-time) qui sont faites pour explorer l’impact des décisions prises par les contrôleurs aériens dans le but de déterminer les trajectoires. L’initialisation des simulations dans ce cas est un cas très particulier. En effet, le triptyque position-trajet-vitesse de chaque élément contrôlé est très bien connu et défini à tout instant. De plus, très peu de perturbations relativement à la dynamique du système ne viennent perturber les prédictions. De ce fait, la relation entre objets du système réel et objets simulés est presque immédiate, et donc l’initialisation également. Devant la difficulté d’initialiser les simulations en ligne, certains auteurs ont diminué le niveau d’expertise de leur solution. Ainsi, [Kouiss et Pierreval, 1999] proposent une application basée sur une simulation en ligne. Cette application a pour objectifs d’aider à surveiller le système par l’analyse et la comparaison entre les données réelles et simulées et d’aider l’opérateur à prendre des décisions spécialement concernant l’ordonnancement. Pour montrer la validité de l’approche, ils ont développé cette application sur un FMS « taille réelle » installé à l’Institut Français de Mécanique Avancée (IFMA). La collecte d’informations sur le terrain se résume ici à une mise à jour des paramètres intrinsèques de la simulation (durées de production etc.) pour affiner cette dernière. Toutefois, les simulations partent toutes d’un état initial identique généralement considéré vide et inactif (idle et empty). Ici, la simulation est « en ligne » dans le sens où l’on initialise automatiquement les données du simulateur à partir du système réel, mais on ne traite pas du problème de l’initialisation de l’état du simulateur. De la même manière, [Peters et Smith, 1998] présentent un système de commande appelé TSCS développé par TAMCAM, utilisé pour étudier les avantages (et désavantages) de la simulation en ligne dans l’architecture de commande. La simulation est utilisée pour faire des prévisions destinées à évaluer des politiques de commande alternatives : ils appellent cela « travailler en Look Ahead ». L’implémentation est faite sur Arena équipé du modèle temps-réel (Arena RT), Access, Visual Basic et Visual C++. La modélisation de leur système réel considère que les durées opératoires sont toutes basées sur une loi de distribution. La simulation qu’ils font tourner en parallèle du système réel sert à collecter les différentes durées de production. L’historique de ces durées sert alors à évaluer les coefficients des distributions aléatoires, coefficients qui sont réutilisés pour la simulation en mode Look Ahead. De ce fait, ils n’ont qu’une vue sur « Comment le système fonctionne en ce moment ? », car ils ne prennent pas en compte toutes les données nécessaires pour savoir « Dans quel état est le système en ce moment ? », données qui sont les plus compliquées à obtenir. Les conclusions qu’ils peuvent tirer sur l’utilité de la simulation en ligne n’ont donc pas une grande portée puisque leur simulation est finalement assez loin de ce que l’on pourrait attendre d’une simulation en ligne complète. Même si la finalité du système est différente de la notre, l’implémentation de la solution envisagée est intéressante. La Figure 10 présente l’implémentation qu’ils envisagent. Le concept et surtout les finalités de la simulation temps-réel sont relativement différents dans nos travaux, mais le découpage entre une simulation temps-réel qui suit la production pour fournir des données à une simulation en mode Look Ahead sera développé dans la suite de ce document. [Ramakrishnan et al., 2002] utilisent également un modèle type look-ahead et un modèle appelé RT lancé en temps réel et connecté au système de production. Ce modèle RT sert à comparer les fins de tâche programmées des opérations d’une SCM avec celles définies dans la base de données. S’il y a une déviation, une simulation look-ahead est lancée pour déterminer si la tendance va à l’aggravation et s’il faut alors déclencher des actions correctives. Les modèles sont développés sur Arena 4.0 avec une base de données SQL. À part cela, peu d’informations sont données sur l’implantation pratique de leur solution. [Wu et Wysk, 1989] ont choisi de discrétiser le temps en intervalles égaux. À chaque début de période dt, une simulation est lancée pour tester différentes règles locales d’ordonnancement et décider quelles sont la ou les meilleures selon plusieurs critères (mean flow time etc.). À ce moment, ils choisissent d’appliquer ces règles pendant le prochain dt, et recommence dt plus tard. L’initialisation ne leur pose pas trop de problèmes, puisque les pièces ne peuvent être au début d’une simulation que dans les machines ou dans des stocks bien définis. Si elles ne le sont pas en réalité, ils en font l’approximation. De ce fait, ils ne semblent pas prendre en compte les temps de transferts, et ne parlent pas de la remontée d’informations depuis l’atelier (notamment sur la taille des stocks et l’acquittement des opérations), puisqu’ils ne font cette simulation que pour servir de benchmark de leur solution. Au final, ils ne décrivent pas l’application de leur solution sur un cas de taille industrielle.
|
Table des matières
INTRODUCTION
CHAPITRE I. LE PILOTAGE D’UNE UNITÉ DE PRODUCTION ET L’AIDE DE LA SIMULATION
I.1 LE PILOTAGE DE LA PRODUCTION
I.1.1 STRUCTURES DE PILOTAGE
I.1.2 HIÉRARCHIES DE PILOTAGE
I.2 LA SIMULATION DE FLUX
I.2.1 DÉFINITION – FONCTIONNEMENT – LIMITES – OBJECTIFS
I.2.2 LANGAGES ET PROGICIELS DE SIMULATION
I.3 LA SIMULATION EN LIGNE
I.3.1 DÉFINITION
I.3.2 LA SIMULATION EN LIGNE ET LE SYSTÈME RÉEL
I.3.3 QUELQUES EXEMPLES DE DÉVELOPPEMENTS DE LA SIMULATION EN LIGNE
I.4 CONCLUSION
CHAPITRE II. LA SIMULATION EN LIGNE ET L’AIDE À LA DÉCISION
II.1 L’AIDE À LA DÉCISION
II.1.1 RÉSOLUTION DE PROBLÈMES DANS LE PILOTAGE DES SYSTÈMES DE PRODUCTION
II.1.2 CHRONOLOGIE DE LA PRISE DE DÉCISION
II.1.3 PLACE RELATIVE DE L’HUMAIN ET DE LA SIMULATION DANS UN COMPORTEMENT BASÉ SUR LES RÈGLES
II.2 LA PHASE D’IDENTIFICATION DE L’ÉTAT ET DE PRÉVISION DE L’ÉVOLUTION DU SYSTÈME
II.2.1 ÉVALUATION DE L’IMPORTANCE DE LA PRISE EN COMPTE DE L’ÉTAT INITIAL SUR UN EXEMPLE
II.2.2 L’INITIALISATION
II.3 CONCLUSION
CHAPITRE III. UTILISATION DE LA SIMULATION COMME OBSERVATEUR D’UN SYSTÈME DE PRODUCTION
III.1 INITIALISATION UTILISANT DIRECTEMENT L’ÉTAT DU SYSTÈME DE PRODUCTION
III.1.1 NOTION D’ÉTAT DU SYSTÈME
III.1.2 UTILISATION DES INFORMATIONS DIRECTEMENT ISSUES DU SYSTÈME RÉEL
III.2 UTILISATION D’UN SIMULATEUR TEMPS-RÉEL
III.3 LE CONCEPT D’OBSERVATION PAR SIMULATION
III.3.1 LA RECONSTRUCTION D’ÉTAT
III.3.2 LES DONNÉES NÉCESSAIRES
III.3.3 RECALAGES
III.3.4 L’OBSERVATEUR DANS L’ARCHITECTURE DE COMMANDE
III.4 CONCLUSION
CHAPITRE IV. VALIDATION SUR UNE PLATEFORME EXPÉRIMENTALE
IV.1 LA LIGNE D’ASSEMBLAGE
IV.1.1 LA STRUCTURE PHYSIQUE
IV.1.2 LA STRUCTURE INFORMATIONNELLE
IV.1.3 LE FONCTIONNEMENT
IV.2 QUELQUES EXEMPLES DE DÉCISIONS À PRENDRE PAR LE PILOTE
IV.2.1 LANCEMENT DE PRODUCTION
IV.2.2 RÈGLE LOCALE D’ORDONNANCEMENT
IV.3 INTÉGRATION DANS L’ARCHITECTURE DE COMMANDE
IV.3.1 LE SIMULATEUR
IV.3.2 L’OBSERVATEUR
IV.3.3 PERFORMANCE DE LA REMONTÉE D’INFORMATIONS DEPUIS L’ATELIER
IV.4 MODÉLISATION DE L’OBSERVATEUR
IV.4.1 SOUS QUEST
IV.4.2 SOUS ARENA
IV.5 MODÉLISATION DU SIMULATEUR
IV.6 L’ARCHITECTURE IMPLANTÉE
IV.7 LE MODULE D’AIDE À LA DÉCISION
IV.8 CONCLUSION
CONCLUSION ET PERSPECTIVES
BIBLIOGRAPHIE
Télécharger le rapport complet
