- Email: [email protected]
Generic Framework for Conflict Resolution in Negotiation-Based Agile Scheduling Systems
Copyright © IFAC Intelligent Manufacturing Systems, Gramado - RS, Brazil. 1998
GENERIC FRAMEWORK FOR CONFLICT RESOLUTION IN NEGOTIATION-BASED AGILE SCHEDULING SYSTEMS Ricardo J. Rabelo I; Luis M. Camarinha-Matos 2
I
2
Federal University ofSanta Catarina, Brazil - [email protected] New University ofLisbon, Portugal- [email protected]
Abstract: 1bis paper descnbes a general framework for conflict resolution being implemented on the HOLOS muhi-agent scheduling system. The framework is integrated with the planning and execution supervision activities, emphasizing the importance of local supervision actions. Conflicts are classified in levels and types, and the specific actions for their resolution, carried out dming scheduling genemtion, after its generation and during its execution, are also presented. A significant part of the conflict resolution process is supported by using the user guide negotiation approach. Finally, the decentralized scheduling supervision process is shown. Copyright @ 19981FAC. Keywords: Scheduling algorithms, Agile manufacturing, Distributed artificial intelligence.
I.
INTRODUCfION
• Agile adaptation: fleXIble adaptation of the whole production structure to the given order's requirements. Agility is related to fleXIbility in terms of the internal routing and virtual production areas.
The current scenario of industrial environment can be basically characterized by an effort to produce an ever increasing variety of products, in lower quantities, with higher quality, lower costs and within shorter production times. From the external point of view, industries are exposed to a very competitive, demanding and global market. From the internal point of view, industries have to efficiently accommodate both changes in the external world and d.istmbances in their shop floors. One of the contributions to face that dynamic reality is to provide the industries with agile manufactming scheduling systems. Agility is an emergent requirement for advanced maoufactming scheduling systems. Scheduling is generally defined as the activity of assigning orders to manufactming resources during a certain period of time. An agile scheduling system is one that supports (Rabelo, 1997): • Dynamic scheduling: reaction and dynamic adaptation of the current schedule in the presence of unexpected events, both from the shop floor (like machine failure. tool unavailability and operation lateness) and from the planning level (like changes in order priority and orders cancellation), and;
In fact, the implementation of a system with such capabilities is still a challenge, specially considering that it must remain realistic, coherent and feastble along its execution One of the main reasons for this situation is related with the intrinsic scheduling problem complexity, which is NP~mplete. In a real world production environment there are many operational objectives that may change along the time and that are usually impossible to be achieved simultaneously. The technological. temporal and capacity constIaints associated to the on1ers and to the shop floor are not static and not even known. It means that more important than searching for optimal schedules, it is the generation of fleXIble schedules in which the conflicts due to the current constraints can be fleXIbly relaxed and then solved. The goal is then to generate robust and fleXIble schedules so that the system can keep running without disruptions in the presence of unexpected events (Panmak, et al., 1995).
159
avoid announcement broadcasting. They are also responsible to select the most suitable agent for a certain order after a negotiation process. • Consortium (C): temporary instances created to supervise the execution of a given order by the involved EAAs.
This paper presents a generic framework for conflict resolution developed on top of the HOLOS system a framework to derive instances of multi-agent agile scheduling systems - and that is being refined and reimplemented in the scope of INCO-DC KIT Massyve (Massyve, 1997) and Esprit Prodnet-II (Prodnet, 1996) projects.
2.
Therefore, a schedule is generated and supervised via a cooperative and tight coordinated information exchange among agents.
THE HOLOS SCHEDULING SYS1EM
HOLOS.is a framework specially developed to derive "instances" of agile scheduling systems (Rabel0, 1997). A HOLOS scheduling system is represented by a group of agents configured for a very particular shop-floor and that process and exchange information about orders in order to generate, execute, and supervise a schedule. In this framework an instance of a scheduling system is interactively and semi-automatically derived from a reference model - The HOLOS Generic Architecture (Rabelo, Camarinha-Matos, 1995) - supported by a specific agent-oriented methodology the HOLOS Methodology (Rabelo, Camarinha-Matos, 1996).
Each agent has its graphical user interface, giving to the user the possibility to both supervise the system and to intervene in some situations. In the case of the EAA agents, they are linked to the manufacturing resources they are associated to. For example, a particular EAA, identified as "Robot_ Scara", can establish a communication with the corresponding physical entity existing in the shop-floor. The communication with the CIM-IS is made using a subset of the S1EP/SDAI (STEP Data Access Interface) protocol (Fowler, 1992). The inter-agent communication is supported by a specific high-level 1997). The negotiation protocol (Dionisio, communication between the EAAs and the manufacturing resources uses a subset of the MAPIMMS (Manufacturing Message Specification) protocol (Mackiewicz, 1994), supported by a wrapper (Rabelo, Camarinha-Matos, 1994).
Figure 1 illustIates a global view of a particular HOLOS multi-agent scheduling scenario. The scheduling system is viewed as an application that receives I feeds data from I to a CIM Information System (CIM-IS), receiving I providing information from I to other applications. Differently from classical systems, HOLOS is not a unique and comprehensive system, but rather a collection of distributed processes with some autonomy, independence and communication capabilities (agents). A HOLOS system is constituted by a set of instances of the following HOLOS agents' classes: • &heduling Supervisor (SS): instance agent that performs the global scheduling supervision and it is the unique system's "door" to other systems. • Enterprise Activity Agents (E4A): instances that are directly associated to the manufacturing resources (robots, CNC machines, etc.), representing them into the agents community. These agents are the real executors of orders. • Local Spreading Centers (LSC): instances that represent functional clusters of EAAs in order to existing applications
3.
SCHEDULING BOUNDARIES: DEFINING RESPONSmILITIES AND LOCAL SUPERVISION
The scheduling activity cannot be seen as an isolated activity, but one with a stronger interaction with other activities, mainly with the planning and the execution supervision. Thus, in order to provide a more comprehensive environment for the resolution of scheduling problems a clear identification of their boundaries must be carried out firstly. It means to identify the level of responsibilities of each of these activities, i.e. the recognition of the set of conflicts and events that can occur - and that should be solved - in their scope of actions.
HOLOS scheduling system Instances of
elM-IS
Shopfloor
Fig. I. A particular HOLOS multi-agent scheduling system. 160
The planning activity can be roughly defined as the specification of the actions (orders) needed to reach a given objective, and complying with a group of constraints. In other words, it is related with the specification of "'how" and in "which sequence" the tasks should be processed. In this work the areas of supply-chain management, master production scheduling and material requirements planning are clustered in the general planning activity. The scheduling activity is responsible for the specification of "when" and "'who" will process each of the planned tasks. The supervision activity comes from the need to supervise the scheduling execution. It means to monitor the production from the level of each manufactming resource to the level of the factory as a whole, checking the current results against what was scheduled.
completely independent, the SUpeIV1Slon actions should also support this tendency. The supervision framework presented is decentralized, executed at local level. This means that when some deviation in a particular level is detected, the corresponding activity should take the respoDSlbility to try to solve the problem locally, within its action scOpe. Only if it cannot be solved, then problem can be reported/passed to the upper level. At the end, in the case the problem is considered unsolvable, then it is considered up to higher levels of decision.
4.
CONFLICTS
Conflicts are events that can happen in any moment within the enterprise and that provoke distmbances in a schedule during its generation, after its generation or during its execution, normally affecting the current schedule (capacity, technological and temporal) constraints. Regarding the framework shown in figure 2, a conflict in the scheduling system can come from three sources: • Planning: when the planning activity introduces modifications and/or cancellation in a given order after the orders have already been loaded. In the HOLOS system, this kind of conflict notification is received by the SS agent, which in turn propagates it to the affected Consortium agents. The conflicts here are related to order cancellation, ("random") arrival of a new order, or alteration in the specification of the order; • Execution Supervision: this level deals with conflicts occurred in the shop-floor and that are detected by the execution supervision activity and communicated to the scheduling system. In the HOLOS system, this kind of conflict is received by the EAA agents, which in turn propagate it to the affected Consortium agents. These conflicts have two basic causes: - delays: when the required resources (material/components, human resources, tools or programs) are not available in the scheduled time at the right place;
There is a natural hierarchical relationship among the planning, scheduling and supervision activities. Planning feeds the scheduling activity with an initial plan and with changes in the current plan, whose result (a schedule) is supervised when put in execution (by the dispatcher). In each one of these activities there is a supervision action, respoDSlble for taking care of deviations from what has been planned In other words, to compare the accomplishment status of the plan's goals versus the achieved results; to analyze, by means specific performance indicators, the expected results in terms of scheduling quality versus the results actually obtained; and to check the correctness of the execution of the scheduled operations versus what is being verified. The scheduling activity may require alternative process plans, which in turn has some relation with the product model. Therefore, a truly production planning and control system can be characterized by the existence of decentralized decision areas, whose support systems are distributed and autonomous, but strongly cooperative. Figme 2 shows this integrated framework for agile scheduling.
In order to support agile reactions at the shop-floor level, a gradual increase of the autonomy levels has been observed in those activities. As they are not .; w. . ______ .;·.': .' . • Product , . .'
~ Design r . . -----!-':"-- ."
,',
• • •
•
'C'
....
"1 , "
',°
0
'.:" ' .
.1----,_-' . " .•.
EXecutiOn.
· s~ .
Fig. 2. Integrated framework for agile scheduling.
161
•
- execution errors: machine failme, tooling
5.
problem, program error, arrival of a defective component at the machine, or arrival of a wrong componentltool/program at the machine. • Scheduling: deals with the conflicts occwred within the scheduling activity both when the scheduler cannot schedule a given order and when the user evaluates the current schedule and decides to correct some deviation. These conflicts can happen independently of the other two sources. In the HOLOS system, this kind of conflict is received by the Consortium agents, which in turn propagate it to the SS agent if they cannot solve the conflict locally.
An entire order (a component or an end-product) to be scheduled is represented by a set of inler-related orders, whose manufacturing processes are expressed by the respective process plans (operations). The HOLOS approach for the scheduling generation applies the job-centered strategy (Fox, 1994). It means that a next order is only scheduled if and only if the previous one has been successfully scheduled. One of the main differences between the schedules generated by the HOLOS system and those ones generated by tIaditional scbedulers is that in the former case there is not a unique and comprehensive schedule, but rather a collection of distributed "pieces" of schedules, one per order, supervised by the respective Consortium agent 1berefore, when a conflict happens, there are different objectives to be pursued according to the general scheduling phase, regarding the job-centered strategy: - schedule generation: to guarantee that there will be the adequate manufacturing-resources for one order; - after the schedule generation: to guarantee that all the previously scheduled orders keep scheduled in the same manufacturing-resources; - during the scheduling execution: to guarantee that all the schedules tmder supervision by the Consortium agents will be executed..
The occurrence of a conflict in one of these three main scheduling phases may imply in rescheduling, which is an undesirable but most of times an inevitable action. Because rescheduling is usually a high time-demanding operation, the strategy is to try to reschedule the schedule "portions" not affected by the conflict, similarly to the iterative repair approach (Zweben, 1994), but adapted to a mnlti-agent control arcbitectme. Thus, when a conflict takes place, it is necessary to identify its severity, which can be classified into three levels:
- slight. when the conflict can be absoIbed by the affected manufacturing resource, via backward or forward operations in its agenda (managed by its respective agent), based on the earliest start time and latest end time parameters of each order;
The conflict resolution framework comprises seven main actions, showed in the figme 4: 1- Conflict detection and identification. Reception of the conflict by an agent (see figure 3).
- medium: when the conflict affects other orders in other manufacturing resources but only at temporal level, i.e. its resolution does not imply changing the equipment assignment;
2- Identification of the orders affected by the conflict. A conflict normally refers to one order. However, considering that most orders are inter-
- serious: when the conflict affects other orders in other manufacturing resources such that the previously assigned orders should be rescheduled in other equipment in order to solve the conflict.
related, it is necessary to evaluate which other orders are consequeolly affected too, i.e., which orders will get delayed if a rescheduling is not carried out.
The figme 3 illustrates bow the conflict scenario is managed within the HOLOS multi-agent control architectme. This scenario represents the (local) supervision actions within the scheduling activity (figme 2). In other words, it means that each agent has some capabilities for dealing with some conflicts.
~
3- Identification of the general scheduling phase affocted by the conflict. Once the orders affected by a conflict were identified, it is necessary to
verify in which scheduling phase they are, i.e. scheduling generation (when the Consortium agents are being created), after the scheduling generation (when the Consortium agents bad been created), or during the scheduling execution (when the Consortium agents are in execution).
Planni ng
~conflicts Schedul ing conflict !!!
t ComorIia in aabOO
(scbecalIiDg ~oo)
ConIartia aaled (g.....-.red lCbedIaes)
CONFLICT RESOLUTION
4- Identification of the type of conflict (planning, execution, or scheduling). Depending on the type of conflict, different actions are necessary to be
Coaoonia in """"";011
executed, considering the general objective of each scheduling phase, as descnbed before.
(~eotOCUIian)
Execution confl icts
5- Analysis of the conflict severity level (slight, medium, or serious). 6- Four possible actions, according to the scheduling general phase and conflict severity: 6.1- Change in the order's attributers). As
Fig. 3. Conflict scenario within HOLOS.
mentioned in the chapter 2, a (re)schedule is
162
is more critical if it is carried out during the execution phase since there are components already being processed / finished. It is usually an action "ordered" by the planning activity. 7- Conflict resolution analysis and schedule evaluation. After the actions carried out in the previous step, it is necessary to analyze if the conflict was solved. Besides that, it is desirable that the user evaluates the quality of the new schedule, applying some performance indicators (orders delay, completion time, machine utili.zation, WIP, etc.) upon the schedule.
genernted through the exchange information, among agents, about a given order (the attributes of each of its operations, see Fig. 5). When a conflict occurs, some attribute(s) can be modified in order to "relax" some of the current order constraints (specified in the attributes' content). It means to apply a negotiation process (Rabelo, Camarinha-Matos, 1994), initiated when the user selects, one by one, the operation's attributes that should be relaxed. Once this is done, the order should be re-announced to the agents so that at the end of this process an agent that better fits the new constraints can be found. This is the main and first action used by the HOLOS system to (tIy to) solve a conflict, and it is applied in all scheduling phases, for all kinds of conflicts. 6.2- Order re-announcement. This action can be used "after the scheduling generation" and "during scheduling execution", mainly for the execution conflicts / execution errors (there are some particular cases in which this action can be used for scheduling conflicts). It means to reannounce an order aiming at finding a manufactming-resource (an EAA agent) available to replace one that failed. 6.3- Loading an alternative process plan (when eristing). This is mainly used for execution conflicts and for some cases of scheduling conflicts. When the conflict cannot be solved after the execution of the two previous actions, the option is to get an existing alternative process plan in order to find a manufacturing-resource that fits the new constraints requirements (see figure 2). 6.4- Order cancellation. In spite of being a "radical" solution, this can be applied in all scheduling phases, for all kinds of conflicts. It is used when there is no solution, from the scheduler point of view, for the conflict after applying all the previous alternatives. However, it
This framework for conflict resolution is based on a
strong inter.lction with the (expert) end-user, ie., on non-automatic solutions. Even considering that the introduction of a human-based decision-making process may decrease the system performance, it seems to be a realistic approach. The constraints are so volatile and unforeseen to some extent that is extremely difficult to provide the system with the knowledge - specially the empirical one - for automatic and optimum solutions.
As it can be noted, the Consortium agents have a key importance from the supervision point of view. A Consortium is a temporary agent created to supeIvise the execution of a given order by a virtual cluster of resource-agents (EAAs) dynamically selected to process it (Figure 5). Because there are as many Consortium agents as orders scheduled, each Consortium is responsible to supervise the respective order's schedule (a distn"buted schedule). That selection is supported applying a negotiation process. In the same way that in the integrated framework (figure 2) the importance of local supervision is emphasized, the Consortium concept represents the way a local supervision is implemented within the HOLOS system (ie. within the scheduling activity).
schecilJing or ciJring the scheduing
<:elCeCUtion
CXlnfict
plannng _4'l'--~ confict
genenttion
scheciJ.,g or conftct _
analysis of the _ 8fIected orders
analysis of the
sche
sfter the <:eJC8CUtion CXlnfict scheduing
plannng
generation
alamative process plan
conftct
Z
execu1ion confictll:l--~~
ciJringthe scheduling
exeaJlion
pl;wlnng confict
Fig. 4. Conflict resolution framework.
163
/C----
aniwl of a
ne.order
way conflicts are classified and treated, during the scheduling generation, after its generation, and during its execution was shown.
It firstly tries to solve the problem locally (reasoning about the agendas of the EAAs agents it supervises) and it contacts the SS agent (the global supervisor, which can contact other consortia and then propagates the conflict) only when it cannot solve the conflict. It means that, in spite the HOLOS agents are hierarchical. the decision-making process is not centralized. 6.
The implementation work is proceeding on a PC / Window-NT / C++ platform. The next phase will include the test of this framework in ' two Brazilian enterprises, in the scope of two European projects. Next steps after its initial evaluation are related to the introduction of new functionalities into the agents in order to deal with other perspectives of agile scheduling, such as order splitting, conflicts coming from the supply-chain, virtual enterprise scheduling, and the selection of agents based on global criteria (Rabelo et al., 1998).
CONCLUSIONS AND FUTURE WORK
This paper described a general framework for conflict resolution in a negotiation~ agile scheduling system. This framework is based on a multi-level and local / decentralized supervision approach, strongly supported by the end-user. The
op id op time op Jlr<>CeSS type op tolenmoo op due da1e
...
op)_t ea
procesS"p1an id
Fig. 5. The Consortium concept as the main enabler for local supeIVision. Rabelo, R ; Camarinha-Matos, L.M (1994). Negotiation in Multiagent Based Dynamic Scheduling, InterDational Journal on Robotics and Computer Integrated Manufacturing, Vol 11 N 4, pp.303-31O, Pergamon. Rabelo, R; Camarinha-Matos, L.M (1995). A Holistic Control Architecture Infrastructure for Dynamic Scheduling. In: ArtifiCial Intelligence in Reactive &heduling, (eds. Roger Kerr e Elizabeth Szelke), Chapman & Hall, pp.78-94. Rabelo, R ; Camarinha-Matos, L.M (1996). Deriving Particular Agile Scheduling Systems using the HOLOS Methodology, in International Journal in Infonnatics and Control, Vol 5 N 2, pp.89-106, Romania.. Rabelo, RJ. (1997). A Framework for the Development of Manufacturing Agile Scheduling Systems - A Multiagent Approach, Ph.D. Thesis, New University of Lisbon, Portugal. Rabelo, RJ.; Camarinha-Matos, L.M; Afsarmanesh, H. (1998). Multi-agen1 perspectives to agile scheduling. In: Intelligent Systems for Manufacturing (ed.s L.M. Camarinha-Matos, H. Afsarmanesh, V. Marik), Kluwer Academic Publishers, pp.51-66, Boston. Zweben, M ; Daun, B.; Davis, E.; Deale, M (1994). Scheduling and Rescheduling with Iterative Repair, Intelligent &heduling (eds. M Zweben and M Fox), Morgan Kallfmann, pp.241-255.
ACKNOWLEDGMENTS This work has been supported by CNPq (The Brazilian Council for Research), project ProTeM-CC 680120196-3 PRODNET-ll, and European Union, projects 962219 !NCO-DC MASSYVE and Esprit 22647 PRODNET-II.
REFERENCES Dionisio, R (1997). Protocolo HOLOS: Uma Proposta para Comunicayao entre Agemes em Sistemas de Escalonamento da Produyao, M.Sc. Thesis, New University of Lisbon, Portugal. Fox, M. (1994). ISIS: A Retrospective, Intelligent &heduling (eds. M Zweben and M Fox), Morgan Kaufmann, pp.3-28. Fowler, 1. (1992) Proposal for the STEP Data Access InteIface Specification, STEP Implementation Specifications Committee, NIST. Mackiewicz, R (1994). An Overview to the Manufacturing Message Specification, in h1tp:lIlitwww.epfl.ch/-mms. Massyve (1997). h1tp://centamus.dee.fct unl.pt/-massyve. Parunak, V. D . (1995). An EmeIgem Approach to Systems of Physical Agents, Proceedings AAAI Spring Symposium on Software Alchitectures for Physical Agents. Prodnet (1996). h1tp:llcupido.uninova.ptl-prodnet
164
GENERIC FRAMEWORK FOR CONFLICT RESOLUTION IN NEGOTIATION-BASED AGILE SCHEDULING SYSTEMS Ricardo J. Rabelo I; Luis M. Camarinha-Matos 2
I
2
Federal University ofSanta Catarina, Brazil - [email protected] New University ofLisbon, Portugal- [email protected]
Abstract: 1bis paper descnbes a general framework for conflict resolution being implemented on the HOLOS muhi-agent scheduling system. The framework is integrated with the planning and execution supervision activities, emphasizing the importance of local supervision actions. Conflicts are classified in levels and types, and the specific actions for their resolution, carried out dming scheduling genemtion, after its generation and during its execution, are also presented. A significant part of the conflict resolution process is supported by using the user guide negotiation approach. Finally, the decentralized scheduling supervision process is shown. Copyright @ 19981FAC. Keywords: Scheduling algorithms, Agile manufacturing, Distributed artificial intelligence.
I.
INTRODUCfION
• Agile adaptation: fleXIble adaptation of the whole production structure to the given order's requirements. Agility is related to fleXIbility in terms of the internal routing and virtual production areas.
The current scenario of industrial environment can be basically characterized by an effort to produce an ever increasing variety of products, in lower quantities, with higher quality, lower costs and within shorter production times. From the external point of view, industries are exposed to a very competitive, demanding and global market. From the internal point of view, industries have to efficiently accommodate both changes in the external world and d.istmbances in their shop floors. One of the contributions to face that dynamic reality is to provide the industries with agile manufactming scheduling systems. Agility is an emergent requirement for advanced maoufactming scheduling systems. Scheduling is generally defined as the activity of assigning orders to manufactming resources during a certain period of time. An agile scheduling system is one that supports (Rabelo, 1997): • Dynamic scheduling: reaction and dynamic adaptation of the current schedule in the presence of unexpected events, both from the shop floor (like machine failure. tool unavailability and operation lateness) and from the planning level (like changes in order priority and orders cancellation), and;
In fact, the implementation of a system with such capabilities is still a challenge, specially considering that it must remain realistic, coherent and feastble along its execution One of the main reasons for this situation is related with the intrinsic scheduling problem complexity, which is NP~mplete. In a real world production environment there are many operational objectives that may change along the time and that are usually impossible to be achieved simultaneously. The technological. temporal and capacity constIaints associated to the on1ers and to the shop floor are not static and not even known. It means that more important than searching for optimal schedules, it is the generation of fleXIble schedules in which the conflicts due to the current constraints can be fleXIbly relaxed and then solved. The goal is then to generate robust and fleXIble schedules so that the system can keep running without disruptions in the presence of unexpected events (Panmak, et al., 1995).
159
avoid announcement broadcasting. They are also responsible to select the most suitable agent for a certain order after a negotiation process. • Consortium (C): temporary instances created to supervise the execution of a given order by the involved EAAs.
This paper presents a generic framework for conflict resolution developed on top of the HOLOS system a framework to derive instances of multi-agent agile scheduling systems - and that is being refined and reimplemented in the scope of INCO-DC KIT Massyve (Massyve, 1997) and Esprit Prodnet-II (Prodnet, 1996) projects.
2.
Therefore, a schedule is generated and supervised via a cooperative and tight coordinated information exchange among agents.
THE HOLOS SCHEDULING SYS1EM
HOLOS.is a framework specially developed to derive "instances" of agile scheduling systems (Rabel0, 1997). A HOLOS scheduling system is represented by a group of agents configured for a very particular shop-floor and that process and exchange information about orders in order to generate, execute, and supervise a schedule. In this framework an instance of a scheduling system is interactively and semi-automatically derived from a reference model - The HOLOS Generic Architecture (Rabelo, Camarinha-Matos, 1995) - supported by a specific agent-oriented methodology the HOLOS Methodology (Rabelo, Camarinha-Matos, 1996).
Each agent has its graphical user interface, giving to the user the possibility to both supervise the system and to intervene in some situations. In the case of the EAA agents, they are linked to the manufacturing resources they are associated to. For example, a particular EAA, identified as "Robot_ Scara", can establish a communication with the corresponding physical entity existing in the shop-floor. The communication with the CIM-IS is made using a subset of the S1EP/SDAI (STEP Data Access Interface) protocol (Fowler, 1992). The inter-agent communication is supported by a specific high-level 1997). The negotiation protocol (Dionisio, communication between the EAAs and the manufacturing resources uses a subset of the MAPIMMS (Manufacturing Message Specification) protocol (Mackiewicz, 1994), supported by a wrapper (Rabelo, Camarinha-Matos, 1994).
Figure 1 illustIates a global view of a particular HOLOS multi-agent scheduling scenario. The scheduling system is viewed as an application that receives I feeds data from I to a CIM Information System (CIM-IS), receiving I providing information from I to other applications. Differently from classical systems, HOLOS is not a unique and comprehensive system, but rather a collection of distributed processes with some autonomy, independence and communication capabilities (agents). A HOLOS system is constituted by a set of instances of the following HOLOS agents' classes: • &heduling Supervisor (SS): instance agent that performs the global scheduling supervision and it is the unique system's "door" to other systems. • Enterprise Activity Agents (E4A): instances that are directly associated to the manufacturing resources (robots, CNC machines, etc.), representing them into the agents community. These agents are the real executors of orders. • Local Spreading Centers (LSC): instances that represent functional clusters of EAAs in order to existing applications
3.
SCHEDULING BOUNDARIES: DEFINING RESPONSmILITIES AND LOCAL SUPERVISION
The scheduling activity cannot be seen as an isolated activity, but one with a stronger interaction with other activities, mainly with the planning and the execution supervision. Thus, in order to provide a more comprehensive environment for the resolution of scheduling problems a clear identification of their boundaries must be carried out firstly. It means to identify the level of responsibilities of each of these activities, i.e. the recognition of the set of conflicts and events that can occur - and that should be solved - in their scope of actions.
HOLOS scheduling system Instances of
elM-IS
Shopfloor
Fig. I. A particular HOLOS multi-agent scheduling system. 160
The planning activity can be roughly defined as the specification of the actions (orders) needed to reach a given objective, and complying with a group of constraints. In other words, it is related with the specification of "'how" and in "which sequence" the tasks should be processed. In this work the areas of supply-chain management, master production scheduling and material requirements planning are clustered in the general planning activity. The scheduling activity is responsible for the specification of "when" and "'who" will process each of the planned tasks. The supervision activity comes from the need to supervise the scheduling execution. It means to monitor the production from the level of each manufactming resource to the level of the factory as a whole, checking the current results against what was scheduled.
completely independent, the SUpeIV1Slon actions should also support this tendency. The supervision framework presented is decentralized, executed at local level. This means that when some deviation in a particular level is detected, the corresponding activity should take the respoDSlbility to try to solve the problem locally, within its action scOpe. Only if it cannot be solved, then problem can be reported/passed to the upper level. At the end, in the case the problem is considered unsolvable, then it is considered up to higher levels of decision.
4.
CONFLICTS
Conflicts are events that can happen in any moment within the enterprise and that provoke distmbances in a schedule during its generation, after its generation or during its execution, normally affecting the current schedule (capacity, technological and temporal) constraints. Regarding the framework shown in figure 2, a conflict in the scheduling system can come from three sources: • Planning: when the planning activity introduces modifications and/or cancellation in a given order after the orders have already been loaded. In the HOLOS system, this kind of conflict notification is received by the SS agent, which in turn propagates it to the affected Consortium agents. The conflicts here are related to order cancellation, ("random") arrival of a new order, or alteration in the specification of the order; • Execution Supervision: this level deals with conflicts occurred in the shop-floor and that are detected by the execution supervision activity and communicated to the scheduling system. In the HOLOS system, this kind of conflict is received by the EAA agents, which in turn propagate it to the affected Consortium agents. These conflicts have two basic causes: - delays: when the required resources (material/components, human resources, tools or programs) are not available in the scheduled time at the right place;
There is a natural hierarchical relationship among the planning, scheduling and supervision activities. Planning feeds the scheduling activity with an initial plan and with changes in the current plan, whose result (a schedule) is supervised when put in execution (by the dispatcher). In each one of these activities there is a supervision action, respoDSlble for taking care of deviations from what has been planned In other words, to compare the accomplishment status of the plan's goals versus the achieved results; to analyze, by means specific performance indicators, the expected results in terms of scheduling quality versus the results actually obtained; and to check the correctness of the execution of the scheduled operations versus what is being verified. The scheduling activity may require alternative process plans, which in turn has some relation with the product model. Therefore, a truly production planning and control system can be characterized by the existence of decentralized decision areas, whose support systems are distributed and autonomous, but strongly cooperative. Figme 2 shows this integrated framework for agile scheduling.
In order to support agile reactions at the shop-floor level, a gradual increase of the autonomy levels has been observed in those activities. As they are not .; w. . ______ .;·.': .' . • Product , . .'
~ Design r . . -----!-':"-- ."
,',
• • •
•
'C'
....
"1 , "
',°
0
'.:" ' .
.1----,_-' . " .•.
EXecutiOn.
· s~ .
Fig. 2. Integrated framework for agile scheduling.
161
•
- execution errors: machine failme, tooling
5.
problem, program error, arrival of a defective component at the machine, or arrival of a wrong componentltool/program at the machine. • Scheduling: deals with the conflicts occwred within the scheduling activity both when the scheduler cannot schedule a given order and when the user evaluates the current schedule and decides to correct some deviation. These conflicts can happen independently of the other two sources. In the HOLOS system, this kind of conflict is received by the Consortium agents, which in turn propagate it to the SS agent if they cannot solve the conflict locally.
An entire order (a component or an end-product) to be scheduled is represented by a set of inler-related orders, whose manufacturing processes are expressed by the respective process plans (operations). The HOLOS approach for the scheduling generation applies the job-centered strategy (Fox, 1994). It means that a next order is only scheduled if and only if the previous one has been successfully scheduled. One of the main differences between the schedules generated by the HOLOS system and those ones generated by tIaditional scbedulers is that in the former case there is not a unique and comprehensive schedule, but rather a collection of distributed "pieces" of schedules, one per order, supervised by the respective Consortium agent 1berefore, when a conflict happens, there are different objectives to be pursued according to the general scheduling phase, regarding the job-centered strategy: - schedule generation: to guarantee that there will be the adequate manufacturing-resources for one order; - after the schedule generation: to guarantee that all the previously scheduled orders keep scheduled in the same manufacturing-resources; - during the scheduling execution: to guarantee that all the schedules tmder supervision by the Consortium agents will be executed..
The occurrence of a conflict in one of these three main scheduling phases may imply in rescheduling, which is an undesirable but most of times an inevitable action. Because rescheduling is usually a high time-demanding operation, the strategy is to try to reschedule the schedule "portions" not affected by the conflict, similarly to the iterative repair approach (Zweben, 1994), but adapted to a mnlti-agent control arcbitectme. Thus, when a conflict takes place, it is necessary to identify its severity, which can be classified into three levels:
- slight. when the conflict can be absoIbed by the affected manufacturing resource, via backward or forward operations in its agenda (managed by its respective agent), based on the earliest start time and latest end time parameters of each order;
The conflict resolution framework comprises seven main actions, showed in the figme 4: 1- Conflict detection and identification. Reception of the conflict by an agent (see figure 3).
- medium: when the conflict affects other orders in other manufacturing resources but only at temporal level, i.e. its resolution does not imply changing the equipment assignment;
2- Identification of the orders affected by the conflict. A conflict normally refers to one order. However, considering that most orders are inter-
- serious: when the conflict affects other orders in other manufacturing resources such that the previously assigned orders should be rescheduled in other equipment in order to solve the conflict.
related, it is necessary to evaluate which other orders are consequeolly affected too, i.e., which orders will get delayed if a rescheduling is not carried out.
The figme 3 illustrates bow the conflict scenario is managed within the HOLOS multi-agent control architectme. This scenario represents the (local) supervision actions within the scheduling activity (figme 2). In other words, it means that each agent has some capabilities for dealing with some conflicts.
~
3- Identification of the general scheduling phase affocted by the conflict. Once the orders affected by a conflict were identified, it is necessary to
verify in which scheduling phase they are, i.e. scheduling generation (when the Consortium agents are being created), after the scheduling generation (when the Consortium agents bad been created), or during the scheduling execution (when the Consortium agents are in execution).
Planni ng
~conflicts Schedul ing conflict !!!
t ComorIia in aabOO
(scbecalIiDg ~oo)
ConIartia aaled (g.....-.red lCbedIaes)
CONFLICT RESOLUTION
4- Identification of the type of conflict (planning, execution, or scheduling). Depending on the type of conflict, different actions are necessary to be
Coaoonia in """"";011
executed, considering the general objective of each scheduling phase, as descnbed before.
(~eotOCUIian)
Execution confl icts
5- Analysis of the conflict severity level (slight, medium, or serious). 6- Four possible actions, according to the scheduling general phase and conflict severity: 6.1- Change in the order's attributers). As
Fig. 3. Conflict scenario within HOLOS.
mentioned in the chapter 2, a (re)schedule is
162
is more critical if it is carried out during the execution phase since there are components already being processed / finished. It is usually an action "ordered" by the planning activity. 7- Conflict resolution analysis and schedule evaluation. After the actions carried out in the previous step, it is necessary to analyze if the conflict was solved. Besides that, it is desirable that the user evaluates the quality of the new schedule, applying some performance indicators (orders delay, completion time, machine utili.zation, WIP, etc.) upon the schedule.
genernted through the exchange information, among agents, about a given order (the attributes of each of its operations, see Fig. 5). When a conflict occurs, some attribute(s) can be modified in order to "relax" some of the current order constraints (specified in the attributes' content). It means to apply a negotiation process (Rabelo, Camarinha-Matos, 1994), initiated when the user selects, one by one, the operation's attributes that should be relaxed. Once this is done, the order should be re-announced to the agents so that at the end of this process an agent that better fits the new constraints can be found. This is the main and first action used by the HOLOS system to (tIy to) solve a conflict, and it is applied in all scheduling phases, for all kinds of conflicts. 6.2- Order re-announcement. This action can be used "after the scheduling generation" and "during scheduling execution", mainly for the execution conflicts / execution errors (there are some particular cases in which this action can be used for scheduling conflicts). It means to reannounce an order aiming at finding a manufactming-resource (an EAA agent) available to replace one that failed. 6.3- Loading an alternative process plan (when eristing). This is mainly used for execution conflicts and for some cases of scheduling conflicts. When the conflict cannot be solved after the execution of the two previous actions, the option is to get an existing alternative process plan in order to find a manufacturing-resource that fits the new constraints requirements (see figure 2). 6.4- Order cancellation. In spite of being a "radical" solution, this can be applied in all scheduling phases, for all kinds of conflicts. It is used when there is no solution, from the scheduler point of view, for the conflict after applying all the previous alternatives. However, it
This framework for conflict resolution is based on a
strong inter.lction with the (expert) end-user, ie., on non-automatic solutions. Even considering that the introduction of a human-based decision-making process may decrease the system performance, it seems to be a realistic approach. The constraints are so volatile and unforeseen to some extent that is extremely difficult to provide the system with the knowledge - specially the empirical one - for automatic and optimum solutions.
As it can be noted, the Consortium agents have a key importance from the supervision point of view. A Consortium is a temporary agent created to supeIvise the execution of a given order by a virtual cluster of resource-agents (EAAs) dynamically selected to process it (Figure 5). Because there are as many Consortium agents as orders scheduled, each Consortium is responsible to supervise the respective order's schedule (a distn"buted schedule). That selection is supported applying a negotiation process. In the same way that in the integrated framework (figure 2) the importance of local supervision is emphasized, the Consortium concept represents the way a local supervision is implemented within the HOLOS system (ie. within the scheduling activity).
schecilJing or ciJring the scheduing
<:elCeCUtion
CXlnfict
plannng _4'l'--~ confict
genenttion
scheciJ.,g or conftct _
analysis of the _ 8fIected orders
analysis of the
sche
sfter the <:eJC8CUtion CXlnfict scheduing
plannng
generation
alamative process plan
conftct
Z
execu1ion confictll:l--~~
ciJringthe scheduling
exeaJlion
pl;wlnng confict
Fig. 4. Conflict resolution framework.
163
/C----
aniwl of a
ne.order
way conflicts are classified and treated, during the scheduling generation, after its generation, and during its execution was shown.
It firstly tries to solve the problem locally (reasoning about the agendas of the EAAs agents it supervises) and it contacts the SS agent (the global supervisor, which can contact other consortia and then propagates the conflict) only when it cannot solve the conflict. It means that, in spite the HOLOS agents are hierarchical. the decision-making process is not centralized. 6.
The implementation work is proceeding on a PC / Window-NT / C++ platform. The next phase will include the test of this framework in ' two Brazilian enterprises, in the scope of two European projects. Next steps after its initial evaluation are related to the introduction of new functionalities into the agents in order to deal with other perspectives of agile scheduling, such as order splitting, conflicts coming from the supply-chain, virtual enterprise scheduling, and the selection of agents based on global criteria (Rabelo et al., 1998).
CONCLUSIONS AND FUTURE WORK
This paper described a general framework for conflict resolution in a negotiation~ agile scheduling system. This framework is based on a multi-level and local / decentralized supervision approach, strongly supported by the end-user. The
op id op time op Jlr<>CeSS type op tolenmoo op due da1e
...
op)_t ea
procesS"p1an id
Fig. 5. The Consortium concept as the main enabler for local supeIVision. Rabelo, R ; Camarinha-Matos, L.M (1994). Negotiation in Multiagent Based Dynamic Scheduling, InterDational Journal on Robotics and Computer Integrated Manufacturing, Vol 11 N 4, pp.303-31O, Pergamon. Rabelo, R; Camarinha-Matos, L.M (1995). A Holistic Control Architecture Infrastructure for Dynamic Scheduling. In: ArtifiCial Intelligence in Reactive &heduling, (eds. Roger Kerr e Elizabeth Szelke), Chapman & Hall, pp.78-94. Rabelo, R ; Camarinha-Matos, L.M (1996). Deriving Particular Agile Scheduling Systems using the HOLOS Methodology, in International Journal in Infonnatics and Control, Vol 5 N 2, pp.89-106, Romania.. Rabelo, RJ. (1997). A Framework for the Development of Manufacturing Agile Scheduling Systems - A Multiagent Approach, Ph.D. Thesis, New University of Lisbon, Portugal. Rabelo, RJ.; Camarinha-Matos, L.M; Afsarmanesh, H. (1998). Multi-agen1 perspectives to agile scheduling. In: Intelligent Systems for Manufacturing (ed.s L.M. Camarinha-Matos, H. Afsarmanesh, V. Marik), Kluwer Academic Publishers, pp.51-66, Boston. Zweben, M ; Daun, B.; Davis, E.; Deale, M (1994). Scheduling and Rescheduling with Iterative Repair, Intelligent &heduling (eds. M Zweben and M Fox), Morgan Kallfmann, pp.241-255.
ACKNOWLEDGMENTS This work has been supported by CNPq (The Brazilian Council for Research), project ProTeM-CC 680120196-3 PRODNET-ll, and European Union, projects 962219 !NCO-DC MASSYVE and Esprit 22647 PRODNET-II.
REFERENCES Dionisio, R (1997). Protocolo HOLOS: Uma Proposta para Comunicayao entre Agemes em Sistemas de Escalonamento da Produyao, M.Sc. Thesis, New University of Lisbon, Portugal. Fox, M. (1994). ISIS: A Retrospective, Intelligent &heduling (eds. M Zweben and M Fox), Morgan Kaufmann, pp.3-28. Fowler, 1. (1992) Proposal for the STEP Data Access InteIface Specification, STEP Implementation Specifications Committee, NIST. Mackiewicz, R (1994). An Overview to the Manufacturing Message Specification, in h1tp:lIlitwww.epfl.ch/-mms. Massyve (1997). h1tp://centamus.dee.fct unl.pt/-massyve. Parunak, V. D . (1995). An EmeIgem Approach to Systems of Physical Agents, Proceedings AAAI Spring Symposium on Software Alchitectures for Physical Agents. Prodnet (1996). h1tp:llcupido.uninova.ptl-prodnet
164