Presentation on theme: "Using Finite State Automata to Model Manufacturing Systems R. Wysk."— Presentation transcript:
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 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 Task Number Task Name 1Pick L 2Put M1 3Process 1 4Pick M1 5Put M2 6Process 2 7Pick M2 8Put UL Machine 1 M1 Machine 2 M2 R L UL
Physical Model - Processing Workstation Process
Resource Acquisition: Simulation for Real-time Control MH tasks are represented explicitly like MP tasks Resource management is significantly complex Task Number Task Name M1M2R 1Pick L 2Put M1 3Process 1 4Pick M1 5Put M2 6Process 2 7Pick M2 8Put U
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 – q 0 –Event transitions – F(X 1, e) = X 2
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, Γ, x 0,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 → 2 E 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 x 0 is the initial state X m ⊆ 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 2 X ; 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
Gate House 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, Dock i ) E(Depart/Balk, Gate_serve,Travel i, 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
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:
Generated FSA Execution model -- based on the rules, but manual yet R M2M2 M3M3 ASAS 1 Due to limited space, these two arrows are expanded in this figure IIOI II O O IOIO IOIO T Robots Index R1 Stations Index AS1 M12 M23 M34 Blocking attributes are set to 1: must be blocked M1M1
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
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.
Equipment-level Device Interaction robot clear execute program to close fixture fixture closed execute part program clear to load part ? execute program to load part close 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_sbremove_kardex_sbpick_ns_sb return_sb put_sb move_to_mach_sb move_to_kardex_sb put_ns_sb move_to_mach_sb process_sb pick_sb 7 89 return_sb