Using Finite State Automata to Model Manufacturing Systems R. Wysk.
-
Upload
dane-jenny -
Category
Documents
-
view
223 -
download
3
Transcript of Using Finite State Automata to Model Manufacturing Systems R. Wysk.
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
8
2
34 5
6
71Machine
1 M1Machine
2 M2R
L UL
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
E nterS hop
D eliver 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 e live r toW ks tn
Finite state view to IllustrateControl Simulation Requirements
TaskNumber
TaskName
1 Pick L2 Put M13 Process 14 Pick M15 Put M26 Process 27 Pick M28 Put UL
8
2
34 5
6
71Machine 1
M1Machine 2
M2R
L UL
Physical Model - Processing Workstation
S
po rt_ a rr ive
port_p ickport_depart
bs_p ick 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
MP
Process
Process
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-tupleG = (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
• PlanningDetermining 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 hysica lS ys tem
P lann ed ta sk s
S ched u led ta sk s
T ask s
Shop Floor Controller Structure
ProductionR equirem ents
C ontro lle r
PhysicalSystem
I/O C hanne ls
P lanner S cheduler Ex ecuto r
TaskL ist
I/O C hannel
System M odel
PhysicalM odel
SystemSta tus
PhysicalConfigura tion
Gate House
1 2 3
Dock 3
Yard Example
We can treat the Gate
House as the “material handler”
Queue of
trucks
System Model for the Yard
Yard Gate House
Dock 1
Dock 2
Dock 3
Depart
Truck Arrival
Request
Go to 1
Go to 2
Go to 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) Ip – Pallet in buffer area p B – Inbound truck load (cases) Jk – Pallet at outbound dock k Ci – Cases in bulk dock i Ko – Pallet at case picking rack o (level 1) Di – Pallets at inbound dock i L – Re-work area Ej – Pallet in forklift j – TRM algorithm Mp – New pallet in buffer area p Fl – Complete pallets in drive-in rack l Np – Wrapped pallet in buffer area p Gm – Partial pallets in single-deep rack m Oq – Pallet in pallet jack q Hn – Pallet at case picking rack n (level 2) 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
Yard Gate House
Dock 1
Dock 2
Dock 3
Depart
Truck Arrival
Request
Go to 1
Go to 2
Go to 3
A – Inbound truck load (pallets) Ip – Pallet in buffer area p B – Inbound truck load (cases) Jk – Pallet at outbound dock k Ci – Cases in bulk dock i Ko – Pallet at case picking rack o (level 1) Di – Pallets at inbound dock i L – Re-work area Ej – Pallet in forklift j – TRM algorithm Mp – New pallet in buffer area p Fl – Complete pallets in drive-in rack l Np – Wrapped pallet in buffer area p Gm – Partial pallets in single-deep rack m Oq – Pallet in pallet jack q Hn – Pallet at case picking rack n (level 2) P – Cases in truck load
• Generic -- applies to any discrete system
• Other application specifics– Parts
• Number• Routing• Buffers (none in our system)
Some Observations about this Perspective
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
1
1
1
R
M2
M3
AS
1
Due to limited space, these two arrows are
expanded in this figure
part_enter@1_sb rm_asrs@1_sb rm@1_bk at_loc@1_kb
pick_ns#1@1_sb.......return_ok@1_bs
I I O I
II
at_loc@1_bs
O
pick_ns#1@1_br
O
mv_to_asrs@1_sb arrive@1_bk arrive_ok@1_kb loc_ok@1_bs
put_ns#1@1_sbput_ns#1@1_brclear_ok#1@1_rbput_ok#1@1_bs.......
I O I O
IOIO
T
delete@1
Robots IndexR 1
Stations IndexAS 1M1 2M2 3M3 4
Blocking attributes are set
to 1: must be blocked
M1
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.
• A Mealy machine is essentially a finite automaton with output. Formally, a Mealy machine M defined as follows:
So, a Mealy machine is a finite 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
Q
QF
Q
FqQ
MPSG for Generic MP Equipment
assign _w e t_assign @ loc_ew
@ loc_ns_ew
grasp_we t_grasp grasp_ok_ew clear_ok_we
m p_ put
1 2 3 4 5 6 70
proc esst_sta rt
t_s top
t_dnld
fin ish_de done_ew
t_sta rt
t_dn ld
done_ew
7 8 9 10
re lea se_ok_ew@ loc_ew
@ loc_ns_ew
clear_ok_werem ove_w e t_rem ove re lease_w e t_re lease
m p_ p ick
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.
Simulation-based SFCS
ARENA: real-time(Shop floor controller)
Big Executor (Shop Level)Big Executor (Shop Level)
Equipment Controllers
SL-20SL-20Hass VF 0E
Hass VF 0E
M1M1ABB 240
ABB 240
AGVSAGVSKardexKardex
TaskOutput Queue
TaskOutput Queue
Database Scheduler
TaskInput Queue
TaskInput Queue
ABB140
ABB140
Equipment-level Device Interaction
robot clear
execute programto close fixture
fixture closed
execute partprogram
clear to load part ?
execute programto load partclose fixture
execute program to release part and
move away
clear
mp_put
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 remove_kardex_sb pick_ns_sb return_sb
put_sb
move_to_mach_sb
move_to_kardex_sb
put_
ns_s
b
move_to_mach_sb
0 1 2 3
456
process_sbpick_sb
7
8 9return_sb