generic framework for conflict resolution in negotiation-based agile ...

1 downloads 0 Views 128KB Size Report
Roger Kerr e Elizabeth. Szelke), Chapman & Hall, pp.78-94. Rabelo, R.; Camarinha-Matos, L.M. (1996). Deriving Particular Agile Scheduling Systems using the ...
Presented in the 5th IFAC Workshop on Intelligent Manufacturing Systems / IMS’98, Gramado, Brazil, 1998.

GENERIC FRAMEWORK FOR CONFLICT RESOLUTION IN NEGOTIATION-BASED AGILE SCHEDULING SYSTEMS Ricardo J. Rabelo 1 ; Luis M. Camarinha-Matos 2 1 2

Federal University of Santa Catarina, Brazil – [email protected] New University of Lisbon, Portugal – [email protected]

Abstract: This paper describes a general framework for conflict resolution being implemented on the HOLOS multi-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 during scheduling generation, 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  1998 IFAC. Keywords: Scheduling algorithms, Agile manufacturing, Distributed artificial intelligence.

1.

INTRODUCTION

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 disturbances in their shop floors. One of the contributions to face that dynamic reality is to provide the industries with agile manufacturing scheduling systems. Agility is an emergent requirement for advanced manufacturing scheduling systems. Scheduling is generally defined as the activity of assigning orders to manufacturing 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;

§ 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. In fact, the implementation of a system with such capabilities is still a challenge, specially considering that it must remain realistic, coherent and feasible along its execution. One of the main reasons for this situation is related with the intrinsic scheduling problem complexity, which is NP-complete. 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 constraints associated to the orders 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 (Parunak, et al., 1995).

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.

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. Therefore, a schedule is generated and supervised via a cooperative and tight coordinated information exchange among agents.

THE HOLOS SCHEDULING SYSTEM

HOLOS is a framework specially developed to derive “instances” of agile scheduling systems (Rabelo, 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 STEP/SDAI (STEP Data Access Interface) protocol (Fowler, 1992). The inter-agent communication is supported by a specific high-level negotiation protocol (Dionisio, 1997). The communication between the EAAs and the manufacturing resources uses a subset of the MAP/MMS (Manufacturing Message Specification) protocol (Mackiewicz, 1994), supported by a wrapper (Rabelo, Camarinha-Matos, 1994).

Figure 1 illustrates a global view of a particular HOLOS multi-agent scheduling scenario. The scheduling system is viewed as an application that receives / feeds data from / to a CIM Information System (CIM-IS), receiving / providing information from / 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: • Scheduling Supervisor (SS): instance agent that performs the global scheduling supervision and it is the unique system’s “door” to other systems. • Enterprise Activity Agents (EAA): 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 Apl.1 Apl.2 Apl.n

3.

SCHEDULING BOUNDARIES: DEFINING RESPONSIBILITIES 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.

existing applications

HOLOS scheduling system SS

CIM-IS EAA i

EAA EAA

i

LSC

Ci

i EAA

i

EAA

LSCi

i

EAA i

i

C

i

Instances of the Holos agents classes

EAA i

< Scheduler_id >

Shopfloor

Fig. 1. A particular HOLOS multi-agent scheduling system.

Robot_Scara

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 manufacturing resource to the level of the factory as a whole, checking the current results against what was scheduled.

completely independent, the supervision 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 responsibility 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 are events that can happen in any moment within the enterprise and that provoke disturbances 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, responsible 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. Figure 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 Product Design

Process Planning

CONFLICTS

Changes from Planning

Planning Planning Supervision

Deviations at Planning level

Replanning

Scheduling Supervision

Deviations at Scheduling level

Rescheduling

Execution Supervision

Deviations at Execution level

Recovering

Scheduling

Execution

Fig. 2. Integrated framework for agile scheduling.

- execution errors: machine failure, tooling problem, program error, arrival of a defective component at the machine, or arrival of a wrong component/tool/program at the machine. • Scheduling: deals with the conflicts occurred 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. 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 multi-agent control architecture. 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 absorbed 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; - 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; - 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. The figure 3 illustrates how the conflict scenario is managed within the HOLOS multi-agent control architecture. This scenario represents the (local) supervision actions within the scheduling activity (figure 2). In other words, it means that each agent has some capabilities for dealing with some conflicts. SS

Planning conflicts Scheduling conflicts

CC C

CC C Consortia in creation (scheduling generation)

CC C

Consortia created (generated schedules)

Consortia in execution (scheduling execution) Execution conflicts

EAA

EAA

EAA

...

EAA

Manufacturing Resources

Fig. 3. Conflict scenario within HOLOS.

5.

CONFLICT RESOLUTION

An entire order (a component or an end-product) to be scheduled is represented by a set of inter-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 traditional schedulers 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. Therefore, 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 under supervision by the Consortium agents will be executed. The conflict resolution framework comprises seven main actions, showed in the figure 4: 1- Conflict detection and identification. Reception of the conflict by an agent (see figure 3). 2- Identification of the orders affected by the conflict. A conflict normally refers to one order. However, considering that most orders are interrelated, it is necessary to evaluate which other orders are consequently affected too, i.e., which orders will get delayed if a rescheduling is not carried out. 3- Identification of the general scheduling phase affected 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 had been created), or during the scheduling execution (when the Consortium agents are in execution). 4- Identification of the type of conflict (planning, execution, or scheduling). Depending on the type of conflict, different actions are necessary to be executed, considering the general objective of each scheduling phase, as described before. 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 attribute(s). As mentioned in the chapter 2, a (re)schedule is

generated 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 (try 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 manufacturing-resource (an EAA agent) available to replace one that failed. 6.3- Loading an alternative process plan (when existing). 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

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 utilization, WIP, etc.) upon the schedule. This framework for conflict resolution is based on a strong interaction with the (expert) end-user, i.e., 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 supervise 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 distributed 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 (i.e. within the scheduling activity).

during the scheduling generation

conflict

analysis of the affected orders

analysis of the scheduling phase

after the scheduling generation

scheduling or execution conflict planning conflict

scheduling or execution conflict planning conflict

execution conflict during the scheduling execution

Fig. 4. Conflict resolution framework.

planning conflict

change in the order’s attribute(s)

order re-announcement

alternative process plan

order cancellation

arrival of a new order

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.

way conflicts are classified and treated, during the scheduling generation, after its generation, and during its execution was shown. 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-based agile scheduling system. This framework is based on a multi-level and local / decentralized supervision approach, strongly supported by the end-user. The

end-product

part

User

production plan part’s operations

Op_Announcement op_id … op_time … op_process_type … op_tolerance … op_due_date … op_earliest start_time … op_latest end_time … op_relaxation … op_preferences ... process_plan_id ...

Consortium distributed schedule

E

A

A

s

Shopfloor

Fig. 5. The Consortium concept as the main enabler for local supervision. ACKNOWLEDGMENTS This work has been supported by CNPq (The Brazilian Council for Research), project ProTeM-CC 680120/96-3 PRODNET-II, and European Union, projects 962219 INCO-DC MASSYVE and Esprit 22647 PRODNET-II. REFERENCES Dionísio, R. (1997). Protocolo HOLOS: Uma Proposta para Comunicação entre Agentes em Sistemas de Escalonamento da Produção, M.Sc. Thesis, New University of Lisbon, Portugal. Fox, M. (1994). ISIS: A Retrospective, Intelligent Scheduling (eds. M. Zweben and M. Fox), Morgan Kaufmann, pp.3-28. Fowler, J. (1992) Proposal for the STEP Data Access Interface Specification, STEP Implementation Specifications Committee, NIST. Mackiewicz, R. (1994). An Overview to the Manufacturing Message Specification, in http://litwww.epfl.ch/~mms. Massyve (1997). http://centaurus.dee.fct.unl.pt/~massyve. Parunak, V. D. (1995). An Emergent Approach to Systems of Physical Agents, Proceedings AAAI Spring Symposium on Software Architectures for Physical Agents. Prodnet (1996). http://cupido.uninova.pt/~prodnet.

Rabelo, R.; Camarinha-Matos, L.M. (1994). Negotiation in Multiagent Based Dynamic Scheduling, International Journal on Robotics and Computer Integrated Manufacturing, Vol 11 N 4, pp.303-310, Pergamon. Rabelo, R.; Camarinha-Matos, L.M. (1995). A Holistic Control Architecture Infrastructure for Dynamic Scheduling. In: Artificial Intelligence in Reactive Scheduling, (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 Informatics and Control, Vol 5 N 2, pp.89-106, Romania. Rabelo, R.J. (1997). A Framework for the Development of Manufacturing Agile Scheduling Systems – A Multiagent Approach, Ph.D. Thesis, New University of Lisbon, Portugal. Rabelo, R.J.; Camarinha-Matos, L.M.; Afsarmanesh, H. (1998). Multi-agent 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 Scheduling (eds. M. Zweben and M. Fox), Morgan Kaufmann, pp.241-255.