Ž .Computers in Industry 38 1999 103–113

A distributed architecture and negotiation protocol for schedulingin manufacturing systems

Paulo Sousa ), Carlos Ramos 1

( )Instituto Superior de Engenharia do Porto ISEPr IPP , Departamento de Engenharia Informatica, Rua Sao Tome, 4200 Porto, Portugal´ ˜ ´

Abstract

This paper deals with a new architecture and negotiation protocol for the dynamic scheduling of Manufacturing Systems.The architecture is based on two paradigms: Multi-Agent Systems and Holonic Systems. The main contribution in the

warchitecture is the development of Holons representing tasks and resources. The well-known Contract Net Protocol R.Ž . Ž . xDavis, R. Smith, Negotiation as a metaphor for distributed problem solving, Artificial Intelligence, 20, 1 , 1983 63–109

has been adapted to handle temporal constraints and to deal with scheduling conflicts. The purpose of this protocol is todynamically assign operations to the resources of the Manufacturing System to accomplish the proposed tasks. This protocolinvolves a renegotiation phase whenever exceptions appear. It also deals with conflict situations, namely, with the case ofthe ‘indecision problem’. The used approach assumes that deadlines are the most important constraints to consider. Thus theacceptance or refusal of a resource for a specific operation depends on the capability of executing the operation within thespecified deadline. q 1999 Elsevier Science B.V. All rights reserved.

Ž . Ž .Keywords: Intelligent Manufacturing Systems IMS ; Holonic Manufacturing Systems HMS ; Co-operation; Dynamic scheduling

1. Introduction

During recent years, it has been necessary torespond to emerging trends in the ManufacturingSystems. These new directions include the reductionof the dimensions of orders as well as the reductionof life cycles of products. Thus, Manufacturing Sys-tems need to handle the dynamic nature of demands.In fact, in the dynamic scheduling, solutions need tobe rapidly achieved. Scheduling of ManufacturingSystems corresponds to a distributed problem fromthe physical and from the logical point of view.Physically, the Manufacturing System involves sev-

) Corresponding author. E-mail: psousa@dei.isep.ipp.pt1 E-mail: csr@dei.isep.ipp.pt.

Žeral resources NC machines, robots, AGVs, convey-.ors, etc. and from the logical point of view it is also

a distribution problem, because several tasks 2 canbe carried out at the same time. Due to these reasonsthe framework of distributed artificial intelligenceŽ .DAI and Holonic Manufacturing Systems for dy-namic scheduling of industrial tasks is proposed.

The paper presents a new architecture and Negoti-ation Protocol for dynamic scheduling of Manufac-turing Systems. It is made under the premise that due

Ž .dates deadlines for the tasks to be met. Section 2

2 Task means a set of operations to perform resulting in a finalŽ .item e.g., make a chess pawn . An operation is a small part of a

task, for example, in the ‘make a chess pawn’ task, one operationis drilling or painting.

0166-3615r99r$ - see front matter q 1999 Elsevier Science B.V. All rights reserved.Ž .PII: S0166-3615 98 00112-2

( )P. Sousa, C. RamosrComputers in Industry 38 1999 103–113104

briefly describes some Distributed Intelligence con-cepts. This section also presents the concept of

ŽHolonic Manufacturing Systems an extended expla-nation of these concepts was given by Sousa and

w xRamos 13 . Section 3 describes a new architecturefor the dynamic scheduling of Manufacturing Sys-tems and Section 4 illustrates how the NegotiationProtocol is established and presents the renegotiationphases for handling exceptions. Finally, conclusionsare presented in Section 5.

2. Multi-Agent Systems and Holonic Manufactur-ing Systems

Two scientific communities are developing workrelated with Intelligent and Distributed Systems forManufacturing. For Artificial Intelligence re-searchers, the Distributed Artificial Intelligence isthe solution for distributed problems. On the otherhand, some researchers from the Manufacturing areaprefer to use the Intelligent Manufacturing Systemconcept, where Holonic Manufacturing Systems ispresented as the solution for distribution of tasks. Asit is usual in these situations similar concepts appearwith different names.

2.1. Distributed Artificial Intelligence and Multi-Agent Systems

During the last two decades, efforts have beenmade for a continuous enhancement of IntelligentSystems to deal with increasingly complex problems.Such systems soon became too heavy to be imple-mented as a centralised control program in only onecomputer. Fortunately, Distributed Computing hasalready given some answers to the problem of howto efficiently implement communities of interactivesystems. A new research area appeared to cover theproblem posed by the integration of Artificial Intelli-gence and Distributed Computing. This area wasDistributed Artificial Intelligence. DAI was firstlyidentified as a kind of problem solving where thecomputation and inference were distributed in the

w x w xlogical or physical sense 8 . Davis 4 stated thatDAI is concerned with those problems for which asingle problem solver, single machine or locus ofcomputation seems inappropriate.

DAI methodologies also lead to two differentapproaches for Intelligent Systems distribution: Dis-

Ž .tributed Problem Solving DPS and Multi-AgentŽ .Systems MAS . In DPS, there is a set of modules or

nodes co-operating to solve a specific problem. Theknowledge about the problem and its solution isdivided among all nodes of the system. In MAS thedistinction between problem solving and co-oper-ation is much clearer. The attention is on the co-ordination process between intelligent autonomousagents. The negotiation between different Agents isone of the most important problems to solve inDistributed Intelligent Systems. Whenever severalsystems, or resources, are able to execute the sametasks or operations a negotiation protocol establish-ing relationships between contractors and possible

Žcontracted Agents is very important e.g., Contractw x.Net Protocol, 5

2.2. Intelligent Manufacturing Systems and HolonicManufacturing Systems

Ž .Intelligent Manufacturing Systems IMS in gen-eral and Holonic Manufacturing Systems in particu-lar are new concepts in the Manufacturing arena.

w xSolberg and Kashyap 12 analysed the results ofsome independent studies on the changes that arerocking the manufacturing world. Among the trendswhich virtually all observers have noted are: globali-sation; increasing complex and competitive markets;shortened product life-cycles; increasing require-ments for quality; increasing customisation of prod-ucts; faster paced advances in technology; rapidlyexpanding options in materials and processes; andincreasing skill requirements. Additionally, one mustconsider the effect of environmental constraints forc-ing changes in products and processes and the costof energy.

The new trends on manufacturing gave origin to anew concept: Intelligent Manufacturing Systems. Ini-tially, IMS was a vision of a future manufacturing

w xscenario 15 : ‘‘The Intelligent Manufacturing Sys-tem takes intellectual activities in manufacturing anduses them to better harmonise human beings andintelligent machines integrating the entire corpora-tion from marketing through design, production anddistribution, in a flexible manner which improvesproductivity.’’ IMS will possess the innate ability to

( )P. Sousa, C. RamosrComputers in Industry 38 1999 103–113 105

respond, promptly and correctly, to changes in re-quirements. They differ from conventional Manufac-turing Systems—even advanced ones—in their in-herent capability to adapt to changes without exter-nal intervention.

The underlying idea behind Holonic Manufactur-Ž .ing Systems HMS is to provide a dynamic and

decentralised manufacturing process, in which hu-mans are effectively integrated, so that changes canbe made dynamically and continuously. HMS are

w xbased on the notion of Holon 6 —combination fromŽ .Greek holos whole with the suffix on which, as in

proton or neutron, suggests a particle or part. AHolon means simultaneously a whole and a part ofthe whole. Thus, a Holon can be made up of otherHolons. This feature distinguishes holons fromagents. A Holon is autonomous and co-operative and

Žsometimes intelligent. Each production unit e.g. NC.machine can be a Holon and these Holons co-oper-

ate with each other in order to manufacture products.w xAs it was observed by Valckenaers et al. 14 , it is

expected that rigid, static and hierarchical Manufac-turing Systems will give way to systems that aremore adaptable to rapid change. As an alternative tohierarchy it appears the concept of holarchy as asystem of holons that can co-operate to achieve agoal or objective. A holonic Manufacturing Systemis a holarchy that integrates the entire range ofmanufacturing activities from order booking throughdesign, production, and marketing to achieve the

w xagile manufacturing enterprise. See Ref. 13 for aglossary of HMS conceptsrproperties and Refs.w x1,2,7 for some examples of systems that have usedholonic approaches in industrial scenarios.

3. Holonic architecture for Manufacturing Sys-tems

There can be several holarchies in a Manufactur-ing System. However, this paper will focus princi-pally on the Scheduling Holon.

3.1. The holonic architecture

Fig. 1 illustrates the proposed holonic architecturefor Manufacturing Systems. The attention of this

Fig. 1. The Holonic architecture.

architecture will be focused in the areas of Processand Production Planning.

This figure intends to illustrate part of a Manufac-turing System holarchy and it is important for under-standing the Holon concept. In Fig. 1 some resourcesŽ . Žmachines, robots, etc. and tasks manufacturing

. Žorders are grouped in a Scheduling Holon later, itwill be defined how these holons co-operate for

.scheduling orders in a Manufacturing System .Two important attributes of holons are depicted in

this figure:1. A Holon can be made up of others holons. For in-

stance the Scheduling Holon can be grouped toŽ .other holons e.g. Stock Management Holon, etc.

to define the Production Planning Holon; and2. Holons can be part of several holons. For exam-

ple, the Resource Holons of Fig. 1 are membersof the Scheduling Holon and of the Process Plan-ning Holon.Clearly this kind of architecture is much more

flexible than the static and traditional CIM architec-tures. However, a great effort must be put in theco-ordination between holons to maintain the overallsystems coherence.

3.2. The scheduling holon

w xBongaerts et al. 3 identified three types of basicŽ .building blocks—holons—in a HMS: i product

Ž . Ž .holons, ii resource holons, and iii order holons.The proposed architecture also involves ResourceHolons, but deals with manufacturing tasks insteadof orders. The Product Holon is part of the ProcessPlanning Holon and not of the Scheduling Holon.Fig. 2 represents the architecture of the SchedulingHolon and its components.

( )P. Sousa, C. RamosrComputers in Industry 38 1999 103–113106

Fig. 2. Scheduling Holon’s architecture.

The different components involved are listed be-low.

Ø Resources are the basic components of theŽManufacturing System robots, NC machines, con-

.veyors, etc. or they can be cells made up of basicresources. A Holon represents each resource and

Žeach cell still in this case there is a holon for each.resource in the cell . The number of resources does

not vary, except when resources are added to orremoved from the Manufacturing System.

Ø A Resource Holon represents the current situa-Žtion of one resource its status; delivered activity;

.and activity yet to be done . The activity of theresource is represented into an agenda. The agenda isthe sequence of operations to be carried out and itspecifies the expected duration for these operations

w xas well as the free time intervals of the resource 10 .The activity of a resource changes according to theoperation of the resource and according to the dy-

Žnamic situation of the Manufacturing System new.orders, failures and delays in other resources, etc. .

Ø Task Holons represent the possibilities to exe-w xcute a plan for a task into the plan structure 9 . Once

launched, they directly negotiate with the appropriateResource Holons. A Task Holon has a birth anddeath. During its existence each of these holons isresponsible for monitoring the progress of the work,and act accordingly if anything unpredictable hap-pens. The Task holon will have a Control Systemwith a monitor–detect–react loop for process moni-toring and control.

Ø The Task Manager is the user interface to thesystem. It receives orders for new tasks. This Holonis responsible for launching Task Holons whenever anew task is ordered. Besides, the Task Manager isresponsible for dealing with dynamic changes of task

Žconditions e.g. when the user changes the deadline.of a task .

Each holon has a Constraints module that handlessome knowledge and heuristics from production foreach special implementation. This module helps find-ing answers for questions like ‘‘if there are twoidentical production units that only differ in the

Žamount of time they take to perform a task a new.machine was bought but the old one is still running ,

which one is best to choose?’’

4. Negotiation protocol

The proposed architecture supports a negotiationprotocol between all parts of the system. This proto-

Žcol is adapted to handle conflicts mainly the indeci-.sion problem and dynamic changes in the system.

4.1. Negotiation phase

The example used during this section describes asystem with three resources—A, B and C—and onetask consisting of tree operations—op1, op2 and op3—that must be done sequentially. Resource A canexecute op1; Resource B op2; and Resource C bothop2 and op3.

Fig. 3 illustrates the first two steps of the Negotia-tion Protocol for contracting resources for the execu-tion of a task.

Fig. 3. Task announcement and resource request.

( )P. Sousa, C. RamosrComputers in Industry 38 1999 103–113 107

When a new request for task execution appears,the user specifies the name of the task to be carriedout as well as its deadline. The Task Manager re-ceives information from the user and will inform thetask Holon about the deadline and other constraintsof the task. The format 3 of the request for taskexecution is as follows:

� 4NoP, Item, TimeWindow, Const , TDŽ .where:Ø NoP is the number of parts to manufacture;Ø Item identifies what is to manufacture;Ø TimeWindow is the time interval in which the

Žscheduling makes sense the superior limit isassigned based on the due date for the manufac-

.turing order ;Ø Const represents a constraint imposed to the task

Že.g. precision, repeatability, compliance, stabil-.ity, uncertainty ; and finally

Ø TD is the task descriptor for identifying the task.This message is sent from the Task Manager to

the Task Holon and it will be referred as the TaskAnnouncement Message.

After receiving the announcement from the taskmanager, the first thing the Task Holon does is to getthe basic plan—and some alternative plans too—forthe manufacturing of the requested item. This is doneby interfacing the Scheduling Holon with the ProcessPlanning Holon. Plans are generated by a system

Žcalled TPMS Task Planning for Manufacturing Sys-. w xtems 11 . TPMS automatically generates a high

level plan for a task given its precedence graph.The task Holon receives a message with the fol-

lowing information:

� 4 � 4 � 4BPlan, Resource , BC , AltPlan, AltRes� 4Ž .where:Ø BPlan is the basic plan for executing one se-

quence of operations;Ø Resource is a resource needed for this plan;Ø BC is a basic component this task uses;Ø AltPlan is an alternative plan for this task;Ø AltRes is a resource used in the alternative plan.

3 Ž.The following notation is used in message’s format: group�4or structure listrrepetition.

A plan is a list of nodes, each node havingŽinformation about an operation name, resource, du-

.ration, tools and components .At this moment, the Task Holon knows the se-

quence of resource operations to execute. The nextstep in the Negotiation Protocol is the proposal ofoperations to the resources or cells. However, toguarantee the deadline, the negotiation between theTask Holon and the Resource Holons will havetwo phases: the forward influence phase and thebackward influence phase. The algorithm forscheduling has been adopted from a method devel-oped for centralised dynamic scheduling that is well

w xdescribed by Ramos et al. 10 .The Task Holon will contact all resources able of

performing each operation with the Resource Re-quest Announcement message. This message has thefollowing format:

� 4 �NoO, Op, TimeWindow, Const , TD, PrevOp,Ž� 4 � 4ResPrevOp , NextOp, ResNextOp4 � 4 .

where:Ø NoO is the number of operations to be executed;Ø Op is the operation itself;Ø TimeWindow is the initial time interval for

scheduling;Ø Const is a constraint;Ø TD is the task descriptor;Ø PreÕOp is an operation that must be done prior to

this one;Ø ResPreÕOp is a resource contacted for the previ-

ous operation;Ø NextOp is an operation which Op precedes; andØ ResNextOp is a resource contacted for the next

operation.Once a Resource Holon receives a Resource Re-

quest Announcement it analyses its agenda markingtime intervals where it can execute the requested

Ž .operation see Fig. 4 .Ž .The Resource Holon s contacted for the opera-

Ž .tion s with no predecessors will start theforward influence phase. This phase consists of ‘in-fluencing’ the list of time intervals for the nextoperation with the resulting list from the previous

Ž .operation s —the list of free time intervals of thisresource is considered as the TimeWindow for theother operations that it precedes. Fig. 5 illustratesthis step of the negotiation.

( )P. Sousa, C. RamosrComputers in Industry 38 1999 103–113108

Fig. 4. Resource Holon’s agenda.

Thus each Resource Holon has to wait for amessage from each Resource Holon contacted for the

Ž .operation s preceding it. For each List of InterÕalsmessage, the Resource Holon will generate an ‘in-fluenced’ list of intervals it will pass to the Resource

Ž .Holons of the next operation s . The List of Intervalsmessage has the following format:

� 4Res, Op, TimeInterval , TD, DirŽ .where:Ø Res is the sender resource;Ø Op is the operation;Ø TimeInterÕal is a time interval in which the oper-

Žation could be done this list is important for thew x.scheduling algorithm of the resources 10 ;

Ø TD is the task descriptor; andŽ .Ø Dir is the direction forward or backward

This phase stops when a Resource Holon has nooperations after it.

The backward influence phase starts now. TheŽ . Ž .Resource Holon s of the last operation s will ‘in-

Ž .fluence’ the list of intervals of the operation s pre-ceding it. The List of Intervals message is used topass the list of intervals.

Each Resource Holon has to wait for a list ofintervals from the Resource Holons contacted for

Fig. 5. Forward influencing the list of intervals of operations.

Fig. 6. Backward influencing the list of intervals of operations.

operations after it. The Resource Holon will use thislist to generate the final List of Intervals for thisparticular operation. This list is passed to the Re-source Holons contacted for operations precedingthis one. The backward influence phase ends when

Ž .the Resource Holons for the first operation s receivethe list of intervals from the operations proceeding

Ž .them see Fig. 6 .When each Resource Holon has the final list of

intervals, it responds to the Task Holon with amessage in the following format:

� 4Res, Op, TimeInterval, FreeTime TillEnd , TDŽ .where:Ø Res is the sender resource;Ø Op is the operation to schedule;Ø TimeInterÕal is a possible time interval for

scheduling that operation in this resource;Ø FreeTime TillEnd is the amount of time in which

the resource is free till the specified deadline ifthe Task Holon selects this time interval; and

Ø TD is the task descriptor.

Fig. 7. Resource bid for operations.

( )P. Sousa, C. RamosrComputers in Industry 38 1999 103–113 109

Fig. 8. Ending the negotiation.

This message will be referred as Resource BidŽ .Message see Fig. 7 .

After receiving all Resource Bid Messages theTask Holon selects one Resource Holon that is ableto handle each operation. This selection is based on

Žheuristic rules e.g. the resource having more free.time till the deadline . If the co-ordination between

resources is not possible, the Task Holon tries tochange the selection of Resource Holons for theoperations. If a solution can be found an AcceptanceMessage is sent to the Task Manager, otherwise it issent a Non-Acceptance Message. Before sending theAcceptance Message the Task Holon will notifyresource holons that are not contracted with theCancel Resource Request Message. It will also con-firm the execution of the operations to the selectedResource Holons with a Resource Request Acknowl-edgement message. Fig. 8 illustrates the final stepsof the Negotiation Protocol.

The Resource Request Acknowledge message hasthe following format:

Op, SelTimeInterval, TDŽ .where:Ø Op is the operation;

Ø SelTimeInterÕal is the selected time interval forthe operation;

Ø TD is the task descriptor.When a resource Holon receives a confirmation of

an operation it will mark the selected time interval asoccupied and clears any marks it made for thatoperation in other time intervals. Similarly, if theresource Holon receives a Resource Request Cancelmessage it will clear all the marks it made for that

Ž .operation see Fig. 9 .This protocol serves the purpose of contracting

resources for the execution of a task, but how toguarantee no deadlocks and conflicts between tasksand resources when there are several tasks negotiat-ing at the same time?

4.2. The indecision problem

This protocol by itself does not avoid conflictswhen multiple tasks negotiate with the same re-sources at the same time. Suppose a situation in

Ž .which there are two tasks T1 and T2 and 2 re-Ž .sources RA and RB . T1 starts the negotiation of

operation op1 with RA and RB, imposing a deadlinefor it. RA analyses the deadline for op1 and con-cludes that there is a free time interval in which it ispossible to guarantee the execution of op1 withoutviolating the deadline. Thus RA informs T1 of thisfree time interval. However, when T1 starts theanalysis of the bids from RA and RB to decidewhich resource will take care of op1, RA receives anew request announcement from T2 for another op-eration—op2. Suppose that the only way to guaran-tee the deadline for op2 is to use part of the timeinterval previously obtained for op1. Now, RA hasan indecision, since T1 has not still acknowledged

Ž .RA to execute op1 notice that T1 may choose RB .

Ž . Ž .Fig. 9. Resource Holon’s agenda a operation contracted; b operation cancelled.

( )P. Sousa, C. RamosrComputers in Industry 38 1999 103–113110

Two inconvenient scenarios that may appear are asfollows.

Ž .A RA considers the time interval as reserved forop1 and informs T2 that the execution of op2 is notpossible in the specified deadline. This decision isbad if T1 does not contract RA for the execution ofop1, since in this case RA could execute op2 in thedeadline

Ž .B RA considers the time interval for op1 as freeand informs T2 that the execution of op2 is possiblein the specified deadline. This decision is bad ifboth, T1 and T2, acknowledge RA to execute op1and op2. In this case one of the operations, op1 orop2, will not be accomplished in the specified dead-line.

This kind of problem is called the ‘IndecisionProblem.’ The solution for the ‘Indecision Problem’can be the negotiation task by task or to have somecare to avoid conflicts when supporting multi-tasknegotiation.

4.3. Changes in the negotiation protocol for conflictaÕoidance

As explained earlier, the Task Manager is respon-sible for launching Task Holons. However, there isanother role for the Task Manager, so that it willhelp prevent the Indecision Problem.

The Task Manager will not launch Task Holonsimmediately after receiving requests from users. Itmaintains a priority list of waiting tasks. The nextTask Holon to be launched is the one with highestpriority and that does not conflict with other TasksHolons that are still negotiating with ResourceHolons. The possibility of a conflict is detected whena task needs a resource in part of the same timewindow that another task is currently negotiating.Task’s priority is a function of the customer, thevalue of the order and the due date.

Fig. 10. New steps in the negotiation protocol.

Fig. 11. Performance optimisation.

Fig. 10 shows the first change in the NegotiationProtocol. In order to avoid the Task Manager toknow all the resources each task needs, each TaskHolon—after being announced what to do—sends amessage to the Task Manager with the list of re-sources it will negotiate. This is called the ResourceList message. The Task Holon then waits for a signalfrom the Task Manager to proceed negotiation—theGreen Light message. The Task Manager keeps a listof resources being negotiated and sends the ‘GreenLight’ message if and only if there is no intersectionbetween this list and the Task Holon’s list. Note thatif the time windows do not intersect the indecisionproblem does not arise.

Notice that there may be more than one task innegotiation at the same time and still the indecisionproblem do not arise. There are no simultaneousconflicting tasks, but there may be simultaneoustasks negotiating different resources.

The Task Holon can decide that a specific re-source is no longer important—other resources havea better behaviour—for the task under negotiation.To improve the efficiency of the negotiation process,the Task Holon sends Resource GiÕe-Up messages

Ž .to the Task Manager as shown in Fig. 11 .In this way, the Task Manager will receive infor-

mation on availability of resources before the end ofthe negotiation. Then, other tasks, blocked by thenon-availability of a resource, may start their negoti-ation process. The task manager will check its list of

Fig. 12. An example of renegotiation.

( )P. Sousa, C. RamosrComputers in Industry 38 1999 103–113 111

Ž . Ž .Fig. 13. Resource agenda: a no free interval for the scheduling of the requested operation; b reallocation of an already scheduledoperation to give space for the new one.

waiting Task Holons whenever it receives a ‘Re-source Give-Up,’ ‘Acceptance’ or ‘Non-Acceptance’message to see if it can give green light to any ofthem.

4.4. Renegotiation phase

w xRamos et al. 9 initially described this Renegotia-tion Protocol. Fig. 12 illustrates an example of thisrenegotiation phase.

When the Resource Holon detects a malfunctionthat it cannot recover it decides to inform every TaskHolon that have contracted its work. Notice that theResource Holon may analyse the situation and de-cide not to inform the Task Holons, then it will try torecover from the malfunction and execute its workwith a slight delay. After receiving the MachineFault message from the Resource Holon, the TaskHolon will begin negotiations with other ResourceHolons capable of performing the operations it needs.This negotiation has the same steps explained earlier.The Task Holon communicates the result of this

negotiation to the Task Manager with a TaskRescheduling OK or Task Rescheduling Not OKmessage.

Another situation where renegotiation exists iswhen a rush order comes in or the due date of analready scheduled task is changed. The protocol isthe same as explained in Section 4 except for a fewchanges when there is no free time intervals in theimposed time window. Suppose there is a resourcewith the agenda of Fig. 13a. This resource receives arequest for an operation that takes longer than anyfree interval in the given time window. Taking intoaccount the priority of each task it decides to reallo-cate operation A to free some time, in order to

Ž .execute the new requested operation see Fig. 13b .This change may result in a delay for the task to

which operation A belongs, or it may not if that taskhas some free time in its own time window.

This situation may involve a more drastic reallo-cation like the one in Fig. 14. This kind of changeinvolves a negotiation task to task in which the new

ŽTask Holon has to persuade or bargain, may even

Ž . Ž .Fig. 14. Rescheduling for a new operation: a the request; b reallocation.

( )P. Sousa, C. RamosrComputers in Industry 38 1999 103–113112

.demand the other task holons to give him the re-source time it needs.

5. Conclusions

This paper has presented holonic architecture forthe dynamic scheduling of Manufacturing Systems.It also presented a Negotiation Protocol based on theContract Net Protocol and suitable for the dynamicscheduling of manufacturing tasks. This NegotiationProtocol is able to deal with deadlines and excep-

Žtions since a Task Holon can start a renegotiationphase of the protocol if it is a high priority task justbeing launched or if its priority changes. It will try topersuade other Task Holons to give it the time it

.needs in the resources . While other co-operativecommunities operate with Agents representing re-sources or systems, the architecture proposed herecombines Resource-based Holons with Task-basedHolons. The main advantage is the easy access totask activities that are supported in Task-basedHolons. In some other approaches the resources arenot certain to be contracted when they offer theirbids. This means that when a Resource Holon re-ceives a new request, it does not know if the previ-ously announced operations are to be contracted ornot when several tasks are being contracted at the

Ž .same time ‘indecision problem’ . This will lead tosome uncertainty in the scheduling of the operations.The ‘indecision problem’ is solved without the needto negotiate task by task.

Future work will try to explore some new direc-tions. In real-life Manufacturing Systems the failurein accomplishing a deadline does not imply to abortthe task. Sometimes, the delay in the due date for a

Žtask leads to an additional cost fines imposed by the.consumer or who required the task . This will imply

to have a second type of negotiation between TaskHolons in order to achieve a compromise.

Acknowledgements

ŽThis work is partially supported by FLAD Pro-. Žject 443r93 , JNICT Projects PBICrTPRr2551r95

. Žand PBICrTPRr2556r95 and ESPRIT IMS-WG.Project 21955 .

References

w x1 J. Agre, G. Elsley, D. McFarlane, J. Cheng, B. Gunn,Holonic control of cooling control systems, Rensselaer’s 4thInt. Conference on Computer Integrated Manufacturing andAutomation Technology, 1994.

w x2 L. Bongaerts, P. Valckenaers, H. Van Brussel, J. Wyns,Schedule execution for a holonic shop floor control system,Proceedings of the Advanced Summer Institute on IntelligentControl and Integrated Manufacturing Systems, Lisbon, Por-tugal, 1995.

w x3 L. Bongaerts, J. Wyns, J. Detand, H. Van Brussel, P. Valcke-naers, Identification of Manufacturing Holons, EuropeanWorkshop on Agent Oriented Systems in Manufacturing,Berlin, Germany, 1996.

w x4 R. Davis, Report on the workshop on Distributed ArtificialŽ .Intelligence, SIGART Newsletter 73 1980 42–52.

w x5 R. Davis, R. Smith, Negotiation as a metaphor for distributedŽ . Ž .problem solving, Artificial Intelligence 20 1 1983 63–109.

w x6 A. Koestler, The Ghost in the Machine. Hutchinson, London,1967.

w x7 D. McFarlane, B. Marett, G. Elsley, D. Jarvis, P. Wilbers,Application of Holonic Methodologies to Problem Diagnosisin a Steel Rod Mill, IEEE Int. Conference on Systems, Manand Cybernetics, 1995.

w x8 N. Nilsson, Distributed Artificial Intelligence, Report SRIInternational, Menlo Park, CA, 1981.

w x9 C. Ramos, A Holonic Approach for Task Scheduling inManufacturing Systems, IEEE International Conference onRobotics and Automation, Minneapolis, USA, 1996.

w x10 C. Ramos, A. Almeida, Z. Vale, Scheduling manufacturingtasks considering due dates: a new method based on be-haviours and agendas, International Conference on Industrialand Engineering Applications of Artificial Intelligence andExpert Systems; Melbourne, Australia, 1995.

w x11 J. Rocha, C. Ramos, Plan representation and heuristic genera-tion of operation sequences for manufacturing tasks, data andknowledge systems for manufacturing and engineering,Tempe, Arizona, USA, 1996.

w x12 J. Solberg, R. Kashyap, Research in Intelligent Manufactur-Ž . Ž .ing Systems, Proceedings of the IEEE 81 1 1993 .

w x13 P. Sousa, C. Ramos, Proposal of a Scheduling Holon forManufacturing, PAAM97—The Practical Application of In-telligent Agents and Multi-Agent Technology. London, UK,1997.

w x14 P. Valckenaers, F. Bonneville, H. Van Brussel, L. Bongaerts,J. Wyns, Results of the Holonic Control System Benchmarkat K.U. Leuven, Rensselaer’s 4th International Conference onComputer Integrated Manufacturing and Automation Tech-nology, 1994.

w x15 H. Van Brussel, Working Group Proposal on IntelligentManufacturing Systems, submitted to the Fourth FrameworkProgramme of EC, 1995.

( )P. Sousa, C. RamosrComputers in Industry 38 1999 103–113 113

Paulo Sousa studied informatics at theŽPolytechnic Institute of Porto ISEPr

.IPP , Portugal, where he graduated inIndustrial Informatics. From 1993 to1996, he was an application developer ata Portuguese Software house, in the areaof clientrserver computing. He becamean Assistant Professor at ISEPrIPP in1996, and is currently a PhD student atMinho’s University, Portugal, workingin Holonic Manufacturing Systems. Hismain interests are Distributed Systems,

Manufacturing and Computer Graphics. He can be reached byemail psousa@dei.isep.ipp.pt and his URL is http:rrwww.dei.isep.ipp.ptr ;psousa.

Carlos Ramos received a Bachelor ofScience degree in Electrical Engineering

Ž .from the University of Porto Portugalin 1986. He received the Ph.D. degreefrom the same University in 1993. Cur-rently, he is Co-ordinator Professor inthe Institute of Engineering at the Poly-

Ž .technic Institute of Porto ISEPrIPP .He is Director of the CIM Centre ofISEPrIPP. His main areas of interestare Artificial Intelligence and ComputerIntegrated Manufacturing. He has more

than 100 publications in these areas and co-ordinates several R&Dprojects. Readers can contact him at csr@dei.isep.ipp.pt.