Concurrent Program Synthesis Based on Supervisory Control

Transcription

1 010 American Control Conference Marriott Waterfront, Baltimore, MD, USA June 30-July 0, 010 ThB07.5 Concurrent Program Synthesis Based on Suervisory Control Marian V. Iordache and Panos J. Antsaklis Abstract The aer introduces a new area of alication of the suervisory control (SC) methods and a roject dealing with this research toic. Based on the observation that various constraints on the oeration and synchronization of concurrent rocesses can be exressed in terms of SC secifications, the aer rooses the alication of SC to the automation of concurrent rogram synthesis. Secifically, the aer rooses a three-stage aroach allowing to generate automatically the art of the rograms that deals with the coordination of concurrent rocesses. In a first stage, Petri net models are extracted from a high level secification. An SC secification is also extracted. Then, SC is alied to generate the suervisor enforcing the secification. Finally, the rograms reresenting the rocesses and the suervisor are generated. This work is motivated by the difficulty of writing correctly concurrent rograms. Since this difficulty is due to the constraints on the oeration and synchronization of concurrent rocesses, research in this area has the otential of simlifying the develoment of concurrent rograms. I. INTRODUCTION The develoment of correct software can be difficult and exensive, esecially in the context of concurrency. Thus, tools that can automate software develoment to a higher degree are of interest, in order to reduce the rogramming effort and increase the number of features of the roduct that are correct by construction. In the context of concurrency, the main difficulty is writing the rogram segments that ensure that the concurrent rocesses satisfy desired oeration and synchronization constraints. This aer considers the automatic synthesis of these rogram segments and introduces an aroach based on Suervisory Control (SC). This work is art of a roject for the develoment of a concurrency tool suite (ACTS) for the synthesis of concurrent rograms [1], [17]. The goal is to design software that based on a high level secification can generate concurrent rograms. The ACTS architecture is outlined in Figure 1. Given is a secification written in a high level secification language (HLL). Next, an analysis tool is alied to the high level secification in order to extract a lant model of the concurrent rocesses and also a secification for SC. Then, SC is alied to generate a suervisor. Finally, the lant and the suervisor are translated to rogramming code. All these stes are carried out transarently and automatically, based on the high level secification. The benefit of this aroach M. V. Iordache is with the School of Engineering & Engineering Technology, LeTourneau University, Longview, TX 75607, USA MarianIordache@letu.edu P. J. Antsaklis is with the Deartment of Electrical Engineering, University of Notre Dame, Notre Dame, IN 46556, USA antsaklis.1@nd.edu The authors gratefully acknowledge the suort of the National Science Foundation (NSF CNS ). is that the rogrammer would focus on a concise high level descrition, instead of the more comlex lower level imlementation. Of course, not every tye of secifications can be handled by a SC aroach. However, the roblem of automating to a higher degree rogram synthesis raises issues intrinsically related to SC, since various high level requirements, such as fairness, absence of deadlocks, and mutual exclusion, can be seen as SC secifications. The aer is organized as follows. First, an illustrative examle is given in section II. Next, the Petri net reresentation of rograms is described in section III. The code generation aroach is described in section IV. Issues related to the design of the HLL are addressed in section V. The alication of SC methods is discussed in section VI. Related literature results are discussed in section VII. Additional information about this roject can be found in [1]. II. ILLUSTRATIVE EXAMPLE Here we consider the roblem of designing control software for an assembly oeration in a manufacturing line. Two comonents A and B are assembled into a comonent C as follows. A robot takes a art A and laces it on a conveyor, if the conveyor is stoed and no other art A is on the conveyor. Another robot takes a art B and laces it on the conveyor at the same location if the conveyor is stoed and no other art B is there. Then, the two arts A and B are assembled. Then, after the conveyor is turned on and the assembled roduct is removed, a new cycle may begin. The conveyor should not move from the time a art A or B is laced until the time when the arts are assembled. Referring to Figure 1, the SC secification corresonds to the requirements that only one art A (B) is laced on the conveyor, that the arts are laced when the conveyor is stoed, and that the conveyor should not move from the time a art A or B is laced until the time when the arts are assembled. For the rest, the secification describes the rocessing sequence and corresonds to the descrition of the lant. The role of the analysis tool is to extract a PN model of the lant and the SC secification based on a formal descrition of the secification above. A ossible solution is the PN model of the lant is shown in Figure and the SC secification given in the inequalities (1) (4). In the lant model of Figure, the rocessing sequence is shown to the left and the states of the conveyor to the right. To incororate the effect of rocessing delays, a rocessing ste is modeled by a controllable transition, an uncontrollable transition, and a lace, as shown in Figure 3. The controllable transition is fired when the command is issued and the uncontrollable transition is fired after the /10/$ AACC 3378

2 SC secs HLL Secification Analysis DES model (lant) Suervisory Control DES and suervisor Code Generation Fig. 1. Outline of the rogram synthesis aroach. Bring A t 5 t 7 7 Bring B 1 Stoed t 4 t 5 t 7 C C 4 A brought 6 t 6 t 8 B brought Run t t 1 3 t Running Sto 3 t 6 7 t 8 1 t 4 t 1 t 3 t Assemble C t 9 CONVEYOR 6 3 t 9 9 C 1 C 3 C assembled t 10 9 controllable t C removed t 11 uncontrollable 10 t 11 Fig.. Plant model. Fig. 4. Plant and suervisor. Fig. 3. Issue Command Command Executed A ossible way to model rocessing delays. command has been executed. For instance, in Figure, t 1 is fired when the command to turn on the conveyor is issued and t is fired when the conveyor is on. Finally, the following inequalities on the marking of the PN exress the remaining requirements of the secification. Note that µ i denotes the marking of the lace i. µ 6 + µ 9 + µ 10 1 (1) µ 6 + µ 9 + µ + µ 3 + µ 4 1 () µ 8 + µ 9 + µ 10 1 (3) µ 8 + µ 9 + µ + µ 3 + µ 4 1 (4) The inequality (1) exresses the requirement that only one art A should be laced on the conveyor. Further, () describes the requirement that the conveyor should not move from the time a art A is laced until the time when the arts A and B are assembled. The inequalities (3) and (4) exresses the similar requirements for the arts B. The suervisor enforcing (1) (4) could be designed following any of the literature SC aroaches. The rocedure resented in this aer is not limited to a articular set of SC methods. If [5] and [14] are followed, the inequalities (1) (4) are transformed to an admissible form that accounts for the artial controllability of the lant: µ 5 + µ 6 + µ 9 + µ 10 1 (5) µ 5 + µ 6 + µ 9 + µ + µ 3 + µ 4 1 (6) µ 7 + µ 8 + µ 9 + µ 10 1 (7) µ 7 + µ 8 + µ 9 + µ + µ 3 + µ 4 1 (8) The inequalities (5) (8) are imlemented by the laces C 1,, C 4 shown in Figure 4. In this examle we could associate software rocesses with the oeration sequences of the arts A, B, and C and with the conveyor. SC rovides a way to generate a coordination strategy of these rocesses such that the secified outcome is achieved. While here we have used a manufacturing examle, coordination needs arise also in urely software alications. III. PETRI NET REPRESENTATION OF PROGRAMS In this roject, a rogram consists of a number of rocesses running concurrently. The structure of each rocess 3379

3 1 a 3 1 a 3 e e e h f h f g 6 g b b g b c d c d (a) (b) (c) (d) Fig. 5. PNs that reresent rograms are a comosition of state machine comonents. Note that the transitions with the same label are comosed. is reresented by a PN. The laces of the PN corresond to oerations erformed by the rocess. The transitions may be labeled by conditions, indicating which transition should be taken when there is a choice. Each PN token corresonds to a rocess. As a token moves from one lace to another, the execution of the corresonding rocess rogresses from one set of oerations to another. Thus, the various laces of the PN corresond to different stages in the execution of the rocess. We will denote by HPN (high level PN) a PN in which laces are labeled with instructions and transitions with conditions. In general, PN transitions may have multile inut laces and multile outut laces. The effect of firing such transitions is made recise by describing the PN structure by means of tules of the form ( 1, t, ), (, t), and (t, ), where 1,, and stand for laces and t for a transition. A ( 1, t, ) tule indicates that the PN has one arc from 1 to t and of one arc from t to. Further, when the transition t is fired, a rocess in the stage 1 continues with the stage. A (, t) air indicates that the PN has one arc from to t. Further, when the transition t is fired, a rocess in the stage terminates. A (t, ) air indicates that the PN has one arc from t to. Further, when the transition t is fired, a new rocess is created and the rocess begins in the stage. The descrition above can be alied to PNs with arbitrary weights, since reeated arcs could be used to indicate weights greater than one. Note that when a lace has multile outut transitions, if the transitions are labeled with conditions, a rocess in the stage will select the next transition to be fired based on the conditions labeling the transitions. On the contrary, if the transitions do not have conditions and there is no code associated with to select the next transition, the choice of the next transition may be made by the suervisor. Transitions with a single inut lace are fired immediately, unless controlled by a suervisor rocess. However, transitions controlled by a suervisor or involving more than one inut lace cannot be fired immediately. Rather, a rocess sends a request to fire such a transition and then waits for ermission. After ermission is granted, the signals PROCESS 1 Fig. 6. COORDINATOR PROCESS PROCESS PROCESS M Imlementation of the secification. rocess goes on with the next stage. Note that a PN may have more than one token. Each token of the PN corresonds to a different instance of the rogram associated with the PN. Note also that multile tokens in the same lace are allowed. This situation corresonds to multile rocesses in the same execution stage. By examining the way PNs are used to reresent rograms, it becomes aarent that the reachable stages and transitions of any software rocess form a state machine. That is, for any given initial osition of a token in the PN, a state machine will describe the ossible stages and transitions of the rocess associated with the token. Moreover, the PN can be seen as a arallel comosition of state machines. An examle of comosition of state machine comonents into a PN is shown in Figure 5. Therefore, without loss of generality, state machines rather than general PNs can be associated with rocesses. However, unlike to the tyical definition of state machines, note that here arbitrary markings and arbitrary arc weights are allowed. Moreover, note that associating state machines with rocesses does not simlify the SC roblem, since the arallel comosition of state machines can result in arbitrary PNs that are not necessarily state machines. IV. CODE GENERATION Code is generated according to the coordinator architecture shown in Figure 6. Thus, the result of software 3380

4 .. SPECS FILE SPECS FILE Fig. 8. Fig. 7. SOFTWARE SYNTHESIS TOOLS ANALYSIS LIBRARIES MAKE FILE PROC TYPE 1.C. MAKE. PROC TYPE N.C SUPERVISOR.C How the software synthesis tools are alied. SC SPECS HPN 1 HPN. HPN N SUPERVISORY CONTROL CODE SUPERVISOR GENERATION PROC TYPE 1.EXE PROC TYPE N.EXE SUPERVISOR.EXE SUPERVISOR.C PROC TYPE 1.C PROC TYPE.C. PROC TYPE N.C The software synthesis rocedure. HPN stands for high level PN. synthesis consists of a number of alication rocesses and a coordinator rocess. The alication rocesses corresond to rocesses defined in the secification. The coordinator rocess corresonds to the software imlementation of the constraints given in the secification. Thus, the coordinator rocess reresents the suervisor generated by means of SC. The suervisor (coordinator) exchanges messages with the other rocesses to ensure that their oeration resects the constraints given in the secification. Note that the number of rocesses is variable. Processes may terminate and new rocesses may be created, as described in the secification. While Figure 6 shows a single coordinator rocess, a decentralized or distributed aroach is ossible by using the corresonding SC methods. Note that a distinction is made here between rocesses and rocess tyes. Several rocesses may have the same rocess tye, that is, the same executable code. The code of the suervisor and the code of the rocess tyes is generated as shown in Figure 7, where the software synthesis rocedure is outlined in Figure 8. The coordinator aroach is illustrated here on the examle of section II. The coordinator will use four variables m 1 m 4, each corresonding to the marking of the suervisor laces C 1 C 4. The coordinator rocess is notified by the conveyor rocess each time t 4 is fired and by the assembly rocess each time t 10 and t 11 are fired. Further, before firing one of t 1, t 5, or t 7, the conveyor and the assembly rocesses request ermission from the coordinator. The coordinator determines whether t 1, t 5, and t 7 are enabled or disabled based on the solution shown in Figure 4. For instance, the coordinator enables t 1 if m 1 and m 4 1. Further, if ermission to fire t 1 is granted, m and m 4 are decremented. Similarly, if the firing of t 4 or t 10 is announced, m and m 4 are incremented. In code generation, secial attention is given to transition synchronization. Synchronization is imlemented by a coordinator rocess. When an alication rocess is ready to fire a transition t that is synchronized with other transitions, the rocess requests the coordinator ermission to fire t. Permission is granted when all other rocesses involved in the synchronization are ready. Transitions are classified as follows. A transition is controlled if the suervisory olicy disables it in certain circumstances. A transition is observed if its firings must be communicated to the suervisor. Further, t is a synchronization transition if t and there is t of a different rocess tye that has the same label and satisfies t. Moreover, if two transitions of two different rocess tyes have the same label, one of them has one outut lace but no inut lace, and none is a synchronization transition, then they are action transitions. For examle, in Figure 5(a) (c) the transitions of label e are synchronization transitions and the transitions of label b are action transitions. Note that transitions with one outut lace and no inut lace create new rocesses. Thus, when an action transition takes lace, the coordinator rocess is notified in order to generate the corresonding new rocesses. Based on the communications needs for each transition and the suervisory olicy, code generation algorithms can be develoed [17]. V. THE SPECIFICATION LANGUAGE As reviously mentioned, in our aroach (Figure 1) the secification is given in a high level secification language (HLL). As shown in Figure 8, based on the secification, a number of high level PNs (HPNs) and a suervisory control (SC) secification are extracted. Note that using HPNs instead of lace transition nets (P/T nets) is necessary due to the fact that the latter do not have the ower of Turing machines. Thus, rocesses are reresented by PNs in which laces are associated with low level code and transitions with conditions. However, this means that only the art of the secification exressed by PNs is addressed by the synthesis tools. Thus, the SC tools would only guarantee correctness for the subroblem associated with the PN structure extracted from the HLL rogram. This is because the SC tools do not take in account the low level code sections. The low level code sections embedded in the secification are simly coied, as aroriate, to the outut files. In this resect our aroach resembles the aroach taken in other rogram synthesis tools, such as lexical analyzer generators and arser generators. While the HLL will allow sections of low level code, the HLL has to rovide other ways to secify the software arts that are difficult to write manually, so that they are generated automatically. Thus, in the context of concurrent rogramming, the HLL has to address the various synchronization constraints that may be needed. 3381

5 The role of the HLL is to allow for rograms that are both comact and very readable. The HLL should allow users not familiar with PNs to easily generate correct code. Further, a secification written in the HLL is exected to be considerably more comact than the PN reresentation of the secification and much more comact than the result of the SC and code generation stes. Indeed, the high level secification would not detail how to imlement requirements such as mutual exclusion or liveness. Such details would be handled by the SC tools. Thus, the user would focus more on what needs to be done and less on how it should be done. Moreover, since the high level secification is more comact, the rogrammer would have less code to check for errors. VI. SUPERVISORY CONTROL In the context of concurrent rograms, SC secifications could involve constraints exressed by inequalities, such as (1) (4), constraints involving disjunctions of inequalities [15], and constraints described in terms of languages. The ability to enforce liveness or reversibility is also of great imortance. Secific to concurrent rogramming alications is also the fairness requirement. In its most basic form, it requires that regardless of external events, a rocess waiting for a resource will eventually get access to it. Some of the fairness constraints can be exressed in terms of marking inequalities or Parikh vector inequalities [13]. While some of the aforementioned secifications have simle solutions when the lant is fully controllable and observable, note that artial controllability and observability can arise in certain contexts. Uncontrollable and/or unobservable transitions may be needed in any of the following contexts: - A decentralized environment in which the transitions of one entity are unobservable and uncontrollable to the other entities. - An embedded system environment in which transitions are controllable when they can be controlled by actuators and observable when they can be detected based on sensor information. - A transition associated with an interrut can be considered uncontrollable (such as in [8]). - For certain SC roblems (such as liveness enforcement), transitions labeled by conditions have to be considered uncontrollable. Currently, the SC methods used in this roject are those imlemented in [1]. However, all available SC methods are of interest, including automata based methods. Of secial interest for future work are algorithms and heuristics to find the methods that suit best a given lant and secification. VII. LITERATURE REVIEW Due to the advent of multicore microrocessors, software tools that convert sequential code to arallel code have become increasingly imortant. However, such tools do not affect the need for concurrent rogramming. Exceting secial cases, they cannot convert a sequential algorithm to a arallel algorithm. Thus, concurrent rogramming is still necessary and remains difficult. The alication of the SC, as roosed here, could hel by automating certain asects of the develoment of concurrent rograms, esecially the asects related to the coordination of concurrent tasks. When this aroach is alied, tools converting sequential code to arallel code remain very useful, as they could imrove the execution time of the sequential segments of code of the concurrent rocesses. Note that our roject deals with the develoment of concurrent secifications and not with the conversion of sequential code to arallel code. Related to the SC theory is the aroach for rogram synthesis for reactive systems [19], [8]. The roblem is to synthesize a rogram based on a secification described in temoral logic. In terms of the SC terminology, a rogram would corresond to a suervisor. While currently our roject does not consider temoral logic secifications, these and other classes of secifications could be incororated in the future in order to increase the area of alications. The modeling and analysis of concurrent rograms using PNs has been considered before, such as in [7] and references therein. A software tool PEP has been created for the develoment, verification, and simulation of arallel rograms [], [9]. Comaring our aroach with the aroach of the PEP tool, note that the inut is described by a secification language in our work and by a low-level language in PEP. Our aroach could be used to assist the rogrammer in writing a low-level secification, while the PEP tool can be used to verify a low-level secification. Among other PN based verification aroaches, we mention [6], [6], [7] for Ada rograms. Note that our roject is on correct-by-construction synthesis, not on verification. The scheduling roblem, dealing with the execution order of concurrent tasks, has been aroached based on PN models in references such as [8], [0], [3], [4], [30]. Tyically, the results are on the sequential execution of concurrent rograms on hardware with a single comutational resource. Most often reachability analysis is used for synthesis, though there are also structural results, such as in [4]. Note that in our roject SC is to be used to assist the rogrammer in writing concurrent rograms, not just in solving the scheduling roblem based on a given concurrent rogram. Further, the intent is to focus on structural SC methods, in an attemt to avoid the state exlosion roblem of reachability based methods. Related is also the work on hardware/software codesign of [5]. There, the secification is written in a language such as Esterel [10], from which a network of codesign finite state machines (CFSMs) is extracted. Note that networks of CFSMs corresond to safe PNs [16]. Comared to our roject, while individual rocesses are modeled by state machines, the arallel comosition of the rocess models results in PNs that are tyically not safe. Moreover, we intend to use secifications at a higher level. 338

6 An aroach for finding and correcting otential deadlock situations in software aears in [3]. Given a rogram, a PN model is extracted first. Then, a liveness enforcing suervisor is generated. Finally, the liveness enforcement suervisor is imlemented by additional lines of code in the original rogram. This aroach has been imlemented in the software tool GADARA. Comared to our roject, we deal with rogram synthesis instead of rograms that are already written. In our roject, SC is alied not only for liveness enforcement but also to automate code generation for other requirements that can be exressed in terms of SC secifications. The alication of SC methods to software engineering has also been considered in [1], []. Moreover, certain comuter science methods, such as redicate control for distributed comutations [31] and the aforementioned scheduling aroaches, can be seen as SC methods [16]. The aroaches used to generate control software are also related to the SC. In [11], [9], control software is obtained based on condition system models. Given a condition system model and a secification language describing a sequence of states that the system should follow, control software is automatically generated [3]. Control software can also be generated using the tool Suremica [18], [4] based on finite automata secifications and methods. Note that in our roject, by using PN models, it is ossible to take advantage of both PN methods and automata methods, as automata reresent the reachability sace of PNs. Further, comared to [11], [9], we intend to use more general secifications. VIII. CONCLUSION This aer rooses the alication of suervisory control (SC) for the automatic synthesis of concurrent rograms. The roosed aroach involves three stes. Starting with a rogram descrition written in a high level secification language, a Petri net model and an SC secification is extracted. Then, a suervisor is generated using SC methods. Finally, the suervisor is converted to low level code. SC is of interest because various high level requirements can be seen as suervisory control (SC) secifications. Thus, SC methods or similar methods from related areas of research have to be alied in order to achieve a high degree of automation of the rogramming rocess. REFERENCES [1] A Concurrency Tool Suite. [] PEP homeage. htt://arsys.informatik.uni-oldenburg.de/ e. [3] Sectool homeage. htt:// holloway/sectool. [4] Suremica homeage. htt:// [5] F. Balarin et al. Hardware-Software Co-Design of Embedded Systems: The Polis Aroach. Kluwer Academic Publishers, [6] K. Barkaoui and J.-F. Pradat-Peyre. Verification in concurrent rogramming with Petri nets structural techniques. In High-Assurance Systems Engineering Symosium, ages , [7] E. Best, R. Devillers, and M. Koutny. Petri nets, rocess algebras and concurrent rogramming languages. In Lectures on Petri Nets II: Alications, vol. 149 of LNCS, ages Sringer, [8] J. Cortadella et al. Task generation and comile-time scheduling for mixed data-control embedded software. In Proc. Design Automation Conf., ages , 000. [9] B. Grahlmann. The PEP tool. In Grumberg, O., editor, Comuter Aided Verification, volume 154 of Lecture Notes in Comuter Science, ages Sringer-Verlag, [10] N. Halbwachs. Synchronous Programming of Reactive Systems. Kluwer Academic, [11] L. E. Holloway, X. Guan, and R. Sundaravadivelu. Automated synthesis and comosition of taskblocks for control of manufacturing systems. IEEE Trans. Syst. Man Cyber. Part B, 30(5):696 71, 000. [1] M. V. Iordache and P. J. Antsaklis. Software tools for the suervisory control of Petri nets based on lace invariants. Technical reort isis , University of Notre Dame, Aril 00. [13] M. V. Iordache and P. J. Antsaklis. Suervision based on lace invariants: A survey. Discrete Event Dynamic Systems, 16:451 49, 006. [14] M. V. Iordache and P. J. Antsaklis. Suervisory Control of Concurrent Systems: A Petri Net Structural Aroach. Birkhäuser, 006. [15] M. V. Iordache and P. J. Antsaklis. Petri net suervisors for disjunctive constraints. In Proc. 007 ACC, ages , 007. [16] M. V. Iordache and P. J. Antsaklis. Petri nets and rogramming: A survey. In Proc. 009 ACC, ages , 009. [17] M. V. Iordache and P. J. Antsaklis. Synthesis of concurrent rograms based on suervisory control. Technical reort isis , University of Notre Dame, Setember 009. [18] K. Åkesson, M. Fabian, H. Flordal, and R. Malik. Suremica an integrated environment for verification, synthesis and simulation of discrete event systems. In Proc. 8th Internat. Worksho on Discrete Event Systems, ages , 006. [19] O. Kuferman and M. Vardi. Church s roblem revisited. The Bulletin of Symbolic Logic, 5():45 63, [0] E. A. Lee and D. G. Messerschmitt. Static scheduling of synchronous data flow rograms for digital signal rocessing. IEEE Transactions on Comuters, 36(1):4 35, [1] M. Lemmon and K. He. Suervisory lug-ins for distributed software. In Proc. Worksho on Software Engineering and Petri Nets, ages University of Aarhus, 000. [] M. Lemmon, K. He, and S. Shatz. Dynamic reconfiguration of software objects using Petri nets and network unfolding. In Proc. IEEE Internat. Conf. Syst. Man Cyber., ages , 000. [3] B. Lin. Software synthesis of rocess-based concurrent rograms. In Proc. Design Automation Conf., ages , [4] C. Liu et al. Schedulability analysis of Petri nets based on structural roerties. In IEEE Internat. Conf. on Alication of Concurrency to System Design, 006. [5] J. O. Moody and P. J. Antsaklis. Suervisory Control of Discrete Event Systems Using Petri Nets. Kluwer Academic Publishers, [6] T. Murata, B. Shenker, and S. M. Shatz. Detection of Ada static deadlocks using Petri net invariants. IEEE Transactions on Software Engineering, 15(3):314 36, [7] M. Notomi and T. Murata. Hierarchical reachability grah of bounded Petri nets for concurrent-software analysis. IEEE Transactions on Software Engineering, 0(5):35 336, [8] A. Pnueli and R. Rosner. On the synthesis of a reactive module. In Proc. ACM Sym. Princiles of Programming Languages, ages , [9] D. Shewa, J. Ashley, and L. Holloway. Sectool.4 beta: A research tool for modular modeling, analysis, and synthesis of discrete event systems. In Proc. 8th Internat. Worksho on Discrete Event Systems, ages , 006. [30] F.-S. Su and P.-A. Hsiung. Extended quasi-static scheduling for formal synthesis and code generation of embedded software. In Proc. Internat. Sym. on Hardware/Software Codesign, ages 11 16, 00. [31] A. Tarafdar and V. K. Garg. Predicate control: synchronization in distributed comutations with look-ahead. Journal of Parallel and Distributed Comuting, ages 19 37, 004. [3] Y. Wang, T. Kelly, M. Kudlur, S. Mahlke, and S. Lafortune. The alication of suervisory control to deadlock avoidance in concurrent software. In Proc. 9th Internat. Worksho on Discrete Event Systems, ages 87 9,