Copyright Cl IF AC Advances in Control Education, Gold Coast, Queensland, Australia, 2000
MATLAB STATEFLOW IN TEACHING DISCRETE-EVENT CONTROL
Claudiu Lefter and Octavian Pastravanu
Department ofAutomatic Control and Industrial Informatics, Technical University "Gh. Asachi " ofIasi, Blvd. Mangeron 53A, 6600 Iasi, Romania E-mail:
[email protected]@delta.ac.tuiasi.ro
Abstract. An approach to design, implementation and testing of discrete-event control architectures is presented from the teaching methodology point of view, taking advantage of the various facilities offered by Stateflow, as a software embedded in the complex environment MATLAB-Simulink. Mainly devoted to practical demonstrations for laboratory classes, the simulation experiments aim to illustrate the efficiency of the procedural controllers designed along the lines of supervisory control theory. Copyright © 2000 IFA C
Keywords. Discrete event systems, Supervisory control, Simulation, Educational aids.
1.
INTRODUCTION
In this context, the release of MATLAB's Statejlow (MathWorks Inc., 1998) opened new perspectives for DES laboratory work of CE students, by deriving a full benefit from their skills in using MATLABSimulink and concentrating the whole attention on DES problems. The main advantage of developing applications in Statejlow (SFL) results from its facility to operate with Finite State Machine (FSM) models. This makes possible the implementation of feedback strategies based on Supervisory Control Theory (SCT), which are very suited for turning into value the CE students' solid background in systems theory.
In the middle nineties, many universities offering education programs in Control Engineering (CE) included, in their curricula, courses on Discrete Event Systems (DES), as a consequence of the large impact on research and technology proved by the tremendous development of this field. The organization of the experiments for laboratory classes, associated with the DES courses, requested specific software tools and, therefore, the educators relied on the usage of some already existing environments, among which the most popular were Petri net or queuing system simulators. Unfortunately, none of these software platforms is familiar for CE students, whose regular practical training focuses on the exploitation of the generous resources offered by MATLAB-Simulink and the specialized toolboxes. Moreover, the fundamental concepts of CE, referring to the key elements of feedback system architecture - which have been successfully integrated in the MATLAB philosophy, are almost missing in the DES-oriented simulators mentioned above. Thus, supplementary time and effort should be invested for getting students acquainted with the software environment chosen for approaching DES applications.
The purpose of this paper is to create on overview of both theoretical points and practical issues sustaining successful laboratory demonstrations for DES courses taught to students specializing in CE. Our approach covers all the key aspects of procedural controller design, starting with the systematic construction of SCT-based solutions to synthesis problems, followed by the Stateflow implementation, and ending with the closed-loop simulation in Simulink for checking the controller validity. At the conceptual level, the paper reflects the same interest manifested by one of the authors in a previous work
193
(Pastravanu et al., 1997) for enlarging the compatibility between the novelty of DES scenarios and the traditional background of CE students.
steps, by adding, at each step, extra dynamic specifications (formulated according to the designer's expertise). Cu"ent trends in exploiting SCT move the center of gravity on hybrid dynamics and hybrid control, in order to develop more efficient analysis and synthesis procedures for the wide class of systems containing both continuous and discrete states.
2. THEORETICAL PRELIMINARIES SCT as developed by Ramadge and Wonham in their pioneering works (Ramadge and Wonham, 1987, 1989), relied on a noticeable initiative of applying methods and techniques issued in the field of computer science to control engineering. However, at that stage, the applicability of SCT to concrete problems revealed a number of inconveniences, mainly due to the following three reasons: (i) DEStype models constructed for realistic processes exhibit a cumbersome complexity; (ii) completely controllable systems (as requested by the theoretical framework) are quite rarely encountered in practice; (iii) there exists no control enforcement upon the process (the controller action being limited only to appropriate disabling of controllable transitions).
3. USING STATEFLOW FACILITIES SFL is a powerful development tool for complex logic problems, operating with FSM models, which are described graphically as state-transition diagrams (charts). The way transition conditions are specified in SFL offers a supplementary flexibility to FSM models, since the broadcast of an event can trigger a transition to occur and/or can trigger an action to be executed. The integration of SFL with MATLAB and Simulink environments allows incorporating SFL diagrams into Simulink models and, consequently, simulating a wide variety of dynamical systems, including advanced organization structures, such as hierarchy, parallelism, and history.
Later on, a large body of research contributed to the gradual improvement of SCT, for details see (Cassandras et aI., 1995; Kumar and Garg, 1995). Thus, in 1996, Sanchez (Sanchez, 1996) was able to present a systematic approach to procedural controller design, free of all previously mentioned drawbacks. His main interventions at the theoretical level are summarized below: (i) In analysis, the concept of controllability is relaxed to conditional controllability; (ii) Model construction for the process relies on the identification of some simple structures, called elementary components and their further merging by asynchronous product; (iii) In synthesis, a new entity, called local controller, is introduced as responsible for the avoidance of forbidden states (corresponding to static specifications) and for the enforcement of a certain behavior (prescribed by a dynamic specification); (iv) At the end of design stage, all the local controllers are merged by synchronous product to get the global controller.
In particular, SFL ensures an appropriate framework
for design and development of deterministic, supervisory control strategies for DES and hybrid systems. Moreover, operating changes in models, as frequently requested by design techniques, becomes a straightforward task, relying on the block-oriented philosophy of Simulink. The action of the resulting controller, running in Simulink, can be applied to both simulated and real-life processes. In the latter case, an adequate interface is necessary to be achieved (e.g. by using RealTime Workshop). Once tested and validated, a control algorithm can be implemented on a target computer (without MATLAB-Simulink platform), by exploiting the C code resulting whenever the SFL option "generate code" is activated.
It is worth outlining that the procedural controller synthesized according to (Sanchez, 1996) not only ensures the standard functions of the supervisor (with inhibitory role) devised by Rarnadge and Wonham, but also generates proper control actions (representing an enforcement upon the process). The efficiency of the controller depends on the correlation between the practical meaning of the uncontrollable transitions (revealed during the analysis stage) and the closed-loop requirements defined by the dynamic specifications (for synthesis purposes). In general, the controller design requires an iterative (multi-step) strategy, because a single step cannot guarantee the existence of a unique controllable transition for each state of the procedural controller. This uniqueness condition can be obtained within a finite number of
4. TOOLS FOR AUTOMATIC DESIGN OF PROCEDURAL CONTROLLERS Even for a simple control problem, the construction and manipulation, by hand calculus, of the FSM model for both process and controller is quite laborious a task. Therefore, approaches to FSM modeling become really efficient only when the whole sequence of requested operations is implemented by an automatic procedure. This fact motivated us to develop a minimal set of functions for accomplishing the computational tasks T1, T2 detailed below.
194
(n) The elaboration of the FSM model for the process starts (as input data) from the models of all elementary components, described by state-transition diagrams, and provides (as output data) the associated transition matrix. The diagrams corresponding to the elementary components are collected within a file, with a given structure, easy to create by the help of a text editor. The asynchronous product is applied to the elementary models and supplies all possible combinations of the statevariables in an interleaved fashion (Sanchez, 1996), yielding the global model of the process.
The process to be controlled was chosen from the examples most frequently used in DES literature and consists of the burner system depicted in fig. 1, whose close-loop behavior complies with the specifications formulated in (Sanchez, 1996; pp 6162).
5.1 Design aspects For teaching purposes, the controller design first deals with the case when no dynamic specifications are formulated for two uncontrollable transitions (flame detection in the state corresponding to air valve opened and fuel valve closed; flame extinction in the state corresponding to both valves opened, igniter on and flame detected), whose occurrence induces an abnormal behavior to the process. Whenever this happens, the resulting controller is not able to make a decision and it cannot protect the process against the abnormal operation; besides, the human operator is not warned of the abnormality. All these aspects are illustrated by simulation in MATLAB-Simulink, using the SFL facilities for the implementation of the FSM models; details are omitted here, because extensive comments on implementation, simulation and testing will be given bellow, in the context of a more complex study.
(12) The synthesis of the FSM model for the procedural controller starts (as input data) from the transition matrix of the process modeled at (n), as well as from the static and dynamic specifications for the closed-loop system, and generates (as output data) the transition matrix of the global controller. The forbidden states (corresponding to the static specifications) together with the afferent transitions are removed from the process model leading to the of the supervisor. The logic structure homomorphisms proposed in (Sanchez, 1996) are exploited for mapping the dynamic specifications, expressed by Temporal Logic formulas, into FSM domain. The resulting FSMs are joined with the supervisor structure by the synchronous product, yielding the models of the local controllers. Finally, the global controller is obtained by successively applying the synchronous product to all the local controllers. If the closed-loop system (with the controller resulted from synthesis) does not meet the design specifications, this task has to be repeated with additional requirements in the set of specifications.
After discussing the disadvantages of the above design solution, the whole approach is repeated, paying more attention to the physical meaning of the abnormal functioning caused by the two uncontrollable transitions. In such cases, a welldesigned controller should be able to eliminate the drawbacks pointed out previously, in the sense of signaling for the abnormality and driving the burner system into the safe state where both valves are closed and the igniter is off. For signaling, an augmentation of the process model is considered, by introducing two supplementary state variables, which can be used for triggering two emergency alarms, as suggested in (Sanchez, 1996, pp. 107 -108). Thus, the augmented model should be regarded as corresponding to an extended physical process, incorporating the original burner system, supplemented with the alarm devices. For ensuring the protection against abnormal functioning (i.e. driving the process into the safe state), the controller is redesigned, starting from the augmented model and a new set of specifications (based on the former ones, restated for the extended system). The requested computations are done automatically, by running tasks n, 12 detailed in Section 4.
5. CASE STUDY The goal of this case study is to briefly present the design and implementation of a procedural controller for a typical event-driven process, placing emphasis on simulation and testing experiments developed in MATLAB-Simulink.
__
BURNER CHAMBER
1"-'-'-', FLAME •
AIR
i
D.~~
L_
I
FUEL I I
I I I I I
;---' ,
I
iIGNITE!i I '
,
'-'-r-'-
:
!
I
5.2 Simulink implementation
I
I
L------- il-_CO_NTR __ O_LL_E_R--,~_l
The new controller synthesized for the extended burner system was implemented and tested in MATLAB-Simulink. The Simulink model of the
Fig. I. Schematic representation of the burner system
195
closed-loop system is given in fig. 2 and takes advantage of the user-friendly graphic interface of SFL for operating with state-transition diagrams. The Simulink model comprises three main blocks, named Process, Controller, Timer, and their interconnection requires small delays for avoiding the occurrence of algebraic loops. This model is meant for running Simulink in external mode (using the exe-file built by Real-Time Workshop). Thus, students effectively generate real-time events, in a similar fashion as the human operator acts upon the process. For laboratory classes, such interactive exercises present the advantage of creating a framework much closer to the exploitation of real-life objects, than pure simulation (i.e. running Simulink in internal mode). Nevertheless, our primary tests were performed in internal mode, based on an adequate Simulink model, which received event sequences defined off-line (as vectors in the MATLAB workspace), before starting the simulation. Experiments of this type cannot be commented in the current text, because the size of our paper would dramatically increase, but their incontestable importance as complementary aids for practical training should be mentioned.
modeling changes of the flame detector status; (iii) events generated by the single switch called Power which ensures the reset of the FSMs modeling the process and the controller. The event output generates the event called mod whenever the process model changes the state (see, below, the role of super and substates concepts in implementation) and it ensures the synchronization between the process and the controller. The data outputs are declared as binary variables and give complete information about the six elementary components of the process (air valve, fuel valve, igniter, flame detector, alarm!, alarm2), each one defining a superstate in the SFL language. As an illustrative example for the exploitation of SFL capabilities to operate with hierarchical structures of type superstate-substate, fig. 3 depicts the superstate model of the air valve, which incorporates two substates, corresponding to the valve on/off positions. The other five superstates used in the SFL model have analogous meaning. The Controller block implements the designed controller and has two event inputs, one data input and six event outputs. The event inputs are mod (defined above as output for process model) and time_out (defined as output for Timer block -see below). The data input (named emergency) is the data output of Process block associated with the flame detector. The change of its value and the current state of the controller are used by SFL to decide on the controller action: either performing a transition (which corresponds to the latest transition performed by the process), or broadcasting an event to the process.
The Process block implements the model of the extended burner system and has seven event inputs, one event output and six data outputs. The event inputs are defined as follows: (i) events received from either a set of switches that can be changed while Simulink runs in external mode (modeling the interventions of the human operator on air valve, fuel valve, igniter, alarm!, alarm2), or the controller (via the feedback mechanism - see below Controller block); (it) events generated by a single switch
"_fuell-------+t. ign fl ..
1-------.1.
mel-""T"----. . . .- - ,L...-_ _ .. 11
.. 121--+-----+1.
Timer
Controller
Fig. 2. Simulink model of the closed-loop system used in case study
196
~
Two scenarios (experiments E2, E3) from the test set are selected here to demonstrate the controller capability of driving the process to a safe state whenever the process enters an abnormal behavior. In the first scenario (E2) the flame is detected after the air valve is opened. In this case the controller will activate alarm 1 (alarml = 1) and will close the air valve (air_valve = 0). The result is plotted in fig. 5. The second scenario (E3) simulates the case in which, after the process reaches the normal operation state, the flame extinguishes. In fig. 6 one can easily see that the controller activates alarm 2 (alarm2 = 1) and drives the process to a safe state, by closing the fuel valve (fuel_valve = 0), switching the igniter off (igniter = 0) and closing the air valve (air_valve = 0). Fig. 3 SFL superstate modeling the air valve The event outputs are defined as follows: (i) events mod_air_c, mod.Juel_c, mod_ign_c, mod_all , mod_ al2 representing actions enforced upon the process, whenever an abnormal behavior is exhibited; (ii) event start_temp, generated for triggering the Timer block (see below) when the controller expects no further event on the mod input. The Timer block is not resulting from the design stage and it does not properly pertain to the closedloop structure. It is introduced just for Simulink implementation reasons, in order to achieve a programmable delay by using the data flow facility of SFL. The only input of the block is the event start_temp, (see above). The block generates the output event time_out, which is sent to the controller as a "false" event (i.e. not belonging to the alphabet of process and controller) to ensure the controller transitioning, even if "true" events are missing.
Fig. 4. El - normal startup (air-igniter-fuel-flame), normal shutdown (igniter-fuel-flame-air)
5.3 Experimental validation of the designed controller
Fig. 5. E2 - abnormal behavior: flame detection after opening the air valve
Simulation experiments (based on the Simulink model in fig.2) were performed to validate the effectiveness of the design solution. Such experiments are extremely relevant for illustrating the SFL capabilities to manipulate DES models. It is worth underlining that simulation becomes more attractive for the students, because they can generate sequences of events in real-time, by their own interventions on the positions of switches in fig. 2 (while Simulink runs in the external mode). In what follows, the presentation is limited to some representative tests selected from an exhaustive set, recommended for student's individual work.
Fig. 6. E3 - abnormal behavior: flame extinction after reaching the normal execution state
The first experiment (El) is devoted to the study of the behavior during normal startup and shutdown procedure (open air valve - switch igniter on - open fuel valve - detect flame - switch igniter off, and close fuel valve - close air valve, respectively). The evolution of data outputs from the process is plotted in fig. 4.
6. TEACHING GOALS In the syllabus of a DES course given to CE students,
lectures on SCT should be organized as a leading chapter, because SCT (in comparison to other DES
197
approaches, such as Petri nets, queuing systems) allows pointing out numerous analogies with the classical time-driven systems, which are extremely profitable for a deeper understanding of the concepts: (i) Terminology used in modeling relies on fundamental notions of input, state, output; (ii) Desired behavior is ensured by a feedback mechanism which is structurally separated from the process; (Ui) Philosophy of controller design requires, as a starting point, the rigorous description of the process (i.e. model) and desired behavior (Le. specifications); (iv) Fulfillment of closed-loop specifications ensured by the synthesized controller needs a careful validation by simulation, using relevant tests and a trustable simulator; (v) Design should be repeated whenever achieved performance differs from the proposed one (in such cases, particular attention should be given to possible deficiencies in model construction or interpretation).
because its similarities with the classical control theory allow elaborating a comparative study, in the framework of which analogies and differences can be easily revealed. This point of vie becomes more convincing if adequate laboratory experiments are devised to complement theoretical knowledge. It is the purpose of our paper to demonstrate that
relevant simulation exercises for studying DES, in accordance with the methodological lines suggested above, can be developed in Simulink. The presented case study amply illustrates the important role of simulation in testing the validity of DES design solutions, by taking advantage of the facilities available in the recently released SFL software, integrated with Simulink. In order to reduce the design effort and to make the overall synthesis problem more attractive for the students, some automatic procedures have been implemented for avoiding cumbersome hand calculus. Future plans focus on transferring the whole expertise to the realtime implementation of procedural controllers on adequate laboratory setups.
Besides the similarities between SCT and classical theory of time-driven systems, the educator has to clearly emphasize the main differences between the twos: (i) Dynamics (i.e. models and specifications) are defined in qualitative terms for the former (involving only event sequencing - i.e. the precedence relation induced by physical time), whereas quantitative descriptions are requested for the latter; (ii) Discrete-mathematics (including fundamentals of formal languages and lattice theory) are needed as background for the former, whereas differential and difference equations are obligatory for the latter; (iii) Simulation studies require different computational capabilities for the two types of dynamics.
ABBREVIAnONS CE - Control Engineering DES - Discrete Event System FSM - Finite State Machine SCT - Supervisory Control Theory SFL - Stateflow REFERENCES Cassandras, C.G., S. Lafortune and G.J. Olsder (1995). Introduction to the Modeling, Control and Optimization of Discrete Event Systems. In: Trends in Control. A European Perspective (Isidori, A. (Ed)), 217-252. Springer-Verlag, London. Kumar, R. and V.K. Garg, (1995). Modeling and control of logical discrete event systems,-Kluwer Academic Publishers, USA. Pastravanu, O.C., A. Giirel and F.L. Lewis (1997). Teaching discrete event control ofmanufacturing systems. In: Prep. of the 4th IFAC Symposium on Advances in Control Education, ACE'97, 307-312. Ramadge, P.J. and W.M. Wonham (1987). Supervisory control of a class of discrete event systems. SIAM Journal of Control and Optimization, 25, 206-230. Ramadge, P.J. and Wonham, W.M. (1989). The control of discrete event systems. Proc. IEEE, 77,81-97. Sanchez, A. (1996). Formal Specification and Synthesis of Procedural Controllers for Process Systems. Springer-Verlag, London. The MathWorks, Inc. (1998). Stateflow User's Guide, 24 Prime Park Way, Natick, MA 01760-1500, USA.
Laboratory classes are equally important as the taught courses for highlighting the analogies and differences discussed above. Unlike lectures, practical demonstrations should concentrate on the relevance of experiments and therefore Simulink can be regarded as an excellent environment, allowing simulation of both event- and time-driven dynamics. CE students have good skills in exploiting Simulink for time-driven systems, and the laboratory exercises on DES create them the opportunity to enlarge their experience, by learning how to use SFL. Moreover, nowadays, MATLAB-Simulink stands as a standard for scientific computation software and students' training by complex simulations within this environment ensure their high level qualification as future specialists. 7. CONCLUDING REMARKS In teaching DES to CE students, a particularly subtle
task consists in making extremely clear the differences between the approaches to time-driven and event-driven systems, in the specific situation resulting from a good familiarization of the students with the former topic. For addressing such a didactic task, SCT represents a very convenient setting,
198