Object-oriented modeling and implementation of control software for a robotic flexible manufacturing...

Pergamon

Robotics & Computer-lnteorated Manufacturing, Vol. 11, No, 1, pp, 1-12, 1994 Copyright ~" 1994 Elsevier Science Lid

Printed in Great Britain. All rights reserved 0736-5845/94 $7.00 + 0.00

• Paper

OBJECT-ORIENTED MODELING AND IMPLEMENTATION OF CONTROL SOFTWARE FOR A ROBOTIC FLEXIBLE MANUFACTURING

CELL

LI LIN,* MASATOSHI WAKABAYASHI* and SADASHIV ADIGA'~

*Department of Industrial Engineering, State University of New York at Buffalo, 342 Lawrence D. Bell Hall, Buffalo, NY 14260, U.S.A. and "['Department of Industrial Engineering and Operations Research, University of

California at Berkeley, Berkeley, CA 94720, U.S.A.

This paper discusses the development of an object-oriented software for the control of a robotic flexible manufacturing cell (FMC). The control software is based on a formal modeling of the entities involved in a cell and their interactions. An entity-relationship model, message flow diagrams, and state transition models are used to specify the software objects needed to model the operation of an FMC. In an object-oriented approach, the cell controller takes care of coordination and synchronization issues while the individual objects are responsible for their own activities. This approach has numerous advantages over the conventional state transition method where the number of state grows exponentially with the increase in cell components and complexity of control tasks. Implemented in Turbo C + + on an IBM PS/2 computer, the software can accommodate cell configuration changes, such as the number of machines, without reprogramming. Robot dispatching rules that are independent of the cell configuration were developed for handling the simultaneous setups, prevention of order sequence interference and batch break-up situations that are often encountered in FMC control.

INTRODUCTION A manufacturing cell is identified as an important control level in the control hierarchy of modern manufacturing systems. 14'24 Flexible manufacturing cells (FMCs) are generally organized to manufacture part families with similar processing requirements but slightly different routings. Controlling an FMC typi- cally requires responding to real-time events by identifying short-term requirements and generating control commands accordingly in runtime.

Modeling the control logic of coordinating multiple machines and a material handling robot that comprise a typical FMC is a complex task. Larin ~5 recognized that the deficiency in available software, software tools and languages significantly limits the flexibility of cells.

The benefits of an object-oriented (OO) world view for simulating flexible manufacturing systems have been discussed by Basnet and Mize 3 and Mize et al. 19 This "fundamental paradigm shift" (Mize et al.) 19

facilitates managing the complexity of manufacturing control systems. When applied to a manufacturing cell environment, most control situations can be modeled as a sequence of messages that are exchanged between objects that represent important devices in the cell. The objects take responsibility for controlling device-level activities. In this paper, we present the design of a

Acknowledyement--This research is supported in part by the National Science Foundation, Division of Design and Manufacturing Systems, Grant No. DDM-9209452.

control system (software and heuristics) for an FMC based on an OO modeling and discrete-event analysis approach. The functioning of this control software was verified through a discrete-event simulation.

It is well known that a material handling robot has a significant impact on the dynamics of a robotic FMC through its coupling of the components in the cell. It can cause major delays if it is not properly managed or is down due to failures. Therefore, we have chosen to focus on issues of robot dispatching and control by the cell controller in this investigation. Although basic heuristic rules have been proposed in this paper, our primary emphasis is on OO analysis and modeling rather than development of sophisticated dispatching rules or control algorithms. (Readers interested in this subject are referred to Liu and Lin 16 who specifically discuss the dynamic sequencing of robot moves in a cell.)

MANUFACTURING CELL CONTROL Manufacturing cells An FMC is an outgrowth of flexible manufacturing systems (FMSs) and distributed numerical control systems. 15 All these systems involve the coordination of multiple machine tools. The difference between a cell and an FMS appears to be more one of size and complexity than anything else. Definitions of a manufacturing cell vary, but a good one is: "a manufacturing cell is the grouping of people and processes into a

specific area dedicated to the production of a family of parts or products." 17 Typical cells consist of two to six machine tools linked by a common material handling device such as a robot, and are controlled by a supervisory cell controller.

Approaches to cell control There are three approaches to FMC control: 6'1° centralized, hierarchical and heterarchical. A centralized control uses one processor to control the entire cell operations. Its lock-step sequential control cannot handle failures or be modified for cell configuration changes without substantial re-programming of the control software.

A part-oriented heterarchical control models each entity in the cell with its own software module. Entities communicate with one another through a network link. Since far less global information is used in this localized control strategy, it is flexible and has a good fault tolerance. However, the excessive communication between the software modules slows down the system considerably. This may result in delays when there are a large number of processes to control.

In hierarchical control, a cell control master computer coordinates the operation of all equipment by constantly monitoring all process functions, each controlled by a slave computer. The communication between the cell controller and the equipment is achieved by passing control commands and execution status feedback as messages in a computer network. Several FMCs using this approach have been reported. 5'12 An advantage of hierarchical control is that it allows the control problem to be partitioned to limit the complexity of any module in the hierarchy, regardless of the complexity of the entire structure. 24 Information is passed through the system in well- organized and well-defined communication protocols. 23 Since the scope or influence of a particular controller in a hierarchical facility is limited to its (single) parent and (many) child nodes, minimum reprogramming effort is required when controller is to be modified, z°

Although the hierarchical approach is the most widely used one in manufacturing control systems for its good response times, the structure of such systems becomes fixed early in their development, thus making subsequent (some times unforeseen) modifications difficult for complex systems. 9 A modified hierarchical architecture with lateral links between components at the same level is therefore used to improve system autonomy. 6

Heterarchical control systems have the advantages of even more local autonomy, reduced software complexity and implicit fault-tolerance. 6 However, due to the lack of a communication protocol and their requirement for a high network capacity, they are mostly used in laboratories and do not seem to be implemented in many factories.

Our approach may be considered as a hybrid one where individual objects (work order, machines, robot,

Robotics & Computer-Integrated Manufacturing • Volume 11, Number 1, 1994

etc.) control their actions and communicate with each other while the coordination among objects is left to the cell controller. Within the modified hierarchical control architecture, 6 a cell controller may have three types of interactions with other controllers: (1) with a higher-level controller, (2) with other cell controllers, and (3) with equipment in the cell. In this paper, we address issues related to a cell controller's interactions with equipment (with special attention to the material handling robot).

State transition models State transition models are commonly used for manufacturing cell control by establishing relations between system states and control actions. Tiemersma and Kals 25 analysed cell behavior using a state transition diagram for the equipment in a cell. Specific conditions (inputs) trigger the corresponding action(s) (outputs) and change the equipment state. Drolet and Moodie 6 used a relational database with a state table for a cell controller. Control commands were obtained by querying the state table. This is an attractive appoach as it separates static data from control logic. As a result, the state table is concise, and the execution is therefore faster.

Jockovic et al. 13 developed control rules in a knowledge base. The rules are extracted and executed depending on the input signals. By organizing the cell controller's complicated logic, access time was reduced.

The major drawback of the state transition model stems from its complexity due to the explicit representation of all states of the cell's components. Even adding one machine would result in a significantly more complex state table. This makes it difficult to expand the system. In addition, the deterministic nature of the state table increases the system's inflex- ibility in dealing with abnormal conditions such as a machine breakdown.

OO WORLD VIEW AND MODELING O 0 modeling and design The OO world view consists of looking at the world as a set of interacting objects. An object is an encapsula- tion of data and procedures (or methods) that operate on the data. Objects communicate with one another by sending messages. Thus, we may say that the interface of an object is a set of messages. Because of these information hiding and data abstraction features, the effect of software changes can be confined to a minimal part of the program. Objects are organized in a hierarchy of classes. The inheritance feature reduces the programming effort when the system is expanded. The dynamic binding property available in most OO systems makes the program flexible.

Designing a control system based on an OO world view requires decomposition of the system as objects rather than functions. In a design following the traditional functional decomposition approach, software modules correspond to the system's functions.

Object-oriented modeling • L. LIN et al.

OO design is a design technique in which a system is decomposed into objects that exist in the real-world system. 4 Thus, the model of the domain reflected in the software may closely resemble the real-world system.

O0 models for FMS The OO world view has been used by a several other researchers 2'3'~ ~ to solve production control problems related to FMS. Adiga and Gadre 2 illustrated a design method by modeling an FMS with six machines interconnected by an automated guided vehicle system. Physical objects and control tasks are modeled as objects, and their dynamic changes are represented by message flow diagrams. Miller and Lennox is developed a robot controller to work with a hierarchy of software objects. They demonstrated the similarity between the hierarchy in software objects and real-life manufacturing systems. A hierarchical FMC control system was modeled without losing its flexibility and fault tolerance. An improvement in overall system development productivity was demonstrated due to reusability and portability of the software. Basnet and Mize 3 and Mize et al. 29 discussed different approaches to modeling operational problems of FMSs. They suggest that the complexity of dynamically scheduling and controlling a random FMS can be captured adequately only by a discrete-event simulation model.

OO MODEL OF THE FMC An OO model of the FMC is constructed by iteratively following the three steps given below: (a) identify the objects based on an entity-relationship (E-R) model, (b) identify the methods needed in each object by analysing the message exchanges that take place in response to important events, 2 and (c) analyse the state changes to further formalize the behavior of individual objects. The first two steps are discussed in this section. The next section will discuss the third step by focusing on the dynamics of cell operations. It is important to note that message flow diagrams draw one's attention to system level interactions while state transitions focus on individual object states. Since many control actions are driven by particular states attained by objects during their manufacturing activities, state transition models complement message flow diagrams in modeling the dynamic behavior of individual objects.

Objects and classes First, object classes and attributes are identified in the problem domain. This is done by building an E-R diagram where each entity is replaced by an object. Candidates for representation as software objects are: physical objects, databases and conceptual objects. Physical objects include a robot, input/output buffers, machines and parts. Databases are for making available compact information related to production orders, parts, process plans and NC programs. The cell controller is a conceptual object. Figure 1 shows the E-R diagram used to extract objects in this appli-

) r d g ~ Contains

executed status of

, . . . . . . d l ~o,d. I I es by "

R ,, ,or plan Itroller ] . [ plan

Is served by

I I l l Holds stor.a~e

Is at I Controls y Checks Requires status of d I

' ~ Tool

Requires

N{

-2 Uses ~a,

Fig. 1. Entity-relationship diagram for FMC control.

[s at

cation. With the notations from Rumbaugh et al., z2 entities are represented by rectangles, and lines connecting entities along with a verb represent relations (read from left to right and from top down).

We distinguish between two types of attributes: static and dynamic. Static attributes maintain their values throughout the system execution, while dynamic attributes change their values depending on the condition of the object, i.e. state changes. Table 1 lists the object classes and their attributes.

Object modeling of database support for FMC control Designing a normalized database to support all functions of an FMC is a non-trivial task that is beyond the scope of this paper. In this research database support is provided by a collection of flat files containing (mostly external) data needed for control purposes. The files used include cell configuration,

Table l . Object classes and attributes

Object class Attributes

Robot

Machine

Input buffer Output buffer Order Part

Process plan

NC prog DB Cell controller

Name, robot id, speed, state, grip_proc, wait loc, pickup loc, dropoff loc Name, machine id, location, state, NC~t~rog_id, NC_prog

Name, buffer_id, location, num of parts Name, bufferid, location Orderid, partid, quantity, due date

Name, part id, process id, grip~roc, dimensions, weight, material Name, process id, part_id, operation_sequence, operation_names, opration ids, M/C ids, NC_prog_ids NC_prog_id, NC prog

Name, celljd, nurn_of m/cs , station_locs, state, current order_id, current_partid, current_process id, process_seq, current due date, num orders_comp, num_parts comp, robdispatch corns

order, part, process plan and NC program databases. In addition, a breakdown information file is provided to handle a machine breakdown situation. Using the OO approach, all databases are here modeled as objects. (Readers interested in data modeling in FMSs are referred to work by other researchers, for example, Moyne et al. 2° and Wedekind and Zoerntlein, 2~ for manufacturing data modeling activities.)


"start machining." The robot's dispatch is determined according to the processing sequence of machines, the dispatching rules, and status of components in the cell. A typical command to the robot is "move a part from station i to station j with gripping procedure k."

Messaye flow diayrams A message flow diagram is a network in which the nodes represent objects and the arcs connecting them represent messages. It is a useful design aid, both for understanding interactions among objects and for specifying methods needed in objects. All important events, including the transfer of static information such as part ID, and dynamic information such as the command "start machining", can be analyzed by message flows diagrams.

The message flows at the beginning of a work cycle are shown in Fig. 2. When the robot removes the last part of an order from the input buffer, the input buffer sends a signal to the cell controller, requesting information about the next order. The cell controller retrieves the next order from the order database to obtain the part ID, quantity and due date. Using the part ID as a key, the corresponding process plan and robot gripping procedure are then retrieved. The process sequence of machines and NC program IDs for the next order are read from the process plan database and stored in the cell controller. If all parts of the previous order are completed from checking the status of each machine, the cell controller initiates a setup for the machine, and the machine updates its NC program for the next order by retrieving the NC program database.

During one order cycle, the cell controller receives signals from cell components and determines what control signals to send to the cell components, e.g.

Sends signal I , / / "the ,astpart ] ~ k L © ~ ' ~ ' ~ ? ~

picked u ~ ~ . . . . . . ~© fl~-

Ice"l ®soo0. p,r,_id =1 ~ " I I ~ ° " t ~ ° l ' ~ ( ~ Ro, . . . . p-of . . . . i d - I " " " I

® Se,ds s~°,, I "~ . "~*o , , . "the lastpart I of order is I x~, z ~ v e e , t,t .

Sends S ~ N C - - ~ - ; d ""e, ge@" | 1 - ' '°" | "finishes [ e~c. -r- . . . . . setup" Jr / ' ~ .

IM, :hine l- "1.,~,~'.,.I ' ' ~ Returns NC_prog I ~-° . . . . . I

Fig. 2. Message flow diagram (per order).

Objects and methods Being the primary means for implementing object interactions, methods are derived from the message flow diagrams and state transition diagrams. A method is simply the way for an object to respond to a message or command for state change(s). For instance, the message "finishes machining", represented by the arrow between "Machining" and "Idle, part" states, will become a method in the machine object (with the program code to change its state). Immediately after finishing machining, the machine reports its state change to the cell controller.

Methods for each object class are listed in Table 2 Multiple methods, such as "finish dropping off", "send signal" (for robot), "receive signal", send command" (for cell controller), "receive command" and "start machining" (for machine) can be executed successively.

D Y N A M I C S OF CELL OPERATION: OBJECT STATE TRANSITION MODELS

A state is an abstraction of the attribute values of an object. It corresponds to the interval between two events received by an object. 22 Objects change their states (status) in response to the messages they receive. State transition models of a few major objects in our system are discussed next.

Machine Figure 3 shows the machine's state transition. When the cell controller sends a message "start machining" to a machine after a part is delivered to the machine by the robot, the machine changes its state from "Idle, no part" to "Machining." When it finishes machining, it changes to "Idle, (with) part" by itself and sends a signal (message) to notify the cell controller of this event. The dashed lines at the state changes indicate the object's communication to other objects, including the interaction with a database. Note that the setup for

Table 2. Objects and methods

Object class Method

Robot

Machine

Input buffer

Cell controller

Send signal, receive command, reportstatus, start moving, finish _pickup, finishdropoff

Send_signal, receivecommand, reportstatus, start machining, finish_machining, releasepart, start setup, finishsetup, retrieve NC_prog

Sendsignal, accept part, release part, count parts

Receive order, receive signal, sendcommand, inquire_status, retrieve DBs, determine robdispatch, update com_queue, check com queue

new orders is distinctively modeled transitions.

Object-oriented modeling • L. Lirq et al. 5

in the state up." If not, the state returns to "Waiting for signal (Robot idle)."

Robot For the robot, a move command from the cell controller changes its state from "Idle" to "Moving to pick up." A pickup changes the state to "Moving to drop off" and a part dropoff to the designated location changes the state to "Idle" with a message sent to the cell controller, notifying the robot's availability.

Buffers The input buffer has only two states: "No part," and "Part" (indicating there is at least one part). A part arrival and a robot pickup may cause the state transitions. States of the output buffer are modeled similarly.

Cell controller Figure 4 shows the cell controller's state transition. Initially at "Waiting for order," the cell controller starts its operation when it receives a list of orders (production commands) from the shop. After machines are set up with process data retrieved from the databases, it waits for a signal from the input buffer at the state "Waiting for signal (Robot idle)."

The command queue is the cell controller's memory space for a list of robot dispatching commands. A dispatching decision is made when the cell controller receives signals from the cell's components. The dispatching command is then appended to the command queue by the "Updating command queue" procedure. The commands are executed by the robot by the "first-in-first-out (FIFO)" rule. Whenever the robot becomes "Idle," if the cell controller determines that there are robot dispatching commands in the command queue by the "Checking command queue" procedure, the first command is removed from the quene and sent to the robot. The robot consequently will change its state from "Idle" to "Moving to pick

Receives command "start machining"

from

m.chi ', g I / L-tting.,

Robot ~ /W Sends finishes ~ L NC_prog_id

picking up ~ / - ' - . ~ 1 - - - " ~ ' ~ the last part X / 7 ...~.-._ I

of ordnr _ I " \ / I v ' ~ . . . . I Rocel,os comm;nd

[ ~ I g ~ "start setting up" I ~ " " " " u I ~ from cell control ler

Fig. 3. Machine state transition model.

SOFTWARE IMPLEMENTATION OF THE CELL CONTROLLER

As in most OO programs, the main program of our system (implemented in Borland International's Turbo C + + on an IBM PS/2 computer) creates the objects and manages the main flow of control in the software by chaining a sequence of important messages to individual objects such as orders, machines, etc. The corresponding objects are responsible for exhibiting the behavior expected from them in response to the control messages. A flow chart of the cell controller's logic flow is shown in Fig. 5. After retrieving the configuration file to set up the cell environment, the cell controller reads the first order from the order database. Part and process data files are retrieved next.

Using the order queue information of the next order, the input/output buffers are set up for the current order (details to be given next) and machines are set up for further querying the NC program database. The logic flow corresponds to the cell controller's state transition shown earlier.

MODELING IMPORTANT CONTROL FUNCTIONS

As mentioned earlier, we believe that a material handling robot can have a significant impact on the dynamics of a manufacturing cell. Our OO model of the FMC is designed to handle the following situations in the operation of the FMC: (a) dispatching of the robot for transfer of parts between stations (note: machines and buffers are all referred to as stations), (b) handling simultaneous setup of machines, (c) dispatching to prevent interference from processing different orders in the cell at the same time, and (d) handling machine breakdown and restart. The cell control logic in this paper does not aim to optimize robot dispatching. Robot commands are executed in the sequence of their determination, using FIFO transaction of the command queue. The use of an efficient sequencing logic may improve robot productivity, as demonstrated in Liu and Lin.16

Robot dispatching conditions To be consistent with realistic discrete-event systems, we assume that the cell controller is not aware of the status changes of the cell components until notified by corresponding signals. After receiving a signal, the cell controller checks if the event would create a new condition for part transfer.

Figure 6 shows the robot dispatching conditions. Conditions at both origin and destination stations have to be satisfied before a decision on a part transfer between them can be made. According to the process plan, a part must be processed at these two stations in succession, i.e. the processing sequence number for the two stations, m/c_seqs, must be consecutive.

The robot dispatching rules for a part transfer


Roo°i,o, I P'r' I I I order A Sends A Sends

from shop I part_id I "start setup" # ~ 1 I 1 | u ~ , ~ " " ; ' ; d ' ~ / v ' ) , R e a d s , Sends

~ _ ~ ~ first order ~ process_id

[ Order [ ~ Pr°cess I / , I , v l a n ,

~ ~ ~h~e is

Robot finishes I ~ ; : : ~ a a n d dropping off the [ l , r ~necl~ing_

last part of the I { c o m m a n d last order at I If at machine, ~ queue ~./

O-buffer I sends "start ~ J vx There is

a command

Waiting for signal

(robot idle)

Robot /J"< ~. Sends command finishes / ~ " .. "move part" \

Robot Finishes updating Waiting for

signal p= irobot moving).~. Robot finishes dropping off

the last part of order at O-buffer

Updating command

queue

Receives signal from I-buffer or machine

Robot finishes picking up the

last part of order at

I-buffer

Reads / / t ~" ,. next order// Sends ~ x ,. Sends

/ part_id | - - process_id

[ Order [ [ Part I [ Pr°cess [ p l a n

Fig. 4. Cell controller state transition model.

If the last part ~ of order is picked

up at machine, sends "start setup" &~" ~, ~"

[ Machine I

Robot finishes picking up at machine, or

receives signal from . I-buffer or machine

~ " Updating Finishes ~ command ) updating

between stations i and j (the two consecutive stations a part will visit) are represented by the following pseudo codes (for simplicity, machining sequence is abbre- viated as "m/c_seq", and command queue is "com q"). In this data-driven system the maching sequence (obtained by a query to the process plan object) dictates the part routing in the cell.

If signal = part available at station i if (for destination) s ta t ion j ' s

m/c seq = station i's m/c_seq + 1 AND state of station j ="Idle, no part" (for m/c) or

any state (for o buff) then add command "move from station i to

station j" to com q else no command is created endif

Elseif signal = station i available to accept part if (for origin) station i's m/c_seq = s ta t ionj ' s

m/c s e q - 1 AND state of station i = "Pa r t " (for i_buff) or "Idle,

part" (for m/c) then add command "move from station i to

station i" to corn q else no command is created endif

Endif

If there are robot dispatching commands in the

command queue, the one stored the earliest is extracted by the FIFO rule. Otherwise the robot remains "Idle" while the cell controller waits for the next signal. There are, however, several special situations in FMC operation that require some specific robot dispatching rules. These are discussed next.

Simultaneous setup In an FMC with batch processing, machines need to be set up for each new order. In this research, the control program is designed so that each machine can be set up for the next order even while other machines are still processing the current order. In order to do so, order number, order quantity, and a counter for number of completed parts are assigned as dynamic attributes for the machine objects. A new order number and order quantity are assigned to a machine, and the counter is reset to zero when the machine is set up for the new order. By using OO design, this is easily accomplished without complicating the program since all the data related to machines can be encapsulated in machine objects.

In this way, it is possible to set up machines for process plans of different orders simultaneously to reduce the much wasted machine waiting time for other machines to finish the current order. The cell's efficiency will be improved. Rules for the simultaneous setup are summarized as follows:

I setup I environment ]

_ _ ~ Retrieve databases I

Set up I/O-buffers

and machines

Object-oriented modeling n L. LIN et al.

R pickup at I-buffer

at M/C le°m-Q ~ N -I

R dropoff I

R dropoff Y~-"~O--bufferl"]cgm 0 [-~ atO-b f L .--%... " - " I ~ Last pan ol ~.~. ~ Check

finish ~ / ~ 1

PartM/ci_buffaratan.iV,empty - •||| " / N [ r o b o t ] iil

breakdown _1 Follow procedures ] -1 for breakdown [

Check order completion

I Last part of order ~ / The last part I i: 'Pli-Cbl¢: fleUrP T i ; ~ b ~ ~

Fig. 5. Cell controller program logic flow.

Cell controller

command [com_l ~'b rot.at - " | queue [com_2 I / disp~.com !Tm- I|

(D Searches destination |

teen. d"s siflni?tls Inquires ~ ~ • s macbiu"7/. ® \ \ ®,,n,., state and ~ ~ state and

P a r t ~ order_num ~ . ~ u m

I-buffer or M/C M/C or O--buffer

Conditions:

I-buffer or M/C M/C or O-buffer Processing N N + 1 seq_num

State "Part (I-buffer) "Idle, no part" "Idle, part" (M/C) (M/C)

Order..num M M

Fig. 6. Robot dispatching conditions.

If signal---"robot finishes picking up at machine" num_comp = num_comp + 1 (increment part count

by 1 at the machine) if num_comp < order_quantity

then change machine state to "Idle, no part" else change machine state to "Waiting for setup"

endif Inquire machine_state (by cell controller)

if machine_state ="Waiting for set-up" AND order no. of machine < order no. of i buff then get N C i d , order_quantity, m/c_seq of

order no.+ 1 from order q assign NC_id, order_quantity, m/c seq (to

machine object) retrieve NC prog (using the assigned NC_id) reset num_comp = 0 (new order starts with a

new part count) change machine state to "Setting up" endif

Update command queue Endif

The first part states the condition for setup when a part is picked up from a machine. The order quantity is used to check with the part count by the machine. The second part uses "order no." as a key to determine whether the machine is ready for the setup for the arriving order at the input buffer. A machine setup is then performed by retrieving all the required process parameters.


Prevention of order sequence interference When simultaneous setup is included in the control logic, an order sequence interference may result from the processing of parts from different orders in the cell at the same time.

In the example shown in Fig. 7, the cell consists of three machines, and two orders are issued from the shop. Assume that the last part of order 1 is being processed at machine 1, when there is no part at machine 2. Even if the first part of order 2 arrives and its first processing machine, machine 2, is idle, it is not suitable to load it, because machine 2 is not set up for order 2. In order to prevent this order sequence interference, additional robot dispatching rules have to be established. Order numbers need to be assigned not only to the attributes of the machine objects, but also to the attributes of the input buffer, indicating which order the station is set up for. When the cell controller determines how to dispatch the robot, it needs to check order numbers as well as states of the successive stations, according to the processing sequence. There- fore, as a necessary condition to transfer parts, order numbers of the two stations must be the same. This is added to the previous dispatching rules.

A simulation run of the situation is provided in the Appendix. It verifies all the states and order information as the system progresses through various events in the above example.

Prevention of batch break-up When parts from multiple orders are processed in the cell at the same time, problems of batch break-up may

First part of ~ Last part of order 2urrives ( 0 " ~ order l

Turn

0 4 - (M/C 1) "Machining"

I-buffer - . .

"Idle, (M/C 2) no part"

"1 O-buffer Drill "Idle,

(M/C 3) no part"

Process plans

Order 1

O-buffer

Turn Mill Drill Order 2 (M/C 1) (M/C 2) (M/C 3)

@ °" [~ --'~ "4~ O-buffer

Mill Drill (M/C 2) (M/C 3)

Fig. 7. Order sequence interference.

also occur. An example is illustrated in Fig. 8 with two orders given by the shop. If the first part from order 2 is finished by machine 1 while the last two parts from order 1 are still being processed at machines 2 and 3, respectively, the robot may attempt to transfer the part to the output buffer, causing a mix-up with order 1.

Additional robot dispatching rules are added to prevent this from happening. Order number is also assigned to the attributes of the output buffer and only when it matches the order number of an originating machine can a part can be transferred between them. The improved robot dispatching rules are now summarized as follows:

If signal = part becomes available at station_i if (for destination) station j's

m/c seq = station_i's m/c seq + 1 AND station_j's state ="Idle, no part" (for m/c), any

state (for o_buff) AND order_no, of station j = order_no, of station i then add command "move from station i to

station j " to com_q else no command is created endif

Elseif signal-- station j becomes available to accept part

if (for origin) station i's m/c_seq = station i's m/e/ s e q - 1 AND

state of station_i = "Part" (for i_buff) or "Idle, part" (for m/c) AND

order_no, of station_i = order_no, of station_j then add command "move from station i to

station_j" to com_q

I-buffer

(M/C I) / / [

/ Mill / t (M/C 2)

I

P

ml × O-buffer Dri

(M/C 3) "Machining"

Process plans

Order 1

First part of order 2 finishes machining

@ "Machining"

Last two parts of order 1

Turn Mill Drill (M/C I) (M/C 2) (M/C 3)

Order 2

~ ~ ~ ~., O-buffer

Turn (M/C 1)

Fig. 8. Batch break-up.

else no command is created endif

Endif

Machine breakdown and restart handling procedures When one of the machines breaks down, the following sequence of events and associated actions are taken: (i) The cell controller changes its status to "Machine breakdown." (ii) Except for the broken one, machines in operation or setup process should continue until such operations are completed. No further commands to initiate machining or setup are sent to the machines after the cell controller is in breakdown status. (iii) The robot operates until it delivers a part currently being held at the designated station. No further command will be given. (iv) The broken machine is stopped if it is in operation, and the part on the machine is scrapped. Correspondingly, all counters, including that for the order, the buffers, and the machines, will be decreased by one. (v) The cell controller records the current order and status of the cell to the breakdown information database. (vi) The cell controller stops its operation.

After the machine is repaired, the cell controller restarts its operation. The breakdown information database is read at the beginning of each program run, and a flag value at the first attribute signifies whether the previous run was terminated due to a machine breakdown event. The restart procedure is as follows: (i) The cell controller reads the breakdown information and checks if it is restarting from a machine breakdown situation. (ii) If it is, order and status information is retrieved and set to attributes of all objects and the cell controller's main control module. (iii) The system returns to the regular work cycle.

DISCUSSION In this section, we present some interesting issues related to cell control in the OO paradigm. We elect not to discuss the popular benefits of OO software such as reusability, etc., since such examples may be found in other references, such as the ones provided earlier in this paper.

Specification and representation of control logic In the OO approach, control actions are often modeled as a specific sequence of messages to objects. This makes the system flexible as implementation of individual responses is left to the discretion of the receiving objects. Representation of control actions reflecting some of the algorithms used required multiple levels of message-flow diagrams. It may be noted that the respective algorithms have been presented in a few lines of text in this paper.

We echo Nof's 21 observation that, while the system specification is made easier by the OO paradigm, control specification is affected by the tendency among analysts to think about control in a procedural manner. One of the reasons for this is that mapping from a procedural expression to message sequences is not intuitive. Further, communication through a

Object-oriented modeling • L. Lmr et al. 9

message may also result in a transfer of control to the receiving object. This may shift the focus of attention to different sets of objects calling for different diagrams to highlight the interactions. An intuitive and compre- hensive representation of the dynamics of message flows is a good research topic for the future.

Flexibility of the representation Since the software designed from an OO model closely resembles the real system, it is easy to understand and easy to modify. Program changes of a certain object require little or no changes to other parts of the software.

We believe that replacing the conventional state table approach with an OO representation has given us additional flexibility in dispatching the robot. As a result, there is no fixed logic such as a state table to dispatch the robot. In our approach, each object stores its own state (in its attributes or instance variables). State transitions are triggered by events determined by the dispatching rules used. Dynamic behavior expected of these objects during these transitions is captured by analysing state transition diagrams in the design stage. The notion of managing control through one table has been decentralized in our approach.

The increase in complexity and the number of combinations expected in the state table approach does not arise in our case. The dispatching rules are not dependent on the number of machines in a cell. Consider the following example: When a station changes its state, only the state of the "destination" station is checked if it is possible to transfer a part between these two stations. A destination station is determined by comparing the machining sequence assigned to the machine and buffer objects. The cell controller only needs to focus on the states of these two stations by using the dispatching rules.

Flexibility of the software implementation The software system is designed so that it can accommodate cell configuration changes, such as adding a machine, without reprogramming. The number of machines and their locations can be easily specified by the user in a configuration file. This flexibility is achieved since the OO design makes it possible to dynamically allocate memories for objects during a program run, and to encapsulate data about objects only in the object modules.

Fault tolerance An important and difficult issue in the design of complex control systems is achieving fault tolerance. We did not target fault tolerance as a topic for investigation in this experiment. However, we can make some observations on this issue as given below.

In a typical hierarchical control system, an entity at a given level in the hierarchy requires substantial knowledge of the entities above it in the hierarchy as well as the entitities below it when fault tolerance is incorporated. As pointed out by Duffle, s this tends to

lo

make large hierarchical systems difficult and expensive to design, maintain, and modify. In an OO approach, objects are designed with minimum assumptions about the behavior of other objects. Moreover, the OO design uses less global information and more local control. Objects can store their own data and access remote databases as needed. If we take advantage of such features, it is possible to design systems where some objects continue to function even if others fail.

Robotics & Computer-Integrated Manufacturing • Volume 11, Number 1. 1994

signals from a real manufacturing cell and to integrate with a fully functional FMS database. Real cell components, such as machine and robot controllers, can be connected to substitute their counterparts in the software objects. Real signals from such controllers can be sent to the cell controller instead of the simulated ones used here.

Control system architecture As mentioned earlier, our approach is not a strictly hierarchical control. We have treated machines and the cell controller as independent objects without making any assumptions about the behavior of others. They communicate with one another by sending messages. This provides a loose coupling between important control objects and allows them to be replaced or upgraded individually as needed. This feature will aid system designers and implementors to choose a hierarchical or heterarchical control (or a hybrid one) as appropriate to their respective control situations.

An industrial control system will need to have a user interface, monitoring and communication features in addition to control or decision logic. It has been shown elsewhere that it is possible to integrate these features through a common OO model. 1

CONCLUDING REMARKS We have implemented a moderately complex control system for a robotic FMC by building a computational model of the FMC as consisting of discrete objects that interact with one another by passing messages.

Since data in the object modules are hidden from other objects, and objects communicate by messages for executing pre-defined tasks, the software program closely resembles the real manufacturing environment. Consequently, the software is easy to understand and easy to modify. Because the dynamic behavior of each object is modeled by analysing its own state transition model, it satisfies the needs of real-time control while overcoming the difficulty in the state table method where all states must be explicitly represented. Due to this modularity from the object creation and data hiding features of the O O design, little or no reprogramming is required when the number of machines is changed.

The cell control logic for FMC operation is built by developing several robot dispatching rules, including the handling of simultaneous setup, prevention of order sequence interference and batch break-up. Access to production information through the system database makes it possible to experiment with different situations in the operation of an FMC.

Currently the software system works in a computer environment with simulated signals from the cell components, and minimum necessary database support is provided only for demonstration purposes. Future research can be expanded to incorporate

REFERENCES 1. Adiga, S.: Object-oriented technology for integrated

modeling of a robot for simulation, control and monitoring tasks. Technical Report, Engineering Systems Research Center, University of California at Berkeley, 1992.

2. Adiga, S., Gadre, M.: Object-oriented software modeling of a flexible manufacturing system. J. Intell. Robotic' Systems 3: 147-165, 1990.

3. Basnet, C. B., Mize, J. H.: An object-oriented framework for operating flexible manufacturing systems. In Pro- ceedings of International Conference on Object-oriented Manufacturin# Systems, The University of Calgary, Canada. 1992, pp. 346-351.

4. Booch, G.: Object-oriented development. IEEE Trans. Software Engng SE-12(2)" 211 221, 1986.

5. Cutkosky, M. R., Fussel, P. S., Milligam R., Jr.: The design of a flexible machining cell for small batch production. J. mfq Systems 3(1): 39-58, 1984.

6. Dilts, D. M., Boyd, N. P., Whorms, H. H.: The evolution of control architectures for automated manufacturing systems. J. mfq Systems 10(l ): 79-93, 1991.

7. Drolet, J., Moodie, C. L.: State-table innovation for cell controllers. Comput. ind. Engn9 16: 235-243, 1989.

8. Duffle, N. A.: Non-hierarchical cell control. In Manufac- turin# Cells: Control, Programming and Integration, Williams, D. J. and Rogers, P. (Eds). Oxford, Butter- worth-Heinemann. 1991, pp. 143-172.

9. Duffle, N. A., Chitturi, R., Mou, J.: Fault-tolerant heterarchical control manufacturing system entities. J. mf9 Systems 7:315 328, 1988.

10. Duffle, N. A., Piper, R. S.: Non-hierarchical control of a flexible manufacturing cell. Robotics Computer-lnteqr. Mf9 3: 175-179, 1987.

11. Fabian, M., Lennartson, B.: Control of manufacturing systems: an object-oriented approach. In Proceedinqs o[" the 7th IFAC Symposium on InJormation Control Prob- lems in Manufacturing Technology (INCOM 92), Tor- onto, Canada, 25-28 May 1992.

12. Hammer, H.: Flexible manufacturing cells and systems with computer intelligence. Robotics Computer-hlte#r. Mf9 3: 39-54, 1987.

13. Jockovic, M., Vukobratovic, M., Ognjanovic, Z.: A contribution to the organization of an expert system for process control of FMC. Robotics Computer-h~te.qr. Mfq 7: 297-302, 1990.

14. Jones, A. T., McLean, C. R.: A proposed hierarchical control model for automated manufacturing systems. J. mfq Systems 5(1): 15-25, 1986.

15. Latin, D. J.: Cell control: what we have, what we need. Mf9 Engn9 102(1): 41-48, 1989.

16. Liu, S.-C., Lin, L.: Dynamic sequencing of robot moves in a manufacturing cell. Eur. J. opl Res. 69: 482-497, 1993.

17. Martin, J. M.: Cells drive manufacturing strategy. Ml.q Engnff 102(1): 49-54, 1989.

18. Miller, D. J., Lennox, R. C.: An object-oriented environment for robot system architectures. IEEE Control Systems 11(2): 14 23, 1991.

19. Mize, J. H., Bhuskute, H. C., Pratt, D. B., Kamath, M.: Modeling of integrated manufacturing systems using an object-oriented approach, l i e Trans. 24(3): 14 26, 1992.

Object-oriented modeling •

20. Moyne, J. R., McAfee, Jr., L. C., Teory, T. J.: An application of entity-relationship data modeling tech- niques to the automated manufacturing process. In IEEE Computer Society, Second International Confer- 24. ence on Data and Knowledge, Systems for Manufacturing and Engineering, Gaithersburg, MD. 16-18 October 1989, pp. 206-215.

2l. Nof, S.: Is all manufacturing object-oriented? In Pro- 25. ceedings of International Conference on Object-oriented Manufacturing Systems, The University of Calgary, Canada. 1992, pp. 37 54.

22. Rumbaugh, J. Blaha, M., Premerlani, W., Eddy, F., Lorensen, W.: Object-oriented Modeling and Design. 26. Englewood Cliffs, N J, Prentice-Hall. 1991.

23. Scogin, D. N., Titone, M. J.: Automated Manufacturing Research Facility (AMRF) based manufacturing system control software. In Proceedings of Manufacturing Inter-

L. LIy et al. 11

national '90, Part 1: Intelligent Manufacturing Structure, Control and Integration, Atlanta, GA. 25-28 March 1990, pp. 39-48. Simpson, J. A., Hocken, R. J., Albus, J. S.: The Automated Manufacturing Research Facility of the National Bureau of Standards. J. mfg Systems 1(1): 17-31, 1982. Tiemersma, J. J., Kals, H. J. J.: A real-time monitoring and control system for small batch bart manufacturing. In Proceedings of Manufacturing International '90, Part 3: International Aspects of Manufacturing, Atlanta, GA. 25-28 March 1990, pp. 41-48. Wedekind, H., Zoerntlein, G.: Conceptual basis for database applications in flexible manufacturing systems. In Proceedings of IEEE International Conference on Robotics and Automation, Raleigh, NC. 1987, pp. 551-557.

A P P E N D I X : SAMPLE P R O G R A M R U N F O R M U L T I P L E O R D E R P R O C E S S I N G

Ibuff (ord2) M/C 1 (ordl) M/C 2 (ordl) 'No part' 'Idle,no part' 'Idle,no part'

M/C 3 (ordl) Idle,no part

Obuff (ordl) (#comp=l)

- R o b o t d r o p o f f part(2/l) a t M/C

Ibuff (ord2) M/C 1 (ordl) 'No part' 'Machining'

i

M/C 2 (ordl) 'Idle,no part'

<event time=103.313210>

M/C 3 (ordl) Obuff (ordl) Idle,no part (#comp=l)

- P a r t (i/2) arrival

Ibuff (ord2) M/C i (ordl) 'Part (q=l) ' 'Machining'


<event time=lll.219650 >


-M/C I finish machining part(2/l)

Ibuff (ord2) M/C I (ordl) 'Part (q=l) ' 'Idle, part'

COL 'i to 2'


added <event time=llg.313210>


-Robot pickup part(2/1) at M/C I

Ibuff (ord2) M/C i (ord2) 'Part(q--I)' 'Waiting setup'


<event time=l18.313210 >

M/C 3 (ordl) Obuff (ordl) Idle,no part (#comp-- I)

-Robot dropoff part(2/l) at M/C 2

Ibuff (ord2) M/C 1 (ord2) M/C 2 (ordl) 'Part(q=l) ' 'Waiting setup' 'Machining'

<event time=t19.727425>

M/C 3 (ordl) Obuff (ordl) Idle,no p a r t (#comp=l)

-M/C 2 finish machining part(2/l) com '2 to 3'

Ibuff (ord2) M/C I (ord2) M/C 2 (ordl) 'Part(q=l) ' 'Waiting setup' 'Idle, part'

added <event time=f21.727425 >

M/C 3 (ordl) Obuff (ordl) Idle,no part (#comp=1)

-Robot pickup part(2/1) at M/C 2

Ibuff (ord2) M/C 1 (ord2) 'Part(q=l) ' 'Waiting setup'

M/C 2 (ordl) 'Settlng up'

<event t ime=121. 727425>

M/C 3 (ordl) Obuff (ordl) Idle,no p a r t ' (#comp= i)

12 Robotics & Computer-lntegrated Manu~cturing • Volume 11, Number 1, 1994

-H/C 2 finish setup com '0 to 2' added <event time=122.227425 >

Ibuff (ord2) H/C 1 (ord2) H/C 2 (ord2) M/C 3 (ordl) Obuff (ordl) 'Part(qffil) ' 'Waiting setup' 'Idle,no part' 'Idle,no part' (#comp=l)

-Robot dropoff part(2/l) at M/C 3

Ibuff (ord2) M/C 1 (ord2) 'Part(q=l)' 'Waiting setup'

M/C 2 (ord2) 'Idle,no part'

<event time=123.141640 >

M/C 3 (ordl) Obuff (ordl) 'Machining' (#comp=l)

-fi/C 3 finish machining part (2/1)

Ibuff (ord2) H/C I (ord2) 'Part (q=l) ' 'Waiting setup'

com '3 to 4' added <event timeffi125.141640 >

M/C 2 (ord2) H/C 3 (ordl) Obuff (ordl) 'Idle,no part' 'Idle, part' (#comp=l)

- R o b o t pickup p a r t ( i / 2 ) a t I b u f f

Ibuff (ord2) M/C i (ord2) 'No part' 'Waiting setup'

M/C 2 (ord2) 'Idle,no part'

<event time=125.377708 >

M/C 3 (ordl) Obuff (ordl) 'Idle, part' (#comp=l)

- R o b o t d r o p o f f p a r t ( i / 2 ) a t M/C 2

I b u f f (o rd2) M/C 1 (o rd2 ) 'No part' 'Waiting setup'

H/C 2 (ord2) 'Machining'

<event timeffi127.613777 >

M/C 3 (ordl) Obuff (ordl) 'Idle, part' (#comp=l)

-Robot pickup p a r t ( 2 / 1 ) a t M/C 3

Ibuff (ord2) M/C i (ord2) 'No part' 'Waiting setup'

M/C 2 (oral2) 'Machining'

< e v e n t t i m e = 1 2 9 . 0 2 7 9 8 5 >

H/C 3 (ordl) Obuff (ordl) ' S e t t i n g up ' (~compffil)

Object-oriented modeling and implementation of control software for a robotic flexible manufacturing...

Documents

Transcript of Object-oriented modeling and implementation of control software for a robotic flexible manufacturing...