A Distributed Task Planning Method for ... - Semantic Scholar

A Distributed Task Planning Method for Autonomous Agents in a FMS Stefan Hahndel

Paul Levi

Institut fur Informatik Institut fur Parallele und Forschungs- und Lehreinheit IX Verteilte Hochstleistungsrechner TU Munchen Universitat Stuttgart Orleansstr. 34 Breitwiesenstr. 20-22 81667 Munchen 70565 Stuttgart email: [email protected] email: [email protected]

Abstract We present an approach of a distributed planning method to solve dynamically some typical tasks of a production planning system in a exible manufacturing system (FMS) at control level without using a xed central component during planning and execution of orders received by one or several production planning systems above the control level. To achieve this, a exible manufacturing system has been modelled as a multi-agent system, while the planning method we present uses the structure of manufacturing plans to coordinate properly their activities through negotiation among the agents. This has been implemented and tested in an object-oriented simulation environment.

1 Introduction In present-day manufacturing environments there is an increasing number of intelligent mobile robots and intelligent manufacturing cells with growing autonomous capabilities. These systems

are usually connected by a powerful computer network. It seems to be just a natural step to use distributed planning methods instead of centralized ones, as they are the state of the art in most real-world manufacturing systems. It is well known that such a centralized system forms a bottleneck. Instead, it seems to be more promising, if the autonomous agents in the environment build their own plans and coordinate these through negotiation. In this case the enormous complexity of planning can be distributed to several dierent agents, thus reducing the complexity for a single system. Of course, such a distributed approach leads to higher communication costs. Due to this the main objective must be to gain as many advantages as possible from the distribution of the tasks while trying to reduce the communication costs as much as possible. We developed a distributed planning method that needs no xed central decision component and organizes itself using the structure of manufacturing plans, while overlapping planning and execution of actions. Manufacturing plans can be seen as skeleton plans, containing only manufacturing steps on the highest level of abstraction, together with the causal dependence, but with-

out the auxiliary actions needed. These are to 2 The Model be generated by the distributed planning process, We regard a manufacturing process as a process together with the scheduling of all actions. transforming a set of basic objects into a goal object. The model contains a set of possible objects Related Work Examples for related work are O. There is also a set of possible actions T reprethe works of Albayrak [Alb92], Ayel [Aye92], senting the set of possible transformations in the Dilger [DK93], Draeger [Dra93], Fischer [Fis93], production environment. Each action t 2 T conParunak [Par89], Raulefs [Rau91] and the diverse sumes a set of objects foa1 ; : : :; oak g and produces Japanese projects, which are described in the "ka- a set of objects fop1 ; : : :; oplg. Formally, such an haner report" [Kah92]. action can be seen as a (partially de ned) funcBoth Albayrak and Dilger use a blackboard-based tion t: 2O ! 2O , which can be modelled properly model of a distributed system for production by a petri net transition ( gure 1). In our sysplanning. Ayel realized a multi-agent system consisting of a set of so-called "supervision kernels" op oa to monitore of a manufacturing system. This is a reactive approach which is also partly based on a blackboard architecture. Raulefs, who introduced the denotation "computational manufacopl oak turing", is working on the realization of an objectoriented model of a virtual factory. His approach can also be classi ed as a reactive approach, beFigure 1: manufacturing action cause no lookahead planning is done. Parunak examined the use of the contract net protocol to distribute tasks in a hierarchically organized set tem we also have a set of autonomous agents A of manufacturing units. In this concept there is representing manufacturing cells, machines and also no planning lookahead. In the work of Fis- autonomous robots. The capabilities Cap(a) of cher, each agent has a set of behavior patterns an agent a 2 A can be seen as a subset Ta  T of represented by a set of rules. If a rule matches all available action types. To do an action t 2 T , the actual situation the corresponding actions are an agent needs some resources, e.g. tools. These performed. Moreover, each agent is able to send are modelled by a set of possible resources R and a function : T  A ! 2R . The (manufacturfacts to other agents. One of the main dierences between our approach ing) agents are connected by a network of paths and other distributed approaches is that it is not Pa, de ned by a graph, connecting machines and pure reactive. Instead, it is a hybrid approach. crossing points. We have a lookahead range in which succeeding A manufacturing plan M is de ned by a high steps are planned previously in order to prevent level petri-net ([Rei86]). It is a 6-tuple M = con icts arising as soon as possible. But, con- (P; T; F; O; ; ) trary to most central approaches we did not plan  As usual, P denotes a set of Places and T a all steps of a certain task in advantage, because set of transitions, connected by a ow relathe real-world environment changes during plantion F  (P  T ) [ (T  P ). ning. Distributed planning, monitoring and execution of actions is done in a temporal overlap O is a set of possible objects, these being the ping manner. allowed token of the net. 1

1

. . .

action

. . .

Product P1:

mill-1

mill-2

mill-1

drill-1

grind-1

paint

dry

drill-1 assembly

saw-1

Product P2: mill-3

drill-2

Figure 2: Simpli ed example of typical manufacturing plans

  is a function, assigning terms to the arrows of the net; : F ! Terms(D; X ) n ;, D, as

3 The agent architecture

usually is an algebra and X a set of variables. In our concept, each agent has its own knowledge base and a combined communication and plan  is a domain function, assigning a set of ning module. The (object-oriented) local knowledge base conallowed objects to each place; s: P ! 2O tains Examples of (simpli ed) manufacturing plans are  a local time plan of its planned actions shown in gure 2. The gure shows only the causal dependence of the actions, without the in knowledge about which actions the agent can scriptions of arrows and places. perform by itself and which actions it must delegate to other agents, and the average duSeveral tasks must be solved by a distributed proration of these. Furthermore, it knows how duction planning and control system. to build a local action plan.

 Knowledge of the manufacturing plans con1. Each action t in the manufacturing plan tributed by it. must be expanded to a local (multi-agent) action plan, which is also de ned by a petri The communication manager has the task, of net containing all auxiliary actions. carrying out the negotiation needed with other agents. If it has to allocate an agent a 2 A for 2. An agent (i.e. manufacturing cell or robot) action t, it determines automatically the set of must be assigned to each action t of the man- agents fa 2 A j t 2 Cap(a)g, which can carry out ufacturing plan and to each auxiliary action. the requested action, and perform the necessary All actions must be scheduled dynamically, negotiation with some of these. that means every action must be assigned a The main tasks of the local planning module are: time interval [ts; te]. building a local action plan, optimizing the local time plan, evaluating the oers for actions re3. Actions must be monitored to overcome as ceived from other agents, and generating oers to soon as possible arising con icts. other agents.

agent M-1 M-2 M-3 M-4 R-1 R-2

abstract capabilities and average times (mill-1, 10), (mill-2, 6), (drill-1, 3), (drill-2, 3) (mill-2, 8), (mill-3, 12), (saw-1, 4) (drill-1, 2), (drill-2, 2) (saw-1, 4), (saw-2, 4) (assembly, 10), (paint, 5) (assembly, 10)

Table 1: Capabilities in the example The execution and monitoring module starts its own planned actions at the right time and monitors the execution. Deviations from the planned activities are inserted into the knowledge base as soon as they become obvious in order to ensure that these deviations are respected by the planning module.

4 A Simple Example Let us suppose that we have the agents shown in table 1 together with their abstract capabilities and the average times. Figure 3 shows the network of paths for the transportation agents MR-1 and MR-2, together with the transporting times. Now, this small system receives two new orders to produce the products P1 and P2, whose manufacturing plans are shown in gure 2. In the starting state, the agents have already reserved the time intervals as shown in black in gure 5. By starting a negotiation process which is similar to the Contract Net Protocol [Smi88], the production planning system (PPS) tries to allocate agents to the very rst action of both plans. The PPS agent requests an oer from agent M1 for the action mill-1 and from agent M2 for the action mill-3. M1 and M2 try to plan these actions

and estimate when they could carry them out. M1

2

1

M3

M2

2

1

2

M4

1

1

LS

MS MR1

R1 2

1

R2

MR2

Figure 3: Net of paths in the example Planning such an action includes determining what resources are needed and building a local action plan to obtain the resources not yet available. In order to keep this example simple we take into consideration only additional needed transport actions to bring workpieces. The agents M1 and M2 test if and when they can perform the requested actions. M1 has free time from time point 4 until 22 (see gure 5, only the black area is important at this time). To do action mill-1, it needs the Object O1. Because the object O1 must be fetched from the main store MS, M1 announces a transport order "transport O1 from MS to M1, arrival in [4; 12]". Both MR1 and MR2 try to plan this order and both send M1 the oer to bring the requested object before time point 8. M1 evaluates these oers and estimates, when it will be able to perform action mill-1, respecting the transport actions oered. It determines that it can do action mill-1 within the time interval [8; 18] and sends an corresponding oer to the PPS agent. Because that was the single requested oer, the PPS-agent con rms it immediately. After M1 has received the con rmation, it con rms an adequate oer for the needed transporting action. Let us suppose it chooses agent MR2. After that, the PPS agent

mill-1

choosed agent

saw-1 [23,27] M2

mill-2 [29,33] M1

drill-1 [27,31] [30,32] M2 M3

M1

PPS [8,18]

[24,27] M4

[29,31] M1

mill-3 [6,18]

M2 drill-2 [20,23] M1

[21,24] M3

paint [29,34] R1

Figure 4: oered time intervals during the rst planning wave sends the corresponding manufacturing plan to M1, thus giving the planning control to M1. In a similar manner, action mill-3 is assigned an agent and a time interval. But here a problem becomes obvious in the case in which agent M2 requests the transport action it needs "transport O2 from MS to M2 within time interval [6; 10] " from the transport agents MR1 and MR2. If neither of these had already a con rmation for its oer to M1, it is possible that both agents send an oer to M2 and that the agents M1 and M2 choose MR2's oer. To prevent this, the con rmation of an oer must also be re-con rmed by the oering agent. When the con rmation of an oer fails, an agent tries to con rm the next best oer. If there is no more oer, the requesting agent must relax the restrictions given with the earlier request and request new oers under these new constraints. In our example, at least agent MR1 is chosen for the transport action needed by M2 After updating the manufacturing plan (structure), the agents M1 and M2, send the modi ed manufacturing plan P1 and P2 respectively to the choosen agents, in our case to M2, respectively M1. Because the lookahead value of 2 is not yet

reached, both agents continue the actual competing "planning waves", as we call it, and try to allocate other agents for the next actions in the manufacturing plans. That means that those agents request oers and behave themselfes in the same way, as we explained it for the the PPS agent in the rst planning step. Figure 4 shows the negotiation relationships, the time intervals oered and the allocations of agents for the rst planning wave of the example, while the result of this planning wave is shown in the gantt chart in gure 5. Each agent which is currently executing an action starts one planning wave after the other until it gives the execution control to the next agent. During this iterative distributed process the planning result for the next actions is improved with each planning wave.

5 Simulation Because it is very dicult to verify such a distributed planning system with formal methods, we veri ed this method in a simulated environment modelled as a multi-agent system. It con-

drill-1 mill-1 mill-3

M1 M2

drill-2 saw-1

mill-2

M3 M4 paint

R1 R2 MR1

M2

MR2 2

4

M2 M1 6 8

order 1

10

12 14 16

M1 18 20 22

order 2

M1 24 26

R1 28 30

32 34 36

38 40 42 44

46

allocated by other orders

Figure 5: Schedule of the example sists of a set of manufacturing cells and mobile robots, as shown in gure 6. Each manufacturing cell has several loading stations, and are connected by a network of paths. The rst implementation of this simulated environment was done with the object-oriented development system Prokappa. Simulating a distributed method with an objectoriented language such as Prokappa (or a similar OOPS) leads to some "technical" diculties because those OOPS have no real message passing mechanism. Each "message" between objects is a simple function call that causes a stack over ow after a short time. To overcome this, we have built our own message layer within Prokappa which realizes real message passing and contains its own dispatcher. Instead of calling a method of an object directly, the "SendMessage" function of the message layer only inserts the function call, together with a virtual time stamp, into a kind of queue for later use by the dispatcher. The manufacturing plans are generated randomly by a simple grammar that describes the typical structures of a manufacturing plan. It is also possible to generate random orders and to change some planning parameters such as average number of actions of the plans, the frequency of forks,

the grade of specialization of the agents and some others, in order to allow experiments in the simulated factory.

6 Conclusion We have presented a distributed organization scheme for distributed production planning and on-line scheduling that needs no xed central component, which often builds a bottleneck in other systems. The multi-agent system can easily be extended with further agents without changing the existing structure. Planning and execution of actions is performed overlappingly this allowing dynamic reaction to changes in the system in case con icts or failures should arise. From our simulation environment we learned that it is possible to coordinate the actions of several autonomous agents by using such a simply realizable planning method we described. In order to obtain satisfactory planning results, it is important to choose appropriate values for the dierent planning parameters, e.g. the lookahead value. In our experiments the system shows the following behavior: if simple reactive planning is done with lookahead 1, good values for machine load are achieved, but the time a single

Figure 6: A modelled virtual factory product remains within the manufacturing process turns out to be very high. The obvious reason is that the planning process is not able to keep together the manufacturing steps of a given product within a certain time interval, because in a planning wave only one step at a time is planned. Also the probability for resource con icts is high, because such con icts are recognized too late to be avoided. Increasing the lookahead value leads to better planning results, e.g. better load and smaller delays, until a point is reached when the overhead of planning and communication becomes too big and the results get worse. Of course, such a simulation environment running on one workstation can only be a rst step when developing distributed planning algorithms. The next step we are already working on is a distributed implementation running on a real computer network, which consists of a set of workstations performing the described planning method. For this purpose we are using the public domain tool PVM. This implementation will show how this planning method behaves in practice in a real environment.

References [Alb92] S. Albayrak. Kooperative Losung der Aufgabe Auftragsdurchsetzung in der Fertigung durch ein Mehr-AgentenSystem auf Basis des Blackboardmodells, 1992. [Aye92] Jacqueline Ayel. Decision coordination in production management. In Proc. of the 4 th MAAMAW, Pre-Proceedings of the 4th European Workshop "Modeling Autonomous Agents in a Multi-Agent World, 1992. [DK93] Werner Dilger and Stephan Kassel. Sich selbst organisierende Produktionsprozesse als Moglichkeit zur exiblen Fertigungssteuerung. In Jurgen Muller, editor, Verteilte KI. BI Verlag, 1993. [Dra93] Joachim Draeger. Ein exibles verteiltes Planungsverfahren ohne Anomalien fur den Einsatz in Fertigungsumgebungen. In Jurgen Muller, editor, Verteilte KI. BI Verlag, 1993.

[Fis93] Klaus Fischer. Verteiltes und kooperatives Planen in einer Fertigungsumgebung. Number 26 in DISKI. In x, St. Augustin, 1993. [Kah92] David K. Kahaner. A survey and discussion of cim projects in japan. Technical report, US Oce of Naval Research Asia, 1992. [LH93] Paul Levi and Stefan Hahndel. Kooperative Systeme in der Fertigung. In Jurgen Muller, editor, Verteilte KI. BI Verlag, 1993. [Par89] H. Van Dyke Parunak. Distributed ai and manufacturing control: Some issues and insights. In Proc. of the 1 th MAAMAW, pages 81{101, Cambridge, England, 1989. [Rau91] Peter Raulefs. Cooperating agent architecture to manage manufacturing processes. In W. Brauer and D. Hernandez, editors, 4. Internationaler GI-Kongre, pages 6{17, Munchen, 1991. [Rei86] Wolfgang Reisig. Petrinetze. Springer Verlag, 1986. [Smi88] R. G. Smith. The contract net protocol: High-level communication and control in a distributed problem solver. In A. H. Bond and L. Gasser, editors, Readings in Distributed Arti cial Intelligence, pages 357{366. Kaufmann, San Mateo, CA, 1988.