S Enjalbert

B Archimède

P Charbonnaud

Feasibility evaluation of multi-site scheduling by distributed simulation of workshops

Keywords: supply chain, multisite scheduling evaluation, distributed simulation

In this article, a distributed simulation tool for the feasibility evaluation of multi-site scheduling is proposed. The application areas concern supply chains or networks of cooperating and distributed workshops. In order to facilitate the modelling of a corporate network, a generic framework is proposed. The distributed simulation of workshops, called virtual workshops, generates various problems of causality and of tasks execution coordination. These problems are addressed in the proposed distributed architecture by the use of HLA protocol guaranteeing the synchronization and the chronology of events. An application to a simple case of supply chain organizing the flow between three workshops shows the effectiveness of the distributed simulation tool.

INTRODUCTION

The Supply Chain (SC) consists of specialized, cooperating and geographically distributed manufacturing units, and poses the problem of its performance evaluation. The principal stakes of SC are organization and management of the production distribution [START_REF] Stadtler | Basics of Supply Chain Management: An Overview[END_REF]. The complexity of these multi-site organizations is studied with specialized tools of production activity control such as ERP (Enterprise Resource Planning) or APS (Advanced Planning System) [START_REF] Stadtler | Supply Chain Management and Advanced Planning[END_REF]; [START_REF] Meyr | Concepts of Advanced Planning Systems: Structure[END_REF]. However, these tools are based on aggregated models of real production systems for the generation of production plans used by partners. The calculated plans cannot be suitable for real situation because of discrepancies between aggregated models and real production sites. To cure this drawback, the evaluation of plans is necessary before the dispatching in workshops. By this way, the feasibility is evaluated and if necessary ensured by the SC reconfiguration.

Various methods were proposed to evaluate the plan feasibility of the distributed workshops. In [START_REF] Lee | Production distribution planning in supply chain using a hybrid approach[END_REF], the analytical resolution rests on a set of mathematical equations representing the SC model considered. However, incomplete modelling of the dynamic characteristics does not provide acceptable solutions for the analyzed system. As described in [START_REF] Luder | Distributed intelligence for plant automation based on multi-agent systems: The PABADIS approach[END_REF]; [START_REF] Gupta | TOC-based performance measures and five focusing steps in job-shop manufacturing environment[END_REF]; [START_REF] Kubota | Enterprise modelling and simulation platform integrating manufacturing system design and supply chain[END_REF], simulation allows the SC evaluation by regarding it as a centralized company. Nevertheless, during the modelling phase, difficulties related to the significant number of entities to be modelled and to the detail level wished by companies, represent the first limits of this approach. Other drawbacks are related to the quantity of events to be simulated, the computing power, the reuse of the simulation models and the intellectual property protection. Finally, the modelling of all SC sites remains possible but simulation done with one processor is not always achievable. A fine evaluation of multi-plan feasibility is difficult to obtain when being based on an aggregated model. For the SC, the feasibility is not reduced to the sum of the evaluations for each site. Taking into account these limits, the evaluation of the multi-site scheduling feasibility requires the definition of distributed simulation architecture.

Companies can be implied in various networks and wish to be able to keep the control of their production activities without being dependent on a network in particular. A first asset in favour of the decentralization is linked to the information protection of each site which can choose to mask certain data at the time of distributed simulation. The actors generally wish to preserve confidential their know-how. The networks studied and modelled thereafter consist of companies sharing their production tools during a limited time, for local activities, with clearly defined aims, while having the guarantee to preserve their autonomy and the confidentiality of their methods. Several works were undertaken on the distributed simulation of large scale production systems. The distributed mod-els are locally built, maintained and joined for evaluation [START_REF] Mertins | Distributed modelling and simulation of supply chains[END_REF]. Moreover, the total performance of the simulation time is improved thanks to distribution [START_REF] Turner | Adapting a supply-chain simulation for HLA[END_REF]. HLA (High Level Architecture) protocol was proposed by the DMSO (Defense Modelling and Simulation Office) to synchronize simulators within a large simulation. HLA facilitates the interoperability and the reuse of simulations to reduce modelling and simulation costs and provides the means for large simulations using geographically distributed components [START_REF] Standards | Standard for Modelling and Simulation High Level Architecture[END_REF]. HLA implements algorithms for synchronization and respect of the chronology for simulated events and in particular those defined in [START_REF] Chandy | A nontrivial example of concurrent processing: Distributed simulation[END_REF]. HLA enables to synchronize a federation, i.e. a set of federates sharing a common model object, the FOM (Federation Object Model), containing all information relating to the simulation execution. A federate is a federation component including a simulator to which an operator, a machine or a complete workshop can be associated. The RTI (Run-time Infrastructure) constitutes a data-processing implementation of the HLA interface specifications and ensures the communications between federates of the same federation by offering the HLA services for the synchronization and the management of the chronology events.

In this article, the definition of the architecture model is presented in Section 2. In Section 3, the principles of distributed simulation are described studying the principal software classes. The tool algorithm and the coordination and synchronization mechanisms of messages and information are detailed. In section 4, a generic modelling framework for corporate network is presented to simulate all kind of organizations. In Section 5, an application to a simple case of a multi-site SC model organizing a flow between three distributed workshops is used to illustrate modelling steps. Finally, the evaluation results of the multi-site scheduling feasibility are discussed.

F-R-PAC model

The PAC model (Production Activity Control) conceptually represents a system for controlling and following-up a workshop. The MO (Manufacturing Orders) are scheduled and distributed within the workshop. The follow-up makes it possible to count of the events to establish a state of the production and of the workshop. In [START_REF] Archimede | A supervised multi-site reactive production activity control method for extended enterprise[END_REF], a MS-R-PAC (Multi-site Reactive PAC) architecture was firstly proposed for geographically distributed workshops simulation. MS-R-PAC coordinates the control of several virtual workshops using a distributed scheduling carried out thanks to a protocol close to Contract Net Smith (1980). The virtual workshop is the data-processing representation of a real workshop. However, synchronization problems can appear in the MS-R-PAC model according to the number of events to be simulated. The causality principle and the respect of the chronology of the events issued of each site cannot be guaranteed when the simulators have different processor speeds. In order to answer these requirements, a new model F-R-PAC (Federation of R-PAC), associating as federate as there are sites, was defined. In Figure 1, a F-R-PAC federation is depicted. The sites can indifferently represent workshops, machines, operators or transportations. A distributed scheduling layer calculates the multi-site planning and sends it to the R-PAC federate by network. The distributed simulation consists of a set of networked R-PAC enabling the execution of any kind of multi-site scheduling by simulation.

Each R-PAC federate is composed by four functions and one encapsulated simulation tool. The Communication ensures the connection between scheduling and R-PAC federate. The Monitoring carries out the follow-up of the production and enables the detection of events linked to the start or the end of operations resulting from virtual workshop. The Synchronization enables coordination between diferent federates of the federation. Finally, the Commanding controls the plan execution and the task dispatching in the simulated workshop. This architecture enables to easily take into account any modification of the corporate network; any change in real workshop requires an adaptation of the corresponding virtual workshop.

F-R-PAC Implementation

In Figure 2, the F-R-PAC federation has been implemented. Each R-PAC federate consists of four managers and one encapsulated simulator. The SAM (Scheduler AMbassador) ensures the communication between the distributed scheduler and the R-PAC federate. The FSM (Flow Shape Manager) carries out the monitoring. The RTIA and FEDA are two ambassadors in the synchronization layer, i.e. entities providing the interface with HLA protocol. Finally the DM (Dispatching Manager), whose algorithm is detailed thereafter, controls the commanding. A HLA Manager denoted RTIG ensures synchronization between all federates.

In Figure 3, a UML class diagram details the principal functions of the distributed simulation in F-R-PAC ar- CShopFederate enables the federate R-PAC to reach HLA mechanisms. CWorkshop represents databases feeding the various classes. It recovers all simulation information and stores them in its databases. CWorkshop requires information on initial scheduling by its connection with COr-doAmbassador. Databases can be accessed by the DM via the CSimulator class in order to supply the simulator with data. It is also linked with CFlowShapeManager to give information on the predicted scheduling to build flow-shape functions. All databases are accessed by CShopFederate in order to take generate or take into account time stamped messages in HLA formalism. CWorkshop makes available simulation information necessary to the federate synchronization.

Scheduler AMbassador

The SAM implements a communication layer between R-PAC federate and the distributed scheduler. It is described in the COrdoAmbassador class and enables to send to the scheduler information on production or transportation detected disturbances. An ES (Executed Schedule) refers to the local plan of the simulator (CPlan) which can be modified if disturbances modify the operations at the time of simulation. SAM listens constantly to the scheduler in order to always receive new schedules. A N S (New Schedule) to execute can be received at any time with two types of tasks which must be considered: the whole of the N T (New Tasks) and the whole of the RT (Remaining Tasks). RT are composed of all the tasks which belonged to preceding executed schedule and which were not removed or were renewed. Following the reception of a new schedule, SAM sends to the DM a N Sevent event to update the Executed Schedule.

Flow Shape Manager

The FSM is implemented in the CFlowShapeManager class and provides mechanisms for checking, at each event occurrence or at the end of a scrutation period, if the running plan execution is correct. A planned flow-shape function for the workshop is generated according to scheduling initially predicted and available in CWorkshop. During simulation, the time stamped data concerning the task execution are processed and a comparison is carried out in order to detect the discrepancies. A flow-shape function is generated from the occurrences of beginning and ending of operation dates. The level represents the sum of the tasks whose dispatching is envisaged in the workshop. A level increase expresses that the total load of the workshop is growing whereas level zero means no task is planned. In practice, the production plan always differs from the effective plan because schedule modelling is based on a simplification of reality. The differences between the predicted and real profiles are analyzed for each event occurrence or for each end of scrutation period in order to evaluate the plan performances. The flow-shape functions of the same workshop are aggregated according to a mechanism described in [START_REF] Archimède | Flow-profiles and potential graphs based FMS dynamical control[END_REF] to reduce detection times.

Federate synchronization and Dispatching Manager algorithm

The DM controls the MO execution in the virtual workshop via a CSimulator class. CSimulator is related to classes allowing the recovery of information on the simulator behavior (CPlan, CBillBook, CTransportationNetwork and CSimbaModel). CPlan represents the plan being executed on simulator. CBillBook realizes a local billbook by mixing events from local plan and from virtual workshop. CBillBook enables coordination and synchronization of events between simulator, local tasks to be dispatched in simulator and events incoming from other fed- The F-R-PAC behavior requires the management of two kinds of synchronization: inter-federate and intra-federate synchronizations. The first one, managed by HLA, rests on a publication/subscription mechanism. During simulation, R-PAC federates cooperate and react to events which are conveyed on the network using time stamped messages. These time stamped messages ensure a regulated and constrained behavior for all federates. Intra-federate synchronization between the DM and the controlled simulator is based on the assignation points to which the simulator must go to be synchronized by the DM algorithm presented in Figure 4.

While simulation is running, the DM requests RTI for a N ER (Next Event Request) dated T 2 where T2 is the minus from logical time clock plus L or D min . clock is the federate logical time, this one can be different for all the federates. D min is the next local event date envisaged corresponding at the lowest of the scheduled dates in the billbook. Some events can occur during simulation. The difficulty is linked to the coexistence of these two synchronization mechanisms. In order to guarantee the good execution of the plan the DM determines the nearest event date according to information received from the simulator and information drawn from its own scheduling. The next assignation to a desired date is fixed by the DM according to local information. This date can be a planned operation or a beginning or ending transportation, or a date corresponding to a waited and delayed event. The DM must ensure that an assignation point is not too distant to guarantee synchronization of the simulator. Then, the federate requires the RTI authorization to advance the simulator to this date (N ER). If the RTI considers that until this date no external event will appear to disturb the federate, then it authorizes the time advance (T AG: Time Advance Grant) of the simulator. On the contrary, if the RTI refuses the desired assignation date advance, a new assignation point on a lower date corresponding to the next external event concerning the federate is proposed. Until the assigned date was reached, several stops and resumes can be necessary. The DM updates the scheduling, transmits time stamped messages on its state to the RTI, and starts a new cycle by proposing a new assignation date. In Figure 5 the effectiveness of the time management and the causality rule implementation is illustrated.

The first synchronization is done at date u expressed in time unit [t.u.]. A CDE (Current Date Event) is sent by the simulator to the DM, corresponding to an appointed assignation date. The federate transmits to the RTI messages concerning the state of objects locally simulated, (U AV : Update Attribute Value). Then, a new time advance towards the next assignation desired date is asked. The time advance request must drive the simulator to date t. The RTI makes sure beforehand no event will be able to interfere before the appointed date t for the federate. When the authorization is granted (TAG) and after having received messages concerning the state of the objects simulated by other federates (RAV : Reflect Attribute Value), the DM transmits information to the controlled simulator which can advance at date t. The mechanism is renewed until the complete simulation of all planned events.

In practice, the inter-federate synchronization mechanism is automated within the pRTI, developed by the Swedish company Pitch. An example of management of time in the case of four federate is presented in the Figure 6.

On this example, the four federates have their position (logical time) symbolized by the red triangular cursor. They are synchronized at time 700 t.u. The four federates have a common lookahead value L equalizes with one. At any time during the execution of the federation, the value L of the lookahead prevents federate from producing an event dated before its own logical time plus the L value. The federate cannot send messages in the past of the others federates. So at each step during simulation, federates are synchronized. The zones shaded beyond time 701 t.u. cannot be reached since the sum of L and their logical time equalizes 701 t.u. The gray rectangle symbolizes the advance of time which was required by the different federates.

Modelling a corporate network

The modelling of a corporate network requires a simulation model for each company like for the transportation system between companies. These models are managed by SIMBA (Simulation Based Applications). SIMBA is an ActiveX which enables the modelling of virtual workshops by integrating the functionalities of simulation in applications thanks to COM OBJECT technology. It makes it possible to exploit by programming models created with WITNESS. In order to facilitate the modelling of the corporate networks three types of generic and skeletal WIT-NESS modules are depicted in Figure 7.

The Station module (Fig. 7.I) enables modelling using WITNESS components (machine, stock, track) according to the level of aggregation, a machine in a site or a site in a corporate network. The Transportation module (Fig. 7.III) makes it possible to use a network of WITNESS tracks to model the transportation logic between the machines in a site or between the sites in a corporate network. It regroups all information relating to the tracks (journey times, number of vehicles being able to circulate at the same time on the same track, etc) and the routing of trucks and carriages. The transportation logic must be defined in a function including for each Station module which track must be used for loading and unloading trucks or carriages in entrance and exit. Finally, The Configuration module (Fig. 7.II) describes the modelled system by defining WIT-NESS vehicles representing of the carriages or the trucks as well as the name and the number of Station modules. They make it possible to establish connection between Transportation module and the Station ones using two WIT-NESS tracks named Entrance and Exit. The Configuration module contains the identification of the sites or machines represented and information which allows trucks and carriages to position geographically and of knowing towards which destination to go. It comprises also information necessary to the initialization of simulators (number of trucks and carriages, initial position in garage tracks, etc). The Entrance track evaluates for each route the first track to be used at beginning in Transportation module. Trucks or carriages are sent to the Exit track of Configuration module at the end of route in order to evaluate which station and which trak (load or unload) is concerned. The modelling of this example of corporate network requires a Configuration module, a Transportation module and as many Station modules than there are sites in the network or machines in the site. The products to manufacture are transported towards the unload area of a Station module (1). The product is disassembled from any container then sent for process queue whereas the truck or carriage is held to the garage (2). Herein they will wait to be called [START_REF] Department | The contract net protocol: High-level communication and control in a distributed problem solver[END_REF]. If one is needed on another station, the Transportation module will ask for at his entrance (7). At the end of process, the product and a carriage are sent on the load area (4) where container can be assembled. The carriage or a truck can now transport the product towards the next destination according to the manufacturing routing (5). At any time, if transportation is needed in the load area and none available in Station garage, carriage can ben send directly from Transporation module (6). Depending on aggregation level, products can be transported between two production sites. At the end of transportation, the product is take into account by the machine represented by it own Station model. At this point, no more product is available to be produced on multi-site Station model. This product must be deleted as represented in (a). For same reason, when process is over, product can be sent from one site to another and product is held from machine station to workshop or site Station. As long as there is no more product on machine station, this one is deleted (a). During simulation initialization, we consider that products and transportations are available directly from the point they will be first needed for process or transportation. (b and c) have been introduced to take into account this possibility.

5 Application to a simple case A simple application illustrating the case of a corporate network cooperating for manufacturing a coffee table is detailed herein. This ovoid table consists of 4 feet, and of higher and lower plates. The 3 MOs necessary to carry out its manufacturing, MO1, MO2 and MO3, are offered at the possible suppliers. Associated routings and durations of each activity are summarized in Table 1. Three sites of production located at Toulouse, Paris and Lyon are selected as partners for this manufacturing project. The site of Toulouse provides basic preparation of the feet as well as plates. The site of Paris prepares turning activities. The site of Lyon is in charge of assembling and painting. Associated machines and activities are described in Table 2. Inter-site transportation durations are defined in Table 3 while intra-site transportation durations are 2 t.u. between each machine. For this manufacturing case, a distributed scheduling was carried out using the software R@mses (Re@ctive Multi-agent System for Scheduling) and is presented in Figure 8.

During this period, road works are in progress on axes connecting the sites and traffic is limited. An arbitrary direction of traffic is then imposed. The course of delivery joins successively the sites of Toulouse, Lyon and Paris before to be back in Toulouse. Initially, only one truck able to transport only one part per way at the same time is considered. Thereafter, when several trucks are available, as soon as an operation requires a transportation, a request is sent to the trucks. The first available one accomplishes transportation. In order to evaluate the feasibility of this multi-site scheduling, several workshop configurations according to transportation capacities are studied. Simulation was initially carried out with one, two and finally three trucks to determine the better configuration of distributed workshops able to take into account the described constraints linked to traffic.

Figure 9 represents a WITNESS model of this network where it is possible to distinguish the three Stations modules (Toulouse, Paris, and Lyon), Transportation module and Configuration module named BaseShop.

The same type of representation will be used for all the levels that we have to simulate. Indeed, it is possible to consider that the simulated machine represents an assembly line or a complete workshop. According to degrees of aggregation, only a partial vision will be given to the user. The interest of this modelling technique rests on the re-use of the models. A routing is carried out to control displacements of the carriages within the simulators. This routing makes it possible to indicate which track trucks or carriages must be used to go from a site to another or from a machine to another. The routing corresponds to the definition of the priority ways to connect the various sites within the models. Transportation times as well as the tracks to be used are defined for the automatic piloting of transportation. It is necessary to take precautions in order to make sure that times of displacement of transportation will be same on the model and scheduling. The step of time of simulation as well as the transportation speed of the model must correspond.

In Figure 10 For the site of Toulouse (a), (d), and (g), until to 85 t.u., the three flow-shapes are similar because no MO is dispatched and no part is coming from Paris. At time 85 t.u., the level of (d) increases because new tasks are planned but not carried out. The site is waiting for the deliveries from Paris. The delivery delays increase and the flow-shape (d) is stretched. The load level of the workshop awaited by (a) at time 120 t.u. is reached only around time 270 t.u. for (d). Simulation is complete at date 840 t.u. for (d) against 305 t.u. as initially predicted for (a). In time 85 t.u., the second and third trucks supply quickly enough the site (g) avoiding a load increase. The level awaited by (a) at time 130 t.u. is reached only at date 180 t.u. for (g) because three trucks resource is not sufficient to carry out all transportation at the same time. When a great number of MO are located at the beginning of routings, the cumulative delays are without any consequences as shown in (b), (e), and (h). After initialization, the three flow-shapes are identical until date 115 t.u.. For (e), the level decreases at time 170 t.u. whereas for (h) this decrease begins only at time 145 t.u.. In the case of a single transportation, the flow-shape for (e) ends at date 330 t.u. against 165 t.u. for (b) as initially predicted. The MOs of Lyon are located at the end of routings. The predicted operations are ended at time 350 t.u. for (c), at time 440 t.u. for (i), and at time 440 t.u. for (f).

As soon as inter-site transportations are required, the truck availability, its geographical localization and the traffic direction are the main constraints not taken into account in the multi-site scheduling. The use of only one truck to supply the various sites introduces a delivery delay. In this manufacturing project, the scheduling quality depends on the transportation organization. The two trucks transportation case was simulated but the resulting improvement is not significant in comparison to the three trucks case. Moreover intra-site transportation have no direct influence on multi-site MO transportation strategy (see pikes of 2 or 4 t.u. in Figure 10.a, c, d, f, g & i) because inter-site transportations generate more important delay. The tool for distributed simulation of virtual workshops enables to evaluate the feasibility of multisite scheduling and to adapt the resources in order to correspond as well as possible to the predicted plan. In this manufacturing project, three inter-site trucks and one intra-site transportation lead to the best result.

Conclusion

A tool for distributed simulation able to guarantee the synchronization and the causality of production operations for a distributed workshop network was presented. The simulation tool deals with any kind of distributed scheduling by preserving the independence of each partner. The dimensioning of transportation resources can be evaluated when a manufacturing project is dispatched. By this way, the feasibility evaluation of multi-site scheduling enables the adaptation of the supply chain configuration or the improvement of the plan. A generic modelling framework has been presented to enable the simulation of all kind of corporate network. Next objectives will concern the performances evaluation of F-R-PAC model and HLA protocol, implemented by RTI, on a simulation benchmark.

Figure 1 :

 1 Figure 1: F-R-PAC federation model.

Figure 2 :

 2 Figure 2: F-R-PAC federation implementation.

Figure 3 :

 3 Figure 3: UML class diagram of F-R-PAC.

Figure 4 :

 4 Figure 4: Dispatching Manager principal algorithm.

Figure 5 :

 5 Figure 5: Communications within a R-PAC federate.

Figure 6 :

 6 Figure 6: Time management with pRTI for inter-federate synchronization.

Figure 7 :

 7 Figure 7: Connexion mechanism between generic modules (Station (I),Configuration (II) and Transportation (III)).

Figure 9 :

 9 Figure 9: Network of enterprises modelisation on SIMBA for F-R-PAC.

  , the flow-shapes resulting from scheduling and simulations are represented. The aggregated flowshape functions scheduled for the sites (a) Toulouse, (b) Paris, and (c) Lyon are used as input data for simulation. The first simulation was done with one transportation resource. Results are represented in Figure 10 by flow-shapes of the sites (d) Toulouse, (e) Paris, and (f) Lyon. After several simulations, finally the case of three trucks is presented for the sites (g) Toulouse, (h) Paris, and (i) Lyon.

Figure 10 :

 10 Figure 10: Aggregated flow-shape predicted for (a) Toulouse, (b) Paris, and (c) Lyon, followed with one transportation for (d) Toulouse, (e) Paris, and (f) Lyon, and followed with three transportations for (g) Toulouse, (h) Paris, and (i) Lyon.

Table 1 :

 1 Routings.

	MO	Activity	Duration
	MO1	Turning	36 t.u.
		Milling	33 t.u.
		Fettling	48 t.u.
		Drilling	48 t.u.
		Fettling	48 t.u.
		Assembling	30 t.u.
	MO2	Turning	33 t.u.
		Milling	36 t.u.
		Fettling	28 t.u.
		Turning	18 t.u.
		Assembling	24 t.u.
		Painting	33 t.u.
		Assembling	26 t.u.
	MO3	Turning	30 t.u.
		Drilling	36 t.u.
		Turning	24 t.u.
		Painting	30 t.u.
		Assembling	24 t.u.
		Painting	42 t.u.
		Fettling	22 t.u.

Table 2 :

 2 Machines and activities.

	Location Machine	Activity
	Toulouse	M1	Milling
		M2	Drilling
		M3	Fettling
	Paris	M1	Turning
		M2	Turning
	Lyon	M1	Assembling
		M2	Painting

Table 3 :

 3 Inter-site transportation durations.

	From/To Toulouse Paris	Lyon
	Toulouse	-	24 t.u. 30 t.u.
	Paris	24 t.u.	-	18 t.u.
	Lyon	30 t.u.	18 t.u.	-

Acknowledgment

The authors thank Lanner group for its partnership in this project on distributed simulation. WITNESS and SIMBA are trademarks of Lanner group.


S Enjalbert Ab

B Archimede

P Charbonnaud
email: philippe.charbonnaud@enit.fr

Distributed simulation of virtual workshops for the multi-site scheduling feasibility evaluation

Keywords: Supply Chain, multi-site scheduling, distributed simulation, High Level Architecture

HAL is

Introduction

The Supply Chain (SC) consists of specialized, cooperating and geographically distributed manufacturing units, and poses the problem of its performance evaluation. The principal stakes of SC are organization and management of the production distribution [START_REF] Stadtler | Supply chain managementan overview. Supply chain management and advanced planning[END_REF]. The complexity of these multi-site organizations is studied with specialized tools of production activity control such as ERP (Enterprise Resource Planning) or APS (Advanced Planning System) [START_REF] Stadtler | Supply chain management and advanced planning-basics, overview and challenges[END_REF], [START_REF] Meyr | Structure of advanced planning systems[END_REF]. However, these tools are based on aggregated models of real production systems for the generation of production plans used by each enterprise of the network. The calculated plans cannot be suitable for real situation because of discrepancies between aggregated models and real production sites. To cure this drawback, the evaluation of plans is necessary before their dispatching in workshops. By this way, the feasibility is evaluated and if necessary ensured by the SC reconfiguration. Various methods have been proposed to evaluate the plan feasibility of the distributed workshops. In [START_REF] Lee | Production-distribution planning in supply chain using a hybrid approach[END_REF], the analytical resolution is based on a set of mathematical equations representing the considered SC model. However, incomplete modelling of the dynamic characteristics does not provide acceptable solutions for the analyzed system. As described in [START_REF] Lüder | Distributed intelligence for plant automation based on multi-agent systems: the PABADIS approach[END_REF], [START_REF] Gupta | TOC-based performance measures and five focusing steps in a job-shop manufacturing environment[END_REF] and [START_REF] Kubota | Enterprise modeling and simulation platform integratingmanufacturing system design and supply chain[END_REF], simulation allows the SC evaluation by regarding it as a centralized company. Nevertheless, during the modelling phase, difficulties related to the significant number of entities to be modelled and to the detail level wished by companies, represent the first limits of this approach. Other drawbacks are related to the quantity of events to be simulated, the computing power, the reuse of the simulation models and the intellectual property protection. Finally, if the modelling of all SC sites remains possible, the simulation execution with one processor is not always achievable. A fine evaluation of multi-plan feasibility is difficult to obtain when being based on an aggregated model. For the SC, the feasibility is not reduced to the sum of the feasibility evaluations of each site. Taking into account these limits, the feasibility evaluation of the multi-site scheduling requires the definition of distributed simulation architecture. Several works were published on the distributed simulation of large scale production systems. A first asset in favour of the decentralization is linked to the information protection of each site which can choose to mask certain data at the time of distributed simulation. The distributed models are locally built, maintained and joined for evaluation [START_REF] Mertins | Distributed modelling and simulation of supply chains[END_REF]. Moreover, the total performance of the simulation time is improved thanks to distribution [START_REF] Turner | Adapting a supply-chain simulation for HLA[END_REF]. HLA (High Level Architecture) protocol was proposed by the DMSO (Defense Modelling and Simulation Office) to synchronize simulators within a large simulation. HLA facilitates the interoperability and the reuse of simulations to reduce modelling and simulation costs and provides the means for large simulations using geographically distributed components (IEEE-Std.-1516-20002000). HLA implements algorithms for synchronization and respect of the chronology for simulated events and in particular those defined in [START_REF] Chandy | A nontrivial example of concurrent processing: Distributed simulation[END_REF]. HLA enables to synchronize a federation, i.e. a set of federates sharing a common object model, the FOM (Federation Object Model), containing all information relating to the simulation execution. A federate is a federation component including a simulator to which an operator, a machine or a complete workshop can be associated. The RTI (Run-time Infrastructure) constitutes a data-processing implementation of the HLA interface specifications and ensures the communications between federates of the same federation by offering the HLA services for the synchronization and the management of the chronology events. In this article, the definition of the architecture model is presented in Section 2. In Section 3, the principles of distributed simulation are described studying the principal software classes. The coordination and synchronization mechanisms of messages and information are detailed. In Section 4, an application to a simple case of a multi-site SC model organizing a flow between three distributed workshops is used to illustrate modelling steps. Finally, the evaluation results of the multi-site scheduling feasibility are discussed.

Problem statement 2.1. MS-R-PAC model and its limits

The R-PAC model (Reactive Production Activity Control) conceptually represents a system of controlling and follow-up for a workshop. In this model, the MO (Manufacturing Orders) are scheduled and launched within the workshop as depicted in Figure 1. The follow-up function consists in identifying the events to establish a state of the production and of the production equipment. In [START_REF] Archimede | A supervised multi-site reactive production activity control method for extended enterprise[END_REF], a MS-R-PAC (Multi-site Reactive PAC) model which integrate several R-PAC was proposed to deal with the geographically distributed workshops case. This model (Figure 2) coordinates the control of several virtual workshops using a distributed scheduling carried out thanks to a protocol close to Contract Net [START_REF] Smith | The contract net protocol: High-level communication and control in a distributed problem solver[END_REF]. The virtual workshop is the data-processing representation on a simulator of a real workshop. Distributed scheduling is carried out using SCEP model (Supervisor Customer Producer Environment) by indirect cooperation between the MO, i.e. the set of customers, and the machines agents, i.e. the set of producers [START_REF] Archimède | Robustness evaluation of multisite distributed schedule with perturbed virtual jobshops[END_REF]. The SCEP cooperative mechanism is based on a synchronous approach of negotiation under a Supervisor agent control via a "blackboard" environment. Figure 2 shows connections between four SCEP cores (three servers and one customer). This configuration makes it possible to carry out the cooperation between three distributed sites. To drive virtual workshops, each site control is ensured by the cooperation of one SCEP core and a tasks launching module. For the monitoring, two functions are combined to follow-up and detect all the events during the production activities execution. The generation of distributed scheduling is provided with the negotiation method between four SCEP cores.

A great interest of the MS-R-PAC model is the capacity to identify easily the bad configuration of the sites and the improvement of each site independently ones of the others. The main drawback of this model lies in the inability to absorb on a site the time delay caused by another site without adapting the manufacturing plans. When there is a time delay in one of the sites, it is sent to the SCEP customer. In order to absorb the time delay, all the sites should be directly informed. On the other hand, important causality problems, due to the load and/or the speed of the various simulators, can appear. The causality principle and the respect of the chronology of the events issued of each site cannot be guaranteed. However, synchronization problems can appear in the MS-R-PAC model. Starting from a synchronization point, a simulator processing at each time step numerous events on a high speed processor may need a more important processing time to meet an assignation date than a simulator lower loaded by events which are computed in parallel on a machine with a lower speed processor. As depicted in Figure 3, some foreseen events, overcoming at the due date in the temporal repository of the most loaded with simulator that must start before other foreseen events overcoming at the due date in the temporal repository of the least loaded with simulator, can be observed after these last ones in the repository of a human observer and thus in past of the least loaded with simulator. Indeed, during the execution of the simulation, an overlapping of two successive operations of the same project executed on two different sites can be observed in repository temporal of a human observer while every site respects perfectly the foreseen plan.

F-R-PAC model

In order to satisfy these requirements and to take into account the causality problem, a new model F-R-PAC (Federation of R-PAC) (Figure 4), associating a federate R-PAC on each site, was defined. F-R-PAC is conceived to carry out a multi-site plan of production, resulting from an external scheduler, in a network virtual of production workshop. A federate R-PAC consists of four main functions which are Communication, Monitoring, Commanding and Synchronization. The Commanding function, encapsulates a simulation function of which role is the management of the virtual workshop. Commanding controls the plan execution and the task dispatching in the virtual workshop. Monitoring carries out the follow-up of the production and enables the detection of events linked to the start or the end of operations resulting from the virtual workshop. Communication ensures the connection between the external scheduler and the two functions Commanding and Monitoring. Synchronization defines the linking interfaces with the other sites. F-R-PAC architecture enables to easily take into account any modification of the corporate network; any change in real workshop requires an adaptation of the corresponding virtual workshop. The distributed simulation consists in synchronizing a set of R-PAC enabling the execution of any kind of multi-site scheduling in virtual workshops. The sites can indifferently represent workshops, machines, operators or transportations. A distributed scheduler calculates the multi-site planning and sends it to the R-PAC federates using an adequate communication network protocol.

In Figure 5, the R-PAC federate is a component software which makes it possible to model the sites partners and consists of four managers and one encapsulated simulator: the Dispatching Manager (DM), the Flow Shape Manager (FSM) and the COMmunication Manager (COM) and the SYnchronization Manager (SYM). The DM, whose algorithm was detailed in [START_REF] Enjalbert | A HLA Federation of Reactive Production Activity Control for Extended Enterprise Performance Evaluation[END_REF], controls the plan execution and the task dispatching in the virtual workshop and makes it possible to access via SYM to the functionnalities of HLA by the mean of two Ambassadors RTI A and FED A, i.e. entities providing the interface with HLA. It can encapsulate any discrete events simulator. The FSM carries out the follow-up of the production and enables the detection of events linked to the start or the end of operations resulting from virtual workshop. The COM ensures the connection between the external scheduler and DM or FSM.

F-R-PAC implementation

In Figure 6, a UML class diagram details the principal functions of the distributed simulation in F-R-PAC architecture. There are five principal classes. CSimulator models the DM and encapsulates the controlled simulator. CFlowShopManager carries out the follow-up of the production operations through flow-shape functions. COrdoAmbassador is the class which manages the connection with scheduling. CShopFederate enables the federate synchronization R-PAC to reach HLA mechanisms. CWorkshop represents database feeding the various classes.

Dispatching Manager

The DM controls the MO execution in the virtual workshop. CSimulator is related to classes allowing the recovery of information on the simulator behavior (CPlan, CBill-Book, the DM scheduling and CTransportationNetwork, to facilitate transportations). The CSimbaModel class implements the simulator encapsulation. In this study, the virtual workshop is implemented using SIMBA, an event-driven simulation software of Lanner Group. CSimulator ensures the control of the plan execution in the virtual workshop.

Flow Shape Manager

The FSM is implemented in the CFlowShapeManager class and provides mechanisms for checking, at each event occurrence, if the running plan execution is correct. A flow-shape function for the workshop is generated according to the foreseen scheduling, available in CWorkshop. During simulation, the time stamped data concerning the task execution are processed and a comparison is carried out in order to detect the discrepancies. Figure 7 illustrates a flow-shape function generated from the occurrences of beginning and ending of operation dates. The level represents the sum of the tasks, expressed in minutes, whose dispatching is planned in the workshop. An increasing level expresses that the total load of the workshop is growing whereas level zero means no task is planned.

In practice, the production plan always differs from the effective plan because schedule modelling is based on a simplification of reality. The differences between the foreseen and the followed flow-shape functions are analyzed for each event occurrence in order to evaluate the plan performances. The flow-shape functions of the same workshop are aggregated according to a mechanism described in [START_REF] Archimède | Flow-profiles and potential-graphs based FMS dynamical control[END_REF], reducing detection times.

Communication Manager

The COM manager implements a communication layer between the distributed simulation and the distributed scheduling. The COM is described in the COrdoAmbassador class and enables to send to the scheduler information on production or transportation detected disturbances. Moreover, COM is waiting from the scheduler to receive a new scheduling at any moment. CWorkshop class recovers all simulation information and stores them in its databases. CWorkshop requires information on initial scheduling by its connection with COrdoAmbassador. The time stamped messages are available for the CShopFederate in HLA formalism. In the same way, a database can be accessed by the DM via the CSimulator class in order to supply the simulator with data. Finally, CWorkshop is linked with CFlowShapeManager to give information on the predicted scheduling to build flow-shape functions. CWorkshop makes available simulation information necessary to the federate synchronization.

Federate synchronization manager

The virtual workshops communicate independently of the COM via HLA bus thanks to the CShopFederate class including all HLA information necessary to the federation execution. The F-R-PAC behavior requires the management of two kinds of synchronization: inter-federate and intra-federate synchronizations. The first one, managed by HLA, rests on a publication/subscription mechanism. During simulation, R-PAC federates cooperate and react to events which are conveyed on the network using time stamped messages. These time stamped messages ensure a regulated and constrained behavior for all federates. Intra-federate synchronization between the DM and the controlled simulator is based on the assignation points to which the simulator must go to be synchronized by the DM algorithm. The difficulty rests in these two synchronization mechanisms coexistence. The DM must ensure that an assignation point is not too distant to guarantee synchronization of the simulator. In Figure 8 the effectiveness of the time management and the causality rule implementation is illustrated. In order to guarantee the good execution of the plan the DM determine the nearest event date according to information received from the simulator and information drawn from its own scheduling. The next assignation to a desired date is fixed by the DM according to local information. This date can be a planned operation or a beginning or ending transportation, or a date corresponding to a waited and delayed event. Then, the federate requires the RTI authorization to advance the simulator to this date (NER: Next Event Request). If the RTI considers that until this date no external event will appear to disturb the federate, then it authorizes the time advance (TAG: Time Advance Grant) of the simulator. On the contrary, if the RTI refuses the desired assignation date advance, a new assignation point on a lower date corresponding to the next external event concerning the federate is proposed. Until the assigned date was reached, several stops and resumes can be necessary. The DM updates the scheduling, transmits time stamped messages on its state to the RTI, and starts a new cycle by proposing a new assignation date. In Figure 8, the first synchronization is done at date u expressed in time units. A CDE (Current Date Event) is sent by the simulator to the DM, corresponding to an appointed assignation date. The federate transmits to the RTI messages concerning the state of objects locally simulated, (UAV: Update Attribute Value). Then, a new time advance towards the next assignation desired date is asked. The time advance request must drive the simulator to date t. The RTI makes sure beforehand no event will be able to interfere before the appointed date t for the federate. When the authorization is granted (TAG) and after having received messages concerning the state of the objects simulated by other federates (RAV: Reflect Attribute Value), the DM transmits information to the controlled simulator which can advance at date t. The mechanism is renewed until the complete simulation of all planned events.

Application to a simple supply chain case

A simple application illustrating the case of a corporate network cooperating for manufacturing three products is detailed herein. The three MOs necessary to carry out its manufacturing, MO1, MO2 and MO3, are offered at the possible suppliers. Associated routings and durations of each activity are summarized in Table 1. Three sites of production located at Tarbes, Pau and Lourdes are selected as partners for this manufacturing project. The site of Tarbes provides basic preparation of the feet as well as plates. The site of Pau prepares turning activities. The site of Lourdes is in charge of assembling and painting. Associated machines and activities are described in Table 2. Inter-site transportation durations are defined in Table 3 while intra-site transportation were neglected.

For this example, a distributed scheduling was carried out using the software R@mses (Re@ctive Multi-agent System for Scheduling). Based on model SCEP defined previously, R@mses puts in competition the MO which are negotiated for the sites [START_REF] Archimede | Reactive scheduling using a multi-agent model: the SCEP framework[END_REF]. In Figure 9, a bar chart recapitulates the whole of the MO distributed on the three sites. We note that the first three orders proceed in Pau. Transport is During this period, road works are in progress on axes connecting the sites and traffic is limited. An arbitrary direction of traffic is then imposed. The course of delivery joins successively the sites of Tarbes, Lourdes and Pau before to be back in Tarbes. Initially, only one truck able to transport only one part per way at the same time is considered. Thereafter, when several trucks are available, as soon as an operation requires a transportation, a request is sent to the trucks. The first available one accomplishes transportation. In order to evaluate the feasibility of this multi-site scheduling, several workshop configurations according to transportation capacities are studied. Simulation was initially carried out with one then two trucks to determine the better configuration of distributed workshops able to take into account the described constraints linked to traffic.

In Figure 10 At time 85 min, the level of (d) increases because new tasks are planned but not carried out. The site is waiting for the deliveries from Pau. The delivery delays increase and the flow-shape (d) is stretched. The load level of the workshop awaited by (a) at time 120 min is reached only around time 270 min for (d). Simulation is complete at date 840 min for (d) against 305 min as initially predicted for (a). In time 85 min, the second and third trucks supply quickly enough the site (g) avoiding a load increase. The level awaited by (a) at time 130 min is reached only at date 180 min for (g) because three trucks resource is not sufficient to carry out all transportation at the same time. When a great number of MO are located at the beginning of routings, the cumulative delays are without any consequences as shown in (b), (e), and (h). After initialization, the three flow-shapes are identical until date 115 min. For (e), the level decreases at time 170 min whereas for (h) this decrease begins only at time 145 min. In the case of a single transportation, the flow-shape for (e) ends at date 330 min against 165 min for (b) as initially predicted. The MOs of Lourdes are located at the end of routings. The predicted operations are ended at time 350 min for (c), at time 440 min for (i), and at time 440 min for (f). As soon as inter-site transportations are required, the truck availability, its geographical localization and the traffic direction are the main constraints not taken into account in the multi-site scheduling. The use of only one truck to supply the various sites introduces a delivery delay. In this manufacturing project, the scheduling quality depends on the transportation organization. The two trucks transportation case was simulated but the resulting improvement is not significant in comparison to the three trucks case. The tool for distributed simulation of virtual workshops enables to evaluate the feasibility of multi-site scheduling and to adapt the resources in order to correspond as well as possible to the predicted plan. In this manufacturing project, three inter-site trucks and one intra-site transportation lead to the best result. This example was sized to show the software tool efficiency and the effectiveness of the feasibility evaluation of multi-site scheduling. For an increasing example size, the simulation time remains correct regarding to complexity and to the production volume of studied networks. When supply chain takes into account a large number of partners, a centralized architecture can fail into simulating too many events at the same time whereas the use of the HLA protocol implemented in the software tool guarantees large scale simulations. Moreover, information about each partner is kept private. This method guarantees autonomy and confidentiality among cooperating simulations partners.

Conclusion

A tool for distributed simulation able to guarantee the synchronization and the causality of production operations for a distributed workshop network was presented. The simulation tool deals with any kind of distributed scheduling by preserving the independence of each partner. The dimensioning of transportation resources can be evaluated when a manufacturing project is dispatched. By this way, the feasibility evaluation of multi-site scheduling enables the adaptation of the supply chain configuration or the improvement of the plan. Next objectives will concern the use of transportation resources without constraint and the definition of variable size of transportation containers.

Figure 1 .

 1 Figure 1. R-PAC conceptual model.

Figure 2 .

 2 Figure 2. MS-R-PAC Model.

Figure 3 .

 3 Figure 3. Causality problem example.

Figure 4 .

 4 Figure 4. F-R-PAC federation.

Figure 5 .

 5 Figure 5. R-PAC federate.

Figure 6 .

 6 Figure 6. UML class diagram of F-R-PAC.

Figure 7 .

 7 Figure 7. Flow-shape function between two machines i and j.

Figure 8 .

 8 Figure 8. Communications within a R-PAC federate.

  represented each time that an activity of a MO requires a change of site. The three parts corresponding to the three MO thus are successively transported from Pau towards Tarbes. The activities and transport follow one another thus until the scheduling of all the activities.

Figure 9 .

 9 Figure 9. Gantt chart of the multi-site MO.

  , the flow-shapes resulting from scheduling and simulations are represented. Level are expressed in ten minutes. The aggregated flow-shape functions scheduled for the sites (a) Tarbes, (b) Pau, and (c) Lourdes are used as input data for simulation. The first simulation was done with one transportation resource. Results are represented in Figure 10 by flow-shapes of the sites (d) Tarbes, (e) Pau, and (f) Lourdes. After several simulations, finally the case of three trucks is presented for the sites (g) Tarbes, (h) Pau, and (i) Lourdes. For the site of Tarbes (a), (d), and (g), until to 85 min, the three flow-shapes are similar because no MO is dispatched and no part is coming from Pau.

Figure 10 .

 10 Figure 10. Foreseen aggregated flow profiles for (a) Tarbes, (b) Pau, (c) Lourdes, followed with 1 transport for (d) Tarbes, (e) Pau, (f) Lourdes and followed with 2 transports for (g) Tarbes, (h) Pau, (i) Lourdes.

Table 1 .

 1 Routings.

	MO	Activity	Duration
	MO1	Turning	36 min
		Milling	33 min
		Turning	48 min
		Milling	48 min
		Assembling	48 min
	MO2	Turning	33 min
		Milling	36 min
		Turning	18 min
		Assembling	24 min
	MO3	Turning	30 min
		Milling	36 min
		Turning	24 min
		Milling	24 min
		Assembling	42 min

Table 2 .

 2 Machines and activities.

	Location Machine	Activity
	Tarbes	M1	Milling
		M2	Milling
	Pau	M1	Turning
		M2	Turning
	Lourdes	M1	Assembling

Table 3 .

 3 Inter-site transportation durations.

	From/To Tarbes	Pau	Lourdes
	Tarbes	-	24 min 30 mmin
	Pau	24 min	-	18 min
	Lourdes 30 min 18 min	-