An Overview of RapidCIM Concepts

Richard A. WyskIE551 - Computer Control of Manufacturing

Systems

R ap idC IMP ro jec t

R ap idC IM

P S U

T A M U

S y stemD e sig n e r

S y ste mO p era to rs

A C M Ep rod u ces gene ra tes

c o n tro ls

O w n e r

X

co n tro ls

co n tro ls

Agenda• Traditional Software Development• Motivation for RapidCIM• RapidCIM Concepts• Equipment Level Models• Message-based Part State Graphs• Conclusions• Resources

IntroductionAutomated

Flexible Manufacturing Cells/Shops

HardwareSystemControl

Software

ProgrammingTools &

Software

Tools to assist indevelopment ofSystem Control

Software

Input Input ????

????NC ProgrammingOffline Robot Programmingetc.

CAD Modelsetc.

Traditional Control Software Development

In traditional “PLC-type” control, the control software is developed using the same planning, scheduling, and execution flow diagram.

Traditional Control Software Development

Planning (determining part routes) and scheduling (sequencing tasks) are built into the control software - Similar to a PLC ladder diagram.

Adding new parts or changing the scheduling rules require significant modifications to the control software

These changes must be done by the FMS vendor instead of the system operators

Motivation For RapidCIM Most current FMS control implementations

are customized Lack of generic tools

Limitations in flexibility and reconfiguration High cost of reliable software development

2/3 rd of total expenditure is incurred during implementation phase, due to errors in software design

approx. 64% of the errors are made at the concept stage and only 36% are programming errors

On average, 50% or more of the software costs for flexible automation are related to control

Shop-floor control Lack of emphasis on software

development Architectures do not provide sufficient detail Software requirements have not been

systematically analyzed to separate generic requirements from implementation-specific requirements

Functions performed are too tightly coupled Tools to aid in the manufacturing

system software development do not exist

RapidCIM Project

R ap id C IMP ro jec t

R apidC IM

P S U

T A M U

S y stemD e sig n e r

S y ste mO p era to rs

A C M Ep rod u c es ge nera tes

c o n tro ls

O w n e r

X

c o n tro ls

c o n tro ls

Specific Tasks Understand the control elements of a FMS Develop theoretical foundations for FMS

control, through use of formal models Create generic model of control

independent of implementation specifics Automatic generation of control software

for various controllers in the cell using the formal models

Create a FMS control software development methodology which can be implemented as a set of domain specific CASE tools

Control Software Need Software

That is generic and hence reuseable

Easily customized per installation

Modular & modules being “plug compatible”

Shop Floor Control Software

Generic Implementation Specific

AutomaticallyGenerated

HandCoded

Hierarchical ArchitectureS ho p

E q u ipE q u ip

W k s tn

E q u ipE q u ip

W ks tn

E q u ipE q u ip

R e s o u rc eM a na g e r

W ks t n

Control Hierarchy EQUIPMENT

Physical devices (NC machines, robots, AGV, ASRS, programmable fixtures, buffers, etc)

WORKSTATION Integrated pieces of equipment Robot tending a single machining center, along

with requisite fixtures, sensors, etc. Robot tending several machines

SHOP Several integrated workstations, coupled by

material transport workstations

Equipment Level Each controllable equipment is

viewed as comprising Physical device controller (supplied with

machine) Equipment controller (typically a PC)

Generic Classes of Equipment MP - Material Processor (NC machine, CMM) MH - Material Handler (robot) MT - Material Transporter (AGV, conveyor) AS - Automated Storage Device

EQUIPMENT LEVEL (Cont) Non Controllable equipment

BS - passive buffer storage devices PD - passive devices

Ports (entry and exit of parts) PO - ports

Equipment level controller incorporates a device driver, that implements

the equipment level functions (cycle start, download, etc)

This is the implementation specific portion

Workstation Level Workstation comprises

equipment (MP, MH, PO, BS, MT ....) Types of Workstation

Processing workstation Transport Workstation Storage Workstation

Planning, Scheduling, and Execution Planning

Determining what tasks thesystem needs to perform

SchedulingSequencing planned tasks

ExecutionPerforming the scheduledtasks at the appropriatetime

S ystem O p era tio n

P lann in g

S ch ed u lin g

E x ecu tio n

P h ysica lS ys tem

P la nn ed ta sk s

S ch ed u led ta sk s

T ask s

Functional ArchitectureLEVEL

FUNCTIONS

EQUIPMENT WORKSTATION SHOP

PLANNINGTool Selection, Toolpath refinement

Tool assignment toslots, job set upplanning

Resource allocations

Batch splitting

Equipment LoadBalancing

Batching

Worlokad Balancingbetween workstations

Task allocation toworkstations

SCHEDULING Operation sequencingat individualequipment

-Sequence equipment levelsubsystems

-Deadlock Detection

Buffer Management

Assignment of due dates toworkstations

Batch sequencing andmanagement

EXECUTION Interface toworkstation controller

Physical control ofmachinesExecution of control

Monitor equipment statesand execute part andinformation flow based onstates

Synchronization

Organizational control ofworkstaions

Interface with MRP

Report Generation

Shop Floor Controller Structure

ProductionR equirem ents

C ontro lle r

PhysicalSystem

I/O C h anne ls

P lanner S cheduler Ex ecuto r

TaskList

I/O C hann el

Syste m M o del

PhysicalM odel

SystemSta tus

PhysicalConfigura tion

Part Flow Through the Shop

E nte rS hop

D elive r toW ks tn

P ut onEq uip P rocess

R efix tu reP ick fromE qu ip

R em ove fromW k stn

E xitS hop

P ut onEq uip

D elive r toW ks tn

Material Processor System Model

O utput Input

Process ing

2 13

NC M achineEquipm ent Type: M PNam e: NC M illPart Locations:Num P rocessing B locked Input Output 1 N N Y N 2 Y Y N N 3 N N N Y

M P :m p_put p rocess m p_p ick

Physical Model

Physical Configuration

Material Handler System Model

M H :pu tp ick

Home Equipment Type: MHName: M1-L RobotGripper Capacity: 1Locations: 20 - Home: 0Num x y z1 0 0 0: : : :20 100 100 100

Physical Model

Physical Configuration

Typical Processing Workstation

Horizon VVertica l M ill

Da e woo Pu m aTu rn ing Ce n te r

Bu ffer

Fan uc M 1-L

M ate ria l T ra nspo rtCar t

Physical Model - Processing Workstation

S

po rt_ a rr ive

po rt_p ickport_depart

bs_pick bs_put

port_put

E

P o rt M H

B S

m p_ pickm p_put

M P

m p_ pick

m p_put

M P

Event SequenceEvent Source Message/

TaskDestination

1 Workstation assign part machine controller2 Machine Controller at location workstation3 workstation put part robot controller4 robot controller put task robot5 robot controller put done workstation6 workstation grasp part machine controller7 machine controller grasp part

taskmachine

8 machine controller grasp done workstation9 workstation clear robot controller10 robot controller clear task robot11 robot controller clear done workstation12 workstation clear OK machine controller

Equipment-level Device Interaction

ro b o t c le a r

e x e c u te p ro g ra mto c lo s e fix tu re

fix tu re c lo s e d

e x e c u te p a r tp ro g ra m

c le a r to lo a d p a rt ?

e x e c u te p ro g ra mto lo a d p a rtc lo s e fix tu re

e x e c u te p ro g ra m to re le a s e p a rt a n d

m o v e a w a y

c le a r

mp_put

Can this be implemented in a generic manner?

Custom specifics Protocols Communications

Message-based Part State Graph (MPSG) An MPSG is a deterministic finite automaton

representing the processing protocol for a part.

An MPSG state provides information about the current processing state of the part that is needed to determine the behavior on subsequent events.

State transitions are caused by receiving messages about the part and by performing functions specified by the scheduler.

A Mealy machine is essentially a finite automaton with output. Formally, a Mealy machine M is defined as follows:

So, a Mealy machine is a finite state automaton in which an output (defined by and ) is generated during state transitions.

Mealy Machine

M Q q

Q q

Q

, , , , , ,

, , , ,,

:

0

0

where

and are as is in a finite automaton,is an output alphabet and

is an output transition function.

MPSG Definition

function.nsition action tra controller a is )(:functionn transitiostate a is )(:

false.or truereturns which predicate a is each e,Furthermor . ingcorrespond a is there,each for that so

dpartitione is actions. controllerfor onspreconditi physical ofset finite a is

action controller some performswhich function executablean is whereactions controller ofset finite a is

taskscontroller ofset a is messagesoutput ofset a is

messagesinput ofset a is and events, ofset finite a is )(

states acceptingor final ofset a is statestart or initial theis

states ofset finite a is :Where

),,,,,,,(=MPSG

0

0

TO

TOI

T

O

I

TOI

QQQ

QFQq

Q

FqQ

MPSG for Generic MP Equipment

ass ign _w e t_ass ign @ loc_ew

@ loc_ns_ew

grasp_we t_grasp grasp_ok_ew clea r_ok_we

m p_ pu t

1 2 3 4 5 6 70

proc esst_sta rt

t_s top

t_dnld

fin ish_de done_ew

t_start

t_dn ld

done_ew

7 8 9 10

re lea se_ok_ew@ loc_ew

@ loc_ns_ew

clear_ok_werem ove_we t_ rem ove re lease_we t_re lease

m p_ pick

10 11 12 13 14 15 16 17

MPSG Characteristics Explicitly separate scheduling from execution.

Extensible at multiple levels to facilitate software development

Generic MPSG can be used unmodified. Extraneous transitions can be removed. Specified messages and tasks can be rearranged. New messages and tasks can be specified.

Execution portion of the control software is automatically generated from the MPSG description.

Shop Floor Controller Class

Storage Class Provides basic database functions for

the controller Parts are tracked based on their location in the

shop, state, and the workstation and equipment level device to which they are assigned.

Objects within the storage class Parts Slots - Corresponding to physical locations Entities - Lower level controllers in the control

hierarchy

Controller Class Embellishes the storage class with

the data structures necessary for control.

U ser In terface

C om m un ic a tion s

M P S G

P lan ner

S ched u ler

Equipment Class Specializes the controller class so that

the instantiated objects interact directly with a piece of equipment

Not “Equipment Objects” in the system. Rather the equipment class is further partitioned based on the behavior of the individual pieces of equipment.

Material Processors (MP) Material Handlers (MH) Automated Storage Devices (AS) Material Transporters (MT)

Software Generation Generation software has been

developed in C++ for use in DOS, OS/2, ULTRIX, AIX, UNIX and Windows operating system environments.

Components of the generation system MPSG Builder Controller Class

MPSG Class Communications Class (IOMUX for CIM lab implementation)

Generic equipment descriptions and functions MPSG Scheduler Task action functions

Communication Controller to device Controller to controller Controller to database Controller to Messaging

Communications - continued IOMUX

1995 based system that connected all of the computers

Router 1997 based system that uses a single

device to route all messages

IOMUX (I/O Multiplier) Facilitates the interprocess transfer of

data in a consistent manner independent of the hardware/operating systems of the components.

System components can be reconfigured without recompilation by modifying an ASCII configuration file representing the route map (default.map).

Platform/domain Formerly implemented on the

following platforms: DOS

RS-232 Serial TCP/IP using Watt TCP

OS/2 TCP/IP Shared queues (IPC)

UNIX - TCP/IP DEC ULTRIX IBM AIX SGI

Current Implementation Windows NT/ Windows 2000 serves

as the core for the system. Arena 3 or 4 is used as message

generation for the Execution system

Router – communication Access - database

Shop Level Physical Model

p u t

p ic k

M P 1

M H 3M H 2M H 1

P 1 P 2 P 3

m ov e

m ove

m o v e

m o v e

p ic k

p ic k

p ic k

p ic k

p ic k

p ic k

p u t

pu tp u t p u t

p u t

p ro c e s s p ro c e ss p ro c e s s

M P 2 M P 3

s to re re trie v e

A S 1

A S 1

Start/Stop

introduce

remove

Controller Tasks Physical Model actions/tasks become tasks

issued by simulation

Simulation - issues a “pick” through a message placed in the task initiation queue

Big Executor explodes the “pick” task into various messages that

are send to the individual controllers and co-ordinates their actions based on the responses

returns a “pick_done” message to the simulation in the task completion queue

Conclusions Traditional Control Software generation

issues Concept of RapidCIM Separation of Planning and Execution Physical models for equipment classes Workstation and shop level controllers

What Next? Manufacturing Architectures RapidCIM Simulation-based Control NEXT! Implementation Issues

Resources Joshi, S. B., Mettala, E. G., Smith J. S., and Wysk, R. A., “

Formal models for control of flexible manufacturing cells: physical and system model”, IEEE Transactions on Robotics and Automation, v11, n4, Aug, 1995 IEEE, Piscataway, NJ, USA, p 558-570.

  Joshi, S., J. Smith, R. Wysk, B. Peters, and C. Pegden, "Rapid-CIM: An

Approach to Rapid Development of Control Software for FMS Control", 27th CIRP International Seminar on Manufacturing Systems, Ann Arbor, MI, May, 1995.

Mettala, E. G., “Automatic generation of control software in computer-integrated manufacturing”, Ph.D. Dissertation, Department of Industrial and Manufacturing Engineering, Pennsylvania State University, University Park, PA 16802, 1989.

Resources Qui, R. B., “Modeling and Control of a flexible manufacturing system

using deterministic finite capacity automata”, Ph.D. Dissertation, Department of Industrial and Manufacturing Engineering, Pennsylvania State University, University Park, PA 16802, 1996.

  Qui, R. B. and Joshi, S. B., “

Deterministic finite capacity automata: a solution to reduce the complexity of modeling and control of automated manufacturing systems”, Proceedings of the 1996 IEEE International Symposium on Computer-Aided Control System Design, Sep 15-18 1996, Dearborn, MI, USA, p 218-223

Qui, R. B. and Joshi, S. B., “A Structured Adaptive Supervisory Control Methodology doe Modeling the Control of Discrete Event Manufacturing” IEEE Transactions on Systems, Man, and Cybernetics, vol. 29, no. 6, 1999, pp. 573-586