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 elive r toW ks tn

P u t onEq uip P rocess

R efix tu reP ick fromE qu ip

R em ove fromW kstn

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

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

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-tuple

G = (X,E, f, Γ, x0,Xm)

where:X is the set of statesE is the finite set of events associated with Gf : X × E → X is the transition function: f(x, e) = y means that there is a transitionlabeled by event e from state x to state y; in general, f is a partial function on itsdomainΓ : X → 2E is the active event function (or feasible event function); Γ(x) is the set ofall events e for which f(x, e) is defined and it is called the active event set (or feasibleevent set) of G at xx0 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 h ysica lS ys tem

P la nn ed ta sk s

S ch ed u led ta sk s

T ask s

Shop Floor Controller Structure

ProductionR equirem ents

C ontro lle r

PhysicalSystem

I/O C h a nn e ls

P lanner S che dule r Ex ecuto r

TaskL ist

I/O C h ann el

Syste m M o de l

PhysicalM odel

SystemSta tus

PhysicalConfiguration

Gate House

1 2 3

Dock 3

Yard ExampleWe 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

QQQ

QFQq

Q

FqQ

MPSG for Generic MP Equipment

assign _w e t_ass ign @ loc_ew

@ loc_ns_ew

grasp_ we t_grasp grasp_ok_ew clear_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_sta rt

t_dn ld

d one_ew

7 8 9 10

re lea se_ok_ew@ loc_ew

@ loc_ns_ew

clear_ok_w erem 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)

Equipment Controllers

SL-20Hass VF 0E

M1 ABB 240

AGVSKardex

TaskOutput Queue

Database Scheduler

TaskInput Queue

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