Validation par simulation distribuée de l’ordonnancement d’entreprises en réseau

22/09/2017
Publication e-STA e-STA 2007-4
OAI : oai:www.see.asso.fr:545:2007-4:19882
DOI :

Résumé

Validation par simulation distribuée de l’ordonnancement d’entreprises en réseau

Métriques

22
8
394.87 Ko
 application/pdf
bitcache://43b740d3d38880ab6b155d881e924e5cbc38cbad

Licence

Creative Commons Aucune (Tous droits réservés)
<resource  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns="http://datacite.org/schema/kernel-4"
                xsi:schemaLocation="http://datacite.org/schema/kernel-4 http://schema.datacite.org/meta/kernel-4/metadata.xsd">
        <identifier identifierType="DOI">10.23723/545:2007-4/19882</identifier><creators><creator><creatorName>Simon Enjalbert</creatorName></creator><creator><creatorName>Bernard Archimède</creatorName></creator><creator><creatorName>Philippe Charbonnaud</creatorName></creator></creators><titles>
            <title>Validation par simulation distribuée de l’ordonnancement d’entreprises en réseau</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2017</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Fri 22 Sep 2017</date>
	    <date dateType="Updated">Fri 22 Sep 2017</date>
            <date dateType="Submitted">Fri 20 Jul 2018</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">43b740d3d38880ab6b155d881e924e5cbc38cbad</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>33793</version>
        <descriptions>
            <description descriptionType="Abstract"></description>
        </descriptions>
    </resource>
.

Résumé — Dans cet article, un outil de simulation distribuée pour la validation d’ordonnancement multi-site est proposé. Son champ d’application concerne l'évaluation de la conduite d'ateliers géographiquement répartis. La simulation distribuée des ateliers, appelés ateliers virtuels, pose des problèmes de causalité et de coordination de l’exécution des tâches. Ces problèmes sont traités dans l’architecture distribuée d’ateliers virtuels par l’implantation du protocole HLA garantissant la synchronisation et la chronologie des événements. Une application à un cas simple de chaîne logistique organisant le flux entre trois ateliers montre l’intérêt de l’outil. Mots clés — Chaîne logistique, ordonnancement multi-site, simulation distribuée, HLA. I. INTRODUCTION La Chaîne Logistique (CL), constituée d’unités de production spécialisées, coopérantes et distribuées géographiquement, pose le problème de l’évaluation de son fonctionnement. L’organisation et la gestion de la répartition de la production et des métiers sont les enjeux essentiels de la CL (Stadtler, 2000). La complexité de ces organisations multi-sites est appréhendée par l’utilisation d’outils spécialisés dans la conduite d’activités de production tels que les ERP (Enterprise Resource Planning) ou les APS (Advanced Planning System) (Stadtler et Kilger, 2000 ; Meyr et al., 2000). Cependant, ces outils s’appuient sur des modèles agrégés de systèmes réels de production pour générer des plans de production utilisés par les entreprises partenaires. Ces plans calculés peuvent ne pas convenir à cause de l’écart entre les modèles utilisés et la réalité des sites de production. Pour pallier à cet inconvénient, il est impératif d’évaluer les plans avant leur mise en œuvre dans les ateliers et de les valider en vue d’adapter, le cas échéant, la configuration de la CL. Différentes méthodes ont été proposées pour valider des plans d’ateliers distribués. Dans (Lee et al., 2002), la résolution analytique présentée repose sur un jeu d’équations mathématiques représentant le modèle de la CL traitée. Cependant, les modélisations incomplètes des caractéristiques dynamiques des systèmes analysés ne fournissent pas de solutions acceptables. Des simulations ont permis l’évaluation de la CL en la considérant comme une seule entreprise centralisée (Luder et al., 2004 ; Gupta et al., 2002 ; Kubota et al., 1999). Néanmoins des difficultés liées au nombre important d’entités à modéliser et au niveau de détail désiré lors d’une modélisation en équipe de travail forment les premières limites de cette approche. D’autres concernent la quantité d’événements à simuler, la puissance de calcul des ordinateurs, la réutilisation des modèles de simulation et la protection de la propriété intellectuelle. Finalement, la modélisation de tous les sites d’une CL demeure possible mais la simulation sur un seul processeur n’est pas toujours réalisable. De plus, il est difficile d’obtenir une évaluation fine de la faisabilité en se basant sur un modèle agrégé. L’évaluation de la faisabilité de la CL ne se ramène pas non plus à la somme des évaluations de la faisabilité des plans de chaque site. Compte tenu de ces limites, la validation d’ordonnancement multi-site nécessite la définition d’une architecture de simulation distribuée. Différents travaux ont été menés sur la simulation distribuée de grands systèmes de production. Un premier atout en faveur de la décentralisation concerne la protection des informations de chaque acteur de la CL. Ceux-ci peuvent choisir de masquer certaines données lors de la simulation distribuée. Les modèles distribués sont construits et maintenus localement et ne se rejoignent que lors de l’évaluation (Mertins et al., 2005). De plus, la performance globale du temps de simulation est améliorée grâce à la distribution (Turner et al., 2000). Pour synchroniser des simulateurs au sein d’une grande simulation, le protocole HLA (High Level Architecture ) a été proposé par le DMSO (Defense Modeling and Simulation Office) (IEEE, 2000). Il facilite l'interopérabilité et la réutilisation des simulations. Il a pour intérêt de réduire les coûts de la modélisation et de la simulation et de répondre aux besoins de grandes simulations faisant intervenir des composants géographiquement distribués. HLA met en œuvre des algorithmes pour la synchronisation et le respect de la chronologie pour les événements simulés et notamment celui défini dans (Chandy et Misra, 1978). HLA permet de synchroniser une fédération, i.e, un ensemble de fédérés partageant un modèle objet commun, le FOM (Federation Object Model), contenant toutes les informations relatives à l’exécution de la simulation. Un fédéré est un composant de la fédération comprenant un simulateur auquel peuvent être associés un opérateur, une machine ou un atelier complet. Le RTI (Run-Time Infrastructure) constitue une implantation informatique des spécifications d’interface HLA. Il s'agit d'un processus informatique assurant les communications entre les fédérés d'une même fédération en offrant les services de HLA pour la synchronisation et la chronologie des événements. Dans cet article, le modèle d’architecture sur lequel repose la démarche est d’abord présenté. Puis l’outil de simulation distribuée développé est décrit par l’étude du fonctionnement des différentes classes qui composent son architecture logicielle. Une attention particulière est portée à la description des mécanismes de coordination et synchronisation des messages et des informations. Enfin, un modèle multi-site de SIMON ENJALBERT, BERNARD ARCHIMEDE, PHILIPPE CHARBONNAUD ENI Tarbes, 47 avenue d’Azereix, BP 1629, 65016 Tarbes Cedex, France {simon.enjalbert; bernard.archimede; philippe.charbonnaud}@enit.fr http://www.enit.fr/ Validation par simulation distribuée de l’ordonnancement d’entreprises en réseau CL organisant le flux entre trois ateliers distribués sert à illustrer la modélisation. Finalement, les résultats sont discutés pour la validation d’ordonnancement multi-site. II. MODELE F-R-PAC Le modèle R-PAC (Reactive Production Activity Control) représente conceptuellement un système de commande et de suivi d’un atelier. Les OF (Ordres de Fabrication) sont ordonnancés puis distribués au sein de l’atelier. Le suivi consiste à recenser les événements pour établir un état de la production et de l’outil de production. Dans (Archimède et al., 2003), une architecture MS-R-PAC (Multi-Site Reactive PAC) a été proposée pour le cas d’ateliers géographiquement répartis. MS-R-PAC coordonne la conduite de plusieurs ateliers virtuels à l’aide d’un ordonnancement distribué réalisé grâce à un protocole proche du Contract Net (Smith, 1980). L’atelier virtuel est la représentation informatique sur un simulateur d’un atelier réel. Des problèmes de synchronisation peuvent cependant apparaître dans ce modèle compte tenu du nombre important d’événements à simuler. La règle de causalité, ou respect de la chronologie des événements, peut ne pas être garantie quand les simulateurs ont des vitesses différentes. Ces différentes limitations ont conduit à la proposition d’un nouveau modèle fédérant les modèles R-PAC capable de gérer la synchronisation des simulateurs en garantissant la règle de causalité et la bonne exécution des plans. Afin de répondre à ces exigences, le modèle F-R-PAC (Fédération de R-PAC), associant autant de fédérés qu’il existe de sites, a donc été défini. Sur la figure 1, une fédération F-R- PAC est illustrée. Ces sites peuvent indifféremment représenter des ateliers, des machines, des opérateurs ou des moyens de transport. Une fonction d’ordonnancement distribué interagit avec les fédérés R-PAC à l’aide du protocole TCP/IP. Pour sa part, la simulation distribuée s’articule autour du bus régit par le protocole HLA et permet l’exécution de tout type d’ordonnancement multi-site sur les ateliers virtuels. La synchronisation des fédérés est assurée par le protocole HLA. A. Fédéré R-PAC Sur la figure 1, au sein d'une fédération F-R-PAC chaque fédéré R-PAC est composé de trois gestionnaires et d’un simulateur d’atelier encapsulé. Le GSF (Gestionnaire de Suivi de Flux) réalise le suivi de la production en détectant l’occurrence des événements de début et de fin d’opérations issus de l’atelier virtuel. Le COM (gestionnaire de COMmunication) assure la liaison entre l’ordonnanceur et le GL (Gestionnaire de Lancement) ou le GSF. Enfin, le GL, dont l’algorithme est détaillé dans (Enjalbert et al., 2004), pilote l’exécution des plans et le lancement des tâches dans l’atelier virtuel. Tout changement sur l’atelier réel nécessite une adaptation de l’atelier virtuel correspondant. Ce type d’architecture permet de prendre en compte facilement toute modification du réseau d’entreprises. RTI A et FED A sont deux Ambassadeurs intégrés au GL, i.e. des entités assurant l’interface avec HLA. B. Synchronisation des fédérés Comme présenté précédemment, la synchronisation et le respect de la règle de causalité sont deux difficultés majeures de la simulation distribuée. Le fonctionnement de F-R-PAC requiert la cohabitation de deux types de synchronisation : la synchronisation inter fédérés R-PAC et la synchronisation intra fédéré. La synchronisation inter fédéré, gérée par HLA, repose sur un mécanisme de publication/abonnement. En cours de simulation, les fédérés R-PAC coopèrent et réagissent aux événements qui se produisent et qui sont véhiculées sur le réseau à l’aide de messages datés. Ces messages datés assurent un fonctionnement régulé et contraint pour tous les fédérés. La synchronisation intra fédéré concerne la liaison entre le GL et le simulateur piloté. Elle est basée sur l’établissement de points de rendez-vous auxquels le simulateur doit se rendre pour se synchroniser avec le GL. TCP/IP Fédéré Contrôle d’Activité de Production Réactif (R-PAC) TCP/IP Gestionnaire HLA RTI G HLA BUS FED A RTI A Gestionnaire Lancement (GL) Gestionnaire du Suivi de Flux (GSF) Simulateur Gestionnaire Communication (COM) ORDONNANCEUR DISTRIBUE FED A RTI A Gestionnaire Lancement (GL) Gestionnaire du Suivi de Flux (GSF) Simulateur Gestionnaire Communication (COM) Figure 1. Fédération F-R-PAC. En réalité, la difficulté réside dans la cohabitation de ces deux niveaux de synchronisation. En effet, le GL, structure de contrôle du fédéré, doit satisfaire le RTI afin d’avancer en tenant compte des autres fédérés. Il doit par ailleurs s’assurer qu’un point de rendez-vous n’est pas trop éloigné afin d’éviter une désynchronisation du simulateur. L’exemple de la figure 2 illustre la gestion du temps et la règle de causalité pour la cohabitation des deux niveaux de synchronisation. Afin de garantir la bonne exécution du plan, le GL doit déterminer la date de l’événement le plus proche dans le temps en fonction des informations recueillies auprès du simulateur et des informations tirées de son propre échéancier. La date souhaitée du prochain rendez-vous est ainsi fixée par le GL en fonction des informations locales. Cette date peut être un début ou une fin d’opération planifiée, un début ou une fin de transport, ou encore une date correspondante à un événement attendu mais retardé. Le fédéré demande ensuite l’autorisation au RTI pour avancer le simulateur à cette date (NER : Next Event Request). Si le RTI considère que jusqu’à cette date aucun événement extérieur ne viendra perturber le fédéré, alors il autorise l’avance dans le temps (TAG : Time Advance Grant) du simulateur. Si au contraire le RTI refuse l’avance à la date souhaitée de rendez-vous, il propose un nouveau point de rendez-vous à une date inférieure correspondante au prochain événement extérieur concernant le fédéré. Le GL peut alors avancer le simulateur jusqu’à la date retenue de rendez-vous. Il est à noter que jusqu’à cette date de rendez-vous, plusieurs relances du simulateur sont possibles. Cela peut être dû aux arrêts du simulateur pour cause de dysfonctionnements. Une fois le point de rendez-vous atteint, le GL réactualise son échéancier, transmet des messages datés sur son état au RTI et recommence le cycle en proposant une nouvelle date souhaitée de rendez-vous. Dans l’exemple étudié, la première synchronisation a lieu à la date u. De manière générale, les dates sont exprimées en unités de temps (u.t). Un CDE (Current Date Event) est envoyé par le simulateur au GL. Celui-ci correspond à une date retenue de rendez-vous préalablement. Le fédéré transmet au RTI des messages concernant l’état des objets simulés localement, (UAV : Update Attribute Value). Il demande ensuite une nouvelle avance dans le temps vers la prochaine date souhaitée de rendez-vous. La requête d’avance de temps doit conduire le simulateur à la date t. Le RTI s’assure préalablement qu’aucun événement ne pourra intervenir avant la date retenue (t) pour le fédéré. Une fois l’autorisation accordée (TAG) et après avoir reçu les messages concernant l’état des objets simulés par les autres fédérés (RAV : Reflect Attribute Value), le GL transmet l’information au simulateur piloté qui peut à nouveau avancer à la date t. Le mécanisme est reconduit jusqu’à la simulation complète de tous les événements planifiés. RTI GL (fédéré) t RAV & TAG (t) T Temps logique fédéré [u.t.] CDE (u) NER (t) UAV (t-) TAG (t) RAV & TAG (T) CDE (t) NER (T) TAG (T) NER (T+x) CDE (T) Simulateur u t T Temps simulateur [u.t.] u UAV (T-) UAV (T+) Figure 2. Communications au sein d’un fédéré R-PAC. III. IMPLANTATION DE F-R-PAC Sur la figure 3, un diagramme de classes UML détaille les fonctions principales de la couche de simulation distribuée pour l’architecture F-R-PAC. Il existe cinq classes principales. CSimulator modélise le GL et encapsule le simulateur piloté. CFlowShopManager réalise le suivi des opérations de production au travers des profils de flux. COrdoAmbassador est la classe qui gère la liaison avec l’ordonnancement. CShopFederate permet au fédéré R-PAC d’accéder aux mécanismes de HLA. Enfin, CWorkshop représente la base de donnée alimentant les différentes classes. Figure 3. Diagramme de classes UML de F-R-PAC. A. Gestionnaire de Lancement Le GL pilote l'exécution des ordres de production dans l'atelier virtuel. CSimulator est liée aux classes permettant la récupération d’informations relatives au fonctionnement du simulateur (CPlan, CEcheancier, l’échéancier du GL et CReseauTransport, facilitant la prise en compte du transport). La classe CSimbaModel met en œuvre l’encapsulation du simulateur. Dans notre étude, le simulateur d’atelier retenu est SIMBA, logiciel de simulation événementielle créé et diffusé par Lanner Group. CSimulator assure le pilotage de l’exécution des plans dans l’atelier virtuel. B. Gestionnaire du Suivi de Flux Le GSF est implanté dans la classe CFlowShapeManager et fournit les mécanismes vérifiant à chaque occurrence d'événement si le déroulement de l'exécution du plan dans l'atelier simulé est correct. En fonction de l'ordonnancement initialement prévu par l'ordonnanceur et disponible dans par l’intermédiaire de CWorkshop, un profil de flux prévu pour l’atelier est généré. Lors de la simulation, les informations datées concernant le déroulement des tâches sont traitées et une comparaison est effectuée afin de détecter les écarts. La figure 4 illustre un suivi de la production par la génération d’un profil de flux à partir des occurrences de dates de début et de fin d'opération. Temps Niveau Tâche produite par la machine i Tâche consommée par la machine j Figure 4. Fonction profil de flux entre deux machines i et j. Le niveau représente la somme exprimée en dizaines de minutes des tâches dont le lancement est prévu dans l'atelier. Un accroissement indique une augmentation de la charge globale de l'atelier alors que le niveau zéro signifie qu'aucune tâche n'est programmée. Dans la pratique, le plan de production diffère toujours du plan effectif car l'ordonnancement est réalisé à partir d'une simplification de la réalité. Les écarts entre les profils prévus et réels sont analysés à chaque occurrence d'événement afin d'évaluer les performances du plan. Pour réduire les temps de détection, les profils de flux d'un même atelier sont agrégés selon un mécanisme décrit dans (Archimède et al., 1993). C. Gestionnaire de Communication Le gestionnaire COM met en oeuvre un lien entre la plate- forme de simulation distribuée et la couche d'ordonnancement distribué. Le COM est décrit dans la classe COrdoAmbassador. Il permet d'envoyer à l'ordonnanceur des informations relatives aux aléas de production ou de transport qui ont été détectés par le GSF et est à l'écoute de l'ordonnanceur pour recevoir à tout instant un nouvel ordonnancement. Les ateliers virtuels communiquent indépendamment du COM via le bus HLA grâce à la classe CShopFederate comprenant toutes les informations HLA nécessaires à l'exécution de la fédération. CWorkshop demande les informations sur l'ordonnancement initial par sa liaison avec COrdoAmbassador. Les dates des messages relatifs aux tâches sont à disposition de CShopFederate dans le formalisme HLA. De même, une base de donnée est accessible au GL par l’intermédiaire de la classe CSimulator afin d’alimenter le simulateur. Enfin, CWorkshop est en contact avec CFlowShapeMgr afin de donner les informations relatives à l’ordonnancement initial pour prévoir les profils de flux. CWorshop est la classe mettant à disposition de la simulation les informations nécessaires à la synchronisation des fédérés. IV. APPLICATION A UN CAS SIMPLE DE CHAINE LOGISTIQUE La démarche est illustrée dans le cas didactique d’une entreprise désirant faire fabriquer cinq produits. Pour chaque OF, une seule pièce est produite. Les cinq OF considérés, OF1, OF2, OF3, OF4 et OF5 sont présentés aux éventuels producteurs. Les cinq gammes de fabrication et les durées de chacune des activités sont résumées dans le tableau 1. Trois sites de production situés à Toulouse, Paris et Bordeaux sont retenus comme partenaires pour ce projet. Le site de Toulouse est spécialisé pour les opérations de fraisage, d’ébavurage et de perçage, Paris pour le tournage et le fraisage et enfin Bordeaux pour l’assemblage et la peinture. Les machines et les activités associées sont décrites dans le tableau 2. Les durées de transports inter-sites sont définies dans le tableau 3 alors que les durées de transport entre chaque machine sont de 40 u.t. OF Activité Durée OF1 Fraisage 2 120 u.t Perçage 90 u.t Ebavurage 100 u.t Peinture 90 u.t Assemblage 140 u.t OF2 Fraisage 2 100 u.t Ebavurage 110 u.t Perçage 80 u.t Assemblage 110 u.t Peinture 80 u.t OF3 Tournage 100 u.t Fraisage 1 80 u.t Tournage 80 u.t Ebavurage 120 u.t Fraisage 2 100 u.t OF4 Tournage 90 u.t Fraisage 1 90 u.t Tournage 90 u.t Assemblage 130 u.t Fraisage 2 80 u.t Perçage 100 u.t OF5 Peinture 240 u.t Assemblage 200 u.t Perçage 100 u.t Ebavurage 130 u.t Assemblage 100 u.t Tableau 1. Gammes de fabrication. Pour cet exemple, un ordonnancement distribué a été effectué à l’aide du logiciel R@mses (Re@ctive Multi-agent System for Scheduling). Basé sur le modèle multi-agent SCEP (Superviseur, Client, Environnement et Producteur), R@mses met en compétition les OF qui négocient leur ordonnancement avec les sites (Coudert, 2000). Site Machine Activité Toulouse M1 Fraisage 2 M2 Ebavurage M3 Perçage Paris M1 Tournage M2 Tournage M3 Fraisage 1 Bordeaux M1 Assemblage M2 Assemblage M3 Peinture Tableau 2. Machines et activités sur les sites. Durant cette période, il est supposé que des travaux sont en cours sur les axes routiers reliant les sites, limitant ainsi le trafic. Un sens de circulation arbitraire est alors imposé. Le parcours de livraison dessert successivement les sites de Toulouse, Bordeaux puis Paris avant de revenir sur Toulouse. Le simulateur SIMBA utilisé dans notre outil permet une gestion de l’allocation des ressources de transport dès qu’une requête est envoyée aux chariots (intra-site) ou aux camions (inter-sites). Le premier disponible effectue le transport pour la pièce relative à l’activité de production. Dans un premier temps, l’influence des transports intra-site sur la simulation de plan multi-site est étudiée. Trois camions sont disponibles pour les transports inter-sites et un chariot est affecté pour chaque site. Chacun ne peut transporter qu’une seule pièce à la fois par trajet. Par la suite, une deuxième simulation est effectuée avec deux chariots pour chaque site afin de valider la meilleure configuration intra-site. De / Vers Toulouse Paris Bordeaux M1 M2 M3 M1 M2 M3 M1 M2 M3 Toulouse M1 M2 M3 - 450 u.t 178 u.t Paris M1 M2 M3 450 u.t - 400 u.t Bordeaux M1 M2 M3 178 u.t 400 u.t - Tableau 3. Durées des transports inter-sites. L’exécution du plan distribué par notre outil de simulation permet la génération des profils de flux représentés sur la figure 5. Ces flux sont des représentations internes qui ne sont pas destinées à être interprétées par un opérateur et servent au suivi automatique de la production. Les 5 OF traités dans cet exemple ont pour particularité de concentrer leurs activités sur le même site en début d’ordonnancement puis de distribuer les activités finales sur d’autres sites. Afin d’évaluer l’influence des transports intra-site, des profils partiels sont présentés. Ils ne concernent que les activités ayant lieu sur un même site avant tout transport externe. Le site de Bordeaux n’est pas représenté ici car le transport intra-site y est rare et se déroule en fin d’ordonnancement, n’influençant pas ainsi la validation du plan. Figure 5. Profils de flux agrégés prévus pour (a) Toulouse, (b) Paris, suivis avec 1 chariot pour (c) Toulouse, (d) Paris et suivis avec 2 chariots pour (e) Toulouse, (f) Paris. Les flux agrégés prévus initialement par l’ordonnanceur pour les sites de Toulouse (fig.5.a) et Paris (fig.5.b) servent de référent pour évaluer les écarts en fonction du nombre de chariots. Le site de Paris avec deux chariots (fig.5.f) connaît un retard de 10 u.t par rapport à la prévision (fig.5.b) qui ne tenait pas compte de la disponibilité des transports. Ce retard est plus marqué dans le cas d’un unique chariot (fig.5.d) ; la simulation des tâches s’achève au temps 210 u.t, soit un retard de 80 u.t. Pour le site de Toulouse, le retard avec deux chariots (fig.5.e) est de 400 u.t par rapport à la prévision (a) contre 978 u.t de retard dans le cas d’un seul chariot (fig.5.c). De plus, la propagation des retards entraîne des modifications de l’allure du profil (fig.5.c). Au temps 290 u.t, les opérations ne peuvent être traitées assez rapidement et la charge des activités planifiées augmente. Par la suite, au temps 584 u.t, les opérations en attente provoquent le décalage de tâches qui auraient dû être lancées et qui ne le sont plus. La charge n’est pas moins importante, elle est lissée dans le temps au-delà de l’horizon concernant les opérations intra-site dont l’étude est ici faite. Il apparaît donc qu’une solution mettant en œuvre deux chariots par site soit préférable pour valider l’ordonnancement. Sur la figure 6, trois cas de configuration d’atelier selon les capacités de transport inter-sites sont étudiés. Pour un nombre de chariot constant fixé à deux, la simulation est initialement effectuée avec deux camions puis avec trois camions et enfin avec quatre camions. Ainsi, il est possible de déterminer quelle configuration d’ateliers distribués permet de mieux absorber l’ordonnancement multi-site dans le cas de la perturbation décrite. L’exécution du plan distribué avec l’outil de simulation permet la génération des profils de flux représentés sur la figure 6. Les flux agrégés prévus initialement par l’ordonnanceur pour les sites de Toulouse (fig.6.a), Paris (fig.6.b) et Bordeaux (fig.6.c) servent de référents pour évaluer les écarts en fonction du nombre de camions. Le cas de deux camions est représenté par les flux agrégés pour les sites Toulouse (fig.6.d), Paris (fig.6.e) et Bordeaux (fig.6.f). L’examen du cas de trois camions et quatre camions sont respectivement présentés pour Toulouse (fig.6.g), Paris (fig.6.h) et Bordeaux (fig.6.i) puis Toulouse (fig.6.j), Paris (fig.6.k) et Bordeaux (fig.6.l). Pour le site de Toulouse (fig.6.a, d, g & j), le niveau des courbes est initialement élevé dans la mesure où de nombreux OF sont planifiés. Jusqu’à 421 u.t, les trois profils sont semblables. Pour (fig.6.d), à la date 421 u.t, le niveau augmente car de nouvelles tâches sont planifiées mais non exécutées. Le site est en attente des livraisons depuis les autres sites. Le profil de (fig.6.d) ne va cesser de se dégrader puisque les retards de livraison vont se cumuler compte tenu du faible nombre de camions. Le niveau de charge de l’atelier attendu par (fig.6.a) à la date 658 u.t ne va être atteint qu’aux alentours de 3769 u.t pour (fig.6.d). La simulation s’achève à la date 6035 u.t pour (fig.6.d) contre 1278 u.t initialement prévues dans le cas (fig.6.a). Pour (fig.6.g & j), à la date 421 u.t, le second camion est en mesure d’approvisionner suffisamment vite les différents sites et d’éviter ainsi un accroissement du niveau. Le profil prévu est alors respecté. Par la suite, (fig.6.g & j) vont évoluer différemment dans le traitement des OF. Le site (fig.6.g) achève la simulation à la date 3119 u.t et (fig.6.j) à la date 3697 u.t. Il apparaît que la présence de deux camions est insuffisante pour gérer tous les transports en même temps. Lorsque la plupart des opérations de production sont placées en début de gamme de fabrication, le cumul des retards à moins de conséquences comme le montre le cas de Paris (fig.6.b, e, h & k). Après initialisation, les trois profils sont identiques jusqu’à la date 220 u.t. Pour (fig.6.e), le niveau monte puis reste constant jusqu’à la date 735 u.t alors que pour (fig.6.h & k), où trois et quatre camions sont présents, la descente s’effectue à la date 350 u.t. Dans le cas de deux camions, la simulation du site (fig.6.e) finit à la date 1225 u.t alors que 420 u.t pour (fig.6.b) étaient initialement prévues. Les simulations des sites (fig.6. h & k) s’achèvent identiquement à la date 550 u.t. Enfin, Les opérations de Bordeaux, (fig.6.c, f, i & l) placées en bout de gamme, vont être le reflet des retards accumulés par l’indisponibilité des moyens de transport. La fin de l’ensemble des opérations prévue à la date 1106 u.t pour (fig.6.c) ne va en réalité s’achever qu’à la date 4399 u.t pour (fig.6.f), 2642 u.t pour (fig.6.i) et 2871 u.t pour (fig.6.l), soit 229 u.t de mieux pour la configuration avec trois camions. L’ordonnancement de ces OF peut être validé pour une configuration optimale avec trois camions et deux chariots. Lors de l’apparition dans le plan de transports intra et inter- sites, la disponibilité du ou des chariots et camions, leur localisation géographique initiale et le sens de rotation imposé sont autant de contraintes et de paramètres non pris en compte lors de l’ordonnancement et qui vont provoquer la dégradation progressive de l’écart temporel entre les flux prévus et suivis pour les trois sites. La présence d’un seul chariot provoque des retards conséquents alors que ces opérations de transports sont minimes en rapport des durées des gammes de fabrication et de transport inter-site. Il semble donc nécessaire de fixer le nombre de chariot à deux, ce qui a été fait avant l’évaluation pour les transports inter-sites. La présence de deux camions afin d’approvisionner les différents sites retarde la livraison des premières pièces avec comme effet de voir de nouvelles tâches planifiées intégrer les flux en modifiant les valeurs des niveaux. Les retards croissant vont entraîner un retard plus ou moins important en fonction du nombre de moyens de transport disponibles. Dans cet exemple, la configuration à quatre camions apparaît moins avantageuse que celle à trois camions. Ceci s’explique du fait que le premier camion disponible choisi par le simulateur n’est pas forcément celui qui se rendra le plus vite sur le site qui a fait une demande de transport. Un camion peut déjà être en route dans la configuration à trois camions et exécutera donc plus rapidement le transport. La qualité de l’ordonnancement pour des ateliers distribués dépend, dans notre exemple, de l’organisation des transports. D’autres configurations de transports (nombre de chariots et de camions) ont été simulées mais l’amélioration de la configuration est peu significative. De la même façon, il est possible d’effectuer plusieurs tests en faisant varier le nombre de machines dans les ateliers afin d’adapter la configuration du réseau de sites distribués pour un plan établi. L’outil de simulation distribuée d’ateliers virtuels proposé permet donc de valider un ordonnancement multi-site et d’adapter les ressources afin de correspondre au mieux au plan défini. Figure 6. Profils de flux agrégés prévus pour (a) Toulouse, (b) Paris, (c) Bordeaux, suivis avec 2 transports pour (d) Toulouse, (e) Paris, (f) Bordeaux, suivis avec 3 transports pour (g) Toulouse, (h) Paris, (i) Bordeaux et suivis avec 4 transports pour (j) Toulouse, (k) Paris, (l) Bordeaux. V. CONCLUSION Un outil de simulation distribuée capable de garantir la synchronisation et la causalité d’opérations de production lors de l’exécution d’un plan pour un réseau d’ateliers distribués a été présenté. L’outil permet de simuler tout type d’ordonnancement distribué en préservant l’indépendance de chacun des acteurs. Lors du lancement d’un projet, le dimensionnement des ressources liées au transport peut être ainsi facilement évalué. La validation d’ordonnancement multi-site en vue d’adapter la configuration de la chaîne logistique ou d’améliorer le plan est réalisable. La prise en compte de ressources de transport sans contrainte et une taille variable pour les conteneurs de transport sont les prochains objectifs. Les règles d’allocation des moyens de transport vont aussi être modifiées afin de déterminer quel transport peut effectuer la tâche le plus rapidement. Ces évolutions prises en compte doivent permettre de faciliter l’évaluation de l’influence des stratégies de transport sur la faisabilité des plans pour la chaîne logistique. VI. REMERCIEMENTS Nous remercions Lanner Group, partenaire de ce projet sur la simulation distribuée. VII. REFERENCES [1] Archimède B., L. Pun, C. Bérard et G. Doumeingts, 1993. « Flow –profiles and potential graphs based FMS dynamical control ». Control Engineering Practice, 1(1), p. 153-161. [2] Archimède B., P. Charbonnaud et C. Firmin, 2003. « A Supervised Multi-Site Reactive Production Activity Control method for extended enterprise ». Journal of Decision Systems : DSS from theory to practice, 12(3- 4), p. 309-328. [3] Chandy K. M. et J. Misra, 1978. « A nontrivial example of concurrent processing distributed simulation ». Proceedings of IEEE COMPSAC’78, p. 822-826. [4] Coudert T., 2000. « Apport des systèmes multi-agents pour la négociation en ordonnancement: application aux functions production et maintenance ». Thèse de doctorat, Institut National Polytechnique de Toulouse (FR). [5] Enjalbert S., B. Archimède et P. Charbonnaud, 2004. « A HLA federation of reactive production activity control for extended enterprise performance evaluation ». 5th EUROSIM congress on Modelling and Simulation, Paris, France. [6] Gupta M., H.-J. Ko et H. Min, 2002. « TOC-based performance measures and five focusing steps in job- shop manufacturing environment ». International Journal of Production Research, 40(4), p. 907-930. [7] IEEE Computer Society/Simulation « Interoperability Stds, 2000. Standard for Modelling and Simulation (M&S) High Level Architecture (HLA) - Framework and Rules (1516) ». [8] Kubota F., S. Sato et M. Nakano, 1999. « Enterprise modelling and simulation platform integrating manufacturing system design and supply chain ». Proceedings IEEE International Conference on Systems, Man, and Cybernetics, 4, p. 511-515. [9] Lee Y.H., S.H. Kim et C. Moon, 2002. « Production- distribution planning in supply chain using a hybrid approach ». Production Planning & Control, 13(1), p.35-46. [10] Luder A., J. Peschke, T. Sauter, S. Deter et D. Diep, 2004. « Distributed Intelligence for Plant Automation Based on Multi-Agent Systems: The PABADIS Approach ». Production Planning and Control, 15(2), p. 201-212. [11] Mertins K., M. Rabe et F.-W. Jakel, 2005. « Distributed modelling and simulation of supply chains ». International Journal of Computer Integrated Manufacturing, 18(5), p. 342-349. [12] Meyr H., M. Wagner et J. Rhode, 2000. « Concepts of Advanced Planning Systems: Structure. Supply Chain Management and Advancement Planning », Springer, p. 75-77. [13] Smith R. G., 1980. « The Contact Net protocol: high level communication and control in a distributed problem solver ». IEEE Transactions on Computers, 29(12), p. 1104-1113. [14] Stadtler H., 2000. « Basics of Supply Chain Management : an overview ». Supply Chain Management and Advancement Planning, Springer, p. 7-27. [15] Stadtler H. et C. Kilger, 2000. « Supply Chain Management and Advancement Planning », Springer, preface. [16] Turner S.J., W. Cai et B.P. Gan, 2000. « Adapting a supply-chain simulation for HLA ». 4th International Workshop on Distributed Simulation and Real-Time Applications, p. 71-78. Simon Enjalbert est doctorant à l'Ecole Nationale d'Ingénieurs de Tarbes. Il a reçu un diplôme d’ingénieur à Tarbes en 2002 et un DEA à l’Institut National Polytechnique de Toulouse la même année. Il a rejoint le Laboratoire Génie de Production et l'Equipe Production Automatisée de l’ENIT. Son domaine de recherche concerne la modélisation et la conduite des entreprises étendues. Ses travaux de thèse portent sur l’évaluation de la faisabilité d’ordonnancements multi-sites par simulation distribuée d’ateliers. Bernard Archimède est Maître de conférences à l'Ecole Nationale d'Ingénieurs de Tarbes et chercheur au Laboratoire Génie de Production au sein de l'Equipe Production Automatisée. Son domaine de recherche concerne les systèmes distribués et plus particulièrement les aspects architecture, simulation et interopérabilité en vue d’évaluer les performances de systèmes complexes organisés en réseau, de faciliter la prise de décisions lors de leur configuration ou de leur conduite. Philippe Charbonnaud est Professeur à l'Ecole Nationale d'Ingénieurs de Tarbes et chercheur au Laboratoire Génie de Production au sein de l'Equipe Production Automatisée. Son domaine de recherche concerne les systèmes d'aide à la décision temps-réel et plus particulièrement la supervision et l'accommodation de la commande (par reconfiguration ou restructuration) permettant une exploitation sûre des systèmes complexes de grandes dimensions.