Using Finite State Automata to
Model Manufacturing Systems
R. Wysk
Agenda – Systems Theory
according to Wysk
• Typical manufacturing systems
• Modeling a manufacturing system as a
state machine
• What is a finite state machine?
• Notation and variables
• Examples
Basic types of systems
• Continuous
– Normally modeled as differential state based
entities
• Discrete (DES)
– Not adequately modeled as differential or
difference entities
– Checkers, chess, many manufacturing
systems
How about Starbucks?
The Concept of a Language
• Every DES has an underlying event set, E
associated with it.
• The set E is thought of as the “alphabet” of
a language.
• The event sequences for a DES are
thought of as “words” in the language.
• Different modeling prospective can be
taken for most DES
Examples - chess
• Model with respect to one piece
• Model with respect to one color
• Model with respect to all pieces
Examples - manufacturing
• Model with respect to a part
• Model with respect to a machine
• Model with respect to all resources
3
Machine
1 M1
4
5
2
1
7
L
R
8
UL
6
Machine
2 M2
How about our machine?
Examples – Highway systems
• Model with respect to one car (like a GPS)
• Model with respect to one highway
• Model with respect to all highways and
cars
How about driving to Crabtree
Valley Mall?
Intent
•
•
•
•
Show what a finite state automata (FSA) is
Show how to formally model an FSA
Illustrate some uses for FSAs
Discuss “discrete event systems” modeling
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
Finite state view to Illustrate
Control Simulation Requirements
3
6
4
Machine 1
M1
2
1
L
5
7
R
8
UL
Machine 2
M2
Task
Number
1
2
3
4
5
6
7
8
Task
Name
Pick L
Put M1
Process 1
Pick M1
Put M2
Process 2
Pick M2
Put UL
Physical Model Processing Workstation
Process
MP
E
mp_put
mp_pick
port_depart
Process
mp_pick
port_pick
Port
MH
MP
port_put
mp_put
port_arrive
bs_pick
bs_put
S
BS
Some Observations about this
Perspective
• Generic -- applies to any system
• Other application specifics
– Parts
• Number
• Routing
• Buffers (none in our system)
Finite State Automata (FSA)
• Consist of
– Nodes – X
– Events – E
– Transition maps – f(m,n,e)
– Starting state – q0
– Event transitions – F(X1, e) = X2
Modeling a state graph
• States/nodes
- X ( x , y, z )
• Events/transistions - E ( a , b, g )
• Graph construction
– F (x , a ) = x
– F (y , a ) = x
– F (z , b ) = z
– F (x , b ) = F (x , g ) = z
– F (y , b ) = F (y , g ) = y
– F (z , a ) = F (z , g ) = y
The Graph looks like
x
y
z
So FSAs
•
•
•
•
Formal way to model discrete systems
Can symbolically build complex systems
Capture lots of system detail
Provide the grain for modeling a system
• So what about a DC?
Deterministic Automaton
•
A Deterministic Automaton, denoted by G, is a six-tuple
G = (X,E, f, Γ, x0,Xm)
where:
X is the set of states
E is the finite set of events associated with G
f : X × E → X is the transition function: f(x, e) = y means that there is a transition
labeled by event e from state x to state y; in general, f is a partial function on its
domain
Γ : X → 2E is the active event function (or feasible event function); Γ(x) is the set of
all events e for which f(x, e) is defined and it is called the active event set (or feasible
event set) of G at x
x0 is the initial state
Xm ⊆ X is the set of marked states.
• The words state machine and generator (which explains the notation
G) are also often used to describe the above object.
• If X is a finite set, we call G a deterministic finite-state automaton,
often abbreviated as DFA.
• The functions f and Γ are completely described by the state
transition diagram of the automaton.
• The automaton is said to be deterministic because f is a function
from X × E to X, namely, there cannot be two transitions with the
same event label out of a state.
• In contrast, the transition structure of a nondeterministic automaton
is defined by means of a function from X × E to 2X; in this case,
there can be multiple transitions with the same event label out of a
state. Note that by default, the word automaton will refer to
deterministic automaton.
• The fact that we allow the transition function f to be partially defined
over its domain X × E is a variation over the usual definition of
automaton in the computer science literature that is quite important
in DES theory.
Planning, Scheduling, and
Execution
• Planning
Determining what tasks the
system needs to perform
System Operation
Planning
Planned tasks
• Scheduling
Sequencing planned tasks
Scheduling
Scheduled tasks
Execution
• Execution
Performing the scheduled
tasks at the appropriate
time
Tasks
Physical
System
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
Yard Example
We can treat
the Gate
House as the
“material
handler”
1
Queue
of
trucks
2
Gate
House
Dock 3
3
System Model for the Yard
Depart
Go to 1
Request
Yard
Dock 1
Go to 2
Gate
House
Dock 2
Go to 3
Truck
Arrival
Dock 3
Build a formal model of the state
graph
• X (Yard, Gate, Docki)
• E(Depart/Balk, Gate_serve,Traveli, Leave
to gate, Return to yard)
• You finish the FSA modeling
Some things not considered
• Queue discipline
– FIFO, SPT, …
• Rules for assigning trucks to docks
– Due date, SPT, …
A – Inbound truck load (pallets)
B – Inbound truck load (cases)
Ci – Cases in bulk dock i
Di – Pallets at inbound dock i
Ej – Pallet in forklift j – TRM algorithm
Fl – Complete pallets in drive-in rack l
Gm – Partial pallets in single-deep rack m
Hn – Pallet at case picking rack n (level 2)
Ip – Pallet in buffer area p
Jk – Pallet at outbound dock k
Ko – Pallet at case picking rack o (level 1)
L – Re-work area
Mp – New pallet in buffer area p
Np – Wrapped pallet in buffer area p
Oq – Pallet in pallet jack q
P – Cases in truck load
A communicating automata
• An FSA that interacts with a decision maker
– Decision maker can be a person, algorithm, …
• Messages create changes in the graph
– Go_to_Dock #1  equivalent to the controller telling a
driver to proceed to dock #1
• Input and Output messages
– Input messages update the status of the graph
– Output messages signal the start of an event
Deterministic and non-deterministic
FSAs
Depart
Go to 1
Request
Yard
Dock 1
Go to 2
Gate
House
Dock 2
Go to 3
Truck
Arrival
Dock 3
A – Inbound truck load (pallets)
B – Inbound truck load (cases)
Ci – Cases in bulk dock i
Di – Pallets at inbound dock i
Ej – Pallet in forklift j – TRM algorithm
Fl – Complete pallets in drive-in rack l
Gm – Partial pallets in single-deep rack m
Hn – Pallet at case picking rack n (level 2)
Ip – Pallet in buffer area p
Jk – Pallet at outbound dock k
Ko – Pallet at case picking rack o (level 1)
L – Re-work area
Mp – New pallet in buffer area p
Np – Wrapped pallet in buffer area p
Oq – Pallet in pallet jack q
P – Cases in truck load
Some Observations about this
Perspective
• Generic -- applies to any discrete system
• Other application specifics
– Parts
• Number
• Routing
• Buffers (none in our system)
RapidCIM Model
• Message-based part state graph (MPSG)
– Execution formalism based on finite automata
– Mimic controller behavior from part point of
view
– Explicitly separate scheduling from execution
– reference: Smith and Joshi, 1992
– web site:
http://www.engr.psu.edu/cim/control.html
Generated FSA Execution model -- based on the rules, but
manual yet
M
2
Blocking
attributes are set
to 1: must be
blocked
1
1
M
1
R
M
3
1
Due to limited space,
these two arrows are
expanded in this
figure
part_enter@1_sb
I
1
A
S
rm_asrs@1_sb
I
.......
mv_to_asrs@1_sb
I
.......
put_ok#1@1_bs
O
Stations
AS
M1
M2
M3
Index
1
2
3
4
O
pick_ns#1@1_br
pick_ns#1@1_sb
O
arrive@1_bk
arrive_ok@1_kb
O
I
clear_ok#1@1_rb
I
at_loc@1_bs
I
I
T
Index
1
at_loc@1_kb
O
return_ok@1_bs
delete@1
rm@1_bk
Robots
R
I
loc_ok@1_bs
O
put_ns#1@1_br
put_ns#1@1_sb
O
I
RapidCIM Project
• Built formal models for shop floor control
(MPSG)
• Developed a compiler to automatically
generate code for control
• Created Arena RT messaging
• Used process plans to define part routes
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 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 automaton in which an
output (defined by  and ) is generated during state
transitions.
MPSG Definition
MP SG = (Q, q0 , F , , , ,  ,  )
Where:
Q is a finiteset of states
q0  Q is theinitialor start state
F  Q is a set of finalor acceptingstates
  ( I   O  T ) is a finiteset of events,and
 I is a set of input messages
 O is a set of output messages
T is a set of controllertasks
 is a finiteset of controlleractionswhere   is an executablefunction
which performssome controlleraction
 is a finiteset of physicalpreconditions for controlleractions.  is partitioned
so thatfor each   , thereis a corresponding   . Furthermore, each
   is a predicatewhich returnstrue or false.
 : Q  ( I   O  T )  Q is a state transition function
 : Q  ( O  T )   is a controlleraction transitionfunction.
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.
Simulation-based SFCS
Scheduler
Database
ARENA: real-time
(Shop floor controller)
Task
Input Queue
Task
Output Queue
Big Executor (Shop Level)
Kardex
ABB
140
AGVS
M1
Hass VF
0E
Equipment Controllers
SL-20
ABB
240
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
Uses of FSAs
• Can generate controllers automatically
– Software can be created directly from this formal
model
• Can be used to define resources and events in a
discrete system
– Bernie Zeigler won the IEEE Gold Metal for his work
on DEVS (2002)
• Can be used to automatically generate
simulation model
– Son created both software controllers as well as
simulation for messaging
Summary - Process a part
part_enter_sb
1
remove_kardex_sb
2
pick_ns_sb
3
put_ns_sb
move_to_mach_sb
7
move_to_kardex_sb
6
put_sb
process_sb
pick_sb
8
return_sb
9
5
move_to_mach_sb
4
return_sb
0