Automatic Control, IEEE Transactions on - Semantic Scholar

6 downloads 0 Views 513KB Size Report
F. Lin is with the Department of Electrical and Computer Engineering, Wayne ...... he is a Professor of Electrical Engineering and Computer Science. He was also.
432

IEEE TRANSACTIONS ON AUTOMATIC CONTROL, VOL. 45, NO. 3, MARCH 2000

Design of Nonblocking Modular Supervisors Using Event Priority Functions Yi-Liang Chen, Stéphane Lafortune, Fellow, IEEE, and Feng Lin

Abstract—A new scheme for the modular control of discrete event systems is presented and studied. This scheme, called modular control with priorities (MCP), is an extension of earlier works on modular control in the realm of the supervisory control theory of discrete event systems. The key feature of this scheme is the use of a priority mechanism based on the priority functions of individual supervisors in the process of combining the control actions of individual supervisors. This approach is motivated by both theoretical and practical considerations. The main objective is to use priority functions to mitigate or eliminate the problem of blocking that originates in conventional modular control. In this paper, we first show how to design individual supervisors so that they can operate under MCP. We then show how MCP operates and discuss the resulting properties of this approach. Finally, we present several algorithms for priority assignment to obtain nonblocking behavior under MCP. A motivating example from the area of telecommunications is used throughout the paper. Index Terms—Blocking resolution, discrete event systems, modular control, supervisory control.

I. INTRODUCTION

T

HIS paper studies a new scheme for the modular control of discrete event systems and presents design algorithms for nonblocking modular supervision. This work is set in the framework of the supervisory control theory of discrete event systems ([1]; see also [2] and [3]), and it extends earlier results on modular control [4]. Modular control refers to the situation in which several individual supervisors are jointly controlling a given discrete event system. The key feature of our scheme is that the control actions of the individual supervisors are combined together according to a priority mechanism based on the priority functions of the individual supervisors. Several algorithms are presented for designing such priority functions to obtain nonblocking controlled behavior. We refer to our scheme as modular control with priorities (MCP). MCP is more general than the work in [4], in which the control actions of the individual supervisors are combined together by set intersection (i.e., conjunction). Our approach is different from that in [5] and [6], in

Manuscript received February 20, 1998; revised December 21, 1998 and March 30, 1999. Recommended by Associate Editor, K. Rudie. This work was supported by the National Science Foundation under Grants ECS-9057967, ECS-9312134, and ECS-9315344. This work was performed while Y.-L. Chen was at the University of Michigan. Y.-L. Chen is with the Rockwell Science Center, Thousand Oaks, CA 91360 USA. S. Lafortune is with the Department of Electrical Engineering and Computer Science, The University of Michigan, Ann Arbor, MI 48109-2122 USA. F. Lin is with the Department of Electrical and Computer Engineering, Wayne State University, Detroit, MI 48202 USA. Publisher Item Identifier S 0018-9286(00)02141-3.

which the prioritized synchronous composition operation introduced in [7] is used as the control mechanism connecting the supervisor and the (nondeterministic) system; these differences will be highlighted in Section IV-C after we have presented our scheme. Our use of priorities is completely different from the use of priorities in [8] and [9] for the purpose of calculating special solutions of supervisory control problems with partial event observation. In this paper, all events are assumed to be observable. We note that, in our framework, each individual supervisor is responsible for one control objective; thus, the problem that we consider is different from the work in [10], in which “decision fusion rules” are used to combine the control actions of a set of partial-observation supervisors and all supervisors are trying to ensure the same control objective. Our motivations for considering an MCP are both theoretical and practical. On the theoretical side, it is well known that the conjunction of nonblocking supervisors need not be a nonblocking supervisor unless the respective languages marked by the system under the control of the individual supervisors satisfy the nonconflicting condition defined in [4]. When this condition is not satisfied, blocking can be resolved by restricting the behavior further by computing supremal nonconflicting and controllable sublanguages [11]; however, this approach can be too restrictive on the resulting system behavior (c.f. the example presented in Section II). Thus, it is of interest to attempt to mitigate the blocking problem that originates in modular control by allowing other types of composition of the control actions of the individual supervisors than pure conjunction. On the practical side, we note that the use of priorities is very common in applications to resolve situations of conflict. In particular, we have been motivated to consider a priority scheme by recent work on the problem of “feature interactions” in telecommunications networks in [12]–[14]. We will explain the nature of this problem in Section II. Fig. 1 depicts the MCP considered in this paper. In this issue control actions, scheme, the individual supervisors , based on the trace of events generated so far denoted by by the system , and on the respective requirements that these supervisors are implementing. The coordinator, denoted by , combines these control actions according to the respective priority sets of the supervisors after trace . The function associated with each supervisor is called the priority function of the supervisor. The exact details about the coordinator as well as the role and the design of the priority functions will be presented later. Observe that, if we omit the priority functions is replaced by the conjunction , we get the standard and modular scheme of [4].

0018–9286/00$10.00 © 2000 IEEE

CHEN et al.: DESIGN OF NONBLOCKING MODULAR SUPERVISORS USING EVENT PRIORITY FUNCTIONS

433

iii)

: is the (extended) (partial) state is the Kleene closure transition function of , where of ; is the initial state of ; iv) is the set of marked states of . v) denotes the language generated by and As usual, denotes the language marked by . We will represent supervisors, or control policies, by functions

Fig. 1. Modular controller with priorities.

The contributions of this paper can be summarized as follows. • The new framework for modular supervisory control of discrete event systems depicted in Fig. 1 provides a flexible means to resolve conflicts that could originate because of the modularization of supervisors. • We adopt a state-based approach to capture the notion of a supervisor being in-specification or out-of-specification in the design of MCP supervisors. • We study the system behavior under the supervision of modular supervisors in the proposed framework. We find that the controlled system behavior satisfies the specifications of at least one of the modular supervisors at any time. • We develop algorithms that can synthesize nonblocking modular supervisors by assigning appropriate priority functions. Some of the algorithms rely on given cost values of events in awarding appropriate priority events to modular supervisors. • Partial priority ordering among modular supervisors can be achieved by applying the above algorithms in a proper sequence. Assignments of priority functions made by these algorithms can then be passed on to the modular supervisors through a priority update procedure. Before going into the details of the scheme in Fig. 1, we present in Section II the application area that motivated our work. In Section III we consider the design of the individual supervisors that will operate under modular control with priorities. Section IV presents the MCP scheme and studies some of its properties. Issues regarding blocking in the MCP scheme are also discussed in Section IV. We then present in Sections V–VII different assignment algorithms for the priority functions that guarantee the resulting behavior to be nonblocking. Implementation issues regarding the design of priority functions for operation, as depicted in Fig. 1 are also discussed in Section VII. A. Preliminaries We assume that the reader is familiar with the main results of supervisory control theory. (We adopt, essentially, the same notation as in [1].) We model the discrete event system to be controlled by a finite state machine where i) ii)

is the finite set of events; is the finite set of states of

;

where is the set of enabled events after the trace of events , with the restriction that should never disable a feasible uncontrollable event, i.e., an uncontrollable event for which , is defined. The subset of uncontrollable is denoted by . The behavior of the system events of ; this language under the control policy is denoted by is called the closed-loop behavior and defined recursively as follows: with initial condition ( denotes the empty trace of is defined events). The closed-loop marked behavior as

A supervisor

is nonblocking if

where the overbar notation stands for prefix closure. It has been proven that, given a requirement on the system , a supervisor can be represented by a language if and only if is controldesigned such that -closed [1]; that is, lable and If many requirements are imposed, the supervision can be achieved in the following modular fashion [4]. Each requirement is implemented by a supervisor , and the joint control . It is easy action is then given by to see that the system behavior under the joint supervisor is and In this modular control scheme, the resulting system behavior under the joint control of two nonblocking modular supervisors may be blocking. A well-known necessary and sufficient condition for two individually nonblocking supervisors to result in nonblocking joint supervision is the nonconflicting property [1]. and are nonconflicting Two languages if This nonconflicting condition may, however, be difficult to satisfy and may result in too restrictive a behavior (see Section II). In this paper, we will introduce a new method to resolve blocking by using MCP.

434

IEEE TRANSACTIONS ON AUTOMATIC CONTROL, VOL. 45, NO. 3, MARCH 2000

II. MOTIVATION: THE PROBLEM OF FEATURE INTERACTIONS To motivate our approach of MCP, we will discuss the application area that motivated our work, namely, the problem of feature interactions in telecommunications. This problem has been recognized as a major hindrance to the rapid deployment of new features in telecommunication networks [15], [16]. The definitions of features and feature interactions in telecommunication networks have not yet been standardized (see [17] for discussion). We adopt here the notion of features defined in [15] as “packages of incrementally added functionality providing services to subscribers or the telephone administration.” With the introduction of a new feature, some unanticipated side effects might develop that could cause undesired system behaviors and interfere with the normal functionalities of the existing features, which is called a feature interaction. Unfortunately, without systematic approaches to this problem, detecting and resolving feature interactions relies mainly on the time-consuming efforts of human experts. Hence, to speed the development and deployment of telecommunication services, effective mechanisms to manage feature interactions are essential. We refer the reader to [18] and [19] for related discussions on the problem of feature interactions. To study the problem of feature interactions in the realm of supervisory control, we view telecommunication systems as the composition of numerous distributed components that are modeled individually by finite state machines. Features are implemented as decentralized modular supervisors operating at local switches. Hence, the development of a feature is considered as the problem of designing a modular supervisor. The logical behavior of telecommunication networks is then represented by the resulting system behavior under the joint supervision of modular supervisors. As in [12]–[14], we consider a telephone system of three users (users 1–3). Each user is connected to a corresponding local switch, where a collection of modular supervisors is implemented to control the behavior of the network. The fact that the model considers only three users is not a limitation of our approach; this number of users keeps the exposition simple and, more importantly, suffices to capture the conflicts discussed in our work. The uncontrolled behavior of this telephone system can be modeled by three similar finite state machines that represent event sequences that can be induced by each user as seen at the corresponding switch. Fig. 2 shows the state machine that models the behavior of user 0 as seen at switch 0, denoted .1 State INIT is the initial state of , indicated as by a wedge pointing into the state. It represents the case in which the handset of user 0's telephone is on-hook. When user 0 picks up the handset, that is, event offh0 (off-hook goes to the state CON. In CON, user 0 can 0) happens, hang up the phone—onh0 (on-hook 0), push and then release the hook-switch immediately once—fh0 (flash-hook 0), or twice—dfh0 (double-flash-hook 0). The user can also dial a number, say, that of user 1 (req01), to request the establishment of a connection with user 1. If the switch at site 1 grants the request (con01), the user will receive a ringing 1This

model is an expansion of the model originally presented in [12].

Fig. 2.

G(0): model of event sequence at user 0.

tone and the telephone at site 1 will ring. When user 1 picks up the phone, the vocal connection between site 0 and site 1 is then established. If the switch at site 1 denies the request (nocon01), a busy tone will be heard by user 0. Call transferring functions are also implemented in this model. According to Signaling System 7 (SS7) [20], the information of the forwarding number is returned to the calling party. Hence, when switch 1 decides to forward the call to user 2, instead of transferring the call directly to switch 2, switch 1 notifies its decision to switch 0 through the event fwd012 (0’s call to 1 is forwarded by 1 to 2). Switch 0 then makes a request to switch 2 for establishing connection (req02). Event nocon0 represents the situation where switch 0 denies the forwarding of calls originated from user 0. This event is necessary because whenever switch 0 is informed by other switches that a call needs to be forwarded, it should be able to decide whether to grant the forwarding action (by issuing a request) or not. , as indicated State INIT is the only marked state in by the double-frame in the figure. A sequence of events generated by this model that terminates at the marked state INIT can be considered as the completion of a call processing task (either the connection is established or denied). Note that all event can generate can be extended to reach a sequences that , which means that the (in fact, the only) marked state in is system can always finish some task, eventually. That is, nonblocking. The complete, uncontrolled system for the three-user net, is built by taking the parallel comwork, denoted as position (also termed synchronous composition) of the models of all users

CHEN et al.: DESIGN OF NONBLOCKING MODULAR SUPERVISORS USING EVENT PRIORITY FUNCTIONS

435

TABLE I

6(0): THE EVENT SET AT SWITCH 0

where and differ from only in the permutation is of indexes. The event set of , where the are mutually disjoint. Not all events in the global event set can be observed at a local switch. The set of events that are observable at switch is de. Likewise, not all events can be disabled through noted as the control actions taken at a local switch. The only events con. trollable at switch form the controllable event set at . The set of events that can never be disabled is denoted as are observable and conTable I illustrates which events in trollable at each local switch. Similar relations hold for and . In the illustrative example in this paper, we will consider the design of the supervisors at local switch 0 only. Therefore, the onto . That plant to be controlled is the projection of , where : is the stanis, dard natural projection [21]. In this paper, we will consider two features, terminating call screening (TCS) and call forwarding (CF), and study their interaction. More features are studied in [13] and [14]. TCS is a feature that allows a user to avoid receiving calls made from some unwanted numbers in a “screening” list prescribed by the user. The specification model of TCS for user 0 to screen out calls from user 2, denoted as , is shown in Fig. 3, where is the event . This model achieves its requirement by set of simply denying the occurrence of events con20, fwd201, . From this specification, we can obtain and fwd202 in the legal language that describes the behavior of the system in the presence of TCS. Because every sequence of events , the legal in the legal language must be possible in . The language is given by , can be obtained generator for this legal language, and : by taking the parallel composition of . It can be verified is controllable and -closed. Hence, that the requirement of TCS can be enforced by a nonblocking . supervisor that implements The second feature under consideration, CF, redirects all calls for a user to a preassigned number. As shown in

Fig. 3.

CSpec

: specification model for TCS at switch 0.

Fig. 4.

CSpec

: specification model for CF at switch 0.

Fig. 4, models the specification of CF for user 0 to transfer all of his/her calls to user 1’s telephone. This model adopts the strategy to disable other possible outcomes, except for events to forward calls to user 1 once requests have been made. The corresponding legal language can be implemented because it is both controllable and -closed. However, the languages and are conflicting. Examining the combined ma, we can find that blocking occurs chine, whenever user 2 calls user 0 while user 0 requests all incoming calls to be redirected to user 1’s location. The approach that has been studied so far in the literature to resolve blocking in the joint controlled behavior under the conventional modular supervisory scheme is to find the “largest” controllable and nonconflicting sublanguages of the languages generated under the sole control of each modular supervisor. Techniques to find the supremal controllable nonconflicting sublanguage are presented in [11]. The modular supervisors are then modified accordingly to achieve these sublanguages.

436

IEEE TRANSACTIONS ON AUTOMATIC CONTROL, VOL. 45, NO. 3, MARCH 2000

However, this approach does not always work because the “largest” controllable and nonconflicting sublanguages found could be empty sets, which is the case in the present TCS and CF interaction. Moreover, even if those sublanguages are nonempty, the resulting system behavior under the joint control of these modified supervisors may be too restrictive and the intended functionality of some supervisors may be lost. Unfortunately, no proper approach exists under the conventional modular control scheme to resolve the conflicts caused by such loss of functionality. An alternative (and intuitive) way to resolve conflicts used in many practical problems is to use priorities and to allow some modular supervisor to temporarily override the control actions issued by other supervisors. For example, in the conflict between TCS and CF, when user 2 calls user 0 (i.e., req20), we should allow the supervisor for TCS to enable event nocon20, which overrides the decision of the supervisor for CF that disables nocon20. However, to ensure that the effect of the override will only last temporarily and that the supervisor whose decision is overridden will be able to resume its control on the system behavior correctly, the modular supervisors must be equipped with certain mechanisms to keep track of the current system behavior. Motivated by the above discussion, we present in this paper a new framework for modular supervisory control that employs a priority mechanism and allows us to temporarily override individual control actions. We call this new framework MCP. In MCP, control requirements are specified by finite state machines, in which a special set of “out-of-specification” states are used to model the situations when the requirements are violated. The individual control actions of modular supervisors implementing these requirements are also defined on the states of their corresponding state machines. We adopt this “state-based” approach because, in a purely language-based approach, it would be very complex, if not impossible, to characterize the effect of event priorities and temporary overrides on the system behavior. For discussions about how the MCP approach can help in alleviating the feature interactions problem, please refer to [14]. III. STATE-BASED DESIGN OF INDIVIDUAL SUPERVISORS In this section, the design procedure of an individual supervisor to be used in the MCP scheme is described. First, we show how to build a state-based model that represents the given requirements on the intended system behavior. Then, we present the supervisor synthesis procedure in our approach. A. State-Based Specifications In the conventional modular control scheme, a requirement to be imposed on the system behavior is usually specified by . In our MCP approach, a rea language , where quirement will be specified by a state-based specification model, . This specification model is a state machine denoted as consisting of the five usual components The state space of , denoted as , is divided into two and , where the states in are called disjoint subsets,

In-Spec states and the states in are called Out-of-Spec , is in . We assume that the states. The initial state, marking of states is solely specified by the uncontrolled system here, and when model . Hence, we set is composed with later in Section III-B, the proper marking will be specified. consisting of all states If we denote the submachine of (but none in ) and of all corresponding transitions in , the language generated by , among them as , should represent the intended behavior specified is the by the requirement. More precisely, analog of the “legal language” in the language-based approach to our state-based specification modeling. The main characteristic of our state-based specifications is the employment of are used Out-of-Spec states. These Out-of-Spec states in to account for the situations when the system is forced to go out of the desired set of In-Spec states in a specification model by some other supervisor(s) temporarily. They are also used to specify how the system behavior can return to In-Spec states. In order to work properly under our MCP scheme, a specification model Spec should always satisfy the following two conditions. should account for Condition 1: A specification model . That is, , all possible traces in : is a natural projection and is the where event set of . is not accessible in , it Condition 2: If a state in , where is an Out-of-Spec state. That is, denotes the accessible part of the machine . Note that, in order to build the specification model Spec, we that represents can first build the accessible submachine the intended behavior under the requirement (as we would proceed in building a finite state machine representation of the legal is obtained by expanding the state space language). Then, , i.e., by adding some Out-of-Spec states to the state of space and adding the corresponding transitions such that Condition 1 is satisfied. The precise manner in which these new states and transitions should be added is problem-dependent. It is a modeling issue intricately connected to the modeling of itself and to the requirements imposed on . Example 1 [Telecommunications Example]: In Fig. 5, we show a possible MCP specification model of the TCS feature at switch 0 that allows user 0 to screen out calls from user 2, . This model is constructed from the denoted as (conventional) specification model of the TCS feature described earlier. State INIT is the only In-Spec state, and state OUT is the single Out-of-Spec state that is added to the model. Because user 0 does not want to receive calls from user 2, the occurrence of events that could possibly connect user 2 to user 0 (i.e., con20, fwd201, and fwd202) will take the system from the In-Spec state INIT to the Out-of-Spec state OUT. The system behavior then stays in OUT until user 2 hangs up the phone (onh2). Fig. 6 presents an MCP specification model, denoted as , for the CF feature at switch 0 that redirects all calls for user 0 to user 1’s telephone. The above example is too cumbersome to serve as a simple illustrative example of the results of this paper, because it in-

CHEN et al.: DESIGN OF NONBLOCKING MODULAR SUPERVISORS USING EVENT PRIORITY FUNCTIONS

437

Fig. 5. The MCP specification model for TCS at switch 0. Fig. 7.

G: the state machine model of the system.

Spec

Fig. 8. respectively.

Fig. 6. The MCP specification model for CF at switch 0.

volves a few hundred states. For this reason, we will also use the following modified and simplified example in the sequel. Example 2 [Illustrative Example]: We consider the uncontrolled system modeled by the state machine shown in Fig. 7. For simplicity, we assume that all events in are controllable. Two requirements are imposed on the system behavior: Requirement 1: The resulting system behavior should not have any traces containing event . Requirement 2: The resulting system behavior should not have any traces containing event . : Define the conventional modular supervisors as follows, for all : and Clearly, supervisors and satisfy Requirements 1 and 2, respectively. Moreover, it can easily be shown that the (or ) is system behavior under the supervision of nonblocking. However, in the conventional modular control

and

Spec

: specification models for Requirements 1 and 2,

scheme, the system will block if these two supervisors are applied simultaneously. Two types of blocking can occur under the joint supervision. A deadlock occurs when the system is in disables and disables . state 1 of , where Moreover, once the system enters state 2 or 3 of , because disables out of state 3 while disables out of states 2 and 3, the system can only loop between these two states and cannot reach the marked state 0 anymore, which results in a livelock. Note that states 1–3 are reachable under and . Normally, each the joint supervision of requirement would be represented by a single-state machine with the appropriate set of self-loops. As a possible way to construct the MCP specification models, we can introduce an Out-of-Spec state to each of the single-state machines and then add the corresponding transitions to satisfy Condition 1. The resulting specification models for requirements 1 and 2, and , respectively, are shown in Fig. 8, where Out-of-Spec states are shaded. B. Synthesis of Individual Supervisors In the previous subsection, we described the construction of the specification model for a given requirement on the system behavior. We now present the procedure to build an individual supervisor to implement this specification model. Given a specification model Spec, we start by constructing a state machine called by following the three-step procedure.

438

IEEE TRANSACTIONS ON AUTOMATIC CONTROL, VOL. 45, NO. 3, MARCH 2000

Construction of Machine : by taking the parallel com1) Construct state machine and . That is, , , , , position of . , , , , that satisfies 2) Build state machine

and where i) is the supremal controllable and ii) the symbol desublanguage of notes “submachine” (in the sense of subgraph; see, e.g., using [22]). Many different ways exist to construct standard techniques in the literature; an efficient construction procedure that can be used to build is presented in is a subma[9, Appendix A]. Note that, because (i.e., ), (c.f. previous subchine of . section), it can be shown that , , , , , 3) State machine is obtained as , , , , , . State machine differs only in the introduction of the set of legal states, from , which equals of . For convenience, we define . Note that the set of illegal states as and . Example 3 [Illustrative Example (Con’t.)]: Continuing our illustrative example with the specification models introduced in Example 2, if we assume for simplicity that all events are confor . The corretrollable, we get that and are shown in Figs. 9 and 10, respectively, sponding where the illegal states are shaded. Once has been obtained, the task of specifying the desired individual control policy requires the following definitions. For , where is the state space of , define all states and (called the active event set and legal active event set at , respectively) as follows: is defined if if Note that, for a trace , we have that denotes the active event set at implies i) in this case. We now use the state machine policy as

Fig. 10.

.

R

R

: the realization for Spec .

: the realization for Spec .

(1)

such that in

Fig. 9.

, where . This result is because and ii)

to define the desired control

State machine is called the realization of the control policy of the individual supervisor. According to this definition, when the system is in a legal state (in ), the supervisor will enable only the events that lead to legal states. It is necessary to defor all , including those traces for which fine , because under the proposed priority scheme, it

will be possible for the requirement modeled by Spec to be vio, we define to lated. In this case, i.e., when . We will see later the effect be of this definition on the priority scheme. State machine of Step 2 in the construction of is called the legal machine of the individual supervisor . This machine represents the (accessible) system behavior under the sole supervision of , as shown in the following proposition, whose proof is straightforward. Proposition 1: . 1) . 2) , . 3) , the system behavior Therefore, because satisfies the requirement modeled by if is the only supervisor present.

CHEN et al.: DESIGN OF NONBLOCKING MODULAR SUPERVISORS USING EVENT PRIORITY FUNCTIONS

Example 4 [Illustrative Example (Con’t.)]: Continuing from , is Example 3, the control policy of the supervisor for

:

439

of each supervisor

policy, : defined as follows,

, denoted by ,

, the coordinated control , is :

if if otherwise The control policy for , and its corresponding behavior can be obtained similarly. The realization plays a very important role in our scheme: it carries the notion of desired system behavior in terms of the legal states upon which the control policy is defined. Mean, it provides the information for while, because the supervisor to follow the system passively once the system moves out of the legal states in , and to resume control after the system returns to one of the legal states. This process will become clear in Section IV-B. It is worth noting that the above synthesis procedure is consistent with that of the supervisory control problem (SCP) originally proposed and solved in [23]; see also the basic supervisory control problem—nonblocking case (BSCP-NB) in [3]. IV. MODULAR CONTROL WITH PRIORITIES With the construction of the individual supervisors and the associated system behaviors discussed in the previous section, we now move on to present our MCP. First, we define the priority function of each individual supervisor. Then, the definition of the coordinated control policy is given and the properties and physical meaning of the coordinated control policy are also examined. The construction of a realization that represents the system behavior under this scheme is presented. Finally, we discuss the issue of blocking in our scheme. A. Priority Functions and Joint Control Policy Let us consider the situation depicted in Fig. 1 of Section I, where several individual (MCP) supervisors issue control actions based on their common observations of the system behavior and a coordinator, , is used to implement the priority mechanism that produces the final control action. employs the control policy based on its Each supervisor , , , , , , corresponding realization which is constructed from some state-based specification by the procedure discussed in Section III. In order to coordinate individual supervisors in a flexible way, we introduce in the MCP scheme a priority function for each individual supervisor. Formally, the priority function of supervisor is defined as a function : with the restriction for all . That is, at every state in that the realization , the priority function of supervisor returns that we call the priority set of at ; the a set of events priority set of at an illegal state is always empty. and the priority The coordinator takes the control action of each individual supervisor as inputs and set , to the system. Given sends the coordinated control action, , and the priority function, the control policy, :

That is, an event belongs to the coordinated control action if and only if i) it is in the control action of every individual supervisor that has it in its priority set and ii) if it is in none of the priority sets of these individual supervisors, it must be in the control actions of all of these supervisors. The closed-loop behavior is defined recursively in the usual manner. Note that, , we have that . from the definition of is empty for all , for all , Moreover, if ; this equality motivated the above condition ii). The priority functions are designed to achieve various objectives, such as nonblocking, the property of interest in this paper; for other objectives, see [24]. We will address the issue of how to synthesize priority functions to resolve blocking among modular supervisors in Sections V–VII. In the remainder of this section, we assume that the priority function of a supervisor is given. Example 5 [Illustrative Example (Con’t.)]: Continuing from Example 4, the priority functions of individual supervisors and (which are realized by and , respectively) could be defined as follows: if if and if if . This choice of priority functions was made based on intuitive considerations and will be used in the remainder of this illustrais discussed in tive example. The controlled behavior Example 6; it is nonblocking. B. Properties of the MCP Scheme We now examine some properties of the priority mechanism defined previously. First, consider the situation in which only and , are in this scheme. It two individual supervisors, can be shown that the coordinated control policy, , has the following equivalent representations:

(2)

(3)

440

IEEE TRANSACTIONS ON AUTOMATIC CONTROL, VOL. 45, NO. 3, MARCH 2000

From (2), we can see that the coordinated control action after trace contains i) the events enabled by both individual supervisors after and ii) the events enabled by only one of the supervisors and are in the priority set of the supervisor that enables them, but not in the priority set of the other supervisor. In other words, regarding the events in both/none of the priority sets, both supervisors have the same power in disabling these events. On the other hand, regarding the events in one of the priority sets, but not in the other, the supervisor whose priority set contains these events has the sole power in the decision process and the other supervisor cannot veto the enablement/disablement of these events in should they be allowed/disallowed by the first supervisor. We include (3) because it is useful in proving the associativity of this priority mechanism, which will be discussed later. can also be written by The coordinated control policy the states in individual realizations, as shown in the following proposition. We omit the proof of this proposition as it is straightforward. be the realization of . For Proposition 2: Let with all can be expressed as follows. 1) If

2) If 3) If 4) If Define the priority function, joint supervisor as

. . :

Properties (of Jointly Supervised Behavior): P.1) From Proposition 1, Part 3, an individual supervisor cannot “force” the system to move from a legal state to an illegal state in its own realization. P.2) The system behavior can move out of the legal states of an individual supervisor only via some event that is in the priority set of some other supervisor, but not in the priority set of this supervisor at that time. This property is a consequence of the definitions of individual control policy and of joint control policy . P.3) Once the system behavior moves into some illegal state of a supervisor, this supervisor becomes “idle” and follows the system behavior passively, because this supervisor cannot disable any event in this case (refer to Section III-B). P.4) An individual supervisor cannot “force” the system to ) of other sugo out of the legal state sets (i.e., pervisors when the current system behavior is in an illegal state of its realization, because of the restriction imposed on the priority function that requires the priority set of an illegal state to be empty (refer to Section IV-A). conP.5) The system behavior under tains the closed-loop behavior resulting from the conventional modular control approach; i.e.,

and . , of the

Then, associativity holds under this priority mechanism. , Proposition 3: Given three individual supervisors, and , and their corresponding priority functions, the following : equation is true: for all

(4) The proof of Proposition 3 is obtained by applying (3) and some set simplification methods; it is omitted here. Because the priority mechanism is associative, the expression of the coordinated control policy in the two-supervisor case shown in (2) can be generalized to the -supervisor case. The : corresponding priority function under the joint supervision of supervisors, and , is defined as

The system behavior under the joint control policy of the following properties.

has

Therefore, from the above properties, we can conclude this subsection with the following theorem, which is vital to the success of the MCP scheme. . Then, for all Theorem 1: Let , exists such that . That is, at any time, at least one of the individual supervisors is in its legal state set. Proof: Follows directly from Proposition 1 and the defini, and tions of individual control policy , priority function joint control policy . Note that, in the MCP scheme, an individual supervisor will never make an unrealistic attempt to disable a feasible, but uncontrollable event to satisfy the given requirement when the supervisor is in a legal state of its realization. This assurance is given by Step 2 of the construction procedure for its corresponding realization described in Section III-B, where the controllability issue is resolved. From Theorem 1, we know that under the joint supervision at least one of the individual supervisors is in a legal state. Meanwhile, from Sections III-A and IV-A, an individual supervisor simply enables all feasible events and has an empty priority set when it is in an illegal state of its realization. Hence, we can conclude that the joint control policy will also never attempt to disable a feasible, but uncontrollable event. Although Theorem 1 guarantees that at any time at least one of the individual supervisors is in its legal state set, it does not

CHEN et al.: DESIGN OF NONBLOCKING MODULAR SUPERVISORS USING EVENT PRIORITY FUNCTIONS

address the issue of whether each supervisor will eventually be in its legal state set along a trace of the controlled behavior. This problem is beyond the scope of this paper; related work on this topic can be found in [24]—c.f. the property of functionality discussed therein. We also note that, in the applications that have motivated the MCP scheme, such as the problem of feature interactions, the system has a “reinitialization” property (e.g., termination of a call) that ensures that a temporarily overridden supervisor returns to its legal state set. C. Realization of Supervised Behavior In Section IV-A, we have described how to construct , re. However, it is somesulting in the supervised system times convenient to have a legal machine that generates as well as a realization of (“legal machine” and “realization” here are to be interpreted as in Section III-B). In this subsection, we will discuss how to construct such a legal machine and reof the individual supervisors alization from the realizations that compose the MCP. For simplicity, we will discuss only the . The method can however be extended to more case of than two supervisors by the associativity property of . (with control Let two individual supervisors , ) and their corresponding policies and priority functions , , , , , be given. realizations , where We would like to find a generator for or simply if , are understood from the context. First, define a new , as the product of and . That is, state machine, , , , , . Second, modify the of to as follows: transition function if

undefined

441

for

. Meanwhile, . . For all

. Therefore, ii) We now show that . Because imply

, and and for and ii) , we conclude that . Hence, . Therefore, .

In view of Theorem 2 and of our earlier definition of realization, the desired realization for is

where the (additional) seventh component of : , is called the illegal transition function of . The transitions defined in this illegal transition function are transitions between two legal states of that are not allowed (enabled) by the joint supervisor. Formally, if and

is undefined

undefined, otherwise. This new component in is necessary for the realization of a joint supervisor because some transitions could occur between legal states that will never be allowed by the joint supervisor. In , we need to modify the notion view of the introduction of of legal active event set given in (1) for machine . The active , and legal active event set, , of at event set, are defined as follows: state is defined

otherwise

and is undefined

if

(5)

That is, at every state , the transition function retains only the transitions from defined in that will be allowed (enabled) under the joint supervision. Then, the legal machine of the joint supervision

if . It can be shown that the joint control action after a trace equals the legal active event set at the corresponding state in the joint realization; i.e.,

generates the language as shown in the following theorem. Theorem 2: . 1) . 2) Proof: Part 1) Straightforward from the definition of above and using the characterization of given in Proposition 2, Part 1. by definition Part 2) Because , it is equivalent to prove that and, from Part 1, . . For all i) First, we show that such that , because for . That is,

The realization of a joint supervisor has one more component (i.e., the illegal transition function) than the realization of an individual supervisor defined in Section III-B. The illegal transition function is not necessary in the case of an individual supervisor. For the sake of uniformity, if we wish that the realization of an individual supervisor have the same structure as that of a joint supervisor, we could add a (fictitious) illegal transition as the seventh component to the realization of an function individual supervisor given in Section III-B. The illegal transition function would be defined as undefined where is the state space of the realization of an individual supervisor. With this addition, the legal active event set of an individual supervisor previously defined in (1) in Section III-B

442

IEEE TRANSACTIONS ON AUTOMATIC CONTROL, VOL. 45, NO. 3, MARCH 2000

and reserve the term individual supervisors to situations when only the supervisors constructed by the procedure presented in Section III can be used. Remark 2: By now, we can clearly see that our MCP scheme is different from the prioritized synchronous composition (PSC) [7] in several ways. First and foremost, MCP is a scheme specifically designed for modular control of a system, whereas PSC is a general operation for composition of processes. No notion of “legal” and “illegal” states in PSC exists, and these two sets are at the core of the MCP paradigm. (We explained earlier the motivation for these two sets.) This characteristic is why our problem could not be formulated in the context of PSC. In MCP, priority functions change with states and, in particular, they depend on . In PSC, the priority sets are fixed and no notion of the set exists. With the help of , we can define of legal states legal and illegal behaviors while leaving the language generated unchanged: . Another by , the tran(albeit technical) difference is that, even within sitions defined in our scheme are different from those of PSC: can occur only if both and an event enable it; in contrast, in PSC it will be executed if one of the processes executes it. D. Blocking Issues in MCP Fig. 11.

R: the realization for the joint supervisor .

would be modified to an equation similar to (5) (with all subscripts removed). Example 6 [Illustrative Example (Con’t.)]: We can construct and in our the realization for the joint supervision of illustrative example when using the priority functions of Example 5. This is shown in Fig. 11, where illegal states and and illegal transitions are shaded.2 Note that, in states , although disables event can be executed by the system under joint supervision because it is in the priority set of (but not in that of ) and enabled by in that state. Supervisor then becomes inactive once is executed in states or and remains inactive until the system again. We can see from Fig. 11 that the enters state system behavior under the joint supervision is not blocking; i.e., . Remark 1: As shown in this subsection, the construction of the joint supervisor is consistent with that of an individual supervisor. The legal machine and realization of the joint supervision have the same structures as those of individual supervisors. The joint control action can be obtained from the state of the joint realization in the same way that the individual control action is defined on an individual realization. In fact, joint supervisors can usually be treated as individual supervisors, and most of the properties of individual supervisors hold for joint supervisors. The construction procedure in this subsection will still or are themselves joint supervisors. Hence, work when we shall use the term constituent supervisors in the situations whenever individual and joint supervisors are both applicable 2For convenience, we have simplified the labels of the states shown in Fig. 11 [e.g., state (A; C; 0) is equivalent to state ((A; 0); (C; 0))].

One of the main reasons for using priorities in modular control is to overcome blocking, which occurs when . It is convenient to characterize the notion of blocking for a supervisor by its realization , or more precisely, its legal machine . For this purpose, we define the notion of a blocking entity as follows. Definition 1 [Blocking Entities]: A set of states of a legal ) is a blocking entity if machine (i.e., , does not exist such that such that That is, a blocking entity of a legal machine is a strongly connected component that i) cannot reach any states not in and ii) does not contain a marked state in . Using this definition, we conclude that an MCP supervisor is nonblocking if and only if no blocking entities exist in its corresponding legal machine. Note that every individual supervisor, , is nonblocking by construction in the MCP scheme (see Section III-B). in a legal machine , in To detect the blocking entities practice, it is usually more efficient to i) first perform the coaccessibility analysis of states in to marked states, ii) apply standard algorithms of finding strongly connected components (e.g., the algorithm in [25, Section 23.5]) to the part of that is not coaccessible to marked states. These strongly connected components are then the blocking entities in . The running time of in the worst case. this procedure is Note that, in our MCP scheme, the nonconflicting condition is neither necessary nor sufficient for nonblocking joint superand . Given vision of nonblocking individual supervisors the fact that i) we incorporate state information in specifying

CHEN et al.: DESIGN OF NONBLOCKING MODULAR SUPERVISORS USING EVENT PRIORITY FUNCTIONS

requirements and ii) the system behavior under the joint supervision could move between legal states and illegal states of the realization for an individual supervisor, we believe that it is not appropriate, if not impossible, to use a purely language-based approach to characterize the conditions for nonblocking joint supervision in the MCP scheme. Hence, the best way thus far in checking for nonblocking joint supervision in the MCP scheme is to construct the joint realization and apply standard algorithms for detecting strongly connected components to check for the existence of blocking entities. The priority mechanism provides a flexible means to resolve blocking among constituent supervisors working in a modular fashion. If priority functions of the constituent supervisors are assigned appropriately, a constituent supervisor may be able to lead the system out of the potentially blocking situation by “forcing” the execution of an event in its current priority set. In the rest of the paper, we present several techniques that allow systematic assignments/modifications of priority functions to individually nonblocking supervisors to generate a nonblocking joint supervisor under the MCP scheme. It is worth noting that one intuitive way to assign priority functions to resolve blocking under the MCP scheme is to simply assign all events to the priority function of a nonblocking constituent supervisor and set the priority functions of all other constituent supervisors to empty sets. However, the resulting system behavior in this case is usually unsatisfactory because it equals the system behavior under the sole supervision of the constituent supervisor to which we gave the priority. Other constituent supervisors are virtually “disabled,” and their objectives can never be achieved. In contrast, the priority assignment algorithms to be presented in the following sections assign/modify appropriate priorities to resolve blocking if necessary while trying to preserve the objectives of the constituent supervisors. OF MIXED PRIORITY FUNCTIONS TO RESOLVE BLOCKING

V. DESIGN

In this section, we present two algorithms that do not commit to always giving priorities to the same supervisor whenever conflicts occur. The first (iterative) algorithm can be applied without any assumptions on the uncontrolled system behavior, and the second (noniterative) algorithm is used when the marked system is livelock-free [26]. behavior For the algorithms presented in this section, we assume without loss of generality that the state spaces of the constituent realizations and the state space of the joint realization are the . If this assumption is not true, same; that is, and we first construct the joint realization from the given

443

. Then, it is straightforward to build from machine that refines the realization with respect to , for . is the same as that of and a subjective The state space of exists, for , such that function : The priority functions of the constituent supervisors are then upby dated to the refined state space for all . New , and are obtained simin ilarly. We then use the refined constituent realizations in the algorithm. The complexity of obtaining place of is . A. General Case Given two nonblocking MCP supervisors , and their corresponding legal machines, , and realizations, , , , , , , , we present an algorithm that and such that the assigns appropriate priority functions is nonblocking. (Recall our resulting joint supervisor .) assumption that for each The algorithm requires that a cost value with respect to the constituent supervisor event , be given. This positive cost value is a design parameter that represents a certain “measurement” (such as the cost of execution) or preference of the particular event with respect is then the sum of to the supervisor.3 The cost of a trace in the cost values of the event labels along this trace. For each constituent realization , we define a state-based cost function : (where is the set of positive real numbers) and : as shown in (6) at the bottom of the page. A simple algorithm that proceeds in a breath-first manner similar to that in [25, Section 23.2] can be used to determine proper values of and for all states in , with the worst-case run. Directly from the definitions of and ning time of , we have the following lemma. Lemma 1:

We propose to assign priorities by proceeding iteratively as follows. In each iteration, we detect all blocking entities that exist in the current joint legal machine. For each blocking entity, we select a state in either of the constituent legal machines value among the states in the such that has the smallest blocking entity (i.e., a state that has “the smallest cost to reach 3Alternatively,

we could define the cost value on each transition  (1; 1) in

R , which would give us a finer measurement.

the smallest cost among the costs of all traces from to the set going through states in only,

if otherwise

the first event label along one of the above if smallest-cost traces from to undefined,

otherwise

(6)

444

IEEE TRANSACTIONS ON AUTOMATIC CONTROL, VOL. 45, NO. 3, MARCH 2000

a marked state”). We then assign to the priority set of the corresponding constituent supervisor at state and remove from the priority set of the other constituent supervisor, if necessary. The iterative procedure continues until the resulting system is nonblocking or the monotonically increasing function reaches an upper bound. The resulting priority functions (where stands for Mixed will be denoted by case). Algorithm 1 (Priority Assignment: Mixed Case): and , determine the values of and 1) For for all states in of the realizations . . Build the corresponding legal machine 2) Let and realization of the joint supervisor , , , where and are the initial priority functions. and 3) While there exist blocking entities in do: a) Let be the number of blocking entities found in . this iteration. Set (note that b) For each blocking entity , pick ) such that . Define

where and for all other states

define

c) Build the corresponding and of the . joint supervisor 4) Let be the last iteration of the previous step. Then, , . To show that Algorithm 1 can indeed assign priority functions appropriately to generate a nonblocking joint supervisor, we adopt the following four-step reasoning: i) Lemma 2 will show that any state picked at Step 3b) was never picked prerepresents the viously; ii) this implies that the function number of states that have been picked after the th iteration as shown in Corollary 1; iii) because this function increases monotonically, in Theorem 3, we show that the algorithm will stop after a finite number of iterations; and, finally, iv) Theorem 4 shows that, when the algorithm stops, the joint supervisor using the final priority assignments is nonblocking. that Lemma 2: In Algorithm 1, at Step 3b), the state , for and . is picked satisfies Proof: Suppose not, then, for the state or such that and and this assignment was made in a prior iteration. Then (otherwise could not be a blocking i) entity);

ii) , by Lemma 1. This is a contradiction of the way that was picked. Corollary 1: The number of states for which or , after the th iteration equals and thus this number strictly increases after each iteration. Proof: The first part of the statement follows directly from Step 3 of Algorithm 1 and Lemma 2; the last part then follows immediately from Step 3a) of Algorithm 1. Theorem 3: Algorithm 1 terminates in finite steps. Proof: Directly from Corollary 1 and Step 3 of the algorithm. Theorem 4: is nonblocking. Proof: From Theorem 3, the algorithm terminates in finite steps. If Algorithm 1 terminates because no blocking entities in in Step 3 exist, the joint supervisor is by definition nonblocking. Suppose Algorithm 1 terminates because in Step 3. Then, from Corollary 1, Lemma 2, and Theorem 1, we know that every unmarked state was picked and the priority sets at were modified during the execution of the algorithm. Hence, for every unmarked state , because , where is the legal active event set at (see Section III-B). That is, all events along the smallest-cost trace to marked states are from every unmarked state in enabled. Moreover, from Lemma 1, the cost of a state to marked , strictly decreases along the smallest-cost trace to states, . Hence, every marked states determined by the function can reach a marked state (or is itself is state in a marked state) under the joint supervision, which implies that can reach a state in . Therefore, the joint every state in supervisor is nonblocking. Steps 1 and 2 of Algorithm 1 are in the worst case. From Corollary 1 and Theorem 3, the algorithm has at (more precisely, ) iterations of Step most . Hence, 3, and each iteration of Step 3 runs in time . the worst-case running time of Algorithm 1 is Example 7 [Illustrative Example (Con’t.)]: Continuing from our illustrative example, a simple (and often natural) way to assign cost values to events is to set the cost value of every event in to one for both constituent supervisors. Hence, the cost equals the number of transitions in this trace. of a trace in and are iniLet us assume that the priority functions of tially empty at all of their states. Because the state spaces of these realizations are not the same, we apply the procedure described at the beginning of this section to refine them to maand , which have the same state space as that chines of the machine in Fig. 11. Applying Algorithm 1, we find that in the first iteration two blocking entities exist: and , . Because and are the smallest values in their respecand are added to the priority sets, tive blocking entities, and , respectively. The reis shown in Fig. 12. sulting nonblocking joint realization Example 8 [Feature Interactions]: Consider the three-user telephone system described in Section II. We implement the

CHEN et al.: DESIGN OF NONBLOCKING MODULAR SUPERVISORS USING EVENT PRIORITY FUNCTIONS

(a) Fig. 13.

Fig. 12.

R

: the resulting joint realization for the mixed case.

TCS feature (for user 0 to screen out calls from user 2) and the CF feature (that redirects calls for user 0 to user 1’s phone) as modular MCP supervisors at switch 0 based on the MCP specifiand presented cation models in Section III. The uncontrolled plant has 72 states. We assume that the priority functions for the TCS and CF supervisors conare initially empty. The resulting joint realization tains 399 states, among which 126 states are legal and the initial state is the only marked state. Applying the procedure of detecting blocking entities outlined in Section IV-D, we can find a blocking entity of 24 states. This blocking entity corresponds to the conflict between the TCS and CF features when user 2 calls user 0, as described in Section II. to one If we set the cost value of every event in for both TCS and CF supervisors, by applying Algorithm 1, we find at the first iteration that at state [where the five components of represent the corresponding states in the state machines , and , respectively] of the blocking entity, we have the smallest cost function values [where and are the cost functions for TCS and CF supervisors, respectively] among the cost function values of all states in the blocking entity. Because both TCS and CF have the same cost function value at , Algorithm 1 can assign either to the priority set of TCS supervisor at or to that of CF supervisor at to resolve the conflicts. In a different scenario, we assign the cost values of all forwarding events to be two and set the cost values of other events

445

(b)

(a) R and (b) R in Example 9.

to be one, which implies that we consider forwarding a call more costly than other operations. In this case, we find that the same state still has the smallest cost function value among all states in the blocking entity found in the first iteration of Algorithm 1. However, the cost function value of CF , now becomes three. Hence, the algosupervisor at to the priority set of TCS rithm assigns supervisor at to resolve the blocking. In both cases, Algorithm 1 terminates after the first iteration and the resulting joint supervisor after the modification is nonblocking. It is necessary to iterate in Algorithm 1 because the assignment of priorities to one constituent supervisor will make the joint legal machine visit states or transitions that could not be reached before. These new behaviors could in turn produce some new blocking entities. The following example illustrates this concern. Example 9 [Iterative Example]: Consider the realizations and , for nonblocking constituent supervisors and , respectively, shown in Fig. 13. Observe that the state spaces of and are the same. Assume that the priority functions of these constituent supervisors are empty at all states in the realizations initially and that the cost values of all events equal one. We apply Algorithm 1 to assign priority functions appropriately to obtain a nonblocking joint supervisor. , As shown in Fig. 14(a), the initial legal machine, that is detected in contains a blocking entity the first iteration of the algorithm. Because is the smallest value among those of the blocking values include entity [other , and ], the priority function at state is set as . of However, the resolution of the blocking entity detected in the first iteration creates a new blocking entity , as indicated in Fig. 14(b). This blocking entity is then found in the second iteration. By assigning at to [because priority function ],

446

IEEE TRANSACTIONS ON AUTOMATIC CONTROL, VOL. 45, NO. 3, MARCH 2000

(a) Fig. 14.

(b)

Legal machines (a) R and (b) R in Example 9.

the blocking entity is resolved. The legal machine in Fig. 14(c) shows that the resulting behavior is nonblocking after two iterations of the algorithm. Algorithm 1 uses state-based cost functions in aiding the selection of states and events to which the priority is awarded. For each blocking entity detected, it adopts a “hill-climbing” strategy that picks the state of a constituent realization whose cost to marked states is the smallest. By proper tuning of the event costs, a user can therefore control the degree to which each supervisor is prioritized in the solution produced by the algorithm. We emphasize the important point that Algorithm 1 results in a “locally minimum” solution by the number of modifications made to the priority functions for achieving nonblocking joint supervision. We focus on this property of the algorithm in the remainder of this subsection. We record each modification of priority functions during the , where execution of Algorithm 1 as a triple is the th blocking entity found in the th iteration of the i) is the state picked for whose priority algorithm, ii) indicates the constituent sets were changed, and iii) whose priority set at was awarded the priority realization [i.e., ]. Let of event be the set of modifications made by running Algorithm and . The following 1 on the joint MCP supervision of theorem shows that Algorithm 1 applies a (locally) minimum set of modifications to the priority functions that results in a nonblocking joint supervisor. and , the modifications Theorem 5: For all result in a blocking joint supervisor. of priority functions by Proof: Please refer to [24]. B. Livelock-Free Case In this subsection, we discuss the assignment of priority functions when the marked system behavior is livelock-free. As deis livelock-free if fined in [26],

where is the length of , and denotes that is a prefix is livelock-free of , which is equivalent to saying that

if and only if each directed cycle in the state machine contains at least one marked state. In the context of the MCP scheme, we have the following lemma. Lemma 3: Let be the state machine for the uncontrolled be the legal machine of the controlled system system and under ( can be an individual supervisor, or where and are constituent supervisors). Then, we have that is -closed; 1) is livelock-free, then is livelock-free. 2) if Proof: Part 1) i) Because . Hence, . ii) Because . Therefore, is -closed. is -closed and Part 2) Because from Part 1 , the result can be obtained directed from [26, Lemma B.3].4 From the second part of Lemma 3, we know that, if is livelock-free, the resulting (marked) behavior of the joint su, is also livelock-free. Hence, pervisor contains at least one marked state, every directed cycle in which means that the only possible blocking entities in are single-state blocking entities, namely, deadlock states. Based on this observation, the following simple algorithm can assign appropriate priority functions to constituent nonblocking superviand , so that is nonblocking, given that sors is livelock-free. By doing so, we avoid iterating, in contrast to Step 3 of Algorithm 1. The resulting priority functions (where stands for livewill be denoted by lock-free case). Algorithm 2 (Priority Assignment: Livelock-Free Case): 1) Build the corresponding legal machine and realization of the joint supervisor , where and initial priority functions. 2) Define the set of potential deadlock states

are the as

where is the legal active event set at . Find all potential deadlock states. , pick or and 3) For each . Set

and

4) Build the corresponding and of the joint super. visor , for all 5) Reassign the priority functions . That potential deadlock states that are not reached in 4Reference

[26, Lemma B.3]: Let

M -closed. Then, L is livelock-free.

M

be livelock-free, and let

LM

be

CHEN et al.: DESIGN OF NONBLOCKING MODULAR SUPERVISORS USING EVENT PRIORITY FUNCTIONS

is, for all ), for of

(where

is the state space

, set

(Note that will not be changed by this reassignment.) Algorithm 2 first identifies all the potential deadlock states , regardless whether they can be reached in the in joint supervised behavior or not. Note that there are no poten, since tial deadlock states in the constituent supervisor that is not in a legal state will follow passively while the other supervisor (which is in a legal state) is nonblocking. For each potential deadlock state , an event in the legal active event set of one constituent supervisor is picked. This event must exist because the two constituent supervisors are themselves nonblocking. Meanwhile, this event must not be in the legal active event set of the other constituent supervisor, or the system would not block at this state. The assignment of the priority sets ensures that the event can occur at this state in the joint supervisor. Finally, the priority functions are reset to the initial conditions at all potential deadlock states that cannot be reached under the resulting joint supervisor. Note that this and , and it algorithm does not need to calculate . The correctness has a worst-case running time of of this algorithm is shown in the following theorem. is nonblocking. Theorem 6: is livelock-free, from Lemma Proof: Because is livelock-free, where is the legal ma3 . Hence, the only posare deadlocks. Assume that is blocking, then a (reachable) exists such that . unmarked state , because is not a marked state, i) If , but from Steps 3 and 5 and the definition of the , joint control action in the MCP scheme, where is the event picked in Step 3. , by definition. Beii) If cause is not marked and is a nonblocking supervisor, . , similarly, . iii) If , which contradicts Hence, cannot be a deadlock state in our assumption. Therefore, the resulting joint supervisor is nonblocking. Because the above algorithm is not iterative, it can be adapted for online execution: whenever a potential deadlock state is and or detected, the algorithm will pick such that . This event is then appended to and removed from if necessary. chine of sible blocking entities in

VI. DESIGN

OF DOMINANT PRIORITY TO RESOLVE BLOCKING

FUNCTIONS

We now investigate priority assignment algorithms that always give priorities to a designated constituent supervisor whenever conflicts occur in the joint supervisor. First, we discuss design techniques under the assumption that the state

447

spaces of the constituent supervisors and the joint supervisor are the same. Then, we present design techniques in which this assumption is relaxed. A. Design Techniques Based on State Space of Joint Realization With the assumption that the constituent supervisors and the joint supervisor have the same state space, algorithms that always assign priorities to a designated constituent supervisor whenever necessary can be readily obtained from the algorithms presented in the previous section. For the general case, Algorithm 1 can be modified so that only the and values of the dominating constituent supervisor are determined in Step 1 and only the values of the dominating constituent supervisor are considered in Step 3b). Similarly, for a livelock-free system , we modify Algorithm 2, so that in Step 3, only an event in the legal active event set of the dominant constituent supervisor can be picked to resolve the potential deadlock. The correctness of these modified algorithms is easily demonstrated by straightforward modifications to the proofs of the correctness of Algorithms 1 and 2. The worst-case running times of these modified algorithms are the same as those of the algorithms described in Section V. It is worth noting that the algorithms described above (as well as those presented in the next subsection) guarantee that the resulting joint behavior can never violate the requirement imposed by the dominating constituent supervisor. It does not mean that the other constituent supervisor does not have any effect on the joint behavior. The notion of dominance applies only when conflicts (i.e., blocking entities) occur. B. Design Techniques Based on State Spaces of Constituent Supervisors In this subsection, we relax the assumption on the state spaces made in the previous subsection; namely, the state spaces of the realizations of the constituent supervisors need not be the same. Hence, the refinement procedure mentioned at the beginning of Section V need not be performed. As in the case of Algorithm 1, we assume the cost values of all events with respect to the dominant constituent supervisors are given. Given two nonblocking MCP supervisors and , the following algorithm will assign an appropriate priority function to each constituent supervisor such that the resulting joint superis nonblocking. In this algorithm, priorities are alvisor ways given to supervisor whenever conflicts exist. That is, is the dominant supervisor between the two individual supervisors. The resulting priority functions will be denoted by (where stands for dominant case). Algorithm 3 (Priority Assignment: Dominant Case): and for all states in of 1) Determine the values of . the realization . Build the corresponding legal ma2) Let and realization of the joint supervisor chine , where and are the initial priority functions. Initialize the Boolean for all . function

448

IEEE TRANSACTIONS ON AUTOMATIC CONTROL, VOL. 45, NO. 3, MARCH 2000

3) While there exist blocking entities in and do: a) Let be the number of blocking entities found in . this iteration. Set b) For each blocking entity , pick such that . Define

and for all other states define

Set . and of the c) Build the corresponding . joint supervisor 4) Let be the last iteration of the previous step. Then, . and need to be Unlike Algorithm 1, only the values of determined in Algorithm 3. Note that the Boolean function Flag is introduced solely for the proof of the correctness of the algorithm; it keeps track of whether the algorithm has assigned priorities to a state. For each blocking entity found in each iterthat has the smallest value is ation, the state is then appended to the priority set of picked. The event at and removed from the priority set of at , if necessary. To show the correctness of the algorithm, we adopt an approach similar to that used for Algorithm 1. Lemma 4: In Algorithm 3, at Step 3b), the state that is picked satisfies . implies Proof: Suppose not, then, and , and the assignments were made in some prior iterations. Then (otherwise could not be a blocking i) entity); , by ii) Lemma 1. This is a contradiction of the way that was picked. Corollary 2: The number of states for which after the th iteration equals , and thus it strictly increases after each iteration. Proof: The first part of the statement follows directly from Step 3 of Algorithm 3 and Lemma 4; the last part then follows immediately from Step 3a) of Algorithm 3. Theorem 7: Algorithm 3 terminates in finite steps. Proof: Directly from Corollary 2 and Step 3 of the algorithm. Theorem 8: is nonblocking. Proof: From Theorem 7, the algorithm terminates in finite steps. If Algorithm 3 terminates because no blocking entities in in Step 3 exist, the joint supervisor is by definition nonblocking.

Suppose Algorithm 3 terminates because in Step 3. Then, from Corollary 2 and Lemma 4, we have that, for every unmarked state because , where is the legal active event set at (see Section III-B). Meanwhile, for every unmarked state because the control policy of in an illegal state enables . That is, all events along every possible event including the smallest-cost trace (with respect to ) from every unmarked to marked states are enabled. Morestate in over, from Lemma 1, the cost of a state to marked states (with , strictly decreases along the smallest cost respect to ), . Hence, trace to marked states determined by the function in can reach a marked state (or it itself is a every state under the joint supervisor, which implies marked state) in can reach a state in . Therefore, the that every state in joint supervisor is nonblocking. From Corollary 2 and Theorem 7, the algorithm has at most (more precisely, ) iterations of Step 3 and each iteration of Step 3 runs in time (which is the worst-case running time for finding the blocking ). Hence, the worst-case runentities in the joint realization . ning time of Algorithm 3 is Similarly to Algorithm 1, Algorithm 3 adopts a “hill-climbing” strategy, which results in a locally minimum solution by the number of modifications to the priority functions made for achieving nonblocking joint supervision. This property of Algorithm 3 can be characterized by a theorem similar to Theorem 5 (details omitted). Finally, observe that, if the initial priority function of supervisor 2 is empty, we have that

Example 10 [Illustrative Example (Cont.)]: Continuing from Example 7, we assume that the cost value of every event is set to one and the priority functions in with respect to and are empty at all of their corresponding states of initially. In this example, we want to always give priority to whenever conflicts exist. Because the assumption of the and is relaxed, we can apply same state space for dominating instead of ). Algorithm 3 directly (with and , Again, two blocking entities, are found in the first iteration. Event is added to for the first blocking entity. However, although , event is assigned to for the second blocking entity. The resulting is shown in Fig. 15. nonblocking joint realization Example 11 [Feature Interactions (Cont.)]: For the interaction between the TCS feature and the CF feature described in Example 8, intuitively, we should favor the TCS supervisor in resolving the interaction, which is because user 0 does not want to hear from user 2 anyway. Hence, we apply Algorithm 3 to our example and assign priority events to states in the TCS realization whenever necessary. We assume that the priority functions

CHEN et al.: DESIGN OF NONBLOCKING MODULAR SUPERVISORS USING EVENT PRIORITY FUNCTIONS

449

Fig. 16. The partial ordering of priorities among supervisors in Example 12.

discuss procedures that assign appropriate priorities to multiple constituent supervisors in one step to result in a nonblocking joint supervisor. Then, we focus on techniques that assign priorities and resolve conflicts in an incremental manner. A. One-Step Blocking Resolution ), Given a set of constituent supervisors (where , we now discuss how to assign priority functions to the constituent supervisors so that the joint supervisor

Fig. 15.

R

: the resulting joint realization for the dominant case.

for TCS and CF are empty initially and that the cost values of all events in TCS are set to one. In the first iteration, we find the same blocking entity of 24 states that was described in Example 8. Examining the cost funcof the TCS feature among the TCS part of the states tion has the smallest in the blocking entity, we find that value of two at state of the individual realization for TCS [where the four comporepresent the corresponding states in the state nents of ], and , remachines spectively). Hence, we assign event to the priority set of TCS realization at state to resolve the blocking. The resulting joint supervisor is nonblocking after this modification. For a livelock-free system, an algorithm for dominant priority assignment similar to that presented in Section V-B, but without the assumption of same state space can be obtained by suitably modifying Algorithm 2. Note that one of the variations is that for some potential instead of picking any event , we can try to “reuse” some event deadlock state , which has already been picked to resolve other in or , where potential deadlock states and . This variation can reduce the size of the priority . set at states in VII. RESOLVING BLOCKING FOR MORE THAN TWO CONSTITUENT SUPERVISORS In this section, we investigate blocking resolution techniques for dealing with more than two constituent supervisors. We first

is nonblocking. The algorithms presented in Sections V and VI can be readily extended to achieve this goal in a single step. To assign mixed priority functions to multiple constituent supervisors, we modify Algorithm 1 such that the and values of all constituent supervisors are determined in Step 1. In Step 3b), the values of all constituent supervisors are considered and the priority functions of all constituent supervisors are updated accordingly. For a livelock-free system, Algorithm 2 is modified so that in Step 3 the event that is chosen to resolve the potential deadlock can be picked from the legal active event set of any of the constituent supervisors. The state spaces of all constituent supervisors should be the same for these two algorithms to be applicable. Finally, Algorithm 3 can be used to give preference to a predetermined constituent supervisor among multiple supervisors, except that the joint realization of these supervisors is used in detecting blocking entities in this case. B. Incremental Blocking Resolution In the previous subsection, we described one-step procedures for priority assignment to multiple constituent supervisors to resolve blocking. However, blocking among multiple constituent supervisors can also be resolved in an incremental manner. Incremental blocking resolution is preferable when the constituent supervisors are introduced sequentially in the system. Moreover, partial ordering of priorities among a given set of supervisors can be achieved by applying priority assignment algorithms incrementally. The following example illustrates this idea. Example 12 [Partial Ordering of Priorities]: Given six con, we want to generate a nonstituent supervisors, blocking joint supervisor according to the partial ordering of priorities among the constituent supervisors shown in Fig. 16 has priority over and , and so on). (where

450

IEEE TRANSACTIONS ON AUTOMATIC CONTROL, VOL. 45, NO. 3, MARCH 2000

A nonblocking joint supervisor can be obtained by applying Algorithms 1 and 3 in the following order:

The notation gorithm 1 to Algorithm 3 to

in the above equation means applying Aland . Similarly, stands for applying and

, where

is the dominant supervisor.

Although the joint control policy of multiple constituent supervisors can be implemented as a single (joint) supervisor based on the joint realization and legal machine obtained at the end of the process of priority assignment, it is more likely (and preferable in practice) that the joint control policy will be implemented in a modular manner, as depicted in Fig. 1, i.e., as a set of “individual” supervisors with one coordinator. If blocking among supervisors is resolved in one step by the procedures described in the previous subsection, the priority functions of the supervisors are updated during the procedure and the modular control scheme of Fig. 1 can be readily implemented. However, if blocking is resolved incrementally, because only the priority functions of various intermediate constituent supervisors are modified, a “priority updating” procedure to “push down” the changes of priority functions along the process to the original constituent supervisors is required before implementation. We now present an algorithm for this purpose. (with priority function ) be a conLet stituent supervisor that is the joint supervisor of individual (with corresponding priority supervisors ). Further, we assume (without loss of genfunctions , where erality) that and are the state spaces of the realizations of and . If we apply a priority assignment algorithm to , Algorithm 4 can update that modifies , to such that the priority functions of , is an arbitrary constituent supervisor with priority where . Note that the priority assignment algorithm used function to is not restricted to the algorithms to modify presented in Sections V and VI. Algorithm 4 applies to any priority assignment procedure in which the following two assumptions hold. A.1) (where

is the set of legal states in

).

A.2) (where

is the legal active event set at .

The purpose of Assumption A.1 is to be consistent with one of the basic assumptions in the MCP scheme (see Section III-B), namely, that the priority set is empty at any illegal state. Assumption A.2 means that the priority assignment algorithm removes from the priority set only events that are already disabled by this supervisor. This assumption is not restrictive when we assign priorities to “enlarge” the joint behavior to resolve blocking. The removal of originally enabled events from the priority set does not “enlarge” the joint behavior; this is why we have not considered this strategy to resolve blocking. Note that all algorithms presented in Sections V and VI satisfy Assumptions A.1 and A.2. Algorithm 4 (Priority Update): For all do: , for do: 1) if , if ; , for do: 2 if . and Algorithm 4 compares priority functions at each state . If an event was added to the joint priority set by the priority assignment algorithm, it appends to the priority sets of all individual supervisors, where is a legal state. Algorithm 4 removes an event from the priority sets of all the individual supervisors if is removed by the priority assignment algorithm. The running time of Algorithm . 4 is The simplest way to prove the correctness of Algorithm 4 (this is done in is to first show that it is correct when Theorem 9) and then to show that incremental application of Algorithm 4 to pairs of supervisors produces the same result as a single application of it to a set of supervisors (this is done in Proposition 4). . Let Theorem 9: Let be changed to by a priority assignment algorithm that , is changed satisfies Assumptions A.1 and A.2. If by Algorithm 4 to

for all admissible constituent supervisors . Proof: Please refer to [24]. Let be the joint supervisor that results from individual , with their respective priority funcsupervisors . The following proposition shows that, when the joint tions is changed to by some priority aspriority function signment algorithm, applying Algorithm 4 directly to update the priority functions of the three individual supervisors produces the same result as first applying Algorithm 4 to update the priand (where ) and then ority function of and by applying Alupdating the priority functions of . Denote the gorithm 4 on the updated priority function of updated individual priority functions by the first approach (di, and denote the updated inrect approach) as dividual priority function by the second approach (indirect ap. proach) as

CHEN et al.: DESIGN OF NONBLOCKING MODULAR SUPERVISORS USING EVENT PRIORITY FUNCTIONS

Proposition 4:

Proof: Immediate by Algorithm 4 and the definition of . The correctness of Algorithm 4 for arbitrary is then obtained immediately from Theorem 9 and Proposition 4. Note that Proposition 4 implies that, regardless of how a joint supervisor is produced (incrementally or directly) from a set of individual supervisors, whenever the joint priority function is changed, the priority functions of the individual supervisors can be updated by applying Algorithm 4 only once. Hence, the priority functions of individual supervisors need not be updated constantly along the design process; they need only be updated by Algorithm 4 right before the implementation. VIII. CONCLUSION We have presented a new scheme for modular control of discrete event systems in which the individual supervisors have associated priority functions that play a central role in determining the coordinated control action of these supervisors. Central to our approach is the fact that a supervisor can be forced out-of-specification when its control action is overridden because of the priority sets of other supervisors at a given time. We have adopted a state-based approach to capture the notion of a supervisor being in-specification or out-of-specification and to specify the priority function of a supervisor, which has led us to propose a specific construction procedure for supervisors, so that they can properly function in our modular control scheme with priorities. This process has also led us to the development of different priority assignment algorithms for the individual supervisors that ensure nonblocking under joint supervision. We note that the MCP scheme can also be used to resolve other issues such, as “functionality,” defined and considered in [24]. Among possible topics for future research, we mention: i) extension of the priority scheme to the case of partial event observation; ii) development of online priority assignment schemes that do not require constructing the joint realization to deal with the state explosion problem for systems with many interacting components; and iii) development of heuristics for appropriately choosing the event cost function used by the priority assignment algorithms based on the application of interest. REFERENCES [1] P. J. Ramadge and W. M. Wonham, “The control of discrete event systems,” Proc. IEEE, vol. 77, pp. 81–98, Jan. 1989. [2] J. G. Thistle, “Supervisory control of discrete event systems,” Math. Comput. Model., vol. 23, no. 11/12, pp. 25–53, 1996. [3] C. Cassandras, S. Lafortune, and G. Olsder, “Introduction to the modeling, control and optimization of discrete event systems,” in Trends in Control. A European Perspective, A. Isidori, Ed. New York: SpringerVerlag, Sept. 1995, pp. 217–291. [4] W. M. Wonham and P. J. Ramadge, “Modular supervisory control of discrete-event systems,” Math. Contr. Signals Syst., vol. 1, no. 1, pp. 13–30, 1988. [5] M. A. Shayman and R. Kumar, “Supervisory control of nondeterministic systems with driven events via prioritized synchronization and trajectory models,” SIAM J. Contr. Optim., vol. 33, pp. 469–497, Mar. 1995. [6] R. Kumar and M. A. Shayman, “Nonblocking supervisory control of nondeterministic systems via prioritized synchronization,” IEEE Trans. Automat. Contr., vol. 41, pp. 1160–1175, Aug. 1996.

451

[7] M. Heymann, “Concurrency and discrete event control,” IEEE Contr. Syst. Mag., vol. 10, pp. 103–112, June 1990. [8] N. Ben Hadj-Alouane, S. Lafortune, and F. Lin, “Think globally, communicate, act locally: On-line parallel/distributed supervisory control,” in Proc. 33rd IEEE Conf. Decision Contr., Orlando, FL, Dec. 1994, pp. 3661–3666. , “Centralized and distributed algorithms for on-line synthesis of [9] maximal control policies under partial observations,” J. Discrete Event Dynam. Syst.: Theory Applicat., vol. 6, pp. 379–427, Oct. 1996. [10] J. H. Prosser, M. Kam, and H. G. Kwatny, “Decision fusion and supervisor synthesis in decentralized discrete-event systems,” in Proc. 1997 Am. Contr. Conf., June 1997, pp. 2251–2255. [11] E. Chen and S. Lafortune, “On nonconflicting languages that arise in supervisory control of discrete event systems,” Syst. Contr. Lett., vol. 17, pp. 105–113, Aug. 1991. [12] J. G. Thistle, H.-H. Hoang, and R. P. Malhamé, “Modélisation et analyse du traitement des appels téléphoniques par 1’approche de Ramadge-Wonham: Rapport préliminaire,” École Polytechnique de Montréal, Montréal, P.Q., Canada, Tech. Rep. EPM/RT-93/15, Aug. 1993. [13] J. G. Thistle, R. P. Malhamé, H.-H. Hoang, and S. Lafortune, “Feature interaction modeling, detection and resolution: A supervisory control approach,” in Feature Interactions in Telecommunications IV. New York: IOS Press, June 1997, pp. 93–107. [14] Y.-L. Chen, S. Lafortune, and F. Lin, “Resolving feature interactions using modular supervisory control with priorities,” in Feature Interactions in Telecommunications IV. New York: IOS Press, June 1997, pp. 108–122. [15] T. F. Bowen, F. S. Dworak, C. H. Chow, N. D. Griffeth, and Y.-J. Lin, “Feature interaction problem in telecommunication systems,” in Proc. 7th Int. Conf. Softw. Eng. Telecommun. Switching Syst., July 1989, pp. 59–62. [16] E. J. Cameron, N. Griffeth, Y.-J. Lin, M. E. Nilson, W. K. Schnure, and H. Velthuijsen, “A feature-interaction benchmark for IN and beyond,” IEEE Commun. Mag., vol. 31, pp. 64–69, Mar. 1993. [17] E. J. Cameron and H. Velthuijsen, “Feature interactions in telecommunications systems,” IEEE Commun. Mag., vol. 31, pp. 18–23, Aug. 1993. [18] N. Griffeth and Y.-J. Lin, Eds., IEEE Commun. Mag., Aug. 1993, vol. 31. , Computer, Aug. 1993, vol. 26. Companion to the special issue of [19] IEEE Commun. Mag., vol. 31, Aug. 1993. [20] A. R. Modarressi and R. A. Skoog, “Signaling System no. 7: A tutorial,” IEEE Commun. Mag., vol. 28, pp. 19–35, July 1990. [21] F. Lin and W. M. Wonham, “On observability of discrete-event systems,” Inform. Sci., vol. 44, pp. 173–198, 1988. [22] S. Lafortune and E. Chen, “The infimal closed controllable superlanguage and its application in supervisory control,” IEEE Trans. Automat. Contr., vol. 35, pp. 398–405, Apr. 1990. [23] P. J. Ramadge and W. M. Wonham, “Supervisory control of a class of discrete event processes,” SIAM J. Contr. Optim., vol. 25, pp. 206–230, Jan. 1987. [24] Y.-L. Chen, “Modular discrete event systems: Modeling, control with priorities, and incremental model evolution,” Ph.D. dissertation, Dept. Elect. Eng. Comput. Sci., Univ. Michigan, Ann Arbor, Aug. 1997. [25] T. H. Cormen, C. E. Leiserson, and R. L. Rivest, Introduction to Algorithms. Cambridge, MA: MIT Press and McGraw-Hill, 1990. [26] S. Lafortune and F. Lin, “On tolerable and desirable behaviors in supervisory control of discrete event systems,” J. Discrete Event Dynam. Syst.: Theory Applicat., vol. 1, pp. 61–92, May 1991.

Yi-Liang Chen received the B.S.Eng. degree in electrical engineering from National Taiwan University, Taiwan, in 1991 and the M.S.Eng. and Ph.D. degrees in electrical engineering: systems from The University of Michigan, Ann Arbor, in 1994 and 1997, respectively. He has been with the Rockwell Science Center, Thousand Oaks, CA, since 1997, where he is a Research Scientist. His current research interests include discrete event systems (modeling, control, diagnosis), model-based diagnostics, condition-based maintenance, system auto-configuration, and enterprise control.

452

Stéphane Lafortune (M’86–SM’97–F’99) received the B.Eng. degree from École Polytechnique de Montréal in 1980, the M.Eng. degree from McGill University in 1982, and the Ph.D. degree from the University of California at Berkeley in 1986, all in electrical engineering. He has been with the University of Michigan, Ann Arbor, since 1986, where he is a Professor of Electrical Engineering and Computer Science. He was also an Invited Professor at École Polytechnique de Montréal in 1993. His research interests include discrete event systems and intelligent transportation systems. Recent publications are available at the website www.eecs.umich.edu/umdes. Dr. Lafortune received the Presidential Young Investigator Award from the National Science Foundation in 1990 and the George S. Axelby Outstanding Paper Award from the Control Systems Society of the IEEE in 1994 (for a paper co-authored with S. L. Chung and F. Lin). He is on the Editorial Board of the Journal of Discrete Event Dynamic Systems: Theory and Applications and has served as Associate Editor (1993–present) and Associate Editor At Large (1996–1998) of the IEEE TRANSACTIONS ON AUTOMATIC CONTROL.

IEEE TRANSACTIONS ON AUTOMATIC CONTROL, VOL. 45, NO. 3, MARCH 2000

Feng Lin received the B.Eng. degree in electrical engineering from Shanghai Jiao-Tong University, Shanghai, China, in 1982 and the M.A.Sc. and Ph.D. degrees in electrical engineering from the University of Toronto, Toronto, Ont., Canada, in 1984 and 1988, respectively. He was a Postdoctoral Fellow at Harvard University, Cambridge, MA, from 1987 to 1988. Since 1988, he has been with the Department of Electrical and Computer Engineering, Wayne State University, Detroit, MI, where he is currently an Associate Professor. His research interests include discrete-event systems, hybrid systems, robust control, image processing and neural networks. Dr. Lin co-authored (with S. L. Chung and S. Lafortune) a paper that received the George Axelby Outstanding Paper Award from the IEEE Control Systems Society. He is also the recipient of a research initiation award from the National Science Foundation, an outstanding teaching award from Wayne State University, a faculty research award from ANR Pipeline Company, and a research award from Ford Motor Company. He was an associate editor of IEEE TRANSACTIONS ON AUTOMATIC CONTROL.