Simulation-based shop floor control

Simulation-Based Shop Floor Control

Young-Jun Son, Dept. of Systems and Industrial Engineering, University of Arizona, Tucson, Arizona, USA. E-mai/:sonQsie.arizona.edu Sanjay B. Joshi and Richard A. Wysk, Dept. of Industrial and Manufacturing Engineering, Pennsylvania State University, University Park, Pennsylvania, USA Jeffrey S. Smith, Dept. of Industrial and Systems Engineering, Auburn University, Alabama, USA

Abstract This paper presents an overview of simulation-based shop

floor control. Much of the work described is based on research conducted in the Computer Integrated Manufacturing (CIM) Lab at The Pennsylvania State University, the Texas A&M Computer Aided Manufacturing Lab (TAMCAM), Technion in Israel, and the University of Arizona CIM lab over the past decade. In this approach, a discrete event simulation is used not only as a traditional analysis and evaluation tool but also as a task generator that drives shop floor operations in real time. To enable this, a special feature of the ArenaTM simulation language was used whereby the simulation model interacts directly with a shop floor execution system by sending and receiving messages. This control simulation reads process plans and master production orders from external databases that are updated by a process planning system and coordinated via an external business system.The control simulation also interacts with other external programs such as a planner, a scheduler, and an error detection and recovery function. In this paper, the architecture, implementation, and the integration of all the components of the proposed simulation- based control system are described in detail. Finally, extensions to this approach, including automatic model generation, are described.

Keywords: Shop Floor Control, CIM, Real-Time Schedul- ing, Simulation

1. Introduction Simulation is a commonly used tool to gain in-

sight into the operational behavior of manufacturing systems. The traditional use of simulation has been limited to planning and design activities, and several commercial simulation languages have been developed specifically for this purpose: for example, ArenaTM, AutoModTM, ProModelTM, and so on. Simu- lation models developed for planning and design are often aggregate models using statistical distributions to model the stochastic nature of the environment. These models are used to perform what-if analysis to determine values of design variables, control strategies, and develop estimates of system performance.

These models are usually discarded after the initial plans are finalized.

Several authors have reported the expanded role of simulation to include “real-time” scheduling as part of intelligent simulation to dynamically select scheduling policies based on real-time shop floor status (Wu and Wysk 1989; Harmonosky and Robohn 1991; Rogers and Flanagan 1991; Smith et al. 1994; Drake and Smith 1996; Jones, Rabelo, Yuchwera 1995; Tunali 1995). These authors demonstrate that by using the most current system information and by using the simulation to make predictions about the future, performance can be improved by dynamically adjust- ing the scheduling policy and control strategy.

Given that simulation is well suited to capture the complex interactions of a system and embodies ele- ments of the actual mode of system operation, a natu- ral extension is the use of the simulation model to actually control the events in a real system. This is the basis of simulation-based shop floor control as first proposed by the Rapid CIM project (Wysk, Joshi, Pegden 1992; Smith et al. 1994). Using a simulation model with the proper level of detail and fidelity with real-time capability of interaction with external events, the same simulation model can be used to provide a common framework for design, planning, and real- time scheduling and control. This paper presents an overview of research in simulation-based shop floor control (SBSFC).

2. Overview of Simulation-Based Control

A shop floor control system (SFCS) is the central part of a computer-integrated manufacturing (CIM) system (Cho 1993). The responsibilities of a SFCS fall into three functional categories: planning, scheduling, and execution (Jones and Saleh 1990; Joshi, Wysk,

380

Jones 1990). In this paper, the function governing “what, ” “where,” and “how” is called execution, whereas a function governing “what,” “when,” and “where” (in the case of alternative resources) is called decision making (planning and scheduling). For example, given a “pick an object” task, the execution function needs to know what needs to be physically done, how the required activity can be executed (e.g. messaging and coordination) by one or more pieces of equipment (alternatives). Prior to executing the task, the decision-making function decides when to perform the task (resolving resource contention) and which piece of equipment to use (a given robot among alternative robots). For a given shop, the execution function is relatively static and depends only on the physical configuration of the shop, whereas the decision-making function is relatively dynamic and depends on both the physical configuration of the shop and the production requirements (Smith and Joshi 1993, 1995).

In the last decade, simulation models have been used to generate “work-to” schedules that are then used to control the flow of product on a shop floor. More recently, simulation has been used for system evaluation and then reused as a basis for a real-time system controller. This type of control is referred to as simulation-based shop floor control (SBSFC). This approach has been illustrated as part of the RapidCIM project (Wysk, Joshi, Pegden 1992; Smith et al. 1994) and has been implemented at the following university labs: (1) Penn State CIM lab, (2) Texas A&M Computer Aided Manufacturing (TAMCAM) lab, (3) Technion-Israel Institute of Technology, and (4) Uni- versity of Arizona CIM lab.

Figure 1 depicts the RapidCIM simulation-based control architecture. The ArenaTM RT (real-time) simulation package has been used to develop the simulation model that obtains master production schedules (e.g., part orders) and part process plans from a Microsoft’ Access 97 database. The database keeps track of part orders and how many parts in each order are finished. The simulation controls the manufacturing system by sending and receiving messages using a TCP/IP socket-based communication link to a high-level task executor, known as the BigE. The BigE performs the shop-level execution functions and keeps track of the status of each individual piece of equipment in the system. The BigE receives instructions (messages) from the simulation and, based on

Journal of Manufacturing Systems Vol. 2l/No. 5

2002

the system status, sends messages to the equipment- level controllers. After a task message is sent from the BigE, both the BigE and the simulation wait for a “completion_ok” message from the equipment-level controller that received the message. Once the BigE receives the “completion_ok” message, it sends a similar message to the simulation, and the simulation knows that the current task was completed. The task generator and execution modules communicate through the task initiation queue (TIQ) and the task completion queue (TCQ). The simulation uses the TIQ to instruct the BigE to perform specific tasks and receives completion messages through the TCQ. These queues facilitate the explicit separation of the decision maker from the execution module. The separation of the decision maker and the execution module makes the system truly “plug and play.” In fact, as long as the decision maker understands the physical constraints imposed on the task sequences, any decision maker can be plugged into the execution module according to the current production requirements. Example decision makers include simulation, a human operator, an expert system, and so on (Smith et al. 1994). Among these candidates, the following ad- vantages have made simulation popular as part of a decision maker: (1) easy bookkeeping, (2) easy speci- fication of physical system constraints, (3) built-in ability to interface with external modules such as databases and external decision procedures, (4) real-time monitoring and animation, and (5) off-line production prediction or cost estimation.

Two general architectures for the decision-making function from the simulation-based control environment are depicted in Figure 2. For the first architecture, the operating logic for the controller is directly coded into the simulation model. For the second architecture, an external scheduler provides input to the simulation (either a work-to schedule for each resource or a dispatching rule for each decision point). For different architectures or control strategies, the associated simulations need to be configured differ- ently (Drake, Smith, Peters 1995). In this research, the second architecture is adopted, where the role of the online simulation excludes significant decision- making activities (as much as possible) and concomi- tantly takes advantage of a commercial scheduling package, in this case RSBizWare SchedulerTM. A brief overview of ongoing work on two methods of schedule interface will be described in Section 5.

Big Executor (Shop Level)

Task - Initiation Queue A

Shop Level

Controller

Level Controllers

Physical Equipment

Figure 1 Simulation-Based Shop Floor Control Structure

3. System Components 3.1 Simulation Model

Several modifications have been made to enable standard Arena to play the role of a task generator for a supervisory controller (Smith et al. 1994). These features are explained in this section and are now part of Arena RT. First, the simulation environment has been modified to run in real time. More specifically, the simulation clock time is now synchronized with the internal clock of the host computer. As such, time progresses in a uniform manner instead of in discrete jumps of different lengths.

The event calendar of the simulation has been modified to handle both internally modeled delays and delays associated with tasks performed by external execution software. When a simulation entity encounters a delay associated with an external event, a message is sent to the external execution module and the simulation entity is placed on the event calendar.

When a return message is received from the execution software implementing the event, the simulation entity is removed from the event calendar. In this way, the state of the simulation is synchronized with the actual state of the shop floor. Another modification required is a mechanism for implementing the task initiation queue (TIQ) and the task completion queue (TCQ) (refer to Section 2). Implementation specifics to facilitate these message queues will be described in Section 6.

In addition to the modifications made to the simulation software, simulation modeling for shop-floor control requires a much higher level of system detail than when it is used as an analysis tool. Because the simulation drives physical tasks of equipment in the shop, the simulation model with low fidelity may cause catastrophic results (for example, errors, resource collisions, etc.) or system deadlocks in the shop floor. Figure 3 shows an example system to illustrate control simulation requirements. Eight tasks are

382

Journal of Manufacturing Systems Vol. 21/No. 5

2002

(a) Decision logic within simulation (b) Decision logic outside simulation

Figure 2 Two Architectures for Simulation-Based Shop Floor Control

Task I I Task Number Name

1 1 [ Pick L

4 Pick Ml

5 Put M2

6 Process 2

7 Pick M2

8 Put UL

Figure 3 Illustrative Example for Required Tasks to Facilitate Part Flow

383

Jourr~trl qf‘Manufacturing Systems Vol. 2 I/No. 5 200?

needed to move the part from the load station to Ml, process it, move it to M2, process it, and move it to the unload station. For these tasks, Table I presents associated resource acquisition. For example, prior to performing a “Pick L” task, both Ml and R need to be acquired (seized), assuming the product’s next operation is supposed to be performed at M 1. This is a strategy to avoid deadlocks. Figure 4 shows a case where deadlocks will occur unless the resource acquisition strategy in Table I is satisfied. In Figure 4, the robot has two control options: (1) not picking up P2 until the current operation of Pl is finished, and (2) picking up P2 and waiting until the current operation of Pl is finished. The latter option causes a system deadlock. The first control option can be achieved by seizing R and M2 for the picking operation in the simulation.

3.2 Resource Model

This section explores a production resource model that provides a common frame of reference among the simulation, the execution system (BigE), the process planner, and so on. In fact, this resource model is used as a major input to automatically generate a simulation model and an execution model (as described in Section 4). A resource model contains a set of definitions and symbolic descriptions that are required to describe all of the individual resources in a facility as well as the necessary interactions between these resources. The model includes both the physical and logical information in the facility directed toward the manufacture of the products. Resources (R) include equipment (E), tools (T), fixtures (F),

____________________~~~~~~~~.

??: Operation finished

@ : Operation currently being done

Figure 4 Illustrative Example for Deadlock Avoidance Strategy

instruction sets (Z), connectivity graph (CG), locations (L), ports (P), and facilitators (FA), which are formally defined as follows:

R=cE,T,F,I,CG,L,I:FA>

A partition of a set A is a collection of disjoint sub- sets of A whose union is all of A. A = <A,, A,, A,> represents that A is partitioned to A,, A,, and A,.

Methodologies developed in this paper interact with only the equipment (25) and the connectivity graph (CG). Therefore, discussions in this section focus only on E and CG, and the other sets will not be further mentioned after this section. Steele, Son, and Wysk (2001) present various usages of the production resource model.

A manufacturing system is made up of several pieces of equipment (devices). Several generic types of equipment have been identified. Smith and Joshi

Task Number

1

2

3

4

5

6

I

Table 1 Resource Acquisition for Control Simulation

Equipment To Be Seized for Each Task

Task Name Ml (machine) M2 (machine) R (robot)

Pick L 4 4

Put Ml 4 4

Process 1 4

Pick Ml 4 4

Put M2 4 li

Process 2 4

Pick M2 4

8 I Put UL I I I 4

384

(1993) define the types of equipment (E) as: material processing (MP), material handling (MH), material transporting (MT), and buJScer storage (BS). Each piece of equipment in the factory belongs to one of these types. Formally, the equipment (E) is defined as follows:

E = d@ MH, MT, BS>, where: MP = 4l’MI: PD>, BS = CABS, PBS>,

ABS = <SABS, LABS>, and PBS = <SPBS, LPBS>.

Equipment belonging to the MP set transforms a product in some way. MP is partitioned into NMP (normal material processors set) and PD (passive devices set). If the material processing equipment requires an equipment-level controller, it belongs to the NMP set. Otherwise, it belongs to the PD set. Equipment belonging to the NMP set includes ma- chining centers, inspection devices, assembly machines, and so on. Equipment belonging to the PD set includes gravity-based inverters, heat lamps used for drying parts after a painting operation, etc. In this paper, the MP set refers to the NMP set unless otherwise specified.

Equipment belonging to the MH set includes those pieces of equipment that transfer products between pieces of equipment; they are robots, human operators, and so forth. Equipment belonging to the MT set includes those that move products from one location (as defined below) to another location; they are AGVs, conveyors, fork trucks, human operators, etc.

Equipment belonging to the BS set includes those pieces of equipment that store products. General equipment storing products is classified either as ABS or PBS. If the storage equipment requires an equipment-level controller, it belongs to the ABS set; otherwise, it belongs to the PBS set. Some requirements of ABS equipment-level controller include synchronization with MH equipment, location allocation, capacity control, etc. ABS is partitioned into SABS and LABS. SABS equipment includes those associated with the system-level activities, meaning that products initiate and terminate their appearance to the production system. LABS equipment is associated with local activities. Equipment belonging to the PBS set stores products and does not need an equipment-level controller. Because no controller exists for this type of equipment, the supervisory-level control-

Journal of Manufacturing Systems Vol. 211No. 5

2002

ler (the simulation model in this case) must make all of the decisions associated with the equipment. PBS is partitioned into SPBS and LPBS with the same way as in the case of ABS.

A connectivity graph (CG) is a graph showing the connections between the equipment in the facilities. Each node is associated with a piece of equipment. Arcs are associated with equipment interactions (e.g., high-level tasks). The connectivity graph is formally defined as:

CG = (N, A), where: N = {n1,n2, . . . . ni} is the set of nodes correspond-

ing to the equipment (E) A= {aijIi,jEN}

3.3 Finite State Automata Based Execution Model

This section explores a message-based part state graph (MPSG) that formed the basis of the BigE and the equipment-level controllers in Figure 1. The MPSG presented by Smith and Joshi (1993) is a formal model of the execution portion of shop floor control that operates in a distributed control environment. It represents the execution module of a shop floor controller as a finite-state machine. Individual controllers in a distributed environment communicate using a well-defined protocol (messages) to affect system operation. An MPSG (which mimics the behavior of the controllers from the part perspective) specifies all possible states that parts can occupy throughout the system. In comparison with a PLC- based control system, the computational complexity of an MPSG is extremely low. An MPSG is a modified deterministic finite automaton (DFA) similar to a Mealy machine (Hopcroft and Ullman 1979). Fur- ther details on the MPSG can be found in Smith (1992) and Smith and Joshi (1993).

Consistent with the type of equipment in the production resource model in Section 3.2, Smith (1992) developed generic MPSGs for each type of equipment and a supervisory controller (BigE). Figure 5 shows an example MPSG for MH equipment (for example, a robot). There are two types of interactions between the MH equipment and other types (for example, MP, BS, or MT) of equipment: synchronous and nonsynchronous. When MH equipment puts (loads) a part to MP equipment, resource synchronization is required (for example, the MP equipment must open the chuck before the MH equipment puts

385

pick_ok_rb

put_ok_rb

0

put_ns_br

I

??0: output messages from MH controller

??T: task messages performed by MH controller

MPSG for Fieure 5 ,I MHI Xquipment

the part and the MP equipment must close the chuck before the MH equipment moves away to a safe position). On the other hand, when an MH equipment picks (or puts) a part from the passive buffer storage equipment (PBS), no resource synchronization is necessary. As shown in Figure 5, the process in an MH equipment controller is initiated by a pick request from the BigE to the equipment controller. To accommodate the synchronous and nonsynchronous pick (and put) tasks, two sequences of controller events (messages) have been defined for the pick task (and for the put task). When a product is picked up (either in a synchronous manner or a nonsynchronous manner) by an MH equipment, the product must even- tually be placed somewhere (for example, MP, BS, or MT) by the same MH equipment. The sequence of controller events associated with a put task starts from state (node) 7 in Figure 5. Example interactions among the simulation, the BigE, and equipment-level controllers will be described in the following section.

3.4 Detailed Interaction Among Components

This section presents example interactions among the simulation, the BigE, equipment-level controllers, and physical equipment, detailing the contents in Fig- ure 1. As mentioned before, the simulation acts as a task generator for the BigE. When the simulation encounters blocks associated with an external event, it sends a message (task command) to the BigE. The BigE, interacting with equipment-level controllers, manages the implementation of the task. At the simulation level, the tasks are modeled in an aggregate fashion. While the simulation logic tracks what resources are involved in the implementation of the task, it contains no details regarding how the tasks are actually implemented. Figure 6 provides a comparison of the level of detail required in the simulation and the detail required in the BigE (along with equipment- level controllers). While the simulation models the task by a simple delay block, the BigE interacts with two equipment controllers and requires more than 10

386

Journal ofManufacturing Systems Vol. 2UNo. 5

2002

Messages

??xxx_sb: simulation to BigE

?? xxx_bs: BigE to simulation

??xxx_br: BigE to robot

??xxx_bm: BigE to machine

??xxx_mb: machine to bigE

?? xxx_rb: robot to BigE

--__ --__ ---__ --__

+-.____ y I MP ctrl I --p

I’ ,’ +

,’ ,’

Message Functions

?? I: input messages to the controller

??0: output messages from the controller

??T: task messages performed by the controller

Figure 6 Interaction Among the Simulation, the BigE, Equipment Controllers, and Physical Equipment

387

messages/actions to manage the completion of the tasks. Note that the MPSG of the robot in Figure 6 contains only part of the MPSG in Figure 5 due to limited space. In Figure 6, the dotted lines specify the interactions between components (for example, simulation, the BigE, equipment controllers, and machine and robot).

In Figure 6, interactions between the simulation, the BigE, the equipment controllers, and the physical equipment are initiated when the simulation commands the BigE to coordinate a pick task @ck_ns_,sb). In response to this pick message, the BigE commands the associated MH equipment controller to perform a pick task (pick_ns_br). Then, the BigE waits for the completion message from the MH equipment (cZear_ok_rb). When the BigE receives the completion message (clear&_&) from the MH equipment controller, it notifies the simulation of the completion of the pick task (pick_ok_bs). Once the simulation has been notified, it commands the BigE to coordinate a move task (mv_to_mp_sb). The next flow of interactions can be explained similarly. The I, 0, and T in Figure 6 denote the incoming messages, outgoing messages, and the tasks carried out, respectively. In addition, messages ending with “sb” denote messages from the simulation to the BigE. Similarly, messages ending with “br” denote messages from the BigE to the MH equipment controller; messages ending with “bm” denote messages from the BigE to the MP equipment controller. It is noted that outgoing messages (for example, pick_ns_sb) from a control entity (e.g., the simulation) are incoming messages to another control entity (e.g., the BigE).

3.5 Process Plan

The process plan provides the instructions for pro- ducing a part. It plays an important role in shop floor control as it forms a major portion of the specifica- tions required for control. As shown in Figure 1, the Arena RT simulation model obtains part process plans from an external database. By decoupling product routing from the actual control software, it is possible to change product mix and product flow data without making changes to the control software. Fur- thermore, process plans in this research will contain alternative routings. Process plans (and alternative process plans) are represented using AND/OR graphs (Mettala and Joshi 1993). AND/OR graphs are em- ployed in this research because they provide addi-

tional required flexibility over the traditional process plans represented either by operation charts or by process routing sheets. More specifically, AND/OR graphs provide a straightforward mechanism for representing alternative processing sequences. The controller must be able to serialize, or linearize, the AND/ OR graphs. Further details on process plan represen- tations and the use of process plans for control can be found in Wysk, Peters, and Smith (1994) and Lee, Wysk, and Smith (1994).

In this research, the process plan has the following information for every part type: ID number, operation code, description, resource ID, robot location, NC file name, and port number. Port numbers are associated with physical locations in the shop; therefore, unique tasks and operating parameters using the port number, resource ID, and operation code can be created.

4. Rapid System Development The previous sections presented the operation stage

of a simulation-based control system (SBC). This section describes the development cycle of this type of control system. To reduce the high cost of control software development and maintenance, research has been conducted on rapid realization of an SBC for a discrete part manufacturing system (Smith and Joshi 1993, Son and Wysk 2001). Figure 7 illustrates an approach to develop an SBC involving the automatic generation of an execution model and a simulation model from a resource model. As mentioned in Sec- tion 3.2, the resource model contains information describing all of the individual resources in a facility as well as the necessary interactions between these resources. A methodology (using a series of rules) to automate execution model generation from a resource model has been developed (Smith and Joshi 1993; Son, Wysk, Jones 2003). Given an MPSG execution model, Smith and Joshi (1993) developed software tools for automatically generating an essential portion (a set of C++ files) of the controller (for example, BigE or equipment-level controller).

A methodology to automate simulation model generation from a resource model and an execution model has also been developed (Son and Wysk 2001; Son, Wysk, Jones 2003). The shop floor resource model provides much of the static information for the simulation model, while a shop-level execution model

388


2002

I I) Physical facility

1 “‘“U”; model ~

BigE MPSG

Automatic generation of C++ files (Smith and Joshi 1992)

Automatic generation (Dynamic Portion)

1 t+ Messages’ q “;” Simulation (task generator)

+ +

Process plan I j Order info.

Legend: + Associated with b Associated with system development system operation

Figure 7 Overview of Development of Simulation-Based Control System

(BigE MPSG in this case) provides much of the dynamic information required by the simulation model. Detailed methodologies of the automatic generation are not presented here due to limited space. How- ever, further details on the model generation can be found in Smith and Joshi (1993), Son and Wysk (2001), and Son, Wysk, and Jones (2003).

The generated simulation is capable of running in three modes. Those three modes are as follows:

?? 1 st mode: users need to provide random part ar- rival information using a distribution function. Part routing information is read from an external database.

?? 2nd mode: part routing and order information is read from an external database. The simulation

.

reads the external database on a regular interval and releases existing orders. Scheduling is performed by default queue disciplines within the simulation model. 3rd mode: same with the 2nd mode except that schedule information is read from an external database, where schedules have been generated by RSBizWare SchedulerTM (refer to Section 5).

For all three modes, the simulation can be run with (real-time mode) or without (fast mode) interacting with the shop-level execution system.

5. Scheduling Methods Wu and Wysk (1989) created a multipass schedul-

ing framework using a mechanism controller and a

389

Journul of Manufacturing Systems Vol. 21/No. 5 2002

I I

I

Figure 8 Architecture for Simulation-Based, Real-Time Scheduling

flexible simulator. Multipass scheduling algorithms are defined as the scheduling algorithms that deal with the scheduling problem of selecting the best dispatching rule, among rules in an alternative space. This multipass structure has been applied to the proposed simulation-based control environment and has been implemented both at the Texas A&M TAMCAM lab [Drake, Smith, Peters 1995) and at the Penn State CIM lab (Son, Rodriguez-Rivera, Wysk 1999).

A multipass simulation is composed of two simulations-a real-time simulation and a preview simulation, which runs in the fast mode. The architecture of the multipass simulation can be seen in Figure 8. Because the real-time simulation has already been described in the previous sections, this section will focus on intersimulation interactions and significant parameters for the multipass simulation. Figure 8 describes in detail the “scheduler” block in Figure I. It should be noticed that two identical simulation

models exist on two different computers. One is used primarily as a real-time task generator to the shop floor, while the other is used for previewing the system. At each decision point in real-time simulation, a subroutine (implemented using an “event” block within Arena) in real-time simulation activates a fast mode simulation by sending a message to see what control policy impacts the current system favorably. Once the look-ahead manager receives a request, it opens fast-mode Arena and runs the number of alternative models sequentially. Several simulations are run, and the performances of each alternative are re- corded in the specific file. When this procedure is done in the fast-mode simulation, this control policy is then fed to the real-time simulation for execution of the best control strategy on the system. Further details on this approach can be found in Drake, Smith, and Peters (1995) and Son, Rodriguez-Rivera, and Wysk (1999).

390

Journal qf Manufacturing Systems Vol. 2UNo. 5

2002

Significant modeling parameters that need to be considered in a multipass simulation include:

?? Does real-time simulation need to be inactive while looking ahead?

?? Rescheduling point (frequency of looking ahead) ?? Simulation window (fast simulation length) ?? Performance measures ?? Candidate alternatives

The above parameters can be significant and even critical to the overall performance of the proposed multipass simulation mechanism. However, the only way to determine reasonably appropriate values of each parameter is empirically, that is, through trial and error. Some of these concerns have also been dis- cussed in Wu and Wysk (1989), Rogers and Gordon (1993), and Dewan (1996).

Work on a simulation-based control system, where a work-to schedule for each resource is provided to the simulation, is interesting yet premature. Because of the different levels of detail between the scheduler and the controller, it is not trivial to implement the schedules in the controller as specified by the scheduler. The level of detail between the scheduler and the controller is different due to the following facts:

?? Buffers are not considered in scheduling. ?? Material handling is not considered in sched-

uling.

Schedules generated without considering these two facts must not be provided to the control simulation. They may cause catastrophic results (e.g., collision) or system deadlocks in the shop floor. Research is being conducted on this problem, hoping a commercial finite-capacity scheduler called RSBizWare SchedulerTM will generate schedules and these schedules will be provided to the control simulation.

Two directions of schedule interface with a shop floor control system have been described in this section. It will be challenging to investigate which method will works better and under what circumstances.

6. Implementation Details This section describes implementation details of

(a) modifications made to enable standard Arena to play the role of a task generator for a supervisory controller and (b) interface with the external database containing process plans and master production schedules.

391

6.1 Modifications Made in ArenaTM

The event calendar of the simulation has been modified to handle both internally modeled delays and delays associated with tasks performed by external execution software (Smith et al. 1994). Techni- cally, when an entity delay is associated with an external event, the block executes two threads in par- allel. The first thread emulates the delay time using the specified value (for example, standard operation time) while the second thread executes the real-time task by sending a message to the real system to start an activity. The thread then waits for the system to respond with a task completion message. If the execution thread finishes before the emulation thread, the emulation thread is terminated and the entity de- parts the block. If the emulation thread finishes first, the entity remains suspended in the block until either (a) the execution thread completes or (b) the actual task time exceeds a value, in which case the task is terminated with a timeout error and the entity is sent to the block specified for the case of an error.

Another modification required is a mechanism for implementing the task initiation queue (TIQ) and the task completion queue (TCQ). To facilitate the TIQ and the TCQ, Arena RT provides the following functions (Smith et al. 1994):

SrIPC_Initialize() - This function initializes the interprocess communications required for the queues. SrIPC_Shutdown() - This function closes the interprocess communications when the simulation terminates. SrIPC_WriteMessage(msg) - This function is used to write the specified text message to the task initiation queue. SrIPC_ReadMessage(msg) - This function is used to read the first message waiting in the task- completion queue.

These functions have been developed under the Win- dows@ 95,98, 2000, and NT environments.

6.2 Interface with External Database Process plans and production orders are stored in

a database constructed using Microsoft@ Access 97 (refer to Figure I). In the Arena simulation, an “event” block is used to interface with the external database. Whenever an entity in the simulation model reaches one of these blocks, the function

“cevent” in the interface code is executed. Four types of events have been created, and their functions are described below:

?? Event 1: this event is triggered by the entity that is periodically created once per minute by the first submodel of the simulation. It uses an SQL command to read the orders from the master production database.

?? Event 2: this event is executed when an entity representing a new order initially enters the system. As described in Section 3.5, process plans are represented as AND/OR graphs and can contain alternative sequences of steps for manufacturing a product. Whenever the simulation needs to access a process plan for a new product, the associated table is read from the database and a graph is internally built to keep this AND/OR graph in memory, containing all the branches (options) in the process plan. Whenever a step in the sequence that makes up the process plan is completed, this process plan is accessed to determine the next operation to be performed. Given a current step in the process plan, several options may exist. In the current implementation, the first option is chosen. However, a planner/scheduler module could be added to decide which alternative should be executed next. Fi- nally, this event updates the process plan pointer to point to the next operation.

?? Event 3: this event determines the next step in the process plan. It is triggered when an operation is completed.

?? Event 4: this event will delete an order from the database. When all the steps in a process plan have been completed, this event is used to delete that order from the database.

In Arena 3 .O 1, an event block can be implemented in either Visual C++ or Visual Basic Application (VBA) embedded in Arena software. In our model, events are implemented in Visual C++ 6.0.

7. Penn State CIM Lab and Products This section describes example products and fa-

cilities at the Penn State CIM Lab, where the proposed simulation-based shop floor control system has been implemented. The purpose of this section is to help readers with visualizing an example environment

of the proposed research. The layout of the Penn State CIM Lab is shown in Figure 9, and specific equipment and its capability are shown in Table 2. The system consists of two workstations, each of which is composed of several CNC machines and industrial robots. There are several kinds of CNC machines, including a vertical milling center, a horizontal milling center, and a turning center, all of which have the capability to manufacture a variety of prismatic and rotational parts with reliability and accuracy. Indus- trial robots are used within a workstation for loading and unloading parts, tools, fixtures, and so on. A human operator also supports some material handling and transporting operations. Raw material, work in process, and finished goods storage is provided by an ASKS. Three example parts-a Penn State chess set with a king, a bishop, and a pawn-are shown in Fig- ure 10. These parts have been manufactured with the facilities described above.

8. Conclusions This paper has presented a simulation-based shop

floor control system, summarizing and integrating re- lated work at the Penn State CIM Lab, the Texas A&M Computer Aided Manufacturing Lab, Technion in Is- rael, and the University of Arizona CIM Lab over the last decade. The overall architecture and components of a simulation-based control have been described. We have also described several modifications made to enable the standard Arena simulation package to play the role of a task generator in an SBSFC. After these modifications, Arena can interact directly with a shop floor execution system by exchanging messages. The control simulation reads process plans and master production orders from external databases. The control simulation also interacts with external programs such as a planner, a scheduler, and an error detecting and recovering function. The interactions among these components have been described in detail. Finally, rapid development of a simulation-based control system has been described. Experience with these labs appears quite promising, and several extensions are being made, including integration with a scheduling system.

References Cho, H. (1993). “Intelligent workstation controller for computer integrated

manufacturing.” PhD dissertation. College Station, TX: Texas A&M Univ.

392


2002

Figure 9 Layout of Penn State CIM Lab

ID

E,

E,

E,

Ed

E,

EC

E,

E,

Table 2 List of PSU CIM Lab Equipment

Equipment Description

Haas SL-20 W/BF Turning center with bar feed and live tooling

Haas SL-20 Turning center

Haas HS-IRP Horizontal milling center

Haas VF-OE Vertical milling center

ABB IRB-2400L Six-axis robot

ABB IRB-140 Six-axis robot

IBM 7545 Robot for loading/unloading the AS/RS

Kardex Vertical carousel AS/RS

Dewan, Pooja (1996). “On-line concurrent simulations for real-time scheduling of CIM systems.” Master’s thesis. University Park. PA: Dept. of Industrial and Mfg. Engg., Penn State Univ.

Drake, Glenn R. and Smith, Jeffrey (1996). “Simulation systems for real time planning scheduling and control.” Proc. of 1996 Winter Simula- tion Conf.

Jones, A.; Rabelo, L.; and Yuchwera, Y. (1995). “A hybrid approach for real-time sequencing and scheduling.” Int’l Journal of Computer Inte- grated Mfg., ~~145-154.

Jones, A.T. and Saleh, A. (1990). “A multi-level/multi-layer architecture for intelligent shop floor control.” Znt ‘1 Journal of Computer h&grated Mfg. (~3, nl), ~~60-70.

Drake, G.R.; Smith, J.S.; and Peters, B.A. (1995). “Simulation as a plan- Joshi, S.B.; Wysk, R.A.; and Jones, A. (1990). “A scaleable architecture ning and scheduling tool for flexible manufacturing systems.” Proc. of for CIM shop floor control.” Pmt. of Cimcon ‘90, A. Jones, ed. Gaitb- 1995 Winter Simulation Conf., ~~805-812. ersburg, MD: Nat’1 Institute of Standards and Technology, ~~21-33.

Harmonosky, C.M. and Robohn, S.F. (1991). “Real-time scheduling in Lee, S.; Wysk, R.A.; and Smith, J.S. (1994). “Process planning interface computer integrated manufacturing: A review of recent literature.” Int’l for a shop floor control architecture for computer integrated manufac- Journal of Computer Integrated Mfg., ~~331-340. turing.” Int’l Journal of Production Research (~33, n9), ~~2415-2435.

Hopcroft, J.E. and Ullman, J.D. (1979). Zntmduction to Automata Theory, Mettala, E.G. and Joshi, S.B. (1993). “A compact representation of alter- Languages, and Computation. Reading, MA: Addison-Wesley Pub- native process plans/routing for FMS control activities.” ht’l Journal lishing. of Design and Mfg. (v3), ~~91-104.

393

Journal of Manufacturing Systems Vol. 2 l/No. 5 100:!

Part King Part Bishop

Figure 10

Part Pawn

Example Parts (Penn State chess set)

Rogers, P and Flanagan, M. (1991). “On-line simulation for real-time scheduling of manufacturing systems.” Industrial Engg. (v23), ~~37-40.

Rogers, P. and Gordon, R.J. (1993). “Simulation for real-time decision making in manufacturing systems.” Proc. of 1993 Winter Simulation Conf., ~~866-874.

Smith, J. (1992). “A formal design and development methodology for shop floor control in computer integrated manufacturing.” PhD dissertation. University Park, PA: Penn State Univ.

Smith, J. and Joshi, S. (1993). “A formal mode1 for shop floor control in automated manufacturing.” Proc. of 2”d Industrial Engg. Research Conf., Los Angeles.

Smith, J. and Joshi, S. (1995). “A shop floor controller class for computer- integrated manufacturing.” int’l Journal of Computer Integrated Mfg. (~8, n5), ~~327-339.

Smith, J.S.; Wysk, R.A.; Sturrok, D.T.; Ramaswamy, S.E.; Smith, G.D.; and Joshi, S.B. (1994). “Discrete event simulation for shop floor control.” Proc. of 1994 Winter Simulation Conf., ~~962-969.

Sony.; Rodriguez-Rivera, H.; and Wysk, R.A. (1999). “A multi-pass simulation-based, real-time scheduling and shop floor control system.” Trans. of the Society for Computer Simulation Int’l(vl6, n4), ~~159-172.

Son, Y. and Wysk, R.A. (2001). “Automatic simulation model generation for simulation-based, real-time shop floor control.” Computers in In- dustry (~45, n3), ~~291-308.

Son,Y.; Wysk, R.A.; and Jones, A.T. (2003). “Simulation based shop floor control: Formal model, model generation, and control interface.” IIE Trans. on Design and Mfg. (~35, nl), ~~29-48.

Steele, J.; Son, Y.; and Wysk, R.A. (2001). “Resource modeling for the integration of the manufacturing enterprise.” Journal of Manufactur- ing Systems (~19, n6), ~~407-427.

Tunali, S. (1995). “Simulation for evaluating machine and AGV scheduling rules in an FMS environment.” Engg. Mgmt. Conf., pp433-438.

Wu, S.D. and Wysk, R.A. (1989). “An application of discrete-event simulation to on-line control and scheduling in flexible manufacturing.” Int’l Journal of Production Research (~27, n9), ~~1603-1623.

Wysk, R.: Joshi, S.B.; and Pegden, C.D. (1992). “Rapid prototyping of shop floor control systems for computer integrated manufacturing.” ARPA project #8881.

Wysk, R.A.; Peters, B.A.; and Smith, J.S. (1994). “‘A forma1 process planning schema for shop floor control.” Engg. Design and Automation Journal (VI, nl), ~~3-19.

Authors’ Biographies Dr. Young-Jun Son is an assistant professor in the Dept. of Systems and

Industrial Engineering at the University of Arizona. He received his BS degree in industrial engineering with honors from POSTECH in Korea in 1996 and his MS and PhD degrees in industrial and manufacturing engineering from Penn State University in 1998 and 2000, respectively. His research work involves distributed and hybrid simulation for analysis and control of automated manufacturing systems and integrated supply chains. Dr. Son was the Rotary International Multi-Year Ambassadorial Scholar in 1996, the Council of Logistics Management Scholar in 1997, and the recipient of the Graham Endowed Fellowship for Engineering at Penn State University in 1999. He was the faculty advisor for the University of Arizo- na team that was awarded first place in the eighth llE/Rockwell Software Student Simulation Contest. He is an associate editor of the International Journal of Modeling and Simulation and a professional member of ASME, IEEE, IIE, INFORMS, and SME.

Dr. Sanjay Joshi is currently a professor of industrial and manufacturing engineering at Penn State University. He received his PhD in industrial engineering from Purdue University in 1987, MS from SUNY at Buffalo, and BS from the University of Bombay, India. His research and teaching interests are in the areas of computer-aided design and manufacturing (CAD/CAM) with specific focus on computer-aided process planning, control of automated flexible manufacturing systems, and rapid prototyping and tooling. He is a recipient of several awards, including Presidential Young Investigator Award from NSF in 199 1, Outstanding Young Manufacturing Engineer Award from SME in 1991, and Outstand- ing Young Industrial Engineer Award from BE in 1993. He has served as the department editor for process planning for the IIE Transacrions on Design and Manufacturing and currently serves on the editorial board of the Journal of Manufacturing Systems, Journal of Intelligent Manufactur- ing, Journal of Engineering Design and Automation. and Internationul Journal of Computer Integrated Manufacturing.

Dr. Richard A. Wysk is well known for his work in computer-integrated manufacturing, computer-automated manufacturing, computer-aided process planning, and concurrent engineering. He holds the Leonhard Chair in Engineering at Penn State University. Prior to his current position, he was director of the Institute for Manufacturing Systems and held the Royce Wisenbaker Chair in Innovation at Texas A&M University. Dr. Wysk also served on the faculty of Virginia Tech and worked in industry as a research analyst for the Caterpillar Tractor Co. and as production control manager for General Electric. He is a decorated Vietnam veteran. Dr. Wysk is the author of several textbooks. Honors recognizing his research include the Institute of Industrial Engineers’ David F. Baker Distinguished Research Award and the Society of Manufacturing Engineers’ Outstanding Young Manufacturing Engineer Award. Dr. Wysk holds bachelor’s and master’s degrees in industrial engineering and operations research from the Univer- sity of Massachusetts and a PhD in industrial engineering from Purdue University.

Dr. Jeffrey S. Smith joined Auburn University as an associate professor in the industrial and systems engineering department in September 1999. Prior to joining Auburn, Dr. Smith was an associate professor in the industrial engineering department at Texas A&M University since 1992. He received his BS degree in industrial engineering from Auburn University in 1986 and the MS and PhD degrees in industrial engineering from Penn State University in 1990 and 1992, respectively. Dr. Smith’s teaching and research work involves analysis, design, and control of manufacturing systems, computer simulation, and simulation software development. In addition to his academic positions, Dr. Smith has held industrial positions at Electronic Data Systems and Philip Morris U.S.A. Dr. Smith is an active member of IIE, SME, and INFORMS.

394

Simulation-based shop floor control

Documents

Transcript of Simulation-based shop floor control