Olivier Cardin

Pierre Castagna

HANDLING UNCERTAINTY IN PRODUCTION ACTIVITY CONTROL USING PROACTIVE SIMULATION

Keywords: Simulation, Scheduling, Uncertainty, Production Control, Manufacturing Systems, Proactive, Real-time

Simulation is a powerful tool used for a long time as a help to production systems conception. Proactive simulation is a new approach, enabling a precious help to these systems control. In this paper is presented a control architecture enabling the use of this tool, and the obstacles to an optimised development.

INTRODUCTION

In today's complex manufacturing setting, with multiple lines of products, each requiring many different steps and machines for completion, the decision maker for the manufacturing plant must find a way to successfully manage resources in order to produce products in the most efficient way possible. The decision maker needs to design a production schedule that promotes on-time delivery, and minimizes objectives such as the flow time of a product. Real-word planning and scheduling problems are generally complex, constrained and multi-objective in nature. For short-term production scheduling, alternative methodologies and problem statements with different considerations have been proposed in the literature. Most of these works rely on mathematical programming approaches based on discrete or continuous-time representations. Although these rigorous methods are able to guarantee the optimality of the solution, their applicability is currently restricted to quite small cases due to the inherent combinatorial nature of scheduling problems. To overcome this limitation, a wide variety of heuristic and rule-based procedures have been developed aiming at providing good schedules to large-scale problems in a reasonable time. Recently, there has been a high research interest in evolutionary, metaheuristic and soft computing approaches for solving scheduling problems. The problem of most of these scheduling solutions in the literature is they need a perfect knowledge of all the parameters involved in the computation of the scheduling. A lot of the production systems, taking into account testing operations for example, cannot fit in this category. Indeed, as soon as the recipes of the products can be modified along the production, the result of the scheduling operation is not up-to-date anymore and thus another scheduling operation should be run. Due to the frequency of this event, and due to the complexity of the operation, another solution has to be defined. Moreover, due to the growing complexity of the production systems, the decisional system (Le [START_REF] Moigne | La modélisation des systèmes complexes[END_REF][START_REF] Lenclud | Contribution à la conception d'un système intégré de simulation des systèmes de production[END_REF], which runs the production system, has to take a lot of decisions along the production. To be able to take satisfying decisions, two conditions have to be respected. First, the decisional system must have at his disposal reliable, complete and frequently updated data, giving him a satisfying view of the system. The proposition in this paper is to add a real-time simulation in the control architecture. This simulation plays the role of an observer, rebuilding, thanks to the partial data retrieved from the system, all the data needed to take a decision. Secondly, the decisional system must be able to evaluate the impact of the different options available. As a matter of fact, a decision model has to be made. This model must be at the same time accurate, i.e. the forecasts must be sharp and correspond as much as possible to the system, and quick. Indeed, facing a given situation, the decisional system has a short time to react and make a decision. The complexity of the production systems makes that no satisfying analytical model exists: this paper presents the use of a proactive simulation module as decision model. First, the concept of a real-time simulation observer is developed. Then, the proactive simulation module is described before presenting an application of these principles in last part.

OBSERVING A SYSTEM BY REAL-TIME SIMULATION

Traditionally, simulation is used as a prediction tool.

As a matter of fact, time in simulation runs as fast as possible to try and reduce the simulation time. To achieve this, simulation tools have an engine base on events. The simulator builds an events calendar, ordered list of all the events that can be dated, chronologically sorted. Then it executes the first event of the list and rebuilds the calendar, which has been modified by the event. This working is very fast, as the simulator goes from event date to event date, without considering dates where nothing is supposed to happen. In a real-time simulation, the engine is very different. Indeed, the simulated time is adjusted with the real time (synchronously with the CPU clock).

The main application of real-time simulation is the development of simulation models meant to verify the behaviour of real-time software (Schludermann et al. 2000, Cofer and[START_REF] Darren | Eventtriggered environment for verification of realtime system[END_REF]. In this paper, another utilization of real-time simulation is presented. The decision maker needs to have, in order to be able to make a choice, a complete description of the actual production system state. To do that, a Manufacturing Execution System (MES) is used. "A Manufacturing Execution System (MES) is a dynamic information system that drives effective execution of manufacturing operations. Using current and accurate data, MES guides, triggers, and reports on plant activities as events occur from point of order release into manufacturing to point of product delivery into finished goods" according to Manufacturing Enterprise Solutions Association International (MESA). MES is the central source for current information on the manufacturing floor. These data are delivered by means of sensors to be placed on the production floor. The problem is that the MES is not able to give us all the state of the system, at any time, because of the limited number of sensors. So, a real-time simulator will be used as an observer of the physical system. The application will reproduce the behaviour of the production system. Thus, the whole state of the system will be known through the state of the simulator. Of course, it will be necessary to insure equivalence between the evolution of the model and the evolution of the system. To achieve this, the simulator will automatically track the physical system thanks to the data coming from the system through the MES. The MES knows the state of the physical system through the state change of a set of sensors. The link between the MES and the simulator enables the achievement of a tracking each time the MES detects a new event. Two possibilities may appear. On the first one, the simulator is ahead of the physical system. In this case, the simulator has to wait the event coming from the MES. It means the simulation model must be aware of all the situations where a synchronisation has to be done. The model evolves until reaching such a situation, and locally waits for this data. The evolution of this part of the model will only keep going when the data will be sent by the MES, whereas the rest of the model keeps on going normally. On the second possibility, the data come from the MES before the model reaches the synchronisation point. At this point, a local time acceleration in order to bring the simulator in a state conformed to the physical system is used. As an illustration, let's take a conveyor and two sensors s1 and s2 (Fig. 1).

On the simulation, a transporter (1) is in front of sensor s1, whereas the real one is not arrived yet. This is the first case previously described. The simulator will then block the transporter in that position until the real sensor s1 detects the real transporter (1). On the opposite, the real transporter (2) is in front of sensor s2 whereas the simulator displays (2) far before sensor s2. The real system is ahead the simulator. The tracking will instantaneously put simulated transporter (2) in position (2b). Obviously, each time the system is known by the MES, there will be no difference between the behaviour of the simulation and the behaviour of the physical system. However, between the two sensors, the position of the transporters is totally unknown. s 1

Physical system

Simulated system

(1)

s 2 s 1 s 2 (1) (2) (2b) (2)
Fig.

Tracking example

The simulation is then used to know this position by simulating the moving of the transporters. Let's note that, because of the use of two interlocked simulations, this work is set in the concept of reflective simulation [START_REF] Kindler | Tentative de simulation réflective des systèmes de production et logistiques[END_REF].

USING THE PROACTIVE SIMULATION

Flow simulation is widely used to study production system. For a long time, it was only used in the conception or re-conception phase of the production system. In [START_REF] Castagna | Apport de la simulation comme outil d'aide au pilotage des systèmes de production -exemples d'application[END_REF], it was proposed to use simulation as a Decision Helping Tool, with the example of a production unit of the aeronautic industry.

In [START_REF] Pujo | Pilotage proactif des lignes de production kanban par modélisation DEVS et simulation temps réel[END_REF], simulation was used inside the Production Activity Control of a unit organised with KANBAN. It is shown that, thanks to proactive simulation, "the production manager […] can lean on forecasts, simulated from structural data of the workshop synoptic, and a model representing the running production considering the actual state of the workshop, permanently updated with the events, planned or contingent, which happen".

To develop proactive simulation on commercial software, two main problems may appear: the duration of the simulation and its initialisation.

The duration of a proactive simulation

Frequently, simulation of an industrial problem is several hours long. In a conception phase, this has no impact on the pertinence of its use. For a proactive simulation, this duration is totally unacceptable. The decisional system has a very short time to make its decision, and the simulation is included in this time as a part of the data retrieval. Let's consider:  D T Total duration available for the decisional system to make its decision,  D C Duration needed for the retrieval of the data needed for the simulation  D S Total duration of the simulation,  D D Decision-taking time, simulation results being known. The following relationship must be respected.

D C +D S + D D ≤ D T
In the D S time, several simulations can be run, each one corresponding to a different scenario to be tested. In each scenario, the decision maker applies a different decision, which obviously leads to a different events series. If the model is deterministic, and the run of a simulation is D u long, then D S = N D u will be needed to test N possible scenario. Furthermore, if the model takes into account stochastic events and that M replications are necessary to increase the confidence interval, then the duration of the simulations will be:

D S = N M D u
All along the model building, a particular care will be brought to the running duration. Fortunately, the simulation horizon needed for decision taking is frequently relatively short.

The initialisation of a proactive simulation

Most of the simulation tools consider the production system empty at initial state. Thus, there is a time at the beginning of each replication devoted to a progressive loading of the production system. If this is not representative of the working of the system, it must be removed. In a proactive simulation, the initial state must be the exact one of the production system. The model has to be brought to this non-empty state starting from an empty system and following a track that will lead it to the correct initial state. This may quickly become very tricky. The idea in this work is to configure the simulator directly in the correct initial state. But, the data retrieval is still a problem. This retrieval has to be quick to decrease D C . As seen previously, the MES does not have all the data required by the simulator for its initialisation. For example, the model needs the exact position of all the transporters all along the system. A communication link is thus settled with the observer (i.e. the real-time simulation) in order to complete the data brought by the MES: to the production data provided by the MES are added simulated data provided by the observer. In the next section these concepts are developed on an assembly line.

APPLICATION ON A COMPLEX MANUFACTURING SYSTEM

The assembly line was built for educational and research purposes by the Institut Universitaire de Technologie of Nantes (Fig. 2). This job shop production system is made of six workstations. The goods are transported with pallets, which move on unidirectional conveyors. The pallets will be called transporters".

Fig. 2. The job-shop production system

A transporter storehouse (an accumulation conveyor) enables the storage of the free transporters. The working of the line is based on the concept of "Intelligent Product" [START_REF] Wong | The Intelligent Product Driven Supply Chain[END_REF]. The 42 transporters are equipped with smart tags. These tags enable an Auto-Identification when in front of a tag reader. The data contained on the tag are part of the decision making process. As lots of decisions are made at a local scale, the global behaviour of the line is hard to model. Indeed, if, for example, the product needs to go on stations 4, 6 and 3 (in this order) to perform the operations required, the transporter moves on the main loop until reaching the entrance of the work station 4 (Fig. 3).

Fig. 3. The job-shop production system

At this point, a local decision is taken, making the transporter enter (or not) the station. This decision depends on a lot of parameters (number of transporters in the station batch, breakdowns of the station etc.). Furthermore, the recipe of the product is an ordered list of operations, not a list of stations. As a matter of fact, it is frequent that two stations perform the same operation. Thus, the entrance rule may become a lot more complicated if, for example, the pilot chooses to let one transporter out of two come in to balance the load of the stations. Similarly, stations 2 and 6 may not have a FIFO priority rule. Indeed, the configuration of the batches makes it possible to use dynamic scheduling methods as list algorithms [START_REF] Kim | A backward approach in list scheduling algorithms for multi-machine tardiness problems[END_REF] or more complicated rules as "Clear a Fraction" for example [START_REF] Kumar | Dynamic Instabilities and Stabilization Methods in Distributed Real Time Scheduling of Manufacturing Systems[END_REF]). Finally, it is possible to take into account test operations. If the test is passed, the product goes on, but if it is not, the recipe of the product is modified to either treat the defective goods or rework it. All these properties make this example particularly adapted to the subject of this work, as the line is almost impossible to model analytically.

THE CONTROL ARCHITECTURE

The Human Machine Interface in the control architecture is made with a supervisor, part of the Manufacturing Execution System with a database. An OPC server is settled as an intermediate between the Programmable Logic Controllers and the MES (Fig. 4). OPC (OLE for Process Control) is a communication standard based on OLE/COM technology (Object Linking and Embedding/Component Object Model), which constitutes a unified mean of data exchanges between software. It offers a great interoperability (read/write) between the industrial equipments (PLC, sensors etc.), all the monitoring/control/supervision software and the office management software. It also defines standard objects, methods and properties based on COM concept to enable real-time data servers (as PLC) to transfer the data to client OPC applications. The server handles the refresh of the data. Its rate may be different according to the technology, in particular the communication protocols.

Fig. 4. The control system

In this case, the OPC server is used as a common platform of communication between any application and the PLC. This enables the insertion of as many elements in the architecture as wanted without disturbing the other ones. Indeed, both of the simulation applications have to be linked to this architecture. As the system must be able to run without the simulation help, these applications are aggregated in a single module (Fig. 4). The module may be set for two different workings: automatic or manual. Next sections will describe these two modes.

Manual working

To illustrate this working, let's take the example of a major failure of station 1 of the assembly line. The pilot expertise says it is necessary to re-organize the workshop. All the five operations performed on the station have to be reassigned to other stations. At this point, the use of proactive simulation can be broken down into 7 steps:

1. The pilot launches the simulation module (Present Time = P T ). The actual state of the system is saved. 2. He sets the total decision time D T and the simulation horizon.

3. He enters one of the new possible sets of operations performed on the stations corresponding to one of the possible scenario. 4. The simulation is launched. It is initialised from the state saved in step 1. The production keeps going on without any change until simulated time P T +D T is reached, and then the changes are made on the operations. 5. Once the simulation is over, either a new replication of the same scenario is launched or a new scenario is tested (step 3). 6. All the results are saved in a separate file. The pilot can make a decision, based on the analysis of all these results. 7. At real time P T +D T , the decision is applied on the production system. The pilot can analyse the results with the same methods as those used in the usual post-production analysis. Indeed, the simulation gives the same kind of results than the real production, which makes this analysis easier. Obviously, this working is very flexible and enables lots of possibilities. The crucial point here is once more the time question, since a lot of replications could be necessary (several hundreds in some cases). Hopefully, the poor programming complexity allows a fast evolution of the proactive simulation.

Automatic working

In automatic working, the simulation must be transparent to the user. As two different simulations cannot be run on the same CPU, a separate dedicated computer may be useful. As soon as the automatic simulation module is turned on, the behaviour of the line changes. An application of this feature is described in [START_REF] Cardin | Defining A Command Architecture Enabling Proactive Simulations On A Complex Manufacturing System[END_REF], enabling the use of the "Clear a Fraction" rule with a proactive sight to decrease the number of settings. In this mode, the decision of performing a simulation is taken without any action of the pilot. In a given configuration, a local decision module asks for a simulation result. The information is transmitted to the simulation module through the OPC server. Eight steps can describe the working of the module: 1. When the event is generated (Present Time=P T ), the actual state of the system is saved. 2. The total decision time D T and the simulation horizon are automatically calculated by the module. 3. The model corresponding to the question asked is launched (each different type of question has an own model). 4. The parameters of the simulation are set. 5. The simulation is launched. It is initialised from the state saved in step 1. The production keeps going on without any change until simulated time P T +D T is reached, and then the changes are made.

6. Once the simulation is over, either a new replication of the same scenario is launched or a new scenario is tested (step 3). 7. The module analyse the results (the decisions procedure are decided during the building of the architecture and may be different in each application). 8. At real time P T +D T , a VBA procedure directly modifies the affected PLC variables thanks to the OPC server. Obviously, this working is not flexible, as everything must be programmed before its use on the production system, but the absence of interaction with the human operator makes the execution time (and thus the Decision Time) a lot shorter. As a matter of fact, this is meant to be applied to decisions that have to be made in a few seconds. Indeed, the decisions can be made on criteria as much complicated as wanted, if the decision protocol is correctly defined and based on a good expertise.

Results

On a temporal point of view, some tests were made to evaluate the time needed for each step to be completed in automatic working. The same tests cannot be significant in manual working as it mostly depends on the time the pilot needs to make his decision, which fluctuates widely according to the problem posed. If steps 1 and 2 (backup of the actual state), 3, 4 and 5 (initialisation of the simulation) all together are 1 second long (D C ), step 6 corresponding to the simulation itself is about 3 seconds long (D S ). As the analysis of the results and the time needed to apply the decision is about 1 second long (D D ), a whole simulation lasts less than 5 seconds (D T ). This result is fully satisfying as it is compatible with an online use. Of course, this solution may be adapted if the production rate is too high. Then, tests were made to estimate the impact on the production of the solution presented here. The results are shown on Table 1. The problematic of this test was to decrease the number of setups of workstation 6. Indeed, this station represents a painting station, and changing the operation means changing the trajectories of the robot and the colour of the painting. As a matter of fact, paint is lost at each setup. The Clear-a-Fraction rule was implemented in this aim, but better performances are required. The results show a falloff of the number of setups thanks to Proactive Simulation (-32%): this result confirms the impact of the new architecture on the real system. Furthermore, the makespan remains globally constant. As proactive simulation is implemented on a single work station (work station 6), its productivity is modified (in this case, it is increased). But the previous station in the recipe is not able to supply enough products to work station 6. Similarly, the next station in the recipe is not able to deal with all the products coming from station 6, thus it slows the production down. This is why the gap between the production with and without simulation is so small (about 1%).

CONCLUSION

This study shows how much simulation can be included in a proactive approach of the Production Activity Control of a manufacturing system with uncertainties. It can be as well used for global scheduling of the workshop activity, or on a very local point of view, improve the behaviour of the system.

As a matter of fact, proactive simulation is:

-Either a data complement given to the pilot of the line in order to be able to take the best decision or a possibility to control the line taking into account what is going to happen next. All the elements needed to use proactive simulation are meant to be aggregated in a single module (containing several computers linked by an Ethernet network), which can be plugged in or out without stopping the system working. In this module, two main elements may appear: the real-time simulation and the proactive simulation. The real-time simulation model is close to a classical simulation model (except for the communications with the other elements of the architecture), and thus this is possible for an operator well versed in flow simulation to build it. Each time a new type of proactive simulation is required, a new model has to be made. This model is only a modification of the original model, but a large set of strict rules has to be respected. As a matter of fact, an expert in simulation is required at the time being. A future development of this work is planned about the definition of libraries useful in the proactive simulation models building to make this easier. Another land to explore is the definition of the decisional system. Indeed, in an automatic working, it takes several decisions autonomously. Thus it needs a decision algorithm based on the expertise of the pilot of the line. This algorithm still needs to be elaborated.

Table 1

 1 Comparison between workings with and without proactive simulation

		Architecture without Simulation Proactive	Architecture Simulation with Proactive	Gap
	Number of setups	159	109	-32%
	Makespan (seconds)	41 686	41239	-1%


Olivier Cardin
email: olivier.cardin@irccyn.ec-nantes.fr

Pierre Castagna
email: pierre.castagna@univ-nantes.fr

Etienne Chove
email: etienne.chove@irccyn.ec-nantes.fr

Contribution of simulation in the product-driven systems production activity control

While promoting the emergence of product driven production activity control concept, the development of RFID technologies had many benefits on numerous elements of the Supply Chain. Indeed, product driven systems enable a great flexibility by decentralizing the decision centres. However, this decentralization does not allow any more to have a global vision, generally necessary for the system's production activity control. We suggest in this article to use simulation to obtain this global vision, in preparation for providing behaviour prevision functions.

INTRODUCTION

Today, agility in supply chain requires a quick response to the changes, not only in the quantity but also in the kinds of products, without losing the productivity. To achieve this challenge, the structure of control for production facilities is radically changing. One of the trends in production control consists in improving existing manufacturing production planning and control systems. We gradually slip from a predictive control to a reactive control. Product-driven control in manufacturing system falls under this evolution.

For a long time, the planning and scheduling functions made it possible to foresee the dates of realization of each production activity. Then, the person in charge of production had, with much of difficulties, to carry out that pre-established planning. This way of making was very rigid because the decisions were global and frozen. It was very difficult to react to uncertainties and risks.

Conversely, product-driven control does not need the realization of a scheduling. The product circulates in the production system and seeks itself for the resources able to carry on its recipe [START_REF] Pétin | Supervisory synthesis for product-driven automation and its application to a flexible assembly cell[END_REF]. This new way of control was made possible thanks to two significant evolutions.

The first one consists in the emergence of distributed, intelligent control systems [START_REF] Trentesaux | Pilotage hétérarchique des systèmes de production[END_REF]. Classical centralized and hierarchical approaches based on time or constraints aggregation show limitations to solve the manufacturing control problem, particularly when the system faces numerous random events. Mass customisation, small volume and/or high variety order management require new approaches. These approaches support the use of cooperative and autonomous units, self-organised in an open structure to offer a very high operational and structural level of flexibility. It implies the use of distributed artificial intelligence (Multi-Agent Systems, MAS) to be implemented.

Besides, advances in automatic identification, in particular radio-frequency identification (RFID), enable to associate some easily accessible data to a product [START_REF] Cea | Ambient Services for Smart Objects in the Supply Chain Based on RFID and UPnP Technology[END_REF]. Using RFID tags, the product might become an informationstoring and processing item [START_REF] Mcfarlane | Auto-ID's three R's: Rules and Recipes for product Requirements[END_REF].

In chapter 2, we will deal with the decision-making in the context of a product-driven system, noticing there still exists a need for global decisions in a local decisions context. Chapter 3 presents the solution we studied to extend the vision a decision centre can have on a product-driven system. The conclusion of this chapter presents the observer concept, used in chapter 4 for the prevision of the future behaviour of the system. Finally, last chapter presents an application on Quest of all these concepts on an industrial system.

DECISIONS IN A PRODUCT-DRIVEN SYSTEM

Due to its distributed intelligence, product-driven control replaces predictive decisions by reactive and local ones. We could think that global decisions disappeared. It is not true. Indeed, at the root of the concept of supply chain, there is a necessary global vision of the industrial system. A major goal of the supply chain is to "improve the flow of material between suppliers and customers at the highest speed" [START_REF] Proth | Scheduling: New Trends in Industrial Environment[END_REF]. This goal suggests making global management decisions, which are not removed by product-driven control. In addition, the local decisions sometimes require the knowledge of the global behaviour of the system.

In a product-driven control system, the product utilizes decision rules. To make its decision, the product applies these rules to its parameters to know what has to be chosen. But in the majority of the situations, the product is not the only actor of the decision-making. The decision is made by both the product and the production line decision centre. Let us present the example of a ranking criterion in a queue. A product arriving in a queue has to decide its rank in this queue. From its parameters (Due date, priority...), it applies a ranking criterion (SPT, EDD, CR/SPT...) to know its position in the queue. But it is the decision-making centre of the production system that chooses the ranking criterion which has to be used by the product. Thus, the decision is made on two hierarchical levels.

In the problem solving procedure, a decision centre has a set of given alternatives and is aware of the consequences of each. In a general way, a decision requires two conditions. First, it is necessary to know the whole parameters influencing the decision-making. Then, the decision maker must have a forecasting tool allowing him to foresee, in the future, the consequences of his decision.

To make these global decisions, the managers need to have a global vision of the production system behaviour.

The problem, in product-driven systems, is that the global behaviour results from the whole local decisions which will be made in real time. It is thus very difficult for the manager to know the current state of his production system (Vision) and foresee its future evolution (Prevision).

VISION

Our first objective was to determine an efficient way of extending the vision that can be obtained on a product driven production system. We chose to examine three main possibilities to achieve this goal. The following paragraphs present these possibilities. Their conclusions deal with their applicability conditions.

Data directly coming from the production system

First solution we studied was to obtain the data directly from the production system, through the floor control, the MES, or higher components of the control architecture such as the ERP or the APS (Fig. 1).

This solution provides obvious advantages: the data obtained are reliable, and represent the actual present state of the system. Furthermore, it only requires a minimal additional architecture to work properly.

The most important component of this data collection is the performance of the sensors settled on the system. Some of them are able to report continuously the evolution of a variable: a temperature sensor may for example give the continuous conditions inside an oven. However, in general, a lot of data are not measured in this way. Let us consider for example the position of an Automated Guided Vehicle (AGV) inside a workshop. Sensors settled at certain points of the network (intersections, work stations, etc.) are sufficient to drive the fleet. The remaining problem is that the use of such devices creates a great uncertainty. Indeed, when an AGV faces a sensor, it is possible to know its position at the current date. As soon as it moves between two of these sensors, its position is totally unknown (except for the information that it is situated on the track between the sensors), and its arrival date in front of the next sensor is unknown a priori. It is therefore not possible to have the whole fleet of AGV in front of sensors of the system each time the information of their location is needed. As a matter of fact, the ground control, the MES, etc. only have a partial view of the system's state: this is what we defined as the space and time uncertainties in [START_REF] Cardin | Handling uncertainty in production activity control[END_REF].

In this work, we chose to use the only sensors strictly necessary to the ground control. To explain this, let us consider again the previous example. The use of a GPS module, or a video camera coupled with an image analyser is possible to solve the problem of positioning of AGVs in a workshop. But, this type of solution is quickly expensive as it would generally be necessary to add several of these technologies to know the complete set of data needed to build the entire state of the complete system.

The conclusion we drew of the use of this solution is that it is not applicable in the general case as many data, essential in the definition of the state, are missing or unavailable through the sensors settled on the system. However, it could be recommended in the rare cases enabling its optimal use, as the data is particularly reliable considering the relative simplicity of the setup. We may cite as a good example of application field the Air Traffic Control [START_REF] Rogers | On-line simulation for real-time scheduling of manufacturing systems[END_REF], where position, flight plan and current trajectory of each aircraft are perfectly known at any time.

Using a simulator

For the last few years, most of the simulation software editors provide "real-time" editions of their tools. These tools have the specificity to run at the same speed as the wall clock, in opposition to classical software in which the simulation engines run as fast as possible. They were developed in order to meet the industrial requirements to be able to use simulation as an emulation of the production systems. The initial idea was to reduce the setup time of complex production systems by making tests of the control system directly on this emulation, without waiting for the existence of the physical system.

Our idea here was to use such a simulation running in parallel with the production. This simulator is meant to react to production solicitations coming from the higher layers of the control architecture (MES, APS, etc.), in the same way the real system does. Doing so, it creates a permanent "image" of the system, which state can be considered as being the state of the real system at any time (Fig. 2). This solution has two main advantages compared to the exclusive use of data directly coming from the production system. First, it suppresses the space and time uncertainties problem that we defined in the previous section. About the example of the movement of an AGV previously presented, the simulator enables to know its current position at any time for example. Furthermore, the state gathered with this method is well formatted for a later computer treatment. Indeed, gathering the state is not useful if it is not possible to treat the data in an effective way. On the other hand, there are several problems in the application of this solution. First, the initialisation of this simulator must be done with a perfectly known state. Typically, this state is chosen "idle and empty" because it is the easiest state to express by hand. Secondly, inaccuracies in the system's model and possible hazards inevitably occurring along the production cause a deflection on the final results. The additive aspect of this deviation along time would end up having an effect far from being negligible.

To guarantee the applicability of this solution on a given production system, several constraints have to be set. First, the simulator has to be extremely reliable to limit the effects of modelling inaccuracies. Then, it is preferable to deal with systems which regularly go back to a known state (generally the idle and empty state mentioned before). Let us cite as a classical example the systems that are empty at the end of each working day. It is possible on such systems to restart the simulation, and by doing so, reset the deviation. Finally, the system shall have a low hazard occurrence frequency relatively to the length of simulation without reset. Indeed, these hazards are not taken into account into such a model, and are thus directly deviating the results.

As we can see, the class of systems that may be considered is relatively limited due to the inevitable growing deviation of the results. On the other hand, this is a credible alternative for applications that cannot afford the equipments necessary to the previous solution and which do not need a high precision on the results.

Using an observer

The conclusion we drew at this point was that both solutions previously presented turned to be well adapted to a limited class of systems. As we wanted to make a solution applicable to the widest class possible, we had the idea to hybridize these solutions. By making so, we thought we could get the advantages of the simulator (about the data availability) and of the direct use of real system's data (about the data reliability).

The Fig. 3 presents the principles of such a solution.

Compared to the previous solution, the simulator is replaced by an observer, meant to deal with the data coming from the ground control. Using these data, it is able to reset the deviation of its predictions. As a matter of fact, this observer is meant to run at the wall clock speed (real-time) as the simulator does. We believe that this solution is the most powerful that can be implanted with the constraints presented before. But, even if the implantation costs are relatively low, this solution is not so easy to implant and is thus made for large facilities to justify a fast Return on Investment (ROI). The purpose of this paper dealing with the product driven production systems, this constraints is very often respected as these systems are generally relatively large.

Let us now examine the implantation of such an observer. A lot of technologies might be used, according to the objectives that were designed. We chose to use discrete-event simulation. Indeed, a lot of simulation pieces of software meet the requirements of our study. First, it was widely used to model the behaviour of such production systems. As a matter of fact, the model that was eventually made for the design of the facility can be used again in the production phase. This implies an interesting diminution of the investment time and costs. Then, the available means of communication are generally very well adapted to the communications inside such control architecture. Their graphical user interfaces is also very interesting, as it enables a clear vision on the behaviour of the system for the operator.

Finally, the state gathered on the observer is particularly well adapted to use to initialize other simulations in order to predict the future behaviour of the system. This is what is described in the next section.

PREVISION

We suggest in this section the use of a discrete event simulation based decision support tool. In the end of the 90s, several studies were lead about the future of discrete event simulation. Their main idea was to switch from a design aimed simulation to a decision support simulation. This concept was named in [START_REF] Davis | Online simulation: Need and evolving research requirements[END_REF] as "online simulation".

Product-driven systems local behaviour is generally simple to express, as it is made of simple rules that each agent respects. Thus, the global evolution of the system starting from a perfectly known state is easily predictable (in absence of hazards) by means of simulation. The remaining problem is the knowledge of this initial state. The observer is of course very helpful to solve this problem, as the data contained in the system's state it provides perfectly fits with the data needed for the initialisation of the simulation. Simulation can be interfaced with almost every component of the architecture, starting with the PLC to the APS. When one of them asks for a simulation, the computation starts. First step is the gathering of the state of the observer, considered as the best possible approximation of the actual state of the system. When the computation is over, the results are sent back to the element that asked for the simulation. Fig. 4 presents this solution, with a simulation request coming from the MES and the results getting stored in the database. Voluntarily, all the communication means are not represented on the figure to avoid overloading it. As we said before, the primary aim of our work was to support a human operator in his decisions along the production. As a matter of fact, the architecture we suggest opens the possibility to add an optimization algorithm. Furthermore, it happens to be possible to couple these tools directly with the ground control in order to extend the rules involved in the control of the system. Indeed, from now on, it is possible to make a decision taking into account the past events and the prevision of the future events happening on the system. The rules may therefore extend their vision, which is generally typically local.

AN APPLICATION EXAMPLE

The assembly line

The assembly line was built for educational and research purposes by the Institut Universitaire de Technologie of Nantes (Fig. 5). This job shop production system is made of six workstations. The goods are transported with pallets, which move on unidirectional conveyors. The pallets will be called "transporters". Therefore, when the transporters move on the main loop and arrive at the entrance of a station, a comparison between the next operation of the recipe and the list of operations the station is able to perform is made. According to the chosen rule, the transporters may enter the station or continue on the main loop.

Online simulation

This kind of working enables a distributed approach of the control, as all the decisions after the transporters leave the storehouse are made on a local point of view. On the other hand, when a decision has to be made by a human operator, it is very difficult for him to evaluate the situation, and even more to foresee the consequences of his decisions on the system's behaviour.

The particular example we developed is about the calculation of due dates of production orders according to the orders' parameters. The main parameter on which the human may act in a production order is the number of transporter that is allocated to this order. This number determines the number of products the transporter will transport, and therefore will have a great influence on the makespan of the order. For example, to produce 40 products, is it better to allocate 1, 40 or any other number in between of transporters? A low number extend the makespan of the order, but has a low influence on the other orders on the system, whereas a high number enable a high parallelism between the operations, but overload the system. The whole tool is controlled via the MES screen. Indeed, it is meant to be used by non-specialists of simulation, and a special effort must therefore be made on the human-machine interface. Our application is relatively easy to use. Each time the operator clicks on the simulation button, the figures representing the simulated end date of each order of the orders table are updated with the new simulation results. These orders are either running or still not launched. This last feature enables the operator to evaluate the pertinence of the parameterization of these orders.

Behind the screen, after the operator pushed the button, the simulation model (simulator) starts gathering all the information needed for this run, including the orders table or the stations parameters for example. These data are located inside the MES database. On the other hand, it contacts the observer to ask its actual state. The observer copies its state in external text files, and then acknowledges the request of the simulator. At this point, the simulator starts initializing at the correct state collected through the text files. When the simulation ends, the results are stored in the database, and an acknowledgement is sent to the MES. The results are then displayed on the screen. In our application, for orders of about an hour long, the results are displayed less than five seconds after the operator pushed on the simulation button.

The Quest observer

The objective of the observer is to extract, at any date, an estimation of the system state, using a simulation model and the piloted system trace. The main problems of using Quest for this application are external communications, real-time management and synchronization of simulated transporters according to the system trace. In this part, we present those problems and the solutions we developed in our application.

The first problem is the lack of communication media between Quest and external applications. There are two possibilities offered by Quest for synchronous exchanges with others applications: TCP/IP sockets and pipes. Pipes are very well supported on UNIX systems, but difficult to use on Windows platforms. We chose to use sockets to communicate with sensors. We had to use intermediates between the observer and the sensors due to incompatible data formats (Fig. 6). The last problem is to synchronise the Quest transporters according to the controlled system events. In this application, we chose to respectively model the real conveyors, the shuntings and the transporters with some Quest conveyors, decision points and parts. The advantages are the use of accumulation capabilities, speed control and routing solutions.

The two main problems we encountered are to stop a part when the corresponding transporter is late or stopped, and to move the part when the transporter is seen at another location than the one the observer had forecasted. The first problem is solved by blocking the parts in the decision points' logics.

The second one is solved by connecting "Out decision points" every x millimetres to "In decision points" through a buffer (Fig. 8). When a transporter is identified at an unforeseen location, the corresponding part is marked and extracted from the nearest "Out decision point". The buffer routes the part to the point the transporter was seen.

Precision of the architecture

When studying the results of a set of online simulations, the question of the precision of the forecasts is essential. Then, the initial state of the simulator is not the exact present state of the system. A first reason for this is that the data acquisition is not immediate, but a gap of time exists between an event on the system and its detection by the observer. We made some benchmarks on the tardiness of the acquisition chain presented in section 5.2 (Chove, 2007). The measured tardiness, with optimised OPC configuration, can be represented by a normal law with an average of 100 ms and a standard deviation of 50 ms. A second reason is the inaccuracy of the modelling of the system in the observer, which makes the prevision of behaviour not accurate. Both of these reasons on our application give an estimated global inaccuracy of less than 500 ms in average, which represents a distance of 10 cm of travel for the transporters.

The problem we encountered to evaluate the global uncertainty is that a slight inaccuracy on the initial state of the simulator may have a great effect on the global behaviour of the system. In order to avoid these side effects, we chose to run a full test on the prevision of the end date of a production order on our application. To do so, we ran a production order on the line, and we simulated every 3 seconds the end of the production. We then compared every simulated date with the real one, obtained after the real production is over. This test was run with several orders, representing different loads of the system. As a result, we noticed that the simulator's previsions were globally less than 5% far from the actual data (Table1). Furthermore, the uncertainties tend to decrease as the order goes, as the simulation length decreases.

CONCLUSION AND PERSPECTIVES

The aim of this paper was to present how simulation could be a powerful tool for the production activity control of a product-driven system. This tool is meant to support a human operator who needs to make a decision about the global behaviour of the system. As a matter of fact, this paper is focused both on a Vision support, enabling the operator to have an overview of the system's present state at any time, and on a Prevision support, enabling him to foresee the alternative consequences of the decisions he could make. This tool is based on an observer for the Vision and a simulator for the Prevision. The observer is also used in the Prevision phase to provide an initial state to the simulator reflecting as accurately as possible the present state of the system. Furthermore, building the observer with the same language as the simulator is enables great data compliance between these two components.

At the present time, our work is particularly focused on the production phase of the supply chain. Future directions of this work will extend the concepts we developed here to the whole supply chain, in order to be able to foresee more accurately the consequences of the operator's decisions on the whole chain.

Fig. 1 .

 1 Fig.1. Data directly coming from the production system

  Fig.2. Using a simulator

  Fig.3. Using an observer

  Fig.4. Relationship between simulator, observer and control architecture A transporter storehouse (an accumulation conveyor) enables the storage of the free transporters. The 42 transporters are equipped with smart tags. The production data of the transporter are written on the tag when it leaves the storehouse: number of products to transport (sequentially), recipe of each product in term of operations, etc. In parallel, each station has a list of operations it is able to perform. Therefore, when the transporters move on the main loop and arrive at the entrance of a station, a comparison between the next operation of the recipe and the list of operations the station is able to perform is made. According to the chosen rule, the transporters may enter the station or continue on the main loop.

Fig. 5 .

 5 Fig.5. The job-shop production system

Fig. 6 .

 6 Fig.6. Communication from ground controller to QuestThe second problem met is the synchronisation of the simulation clock with the world clock. Quest, in opposition with others simulation tools such as Siman Arena RT, does not include any real-time module. The solution we suggest is to incorporate a dummy element in the Quest model, piloted by a customised BCL program. This element connects itself to an external time server and controls the INTERVAL parameter to accelerate or decelerate time stream (Fig.7).

Fig. 7 .

 7 Fig.7. Quest real-time overriding control This overriding control links the Quest model clock and the world clock. In consequence, it reduces the time stream gap between the controlled system and the observer model.

Fig. 8 .

 8 Fig.8. Decision points on a Quest conveyor Thus, we tried and identify the main causes of uncertainty in our own architecture. First, as long as we could have worked on the simulation model, it cannot be the exact representation of the reality: some hypotheses inevitably have to be made, which make the model behaviour diverge from the actual one.

Table 1 . Error evaluation of the previsions

 1

	System's load	40%	60%	80%	100%
	Mean	1.63%	1.18%	1.08%	1.10%
	Standard Deviation	2.77%	2.98%	2.45%	1.64%


Olivier Cardin
email: olivier.cardin@irccyn.ec-nantes.fr

Pierre Castagna

Using online simulation in Holonic Manufacturing Systems

Keywords: Online simulation, HMS, Production Activity Control, PROSA, Staff holon

This paper deals with the use of online simulation on Holonic Manufacturing Systems. Concepts needed for the use of online simulation in a classical hierarchical system were already defined, the observer being the central one. The behavior's differences between both classes of systems are studied to determine the best way to adapt these concepts to this new environment. In the PROSA reference architecture, staff holons were chosen to welcome the simulation models and the observer. An application on an industrial sized Holonic Manufacturing System is described to demonstrate the validity of the approach.

Introduction

For several decades, classical hierarchical manufacturing architectures were used. In the past few years, distribution of information and control was explored until reaching purely distributed isoarchic architectures [START_REF] Pujo | Pull System Control for Job Shop Via a Holonic, Isoarchic & Multicriteria Approach[END_REF]. Among these new alternatives, Holonic Manufacturing Systems (HMS) now encounter a growing success in both academic and industrial worlds [START_REF] Blanc | Holonic control of a laminated security glass production system[END_REF]. Indeed, the combination between global fixed objectives imposed to the holarchy and local strategies left to the free will of these holons is a particularly attractive compromise between fully hierarchical and fully heterarchical behaviors.

The problem with such control architectures is their production activity control. Indeed, it is very difficult to mentally think through the consequences of alternative courses of action, and as a matter of fact to be able to determine whether an alternative decision is better than another. These difficulties, already pointed out in the 1990s about the only problem of scheduling [START_REF] Van Dyke Parunak | Characterizing the manufacturing scheduling problem[END_REF] [START_REF] Cavalieri | A Benchmarking Service for the evaluation and comparison of scheduling techniques[END_REF], are due to the distributed decision making, avoiding a global vision of the system's behavior.

As shown in [START_REF] Valckenaers | Emergent shortterm forecasting through ant colony engineering in coordination and control systems[END_REF], efficiency of a holonic architecture goes by the ability for holons to forecast the future behavior of the underlying system. An example of the importance of this problematic is indirectly presented in [START_REF] Sousa | A distributed architecture and negotiation protocol for scheduling in manufacturing systems[END_REF]. When computing ths scheduling of the HMS in a distributed manner, an indecision problem may occur during the negotiation between holons in charge of the resources (named Resource Holons) and the holons in charge of the orders (named Task Holons) on the only criterion of the due date. This indecision was solved by the authors by assigning a priority order in the negotiation depending on the date of arrival of the order, avoiding several concurrent negotiations on the same resource. This solution seems to be the best considering the holons cannot forecast the future behavior of the system.

One of the solutions suggested in [START_REF] Valckenaers | Emergent shortterm forecasting through ant colony engineering in coordination and control systems[END_REF] to achieve this objective is to use ant colonies to predict the emergent behavior of the system on a short term [START_REF] Valckenaers | Holonic Manufacturing Execution Systems[END_REF]) [START_REF] Valckenaers | Emergent shortterm forecasting through ant colony engineering in coordination and control systems[END_REF] [START_REF] Karuna | Emergent forecasting using a stigmergy approach in manufacturing coordination and control[END_REF]. This solution enables the order holons to gather information about its completion before it is launched (time of completion, date of arrival at each machine, etc.). Moreover, resource holons gather this information to build a projected planning of occupancy which may be used in the future negotiations with other holons.

The focus of this paper is to detail the advantages of using discrete-event simulation as an online forecasting tool. This possibility was already exposed in [START_REF] Gouyon | A product driven reconfigurable control for shop floor systems[END_REF] when saying that the use of tools supporting a discrete-event simulation of the production flows could ensure that no livelocks could occur when various products are considered at the same time in a product-driven system.

Regarding their behavior, the underlying production systems can mainly be seen as discrete-event systems. As a matter of fact, discrete-event simulation is a very powerful tool to model HMS. Indeed, it is very suitable to describe with a lot of details the behavior of each holons in the holarchy. It may even be used as an emulation of the shop floor in order to study alternative rules applied to each holons before the real implementation [START_REF] Blanc | Holonic control of a laminated security glass production system[END_REF]. For several decades, online simulation was described as a powerful tool for decision support in large and complex manufacturing systems. This simulation is meant to foresee the consequences of alternative decisions a decisional entities may take.

Comparing the impacts, this entity is able to decide which solution is the best to apply. Unfortunately, this was almost never implemented as no general framework was designed to ensure the feasibility of the approach. It is only in the last years that [START_REF] Cardin | Proactive production activity control by online simulation[END_REF] introduced several concepts which made the implementation of online simulation possible. This work particularly dealt with the initialization of online simulations, which was one of the biggest issue described in the literature, but only considered the case of complex hierarchical manufacturing systems.

The problem is to know whether this approach is compatible with the specificities of HMS. First, a short description of the PROSA architecture is exposed. This architecture was chosen among others for its balance between hierarchy and heterarchy. A model of decision making for both resource and order holons, based on cognitive engineering works, is exposed in section 2. These models clearly show that the decision making mechanisms are similar in both approaches, except for the localization of each step of the process. The third section deals with the initialization issue. Several propositions are made to efficiently gather the system's state in order to initialize the simulations. This section introduces the use of Staff holons for decision support of other holons. This Staff holon includes both simulations and observer. This use is more precisely described in the last section, which introduces an example of online simulation on a flexible manufacturing cell.

Decision making in HMS a. Holonic architectures

Many holonic architectures are exposed in the literature for the production activity control of HMS.

One of the most famous, enabling a good compromise between hierarchy and heterarchy, is called PROSA (Van Brussels et al., 1998). As expressed in the acronym, PROSA (Product Resource Order Staff Approach) is mainly built around four kinds of holons (Figure 1).

First, the Product Holons (PH) deal with all the data related to the reference s produced in the HMS.

They roughly act like a database for all the other holons of the system to enable them to access all the data (routings, bills of materials, etc.) needed to be able to produce the right products with a sufficient quality. The Resource Holons (RH) correspond to physical entities able to act on products (such as factories, machines or tools) and contain all the data and knowledge to be able to control and organize these entities. The Order Holons (OH) handle the product during its manufacturing, deal with the logistics needed in the routing of the product. These holons are meant to negotiate with RH and other OH in order to achieve at best the production. At last, the Staff Holons (SH) are used as specific advisors. When other holons (OH or RH) need to make a ddecision, they have to apply either the general fixed rules of the system, or a variant coming from the application of the local strategies. If this is not satisfactory, they may ask for the help of a particular SH in order to solve a specific problem. Each SH has therefore an expertise on very specific problems of the HMS. If the SH is not able to provide a result, or not soon enough, the other holons have the possibility to apply their rules.

This results in a non-optimal but safe behavior of the HMS. (Valckenaers, 1998) As a matter of fact, there are only two kinds of holons that are able to make decisions in a HMS: order holons and resource holons. It is to be noticed that the type of decisions they make are completely different. Indeed, RH are inclined to make decisions on a very local point of view, when OH have to cope with the global objectives of the system, and therefore make decisions not only on a local, but also on a global point of view. Furthermore, as every holons deal with fixed rules and local variants, the mechanisms of decision making are quite different.

b. Decision making model [START_REF] Hoc | Supervision et contrôle de processus, la cognition en situation dynamique[END_REF] presents a revised version (adding the cognitive mechanisms of situation evaluation) of Rasmussen's model [START_REF] Rasmussen | Skills, rules and knowledge; Signals, signs and symbols and other distinctions in humn performance models[END_REF] [START_REF] Rasmussen | Information processing and human-machine interaction; An approach to cognitive engineering[END_REF] of human approach for problem solving in the diagnosis phase. Diagnosis is here defined as "a comprehension activity relevant to an action decision" (Cegarra and Hoc, 2001). The authors say that diagnosis is an activity of comprehension, organizing elements into a meaningful structure. This organization is oriented towards decisions relevant to actions. While diagnosing, the operator manages a balance between benefits and costs, trying to reach an acceptable performance according to the goals. The aim is to adapt this model, centered on the role of human operator, to the general case of HMS, centered on the holons.

Rasmussen's model exposes three separate behaviors of the decisional entity (i.e. the holon). First, if it has already encountered the exact same situation, it enters a skill-based behavior (application of a simple rule: High Priority First for example). Otherwise, if the situation is close to a situation previously encountered, it enters a rule-based behavior (application of a well-defined procedure: use of a bin-packing algorithm for example [START_REF] Blanc | Holonic control of a laminated security glass production system[END_REF]). At last, if the situation has never been encountered before, or if the solving procedure is not well-defined, the decisional entity may enter a knowledge-based behavior, where a new solution, taking into account global objectives, is determined.

As stated in [START_REF] Cardin | Contribution of online simulation to production activity control decision support -Application to a flexible manufacturing system[END_REF], the use of online simulation in heterarchical architectures is best fitted in a rule-based behavior: skill based behavior generally does not need any simulation study, and knowledge-based behavior implies a model design that is not compatible with the HMS's dynamic. operator is considered as a problem solver, when the holons generally have to negotiate inside the holarchy to obtain the same result. The decisional center is thus distributed [START_REF] Bongaerts | Hierarchy in distributed shop floor control[END_REF], which makes a great difference in the approach. Indeed, there may be several users of online simulation at a time in a HMS.

Decisions in a HMS are only taken in RH and OH -the holon making the decision will be called DH in the following. When this holon needs to make a decision, it asks for an advice to online simulation.

This advice is meant to orient the decision towards the optimal one. The classical problem of such a behavior is the response time. Indeed, there is generally a time pressure on the DH to make its decision, so that it does not slow the production down. As a matter of fact, there is a possibility that online simulation is not able to provide the results early enough. In that case, the DH has to apply a default rule, known to be safe but not necessarily optimal.

One of the main hypotheses of this paper is to be able to model the decision making process in the simulation. Indeed, as the future behavior of the HMS depends on both the present and the forthcoming decisions, it is necessary to take into account the actual decision making process results to accurately predict this behavior. This hypothesis is not very restrictive as the simulation horizon is generally short in online simulations. This short horizon prevent from modeling events such as breakdowns for example, as their occurrence is too rare in the horizon. [START_REF] Saint Germain | Benchmarking of manufacturing control systems in simulation[END_REF] present a coupled real-time/as-fast-as-possible simulation, which enables a fast computation of the simulation with a shift to real time during the decision making process. It seems possible to use this approach if it is not possible to model the decisions. However, it has to be reconsidered if several replications have to be performed on stochastic models, as the simulation duration is quite longer.

d. Implementation of online simulation in a HMS

Online simulation is a tool designed to help the decision making in the PREVISION phase. Even if the decision is distributed, it is possible to centralize the simulation engines. As a matter of fact, the best place to implement online simulation is inside a staff holon. This holon is an aggregate of several atomic RH, each of them corresponding to a simulation model devoted to a particular problem. The SH may also integrate optimization algorithms if the advice asked by the DH needs it.

Every holon have a remote access to run and collect the results of a simulation. This solution has the advantage of being easier to implement, but the model management is difficult (each specific request corresponding to a specific model) and it is necessary to multiply the simulation engine to allow multiple simulation at a time.

Initialization of online simulation a. Introduction

However, the main problem identified in [START_REF] Cardin | Proactive production activity control by online simulation[END_REF] still remains: the initialization of the simulation on the state of the HMS is both very important and very difficult to perform, as the data needed for this initialization are distributed among the holons. Three main possibilities of state gathering were examined: the following paragraphs present these possibilities. Their conclusions deal with the applicability conditions.

b. Data directly coming from the production system

The first solution studied was to obtain the data directly from the holarchy (Figure 3). Indeed, each holon has a partial knowledge of its state. For example, product holon may provide the production data, order holons may provide data concerning the production orders running, and the resource holon may provide the state of the work stations (breakdown, etc.). This solution provides obvious advantages: the obtained data are reliable, and represent the actual present state of the system.

Furthermore, it only requires a minimal additional architecture to work properly. The remaining problem is that the use of such devices creates a great uncertainty. Indeed, when an AGV faces a sensor, it is possible to know its position at the current date. As soon as it moves between two of these sensors, its position is totally unknown (except for the information that it is situated on the track between the sensors), and its arrival date in front of the next sensor is unknown a priori. It is therefore not possible to have the whole fleet of AGV in front of sensors of the system each time the information of their location is needed. As a matter of fact, the holons only have a partial view of the system's state: this is what was defined as the space and time uncertainties in [START_REF] Cardin | Handling uncertainty in production activity control[END_REF].

Of course, one could argue that there is always a technical response to such a problem. In this work, the choice that was made is to use the only sensors strictly necessary to the control of the HMS. The previous example allows a better understanding of this hypothesis. The use of a GPS module, or a video camera coupled with an image analyzer is an efficient technical possibility to solve the problem of positioning of AGVs in a workshop. But, this type of solution is quickly expensive, and it would generally be necessary to add several of these technologies to know the complete set of data needed to build the entire state of the complete system.

The conclusion that was drawn from the use of this solution is that it is not applicable in the general case, as many data, essential in the definition of the state, are missing or unavailable through the sensors settled on the system. However, it could be recommended in the rare cases enabling its optimal use, as the data is particularly reliable considering the relative simplicity of the setup. A good example of application field is the Air Traffic Control [START_REF] Rogers | On-line simulation for real-time scheduling of manufacturing systems[END_REF], where position, flight plan and current trajectory of each aircraft are perfectly known at any time.

c. Using a simulator

For the last few years, most of the simulation software editors provide "real-time" editions of their tools. These tools have the specificity to run at the same speed as the wall clock, in opposition to classical software in which the simulation engine runs as fast as possible. They were developed in order to meet the industrial requirements to be able to use simulation as an emulation of the production systems. The initial idea was to reduce the setup time of complex production systems by making tests of the control system directly on this emulation, without waiting for the existence of the physical system.

The idea here is to use such a simulation running in parallel with the production. This simulator is meant to react to production solicitations coming from the order holons in the same way the real system does. Doing so, it creates a permanent "image" of the system, which state can be considered as being the state of the real system at any time (Figure 4). This solution has two main advantages compared to the exclusive use of data directly coming from the production system. First, it suppresses the space and time uncertainties problem that was defined in the previous section. About the example of the movement of an AGV previously presented, the simulator enables to know its current position at any time for example. Furthermore, the state gathered with this method is well formatted for a later computer treatment. Indeed, gathering the state is not useful if it is not possible to treat the data in an effective way. On the other hand, there are several problems in the application of this solution. First, the initialization of this simulator must be done with a perfectly known state. Typically, this state is chosen "idle and empty" because it is the easiest state to express by hand. Secondly, inaccuracies in the system's model and possible hazards inevitably occurring along the production cause a deflection on the final results. The additive aspect of this deviation along time would end up having an effect far from being negligible.

To guarantee the applicability of this solution on a given production system, several constraints have to be set. First, the simulator has to be extremely reliable to limit the effects of modeling inaccuracies.

Then, it is preferable to deal with systems which regularly go back to a known state (generally the "idle and empty" state mentioned before). Let us cite as a classical example the systems that are empty at the end of each working day. It is possible on such systems to restart the simulation, and by doing so, reset the deviation. Finally, the system shall have a low hazard occurrence frequency relatively to the length of simulation without reset. Indeed, these hazards are not taken into account into such a model, and are thus directly deviating the results.

As a matter of fact, the class of systems that may be concerned by this solution is relatively limited due to the inevitable growing deviation of the results. On the other hand, this is a credible alternative for applications that cannot afford the equipments necessary to the previous solution and which do not need a high precision on the results.

d. Using an observer

The conclusion that can be drawn at this point is that both solutions previously presented turned to be well adapted to a limited class of systems. As the objective of this work to make a solution applicable to the widest class possible, the idea is to get the advantages of the simulator (about the data availability) and of the direct use of real system's data (about the data reliability). The following paragraph deals with a successful attempt of hybridization of the solutions in an observer.

Figure 5 presents the principles of such a solution. Compared to the previous solution, the simulator is replaced by an observer, meant to deal with the data coming from all the holons. Using these data, it is able to reset the deviation of its predictions. As a matter of fact, this observer is meant to run at the wall clock speed (real-time) as the simulator does. This solution is probably one of the most powerful that can be implemented with the constraints presented before. But, even if the implementation costs are relatively low, this solution is not so easy to implement and is thus made for large facilities. The purpose of this paper dealing with the Holonic manufacturing systems, this constraint is very often respected as these systems are generally relatively large. A lot of technologies might be used to implement this observer, according to the objectives that were designed. The choice that was made here is to use discrete-event simulation. Indeed, a lot of simulation pieces of software meet the requirements of our study. First, it was widely used to model the behavior of such production systems. As a matter of fact, the model that was eventually made for the design of the facility can be used again in the production phase. This implies an interesting diminution of the investment time and costs. Then, the available means of communication are generally very well adapted to the communications inside such control architecture. Their graphical user interfaces is also very interesting, as it enables a clear vision on the behavior of the system for an operator. Finally, the state gathered on the observer is particularly well adapted to use to initialize online simulations in order to predict the future behavior of the system.

Example

The studied HMS (Figure 6) is located in the Quality, Industrial Logistics and Organization (QLIO) department of the University Institute of Technology (IUT) of Nantes, France. It is an automated assembly line, part of a larger set of logistics systems, including an AS/RS and two opto-guided AGV.

This line is widely inspired from an actual line of FILTRAUTO/SOGEFI, world leader of the production of oil filters. where it can negotiate with each station RH in order to go on its recipe. When this recipe is over for all the goods the atomic OH was in charge of, it leads the transporter RH to the storehouse and free it.

As a matter of fact, to run an order, the main OH needs to make three decisions by negotiating with the other main OH (Figure 7 shows the localization of all these decisions on an assembly line scheme):

• DG1: At which date will the production begin?

• DG2: How many transporters will be allocated to this order?

• DG3: Which priority is given to the order?

The atomic OH also negotiate with the storehouse RH to decide:

• DG4: Does the transporter located on the main loop at the entrance enter the storehouse or stay on the loop?

Along the production, atomic OH and stations RH negotiate to decide:

• DL1: Does the transporter located on the main loop at the entrance enter the station or stay on the loop?

• DL2: At the end of an operation, is OH authorized to step to the next operation of the recipe?

Because of their physical structure, buffer management rule of stations 1, 3, 4 and 5 is necessarily FIFO. On the opposite, buffer management rule of stations 2 and 6 can be unspecified, which defines new buffer RH (Figure 8). As a matter of fact, two more decisions have to be negotiated between atomic OH, stations RH and the corresponding buffers RH:

• DL3: Does the atomic OH seize the station RH and free the buffer RH?

• DL4: Does the atomic OH free the buffer RH to enter the main loop? Obviously, all the decisions listed here do not need online simulation decision support. The following describes an example of application: DL3 decision. As stated before, this decision deals with stations 2 and 6 composed of a loop-shaped buffer with a programmable priority rule (Figure 9). The application is about the use of online simulation to choose which OH is supposed to enter the station RH. Numerous dynamic scheduling rules of the buffer can be used as a basis of DL3 decision. Most of these rules look for the best candidate among the elements waiting in the buffer, considering a given objective, to be taken out and treated by the station. The problem of these rules is that the buffer evolves along time, as the rules only take into account the content of the buffer at a precise date.

However, it is not necessarily true that the choice made at date d, taking into account the content of the buffer at this date d, turns out to finally be the best solution. The idea here is thus to use online simulation to extend the vision of the rules to the near future (horizon H), to test the validity of this decision on this horizon. [START_REF] Cardin | Handling uncertainty in production activity control[END_REF] presented the use of the "Clear-a-fraction" rule applied to decision DL3.

It is interesting to notice that the decision is totally automated, without any human intervention. This is due to the short decision lap of time left to the decisional holon (here a station RH). This constraint also has an implication on the use of online simulation. Indeed, to ensure a good working of the line, the station RH has to obtain the results before a due date. This leads to the use of a Staff Holon, which role would only be to advise the RH. If it cannot provide any result before the end of the due date, the station RH is meant to apply a simple rule (let the atomic OH enter the station for example).

Conclusion and future works

This paper deals with the use of online simulation on Holonic Manufacturing Systems. In the literature, all the concepts needed for the use of online simulation in a classical hierarchical system were already defined [START_REF] Cardin | Proactive production activity control by online simulation[END_REF]. The simulation-made observer is the central concept, enabling the simulations to initialize on the actual present state of the system. In this classical approach, Manufacturing Execution System plays a central role, being the link between all the components of the architecture. In the PROSA reference architecture, this role is distributed among all the holons. As a matter of fact, the main aspects to study were both the place of online simulation in the architecture and the relationships between simulation and holons. Staff holons were chosen to welcome both the simulation models and the observer, advising the other holons in their decisions.

The final part of this paper is dedicated to the description of an application of these concepts to an industrial sized Holonic Manufacturing System. An example of fully automated buffer management is presented. This example allowed describing the behavior of each holons, in order to show the timed relationship between each of them. This specific case is in the class of goods routing problems, for which distributed architecture is very well adapted.

The future developments of this work will deal with the generalization of the approach to other control architecture. Furthermore, a real industrial application of the concepts to already existing manufacturing systems will enable a numbered comparison of performance between the use with and without online simulation.

Figure 1 .

 1 Figure 1. Basic building blocks of a HMS and their relation, based on(Valckenaers, 1998)

Figure 2 .

 2 Figure 2. Simplified Rasmussen's rule-based behavior

Figure 3 .

 3 Figure 3. Data directly coming from the production system

  Figure 4. Using a simulator

Figure 5 .

 5 Figure 5. Using an observer

Figure 6 .

 6 Figure 6. General overview of the system

Figure 8 .

 8 Figure 7. The assembly line and the related decisions

Figure 9 .

 9 Figure 9. Implementation of station 6

Figure 10 Figure 10 .

 1010 Figure 10 describes the working of a simulation-based negotiation for the seizing of the station 6 RH