MEDIATOR-BASED COMMUNICATION, NEGOTIATION AND SCHEDULING FOR DECENTRALISED PRODUCTION MANAGEMENT

Transcription

1 MEDIATOR-BASED COMMUNICATION, NEGOTIATION AND SCHEDULING FOR DECENTRALISED PRODUCTION MANAGEMENT I. Seilonen 1, G. Teunis 2, P. Leitão 3 1 VTT Automation, ilkka.seilonen@vtt.fi, Finland 2 University of Hanover, teunis@ifw.uni-hannover.de, Germany 3 Inst. Desenvolvimento e Inovação Tecnológica / Polytechnic Institute of Bragança, pleitao@ipb.pt, Portugal Abstract: Recent trends in industry towards autonomous and co-operative production systems and latest developments in data network technologies have created new opportunities for enhancing the co-operation of production networks. In order to take advantage of the emerged opportunities, an approach based on a software system called has been developed. The provides order planning support necessary to integrate decisionmaking and scheduling of several actors in decentralised business organisations. The approach will be demonstrated in the context of order planning in multi-site and supplychain production. Keywords: decentralised systems, decision-making, production control, scheduling algorithms, software tools, networks. 1 INTRODUCTION * Currently, there is a strong trend in industry away from hierarchical and centralised production structures towards autonomous and co-operative units. Latest developments in data network technologies have created new challenges for enhancing the cooperation in production networks. During the past decade considerable effort has been made to optimise business processes within companies which are supported by systems for Enterprise Resource Planning (ERP). Nowadays, the focus is increasingly being shifted to the interaction between multiple sites of enterprises, customers, and suppliers. The improvement of business processes along the supply chain can benefit from the availability of high speed computing networks and advanced technologies for communication and data structuring. In the supply chain control process responsibilities are divided into different companies. Thus, maintai- ning a continuous control of the production flow becomes very complex. The essence of the multi-site production process is to select the optimal production site for each customer order taking into account the technological and financial constraints in each site. This is also important for enterprise networks without a superior decision-making authority. These enterprises also have different organisation and IT structures that have to be integrated. The objective is to develop prototype software support tools to support decentralised order planning and monitoring processes. The tools will be based on a decentralised decision making and scheduling scheme. The emphasis will be on the reliable communication and co-operation of the decision-making units. The prototype should allow quick planning and re-planning in a near-optimal way. It aims at control and scheduling capabilities beyond the current level by using the fast interaction of local, distributed control domains. * The investigation that is reported in this paper is supported by the European Union, Esprit Programme EP 24986, Decentralised Decision Making and Scheduling.

2 2 MEDIATOR-BASED APPROACH The presented approach for decentralised production planning, scheduling and monitoring is based on the concept of the. The approach is building on previous research about mediated co-operation between autonomous decision-makers (see e.g. Cutkovsky et. al., 1993). In the presented approach the is a mechanism for supporting decentralised decision-making among independent decisionmakers while preserving their autonomy. The role of the is to help the decision-makers to take into account interdependencies between their decisions. It provides a shared mechanism for communication and decision-support. The is not aimed at replacing it s user s own decision-making of nor does it necessitate the centralisation of the decision-making process. The -based approach to production planning, scheduling and monitoring is different from those approaches that require higher degree of centralised decision-making. 2.1 Characteristics of decision-making The three application areas of the -based order planning, scheduling and monitoring have some similar characteristics that make the introduction of a common approach possible. All three cases contain a collaborative planning, monitoring and re-planning process among task and resource owners. In multi-site production, for example, the production sites are the resource owners and the sales offices of a company are the task owners. The interaction between the task and resource owners has several variations in different cases that need to be taken into account in the design of the s decision-making mechanisms. For example, the complexity of products, the number of involved decision-makers, the differences in production strategies and situations result in different patterns of co-operation between task and resource owners. However, some level of interactivity is usually present in the decision-making process. 2.2 Decentralised decision-making mechanisms The provides mechanisms for decentralised negotiation, scheduling, and monitoring. These decision-making mechanisms are customisable with a predefined set of rules. They are also based on underlying communication models. The mechanisms of the are designed to work together. The negotiation mechanism provides a messaging language and a protocol that make communication between task and resource owners possible, while the scheduling mechanism provides algorithms for supporting scheduling decisions. The negotiation mechanism is a group level tool complemented with the local level scheduling mechanism. In addition to planning-oriented negotiation and scheduling mechanisms the provides services for monitoring and integrates them into the planning process. A basic monitoring mechanism is based on the request-and-reply type of communication that relies on the activity of the monitoring party. A more advanced mechanism is based on the publish-and-subscribe type of communication that permits activities of both the monitoring and monitored party. 2.3 Decentralised software architecture The is implemented with a decentralised and layered software architecture. The architecture is motivated by a strive for scalability and modifiability. Decision Maker Local Root Local Decision Maker Local Decision Maker Fig. 1. Decentralised software architecture of the. The s decentralised software architecture comprises a root module and a number of local modules as illustrated in Fig. 1. The root module is the registry of the. The local modules contain the decision-support mechanisms. Their operation is supported by the configuration information stored in the root module. Connections to external information systems are implemented via plug-in modules attached to the local modules. The software architecture of the is quite lightweight. Application case-specific customisations Negotiation Application Scheduling Application General components Monitoring Applications Fig. 2. Layered software architecture of the. The s layered software architecture of consists of three layers as illustrated in Fig. 2. The general layer contains mechanisms that may be applied in any kind of -based applications, e.g. registration of its users. The application layer consists of specific application modules for negotiation, scheduling, and monitoring. Finally, the application case layer contains end user specific

3 customisations, e.g. the rules applied in negotiation, scheduling, and monitoring. 3 COMMUNICATION MODELS In a production network the autonomous units form a wide and distributed decision making system and cooperate in order to improve its global manufacturing performance. The definition of a communication system that supports the co-operation and data exchange between autonomous units is an essential key factor to the success of the whole distributed system. The data exchange is mainly relates to business, product and project information. The main problem related to the manipulation of this data is how the target decision-making unit understands specific company data. The solution to this is to use a generic language that permits communication between decision-making units. 3.1 Overview of communication definition In the definition of the communication needs it is necessary to consider, first of all, the following points: mode of communication, which can be pointto-point or broadcast, and the type of message (according with the nature of the message), such as questions, answers, subscriptions and events. In the presented approach the general mode of communication is broadcast, where one unit uses the to distribute the message to the adequate units. Other components that should be considered in the definition of the communication needs and concepts of between and the decision-making units are: The protocol, i.e., the communication scheme between decision-making units for each subprocess models. The vocabulary, which requires the definition of standard contents for the communication between decision-making units in a distributed environment (basic terms and a precise specification of what those terms mean). The language syntax, i.e. the definition of the language supporting the exchange of data. The communication models developed in the project present an approach to the human communication needs in the business process, defined for the distributed decision-making environment, describing the communication between human decision-makers and not communication between software systems. Each autonomous local decision-making agent is an actor in a specific role, which depends of the environment and the characteristics of the task. 3.2 Communication schemes Communication schemes were designed for the following sub-processes: order planning and replanning, monitoring (request-and-reply, publishand-subscribe), project management, and shipping. The request-and-reply type of monitoring is one example for illustrating the communication models developed in the project. The request for passive monitoring comes from the decision-making unit, which wants to know some specific information, such as the current status of an order or the capacity of a production site. The actors in the request-and-reply type of monitoring are the task owner, whose role is to request information, and the resource owner, who has the information. Typical resource owners are production sites. The role of the sales sites is to collect the requested information from production and provide it to the customer. Additionally, a production site can also be a task owner, e.g. in the case of requesting information from another production site. Such a request could relate e.g. the stock level of a particular material/product in a warehouse. 3.3 Data contents and translation The second step in the definition of communication models is the pinning down of the contents of the messages used in the communication schemes. Altogether 26 message contents were defined for the communication scheme. There are some standards for the data exchange between distributed units, such as EDI (Electronic Data Interchange) format, like EDIFACT, for the commercial data and STEP protocol for the product data. For example, the STEP protocol tries to define a standard protocol to product data exchange based on a data model consisting of generic data and a set of APs (Application Protocol). The APs define data exchange standards for each kind of industry. However, these standards do not completely solve the data translation problem. Some other research approaches, such as the KQLM (Knowledge Query and Manipulation Language) (Ferber, 1999), ACL (Agent Communication Language), ontologies (Ontology Research Group) and the work of Open Applications group try to solve this problem, too, but the most promising approach so far appears to be XML (extensible Markup Language) language that is regarded as the standard for the exchange of data. The XML is a format that allows tag definition reflecting the structure of the data. This facilitates the data exchange between different sources. The data is converted from the source format

4 to XML in the middle-tier and then transferred to the target entities. service without extensively increasing requirements on the users of the system. 4 NEGOTIATION CONCEPT Task owner Resource Owner The negotiation mechanism supports collaborative decision-making in a decentralised environment. The mechanism applies to production planning, scheduling and monitoring functionality. The mechanism provides a protocol and a message language for communication during the decision-making processes. The actual decision-making by actors is then supported by a scheduling mechanism as presented in chapter Negotiation protocol Task Announcement Award Cancellation Bid Acknowledgement Rejection Notification Notification The negotiation protocol is based on the so-called Contract Net approach (Smith, 1980). This protocol has been applied to similar tasks in several research projects since late 80's (Parunak, 1987). In the presented approach the negotiation protocol has been extended and combined with a scheduling mechanism. Furthermore, the protocol is implemented within the architecture. The Contract Net is based on the concept of auction. A task owner makes a task announcement to the resource owners that may reply with bids. Finally, the task owner selects the most suitable bid. Both the power and weakness of the Contract Net lies in its simplicity. The three phase protocol is easy to implement, but cannot reflect the complexity of real negotiation processes. Besides, while the Contract Net is able to support negotiations, it alone cannot provide enough information for making decisions during the negotiation. 4.2 Iterative negotiations In order to be able to support negotiations in supplychains and multi-site manufacturing, the negotiation protocol and language ought to be more flexible than those of the Contract Net. In the presented approach iterative negotiations are allowed. The resource owners may make counter proposals in their bids (e.g. if they cannot or do not want to carry out the entire task specified by the task owner, but a part of it). In general the resource owners can adjust the content, time and cost of the announced task. The limits to these adjustments are specified by the task owner in his task announcement. 4.3 Role of the in negotiation The role of the as a shared communication and co-operation tool permits the required extensions to the negotiation mechanism (Fig. 3). The described negotiation mechanism can be implemented within the and be combined with its other decision-making mechanisms, thus forming a more comprehensive and more powerful decision-support Fig. 3. supported negotiation protocol. The negotiation protocol is run between the local modules of the with the help of the information stored in the root module. In the task announcement phase the can select appropriate bidders on the basis of the registration information in the root module. Decision-making rules and schedulers in the bidder's local modules are then used to form bids. After this the bids are collected and evaluated by the. Finally, the takes care of submitting award and rejection messages. In addition, the can handle timeouts and error situations. The combines the negotiation protocol with scheduling and monitoring mechanisms. The scheduling mechanisms may be used for making negotiation decisions both for task and resource owners. The monitoring mechanisms are used to initiate re-negotiations when needed. For this purpose the may store information about task dependencies. Another role of the monitoring mechanisms is to provide additional network-wide information about the production state (e.g. lead time) for bid creation and evaluation. 5 CONCEPT OF DECENTRALISED SCHEDULING The co-operation of decentralised decision-making units is supported by mechanisms for local scheduling and re-scheduling. The stability of a local schedule is changing over time. The possibility of disturbances and the uncertainty of local information require a constant co-ordination of the distributed information sources to keep them consistent. 5.1 Approach to the scheduling problem Several approaches to overcome isolated local scheduling have been presented (e.g. Sadeh et. al., 1998). Thus, the aim of the here presented scheduling

5 concept is not the development of an independent, monolithic solution for decentralised scheduling, but rather an integration of existing local order planning and control systems. Currently these systems are acting independently. The purpose of the is to integrate local decision-making units and their scheduling functionality. Therefore, at each local module of the a scheduling module is available to extend existing planning and control systems and to allow for an integration of these systems. This module is used for the allocation of tasks and the evaluation of schedules. Fig. 4 gives a simple example of decentralised schedulers. On the task owner s side a production order (PrO) that consists of two dependent manufacturing orders (MO) is composed. Scheduler 1 maintains a master schedule for the PrO. The local schedule of Scheduler 2 on the resource owner s side contains MO 2 and other MOs of this site. Task owner PrO: MO1, MO2 Scheduler 1 master Scheduler 3 local PrO: Production Order MO: Manufacturing Order Scheduler 2 local Resource owner MO1 Resource owner MO2 Fig. 4. Example of decentralised schedulers. 5.2 Characteristics of decentralised scheduling Co-operation of decentralised schedulers. The same scheduling module can be used for different purposes. On the task owner s side the manufacturing orders of a production order can be planned sequentially, if the manufacturing orders are dependent, or in a parallel way by using forward or backward planning, if they are independent. A resource owner can use the module for preliminary scheduling of new orders. In order to find a nearly optimal schedule different scenarios can be generated and evaluated before the resource owner responds to the task owner's order request. Re-active, constraint based scheduling. Local scheduling is based on network-wide goals and constraints. On the task owner s side the master schedule is evaluated in order to find optimal or nearly optimal solutions. On the resource owner s side scheduling considers local hindrances (e.g. limited capacity) and global constraints (e.g. dependencies between orders at other sites). In addition to that, the scheduler can react to local events like resource failures or shifted due dates that might require re-scheduling or renegotiation. Fast rough level scheduling. To support a fast order planning via the scheduling is not done on the shop floor level but on a higher level. Therefore, the definition of resources is scaleable. In the scope of this approach a resource can be a manufacturing site, a department of a site, a supplier or an external site. Detailed scheduling below this level is done using local systems. The rough schedules are used to give quick answers to order requests and to support negotiations in the order planning and re-planning processes. Integration of local systems. Local systems for production planning and control are not replaced but extended and integrated by the. Basic PPC functionality like process planning or material planning remains to be carried out by local systems. The data transfer from and to local systems is supported by a XML-parser (Fig. 5). Scheduling Preliminary scheduling Re-active, constraint based (re-) planning Fast rough level scheduling Simulation of scenarios Evaluation of schedules Current schedule, changes New orders, changes XML-Parser Local System PPC Detailed shop floor scheduling Process planning Material planning etc. Fig. 5. Local rough and detailed level scheduling. 5.3 Scheduling mechanisms and evaluation Numerous algorithms for the job shop scheduling problem have been proposed in research (Baker, 1998; Brucker, 1998). Some of them are implemented in production-planning and control systems. Nevertheless, only few algorithms are really used in industry (Winkler, 1997). Extended priority rules. For a prototype implementation priority rules are selected and extended to meet the requirements for decentralised scheduling. Due to their simplicity priority rules are commonly used in the industrial branch for solving the resource allocation problem. This problem is usually NPcomplete, so mostly no real time application exists for determining an exact solution. In addition, approximation applications are difficult to implement and often suitable for special cases only. Apart from conventional time based priority rules (like earliest due date, least slack or shortest processing time) cost based rules and rules that consider the importance of an order are also used. With the help of cost-based rules costs that are directly related to the order as well as resourcerelated costs for machines and personnel can be considered.

6 Schedule evaluation. In order to compare different schedules several evaluation measures are implemented in the scheduling module. Measures like throughput time, tardiness or utilisation rate are used to calculate the merit of a schedule both on the task and the resource owner's side. The measures and the parameters of the respective schedules are stored in a socalled schedule map for further comparison. 6 APPLICATION OF DECISION-MAKING MECHANISMS The presented decision making mechanisms will be applied and tested in three industrial pilot cases. The first case involves a multi-site steel tube manufacturer with many alternative production sites that are accessed from several sales offices simultaneously. The production of a single order of any sales office might be divided to several production sites. The role of the is to help sales offices in planning suitable production sites for their orders. The production sites are engaged in negotiations with sales offices by providing bids based on their production situation. The is the server that runs the planning process. The underlying business goal of this pilot case is enhanced utilisation of the company's resources. In the second case a group of manufacturers for bakery equipment with several independent companies are working together for customer orders in which technological and time related constraints must be considered. On the customer s site salesmen are planning orders which consist of single machines up to the complete design of a whole bakery where components can be supplied by different companies. In the current order planning process paper checklists are used for product configuration which are the sent by fax or post to the sales department. This process is time and cost intensive and error-prone. With support of the it will be possible to determine realistic due dates with fast rough level scheduling, to reduce effort and errors and to increase transparency in the order planning process. In the third case, an application of the to supply-chain management is demonstrated at a company that delivers large one-of-a-kind products world-wide. Their projects involve a large amount of both external and internal suppliers both in engineering and manufacturing. The company has a remarkable need to monitor these suppliers and foresee potential problems. The company is expecting to have benefit from the monitoring capability of the. 7 CONCLUSIONS Decentralised production structures, e.g. multi-site manufacturing and supply chains, require communication and co-operation facilities and mechanisms to support the decentralised decision-making in order to improve their manufacturing performance. This paper presents a -based approach to support decentralised decision-making, focusing in the communication, negotiation and scheduling domains. The approach provides a complementary set of decision-support mechanisms to be used in order planning, scheduling and monitoring. The approach specifies a modified version of the Contract Net negotiation protocol. The described protocol allows iterative negotiations and partially modified counter proposals to task announcements. The data exchange between and the decentralised decision-making units is implemented with XML, which enables a transparent data exchange between those entities. The described mechanisms may be implemented with a scalable and lightweight decentralised software architecture. The approach is being piloted with three industrial cases. REFERENCES Baker, A.D. (1998). A survey of Factory Control Algorithms That Can Be Implemented in a Multi-Agent Heterarchy: Dispatching, Scheduling, and Pull. Journal of Manufacturing Systems, Vol. 17, No. 4, pp Brucker, P. (1998). Scheduling algorithms. Springer, Berlin. Cutkovsky, M.R. et. al. (1993). An Experiment in Integrating Concurrent Engineering Systems. Computer, Vol. 26, No. 1. pp Ferber, J., (1999). Multi-Agent Systems, An Introduction to Distributed Artificial Intelligence, Addison-Wesley. Ontology research group, Open Applications Group, Parunak, H.V.D. (1987). Manufacturing experience with the Contract Net. In: Huhns, M.N. (ed.) Distributed artificial intelligence. London, Pitman, pp Sadeh, N.M. et. al. (1998). A blackboard architecture for integrating process planning and production scheduling. Concurrent Engineering: Research and Applications, Vol. 6, No. 2. pp Smith, R.G. (1980). The Contract Net protocol: highlevel communication and control in a distributed problem solver. IEEE Transactions on Computers, Vol. c-29, No. 12, pp Winkler, M. (1997). Flexible Werkstattsteuerung für neue Formen der Fertigungsorganisation (Flexible shop control for new approaches of production organisation). VDI-Verlag, Düsseldorf.