Agent-based service-oriented dynamic resource ...

SIMTech technical reports (STR_V10_N4_07_MEC)

Volume 10 Number 4 Oct-Dec 2009

Agent-based service-oriented dynamic resource allocation C. H. Tan, M. Luo, Y. Z. Zhao, L. W. Tay, and M. M. Wong

Abstract – Production schedules, no matter how well they are planned, will be affected by manufacturing shop floor dynamics during their execution. To deal with disruptions arising from shop floor dynamics, a distributed control approach using multi-agents has been demonstrated, as a means to perform local rescheduling of affected manufacturing activities. Software agents are used to represent resources and tasks. Resource and task agents negotiate with each other to arrive at a set of new schedules, by using the available slack between operations of the affected jobs to make up the shortfall in capacity due to the disruption. A successful local rescheduling exercise will eliminate or cause minimal impact to affected operation of the planned schedules, hence avoiding the need to perform a global reschedule.

terials and work-in-process must be moved to the newly allocated equipment for the continuation of the manufacturing process. In situations where there is some excess shop capacity for the disrupted operation or sufficient slack before the due dates of some orders, internal disruptions that are small in scale, can be managed by performing a local rescheduling of manufacturing activities which will result in reducing or totally eliminating any impact of the disruption to the original planned schedules. This approach is used by the dynamic resource allocation and management (DRAM) program of the IMSS project, and is the focus of this report. Local rescheduling can be performed by a multi-agent system (MAS) [1-3], thereby eliminating the need for human intervention. Agents representing equipment and tasks of a MAS, can negotiate amongst themselves to re-allocate manufacturing activities to accommodate stochastic disruptive events. The performance monitoring, diagnosis and prognosis (PMDP) program of the IMSS project will provide feedback to the DRAM’s task agent when there is an equipment breakdown or performance degradation. When such feedback is received from PMDP, the task agent will initiate a local rescheduling to enable its job to be completed by an alternative resource. To allow agents of the MAS to be loosely coupled, a service-oriented architecture (SOA) [4] has been adopted. In a departure from the usual SOA systems, the service requestor will publish its requirements to a service directory facilitator. Service providers will subscribe to the service directory facilitator for service requests. Where service providers can satisfy the requirements of a published request, they will submit bids to the service requestor. The service requestor will evaluate the bids that are received, and choose a service provider that can best meet its requirements based on its policy for the completion of the task that it is responsible. By adopting the SOA approach, the plug-n-play strategy has been incorporated as resource agents are automatically plugged into the MAS when they are switched on, thereby eliminating the need for task agents to know who is available to take on jobs that they have on hand.

Keywords: Dynamic resource allocation, Multi-agent systems, Service-oriented architecture, Local scheduling

1

BACKGROUND

Manufacturing faces many challenges nowadays. Apart from the increase in global competitiveness, which has resulted in the movement of manufacturing to locations that offer cheaper labour and land costs, manufacturing companies must respond to rapidly customer demands. In order to surmount these challenges, manufacturing companies must be agile and be responsive in order to react quickly to both external stimulus such as changing customer demands, as well as internal events, such as shop floor disruptions that can arise from equipment performance degradation, equipment breakdown, etc. There are two broad categories in which disruptive events can be classified. They are namely, external and internal. External disruptions arise from factors outside the boundary of the company, such as changes in customer order relating to order quantity changes, delivery date changes, order cancellation, etc. Internal disruptions arise from within the company and these are mainly unplanned shop floor dynamics such as material shortages, machine breakdown, performance degradation, shortage of operators, etc. Systems such as ERP and finite capacity scheduling (FCS) systems would handle external disruptions. This generally would lead to global rescheduling of manufacturing activities, which is unavoidable and highly disruptive to the shop floor as equipment, materials and labour have to be reallocated, and ma-

2

OBJECTIVE

The objective is to design a system architecture of a MAS for DRAM so that the handling of the rescheduling task can be conducted in a distributed manner.

226

Agent-based service-oriented dynamic resource allocation

plications based on open standards such as Web Services (WS). Software functions are packaged as services by the service provider and published in the service registry whereupon it can be discovered by a service requestor. Following the discovery of the required web service, the service requestor will then interact with the service provider to fulfill the requirements of the service requestor. The World Wide Web Consortium (W3C) and the Organisation for the Advancement of Structured Information Standards (OASIS) have defined the three main standards for WS. They are namely Simple Object Access Protocol (SOAP) for supporting communication between web services, Web Service Description Language (WSDL) for describing web services, and Universal Description, Discovery & Integration (UDDI) for publishing web services. With the advent of Web Services and SOA, realising enterprise integration, accelerating enterprise responsiveness to customers, automating inter-enterprise interactions and optimising the business processes of the whole supply chain become feasible. The service-oriented paradigm and Web Services technologies are rapidly emerging as the most practical approaches for integrating a wide array of manufacturing resources in the manufacturing grid environment, and efforts in the Semantic Web standards and technologies present an opportunity for automating the integration process. Web Services are most likely to be adopted as the de facto standard to deliver effective, reliable, scalable and extensible machineto-machine interaction than any of its predecessors. Aforementioned service requestor and service provider interaction requires stateful service. The Web Service Resource Framework (WS-RF) provides mechanism to model stateful resources with Web Service. A previous work [8] has shown how WS-RF expresses state as stateful resources and codifies the relationship between Web Services and stateful resources. The WS-Resource-based approach thus provides an enabling technology for modeling the resources of manufacturing systems in a service -oriented paradigm. In a service-oriented paradigm, all resources, including various data sources, manufacturing devices / equipment / subsystems, processes / applications, manpower, etc., are required to be virtualised and exposed as Web Services. Upon being virtualised and exposed as Web Services, these components and resources can present their functionalities and transform manufacturing resources into service capabilities in a standard Web Services environment. With service brokering, orchestration and choreography under WS-Resource Framework (WS- RF), automating the integration of manufacturing execution and services can be achieved. Figure 1 shows a service-oriented architecture for automating the integration of manufacturing systems and services.

The rescheduling exercise would involve agents that are affected, and ensures that hard constraints such as equipment capability to process the part that is required to complete the manufacturing task, and soft constraints such as due date of the order, are not violated. 3

ENABLING TECHNOLOGIES

3.1

Multi-agent Systems

A software agent [5] is “an autonomous software component that interacts with its environment and with other agents on a user’s behalf”. Software agents can be used to model the behaviour of real world physical entities or perform their functions. Multiagent systems (MAS) are systems that employ agents that perform various functions, to achieve an objective, such as generating a set of production schedules. The agents that make up a scheduling or dynamic resource allocation MAS communicate and negotiate with each other during the process of developing the production schedules. Operation start time, operation end time, utilisation cost of equipment, changeover or setup cost or time, etc., are information that are exchanged between agents. Software agents can be programmed to exhibit attributes of intelligence and autonomy. An agent representing an entity or resource such as a transporter, has knowledge about its maximum speed, payload capacity and maximum physical dimensions of payload. It will use such knowledge to check if it qualifies to offer its service in response to a transportation service request. A shop floor equipment agent on the other hand, has knowledge about the type of manufacturing process that it can perform as well as its capabilities and the cost of utilisation. Agents in a MAS can be organised in a hierarchical, distributed, or hybrid hierarchical-distributed structure. As a result of their autonomous attributes, they are able to make decisions and collaborate with each other to achieve a common objective. Agents can also be designed to be proactive so that they can take initiatives to pre-empt impending undesirable events. Intelligent agents can learn from past experiences and adapt to the current situation. The Foundation for Intelligent Physical Agents (FIPA) [6], an IEEE Computer Society standards organisation founded in 1996, has developed software standards specifications for agent instantiation and interoperability between agent-based systems that are developed by different companies and organisations. JADE (Java Agent DEvelopment Framework) [7] is a software framework for developing distributed multiagent applications that complies with the FIPA specifications for interoperable peer-to-peer communication between intelligent multi-agent systems. 3.2

Service-Oriented Architecture

Service-Oriented Architecture (SOA) is a platform for building loosely-coupled interoperable ap-

227

C .H. Tan et al

Fig. 1. Service-oriented architecture for automating the integration of manufacturing systems and services.

4

SYSTEM ARCHITECTURE

4.1

The ERP system will handle customer orders. The ERP system will then provide manufacturing inputs based on demands from customer orders. Customer demands are translated into manufacturing orders for products, which are then broken down into process steps based on the routing for these products. The process steps are time-phased by the FCS during the process of allocation to manufacturing resources, to produce a set of feasible schedules. The resultant daily production schedules are then channelled to DRAM as a set of time-phased process steps for each manufacturing order. DRAM will manage the dispatch of the individual process steps of open manufacturing orders.

The Job Shop Prototype Model

The job shop prototype model for the manufacture of three products is shown in Fig. 2. There are five process equipments, labelled P1 to P5. Raw materials are kept in store S1 and finished products are kept in store S2. There are four transporters, labelled T1 to T4 that will move raw materials, work in process (WIP), and finished products between the stores and process equipment. The transportation time between locations is given in the Move Time matrix, and the routing of the products, are given in the table at the bottom of the figure.

Fig. 2. Job shop prototype model.

4.2

DRAM

In recognition of the reality of unforeseen dynamic shop floor events and the realisation that there is a need to respond to such events in a manner with the aim of mitigating the impact of such disruptions to shop floor operations in terms of additional setups and

228

transportation costs that would be incurred as a result of having to shift production amongst the available shop floor resources, as well as to the original production schedules, DRAM will strive to perform local rescheduling of affected tasks by using the distributed control approach to perform resource allocation amongst equipment that are in operation.

Agent-based service-oriented dynamic resource allocation

Within DRAM, software agents are used to model the Task Agent Co-ordinator (TAC), Task Agent (TA), Resource Agent (RA), and Service Di-

rectory Facilitator (SDF). Figure 3 shows the system architecture that models the relationships between TAC, TA, RA and SDF.

Fig. 3. DRAM system architecture.

4.3

complete the set of process steps of the parts that are specified in the manufacturing order. The TA will receive the following from the TAC during its creation: 1. Manufacturing order ID 2. Quantity of the parts for the manufacturing order 3. A listing of the process steps and their corresponding assigned machine ID (i.e. RA IDs), process time, slack time, and due date The TA will manage the process steps by dispatching the process steps to RAs that are assigned to each of the process steps. When all process steps are completed, the TA will inform the TAC of the completion of the task. The TAC will in turn, inform the ERP system of the completion of the manufacturing order. Following that, the TA will be destroyed by the TAC, as shown in Fig. 4.

Task Agent Co-ordinator (TAC)

The TAC acts as the gateway between the ERP/FCS system and DRAM. It receives the production schedules from the ERP/FCS system as individual manufacturing orders with time-phased process steps and assignment to resources. The TAC reports the completion of manufacturing orders to the ERP/ FCS system, as well as the level of WIP for cancelled manufacturing orders. Figure 4 illustrates the relationships between ERP/FCS and DRAM. As shown in Fig. 4, TAC manages TAs in the following manner: 1. Creates a TA for each manufacturing order 2. Destroys the TA when a manufacturing order is completed 4.4

Task Agent (TA) Each TA represents the task that is required to

Fig. 4. Interaction of TAC, TA & RA during normal operation.

229

C .H. Tan et al

When disruptive shop floor events such as tool breakage, equipment breakdown, motor overheating, etc, occurs, the TA will be informed by the RA. The TA will have to decide if the process step should stay with the current equipment until it is serviced and brought back to operation to continue with the process step, or to initiate a local reschedule whereby the current process step will be re-allocated to other equipment that are capable of completing the process step. This scenario is shown in Fig. 6 at the end of this report. Information that is given by the RA for the TA to make the decision includes the following: 1. Breakdown time (actual occurrence time or expected time) 2. Severity of the failure 3. Estimated repair period needed 4.5

Resource Agent (RA)

RAs are software agents that reside on the equipment and transporters. When an equipment or transporter is turned on, the RA will be created in the on-board computer of the equipment or transporter. The RA will be destroyed when the equipment or transporter is turned off. There are two main roles for the RA. Firstly, the RA is in charge of the management and operation of the equipment or transporter. In the course of normal operations, the RA will simply receive the specification IDs from various TAs for executing jobs that have been assigned to the equipment. A job is just one of the many process steps of the manufacturing order that is being managed by a TA, and assigned to the RA. The whole set of jobs for the equipment that is received by the RA, is the planned schedules for the equipment. The RA will sorted the jobs to ensure that they are in the right sequence for execution before communicating the instructions of the specification ID for the first job to the sub-system controller of the equipment for execution. Secondly, the RA will periodically check the SDF for newly published jobs and get their specifications for evaluation to see if it can

participate in bidding for that job. When there is an opportunity for the RA to participate in the bidding, it would prepare a bid, determine the displacements to the outstanding jobs that have been assigned to it, and check with the TAs of displaced outstanding jobs to see if they are agree- able to the displacement of their jobs from the planned start and end times, as well as any lateness that may arise. When acceptance of such displacements has been obtained from the TAs, the RA would submit its bid to the requesting TA. The bid would include the start and end times, and job duration. Figure 6 illustrates the handling of a typical delay scenario. Further elaboration of the negotiation process between RAs and TAs is given in Section 4.9. 4.6

Sub-system Controller

The job that is received by the RA of the equipment from a TA, will be communicated to the subsystem controller for execution. The sub-system controller is also in charge of the real-time control and auto-recovery of the equipment, with consideration of the equipment health prognosis information being taken into account. 4.7

Chain of Responsibilities in Handling Shop Floor Dynamics

The sub-system controller will use the equipment health prognosis as a feedback for real-time control of the equipment with the aim of pre-empting impending breakdown of the equipment by taking the necessary corrective actions within its purview. Required corrective actions that are out of the sub-system’s control will be referred to the equipment’s RA, which will channel it to the TA. The TA will then make a decision based on the decision making policy that is defined for the TA, to determine if it can accept the delay that is arising from the disruption, or initiate a round of local rescheduling amongst the TAs and RAs that are affected by the disruption, as shown in Fig. 7.

Fig. 7. Handling of Delay Scenario.

230

Agent-based service-oriented dynamic resource allocation

4.8

Service Directory Facilitator (SDF)

The SDF is an agent that serves as a service directory by allowing TAs to publish service requests to it whenever there is a need to conduct local rescheduling. The service providers, which are the RAs, subscribe to the SDF to obtain notification and specifications of any potential requests that arise. Upon a successful re-allocation of resources following the negotiation process of a rescheduling attempt amongst the affected agents of the MAS, the TA which has requested the service, will instruct SDF to remove the service request. 4.9

RA-TA Negotiation Process

When an unplanned shop floor event such as equipment breakdown occurs, the equipment’s controller will inform the RA. The RA will then inform the TA of the disruption and the expected delay arising from the time that is required to service the equipment based on statistics from historical records,

before the equipment can resume operation, to continue and complete the job for the TA. The TA will have to make a decision on whether to keep the job with the present equipment until it is serviced so that it can complete the rest of the operations, or to initiate a local reschedule that will cause a re-allocation of resources, provided that the reschedule will not result in delays to the original planned schedule for all manufacturing orders from the ERP system. The negotiation process as shown in Fig. 8 at the end of the report, illustrates the interactions between TAs and RAs during the rescheduling exercise. The main guiding principle in the negotiation process is a RA cannot make a commitment to take on a job if it will cause the outstanding jobs that it has been allocated with, to be late, unless the TAs of these jobs have been informed of the delays to their jobs and have accepted the delays.

Fig. 8. Publication of Service Request & TA-RA Negotiation Process for Delay Scenario.

4.10

Implementation of the DRAM MAS

The DRAM MAS was implemented in JADE by a group of NTU-EEE MSc students. The JADE framework includes a distributed run time environment for MAS, a class library for the development of MAS, & tools to manage, monitor and debug MAS. The web-based main GUI of the Demonstrator, that provides a near real-time view of the shop floor, is shown in Fig. 5. Figure 6 shows the Task-based Production Schedule & Progress GUI. The current time is shown as a red vertical line.

Fig. 5. Web-based main GUI of Demonstrator.

231

C. H. Tan et al

Fig. 6. Task-based Production Schedule & Progress GUI.

5

CONCLUSION

This report is the culmination of the work that was carried out in the IMSS project, to demonstrate the flexibility of a plug-n-play manufacturing shop floor where processing machinery and material/WIP transporters can easily establish their presence and participate in handling disruptive shop floor dynamics such as machine or transporter breakdown, machine performance degradation, etc., as and when they occur. The decision making process is decentralised in that each participating agent for a machine or transporter will assess the present situation as well as its own capability and commitments, with the objective of helping to ease the problem situation that has occurred, by making adjustments through the process of negotiating with one another without making drastic com- promises to its own commitments to deadlines. It must be noted that DRAM is realisable due to the availability of PMDP and the real-time control and auto-recovery (RCAR) modules of the IMSS project. 6

INDUSTRIAL SIGNIFICANCE

DRAM is one of the components or building blocks for the smart factory of the future. In the smart factory of the future, sensors which provide real-time feedback signals are attached to machines and other factory equipment. Output of sensors is transformed into meaningful information that reflects the state or condition of these machines, such as equipment breakdown or performance degradation.

232

The state of machines that has become undesirable can be used to make decisions on the allocation or balancing of machine loading so that the overall objective of meeting the deadlines of customers’ orders can be met as far as possible, without the need for human intervention. In this way, corrective decisions and actions can be taken in a near real-time manner thereby minimising or even eliminating costly machine downtime, hence, maintaining the productivity level of the shop floor. DRAM, in conjunction with RCAR and, PMDP, form the cornerstones for the smart factory of the future. The smart factory of the future knows the pulse of the shop floor and is able to respond effectively to pre-empt the occurrence of equipment breakdown or failures, or mitigate the effects of such events when they do occur. REFERENCES [1] W. Shen, L. Wang, and Q. Hao, “Agent-based distributed manufacturing process planning and scheduling: a state-of-the-art survey”, IEEE Trans. Systems, Man, & Cybernetics, vol. C-36(4), pp. 563-577, 2006. [2] C. Wang, W. Shen, and H. Ghenniwa, “An adaptive negotiation framework for agent based dynamic manufacturing scheduling”, Proc. IEEE Int. Conf. Systems, Man & Cybernetics, Washington D.C., USA, 5-8 October 2003, pp. 1211-1216. [3] W. Shen, S.Y.T. Lang, and L. Wang, “iShopFloor: an Internet-enabled agent-based intelligent shop floor”, IEEE Trans. Systems, Man, & Cybernetics, vol. C-35(3), pp. 371-381, 2005. [4] I.M. Delamer, and J.L.M. Lastra, “Loosely-coupled automation systems using device-level SOA”, Proc. 5th IEEE Int. Conf. Industrial Informatics, June 2007, vol. 2, pp. 743-748. [5] M.L. Griss, “Software Engineering with Java Agent Components”,http://martin.griss.com/pubs.htm, Nov. 2003. [6] FIPA (Foundation of Intelligent Physical Agents), http://www.fipa.org/ [7] JADE, http://jade.tilab.com/ [8] Y.Z. Zhao, J.B. Zhang, L. Zhuang, and D.H. Zhang, “Service-oriented architecture and technologies for automating integration of manufacturing systems and services”, Proc. 10th IEEE Conf. Emerging Technologies & Factory Automation, 19-22 September 2005, pp. 349-354.