An Overview of RapidCIM Concepts
Richard A. Wysk
IE551 - Computer Control of Manufacturing Systems
System
Designer
produces
Owner
ACME
generates
RapidCIM
controls
RapidCIM
Project
X
controls
System
Operators
PSU
TAMU
controls
Agenda
• Traditional Software Development
• Motivation for RapidCIM
• RapidCIM Concepts
• Equipment Level Models
• Message-based Part State Graphs
• Conclusions
• Resources
Introduction
Automated
Flexible Manufacturing
Cells/Shops
Hardware
Input
CAD Models
etc.
Programming
Tools &
Software
NC Programming
Offline Robot Programming
etc.
System
Control
Software
Tools to assist in
development of
System Control
Software
????
Input ????
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
System
Designer
produces
Owner
ACME
generates
RapidCIM
controls
RapidCIM
Project
X
controls
System
Operators
PSU
TAMU
controls
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
Automatically
Generated
Hand
Coded
Hierarchical Architecture
Shop
Resource
Manager
Wkstn
Equip
Wkstn
Wkstn
Equip
Equip
Equip
Equip
Equip
Control Hierarchy

EQUIPMENT


WORKSTATION




Physical devices (NC machines, robots, AGV, ASRS,
programmable fixtures, buffers, etc)
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



Ports (entry and exit of parts)


BS - passive buffer storage devices
PD - passive devices
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 the
system needs to perform
System Operation
Planning

Scheduling
Sequencing planned tasks
Planned tasks
Scheduling
Scheduled tasks

Execution
Performing the scheduled
tasks at the appropriate
time
Execution
Tasks
Physical
System
Functional Architecture
LEVEL
EQUIPMENT
WORKSTATION
SHOP
Tool Selection, Tool
path refinement
Resource allocations
Batching
Batch splitting
Worlokad Balancing
between workstations
FUNCTIONS
PLANNING
Tool assignment to
slots, job set up
planning
Equipment Load
Balancing
SCHEDULING Operation sequencing -Sequence equipment level
at individual
subsystems
equipment
-Deadlock Detection
Buffer Management
EXECUTION Interface to
Monitor equipment states
workstation controller and execute part and
information flow based on
Physical control of
states
machines
Execution of control Synchronization
Task allocation to
workstations
Assignment of due dates to
workstations
Batch sequencing and
management
Organizational control of
workstaions
Interface with MRP
Report Generation
Shop Floor Controller Structure
Production
Requirements
I/O Channel
Controller
Task
List
Planner
System
Status
Scheduler
Physical
Configuration
System Model
I/O Channels
Executor
Physical
Model
Physical
System
Part Flow Through the Shop
Refixture
Enter
Shop
Deliver to
Wkstn
Put on
Equip
Process
Pick from
Equip
Put on
Equip
Deliver to
Wkstn
Remove from
Wkstn
Exit
Shop
Material Processor System Model
Physical Configuration
NC Machine
Output 3
2
1
Input
Equipment Type: MP
Name: NC Mill
Part Locations:
Num Processing Blocked Input Output
1
N
N
Y
N
2
Y
Y
N
N
3
N
N
N
Y
Processing
mp_put
process
MP:
Physical Model
mp_pick
Material Handler System Model
Physical Configuration
Home
Equipment Type: MH
Name: M1-L Robot
Gripper Capacity: 1
Locations: 20 - Home: 0
Num
x
y
z
1
0
0
0
:
:
:
:
20
100 100 100
Physical Model
pick
MH:
put
Typical Processing
Workstation
Horizon V
Vertical Mill
Material
Transport
Cart
Daewoo
Puma
Turning
Center
Fanuc M1-L
Buffer
Physical Model Processing Workstation
MP
E
mp_put
mp_pick
port_depart
mp_pick
port_pick
Port
MH
MP
port_put
mp_put
port_arrive
bs_pick
bs_put
S
BS
Event Sequence
Event
Source
1
2
3
4
5
6
7
Workstation
Machine Controller
workstation
robot controller
robot controller
workstation
machine controller
8
9
10
11
12
machine controller
workstation
robot controller
robot controller
workstation
Message/
Task
assign part
at location
put part
put task
put done
grasp part
grasp part
task
grasp done
clear
clear task
clear done
clear OK
Destination
machine controller
workstation
robot controller
robot
workstation
machine controller
machine
workstation
robot controller
robot
workstation
machine controller
Equipment-level Device Interaction
mp_put
clear to load part ?
clear
close fixture
execute program
to close fixture
fixture closed
robot clear
execute part
program
execute program
to load part
execute program
to release part and
move away
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.
Mealy Machine

A Mealy machine is essentially a finite
automaton with output. Formally, a Mealy
machine M is defined as follows:
M  Q, q0 , , , ,  where,
Q, q0 , , and,  are as is in a finite automaton,
 is an output alphabet , and
 : Q     is an output transition function.

So, a Mealy machine is a finite state automaton
in which an output (defined by  and ) is
generated during state transitions.
MPSG Definition
MP SG = (Q, q0 , F , , , ,  ,  )
W here:
Q is a finit eset of st at es
q0  Q is t heinit ialor st art st at e
F  Q is a set of final or accept ingst at es
  ( I   O  T ) is a finit eset of event s,and
 I is a set of input messages
 O is a set of out put messages
T is a set of cont rollert asks
 is a finit eset of cont rolleract ionswhere   is an execut ablefunct ion
which performssome cont rolleract ion
 is a finit eset of physicalpreconditons
i for cont rolleract ions.  is part it ione
d
so t hatfor each   , t hereis a corresponding   . Furt hermor
e, each
   is a predicat ewhich ret urnst rue or false.
 : Q  ( I   O  T )  Q is a st at e t ransit ion funct ion
 : Q  ( O  T )   is a cont rolleract ion t ra
nsit ionfunct ion.
MPSG for Generic MP
Equipment
mp_put
assign_we
0
1
t_assign
@loc_ew
2
grasp_we
3
4
t_grasp
5
grasp_ok_ew
6
clear_ok_we
7
@loc_ns_ew
t_dnld
t_stop
process
7
t_start
8
finish_de
9
done_ew
10
t_start
t_dnld
done_ew
mp_pick
10
remove_we
11
t_remove
12
@loc_ew
@loc_ns_ew
13
release_we
14
t_release
15
release_ok_ew
16
clear_ok_we
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.
User Interface
Communications
MPSG
Planner
Scheduler
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
Controller
Controller
Controller
to
to
to
to
device
controller
database
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



OS/2



RS-232 Serial
TCP/IP using Watt TCP
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
AS1
process
process
process
store
MP1
MP2
pick
put
put
pick
put
MH1
move
P1
pick
pick
put
pick
MH3
move
P2
move
remove
AS1
MP3
MH2
put
pick
retrieve
put
pick
P3
move
introduce
Start/
Stop
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 ComputerAided 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. 573586