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 Discrete (DES) 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 3 4 5 6 7 1 Machine 1 M1 Machine 2 M2 R 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

Finite state view to Illustrate Control Simulation Requirements 8 2 3 4 5 6 7 1 Machine 1 M1 Machine 2 M2 R L UL Task Number Name 1 Pick L 2 Put M1 3 Process 1 4 Pick M1 5 Put M2 6 Process 2 7 Pick M2 8 Put UL

Physical Model - Processing Workstation

Resource Acquisition: Simulation for Real-time Control Task Number Name M1 M2 R 1 Pick L Ö 2 Put M1 3 Process 1 4 Pick M1 5 Put M2 6 Process 2 7 Pick M2 8 Put U MH tasks are represented explicitly like MP tasks Resource management is significantly complex

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 Scheduling Sequencing planned tasks Execution Performing the scheduled tasks at the appropriate time

Shop Floor Controller Structure

We can treat the Gate House as the “material handler” Yard Example We can treat the Gate House as the “material handler” 3 1 2 Queue of trucks Gate House Dock 3

System Model for the 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 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

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 1 R M2 M3 AS 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 O at_loc@1_bs pick_ns#1@1_br mv_to_asrs@1_sb arrive@1_bk arrive_ok@1_kb loc_ok@1_bs put_ns#1@1_sb put_ns#1@1_br clear_ok#1@1_rb put_ok#1@1_bs T delete@1 Robots Index R 1 Stations Index AS 1 M1 2 M2 3 M3 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.

Mealy Machine 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.

MPSG Definition

MPSG for Generic MP Equipment

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-20 Hass VF 0E M1 ABB 240 AGVS Kardex Task Output Queue Database Scheduler Input Queue ABB 140

Equipment-level Device Interaction b t c l e a x u p g m s f i d ? n v w y _

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 return_sb move_to_mach_sb 7 move_to_kardex_sb 6 put_sb 5 move_to_mach_sb 4 put_ns_sb process_sb pick_sb 8 return_sb 9