Download presentation

Published byDane Jenny Modified over 3 years ago

1
**Using Finite State Automata to Model Manufacturing Systems**

R. Wysk

2
**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

3
**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

4
How about Starbucks?

5
**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

6
**Examples - chess Model with respect to one piece**

Model with respect to one color Model with respect to all pieces

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

8
How about our machine?

9
**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

10
**How about driving to Crabtree Valley Mall?**

11
**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

12
**Part Flow Through the Shop**

13
**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

14
**Physical Model - Processing Workstation**

15
**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

16
**Some Observations about this Perspective**

Generic -- applies to any system Other application specifics Parts Number Routing Buffers (none in our system)

17
**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

18
**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

19
The Graph looks like x y z

20
**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?

21
**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.

22
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.

23
**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

24
**Shop Floor Controller Structure**

25
**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

26
**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

27
**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

28
**Some things not considered**

Queue discipline FIFO, SPT, … Rules for assigning trucks to docks Due date, SPT, …

30
**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

31
**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

34
**Some Observations about this Perspective**

Generic -- applies to any discrete system Other application specifics Parts Number Routing Buffers (none in our system)

35
**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:

36
**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 I O T Robots Index R 1 Stations Index AS 1 M1 2 M2 3 M3 4 Blocking attributes are set to 1: must be blocked M1

37
**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

38
**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.

39
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.

40
MPSG Definition

41
**MPSG for Generic MP Equipment**

42
**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.

43
**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

44
**Equipment-level Device Interaction**

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

45
**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

46
**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

Similar presentations

OK

Ch. 2. Specification and Modeling 2.1 Requirements Describe requirements and approaches for specifying and modeling embedded systems. Specification for.

Ch. 2. Specification and Modeling 2.1 Requirements Describe requirements and approaches for specifying and modeling embedded systems. Specification for.

© 2018 SlidePlayer.com Inc.

All rights reserved.

To make this website work, we log user data and share it with processors. To use this website, you must agree to our Privacy Policy, including cookie policy.

Ads by Google