A multi-agent architecture for control of AGV systems

ARTICLE IN PRESS

Robotics and Computer-Integrated Manufacturing 20 (2004) 473–483 www.elsevier.com/locate/rcim

A multi-agent architecture for control of AGV systems Pooya Farahvash, Thomas O. Boucher Industrial & Systems Engineering, Rutgers University, 96 Frelinghuysen Road Piscataway, NJ, 08854, USA

Abstract Agent is an autonomous, computational entity that can be viewed as perceiving its environment and acting upon it. Agents are event-driven objects that can be integrated in automated manufacturing environments to control certain tasks. In this paper a set of agents (a multi-agent system) is introduced to control an automated manufacturing environment. The architecture includes functions at the manufacturing cell level, materials handling and transport level, and factory scheduling level. Communication between these agents is accomplished by using a relational database (blackboard system). The relational database also integrates the requirements of a manufacturing execution system within the multi-agent task structure, which is unique to this architecture. Manufacturing cell and scheduling agents have been previously described in the literature. Here we focus our attention on the functions of the agents of the transport system, which is composed of a set of AGVs. r 2004 Elsevier Ltd. All rights reserved. Keywords: Multi-agent systems; Automated guided vehicles; Flexible manufacturing systems

1. Introduction Generally speaking an agent is a software (or hardware) object that is capable of doing some specific tasks autonomously. Parunak [1] defines an agent as a ‘‘proactive object’’. That is, a software entity is an agent if it has the data and code encapsulation of a software object, its own thread of control (making it an active object) and the ability to execute autonomously without being invoked externally (thus proactive rather that reactive). Wooldridge [2] has another definition: ‘‘An agent is a computer system that is situated in some environment, and that is capable of autonomous action in this environment in order to meet its design objectives.’’ The definition of agent that has been followed in this paper is that which Weiss introduced [3]: ‘‘Agents are autonomous, computational entities that can be viewed as perceiving their environment through sensors and acting upon their environment through effectors.’’ This definition is related to WoolCorresponding author. Tel.: +1-732-445-3657; fax: +1-732-4455467. E-mail address: [email protected] (T.O. Boucher).

0736-5845/$ - see front matter r 2004 Elsevier Ltd. All rights reserved. doi:10.1016/j.rcim.2004.07.005

dridge’s. Sensors and effectors can be either physical (field devices) or software (files or data streams). From these definitions the following characteristics can be introduced for agents:













Autonomous: The agent can work independently. Independent in the sense that it can perform its assigned jobs without the need of continuous interference of human intelligence. Interacting: Agents may affect other agents or may be affected by other agents or even humans. Communication is one of the major characteristics that must be considered in the design of multi-agent systems. Also they can interact with their environment through sensors and actuators. Intelligent: For the purpose of pursuing and executing tasks, some level of intelligence must be present in the design of the agent. The agent operates rationality in a variety of environmental circumstances. Flexible: Agent design and architecture should consider different environmental states and act properly in different situations.

A multi-agent system (MAS) is a loosely coupled network of problem-solver entities that work together to

ARTICLE IN PRESS 474

P. Farahvash, T.O. Boucher / Robotics and Computer-Integrated Manufacturing 20 (2004) 473–483

find the answer to problems that are beyond the individual capabilities or knowledge of each entity [4]. In other words a MAS is a set of agents that either cooperate or compete to solve a problem. A MAS is usually used in cases where the problem is complex, data is decentralized, and computation is asynchronous. In such cases, it is preferred to distribute tasks over a number of agents and let them work autonomously and also interact with each other. A major subject of research in multi-agent systems is architecture design. The central issues in architecture design are the responsibilities and behavior of individual agents, the coordination of activities among agents, and the communication protocols to be employed. Some examples applied to flexible manufacturing systems (FMS) exist in the literature. MetaMorph [5] is an agent-based, mediator–centric architecture. In MetaMorph, mediators assume the role of system coordinators among intelligent agents, such as machine agents and tool agents. Communication is accomplished using Knowledge Query and Manipulation Language (KQML) protocol [6]. A completely decentralized approach is introduced in [7]. Here, workpieces and workstations are represented by agents. As workpieces are introduced into the FMS, an instance of a workpiece agent is created. The workpiece agent negotiates with workstation agents for the operations necessary to manufacture the parts. In [8], a conceptual architecture of an adaptive production control system is introduced. Workpieces and resources are represented by distributed agents that negotiate for work through a bidding process. If imbalances arise in the work allocation, a supervisory agent can be introduced to assess the current status of a group of resources and optimize the workload across the resources within its span of control. In [9], an architecture is proposed that incorporates error recovery when system failure occurs. In addition to agents for planning and control, recovery agents are designed to diagnose error states and provide recovery plans. Recovery agents are coordinated with cell, workstation, and equipment agents using mediator agents, whose purpose is to facilitate communication. Some researchers have focused on architectures for shop floor material handling systems. In [10], AGVs are represented by intelligent agents. They bid against each other for transporting loads between pick up and delivery points and determine the best paths for accomplishing the task. Communication among agents and pick up/delivery stations is accomplished using a blackboard system. In [11], colored Petri nets and simulation are used for performance analysis of a transport system with an agent architecture consisting of part agents and AGV agents. The architecture is completely distributed. Parts initiate a bidding process by broadcasting a request, to which AGVs respond. However, the emphasis here is on evaluating the

performance of different physical transport system designs under the control of the proposed agent architecture. A hybrid architecture that includes AGV agents and other warehouse transporter agents is introduced in [12,13]. This architecture includes both distributed agents and hierarchical control agents. Lower-level agents are allowed to negotiate with one another within the boundaries set by the higher-level agents. Communication among agents is accomplished using a blackboard system. The researchers show how the proposed architecture is applied to warehouse picking operations using gantry robots and to a shop floor environment consisting of part agents, Cell Agents, and material handling agents, including AGVs. In the current proposal we introduce an architecture that integrates shop floor agents for scheduling, cell control, transportation, and material management. Agents are designed at the supervisory control layer. These agents operate autonomously and interact with each other using a blackboard system that is unique in that it integrates database requirements for the factory manufacturing execution system (MES) within the agent framework. The remainder of this paper is structured as follows. In Section 2 we describe the agent architecture adopted in this research. In Section 3 we discuss the architecture of the multi-agent system. In Section 4 we describe agent communication. In Section 5 we discuss a typical example of agents coordinating their activities in the completion of a task. This is followed by a description of methods used by the agents in controlling the AGV system. An experimental case study is discussed in Section 7. Some concluding remarks are given in Section 8.

2. Agent architecture Agent architecture is a map of the internals of an agent and its data structure, the operations that may be performed on these data structures, and the control flow between these data structures. Agents that we designed in this project are reactive agents. Wooldridge defines reactive agents as agents in which decision-making is implemented in some form of direct mapping from situation to action. He introduces a method to formalize the architecture of reactive agents. We follow this formalization, but introduce new components to this architecture. An agent will typically sense its environment (either by physical or software sensors) and, after performing some computations, issue action(s) through its communication process or through its actuators; see Fig. 1. We assume all states of an agent’s environment can be shown by a set S : S ¼ fs1 ; s2 ; s3 ; . . .g. At any given instant, the environment is assumed to be in one of these states. All actions that can be performed by

ARTICLE IN PRESS P. Farahvash, T.O. Boucher / Robotics and Computer-Integrated Manufacturing 20 (2004) 473–483

475

AGENT

AGENT see

action

Output Actuator

Sensor Input

Output Sensor

Actuator

Input ENVIRONMENT

ENVIRONMENT

Fig. 1. An agent and its environment [2].

Fig. 2. Perception and action subsystems [2].

agent’s actuators can be represented by a set A : A ¼ fa1 ; a2 ; a3 ; . . .g. A reactive agent can be defined as a function, action: S n ! A. S is the set of sequences of the states of the environment. If there is a one-to-one relationship between the environment state set and the action set, this function becomes simply action: S ! A. This latter type of agent is called purely reactive agent. Purely reactive agents decide what to do without reference to their history. They base their decision making entirely on the present, with no reference at all to the past. Behavior of an environment can be modeled as a function env: S  A ! S, which takes the current state of the environment s 2 S and an action a 2 A (performed by agent), and maps them to a set of environment states (s,a) that could result from performing action a in state s. For the purpose of explaining how to design the decision function action, we now decompose agents into sub-systems. Fig. 2 shows a fairly high level internal architecture of a purely reactive agent. Here we separated an agent’s decision function into perception and action subsystems. Function see represent the agent’s ability to observe its environment, whereas the action function represents the decision making process of the agent. Output of the see function is a percept (a perceptual input). Then see is a function, see: S ! P, that maps the environmental states to percepts and now action is a function, action: Pn ! A, that maps a sequence of percept to actions. Suppose that we have two environment states, s1 2 S and s2 2 S, such that s1 and s2 are not identical states, but see(s1)=see(s2). Then two different states are mapped to the same percept and, hence, the agent would receive the same perceptual information from different environment states. As far as the agent is concerned, s1 and s2 are indistinguishable. One step down into the design of an agent is considering agents with internal states. It is common to consider an agent that has different states, as shown in Fig. 3. These agents have some internal data structure, which typically is used to record information

AGENT

see

next

action

state

Sensor

Actuator ENVIRONMENT

Fig. 3. Agent that maintains internal state information [2].

about the environmental state and history. Let I be the set of all internal states of the agent. An agent’s decision-making process is then based, at least in part, on this information. The perception function see remains unchanged, see: S ! P. An additional function next is introduced, which maps an internal state and a percept to an internal state, next: I  P ! I. The action function is changed to action: I ! A. The agent starts in an initial state i0. It then observes its environment state s, and generates a percept see(s). The internal state of the agent is then updated via next function next(i0,see(s)). The action selected by the agent is then action(next(i0,see(s))) and the cycle continues. In practical systems, such as manufacturing, the role of data analysis becomes important. Not all decision functions are characterized by a direct response to environmental inputs. Often there are some internal states driven by information other than percepts and the Next function. Here we extend the architecture proposed by Woodbridge as shown in Fig. 4. Let I be the set of all internal states as previously defined. The function Read is introduced, which maps an internal state and encapsulated agent data, D, to an internal state; Read: I  D ! I. Also, some internal states of the agent operate on data encapsulated within the agent. Therefore, there exists an action function on internal data, Write: I ! D. These additions to the model are shown in the architecture of Fig. 4.

ARTICLE IN PRESS 476

P. Farahvash, T.O. Boucher / Robotics and Computer-Integrated Manufacturing 20 (2004) 473–483

AGENT

see

action D

Input

Sensor

next

Actuator

read

state

Output

ENVIRONMENT

Fig. 4. Reactive agent with data-driven state change [14].

σ Cell Agent(s)

Machines and Robots

ψ Environment

σ Relational Database

(Simulation Model)

Scheduler Agent

ψ

Material Manager Agent

σ ψ AGVs

σ Traffic Controller Agent

ψ

Fig. 5. High-level architecture for proposed MAS [14].

3. Multi-agent system architecture A manufacturing MAS has been constituted by four types of agents: (1) Cell Agent(s), (2) Scheduling Agent, (3) Material Manager Agent, and (4) Traffic Controller Agent. Fig. 5 shows the high-level architecture of our MAS. The Cell Agent and Scheduling Agent functions and methods have been described elsewhere [15–17]. Here, we focus on the material manager and Traffic Controller Agents that are responsible for the transport system. The Material Manager Agent is a multi-state agent that senses changes in its environment and reacts to those changes. The main task of this agent is to assign AGVs to requests for material movements that come from the manufacturing Cell Agents. Fig. 6a presents a digraph of the different internal states of the Material

Manager Agent. Internal states are depicted as circles. Fig. 6c depicts a digraph for different states of the environment (the network of AGVs). If there are more than one AGV, each AGV has the same digraph. These digraphs show related actions and events. An ‘‘Action’’ is a communication from an agent to the environment. It is associated with a state and is shown in a rectangle next to the state. Thus, when the Material Manager Agent is in state M(i3), it outputs the action M(A1) to the environment. ‘‘Events’’ are inputs that cause the digraph to change states and are indicated by labels on the arcs of the digraphs. Thus, when action M(A1) is given by the Material Manager Agent, it is an input event to the environment (AGV) on arc S1-S2. When M(A1) occurs, the environment changes state from S1 to S2. The meaning of states, perceptions, and actions are described

ARTICLE IN PRESS P. Farahvash, T.O. Boucher / Robotics and Computer-Integrated Manufacturing 20 (2004) 473–483

477

M(i1) T(W1): record_link_free T(i2)

P1

P4 P3

M(i2)

¬P2

TRUE

P5 T(i3)

T(i1) P2

¬D1

¬ P3 P6

D1

M(i3) T(i4) M(A1): move_order_true

T(A1): permission_issued

(a)

(b) S1: Checking for move orders M(A1): move order true TRUE S2: Read move data and acknowledgement P3: acknowledgement_true

S6: Unload and write job done to material manager agent TRUE P2: AGV_available_true

S3: Request link P5: link_request_true EOF

S5: Check if EOF

¬ EOF

move_done

P4: free_link_true

T(A1): permission_issued S4: Acknowledge and move through link P6: acknowledgement_true

(c) Material Manager Agent: Internal States, I: M(i1) - Reading move request; M(i2) - Updating free AGV file; M(i3) - Writing move data to AGV. Perceptions, P: P1 - move_request_true; P2 - AGV_available_true; P3 - acknowledgement_true. Actions, A: M(A1) - move_order_true. Traffic Controller Agent: Internal States, I: T(i1) - Reading requests and checking for free links; T(i2) – Recording free link, T(i3) –Checking for available link, T(i4) – Issuing permission to use link. Perceptions, P: P4 - free_link_true; P5 - link_request_true; P6 - Acknowledgement_true. Actions, A: T(A1) - permission_issued. Data, D: D1 – link_is_available. Write, W: T(W1) – record_free_link.

Fig. 6. Digraphs of (a) Material Manager Agent (b) Traffic Controller Agent and (c) Environment.

in the legend at the bottom of Fig. 6. Related actions and events between the Material Manager Agent and the environment will now be described as follows: M(A1): move_order_true: This action is generated by the Material Manager Agent and causes an AGV to

change its state from ‘Checking for move orders’ to state ‘Read move data and send acknowledgement’. This action is a message from the Material Manager Agent to AGV to tell the AGV to start a new task. Actions or communications from a sender are depicted as italic

ARTICLE IN PRESS 478

P. Farahvash, T.O. Boucher / Robotics and Computer-Integrated Manufacturing 20 (2004) 473–483

within a box on the sender’s digraph and are depicted in italics on the receiver’s event arc. P1: move_request_true: This event is generated by the Cell Agent(s) every time raw material or finished products need to be moved from/to warehouse. Perception of this event, P1, changes the state of the Material Manager Agent to ‘Updating free AGV file’, M(i2). P2: AGV_available_true: The communication of this event from the environment (AGV controller) to the Material Manager Agent indicates completion of an AGV task. The state of the AGV then changes to S1: ‘Checking for new move orders’. The same event indicates to the material manager agent that an AGV is done with its task and is free. Actions that are received communications of an agent from the environment are depicted as perceptions, P, on the arc of the receiver’s digraph. P3: acknowledgement_true: This event is generated by the controller of an AGV and indicates that the AGV controller has read the necessary data for serving the move request. The same event changes the state of the Material Manager Agent from M(i3) to M(i1). If the acknowledgement is not received within a predetermined time duration (:P3), the agent returns to M(i2). The Traffic Controller Agent is responsible for preventing collisions on the network and insuring point-to-point passage of the AGVs from origin to destination. This is done by direct communication from the agent to the AGVs. The digraph of the Traffic Controller Agent is shown in Fig. 6b. Related actions and events between this agent and the environment are as follows: P4: free_link_true: This event is generated by the controller of the AGV setting a bit in memory, indicating that it has passed through the link and the link is no longer occupied. T(W1): record_free_link: a ‘‘write’’ action to the encapsulated data file of the traffic controller agent in order to record the availability of a link. P5: link_request_true: This request is generated by the AGV controller when it wants to enter a link. D1: link_is_available: This is a data-driven read event that occurs when the traffic controller checks its encapsulated data file for the availability of a link and the link is free. T(A1): permission_issued: A Traffic Controller Agent’s action permitting the AGV to use the link. P6: acknowledgement_true: This event is generated by the controller of the AGV and it indicates that the AGV received the permission to use the link. Communication between the agents and the environment uses a master/slave protocol. This is roughly comparable to a client/server architecture, where the master always initiates the communication and the slave services the communication request. Each AGV indicates its change of state (events) by setting a bit in its

controller memory. The agents will periodically poll the controllers of the AGVs to obtain event information. All actions that are generated by the agents or the AGV controller are persisting and they remain in the memory or data files until the receivers read and clear them.

4. Agent-to-agent communication Communication among the agents is done through a relational database. Agents write the information and their requests to other agents into the database and these data are available for other agents to work on and respond (Blackboard system). The database is also used to maintain an audit trail on how orders are executed on the shop floor. This is consistent with the data requirements of a manufacturing execution system (MES). Thus, the agents use the database as both a communication device and as an information system for the permanent storage of data. The data model is shown in Fig. 7. A brief description of the use of the database by the agents is as follows: 1. A Cell Agent requests the movement of raw material to the cell or finished parts from the cell to the warehouse by populating the table MOVE_REQUEST with an instance of a request. 2. The Material Manager Agent reads the table MOVE_REQUEST for requests that have not yet been serviced. It assigns the request to an AGV by populating the table AGV_ASSIGNMENT and, simultaneously, communicates the assignment to the AGV. As indicated in the AGV_ASSIGNMENT table, the destination location (TO_LOC) for storage of finished parts in the warehouse is given at this time. 3. When an AGV completes the assigned move, it sets a completion flag in its controller that is read (polled) by the Material Manager Agent. When this occurs, the Material Manager Agent updates the tables LOT_TRANSACTION, WHOUSE_LOT_XREF, and LOT. When updating these tables, a lot number is assigned to the finished part and its storage location in the warehouse is identified. The LOT_TRANSACTION table is an audit table that keeps track of the debit and credit events (TRANACTION_TYPE) that change the contents of the warehouse storage locations. The data model of Fig. 7 serves functions beyond that of providing a communication medium. Plant information systems have become integral to managing modern factories. Two components that are especially widely used are the enterprise resource planning (ERP) system and the manufacturing execution system (MES). ERP is thought of as a ‘‘planning’’ system because it plans the

ARTICLE IN PRESS P. Farahvash, T.O. Boucher / Robotics and Computer-Integrated Manufacturing 20 (2004) 473–483 LOT_TRANSACTION

WHOUSE_LOT_XREF

TRANSACTION_NO

HAS CONTENTS CHANGED BY

LOT_NO (FK) MOVE_NO (FK) TRANSACTION_DATE_TIME W_LOCATION_ID (FK) TRANSACTION_TYPE TRANSACTION_QTY

479

WAREHOUSE

W_LOCATION_ID (FK) LOT_NO (FK)

W_LOCATION_ID STORES

QTY_STORED

W_AREA W_AISLE W_TIER W_BIN

IS STORED IN

LOT

Z

MATERIAL

LOT_NO

MAKES UP

MATERIAL_NAME MATERIAL_DESCRIPTION UNIT_OF_MEASURE

MATERIAL_ID (FK) CREATION_DATE_TIME QTY_CREATED

CREATES

MATERIAL_ID

AGV_ASSIGNMENT MOVE_NO MOVE_REQUEST

CELL

AGV_ID FROM_LOC TO_LOC REQUEST_DATE_TIME ASSIGN_DATE_TIME COMPLETION_DATE_TIME MOVE_QTY

REQUEST_NO

CELL_ID INITIATES

CELL_DESC

CELL_ID (FK) PART_ID REQ_DATE_TIME QTY_PRODUCED MOVE_NO (FK)

SERVICES

Fig. 7. Data model of MES database used by agents.

use of resources to support the fulfillment of production orders. MES is thought of as a ‘‘tracking’’ system because it attempts to manage resources on an hourly basis and record how those resources are being used. The database of Fig. 7 is designed to provide a history of how resources are used in the execution of the material handling system. It also provides a history of the changes in inventory through withdrawals from and additions to the warehouse. It is possible to review the events of the day, including the use of transport resources by appropriately querying the database. There are other components of the database, not shown, that are related to the activities of the Scheduler Agent and Cell Agents. A more complete description of the operation of the MES is given in the next section, which describes a typical set of activities.

5. A typical scenario Fig. 8 describes a typical scenario of activity involving the MAS. In Fig. 8a, an order has arrived in the database and the Scheduling Agent assigns it to a specific cell. The Scheduling Agent selects the specific cell after a bidding process that has been described

in detail in [15]. The Cell Agent then receives the assignment. In Fig. 8b, the Cell Agent places the request for raw material to be brought to the cell. This is done by entering an instance into the table MOVE_REQUEST. Note that the MOVE_NO is not established at this time. The Material Manager Agent reads the request (state M(i1) of Fig. 6a), finds an available AGV (state M(i2)), and assigns it to an AGV by entering an instance in the table AGV_ASSIGNMENT (state M(i3)). At this time the Material Manager Agent also updates the record in the MOVE_REQUEST table by entering the MOVE_NO. Simultaneously, the assignment is communicated to the AGV by the Material Manager Agent along with path information concerning the move between origin and destination (action M(A1) in state M(i3)). In Fig. 8c, the Traffic Controller Agent begins its task. Before an AGV can make a move, it must request the use of a link in the AGV network (state T(i1) in Fig. 6b). It is the job of the Traffic Controller Agent to determine whether or not the link is available (state T(i3)) and to give permission to the AGV to use the link (state T(i4)) or to withhold permission if the link is being used by another AGV. When the AGV completes the traverse of a link, it sets a flag in its

ARTICLE IN PRESS P. Farahvash, T.O. Boucher / Robotics and Computer-Integrated Manufacturing 20 (2004) 473–483

480

Environment Cell 1

Environment

2

1

3

Cell 2

4

5

6

Cell 3

7

8

9

Cell 1 W A R E H O U S E

W A R E H O U S E

Cell 2

Cell 3

Moving assignment

Production order (to the selected cell)

Production order Cell Agent(s)

Cell Agent(s)

Scheduling Agent

Move request

Production order

Material Manager Agent Move request

AGV assignment info

AGV_ASSIGNMENT

Database

Database MOVE_NO AGV_ID FROM_LOC TO_LOC ASSIGN_DATE_TIME COMPLETION_DATE_TIME MOVE_QTY

ORDER_ID MATERIAL_ID ORDER_QTY 1

2

1

1

2

6

1

11/11/2002 4:35:47 PM

1

REQUEST_NO CELL_ID PART_ID REQUEST_DATE_TIME QTY_PRODUCE MOVE_NO

PRODUCTION_ORDER

5939

1

1000

11/11/2002 4:35:44 PM 1

MOVE_REQUEST

(b)

(a)

Environment

Environment Cell 1

Cell 1 W A R E H O U S E

Cell 2

Cell 2

Cell 3

Cell 3

Permission request (to use a link)

W A R E H O U S E

Permission issued

Link Request

Link free

Traffic Controller Agent

Permission

Job done

Material Manager Agent

Traffic Controller Agent

Task completion info Database

Database

(c)

(d) Fig. 8. A typical scenario.

controller to indicate that the link is now free. The Traffic Controller Agent, which polls the AGV controller flags, can then update its internal file on the status of links (state T(i2)). As shown in Fig. 8d, after sequence of permissions are granted, the AGV has completed its assigned move. The AGV sets a flag in its controller to indicate that the move is completed and the Material Manager Agent, polling that flag, knows that the job is done. At this point the remaining tables of the database are updated.

6. Agent methods for AGV system control In performing their assigned tasks, each agent in the proposed multi-agent system has access to methods. When the agent needs to make a decision, it calls the related method. Methods used by the cell and scheduler agents have been discussed in [16]. The Material Manager Agent calls a method for assigning the best AGV for a particular task. In this method, the AGV that is available and is closest to the pick up point is the chosen AGV.

ARTICLE IN PRESS P. Farahvash, T.O. Boucher / Robotics and Computer-Integrated Manufacturing 20 (2004) 473–483

481

Guidance of the AGV in the network and collision prevention are the main tasks of the Traffic Controller Agent. Reveliotis [18] proposed a method for conflict and deadlock prevention in the AGV network based on a logical model that employs zone control. In our work we assume that the network is designed with crossover points at each node that can accommodate AGVs waiting to access a link, allowing AGVs to pass each other at the nodes. This is similar to the design assumption in [11]. Based on these assumptions, there are four methods designed for the Traffic Controller Agent.

a request for a link is made from the AGV to the Traffic Controller Agent. The Traffic Controller Agent gives priority to the predefined shortest distance path. If the shortest distance path link is not available, the Traffic Controller Agent searches for other legal links. If one is found, it is assigned to the AGV in order to reduce the waiting time of the AGV in the node. If no legal link is available, the AGV will wait at the node until a legal link is available.

6.1. Shortest distance path method

This method is a modified version of the combined shortest distance path and least waiting time method. The modification is made by adding a look ahead feature to the combined method. Here the Traffic Controller Agent performs two calculations before making an assignment. (1) If the next link on the shortest path is occupied, the remaining travel time of the AGV on the link is added to the shortest path time. This is the total estimated time of waiting and travel if the AGV continues to be assigned to the shortest path. (2) The second calculation is to add the time of travel on the alternative legal link to the shortest path distance from the next node (end of alternative path) to the final destination. If (1) is less than or equal to (2), the AGV waits and is assigned to the shortest distance path. If (2) is less than (1), the AGV is assigned to the alternative path.

In this method the shortest distance between two nodes is the best path for routing the AGV. The shortest distance path between each pair of nodes in the network is calculated off line and stored in the internal database of the Traffic Controller Agent. When there is a routing request, the Traffic Controller Agent calls the shortest distance path method, which returns a set of links from origin to destination. This file is downloaded to the memory of the AGVs controller. During the movement of the AGV from origin to destination, the AGV requests permission to enter the next link. If the next link in the shortest distance path is not available, the Traffic Controller Agent does not permit the AGV to enter the link until it becomes free. Therefore, the AGV will wait in the node of the link until it gets permission from the Traffic Controller Agent to enter.

6.4. Modified combined method

6.2. Least waiting time method

7. Case study

In this method, minimization of the waiting time at each node is the goal. The Traffic Controller Agent does not download a predefined path to the AGV for it to follow. Instead, at each node, the AGV requests the Traffic Controller Agent to identify the next link to enter. The Traffic Controller Agent has overall knowledge of the status of links on the network. For a request from an AGV at a specific node, the agent can only consider ‘legal’ links to assign to the AGV. A legal link for an AGV is a link that will cause the AGV to move closer to its destination. If there are more than one legal links available, the agent randomly chooses one of them. If there is one legal link available, the AGV is assigned that link. If there is no legal link available, the AGV stays at the current node until a legal link becomes available and is assigned by the Traffic Controller Agent. Since the AGV is not waiting in the node for a predefined link, as in the shortest path method, waiting time is reduced.

In order to demonstrate how different routing methods perform for a specific design, an experiment was performed using a simulation model of an automated production facility. This production facility consists of three production cells and a warehouse. A network of 9 nodes and 12 links provides routes for AGVs. A sketch of this environment is shown in Fig. 8a. Cells are located at nodes 1, 4 and 7 and the warehouse is in node 6. Table 1 shows the length of links, which were selected from a uniform distribution between 40 and 60. Speed of AGVs is assumed to be 1 (unit of length/unit of time). For this trail 100 production orders are randomly chosen from 20 part types and 10 sets of these order populations are generated for 10 experiments. Each part type can be manufactured by two cells. For the experiments each order has been assigned to a pre-specified cell. This assignment is done by balancing the workload of all of the three cells relatively equally. The four methods (treatments) are compared on the basis of move request service time. The move request service time is defined as the time elapsed between the receipt of a move request by an AGV and the

6.3. Combined method This method is a combination of the shortest path method and the least waiting time method. At each node

ARTICLE IN PRESS P. Farahvash, T.O. Boucher / Robotics and Computer-Integrated Manufacturing 20 (2004) 473–483

482

8. Summary

Table 1 Links length Link

Length

Link

Length

1-2 2-3 1-4 2-5 3-6 4-5

52 58 41 60 46 46

5-6 4-7 5-8 6-9 7-8 8-9

54 43 56 44 59 48

SDP LWT SDP-LWT M-SDP-LWT

Ex p1 Ex p2 Ex p3 Ex p4 Ex p5 Ex p6 Ex p7 Ex p8 Ex p9 Ex p1 0

Time

Move Request Service Time 300 290 280 270 260 250 240 230 220 210 200

SDP: Shortest Distance Path Method LWT: Least Waiting Time Method

SDP-LWT: Combined Method M-SDP-LWT: Modified Combined Method

Fig. 9. Comparision of move request service time for different routing methods.

completion time of this move order. Fig. 9 shows the move request service times of the 10 different experiments. It can be seen that for this specific network the shortest distance path method doesn’t perform as well as the other three. The shortest distance path method results in 10–12% longer service time. This result can be explained by considering the design of the network of links for the case study. It can be seen that the shortest distance path between the warehouse and three cells are: 6-5-4-1 (warehouse to cell 1), 6-5-4 (warehouse to cell 2) and 6-5-4-7 (warehouse to cell 3). Therefore the 6-5 and 5-4 links will have a very high congestion, if the Traffic Controller Agent tries to follow the shortest distance path. But the other three routing methods may utilize the alternative path (if one is available), so the congestion on those two links is decreased. Methods that consider alternative routings outperform the shortest path method in AGV systems. However statistical tests among these latter three methods indicate that there is no difference in performance. What is needed in agent-based systems is dynamic selection among the methods as the situation (positions of AGVs) in the network changes. Current work is directed toward ways of enabling the Traffic Controller Agent to dynamically select the most appropriate method under changing circumstances.

Agents are computational entities that sense their environment, analyze the events and act upon the environment. Independence, interaction, flexibility and intelligence are common characteristics of agents. This work introduced a multi-agent system architecture that controls different aspects of a manufacturing environment. The material manager and the traffic controller are agents that manage the AGVs and their movements. In addition, the Material Manager Agent also manages the database of the manufacturing execution system, providing a permanent record of shop floor activities. The system of agents has been implemented in C++ and an experimental test has been performed in which the agents control the simulation model of a production facility programmed in Arena. Four different routing methods are introduced that could be used by the Traffic Controller Agent to guide the AGV in the network of links. This experiment showed that using a combination of routing criteria regularly outperformed the use of shortest distance path. The experiment suggests that performance of the routing methods depends on the design of the network and current states of AGVs in the system. Further research will incorporate these considerations in a dynamic selection of routing method by the Traffic Controller.

Acknowledgement This material is based on work supported by the National Science Foundation under Grant No. 0085135. References [1] Parunak HD. Practical and industrial application of agent-based systems. In: Weiss G, editor. Multiagent systems. Cambridge: The MIT Press; 1999. [2] Wooldridge M. Intelligent agents. In: Weiss G, editor. Multiagent systems. Cambridge: The MIT Press; 1999. [3] Weiss G. Multiagent systems. Cambridge: The MIT Press; 1999. [4] Flores-Mendez RA., Toward a standardization of multi-agent system frameworks, ACM Crossroads, Issue 5.4, 1999. [5] Maturana F, Shen W, Norrie DH. MetaMorph: an adaptive agent-based architecture for intelligent manufacturing. Int J Prod Res 1999;37(10):2159–73. [6] Finin T, Fritzon R, McKay D, McEntire R. KQML—a language and protocol for knowledge and information exchange. Technical Report, University of Maryland, 1993. [7] Duffie NA, Piper RS. Non-hierarchical control of a flexible manufacturing cell. Robotics Comput Integrated Manuf 1987;3: 175–9. [8] Ottaway TA, Burns JR. An adaptive production control system utilizing agent technology. International J Prod Res 2000;38(4): 721–37. [9] Odrey NG, Mejia G. A re-configurable multi-agent system architecture for error recovery in production systems. Robot Comput Integrated Manuf 2003;19:35–43.

ARTICLE IN PRESS P. Farahvash, T.O. Boucher / Robotics and Computer-Integrated Manufacturing 20 (2004) 473–483 [10] McElroy J, Stephens LM, Bonnell RD, Gorman J. Communication and cooperation in a distributed automatic guided vehicle system. IEEE Proceedings, Southeastcon, 1989. p. 999–1003. [11] Nandula M, Dutta SP. Performance evaluation of an auctionbased manufacturing system using colored Petri nets. Int J Prod Res 2000;38(10):2155–71. [12] Heragu SS, Graves RJ, Kim BI, Onge AS. Intelligent agent based framework for manufacturing systems control. IEEE Trans Syst, Man, Cybern 2002; Part A, 32(5): 560–73. [13] Kim BI, Graves RJ, Heragu SS, Onge AS. Intelligent agent modeling of an industrial warehousing problem. IIE Trans 2002;34:601–12.

483

[14] Farahvash P. Application of multi-agent systems in automated manufacturing, M.S. thesis, Industrial & Systems Engineering, Rutgers University, 2002. [15] Boucher TO, Yalcin A, Tai T. Dynamic routing and the performance of automated manufacturing cells. IIE Trans 2000;32(10):975–88. [16] Tai T, Boucher TO. An architecture for scheduling and control in flexible manufacturing systems using distributed objects. IEEE Trans Robotics Automation 2002;18(4):452–62. [17] Yalcin A, Boucher TO. Deadlock avoidance in flexible manufacturing systems using finite automata. IEEE Trans Robotics Automation 2000;16(4):424–9. [18] Reveliotis SA. Conflict resolution in AGV systems. IIE Trans 2000;32(7):647–59.