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

QQ

QF

Qq

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