Resource-oriented scheduling in the distributed ... - Google Sites

Resource-oriented scheduling in the distributed production A. Bratukhin, B. A. Khan and A. Treytl

Abstract— Scheduling in distributed production is a challenging task and the design of a scheduling system is often a key issue for the efficiency of a plant automation system. This paper proposes a scheduling strategy for distributed production based on the MetaMorph clustering and cloning concept and applied to the PABADIS’PROMISE production control architecture.

S

oriented scheduling. Order Flow Order

Order

Order

Resource

Resource

Resource

I. INTRODUCTION

CHEDULING is a key issue in development of control systems for plant automation. A particular scheduling strategy and an algorithm highly depend on the applied architecture and implementation area. The matters complicate more when the scheduling is applied to the distributed environment. Due to the lack of general overview of both, available resources and orders to fulfill, scheduling in the distributed control systems is challenging and often cannot provide global optimum. Therefore, developers of such systems concentrate on the fulfillment of the general driver of the distributed systems – provision of flexibility in the order flow (coming from the top layer systems such as Enterprise Resource Planning - ERP) and management of the shop floor represented by resources (Figure1). Although, optimization is not the main focus in distributed systems, they have to provide a certain level of optimization that would be able to cope with the highly dynamic order flow and the shop floor. Orders and resources are the kernel of every scheduling system, characterized by two main goals: • Optimization of order execution • Optimization of resource utilization The first one is to find the way to execute the orders in respect to the costs that can be time for instance. This type of scheduling focuses on the optimization of the order flow, where the optimization of resource utilization is often neglected. In opposite of the order-oriented, the resource-oriented scheduling attempts to optimize the utilization of resources, for example, to limit the time a resource is not in use. The focus of this paper is to present a solution for the resourceBasit Ahmed Khan, Aleksey Bratukhin and Albert Treytl are with the Austrian Academy of Sciences, Research Unit for Integrated Sensor Systems. [Basit.Khan, Aleksey.Bratukhin, Albert.Treytl,]@oeaw.ac.at (Corresponding author is Aleksey Brathukin, [email protected], phone +43-2622-23420-31)

Shop Floor Figure 1: Order Flow and Shop Flow

As it was mentioned before, lack of the global overview and dynamism of the shop floor make scheduling in the distributed systems challenging. Nevertheless, there are several concepts dealing with these issues. One of the most known and proved is MetaMorph that provides not only the architecture for distributed manufacturing systems but also a concept for resource scheduling. II. METAMORPH MetaMorph is an approach based on the Holonic Manufacturing Systems concept that was developed at the University of Calgary. The name MetaMorph derives from a primary characteristic of the concept – “changing form, structure, and activity as it dynamically adapts to emerging tasks and changing environment” [1]. The MetaMorph project (later recalled as MetaMorph I) and its follow-up MetaMorph II proposed an architecture based on so-called mediators as linking entities in a manufacturing system. The first concept primary deals with the basic definitions of entities of manufacturing system rather than provided architecture for real implementations. The second one is more application-oriented and aims to cover the whole plant automation pyramid from the Supply Chain Management down to the field control by combining existing manufacturing architectures and coupling them with the mediator approach. For the purpose of this paper only MetaMorph I is relevant and is addressed further in the paper. A. Resource and Mediator Agents MetaMorph I concept defines two general types of agents: resource and mediator agents. Resource agents provide manufacturing devices and

operations and can be described as a representation of a shop floor of the factory. Each agent provides a service to the system and performs its functionality independently from the other elements of the community. In order to perform its function, a resource agent communicates with other resource agents and mediators, but considers only its own interests. [1] points that each resource agent “pursues individual goals while satisfying both local and external constraints.” These constrains are the only factors influencing the global goals of the system. But the concurrent production management is the focus of the MetaMorph, because the developers of the systems believed that concurrent engineering is the way to meet the requirements of the modern manufacturing [1] and [2]. Mediator agents coordinate the interactions among agents, both, resource agents and also mediator agents. Each mediator encapsulates a certain functionality that provides knowledge and decision making of a specific problem and coordination between different agents to solve these goals. Therefore, mediators become the key elements in the MetaMorph approach gluing the system together. In particular, two basic functions of mediators can be distinguished: • Brokering and recruiting; mediators are used by the agents to find other agents in the community. Mediators establish communication links between different agents in the system by providing a direct link or by translating communication between agents if additional knowledge (that the agents themselves do not posses) is needed. • Supervision; mediators take over the role of system coordinators by implementing functions that require overview of the certain area of the system or even the whole system. Mediators combine parts of the functionalities and knowledge from the agents and provide services that require an overview of a certain area of the system functionality and environment. There are two methods of linking agents together used by the mediator: brokering and recruiting [3]. In the brokering mechanism, mediators receive messages from the agents, analyzing them and find appropriate recipients. Depending on the intelligence of the mediators and their goals, different strategies can be applied to assign an incoming message to an agent (or agents) that should receive it. In the recruiting mechanism, mediators work use brokering mechanisms for matching agents, but do not interfere into agent-to-agent communication. As long as a link between a message-sender-agent and one or a set of receiving agents is established, mediator’s work is finished. In both cases, to efficiently use these mechanisms, mediators require knowledge to match agent requests with

needed resources, which is crucial for the system success. [1] points that in MetaMorph, organizational knowledge at the mediator level is basically a list of agent-to-agent relationships that is dynamically enlarged. B. Clustering and Cloning The MetaMorph architecture is based on two main principles that guaranty the flexibility and scalability of the implementations, essential factors in the emerging manufacturing: clustering and cloning (Figure2).

Figure 2: Clustering and Cloning mechanism

Clustering is a key element in the concept. The idea behind it is grouping agents in respect to certain functionalities or so-called “decision groups”. In order to implement that multilevel negotiations and cooperation mechanisms that can provide the stability of the decision groups are required. Mediators take responsibility for grouping agents into clusters and providing communication mechanisms mentioned before (brokering and recruiting). Grouping the clusters based on the task decomposition. The top layer tasks are initially composed by mediators, which are grouping the resource agents into clusters to solve smaller more concrete problems. Dynamism of such grouping guaranties the flexibility of the system. Decomposition of tasks is not limited only to the single clusters. In case of the situations when agents in the cluster cannot solve the problem themselves (due to the insufficient knowledge), they try to find the solution outside of the cluster by establishing communication links with other clusters. This process is repeated by creating sub-clusters. This kind of aggregation is an instantiation of the Holonic Manufacturing Systems concept [5], where aggregation of the agents is the way to solve complex problems. Cloning of agents is a mechanism used in MetaMorph to guaranty the concurrent information processing. Instead of being a part of a cluster, Resource agents delegate the decision-making and processing functionality to its clone that acts on behave of an agent and represents it in a virtual cluster which solves a certain problem. The mechanisms such as clustering and cloning provide

flexibility in solving problems in a distributed way. Within this paper, MetaMorph concept of clustering and partly the concept of cloning are applied to the PABADIS’PROMISE architecture to implement scheduling in such highly distributed architecture as PABADIS’PROMISE. III. PABADIS’PROMISE ARCHITECTURE The PABADIS’PROMISE architecture [4] is offering a complete vertical integration solution for distributed plant automation, providing an agent based system for all three levels of the automation pyramid (ERP, MES, and field level). The concept also guaranties horizontal integration of the system, by providing a flexible and adaptive solution on the shop floor. New resources and orders are dynamically added to the plant and the system is able to adapt to the changes.The DCS of PABADIS’PROMISE architecture is based on the paradigm of software agents, that already fulfills similar requirements of flexibility and scalability in other domains. This properties well fit the needs of DCS. A. Plant Automation Pyramid PABADIS’PROMISE consists of three main levels reflecting the automation pyramid structure: ERP – MES – Field level (Figure 3). ERP ERP

Communication via Web Services MES

Product Quantity=50"; such type of order will result in the creation of 50 Order Agents. After its creation Order Agent contacts a special agent in the system that keeps the information of the tasks that are required to be carried out to produce a product. This agent is called as the Product Data Repository; this agent has all the information about how to produce a product. In particular, Bill of Materials (BOM) and Bill of Operations (BOO) are required to start production. Afterwards, an OA parses the order (BOM and BOO) in order to find the abilities that it requires to fulfill the order. 2) OA requests the Ability Broker for resources During the next step, the OA requests the Ability Broker that maintains the actual list of abilities and resources that provide then for the abilities it requires to perform the order. In PABADIS’PROMISE, ability is a certain function that a resource provides. It can be a physical operation, computation function or an action of a human. It reflects the definition of a resource in the concept that varies from a robot to the entire production line or a plant, and can be even a human personal.

3) OA requests an RA for allocation After receiving the list of resources that can perform the requested ability, the OA requests all the RA, that provides the ability, to act as the leader for their resources with same abilities for the purpose of scheduling order. In order to minimize the network load, an OA can request any RA from the list, making the cluster leader election transparent. 4) RA forms a cluster for scheduling Once a cluster leader is chosen, it is its task to communicate to other identical resources and form a resource cluster. This communication can follow the sequence of actions as it is proposed in MetaMorph. That is the leader can first broadcast a message to all the similar Resource Agents, then in reply the Resource Agents can join in the cluster, this cluster then participate in the process of scheduling under the leadership of this leader. However the difference from the classical MetaMorph concept is that in PABADIS’PROMISE the leader does not have the pointers through which other identical resources can be accessed, therefore it needs at o find out those pointers first. In order to find the similar abilities and respected resources, the cluster leader RA contacts the Ability Broker and receives the pointers. Then the leader broadcasts the request for clustering to the RAs with the same ability. As a response, all the requested RAs evaluate the request message and reply to the leader about their decision, the request will either be accepted or dropped. The decision is based on the availability of a resource meaning that if a resource is already allocated for a certain period then it will not participate in the cluster. After that leader receives the responses, it forms a virtual cluster from the positively responded resources. The important feature of the virtual clusters is their dynamism, meaning that they are created on demand and not permanent. A cluster is created for an order and then it is broken after completing the scheduling activity of the order. Moreover it is also possible that an agent that is participating as a leader in one cluster is also acting as a participant in another cluster. 5) RAs perform scheduling and find a solution When the cluster is formed, the mechanism of finding a quasi-optimal solution starts. Within this mechanism a task leader requests the agents in the cluster for the proposals for requested task execution and evaluates the results. There is also a process of the internal evaluation locally at the RAs. a)

Contract-Net Protocol

The communication with in the cluster follows the pattern of Contract-Net Protocol (CNP). However this protocol is adopted to fit the PABADIS’PROMISE demand in benevolence. CNP net protocol is long being consider as a scheduling algorithm, this protocol adopts a greedy approach, it selects the best possible contract, CNP only considers the optimal contract for initiator, it does not

consider possibility of better outcome for the over all good of the system, this type of protocol can work best for the open systems where agents are self interested, however such protocols dose not fit in collaborative environments where agents work for the over all outcome of the system. Therefore, CNP is used for the general communication purposes only, but the decision making is done based on so-called evaluation of optimality. b)

Task evaluation function

Evaluating the optimality of a task is extremely important function, more manufacturing parameter that can be considered while developing this function the better it will be. However, there more parameters are included into evaluation the more computation resources are needed to perform the solution finding that can dramatically decrease the system performance. Furthermore, an exact set of parameters strongly depends on the actual implementation and the chosen strategy. Therefore, this chapter focuses on the designing process of the optimization evaluation function, rather than on specification of criteria parameters. Nevertheless, there are some basic parameters that are general for the evaluation function. These parameters are related to the evaluation of the single task and its position in the schedule of a resource: 1. Start time of the task; 2. Preferred End time of the task; 3. The time it takes for a resource to perform a task, this is because there can be resources that can perform a task much faster than the other resources in the system, the class diagram below shows the class diagram for P2Resource, and as can be seen the variable; 4. End time of pre-scheduled task that is immediately before the start time of new task; 5. Start time of pre-scheduled task that is immediately after the end time of new task; 6. Actual end time of a task is dependent on the time it takes for a resources to perform a task, therefore the actual end time of the resource will be the sum of the “start time” of the task and time it takes by a resource to perform a unit task. Apart from the parameters, the evaluation constrains have to be considered. The most obvious ones are that 1) the start time of the new task does not overlap with the duration of any other task that is committed to the resource, and 2) that the end time of scheduled task does not overlap with any other previously scheduled task. Avoiding overlapping has the highest priority over any other optimality parameter if there is a conflict the evaluation should quit with the optimality set to "zero" since this task is not a useful work that can be done. The only possibility to avoid conflict is to assign the priorities to each of the

task or even OAs that would overtake the overlapping satiation. Another important aspect to consider is the time for tooling then a resource needs to change a tool that implies additional costs (e.g. time). Management of tooling can seriously impact the optimization of the resource utilization. One more issue to conceder is the gap in the resource time schedule between two tasks. This aspect is one of the main focuses of the resource-oriented scheduling, because it does not directly influence the order fulfillment, but rather minimizing the idle state of the resources. The above mentioned set of constrains and parameters only defines the base for the evaluation function c)

Assigning the optimality percentage

The result of the evaluation function of each resource is so-called “optimality percentage” that shows the suitability of a resource for a particular OA request that is the focus of the cluster. The value of the optimality is a combination of the evaluation of each of the parameters and constrains with respect to the priority of each parameter. For instance, such constrains as overlapping the task of another task is has the highest priority due to the fact that a resource is already allocated for the requested period of time. Even in the case of assigned priorities for OAs or their tasks (that allows taking over the already allocated time slot), the overlapping would have the highest priority, because the consequences of the decision concerning the overlapping can cause rescheduling of the entire system. 6) RA sends a proposal to the OA After the cluster leader RA receives all the bids from the cluster members, it verifies the proposals and based on additional parameters, that are given by the OA or general for the shop floor, choose the best solution. The general parameters for the shop floor are the ones that concern the optimization of the whole field layer and not focused on the local optimization of a single resource. Finally, the RA sends a proposal to the requested OA. 7) OA accepts or rejects the proposal Then it is up to the OA to evaluate the proposal and to accept or reject it. It case of accepting, the OA allocates the resource on the proposed conditions. If the proposal is not suitable then the OA has two possibilities to proceed: • Starting the process from the beginning, meaning requesting the AB for the ability, requesting the RA to form a new cluster and so on. Due to the dynamism of the shop floor and of the order flow the result of the new evaluation can be different. • Requests the cluster for other solutions that can fit the OA in a better way, but less optimal for the resources. This mechanism depends of the

configuration of the system that has to position the importance of the shop floor optimization compare to the order flow optimization. Eventually, if the solution within the resource-oriented scheduling cannot be found then the OA has to negotiate with OAs or OAS to find a solution. V. CONCLUSION The MetaMorph-based approach discussed in this paper is only a part of the PABADIS’PROMISE scheduling mechanism. Although, it is based on the HMS paradigm in general and MetaMorph in particular, PABADIS’PROMISE solution has significant differences: • There is no central Scheduler, common in the HMS. Instead, scheduling is distributed among agents. • HMS focuses on the resource-oriented scheduling, PABADIS’PROMISE covers both, resource- and order-oriented, scheduling mechanisms. That allows PABADIS’PROMISE to be used not only in applications within a dynamic shop floor, but also apply the concept to dynamic order flow such as “late order freeze”. Due to the fact that the OAs are involved in the scheduling, the proposed solution is flexible to both, changes in the shop floor and in the order flow. In the highly dynamic environment, such as the application area of the PABADIS’PROMISE architecture, this feature is often more important than providing the optimal solution. In particular, the PABADIS’PROMISE architecture is applicable to mass customized productions, where the “distance” between customers and resources is decreased compared to conventional systems. That makes the MES layer responsible to cope with the dynamism of the order flow. Car production is an application example for the PABADIS’PROMISE approach, due to high costs of final products with the broad variety of customization. PABADIS’PROMISE architecture offers flexibility required by such production control systems. REFERENCES [1] [2] [3] [4] [5]

F. Maturana, D. Norrie, “Multi-Agent Mediator Architecture for Distributed Manufacturing,” in Journal of Intelligent Manufacturing, No. 7, 1999. G. Teunis, P. Leitao, M. Madden, “A New Architecture for Flexible Shop Control Systems,” in Proceedings of Integration in Manufacturing Conference IiM, 1998. K. Decker, “Environment Centered Analysis and Design of Coordination Mechanisms,” in PhD. Thesis, University of Massachusetts, 1995. A. Lüder, J. Peschke, A. Bratukhin, A. Treytl, A. Kalogeras, J. Gialelis, “The PABADIS’PROMISE Architecture”, in Proceedings of the International Congress ANIPLA, 2006. L. Bongaerts, "Integration of Scheduling and Control in Holonic Manufacturing Systems", Ph.D. Thesis PMA/K.U.Leuven, Chapter 3, 1998