AgvTalk: An object-oriented simulator for AGV systems

Computers ind. Engng Vol. 28, No. 3, pp. 575-592, 1995

Pergamon

0360-8352(94)00210-X

Copyright © 1995 ElsevierScienceLtd Printed in Great Britain. All rights reserved 0360-8352/95 $9.50+0.00

AgvTalk: AN OBJECT-ORIENTED SIMULATOR AGV SYSTEMSt RUSSELL E. KING' and KYUNG SUP

FOR

KIM 2

'Department of Industrial Engineering, North Carolina State University, Raleigh, NC 27695-7906, U.S.A. and :Department of Industrial and Systems Engineering, Yonsei University, Seoul, Korea Al~trlct--In this paper, AgvTalk, an object-oriented simulation tool for the design and analysis of AGV system configuration and control is presented. Smalltalk-80 is used as an implementation language in AgvTalk. AgvTalk includes 25 object classes and more than 300 object methods in its library. Compared to general purpose simulation languages, AgvTalk provides several important benefits. First, the hierarchical features and modularity create possibilities for the extension and reuse of simulation object components. This extensibility and reusability provide more flexible modeling capabilities for simulation of many alternative AGV systems. Second, detailed behavior of each object in the AGV system can be modeled easily and exactly because there are no limiting modeling constructs. Third, AgvTalk provides a user-friendly simulation modeling environment through the MVC-triad of Smalltalk-80. This paper also presents a one-to-one comparison of modeling features between AgvTalk with traditional simulation languages.

1. INTRODUCTION

Automated guided vehicle (AGV) systems have been regarded as one of the most exciting and growing areas of material handling and automation today. Although the early uses of AGVs were warehousing and distribution applications, development of hardware and software technology makes the AGV systems the most visible system in the application of manufacturing systems. In particular, because microprocessor technology has developed over the past decade, AGV systems are considered as highly flexible handling systems for the effective operation of such systems as flexible manufacturing systems (FMS) and flexible assembly systems. Efforts to make AGV systems even more flexible are underway by eliminating the constraints which are imposed by the floor-imbedded guidance wire. When designing and planning an automated material handling system, a large number of factors must be considered. In particular, with an automated guided vehicle (AGV) system, things such as the number of vehicles, a guidepath network configuration, control logic for dispatching vehicles, routing of vehicles from origin to destination, and interface with other material handling systems must be considered. Although much work has been done in the design and analysis of AGV systems [1] due to the complexity of these systems, simulation has been used as the primary analysis tool in designing, planning and analyzing AGV systems. Much of the modeling and simulation in the literature of material handling systems have been done by general-purpose simulation languages such as SIMAN [2] or SLAM [3]. Recently, material handling features have been added to SIMAN and SLAM extensions. Although these extensions make the size of the simulation code much smaller, they are not easy to implement due to the inherent functional complexity of each feature. Moreover, these features are not flexible enough to serve as a basis for simulating the great diversity of many alternative material handling systems. Some manufacturing simulation systems [4] such as FACTOR, X C E L L + , MAST, PROMOD,and SIMFACTORY have modeling constructs for manufacturing systems including an AGV system. However, these systems are also inflexible in that they are limited to modeling only those manufacturing configurations allowed by their standard features. To provide flexibility and reduce the complexity of the task of simulating an AGV system, simulation program generators specific for an AGV system have been developed. These include the tResearch supported, in part, by the Office of Naval Research, Contract N00014-90-J-1009. 575

576

Russell E. King and Kyung Sup Kim

C-based AGVSim [5], and SIMAN-based SCG [6]. However, these still do not overcome the modeling limitations of their implementation languages. Systems and processes in most manufacturing environments are constantly changing to keep pace with new technologies. Simulation tools are required that can accurately model a system in detail, yet still be easy to use, and allow rapid model redevelopment to react quickly to system changes [7]. Inherently, conventional approaches do not provide such capabilities. Object-oriented simulation is one such technique that allows an easy adaptation to system changes due to its inherent characteristics of extensibility and reusability [8]. Although object-oriented simulation has a long history since SIMULA, the first object-oriented language, was developed in the 1960s for simulation purposes, the extensive use of object-oriented simulation using object-oriented languages such as Smalltalk and C + + is relatively new. There is a growing list of applications of the object-oriented paradigm to manufacturing systems (see e.g. [9] or [10]) however, simulation of material handling systems such as AGV systems using object-oriented simulation has not been examined in the literature. In an object-oriented approach, a system is modularly decomposed based on classes of objects the system manipulates, not on the function the system performs [l l]. Objects are characterized and encapsulated by their state and the operations that can be performed on that state. Objects communicate with each other by sending messages in order to perform a task. When an object receives a message, the appropriate method is invoked where the response to the message is defined. Unlike in conventional programming languages, the message invokes the method specific to the object, as determined at execution rather than at compile time. This is known as dynamic binding. Thus, the single message can produce different interpretation by different receivers. This condition is termed polymorphism. In an object-oriented approach, classes are hierarchically organized in subclass relationships [12]. Every representation and characteristic of an object defined in a superclass is inherited by objects of its subclasses; therefore, differences from the superclass are defined in the subclass. From the above characteristics, an object-oriented approach provides such advantages as reusability, extensibility, modularity, and portability. 2. OBJECT-ORIENTEDDESIGN FOR AGV SYSTEMS An AGV system consists of objects such as vehicles, workstations, machines, and jobs (parts). A natural one-to-one correspondence can be applied between physical objects in a real AGV system and instances of simulated objects. Message passing in an object-oriented approach (instead of function calls in conventional programming) is more natural and convenient way to represent an AGV system. For example, a message signifying the arrival of a part can be sent to an object representing a WorkStation which may then trigger processing at the workstation. The same message can be sent to an AGV to trigger its movement from one station to another. The inheritance of methods and representation by a hierarchical class structure allows the construction of new objects from existing objects by adding, reducing, or modifying their functionality. For example, the modeling of a general AGV system may be extended to more specific AGV systems by adding their own specific operational characteristics in the subclass. In this section, the logical design of the AGV system is discussed from an object-oriented view point. This discussion includes the design of a model and an experiment for AGV systems. The design is represented by an object diagram [13]. Since it is generally infeasible to capture all the subtle details of a complex AGV system, the key mechanisms will be represented in an object diagram. An object diagram is used to show the existence of objects and their interrelationships in the logical design of a system. The diagram illustrates the dynamic semantics of the key mechanisms in the logical design. A relationship between two objects simply means that the objects can send messages to one another (a line is used to designate these relationships). To specify the visibility between the objects, a directed arc is added next to the line. The symbols used for the object diagram are shown in Fig. 1.

2.1. Object-oriented design of a model 2. !. 1. AG V system. At the highest level of abstraction, an AGV system consists of a cooperating collection of objects such as vehicles, zones, and machines. Direct visibility among instances at all

AgvTalk: an object-oriented simulator for A G V systems

577

Thcre is a relationship between objects A An object B is visible to an object A Fig. 1. Icons for object relationship.

levels of abstraction is a poor design [13]. Instead, the largest conceptual groups are selected at the highest level of abstraction of their visibility. For an AGV system, the material handling system, the production system, the interface, and the part are selected as the largest conceptual groups. The part represents the passive medium of communication among the other three objects. The material handling system describes the movement behavior of vehicles from one location to another along the fixed guidepath, and includes objects such as vehicles, controllers, zones, request queues, etc. The production system describes the part processing operations at workstations and includes objects such as workstations and machines. The interface represents the interface between the material handling system and the production system, and includes input and output buffers. These four objects are included as direct components of the enclosing AGV system. However, many different designs are possible according to the definition of the relationships between these objects. In particular, designs at the higher level of abstraction are more critical and sensitive to the design of a whole system because each design feature directly affects the design at the lower levels of abstraction. For the design of an AGV system at the highest level of abstraction, three objects (the material handling system, the production system, and the part) are visible to the interface and vice versa. This approach matches the physical architecture of the AGV system naturally. Thinking about operations that the interface can meaningfully perform upon each of three other visible objects, the following are derived from the point of each object. • On the material handling system dropOffLoad pickUpLoad activateldleVehiclel fAvailable • On the part update • On the production system process The above operations are the only communication between the interface with the material handling system, production system, and part with the interface. Looking at this same problem from the opposite direction, we can determine what operations the material handling system and the production system perform on the interface. Since the part is a passive object, it does not perform any operations on other objects. • By the material handling system accept Load ForProcessing releaseLoadForDelivery • By the production system accept Load ForDelivery releaseLoad ForProcessing This design protocol leaves us with clear separation and modularity among objects at the highest level of abstraction. The material handling system encapsulates by dropping off and picking up loads, and by activating an idle vehicle if available. The part encapsulates by updating the status of itself. Similarly, the production system encapsulates by processing parts. The interface encapsulates by serving as a communication center between the material handling system and the production system, receiving or sending parts for processing or delivery. These design decisions are shown in the object diagram in Fig. 2. 2. i.2. Material handling system. Figure 3 shows the semantics and relationships between objects in the material handling system. The material handling system only communicates with the

RussellE. Kingand KyungSupKim

578

/ / "

.~_heMaterialHandlingSystem~ 1

\\it dropOffLoad /~

releaseLoadForDellvery II~

acceptLo~o::::~ng ~i\~PickupUpLoa~/ activai¢idleVehiclelfAvailable /

process I

acceptLoadForDelivery releaseLoadForProcessin 8

Fig.2. AGVsystemobjectdiagram. Interface in two ways. First, the communication is performed between the AGV and the Interface when the AGV arrives at a station for a pick up or delivery task. Second, when a work station finishes processing a part and the part needs to be moved to the next station according to the part routing, the Interface where the finished part stays directly sends message activateldleVehicle fAcailable to the AGVSController in the material handling system. The AGVSController is the information collection and distribution center in the material handling system. Every object in the material handling system is visible to the AGVSController; however, the AGVSController is visible only to an instance of an AGV. With the exception of the AGVSController and the AGV, all other classes are encapsulated by themselves. Each time the AGV stops in the network, the AGV passes the message update to the AGVSController. In response to this message, the AGVSController passes appropriate messages to the simulation support objects (e.g. theRoute, theZone, etc.) to receive the information necessary for the AGV to restart. This information is distributed to the AGV with the appropriate message for the next movement. In fact, AGV movement consists of travel through a sequence of the divided zones. Each time an AGV moves through a zone, the AGV passes the message update: to the controller with information of the current zone. Then, the controller collects all information of the next zone such as zone identification, zone availability, zone distance, zone travel time, etc. If the next zone is available, the controller passes the message travelZone to the AGV. If not available, the message waitForA While is sent to the AGV from the controller. 2.1.3. Production system. As can be seen in the object diagram (Fig. 4), there is one class, the WorkStation, in the production system. The WorkStation communicates only with the Interface. When the WorkStation needs to process a part, the message releaseLoadForProcessing is sent to the Interface. Then, the Interface passes the message process. If the resource is not available, the processing operation may be blocked temporarily. When the WorkStation finishes the processing operation and passes the message acceptLoadForDelivery, the Interface activates the work center initiated dispatching rule in the material handling system if

579

AgvTalk: an object-orientedsimulator for AGV systems

ItheldleAGV

theRoute

provideldleVehicleslnformation

[ theDispatching ]

theRequestQ I

IT

provideRoutingSequence

= [

update

~

uestLi

theZone

findNextStationByRule ~ p r o v i d e ~ n e l n f o r m a t i o n findldleVehicleLocationByRule~ providePathConfiguration

deliverToNextStatio,/? travelToNextStation travelToStagingArea update:#currentStation waitForAWhile #currentZone travelZone / d~panType #partRoute

i%

activateldleVehiclelfAvai|able

\ acceptLoadForProcessir

dropOffLoad pickupUpLoad

/

releaseLoadForDelivery

Fig3..Material handling system object diagram. an idle vehicle is available. This is done by sending activateldleVehiclelfAvailable to the AGVSController. 2. !.4. Interface. The object diagram for the interface is shown in Fig. 5. The material handling system and the production system communicate with each other through the Interface. When the Interface is sent messages from the material handling or the production systems, such as accept LoadForProcessing, releasedLoadForDelivery, accept LoadForDelivery, and releaseLoadForProcessing, there is a flow of control internally in the class Interface before the Interface responds to these messages. First, the Interface sends the message update to itself. Then, the status of the appropriate subclass (InputBuffer or OutputBuffer) is updated. In response to the message update, the buffer appropriately sends the message enter: or exit: to the AGVSStatisticsControl with the instance of the Part as a parameter. The AGVSStatisticsControl calculates the flow time and time average statistics internally. Whenever the Interface updates its status, the status of the Part (Job)

process

I I

acceptLoadForDelivery releas©LoadForProcessin

aWorkStation [ Production system object dia~am.

Fig4..

580

Russell E. King and KyungSup Kim

update

/

~

update

enter:#anObject~~ exit:#anObject ~

/enter: #anObject exit:#anObject

\ I theSimulationObjectSecord [

enter:#time exit:#time duration

theAGVSStatisticsControl / store:#duration print

theOutput Fig. 5. Interfaceobjectdiagram. is also updated by sending message update to itself. This status includes the current location (current station, input or output buffer), the entry time of the current buffer, etc.

2.2. Object-oriented design for an experiment Figure 6 represents the top level of an experiment. Three objects are defined: the DiscreteEventSimulation, the AGVProblem, and the AGVSystem. The DiscreteEventSimulation provides the discrete-event simulation framework, in which the AGVProblem is defined. As discussed in the design of the model, the AGVSystem includes the material handling system, the production system, the interface, the part, and the network. The experimental portion is composed of two initialization processes at the beginning of the simulation. These are initializations of the AGVProblem and AGVSystem. The initialization of the

initialize

Fig. 6.

I initialize

Top levelobjectdiagram(experiment).

AgvTalk: an object-oriented simulator for AGV systems

581

AGVProblem includes the definition of any stochastic arrival processes into the AGV System and resources. For example, when an AGV receives the message defmeArrivalSchedule from the AGVProblem, the instance of the AGV is initialized and the arrival process of that instance is defined, and sends itself the message definelnitialLocation, defineVelocity, and defineAcceleration. Also, the AGV sends the message defineArrivalSchedule to the objects Breakdown and Recharging to define their interarrival distribution. The objects which receive the messages defineArrivalSchedule (the AGV, the Breakdown, the Recharging) send the appropriate message to one of the distribution objects which represents their arrival processes. This is illustrated in Fig. 7. The implementation of the Part in an experiment is similar to that of the AGV, in that the Part receives defineArrivalSchedule from the AGVProblem and sends the messages to the distribution object to define its arrival process and the processing time distribution. In addition, the instance of the Part defines its routing sequence and the entry location by sending itself defineRoutingSequence and defineEntry Location. The initialization of the AGV System consists of the initialization of its lower level classes, that is, the material handling system, the production system, the interface, and the network system. The initialization of the material handling system represents the cleaning out the system statistics and redefining them. In particular, by sending the message selectRules to Dispatching, two rules in each category of the vehicle initiated rule and the work center initiated rule are selected. The initialization of the ProductionSystem and the Interface defines the capacities of the work stations and buffers, respectively, by sending the message defineCapacity. In the initialization process of the NetworkSystem, the messages defineControlPoints and constructNetworkandShortestRoute are sent to the objects Node and Net respectively. Then, the Net constructs the system network by connecting the instances of the Node defined as control points. The object flow (link) of the connection can be uni, or bi-directional. In a special case, spur-link can be defined with a dead end in the link. Once the system network is constructed, the shortest routes between any two combination of the control points are generated in the class Net. These generated routes are stored into the object Route by passing the message storeShortestRoute. This is shown in Fig. 8.

2.3. AgvTalk: AGV system simulation environment in Smalltalk The design concepts discussed in previous section have been implemented in Smalltalk-80 [14]. The object-oriented simulation environment with the library of classes developed for an AGV system in Smalltalk-80 is referred to as AgvTalk. AgvTalk includes 25 object classes and more than 300 object methods in its library for many detailed features of AGV systems.

[,.e^O rob,em]

l

defineArrivalSchedule theAGV

defineArrivalSc~ I theBreakdown ]

ArrivalSchedule

m¢lih:

]next from:to:

mean"to~.~ from:

next / t h e E x p ° n '

definelnitialLocation defineVelocity defineAcceleraOon

theUniform....

I theRecharging] ~r~ can; / ~ from:to: ficxt

Fig. 7. AGV object diagram (experiment).

582

RussellE. King and KyungSup Kim

•

.

J ~ - ~ ~

defineNetwork

uniLinkWithAdjacentNodes sloreShorlestRoutes biLinkWithAdjacentNodes spurLinkWithAdjacemNodes Fig. 8. NetworkSystemobject diagram (experiment). 3. MODELINGPROCESSIN AGVTALK To provide the insight on how a simulation model is developed in AgvTalk, the modeling process is presented in this section according to the AgvTalk structure shown in Fig. 9. 3. !. Model specification The main modeling advantage of AgvTalk is the simplicity in defining and changing system requirement and specification. By invoking the method initialize in class AgvProblem, the system is initialized through the MVC (Model-View-Controller) triad in Smalltalk-80 [15]. The system initialization includes layout model definition, entity flow model definition and control model definition. 3. i. !. Layout model specification. Layout model specification involves description of the system guide path configuration and resources, and is as follows: • identification of control points (workstations, intersections, staging area) • definition of distances and number of zones between any two adjacent control points • definition of uni- or bi-directional path between any two adjacent control points The required information for the above descriptions is provided by invoking the eon~tructNetworkAndFindShortestRoutes method in class AgvProblem. Once information for all combinations of two adjacent control points is given, shortest distance routes for any combination of two control points in the system layout are produced by Dijkstra's shortest route algorithm [16].

I

'k I I

\ [

User

II

J ISys,ooLo ,cJ

[

/ ",

\/ 1

/

[ C°ntr°l ° f M Io ~dSmallTalk eLibrary l ObjectsJ r[ AgvTalk Library )ObjectsJ °f

t o.,~., IFig. 9. The AgvTalkstructure.

AgvTalk: an object-orientedsimulatorfor AGV systems

583

3. i.2. Entityflow model specification. Entity flow model specification includes description of the physical objects such as number of vehicles, workstation characteristics, part routing, etc., and are as follows: --Vehicle information --number of vehicle --speed, acceleration/deceleration --loading/unloading time --loading capacity --breakdown/recharging rate distribution --Workstation information --location of pickup/deposit station --number of resources (e.g. machines) ---distribution of inter-breaking time ---distribution of repair time --Part information --number of part types --arrival point into the system of each part type --distribution of interarrival time of each part type --processing route of each part type --processing time distribution of each part type at each station --Buffer information ----capacity of input buffer and output buffer of each workstation. The above information is initialized by invoking the method initialize in AGVProblem, which in turn invokes the methods initialize of the physical object classes, i.e. AGV, Workstation, Part, Buffer, lnputButfer and OutlmtBuffer. For example, Fig. 10 represents the initialization process of the Part instance through the menu-driven interface. 3. i.3. Control model specification. Control model specification includes determination of the control policies for vehicles. Below are listed some candidate rules from the literature. Others can be easily included. --Vehicle initiate rules --shortest distance rule --maximum outgoing queue size rule --minimum remaining queue size rule --first-come first-serve rule --modified first-come first-serve rule --random workstation rule ----extracted rule (ER, ERR) [17] --Workstation initiated rules --nearest vehicle rule --longest idle vehicle rule --random vehicle rule. The above information is also initialized by invoking the method initialize of class AGVProblem, and in turn, class Dispatching. The initialization process in the class Dispatching by the menu-driven interface is shown in Fig. 11. 3.2. Model construction In order to model a complex manufacturing system in an object-oriented environment, the object classes developed in Section 2 should be assembled in some way. One way is for a user to state the system logic from the beginning to the end in the model file. The limitation of this approach is that the user might be familiar with the libraries being provided for the fast model-building and must be an expert for the specific system being analyzed. To overcome these limitations, a hybrid approach is proposed.

584

Russell

E King

and Kyung

Sup Kim

Part Information ]

I Select the entering location of part

I

Enter

Is this

Celll Cell2 Cell3 Cell4 Cell5 Cell6 Cell7 Cell8

[

Yes

?

No

]

Select the next station in route Enter Celll Cell2 Cell3 Cell4 Cell5 Cell6 Cell7 Cell8 Exit

Select distribution

last part type

End of route) (Continue)

of processing

Deterministic Uniform Normal Exponential Erlang Triangular

time at that station ] Enter the mean

10A

Fig. 10. Initialization

I

process of part instance.

3.2.1. Hybrid approach. In an AGV system, the system logic can be usually determined by behavior of two active physical objects which are independent of each other: how a vehicle moves in the system (vehicle move process) and how a part is processed in the workstation (part process). By combining these two processes, the complete AGV system logic is constructed. In AgvTalk, the generic behavior of each process is defined in the methods tasks in class AGV for the vehicle move process and process: in class WorkStation for the part process. That is, different AGV systems represent different system logic, which correspond to different combinations of methods tasks in class AGV and process: in class WorkStation. Considering class AGV, all methods defined represent the generic behavior of an AGV such as loading, unloading, traveling, waiting, etc. However, one of the generic scenarios for an AGV Dispatching Rule Information

[ I Select vehicle initiated rule

S~c.t

work center

initiated ~

-n¢ar¢$-'~tvthicl'-~ ~

T

[

~

~ i ~ e

~

t

~

~

J

Fig. 11. Initialization

shortest travel time extracted r~le (ER~ minimum remaining queue maximum queue first come first serve modified17rst come ~rst serve random work center

process of dispatching class.

AgvTalk: an object-oriented simulator for AGV systems

585

system among many possible alternatives is performed by the method tasks. In a method tasks, the major characteristics for an AGV system such as vehicle flow pattern, existence of the staging area, shop operating condition (job shop, flow shop, etc.) are determined by the sequences of other methods defined in the AgvTalk library, and the method tasks in class AGV is referred to as a "Base" for the given AGV system. Each different sequence represents a specific alternative for AGV behavior. All possible alternatives can be stored in the method tasks in the subclasses of class AGV. The method tasks in subclasses of class AGV are referred to as "Alternatives". Subclasses are different from class AGV only in AGV system behavior defined in the methods tasks, and all other characteristics are inherited from the class AGV (see Fig. 12). For example, subclasses could be used to represent the operating characteristics of various categories of AGVs such as load towing, unit load, pallet trucks, fork trucks, etc. A subclass of one of these classes could represent the specific characteristics of a particular model of AGV within that class based upon vendor-supplied information. While it is easy to envision a variety of such hierarchies, the point is that at each level only behaviour that is different from the parent class is characterized within the methods of the class. All other characteristics are inherited from the parent. In this way "Alternatives" can be retrieved and handled by the user allowing rapid model development when the considered real system is close to one of the available "Alternatives". When the real system is identical to one of the "Alternatives", the user has only to initialize the right AGV class which has the identical "Alternative" in its method tasks. This initialization process can be easily implemented by the menu and window, which explains the patterns of the "Base" and all "Alternatives". The implementation of the method tasks shows inheritance and polymorphism mechanism of AgvTalk, which are shown in Fig. 12. This approach is referred to

Class

I SimulationObject I

Methods

I

finishUp & more

1

Transporter

I I

tasks

& more I FixedPath

]

tasks

& more

Conveyor I t tasks I I

AGV load unload tasks waitForAWhile & more

AS/RS I I tasks

I I

Bases

A|t¢rnativcs

Fig. 12. |nheritance and polymorphism in hybrid approach.

586

Russell E. King and Kyung Sup Kim

as a hybrid approach since an AGV system model is constructed by providing system logic through procedure-oriented methods tasks within an object-oriented environment of AgvTalk and Smalltalk. 4. MODELING ADVANTAGES OF AGVTALK In this section, some modeling advantages of AgvTalk are compared to the general purpose simulation languages. SIMAN, one of the most widely used simulation languages for manufacturing systems, is chosen for comparison. Since material handling features are available in SIMAN, detailed one-to-one comparison of each feature between SIMAN and AgvTalk is conducted.

4. I. Modeling A G Vs In modeling any material handling system, the most difficult thing is to model the detailed behavior of the material handling equipment. An AGV system is one of the most complicated material handling systems, and the behavior of AGV's is even more complicated. Thus, how to define and model AGVs is very critical to the modeling of detailed and complicated processes in AGV systems. In SIMAN, material handling equipment such as AGV, AS/RS, conveyor, truck, etc., is not defined as entities in the model; instead, they are defined in the T R A N S P O R T E R S element. Transporters are referenced in the model by their name. Movement behavior of transporters is controlled by entities defined in the model. Since AGVs are not active entities (objects) in the SIMAN model, their behavior cannot be directly modeled; instead, their behavior should be defined and modeled within the context of control of entities and functions of block statements. In AgvTalk, each AGV is an instance of the class AGV. Since each AGV instance is an active object, the behavior of AGVs can be modeled easily by creating subclasses, instance variables, or adding methods.

4.2. Modeling processes In AgvTaik, processes for each active object match the real behavior of the object. These processes can be modeled distinctly and separately when necessary. For an instance of AGV, the processes include loading, unloading, traveling, checking the zone status, etc. Also, there are the same number of processes as the active number of objects. The active objects include instances of AGV, WorkStation, and Breakdown. The instance of Breakdown actually plays the role of a repair station. Instances of Part are used as passive objects. For example, if there are l0 AGVs and l0 work stations, and 2 AGVs are blocked and 3 work stations are idle, then, there are 15 (10 + l 0 - 3 - 2) active processes. On the contrary in SIMAN, entities control the processes of the model by passing through a sequence of block statements; however, the activity of the entities is confined in the context of the functions of the blocks defined in the model, and some processes are hidden and mixed with other processes between block statements.

4.3. Modeling dispatching rules Each time an entity releases a resource at the RELEASE block, it goes to the AGVQueue and requests an idle AGV at the REQUEST block according to the transporter selection rule. If an idle AGV is available, it is dispatched to pick up the part at the station where the entity requests. From the operational point of view, this transporter selection rule in SIMAN is regarded as the work center initiated rule [18] in AGV systems. Since the functioning of these rules are hidden inside SIMAN, it is not easy to extend the user defined work center initiated rules. Each time an AGV is freed at a FREE block and there is a delivery request in the AGVQueue, the AGV is immediately allocated at the REQUEST block to the first requesting entity in the queue AGVQueue. That is, the vehicle initiated rule [18] is invoked. The AGV is dispatched to the station where the first entity in AGVQueue resides. Thus, the first-come first-serve (FIFO) rule is the only choice as a vehicle initiated rule. Since the AGVs are not active entities, "vehicle initiated" is not the correct term, and it may not be possible for users to develop dispatching rules in the vehicle initiated rule category.

AgvTalk: an object-orientedsimulatorfor AGV systems

587

If there is a staging area, work center initiated rules are meaningless because all idle AGVs stay there. Thus, the only possible rule is the FIFO vehicle initiated rule. Even when there is not a staging area, if the AGV system is busy, work center initiated rules are not invoked, and different rules in this category have little effect on system performance. Selection of a vehicle initiated rule is much more sensitive and critical to system performance. Therefore, modeling the control rules of AGVs in SIMAN is very limited. In AgvTalk, AGVs are active entities (objects). The vehicle initiated rule and the workcenter initiated rule are selected at the initialization of the class Dispatching. These rules include many commonly-used dispatching rules. Rules in both categories are encapsulated as methods in class Dispatching. The user can extend more rules very easily by just providing the rule in the method.

4.4. Modeling AGV breakdown In SIMAN, the breakdown of the AGV is modeled by the sequence of the following blocks [2]. QUEUE-ALLOCATE-RELINQUISH-HALT-FREE. That is, the AGV is allocated to an entity; the path space occupied by the AGV is relinquished; the AGV is halted and freed so that it can become inactive. After the AGV is repaired, a similar but reversed sequence puts the AGV back on the path and changes its status to active. The sequence of blocks is as follows. ACTIVATE-QUEUE-ALLOCATE-CAPTURE-FREE. That is, the AGV is activated; the AGV is allocated by the requesting entity; and the path space is captured by the entity. The actual breakdown modeled by the above sequence of blocks occurs only when the AGV is idle at the staging area, or when the AGV just finishes the delivery task at the station. That is, the AGV whose status is traveling, blocked, unloading, or loading is never broken down. Therefore, in SIMAN, stochastic breakdowns cannot be accurately modeled. Even though the controlling entity for breakdown can be created by a stochastic arrival distribution, the entity must wait until the AGV is idled. In AgvTalk, in order to model stochastic breakdowns, the class Breakdown is defined in the simulation framework. Its arrival process is defined and scheduled in the event queue of the simulation framework when the instance of the class AGV is initialized as follows: Simulation active scheduleArrivalOf: Breakdown accordingTo: BreakdownDistribution startingAt: BreakdownDistribution next When the Breakdown instance is created, its activity is scheduled in the method tasks. Basically, the activity includes removal of the AGV from the path, repair of the AGV, and return of the repaired AGV to the path. However, according to the operation status of the AGV when it failed, the activities defined in the tasks are different. In AgvTalk, different operational status include the following. (1) (2) (3) (4) (5) (6) (7) (8)

traveling in the path (zone) unloading at the input buffer loading at the output buffer being blocked at the input buffer because it is full being blocked at the zone because the next zone is occupied being blocked at the bidirectional link node because another AGV is traveling toward it waiting at the staging area recharging at the recharging station.

588

Russell E. Kingand KyungSup Kim

The general stepwise process for the activities defined in the tasks is as follows: Step 1.

Step 2.

Step 3. Step 4. Step 5. Step 6. Step 7. Step 8.

Information for the current breakdown is generated. Each time an AGV breaks down, the following instance variables are generated and attached to the instance of Breakdown. label: the identification number for the failed AGV operation: the operation status of the AGV when it failed downtime: the time of a breakdown repair Time : the repair time for the failed AGV location: the location where the AGV breaks down. The next breakdown is scheduled. (Optional for the accumulation to the repair time) Each time an AGV breaks down, the next breakdown for the failed AGV is scheduled in the eventQueue instantaneously. The failed AGV is identified. The failed AGV is removed from the system. The next scheduled event for the fMled AGV is removed or the process for the failed AGV is terminated. The failed AGV is repaired. The fixed AGV waits until the space is available. The fixed AGV returns to the system.

In AgvTalk, breakdowns are immediately recognized regardless of the operational status of the failed AGV. To model the breakdown, the definition of the arrival process is only necessary in an experimental stage.

4.5. Modeling pick up and deposit stations In SIMAN, a station submodel can be used to model a workcell or a department. Each station is defined in the STATIONS experiment. When the system network is constructed in an experimental frame, one location is defined for each station as the communication point for AGVs moving around the system. If the locations of the pick up station and the deposit station are different for each station, the actual AGV path of the loaded and unloaded travel should be different for the given starting and destination stations. If it is loaded travel, travel starts from a pick up station and ends at a deposit station. If it is unloaded travel, the opposite is true. To deal with this problem, the additional logic should be provided. In AgvTalk, when the network is constructed at the initialization of the class Net, the pick up and the deposit stations (if different locations) and the pick up/deposit station are defined as instances of the class Node representing the control points. Each instance of AGV has an instance variable task, representing a "pickUp" or a "deposit" task. When an AGV instance arrives at the station, the starting and the destination locations are determined automatically according to the value of the instance variable task.

4.6. Modeling bidirectional links If an AGV arrives and gains control of an intersection at the end of a bidirectional link and a second AGV already occupies the link and is traveling to the ending intersection, a deadlock will occur. The first AGV will be unable to gain control of the travel direction, and the second vehicle will be unable to gain control of the ending intersection. However, there is no control logic to prevent such deadlocks. If a deadlock occurs, SIMAN terminates the simulation with an error message [2]. In AgvTalk, the ending intersections of the bidirectional link (instances of the class Node) have the instance variable semaphore which is the instance of the class Semaphore. As long as the link is occupied by the AGV traveling in some direction, the semoohore of the opposite side of the node has the value "on". The AGV trying to enter the bidirectional link must check the value of the semaphore of the node. If it is "on", the AGV waits without controlling the ending intersection. If it is "off", the AGV is allowed to enter, and the semaphore of the opposite side of the node

AgvTalk: an object-orientedsimulator for AGV systems

589

becomes "on". The AGV leaving the bidirectional link changes the value of the " o n " to " o f f " if no other vehicles are in the link.

semaphore from

5. VALIDATION OF AGVTALK As part of the validation of AgvTalk, sample AGV systems were simulated with AgvTaik and SIMAN and the output data compared. Assuming that a SIMAN model correctly models the AGV system, the percentage deviations of AgvTalk output were tested with SIMAN output. The measures of performance in these tests are throughput and flow time. AgvTalk and SIMAN are capable of modeling many detailed features of AGV systems, however, how these features are modeled may be different between AgvTalk and SIMAN. Therefore, a simple AGV system is modeled to provide as similar system logic as is possible between an AgvTalk model and a SIMAN model. The assumptions for the AGV system in this validation test are as follows. • • • • • • • • • • •

Vehicle breakdown is not considered Battery recharging of vehicles is not considered. Vehicles travel with instantaneous acceleration and deceleration. Vehicles do not pass each other. Vehicles travel based on the shortest path. Vehicles transport one unit load at a time. First-in-first-out (FIFO) is used for the vehicle initiated rule. Shortest travel distance rule is used for the workcenter initiated rule. Only one vehicle can occupy a zone at one time. Idle vehicles are sent to the staging area. The routing sequence of each part type is deterministic.

The layout configuration for the AGV system is presented in Fig. 13, where there are 8 work stations, one staging area, and one recharging station. At each work station, the locations of pick up and deposit stations can be different. Three different part types are processed in a job shop environment, and their arrival processes, routing sequences (station ID), and the corresponding processing times (min) are as follows: Part type 1 Arrival process: Routing sequence Processing sequence

Exponential (8) : ENTER3 : I

7 3

6 5

Part type 2 Arrival process: Routing sequence Processing times

Normal (9,2) : ENTER4 : 1

5

EXIT

4

5

0

Part type 3 Arrival process: Routing sequence Processing times

Triangular (i 0, 13, 15) : ENTER1 : l

2 5

8 5

EXIT 6 0

EXIT 3 0

There are 12 AGVs in the system. The loading and unloading times of the AGVs are 0.25 rain. The velocity of each AGV is 200 fmp. Because of the limitations of SIMAN in modeling dispatching rules, only the shortest-distance rule and the first-come-first-serve rule are used for the work center initiated rule and vehicle initiated rule, respectively. The AGV system was simulated with AgvTalk and SIMAN for 480 min with a warm up time of 50 rain for each of 12 replications. From the replications, the IID measures of performance were collected. Since 12 runs are not enough for a classical approach, a jackknife approach was used for an analysis of percentage deviation data of two outputs. In Table l, the simulation output results are summarized for different performance measures. CAIE " ~ / ~ L

590

Russell E. K i n g a n d K y u n g S u p K i m 411

|

.

.

:

.

.

.

:

.

',

,,

,,~ 4

r

i

i

i

•

r

i

i

i

P

i

i

6

/

i i

I

i

i

i

A i

D i" • I

CELL 4

~-

i i

i

i

i

!

P/D

P/D

CELL 8

•

I

CELL 5

i i

J

I

I

I

tO n

3

i

m

9

1

8

D

..n D

I

I

CELL 1

i

i

|

I

/

o PI

|

|

i

CELL 2

I

CELL 6

I

i ~

i

1

i

i

i

i

i

i

i

i

i

PI. i

I

J

i

II

D

P

m

I i

i

',,'L

13

i !

i i

I

I,

i i i

D

15

-I

i

I

uJ

I I - I CELL 7 I ?

I

I

~

-i

+,.

PI°

CELL 3

T 25

24

i

22

23 "

17

19 I

U

Staging

Recharging

area

area

I

I

I

I

~

1

I

P

:

D

: Deposit station

P/D : i

I

[

I I

I ]

I I

Pickup station Pickup and deposit station

. Control point

Fig. 13. L a y o u t c o n f i g u r a t i o n o f A G V s y s t e m .

For each performance measure, the summary for 2 and its 95% CI is provided in Table !, where 2 is the estimator for the percentage deviation data of AgvTalk from SIMAN. The results show that the estimators for the percentage deviations are < 2%, and the confidence intervals included zero for all performance measures tested, indicating AgvTalk generates almost identical simulation outputs as SIMAN. 6. M O D E L

DEVELOPMENT

AND

EXECUTION

TIMES

COMPARISONS

6.1. Model development time comparison The model construction process in AgvTalk is simple due to the hybrid approach. In the hybrid approach, many models for conventional AGV systems are already developed. Thus, the model for the given AGV system can be developed by selecting the appropriate class which has the appropriate system logic. Table I. Summary for percentage deviation between AgvTalk and S I M A N output data System Performance Measure Average flow Average flow Average flow Average flow Throughput

time time time time

of of of of

all parts part type I part type 2 part type 3

2 -0.00062 -0.00310 -0.00548 0.01766 -0.00224

95% Ci for 2 (-0.02132, (-0.02713, ( -0.02366, (-0.00214, (-0.03621,

0.02008) 0.02093) 0.01270) 0.03736) 0.03173)

AgvTalk: an object-oriented simulator for AGV systems

591

Some advantages in AgvTalk were discussed in modeling such features as breakdown, dispatching rules, different locations of pick up and deposit stations, bidirection link, etc. In AgvTalk, the additional modeling process for these features is very minimal, and all these additional modeling features are defined in the model specification process and are as simple as specifying the parameter values or selecting the appropriate menu by clicking the mouse. However, in SIMAN, as the AGV system becomes more complex, the modeling effort and time increase rapidly. Unlike AgvTalk, the modeling of AGV characteristics such as breakdowns and recharging requires creating entities in a model frame with a series of blocks which have sophisticated functions. Some high level constructs for controls such as different vehicle dispatching rules may not be implemented by the model developer because the functioning of these controls is hidden inside SIMAN. Station submodels are very useful for modeling workstations, however, they have limited capability in modeling workstations which have different locations of pick up and deposit stations. Moreover, because the functions of blocks defined in SIMAN material handling features do not always agree with the activities of objects in a real system, the more complex AGV system requires more modeling effort and time. 6.2. Simulation model execution time comparison

From the point of simulation model execution time, AgvTalk is not as fast as SIMAN due to the additional overhead. The amount of time needed to execute an AgvTalk model is roughly seven or eight times longer. This statement is made from the test results in validation activities where an AgvTalk model and a SIMAN model of the same AGV system were executed repeatedly (12 replications) on a DEC station 3100. However, the longer execution time of an AgvTalk model is not perceived as a major disadvantage because the model execution time (seconds, minutes) is much less than the model development time (hours, days) in which AgvTalk is much more favorable than SIMAN. Also, the continued increase in computer processing speed makes the long execution time less significant.

7. SUMMARY

In this paper, the existence of objects and their relationships in AGV systems has been conceptualized. This conceptual organization was represented in the logical design of AGV systems by the object diagram. This design includes the object-oriented design of a model, and an experiment for AGV systems. Also, this logical design has been applied to the implementation of object-oriented classes providing the ability to create a model for AGV systems. The resulting simulation modeling environment, AgvTalk, includes 25 object classes and more than 300 object methods in its library for many detailed feature of AGV systems. Since the complexities and specific natures of AGV systems do not allow easy construction of a simulation model with only stand-alone natures of objects, the hybrid approach in AgvTalk was proposed. In the hybrid approach, the possible life cycles of active objects were modeled in methods, and the methods were stored in the AgvTalk library. The hybrid approach eliminates the modeling process of behaviors of vehicles, work stations, parts, and repair stations in AGV systems; instead, it provides the selection process among behaviors already built-in in the library. This selection process and data input process for model construction can be performed through the window- or menu-based user interface in AgvTalk. In comparisons of features such as modeling AGVs, processes, dispatching rules, breakdown, and system layout, the main difference between AgvTalk and general purpose simulation languages turned out to be the fact that transporters (e.g. vehicles in an AGV system) are not modeled as active objects in general purpose simulation languages. The lack of modeling causes limiting modeling environments for the detailed and exact behaviors. These comparisons also showed that AgvTalk provides natural constructs for modeling AGV systems separately and distinctly among physical objects, objects' behavior, and control of objects resolving the inherent problems in general purpose simulation languages.

592

Russell E. King and Kyung Sup Kim REFERENCES

1. R. E. King and C. M. Wilson. A review of AGV systems design and scheduling. Prod. Plan. Control 2, No. I, 44-51 0991). 2. C. D. Fegden, R. E. Shannon and R. P. Sadowski. Introduction to Sim~ation Using SIMAN. McGraw-Hill, New York (1990). 3. A. A. B. Pritsker. Introduction to Simulation and S L A M !I. 3rd edition. Halsted Press, New York (1986). 4. B. M. Law and S. W. Haider. Selecting simulation software for manufacturing application: practical guidelines and software survey. Ind. Engng May, 33-46 (1989). 5. R. J. Gaskins and J. M. A. Tanchoco. AGVSim2: a development tool for AGVS controller design. Int. J. Prod. Res. 27, 915-926 (1989). 6. D. Gong and L. F. McGinnis. An AGVS simulation code generator for manufacturing applications. Proceedings of the 1990 Winter Simulation Conference, pp. 676-682 (1990). 7. A. Najmi and S. J. Stein. Comparison of conventional and objected oriented approaches for simulation of manufacturing systems. 198911E Integrated Conference & Society for Integrated Manufacturing Conference Proceedings, pp. 471-476 (1989). 8. S. D. Roberts and J. Helm. A perspective on object-oriented simulation. Proceedings of the 1988 Winter Simulation Conference, pp. 277-281 (1988). 9. C. B. Basnet, P. A. Farrington, D. B. Pratt, M. Kamath, S. C. Karacal and T. G. Beaumariage. Experiences in developing an object-oriented modeling environment for manufacturing systems. Proceedings of the 1990 Winter Simulation Conference. pp. 477-481 (1990). 10. H. M. Mize, H. C. Bhuskute, D. B. Pratt and M. Kamath. Modeling of integrated manufacturing systems using an object-oriented approach, l i e Trans. 24, No. 3, 14-26 (1992). II. R. Meyer. Object-oriented software construction. Prentice-Hall International, Hertfordshire (1988). 12. W. R. LaLonde and J. R. Pugh. Inside Smalltalk, Vol. I. Prentice-Hall, Englewood Cliffs, NJ (1990). 13. G. Booth. Object-Oriented Design with Applications. Benjamin/Cummings (1991). 14. A. Goldberg and D. Robson. Smalltalk-80: The Language. Addison-Wesley, Reading, MA (1989). 15. W. R. LaLonde and J. R. Pugh. Inside Smalltalk, Vol. 2. Prentice-Hall, Englewood Cliffs, NJ (1990). 16. E. W. Dijkstra. A note on two problems in connection with graphs. Numer Math. 1, 269-271 (1959). 17. T. J. Hodgson, R. E. King and C. M. Wilson. Analysis and control of multiple vehicle AGV systems. NCSU-IE Technical Report #90-10. Department of Industrial Engineering, North Carolina State University (1990). 18. P. J. Egbelu and J. A. Tanchoco. Characterization of automatic guided vehicle dispatching rules. Int. J. Prod. Res. 22, 359-374 (1984).