- Email: [email protected]
Modular finite state machines for logic control
ELSEVIER
Copyright © IFAC Discrete Event Systems, Reims, France. 2004
IFAC PUBLICATIONS www.eisevier.com/locateiifac
MODULAR FINITE STATE MACHINES FOR LOGIC CONTROL E. W. EndsIey and D. M. Tilbury
Depa rtment of Mechanica l Engineering University of Mi chigan. Ann Arbor. Ml48J 09-2125 {ericend,tilbury}@umich.edu
Abstract: This paper presents a framework developed for logic control of manufacturing systems based on finIte state machmes. The framework is modular; FSMs are encapsulated mto modules with well-defined communication between them. Events in the finite state machines are of two types, triggers and responses, allowing FSMs to react to and to force events to occur. A simple example is presented to illu strate the theory, and the apphcatIOn of the framework to two manufacturing system testbeds is described. Copyright © 2004 IFAC Keywords: Logic control. finite state machines.
I.
I NTROD UCTIO~
AND BACKGROUND
Both Finite State Machines (FSMs) and Petri nets have been proposed as a way to create and verifv large logic control programs. FSMs are the basis o'f the supervisory control theory developed by Ramadge and Won ham (1989). While a few examples of using supervi sory control on manufac turing systems exist in the literature (Brandin , 1996; Lauzon et al. , 1995). there are several reasons why it is unlikel v tha t its use will become widespread . Because a supervisory controller works by preventing events from occurring, additional constructs such as forced eve nts need to be added to have the controllers cause an event to occur. The method requires detailed mathemati cal descriptions of the system and the de si red behavior. but the creati on of these descriptions may not be sign ificantly easier or less error-prone th an the direct creation of the control logic. Lastly, the computations required for synthesizing a controller for a large manufacturing system are likely to encounter complexity issues.
Medium and high volume manufacturing has traditionally been accomplished by large-scal~ dedicated system s with thousands of inputs and outputs. Their log ic controllers mu st handle sequences of operations, synchroni zation between components, error detection and recovery. as well as safety. Gen erally no model of the machining system is created for the purpose of control design. Additionally, the languages traditionally used to write the log ic control do not lend themselves to analytic verifi~ation . As a result. the primary method for finding errors in the logic control is to run the controller on the actual system. While improvemen ts to the process of creating logic control wo uld always have had economic benefits, changes in the state of man ufacturing are making the se improvements critical. Market pressures are driving the viable life of a product design and its manufac~ lUring system down to the range of 3 to 5 years. In response to these changes, reconfigurable manufacturing systems (Koren et aI. , 1999) are being devel oped to allow manufacturers to keep up with c~nsumer demands while sti ll spreading the ini tial cost of the man ufacturing system over a large number of parts. Current logic control programming practice is an impediment to the creation of reconfigurable manufacturing systems.
Statecharts. proposed by Harel (1987) , introduce hierarchy to FSM s. Statecharts are good at describing the behavior of complex systems in a compact form. Like Petri nets they handle concurrency well. The complexity of the execution semantics make s verification of statecharts difficult, nonetheless some work has been done in this area (Damm et al.. 1997: Rausch and Krogh, 1998). These works generally employ some limited or constrained semantics of statecharts.
393
2. MODULAR FINITE STATE MACHINES This paper describes a new framework that we have developed for logic control called Modular Finite State Machines or MFSMs. ;-'1FSMs are a type of discrete event system: they react to and generate events. The framework is an extension of FSMs, with modularity and forced events, and allows for modular verification of the resulting logic controller (EndsJey, 2004). Although the framework is related to many previously-defined frameworks based on FSMs, it has several important differences. In the classical Ramadge-Wonham supervisory control, the supervisor merely disables events, whereas in MFSMs the controller forces events to occur. This style of inputoutput FSMs (Mealy machines) are used in communicating FSMs (Brand and Zafiropulo, 1983), although there communication of events between subsystems is asynchronous whereas MFSM modules synchronize on the occurrance of events. Balemi (1994) also used input-output FSMs but only considered two modules (the plant and the controller); MFSMs allow for an arbitrary number of modules to be combined in a single system. In contrast to classical supervisory control, the design and verification of a controller using MFSMs does not require that a detailed model of the plant be available. MFSMs are most similar to Statecharts in that there can be mUltiple events labeling a single transition , indicating that when an event occurs and a transition is taken, one or more events are forced to occur at the same time. The above-mentioned frameworks based on FSMs would break such transitions into multiple transitions , each with one event. Although the resulting FSM will generate the same language for a single FSM , the behavior is very different when multiple FSMs are combined. The key difference between MFSMs and Statecharts is that all communication of events between modules is specified using ports and filters; this precise specification allows for the modular verification of their global behavior. 2.1 Trigger / Response Finite State Machines
turing systems, we structure the controller as a system of interacting TR FSMs, with each one controlling a portion of the system. To further aid in the creation of these large systems, we will employ several techniques from current general purpose programming practices. We will encapsulate the TR FSMs into modules. On a module, we will gather the events which communicate with other modules into sockets. Then we will define interfaces which specify the communication between modules. We will call these interfaces filters. The primary purpose of a module is to hold a TR FSM and to indicate the source of trigger events and the destination of response events. Each event of the TR FSM is associated with a connection point called a socket. For example, the User module shown in Fig. 2 has two sockets. Socket 1 has rise and fall as triggers entering the module and no responses leaving the module; socket 2 has done as a trigger, and start and stop as responses. Events in the TR FSM are labeled with a name and socket number.
ot
User 1 ri se 12. star \
~
~ 1.~ a ll i
2.slop 2.done
(do ne)
t
I {sta rt.
stop)
Fig. 2. A TR FSM encapsulated into the User module.
FSMs called filters are interfaces, or specifications, on the communication between modules. Filters play an important role in the design of MFSM systems, as they allow the designer to focus on the behavior of a particular module without having to be concerned with the details of other modules in the system. Filters encapsulate a TR FSM which has no responses , see Fig. 3. As filters are intended to be placed on the connection between two modules , they have two sockets , arbitrarily called a and b. I
fall .' stop done
• (rise. tall)
start
Filter I
:~
Fig. I. A simple TR FSM. The logic of how a particular MFSM behaves is defined by Trigger I Response Finite State Machines (TR FSMs). A TR FSM is always in one of a finite number of defined states. When a TR FSM wimesses an event, it reacts by changing state and/or generating other events as determined by its current state. The events that the TR FSM reacts to are called triggers and the events that it generates are called responses. On a transtion label, the trigger is the event before the slash and the responses are after the slash , see Fig. I. 2.2 System of MFSMs
I
a~
\
done aL \ star1. stop )
I )
b ",,{done}
Fig. 3. A typical filter. There are several steps in creating an MFSM system. (1) Create the Structure, determining the number of modules and points of communication. (2 ) Create the Filters specifying the communication between modules and with the plant. (3) Create the Modules, defining the logical behavior of the system. (4) Assemble the System , and verify.
TR FSMs work well for defining small pieces of logic. To deal with the complexity found in large manufac-
394
This procedure possesses several characteristics of good programming practice. It is a top-down style of programming where the overall system architecture is designed first. A specification, in the form of the filters, is created for each module , and this specification is created at the beginning of the design .
-
a"-; i) a . D-: {t'~ ~l -
2.3 Example of Designing a System Before delving into the formal definitions of MFSMs , we will give an extended example illustrating how MFSMs can be used to construct a logic controller. The plant in this example consists of a push-button and light. The desired behavior of the plant is that the light will turn on when the button is depressed, and turn off after a timer expires or when the button is released, whichever comes first.
c \ . c .,
~:"~ ( C . 2or
C.3s:.J.r:
JsCB
C J oon.
C , 50:00 ' C.2
C300 ... .
ot'
C20~ . C
1 (JOI'I.
I~
T,mer
Ligh t
-
-
1
.
1
- -
Tooo.... i;-~~Mi r-;-·iOon;j
I
-
.-/
'-
'--
I T.,Istar:
Fig . 5. The complete system.
I
Bunon
- -
T.;. ......art
~ ~ I ~ I
The system interacts with 3 external components: the button . the light, and a timer. We will have 2 modules, a User module and a Controller module. The User module interacts with the button . and the Controller module interacts with the light and the timer. The resulting skeleton system is shown in Fig. 4.
'-
-1 ________ " Tim er IT
- -
module to tran sition to the Working state and generate the response start. This start passes into the Controller module through the filter Filter. In the process, it causes Filter to transition to the Working state. The Controller module reacts to start by transitioning to the Working state and generating on and start. The on event leaves the system through the Light filter causing it to transition to the on state. The start leaves the system through the Timer filter. causing it to transition to the running state.
I .-/
I ../
Fig. 4. The system structure.
3. MATHEMATICAL DEFINITIOf\'S FOR MFSMS
We will begin by creating a filter on the communication between the User and the Controller module. This filter (shown in Fig. 3) has two states. From the Idle state the only thing that can happen is that the User module will tell the Controller to start. From the Working state the User can tell the Controller to stop or the Controller can tell the User module that it is done. The Button , Light and Timer filters represent communication with the environment and can be seen in Fig. 5.
Before defining the exact behavior of a MFSM system , we give formal definitions for a MFSM sys tem and its components.
Definition 1. (Trigger / Response Transition). A trigger / response transition determines when and how a change of state occurs in a trigger / response FSM . The transition T = (t ~. Xs_ . Xd. , T,) consists of a trigger t" a source state X s _, a destination state Xd_ , and a sequence of responses produced when the transition OccurST.,. = [T~.l ' .. T,.m. ].
To create the TR FSM for the User module , we consider that we want it to send start to the Controller module when the button is depressed , and to send stop to Controller if the button is released before the Controller sends the done event. see Fig. 2.
Definition 2. (Trigger / Re sponse FSM). A trigger / respon se FSYI observes trigger events and produces response events. The FSM F consists of a set of states XF , a set of triggers TF, a se t of responses R F , a set of transitions T F , an identification of the initial state xo F ' an identification of the dump state XdPF and a set of marked states X M F' The FSM cannot have responses that trigger events within itself, T F n RF = 0, and further, there mu st be no transitions out of the dump state . To ensure determini stic behavior of the FSM , there can be at most one transition for each combination of trigger and source state (L xs ).
The way in which all of the elements of this system work together can be seen by tracing an event and the chain of respon ses that it generates through the system. The initial state of the system has all of the modules and filters in their initial state. From this state the only trigger which can enter the system is rise from the Button filter. Thi s event causes Button to transition to the high state. It also causes the User
395
The dump state indicates that the TR FSM is in a terminal state , and that it is no longer able to process events. Transitions to the dump state are not usually included by design; they are used to identify errors that occurred in the creation of the composition of TR FSMs as defined in Definition 8. Within a module or filter, events are bundled into defined connection points which we call sockets. We will commonly use the same letter to refer to both a module and the TR FSM within the module. We will use bold font for the modules (e.g. M) and italicized font for the TR FSMs (e.g. lvI). The same convention is used for filters and their TR FS~s.
Definition 3. (Socket). A socket bundles events of a module together for connection to another module. The socket S .w, consists of a set of triggers T M , and a set of re sponses R M , .
To ensure that the system is well posed, we require that: (l) the pipes must connect to sockets of modules within the system; (2) the filters on the pipes must be in the system; (3) if a pipe connects two modules then the responses of one module must be a subset of the triggers of the other; (4) an event cannot be a trigger in more than one module, nor can it be a response in more than one module ; (5) if an event is a trigger in one module and a response in another, then it is part of a pipe between those modules ; (6) every filter is associated with exactly one pipe ; (7) if a pipe has both a filter and a module at its a socket, then the re sponses of the module socket must be a subset of the triggers of the filter ' s a socket, and the triggers of the filter's b socket must be a subset of the triggers of the module socket, and similarly for the b socket. The general concept for the behavior of a system of communicating modules of MFSMs is that respon ses from one module travel to another module, triggering transitions and possi bly generating responses there. Due to space constraints a condensed version of the composition algorithm is given here . A more detailed and precise version can be found in (Endsley , 2004).
Definition 4. (Mod ule) . A module encapsulates a TR FSM for use within a system. The module M consists of a TR FSM and a set of sockets which can be connected to other modules. Every trigger in the FSM must be a trigger in exactly one of the sockets , and every trigger in a socket must be a trigger in the FSM. Eve ry response in a socket must be a response in the FSM. It is permissable for the TR FSM to have internal responses which do not appear in a socket, but a response cannot appear in more than one socket.
Definition 8. (Composition of TR FSMs). The composition of TR FSMs FI ... F n , denoted FIll· .liFn, is another TR FSM F l li lln ' Let each FSM Fi = (XF" T F" RF" TF" xO F , XdPF , X MF ) . Then the composi tion is defined as Fl i~. ':n v.: here th~ respon ses are the union of all re sponses, the triggers are the union of the triggers minus the respon ses. and the initial and dump states are the direct product of the initial and dump states of each F i . The set of states X F, 11 In and the set of transitions TF' ll iln are constructed by the composition algorithm on the following page .
Definition 5. (Filter). A filter encapsulates a TF FSM for specifying communication into and out of modules. The filter F consists of a TR FSM and two sockets, SF a and SF o ' Every trigger in the FSM must be a trigger in exactly one of th e sockets , and every trigger in a socket must be a trigger in the FSM . The set of respon ses is empty.
While Definition 8 defines the composition of TR FSM s, we desire slightly different behavior when we compose a MFSM system consisting of modules and filters. We want it to be an error if the filters allow a trigger to occur, but a module does not. Thi s can be accomplished by modifying Step 3 to also create a transition for each trigger t of the composition for which there exi sts a transition triggered by t from the current state of every filter that has that t as a trigger, regardless of the modules . Errors of th is type will appear as disabled re sponses in Step 5.
\'ow that we have defined the components of a MFSM system , we can define how these components are connected to form a system. We first define pipes which are the explicit connection between modules and filters, and then proceed to define MFSM systems.
Definition 6. (Pipe ). A pipe is a linking between objects of a system . The pipe P = (SPa' S P o ' F p ) connects a socket on one module to a socket on another and identifies a filter for the connection.
A MFSM system can be composed into a single module by performing the composition of the TR FSMs contained within the modules and filters . The resulting si ngle module also contains copies of the sockets which are on the perimeter of the system.
There are 4 variations of pipes: connecting 2 modules and identifying a filter, connecting 2 modules without declaring a filter. connecting a filter with SPa but not connecting to another module, and connecting a filter with Sp, but not connecting to another module.
Definition 9. (System Composition ). The modulepossessing the same behavior as a S is ::'1.-15 = (Ms , S.\ls ) where .'vis is the composition of the modules and filters of the system , and SM are copies of the sockets on the perimeter of the sys tem.
Definition 7. (System of Modules). A system of modules S = (/vl 5 , Fs , Ps ) consists of a set of mod{M1 .... , M n.v.}, a set of filters ules .I'V1s Fs = {F 1, .... F nF } , and a set of pipes Ps = {PI, ... , Pnp } connecting those modules and filters.
Fig. 6 shows the results of combining the system seen in Fig . 5 into a single module. The presence of a
396
transition to the dump state indicates that there is an error in the logic that should be corrected before the system is implemented.
TR FSM Composition Algorithm (l) Add the dump state and initial state to the set of states XF' ll l n ' Add the initial state to the queue of states to process Q s . (2) Remove
Xs
from the queue
Qs'
(3) Create a transition Tn for each trigger t of the composition for which there exists a transition triggered by t from the current state X s , of every TR FS!'v1 that has that t as a trigger. The source of the transition is x s , and the trigger is t. The response and the destination state are found with the following loop , which is initialized with an empty event queue Qr and by setting the current event er = t and current state Xc
Fig . 6. The system combined into a single module. 4. IMPLEMENTATIOr\ EXAMPLES A concemthroughout the creation of MFSMs was that they be of practical use in creating logic control for manufacturing systems. To that end we developed a set of software tools (Endsley et al. , 2000; Endsley , 2004) to create , verify and run MFSMs. We have also used those tools to create logic controllers for several manufacturing system testbeds. Fig. 7(a) shows the first testbed that we controlled using MFSMs. All control of the system is done through digital signals. The system has 14 bits of input and 15 bits of output; the machine could be in one of 5 ,038.848 states, not including the states of the parts.
= (xc,,· ·· , XCn) = xs·
(4) If an infinite response is detected , set the current state Xc to the dump state Xdp F ' clear the respon ses r 7"y, of the l. [···lIn
transition and skip to Step 8. (5) If there exists a TR FSM F, for which er is a trigger, but there is not a transition triggered by er from the current state xc, of that TR FSM , or the destination of such a transition is the dump state, then there is a disabled response. Set the current state Xc to the dump state. clear the responses of the transition and skip to Step 8. (6) For each TR FSM Fi for which this event is a trigger, follow the transition for this event, updating the current state xc. of that TR FSM , and adding the respon ses of that transition to the event queue Qr. If the queue and the response of the transition do not have the same events in the same order up to the length of the shorter of the two, there are conflicting responses . Set the current state Xc to the dump state XdPF ' clear th e rel l! · · · iln
sponses r 7" n of the transition and skip to Step 8. If there is no conflict and the transition's response is longer, add the extra events onto the end of the queue.
(b) MFSM Controller Structure Fig . 7. The MSFM for the linear testbed .
(7) If the queue Qr is not empty, remove the next event from the queue and set er to it, add it to the response of the transition r' n and return to Step 4.
The structure chosen for the MFS~ controller, shown in Fig. 7(b), has 4 main subsystems: one for each station , and one for coordination. The controller for each station was created, verified and tested in isolation. demonstrating the localized design capabilities of MFSMs. Instead of a single module for coordination , a subsystem consisting of several modules was used . The resulting subsystem has the benefit that it could be adapted for a linear testbed with n stations by simply repeating one of the modules n times. The controller for this system consisted of 20 modules , but only 13 of these were unique. The transfer conveyor was used 3 times, the linear slide 4 times , and the conveyor coordinator 3 times. This demonstrates a fair amount of code reuse within this project. We have
(8) Set the destination Xd _ of the new transition to the current state Xc . If the current state is not in the set of states X F' iI 'ln' add it to the set of states and to the state queue Qs. (9) If there are more triggers to proce ss for this state return to Step 3. (l0) If Q s is not empty skip to Step 2.
397
explored code reuse and reconfiguration within this testbed (Shah et aI., 2002) and for a different, rotary testbed (Pollice et aI., 2002). Currently we are using MFSMs to create cell level control for portions of the Reconfigurable Factory Testbed at the University of Michigan (Almeida and Tilbury, 2004) 5. CONCLUSIONS AND DISCUSSION While MFSMs share characteristics with other frameworks, the particular combination of characteristics that MFSMs possess makes them unique. MFSMs are inherently modular and interactions between the modules are identified explicitly through pipes. The modules can be used as peers or in a multi-level hierarchy. There is no requirement that certain modules be subordinate to others. Modules can react to trigger events by generating response events, and a system of MFSMs will resolve this chain of responses before considering new input from the environment. The acceptable communication between modules can be explicitly defined using filters, allowing localized design, localized verification and code reuse. It is considered a design error when one module sends an event to a second module when the second module is in a state where it has no transition defined for that event. Like any other framework, MFSMs have their strengths and weaknesses. Areas where MFSMs are strong include modularity, reconfigurability, verification, and execution. The modularity of MFSMs makes them suitable for creating logic control for large systems and enhances code reuse. The modular structure with filters also allows for the design of logic control that can be easily reconfigured when a manufacturing system is reconfigured. Because MFSMs are based on FSMs, verification tools can be easily applied to them. The modularity of MFSMs holds the key to enabling verification of the logic control of very large systems. And finally, as was found in the creation of our software tools, the semantics of MFSMs is directly executable. There is no need to resort to disabling or forcing events. Areas where MFSMs are weak include concurrency and compactness. In creating the logic controllers for our testbeds, we learned that it is cumbersome to represent concurrency within a single module or filter. This is because a module or filter contains a single FSM , which does not represent concurrency well. A study on logic control methodologies (Lucas and Tilbury, 2003) showed that a logic controller written in MFSMs was 'larger' than controllers with the same functionality written in ladder diagram or Petri nets. One of the primary reasons for creating MFSMs was to enable the verification of large logic controllers. While this paper does not present any results on verification. we have made progress in this area. With the help of Trigger / Response Languages , we have created a procedure for verifying the absence of conflicting and disabled responses within a MFSM system (Endsley, 2004). Significantly, this procedure is based on constructing the composition of a module with its surrounding filters. not constructing the composition of the entire system. While the state space of the
398
composition of the module with its filters grows exponentially with the number of filters that the module communicates through, a good design should keep the number of connections to a single module small. Therefore, this composition does not fail due to state explosion , and the check can easily be applied to each module in the system. This procedure allows for the verification of those two properties in very large systems. We are hopeful that other procedures can be created for the modular verification of additional properties of MFSM systems. Acknowledgements This research was supported in part by the NSFERC for Reconfigurable Manufacturing Systems under grant EEC95-92125. The authors would also like to thank the anonymous reviewers for their helpful comments : REFERENCES E. Almeida and D. M. Ti lbury. Automatic logic generation for reconfigurable cell-based manufacturing systems. In Proceedings of the IFAC Workshop on D,screte Event Systems (WODES). Reims. September 2004. S. Balemi. Input / output discrete event processes and communication delays. Journal of Discrete Event Dynamic Systems: Theory and Applications. 4:41 - 85.1994. D. Brand and P. Zafiropulo. On communcating finite-state machines. Journal of the ACM. 30(2):323-342. April 1983. B. A. Brandin. Error-recovering supervisory control of automated manufacturing systems. Integrated Computer-Aided Engineering. 3(4):255 - 267 , 1996. W. Damm. B. Josko. H. Hungar. and A. Pnueli. A compositional real-time semantics of statemate designs. In Proceeding s of COMPOS. pages 186 - 238. 1997. E. W. Ends ley. Modular Finite State Machmes for Logic Control: Theory. VerificatIOn and Applications to Reconfigurahle ManuJacturIng Systems. PhD thesis. University of \1ichigan. Ann Arbor. Ml. May 2004. E. W. Endsley. M. R. Lucas. and D. M. Tilbury. Software tools for veri fication of modular FSM based logic concrol for use in reconfigurable machine tools. In Proceedmgs oJ the Japanu.s.A. SymposIUm on Flexihle Automation. Ann Arbor. 2000. D. Hare!. Statecharts: A visual formalizauon for complex systems. Science ofCompter Programmmg. 8(3):231 - 274. 1987. Y. Koren. u. Heise!. F Jovane. T. Moriwaki. G. Pritschow. G. Ulsoy. and H Van Brussel. Reconfigurable manufacturing systems. In CIRP Annals. vol ume 2. pages 6-12. November 1999. Keynote Paper. S. C. Lauzon. A. K. L. Ma. J. K. Mills. and B. Benhabib. Implementing a discrete-event-system-based supervisory controller for a flexible manufacturing workcell. In Proceedmgs oJ the 1995 IEEE Interna tional Conference on Robotics and Automation. volume 2. pages 1429 - 1434. IEEE. May 1995. M. R. Lucas and D. M. Tilbury. Comparing indu scrial logic design methods used in the automotive industry. In Proceedings oJ the IEEE Internationa l Conference on Systems. Man . and Cybernetics. pages 530 - 537. Washington. DC. October 2003. S. L. Polilce. E. W. Endsley. and D. M. Tilbury. Logic concrol using modular FSMs: An evaluation of code re-use. In Proceedings oJ the 2nd IFAC Conference on Mechatronic Systems. 2002. P. J. G. Ramad;e and W. M. Wonham. The concrol of discrete event systems. Proceedings DJ the IEEE. 77( 1):81 - 98. January 1989. \1. Rau sch and B. H. Krogh. Symbolic verification of stateftow logic. In Proceeding s oJ the IFAC Workshop on Discrete Event Systems (WO DES). Cagliari. 1998. S. S Shah. E. W. Ends ley. M. R. Lucas. and D. M. Tilbury. Reconfigurable logic control using modular FSMs: Design. verifi cation. implementation. and integrated error handling. In Proceedrngs oJ the AmerIcan Control Conference. 2002.
Copyright © IFAC Discrete Event Systems, Reims, France. 2004
IFAC PUBLICATIONS www.eisevier.com/locateiifac
MODULAR FINITE STATE MACHINES FOR LOGIC CONTROL E. W. EndsIey and D. M. Tilbury
Depa rtment of Mechanica l Engineering University of Mi chigan. Ann Arbor. Ml48J 09-2125 {ericend,tilbury}@umich.edu
Abstract: This paper presents a framework developed for logic control of manufacturing systems based on finIte state machmes. The framework is modular; FSMs are encapsulated mto modules with well-defined communication between them. Events in the finite state machines are of two types, triggers and responses, allowing FSMs to react to and to force events to occur. A simple example is presented to illu strate the theory, and the apphcatIOn of the framework to two manufacturing system testbeds is described. Copyright © 2004 IFAC Keywords: Logic control. finite state machines.
I.
I NTROD UCTIO~
AND BACKGROUND
Both Finite State Machines (FSMs) and Petri nets have been proposed as a way to create and verifv large logic control programs. FSMs are the basis o'f the supervisory control theory developed by Ramadge and Won ham (1989). While a few examples of using supervi sory control on manufac turing systems exist in the literature (Brandin , 1996; Lauzon et al. , 1995). there are several reasons why it is unlikel v tha t its use will become widespread . Because a supervisory controller works by preventing events from occurring, additional constructs such as forced eve nts need to be added to have the controllers cause an event to occur. The method requires detailed mathemati cal descriptions of the system and the de si red behavior. but the creati on of these descriptions may not be sign ificantly easier or less error-prone th an the direct creation of the control logic. Lastly, the computations required for synthesizing a controller for a large manufacturing system are likely to encounter complexity issues.
Medium and high volume manufacturing has traditionally been accomplished by large-scal~ dedicated system s with thousands of inputs and outputs. Their log ic controllers mu st handle sequences of operations, synchroni zation between components, error detection and recovery. as well as safety. Gen erally no model of the machining system is created for the purpose of control design. Additionally, the languages traditionally used to write the log ic control do not lend themselves to analytic verifi~ation . As a result. the primary method for finding errors in the logic control is to run the controller on the actual system. While improvemen ts to the process of creating logic control wo uld always have had economic benefits, changes in the state of man ufacturing are making the se improvements critical. Market pressures are driving the viable life of a product design and its manufac~ lUring system down to the range of 3 to 5 years. In response to these changes, reconfigurable manufacturing systems (Koren et aI. , 1999) are being devel oped to allow manufacturers to keep up with c~nsumer demands while sti ll spreading the ini tial cost of the man ufacturing system over a large number of parts. Current logic control programming practice is an impediment to the creation of reconfigurable manufacturing systems.
Statecharts. proposed by Harel (1987) , introduce hierarchy to FSM s. Statecharts are good at describing the behavior of complex systems in a compact form. Like Petri nets they handle concurrency well. The complexity of the execution semantics make s verification of statecharts difficult, nonetheless some work has been done in this area (Damm et al.. 1997: Rausch and Krogh, 1998). These works generally employ some limited or constrained semantics of statecharts.
393
2. MODULAR FINITE STATE MACHINES This paper describes a new framework that we have developed for logic control called Modular Finite State Machines or MFSMs. ;-'1FSMs are a type of discrete event system: they react to and generate events. The framework is an extension of FSMs, with modularity and forced events, and allows for modular verification of the resulting logic controller (EndsJey, 2004). Although the framework is related to many previously-defined frameworks based on FSMs, it has several important differences. In the classical Ramadge-Wonham supervisory control, the supervisor merely disables events, whereas in MFSMs the controller forces events to occur. This style of inputoutput FSMs (Mealy machines) are used in communicating FSMs (Brand and Zafiropulo, 1983), although there communication of events between subsystems is asynchronous whereas MFSM modules synchronize on the occurrance of events. Balemi (1994) also used input-output FSMs but only considered two modules (the plant and the controller); MFSMs allow for an arbitrary number of modules to be combined in a single system. In contrast to classical supervisory control, the design and verification of a controller using MFSMs does not require that a detailed model of the plant be available. MFSMs are most similar to Statecharts in that there can be mUltiple events labeling a single transition , indicating that when an event occurs and a transition is taken, one or more events are forced to occur at the same time. The above-mentioned frameworks based on FSMs would break such transitions into multiple transitions , each with one event. Although the resulting FSM will generate the same language for a single FSM , the behavior is very different when multiple FSMs are combined. The key difference between MFSMs and Statecharts is that all communication of events between modules is specified using ports and filters; this precise specification allows for the modular verification of their global behavior. 2.1 Trigger / Response Finite State Machines
turing systems, we structure the controller as a system of interacting TR FSMs, with each one controlling a portion of the system. To further aid in the creation of these large systems, we will employ several techniques from current general purpose programming practices. We will encapsulate the TR FSMs into modules. On a module, we will gather the events which communicate with other modules into sockets. Then we will define interfaces which specify the communication between modules. We will call these interfaces filters. The primary purpose of a module is to hold a TR FSM and to indicate the source of trigger events and the destination of response events. Each event of the TR FSM is associated with a connection point called a socket. For example, the User module shown in Fig. 2 has two sockets. Socket 1 has rise and fall as triggers entering the module and no responses leaving the module; socket 2 has done as a trigger, and start and stop as responses. Events in the TR FSM are labeled with a name and socket number.
ot
User 1 ri se 12. star \
~
~ 1.~ a ll i
2.slop 2.done
(do ne)
t
I {sta rt.
stop)
Fig. 2. A TR FSM encapsulated into the User module.
FSMs called filters are interfaces, or specifications, on the communication between modules. Filters play an important role in the design of MFSM systems, as they allow the designer to focus on the behavior of a particular module without having to be concerned with the details of other modules in the system. Filters encapsulate a TR FSM which has no responses , see Fig. 3. As filters are intended to be placed on the connection between two modules , they have two sockets , arbitrarily called a and b. I
fall .' stop done
• (rise. tall)
start
Filter I
:~
Fig. I. A simple TR FSM. The logic of how a particular MFSM behaves is defined by Trigger I Response Finite State Machines (TR FSMs). A TR FSM is always in one of a finite number of defined states. When a TR FSM wimesses an event, it reacts by changing state and/or generating other events as determined by its current state. The events that the TR FSM reacts to are called triggers and the events that it generates are called responses. On a transtion label, the trigger is the event before the slash and the responses are after the slash , see Fig. I. 2.2 System of MFSMs
I
a~
\
done aL \ star1. stop )
I )
b ",,{done}
Fig. 3. A typical filter. There are several steps in creating an MFSM system. (1) Create the Structure, determining the number of modules and points of communication. (2 ) Create the Filters specifying the communication between modules and with the plant. (3) Create the Modules, defining the logical behavior of the system. (4) Assemble the System , and verify.
TR FSMs work well for defining small pieces of logic. To deal with the complexity found in large manufac-
394
This procedure possesses several characteristics of good programming practice. It is a top-down style of programming where the overall system architecture is designed first. A specification, in the form of the filters, is created for each module , and this specification is created at the beginning of the design .
-
a"-; i) a . D-: {t'~ ~l -
2.3 Example of Designing a System Before delving into the formal definitions of MFSMs , we will give an extended example illustrating how MFSMs can be used to construct a logic controller. The plant in this example consists of a push-button and light. The desired behavior of the plant is that the light will turn on when the button is depressed, and turn off after a timer expires or when the button is released, whichever comes first.
c \ . c .,
~:"~ ( C . 2or
C.3s:.J.r:
JsCB
C J oon.
C , 50:00 ' C.2
C300 ... .
ot'
C20~ . C
1 (JOI'I.
I~
T,mer
Ligh t
-
-
1
.
1
- -
Tooo.... i;-~~Mi r-;-·iOon;j
I
-
.-/
'-
'--
I T.,Istar:
Fig . 5. The complete system.
I
Bunon
- -
T.;. ......art
~ ~ I ~ I
The system interacts with 3 external components: the button . the light, and a timer. We will have 2 modules, a User module and a Controller module. The User module interacts with the button . and the Controller module interacts with the light and the timer. The resulting skeleton system is shown in Fig. 4.
'-
-1 ________ " Tim er IT
- -
module to tran sition to the Working state and generate the response start. This start passes into the Controller module through the filter Filter. In the process, it causes Filter to transition to the Working state. The Controller module reacts to start by transitioning to the Working state and generating on and start. The on event leaves the system through the Light filter causing it to transition to the on state. The start leaves the system through the Timer filter. causing it to transition to the running state.
I .-/
I ../
Fig. 4. The system structure.
3. MATHEMATICAL DEFINITIOf\'S FOR MFSMS
We will begin by creating a filter on the communication between the User and the Controller module. This filter (shown in Fig. 3) has two states. From the Idle state the only thing that can happen is that the User module will tell the Controller to start. From the Working state the User can tell the Controller to stop or the Controller can tell the User module that it is done. The Button , Light and Timer filters represent communication with the environment and can be seen in Fig. 5.
Before defining the exact behavior of a MFSM system , we give formal definitions for a MFSM sys tem and its components.
Definition 1. (Trigger / Response Transition). A trigger / response transition determines when and how a change of state occurs in a trigger / response FSM . The transition T = (t ~. Xs_ . Xd. , T,) consists of a trigger t" a source state X s _, a destination state Xd_ , and a sequence of responses produced when the transition OccurST.,. = [T~.l ' .. T,.m. ].
To create the TR FSM for the User module , we consider that we want it to send start to the Controller module when the button is depressed , and to send stop to Controller if the button is released before the Controller sends the done event. see Fig. 2.
Definition 2. (Trigger / Re sponse FSM). A trigger / respon se FSYI observes trigger events and produces response events. The FSM F consists of a set of states XF , a set of triggers TF, a se t of responses R F , a set of transitions T F , an identification of the initial state xo F ' an identification of the dump state XdPF and a set of marked states X M F' The FSM cannot have responses that trigger events within itself, T F n RF = 0, and further, there mu st be no transitions out of the dump state . To ensure determini stic behavior of the FSM , there can be at most one transition for each combination of trigger and source state (L xs ).
The way in which all of the elements of this system work together can be seen by tracing an event and the chain of respon ses that it generates through the system. The initial state of the system has all of the modules and filters in their initial state. From this state the only trigger which can enter the system is rise from the Button filter. Thi s event causes Button to transition to the high state. It also causes the User
395
The dump state indicates that the TR FSM is in a terminal state , and that it is no longer able to process events. Transitions to the dump state are not usually included by design; they are used to identify errors that occurred in the creation of the composition of TR FSMs as defined in Definition 8. Within a module or filter, events are bundled into defined connection points which we call sockets. We will commonly use the same letter to refer to both a module and the TR FSM within the module. We will use bold font for the modules (e.g. M) and italicized font for the TR FSMs (e.g. lvI). The same convention is used for filters and their TR FS~s.
Definition 3. (Socket). A socket bundles events of a module together for connection to another module. The socket S .w, consists of a set of triggers T M , and a set of re sponses R M , .
To ensure that the system is well posed, we require that: (l) the pipes must connect to sockets of modules within the system; (2) the filters on the pipes must be in the system; (3) if a pipe connects two modules then the responses of one module must be a subset of the triggers of the other; (4) an event cannot be a trigger in more than one module, nor can it be a response in more than one module ; (5) if an event is a trigger in one module and a response in another, then it is part of a pipe between those modules ; (6) every filter is associated with exactly one pipe ; (7) if a pipe has both a filter and a module at its a socket, then the re sponses of the module socket must be a subset of the triggers of the filter ' s a socket, and the triggers of the filter's b socket must be a subset of the triggers of the module socket, and similarly for the b socket. The general concept for the behavior of a system of communicating modules of MFSMs is that respon ses from one module travel to another module, triggering transitions and possi bly generating responses there. Due to space constraints a condensed version of the composition algorithm is given here . A more detailed and precise version can be found in (Endsley , 2004).
Definition 4. (Mod ule) . A module encapsulates a TR FSM for use within a system. The module M consists of a TR FSM and a set of sockets which can be connected to other modules. Every trigger in the FSM must be a trigger in exactly one of the sockets , and every trigger in a socket must be a trigger in the FSM. Eve ry response in a socket must be a response in the FSM. It is permissable for the TR FSM to have internal responses which do not appear in a socket, but a response cannot appear in more than one socket.
Definition 8. (Composition of TR FSMs). The composition of TR FSMs FI ... F n , denoted FIll· .liFn, is another TR FSM F l li lln ' Let each FSM Fi = (XF" T F" RF" TF" xO F , XdPF , X MF ) . Then the composi tion is defined as Fl i~. ':n v.: here th~ respon ses are the union of all re sponses, the triggers are the union of the triggers minus the respon ses. and the initial and dump states are the direct product of the initial and dump states of each F i . The set of states X F, 11 In and the set of transitions TF' ll iln are constructed by the composition algorithm on the following page .
Definition 5. (Filter). A filter encapsulates a TF FSM for specifying communication into and out of modules. The filter F consists of a TR FSM and two sockets, SF a and SF o ' Every trigger in the FSM must be a trigger in exactly one of th e sockets , and every trigger in a socket must be a trigger in the FSM . The set of respon ses is empty.
While Definition 8 defines the composition of TR FSM s, we desire slightly different behavior when we compose a MFSM system consisting of modules and filters. We want it to be an error if the filters allow a trigger to occur, but a module does not. Thi s can be accomplished by modifying Step 3 to also create a transition for each trigger t of the composition for which there exi sts a transition triggered by t from the current state of every filter that has that t as a trigger, regardless of the modules . Errors of th is type will appear as disabled re sponses in Step 5.
\'ow that we have defined the components of a MFSM system , we can define how these components are connected to form a system. We first define pipes which are the explicit connection between modules and filters, and then proceed to define MFSM systems.
Definition 6. (Pipe ). A pipe is a linking between objects of a system . The pipe P = (SPa' S P o ' F p ) connects a socket on one module to a socket on another and identifies a filter for the connection.
A MFSM system can be composed into a single module by performing the composition of the TR FSMs contained within the modules and filters . The resulting si ngle module also contains copies of the sockets which are on the perimeter of the system.
There are 4 variations of pipes: connecting 2 modules and identifying a filter, connecting 2 modules without declaring a filter. connecting a filter with SPa but not connecting to another module, and connecting a filter with Sp, but not connecting to another module.
Definition 9. (System Composition ). The modulepossessing the same behavior as a S is ::'1.-15 = (Ms , S.\ls ) where .'vis is the composition of the modules and filters of the system , and SM are copies of the sockets on the perimeter of the sys tem.
Definition 7. (System of Modules). A system of modules S = (/vl 5 , Fs , Ps ) consists of a set of mod{M1 .... , M n.v.}, a set of filters ules .I'V1s Fs = {F 1, .... F nF } , and a set of pipes Ps = {PI, ... , Pnp } connecting those modules and filters.
Fig. 6 shows the results of combining the system seen in Fig . 5 into a single module. The presence of a
396
transition to the dump state indicates that there is an error in the logic that should be corrected before the system is implemented.
TR FSM Composition Algorithm (l) Add the dump state and initial state to the set of states XF' ll l n ' Add the initial state to the queue of states to process Q s . (2) Remove
Xs
from the queue
Qs'
(3) Create a transition Tn for each trigger t of the composition for which there exists a transition triggered by t from the current state X s , of every TR FS!'v1 that has that t as a trigger. The source of the transition is x s , and the trigger is t. The response and the destination state are found with the following loop , which is initialized with an empty event queue Qr and by setting the current event er = t and current state Xc
Fig . 6. The system combined into a single module. 4. IMPLEMENTATIOr\ EXAMPLES A concemthroughout the creation of MFSMs was that they be of practical use in creating logic control for manufacturing systems. To that end we developed a set of software tools (Endsley et al. , 2000; Endsley , 2004) to create , verify and run MFSMs. We have also used those tools to create logic controllers for several manufacturing system testbeds. Fig. 7(a) shows the first testbed that we controlled using MFSMs. All control of the system is done through digital signals. The system has 14 bits of input and 15 bits of output; the machine could be in one of 5 ,038.848 states, not including the states of the parts.
= (xc,,· ·· , XCn) = xs·
(4) If an infinite response is detected , set the current state Xc to the dump state Xdp F ' clear the respon ses r 7"y, of the l. [···lIn
transition and skip to Step 8. (5) If there exists a TR FSM F, for which er is a trigger, but there is not a transition triggered by er from the current state xc, of that TR FSM , or the destination of such a transition is the dump state, then there is a disabled response. Set the current state Xc to the dump state. clear the responses of the transition and skip to Step 8. (6) For each TR FSM Fi for which this event is a trigger, follow the transition for this event, updating the current state xc. of that TR FSM , and adding the respon ses of that transition to the event queue Qr. If the queue and the response of the transition do not have the same events in the same order up to the length of the shorter of the two, there are conflicting responses . Set the current state Xc to the dump state XdPF ' clear th e rel l! · · · iln
sponses r 7" n of the transition and skip to Step 8. If there is no conflict and the transition's response is longer, add the extra events onto the end of the queue.
(b) MFSM Controller Structure Fig . 7. The MSFM for the linear testbed .
(7) If the queue Qr is not empty, remove the next event from the queue and set er to it, add it to the response of the transition r' n and return to Step 4.
The structure chosen for the MFS~ controller, shown in Fig. 7(b), has 4 main subsystems: one for each station , and one for coordination. The controller for each station was created, verified and tested in isolation. demonstrating the localized design capabilities of MFSMs. Instead of a single module for coordination , a subsystem consisting of several modules was used . The resulting subsystem has the benefit that it could be adapted for a linear testbed with n stations by simply repeating one of the modules n times. The controller for this system consisted of 20 modules , but only 13 of these were unique. The transfer conveyor was used 3 times, the linear slide 4 times , and the conveyor coordinator 3 times. This demonstrates a fair amount of code reuse within this project. We have
(8) Set the destination Xd _ of the new transition to the current state Xc . If the current state is not in the set of states X F' iI 'ln' add it to the set of states and to the state queue Qs. (9) If there are more triggers to proce ss for this state return to Step 3. (l0) If Q s is not empty skip to Step 2.
397
explored code reuse and reconfiguration within this testbed (Shah et aI., 2002) and for a different, rotary testbed (Pollice et aI., 2002). Currently we are using MFSMs to create cell level control for portions of the Reconfigurable Factory Testbed at the University of Michigan (Almeida and Tilbury, 2004) 5. CONCLUSIONS AND DISCUSSION While MFSMs share characteristics with other frameworks, the particular combination of characteristics that MFSMs possess makes them unique. MFSMs are inherently modular and interactions between the modules are identified explicitly through pipes. The modules can be used as peers or in a multi-level hierarchy. There is no requirement that certain modules be subordinate to others. Modules can react to trigger events by generating response events, and a system of MFSMs will resolve this chain of responses before considering new input from the environment. The acceptable communication between modules can be explicitly defined using filters, allowing localized design, localized verification and code reuse. It is considered a design error when one module sends an event to a second module when the second module is in a state where it has no transition defined for that event. Like any other framework, MFSMs have their strengths and weaknesses. Areas where MFSMs are strong include modularity, reconfigurability, verification, and execution. The modularity of MFSMs makes them suitable for creating logic control for large systems and enhances code reuse. The modular structure with filters also allows for the design of logic control that can be easily reconfigured when a manufacturing system is reconfigured. Because MFSMs are based on FSMs, verification tools can be easily applied to them. The modularity of MFSMs holds the key to enabling verification of the logic control of very large systems. And finally, as was found in the creation of our software tools, the semantics of MFSMs is directly executable. There is no need to resort to disabling or forcing events. Areas where MFSMs are weak include concurrency and compactness. In creating the logic controllers for our testbeds, we learned that it is cumbersome to represent concurrency within a single module or filter. This is because a module or filter contains a single FSM , which does not represent concurrency well. A study on logic control methodologies (Lucas and Tilbury, 2003) showed that a logic controller written in MFSMs was 'larger' than controllers with the same functionality written in ladder diagram or Petri nets. One of the primary reasons for creating MFSMs was to enable the verification of large logic controllers. While this paper does not present any results on verification. we have made progress in this area. With the help of Trigger / Response Languages , we have created a procedure for verifying the absence of conflicting and disabled responses within a MFSM system (Endsley, 2004). Significantly, this procedure is based on constructing the composition of a module with its surrounding filters. not constructing the composition of the entire system. While the state space of the
398
composition of the module with its filters grows exponentially with the number of filters that the module communicates through, a good design should keep the number of connections to a single module small. Therefore, this composition does not fail due to state explosion , and the check can easily be applied to each module in the system. This procedure allows for the verification of those two properties in very large systems. We are hopeful that other procedures can be created for the modular verification of additional properties of MFSM systems. Acknowledgements This research was supported in part by the NSFERC for Reconfigurable Manufacturing Systems under grant EEC95-92125. The authors would also like to thank the anonymous reviewers for their helpful comments : REFERENCES E. Almeida and D. M. Ti lbury. Automatic logic generation for reconfigurable cell-based manufacturing systems. In Proceedings of the IFAC Workshop on D,screte Event Systems (WODES). Reims. September 2004. S. Balemi. Input / output discrete event processes and communication delays. Journal of Discrete Event Dynamic Systems: Theory and Applications. 4:41 - 85.1994. D. Brand and P. Zafiropulo. On communcating finite-state machines. Journal of the ACM. 30(2):323-342. April 1983. B. A. Brandin. Error-recovering supervisory control of automated manufacturing systems. Integrated Computer-Aided Engineering. 3(4):255 - 267 , 1996. W. Damm. B. Josko. H. Hungar. and A. Pnueli. A compositional real-time semantics of statemate designs. In Proceeding s of COMPOS. pages 186 - 238. 1997. E. W. Ends ley. Modular Finite State Machmes for Logic Control: Theory. VerificatIOn and Applications to Reconfigurahle ManuJacturIng Systems. PhD thesis. University of \1ichigan. Ann Arbor. Ml. May 2004. E. W. Endsley. M. R. Lucas. and D. M. Tilbury. Software tools for veri fication of modular FSM based logic concrol for use in reconfigurable machine tools. In Proceedmgs oJ the Japanu.s.A. SymposIUm on Flexihle Automation. Ann Arbor. 2000. D. Hare!. Statecharts: A visual formalizauon for complex systems. Science ofCompter Programmmg. 8(3):231 - 274. 1987. Y. Koren. u. Heise!. F Jovane. T. Moriwaki. G. Pritschow. G. Ulsoy. and H Van Brussel. Reconfigurable manufacturing systems. In CIRP Annals. vol ume 2. pages 6-12. November 1999. Keynote Paper. S. C. Lauzon. A. K. L. Ma. J. K. Mills. and B. Benhabib. Implementing a discrete-event-system-based supervisory controller for a flexible manufacturing workcell. In Proceedmgs oJ the 1995 IEEE Interna tional Conference on Robotics and Automation. volume 2. pages 1429 - 1434. IEEE. May 1995. M. R. Lucas and D. M. Tilbury. Comparing indu scrial logic design methods used in the automotive industry. In Proceedings oJ the IEEE Internationa l Conference on Systems. Man . and Cybernetics. pages 530 - 537. Washington. DC. October 2003. S. L. Polilce. E. W. Endsley. and D. M. Tilbury. Logic concrol using modular FSMs: An evaluation of code re-use. In Proceedings oJ the 2nd IFAC Conference on Mechatronic Systems. 2002. P. J. G. Ramad;e and W. M. Wonham. The concrol of discrete event systems. Proceedings DJ the IEEE. 77( 1):81 - 98. January 1989. \1. Rau sch and B. H. Krogh. Symbolic verification of stateftow logic. In Proceeding s oJ the IFAC Workshop on Discrete Event Systems (WO DES). Cagliari. 1998. S. S Shah. E. W. Ends ley. M. R. Lucas. and D. M. Tilbury. Reconfigurable logic control using modular FSMs: Design. verifi cation. implementation. and integrated error handling. In Proceedrngs oJ the AmerIcan Control Conference. 2002.