Designing communicating transaction processes ... - Semantic Scholar

Form Method Syst Des DOI 10.1007/s10703-006-0023-0

Designing communicating transaction processes by supervisory control theory L. Feng · W. M. Wonham · P. S. Thiagarajan

C

Springer Science + Business Media, LLC 2006

Abstract A Communicating Transaction Process (CTP) is a computational model that serves as a high level specification language for reactive embedded system components and their interactions. It consists of a network of communicating processes coordinating their behaviors via common actions and the common actions are refined as a set of guarded Message Sequence Charts (MSCs). There has been little work devoted to developing CTP models systematically. This paper takes the first step towards bridging this gap. In our work, communicating processes of embedded components are modeled and controlled as DiscreteEvent Systems (DES). The control logic among communicating components is derived by Supervisory Control Theory (SCT), so as to guarantee that the communicating processes meet all predefined constraints and possess other desirable system behavioral properties. The control logic is then translated into propositional formulas for guarded MSCs which then results in a CTP model with guaranteed behavioral properties. Keywords Communicating transaction processes . Message sequence charts . Supervisory control . Discrete-event systems 1. Introduction A Communicating Transaction Process (CTP) is a computational model that serves as a high level specification language based on Message Sequence Charts (MSC) [16]. The CTP

L. Feng () · W. M. Wonham Systems Control Group, Department of Electrical and Computer Engineering, University of Toronto, Toronto, ON, Canada, M5S 3G4 e-mail: [email protected] W. M. Wonham e-mail: [email protected] P. S. Thiagarajan School of Computing, National University of Singapore, S16 Level 5, 3 Science Drive 2, Singapore, 117543 e-mail: [email protected] Springer

Form Method Syst Des

formalism can be viewed as a highly structured Petri net, consisting of a network of communicating components that interact via common actions [25, 26]. The model emphasizes the notions of components and their interactions in a two-level hierarchical form. At the (higher) framework level, a network of labeled transition systems that synchronize on common actions represents the sequences of the transitions and the connecting relationships among the components. The actions in the framework level model are named transaction schemes. At the (lower) transaction level, each transaction scheme is refined as a collection of guarded MSCs, which are named transactions. MSCs elaborate the interactions while highlighting the roles played by the components taking part in a transaction. The guard of an MSC is a propositional formula built from atomic propositions and predicates to describe a predefined operational condition. Each transaction represents some possible communicating operations and involves a flow of data and control signals among the processes participating in the transaction. The framework level CTP model determines when a transaction scheme is to be executed, but which transaction within the transaction scheme will be chosen and what exactly the communicating components will do are determined by the guards of the MSCs in the transaction level model. CTP models are intended for the system level design of embedded systems. It is commonly accepted that, in system level design contexts, the computational models that are deployed should have a clean separation of computational and communicational features [2, 9, 11]. Thanks to their two-level structure, CTP models meet this requirement and nicely balance the modeling efforts for control flow and component interactions. With the assistance of CTP models, designers can gain useful insights into complex systems. Furthermore, a CTP model can also be converted to executable representations from which one can hope to derive hardware/software implementations. In particular, CTP models can be automatically translated to SystemC [11]. The design of a good CTP model for a complex system is, however, a nontrivial task. The usual design paradigm—involving any Model of Computation (MOC) for that matter—follows an iterative scheme: modeling and verification. A complete design process may involve several iterations. At the first step, a designer must propose a tentative CTP model based on his experience and understanding of the given system. To arrive at a correct and complete collection of guarded MSCs for a transaction scheme, the detailed interactions among the participating components and the control logic for their concurrent actions must be specified clearly and completely. This is the most challenging part of the whole design scheme. Since there are limited tools to guide the design, and the definition of CTP models imposes almost no syntactic restrictions, the model obtained at this step may well be problematic, especially for complex systems. For example, certain operational constraints among the concurrent components may be violated, control logic for some actions may be incorrect, and the model may contain unintended deadlocks. To avoid these pitfalls, the tentative CTP model must be verified at the second step. Two approaches are now available for the verification of CTP models. The first is to translate the CTP model into a Live Sequence Chart (LSC) and run a simulation through the play engine mechanism developed in the LSC framework [12]; while the second is formal verification. Two methods for formal verification suggest themselves for the formal verification of CTP models. The first one is to translate a CTP model into a Petri net [25]. Various system behavioral properties of CTP models can be defined and checked via the corresponding Petri net properties, such as boundedness, liveness, and deadlock freedom [20]. Alternatively, one can apply model checking tools, like SPIN [15] and SMV [3]. Whichever method is used, if the verification result is positive then the tentative CTP model is acceptable and the design Springer


process can proceed to the implementation phase; if the result is negative, the model has to be modified and the design process starts a new iteration. Evidently the above design paradigm demands much expertise and is time consuming. Moreover, while the paradigm may produce an acceptable model, it cannot assure its optimality. By an optimal model, we mean one allowing maximal freedom to the interacting components; optimality in turn admits more implementation possibilities. To reduce design difficulty and assure an optimal model, this paper presents a new paradigm for designing CTP models. Our paradigm consists of only two steps and no iteration is needed. The first step is to model the communicating system as a Discrete-Event System (DES) [5] consisting of a network of automata. Then the detailed interaction among concurrent components and the control logic for each action can be deduced systematically, instead of empirically, by Supervisory Control Theory (SCT) [23]. The second step is to translate the obtained information into propositional formulas for the guarded MSCs of each transaction scheme and thus construct a CTP model. According to SCT, the control logic generated by this means is correct by construction and is optimal with respect to both the operational constraints and the system’s behavioral properties. In principle, no further formal verification is necessary and the design iteration process is simplified (though detailed simulation may still be required for performance analysis). The paper is organized in six sections. Section 2 provides the needed background on Supervisory Control Theory. Section 3 delineates a typical communicating process of an embedded system, which is used as an illustrative example throughout the paper. The two steps of our paradigm are illustrated in detail in Sections 4 and 5. Finally Section 6 summarizes the new design paradigm and concludes the paper.

2. Supervisory control theory A discrete-event system (DES) is a dynamic system that evolves in accordance with the instantaneous occurrence of physical events at unknown and irregular intervals [13, 23]. For example, the communicating actions between the components in an embedded system can be envisioned as such events. A supervisory controller can keep a DES from undesirable behavior by disabling certain events in its dynamic process. To do so, supervisory control theory (SCT) has been developed for the monitoring and control of various complex (discreteevent) systems in a wide range of application domains such as manufacturing, robotics, vehicular traffic, logistics, computer and communication networks [4, 7, 17, 18, 24]. There are several possible approaches to model, analyze and control discrete-event systems, including automata [23], Petri nets [14], and max-plus algebra [8]. SCT is directly based on regular language theory and algebraic principles. Hence it is independent of the models that implement the systems. In this paper, we apply the automaton approach, originated by Ramadge and Wonham [22, 23], to the analysis and control of communicating processes, because of the intrinsic duality between regular languages and finite state automata. Compared to other modeling approaches, the approach enables us to solve our control problems synthetically by optimization algorithms. Ramadge and Wonham’s supervisory control paradigm separates the concept of plant (open-loop dynamics) from the feedback control so that traditional control theoretic notions such as controllability, observability, modularity, decentralized and hierarchical control, can be exploited. In applications, the plant is modeled as an automaton (G). The event set in the automaton G is its alphabet (). The desirable behavior of the controlled system Springer


is determined by a control specification, also modeled as an automaton (E). The control specification must be enforced by the supervisory controller for the plant. A monolithic supervisor, or alternatively a group of modular supervisors, is the supervisory controller that closes the loop of a controlled DES and forces the plant to respect the control specifications. This controller acts only to disable certain events that are originally able to occur in the plant, thus preventing them from occurring. Thus the control logic of a supervisory controller is derived from the event disablement list at each state. In practice, we may assume that some events in the alphabet can never, or need not be disabled. Such events are called uncontrollable, while those preventable by a supervisory controller are called controllable. Hence, the alphabet is partitioned into two disjoint subsets, controllable events ˙ u. ( c ) and uncontrollable events ( u ), such that = c ∪ To synthesize a satisfactory supervisor, Wonham [30] has suggested a formal method for theoretically tackling the typical supervisory control problem: ˙ u and control specificaGiven a plant G over alphabet with its partition = c ∪ tions modeled as E, find a minimally restrictive supervisor S such that the controlled system S/ G is nonblocking and always meets the control specifications. In the above, it should be noted that (1) a minimally restrictive supervisor provides maximal freedom for the controlled DES, for given plant and control specifications; (2) a nonblocking system can always reach certain predefined marker states. The nonblocking property of an automaton can be used to define many system behavioral properties, such as deadlock freedom and reversibility. The physical meaning of nonblocking is that the system can successfully complete its tasks. 3. A typical network of communicating processes We will illustrate the method through a typical network of processes. Consider a data transfer process between two pairs of components via a bus. The originators of the data communication are called masters and the receivers of the communication called slaves. We assume that one pair of master and slave components, namely M1 and S1 , have no internal memories and so require associated interfaces, say Im and Is , to buffer the data being communicated. Master M1 first sends data to its interface Im , and the data is temporarily saved there. Later, if admitted, the data will be transferred and saved into slave interface Is via the bus. Finally the transmitted data will arrive at slave S1 . In contrast, the second pair of master and slave components, namely M2 and S2 , have large enough internal memories to store data for transmission. Master M2 transfers data to its slave S2 directly via the bus; no interfaces are needed. The schema of the communicating system is shown in Fig. 1. Here the solid arrows represent the directions of data transfer, as explained in the preceding paragraph. The dashed arrows stand for the directions of control flow in the system. The master and slave interfaces each contain a queue, that is, mq and sq. Compared with the memories of M2 and S2 , the storage capacities of the queues are assumed to be small. Hence, the master interface Im will control data transfer from M1 to the bus in order to protect master queue mq from overflow or underflow. For the same reason, slave interface Is will control data transfer from the bus to S1 . Besides these control actions, the bus can also control the data transfer of Im and M2 . As an exclusive resource, the bus may only serve one pair of components at one time. Details of the control flow will be presented in Section 4.2 through the control specifications. In what follows, we will establish the models of plant components and control specifications of this example by means of SCT. While the plant encapsulates all possible activities of Springer


Bus Master M1

Master Interface Im

Slave Interface Is

Master M2

Slave S 2

Slave S 1

Fig. 1 The schema of the communicating system

the communicating system, the control specifications prescribe the acceptable behaviors of the plant in terms of physical and logical constraints. Then, from both the plant and control specifications, we shall synthesize the desired supervisors.

4. Generating the control logic This section describes the first step in designing a CTP model by SCT. Briefly, we formalize the modeling problem of a system of communicating processes as a DES control problem, which we solve by control synthesis techniques in SCT. The desired control logic is embedded in a group of supervisory controllers (supervisors) of the plant. The plant under supervision is guaranteed to meet the design objectives and possess the nonblocking property. 4.1. Modeling the plant In the framework of SCT, a plant, control specifications, and supervisors are all modeled as automata. An automaton is a five-tuple: A = (Q, , δ, q0 , Q m ). Q is the state set. is the non-empty event set called alphabet. δ is the transition (partial) function defined as δ : Q × → Q. q0 ∈ Q is the initial state and Q m ⊆ Q is the set of marker (terminal) states. If Q is a finite set, A is called a finite automaton. As usual, an automaton can be represented using a directed graph called the state transition diagram, in which nodes represent states in Q and arcs the transitions defined by δ. The transitions defined in A induce the transition set T ⊆ Q × × Q. T := {(q, σ, q )|q = δ(q, σ )}. Each arc in the graph is labeled with a corresponding event in . Graphically, an entrance arrow labels the initial state q0 and an exit arrow labels a marker state. Let ∗ stand for all possible strings over the alphabet with being the empty string. If a string s ∈ ∗ is defined for A, denoted δ(q0 , s)!, a directed path labeled as s will exist in its state transition diagram. All the event strings defined in A constitute the closed language L(A) of the automaton A, according to L(A) := {s ∈ ∗ |δ(q0 , s)!}

(1)

The strings leading A to a marker state, which represent completed tasks, compose the marked language of A, namely, L m (A) := {s ∈ L(A)|δ(q0 , s) ∈ Q m }.

(2) Springer


The prefix closure of a language L ⊆ ∗ is L¯ := {t ∈ ∗ |(∃u ∈ ∗ ) tu ∈ L},

(3)

namely, all strings (say t) of L¯ are extendible into L by appending some other strings (say u). An important property of an automaton is nonblocking. Definition 1 (Nonblocking). If in automaton A any state reachable from the initial state q0 can also reach a marker state via a string, that is, (∀q ∈ Q) [(∃s ∈ L(A)q = δ(q0 , s) =⇒ (∃t ∈ ∗ )δ(q, t) ∈ Q m ], then the automaton A is nonblocking. An automaton A is nonblocking if and only if its closed and marked languages satisfy the condition L m (A) = L(A),

(4)

namely, each string in the closed language L(A) also belongs to the prefix closure of the marked language Lm (A), and so can be extended to another string contained in Lm (A). By properly selecting the marker states of an automaton, we can study various system behavioral properties using the nonblocking property. For example, if the marker states identify the terminal states of tasks, we can judge if the tasks can be accomplished by checking the nonblocking property. If the initial state is marked, we can then check the deadlock freedom and reversibility of the system. With this preparation, we are ready to present our plant model. The plant is composed from the automaton models of the components that generate autonomous activities. In principle, the plant model should be a group of small automaton models for independent plant components and the event sets of these small automata should be pairwise disjoint. In this way, every component can work freely without the intervention of others. By this principle, we select the plant components as M1 , M2 , Im , and S1 . The slave interface Is and slave S2 are not treated as plant components because their models (as shown later) do not introduce any new events to the system, i.e., they are not independent from the other plant components. The state transition diagrams of the plant components are shown in Fig. 2. The initial states are the only marker states of these automata so that later we can examine the system’s reversible and deadlock free properties by checking the nonblocking property. Figure 2(a) shows the automaton model of master M1 . It has two actions labeled as events Localm and Enqm . The event Localm represents an internal computation of M1 . Following that, M1 will save a new datum to queue mq in Im via event Enqm . Event Localm is considered to be controllable because we have to decide when master M1 starts to work. Once started, however, M1 will complete its work without intervention. Hence event Enqm is considered as uncontrollable. In a state transition diagram, a controllable event is identified with a switch symbol “|”. Similarly, Fig. 2(c) shows the automaton model of S1 . Event Deqs is set as controllable and Locals as uncontrollable. Figures 2(b) and (d) show the automaton models of master interface Im and master M2 respectively. As they have similar state transition diagrams, they can be explained together. At the initial states, they can request (Rqt/Rqt2 ) the service of the bus. If the request is granted Springer


Trnsf , Rsd Local m

| 0

| 1

Rqt

0

1

|

|

Grnt m

2

Split m

Enq m (a) Automaton M1

(b) Automaton IM

Trnsf 2 , Rsd 2 |

Deq s | 0

Rqt2

0

1

1 |

|

Grnt 2

2

Split 2

Local s (c) Automaton S1

(d) Automaton M2

Fig. 2 The plant models

(Grntm /Grnt2 ), then they can either transfer (Trnsf/Trnsf2 ) a new datum or resend (Rsd/Rsd2 ) a waiting datum to Is /S2 . As we shall allow them to request the service of the bus at any time, events Rqt and Rqt2 are set as uncontrollable. The requests can be either granted or refused, so events Grntm , Splitm , Grnt2 , Split2 are set as controllable. Likewise, since we must select one between events Trnsf/Trnsf2 and Rsd/Rsd2 at state 2, they are also set as controllable. Note that slave interface Is is not treated as a plant component because it only serves as a queue and is better treated as a control specification. Nor is slave S2 included in the plant model because it will not influence the control logic. Now we can get the global plant model G of the communicating system by the synchronous product [6, 30] of the four plant component models. The computation of synchronous product, as well as all other automaton computations throughout the paper, is implemented by the software tool XPTCT, which can be downloaded from [30]. The quantitative results we report for our example through the remaining parts of the paper have obtained using this tool. We have G := M1 IMS1 M2

(5)

The automaton G has 36 states and 192 transitions. Its total alphabet is: := {Localm , Enqm , Locals , Deqs , Rqt, Rqt2 , Gr ntm , Gr nt2 , Splitm , Split2 , T r ns f, T r ns f 2 , Rsd, Rsd2 } and the uncontrollable event set is: u := {Enqm , Rqt, Rqt2 , Locals }. All the other events in are controllable. Springer


4.2. Modeling the control specifications Many strings generated from the obtained plant G are infeasible, because they violate the physical constraints imposed by the queues and the bus. To exclude them from the final controlled plant, we will synthesize a supervisory controller. The control specifications for the latter are derived from the physical and logical constraints enforced on the plant. These constraints for our example are summarized as follows. 1. Master queue mq in master interface Im cannot overflow or underflow. 2. The bus is an exclusive resource. When it is busy serving one pair of components, the other’s request cannot be granted. 3. Slave queue sq in slave interface Is cannot overflow or underflow. 4. When sq becomes full, Im can still attempt to transfer a new datum to it and keep on resending the datum until either Is accepts it or the resending count number reaches a predefined threshold maxwait. In that case, Im will be split, that is, disconnected, from the bus, and none of its requests for the bus will be granted. 5. During the above resending phase, if empty slots become available in sq, Im will be reconnected with the bus if previously split, and will resend the waiting datum to sq. After that, Im returns to its normal data transfer status. Control specification 1 is modeled as automaton MQ drawn in Fig. 3. It is a generic model for master queue mq of capacity m ≥ 2. The omitted states share the same transition definitions as the state m − 1. At state i, 1 ≤ i ≤ m − 1, there are three transitions: (i, Enqm , i + 1), (i, Trnsf , i − 1), and (i, Localm , i). The number at each state records the amount of data saved in mq. A new datum is saved in the queue at the occurrence of event Enqm and a saved datum is removed from the queue at the occurrence of event Trnsf. At state 0, the queue is empty. So event Trnsf is not defined there to prevent underflow. At state m, the queue is full, so event Enqm should not be allowed to occur to prevent overflow. However, unlike event Trnsf, Enqm is uncontrollable and cannot be prevented directly. Therefore, it is necessary and sufficient to disable its immediately preceding event Localm in automaton M1 at state m. This accounts for the selfloops of event Localm at states 0 to m − 1. Note that events absent from automaton MQ are irrelevant to control specification 1 and this automaton should not disable them. To this end, selfloops of the complementary events are understood as added at every state of MQ, although they are not drawn in Fig. 3 to avoid clutter. These omitted selfloops are designated by the phrase “Selfloop Other Events” in Fig. 3. In the other figures with state transition diagrams, if the phrase is appended, it will mean to add selfloops of complementary events at every state. Control specification 2 is modeled as automaton BC depicted in Fig. 4. When the request of master interface Im is granted (Grntm ), the automaton will reach state 1, where event Grnt2 is not defined and hence a request by master M2 cannot be granted. Symmetrically, when the

Local m Enq m

0

| Trnsf

Enq m

|

Local m

|

Fig. 3 MQ for specification 1

...

m-1

|

| Trnsf

Selfloop Other Events Springer

Enq m

Trnsf

m

Form Method Syst Des Fig. 4 BC for specification 2

Grnt 2 2

| | Trnsf2 , Rsd 2

|

0

Grnt m

| Trnsf,Rsd

1

Selfloop Other Events

|

Trnsf n -1

|

Deqs

Rsd

Rsd__

|

0

|

|

n

|

Deqs

Deqs

... Deqs

Grntm

Rsd

Trnsf

|

w1 |

|

...

|

wk

|

0

...

|

|

Trnsf |

Grntm

|

__

Grntm __

Grntm __

__ n

-1

Deqs

|

Grntm

Grntm Selfloop Other Events

Fig. 5 SQ for specifications 3, 4, and 5

request of M2 is granted (Grnt2 ), the automaton will reach state 2, where event Grntm is not defined and hence Im will be split. Finally automaton SQ shown in Fig. 5 captures the last three control specifications. Again, it is a generic model under the assumption that the capacity of slave queue sq is n ≥ 2 and the threshold (maxwait) is k ≥ 2. Control specification 3 is easy to implement, for it is the same as specification 2. States 0 to n in the first row of Fig. 5 are mainly dedicated for this purpose. States 1 to n − 2 are omitted, for they have the same transition definitions as state n − 1. For every state i, 1 ≤ i ≤ n − 1, three transitions are defined: (i, Trnsf , i + 1), (i, Deqs , i − 1), and (i, Gr ntm , i). These states have a similar physical meaning and transitions definition as those in automaton MQ. In particular, the numbers from 0 to n in the states record the number of data saved in sq. The occurrence of event Trnsf saves a new datum in sq and the occurrence of event Deqs removes a datum from the queue. To prevent underflow, controllable event Deqs is disabled at state 0. Unlike specification 1, data transfer from master interface Im to slave interface Is is still allowed by specification 4. So at state n of SQ, event Trnsf is still defined. However, since sq is full at this state, new data from Im cannot be saved in the queue. Accordingly, the transition of event Trnsf at state n leads SQ to state w1 , which means the datum has waited for one cycle. Im has to wait to resend the waiting datum until sq can accept it. During this period, no new datum should be transferred from Im . Therefore event Trnsf is not defined at those waiting states w1 to wk . State wi , 1 ≤ i ≤ k, means that the waiting datum has waited for i communication cycles. The states between w1 and wk are omitted in Fig. 5 because they have the same transition definitions as state w1 . At state wi , 1 ≤ i ≤ k − 1, three transitions are defined: (wi , Rsd, wi+1 ), (wi , Gr ntm , wi ), and (wi , Deqs , n − 1). When the automaton reaches state wk , the waiting count for resending datum reaches threshold maxwait. Then, Springer


by specification 4, Im must be split and its request to the bus refused. This is achieved by the disablement of event Grntm at state wk . Automaton SQ also effectively enforces specification 5. During the waiting and resending period, SQ is at a state between w1 and wk . When a string of events Deqs occurs, data will be removed from the queue so the queue is no longer full. To avoid underflow of sq, event Deqs can successively occur at most n times. The string of events Deqs will lead SQ to a state in the second row in Fig. 5. The numbers at these states also count the number of data saved in the queue. An underline is used at each state to mark the difference from states in the first row. The states between 0 and n − 1 are omitted because their transitions are the same as state n − 1. At state i, 1 ≤ i ≤ n − 1, three transitions are defined: (i, Rsd, i + 1), (i, Gr ntm , i), and (i, Deqs , i − 1). Since event Deqs is disabled at state 0, only two transitions are defined there: (0, Rsd, 1) and (0, Gr ntm , 0). At these states from 0 to n − 1, sq can only accept the waiting datum via event Rsd. After that, SQ will reach a state from 1 to n, where sq works normally. Up to this point, we have established the plant and control specification models of the communicating system. These two steps directly determine the correctness and performance of the supervisors synthesized later. Admittedly, a certain amount of creative work is involved in this phase. Fortunately however, we need not worry about implementation details and global system behavioral properties at this stage. We only need to design the small local models for a group of simple processes, which is straightforward for those familiar with modeling by automata. The key point is that the supervisors that can implement the control specifications and assure system behavioral properties will be computed algorithmically in the following control synthesis step. 4.3. Synthesizing the supervisors Before solving the control problem for our example, we introduce some basic results of SCT. Recall the typical control problem introduced in Section 2. Its solution can be formalized as the following theorem, which is adapted from [6, 30].

Theorem 1. Let an automaton G be a plant model and an automaton E be a control specification model. Then the minimally restrictive and nonblocking supervisory control for the problem (G, E) can be implemented by a nonblocking automaton S∗ whose marked language is L m (S∗ ) := sup C(L m (G) ∩ L m (E)). The notation sup C(L m (G) ∩ L m (E)) denotes the supremal controllable sublanguage of the language L m (G) ∩ L m (E). It is the supremal element of the following set of languages C(L m (G) ∩ L m (E)) : = {K ⊆ L m (G) ∩ L m (E)| K is controllable with respect to G and u }.

(6)

Every element in the set is a controllable sublanguage of the language L m (G) ∩ L m (E). Note the difference between controllable language and controllable event in Section 2. A controllable language is an event string set that can be ensured by a supervisory controller. Springer


Definition 2. A language K ⊆ L m (G) is controllable with respect to the plant model G and the uncontrollable event set u , if and only if K¯ u ∩ L(G) ⊆ K¯ .

(7)

In Eq. (7) it is defined that K¯ u := {sσ |s ∈ K¯ and σ ∈ u }. The above expression implies that, for any string s ∈ K¯ and any uncontrollable event σ ∈ u , if the new string sσ ∈ L(G) exists, then the process expressed by string s σ may be generated from the plant G in reality. Since no supervisor can disable the uncontrollable event σ , the occurrence of the process pertaining to sσ cannot be prevented. Hence, the prefix closure of the controllable language K must contain the string sσ such that Eq. (7) holds. Any supervisor V of the plant G subject to the specification E must generate a controllable sublanguage of the language L m (G) ∩ L m (E), namely, L m (V) ∈ C(L m (G) ∩ L m (E)). Clearly, L m (V) ⊆ L m (S∗ ), because L m (S∗ ) := sup C(L m (G) ∩ L m (E)). Therefore the supervisor S∗ obtained by Theorem 1 allows the largest interaction freedom for the communicating system and is the optimal supervisor for the control problem (G, E). Moreover, given a plant model G and a control specification model E, the optimal supervisor S∗ can be achieved algorithmically by SCT. Nevertheless, the current synthesis algorithm of SCT cannot be applied to generic automata, such as automata MQ and SQ. Each automaton input to the algorithm must have a fixed number of states. Consequently, we have to set the parameters m, n, and k in the generic automata MQ and SQ as predefined values before we can proceed to get the desired supervisor. This is, however, a minor technical limitation since for a given system these parameters are normally specified. 4.3.1. Monolithic supervision Suppose both queues mq and sq have capacities of two, that is, m = n := 2, and the threshold is maxwait = k := 2. This case will reflect the typical properties of the problem yet not demand too much computation in the synthesis. On replacing these parameters in the generic automata MQ and SQ with the fixed values, MQ will have m + 1 = 3 states and SQ have n + 1 + n + k = 7 states. Consequently, we can use one automaton E to incorporate all three control specification models. E := MQSQBC.

(8)

Automaton E has 60 states and 518 transitions. The algorithm to compute the optimal supervisor for a plant G and a specification E is denoted as supcon : (G, E) → S∗ ,

(9)

where L m (S∗ ) = sup C(L m (G) ∩ L m (E)). Substituting the plant model obtained in Eq. (5) and the control specification model obtained in Eq. (8), we get the optimal supervisor for the communicating process as an automaton S∗ , having 540 states and 2348 transitions. Supervisor S∗ is called monolithic because it incorporates both the control logic and the plant mechanism and has a large state size. A monolithic supervisor is often not comprehensible for its large state size. Thus it is difficult to derive control logic from a monolithic supervisor. Springer


To separate the control logic from the plant mechanism, we can run another algorithm [28] supr educe : (G, S∗ ) → RS,

(10)

where G is a plant model, S∗ is the optimal supervisor synthesized from Eq. (9), and automaton RS is a reduced supervisor that only enforces the control logic. It is a nonblocking automaton whose closed and marked languages satisfy the following equations. L(S∗ ) = L(G) ∩ L(RS),

(11)

L m (S∗ ) = L m (G) ∩ L m (RS).

(12)

Working together with plant G, reduced supervisor RS implements the same minimally restrictive and nonblocking control action as optimal supervisor S∗ . Reduced supervisor RS for the communicating process has only 42 states and 386 transitions. While it is much smaller than the monolithic supervisor S∗ , it is still hard to understand and use for generating the propositional formulas as guards for the transactions. In particular, RS does not display any structural information about the control problem. For a more structured and more comprehensible solution to the control problem, we will consider a modular supervision approach next. 4.3.2. Modular supervision Since the control specification of a control problem is usually given as a group of simple specifications, we may synthesize an optimal supervisor for each of them. These individual supervisors are called modular supervisors for the control problem. The modular supervision approach can reduce the computational complexity of the control synthesis. Moreover, the supervisors achieved by this approach are more structured and smaller in state size [21, 29]. Consequently they are more comprehensible, and convenient for generating the control logic. Given a plant G and a set of control specifications Ei (i = 1, . . . , n), we can find a modular supervisor Si ∗ and its reduction RSi for each specification Ei by the algorithms supcon and supreduce given in Eqs. (9) and (10. According to the properties of these algorithms, the modular supervisors have the property that for i = 1, . . . , n, L m (Si∗ ) = sup C(L m (Ei ) ∩ L m (G)),

(13)

L m (Si∗ ) = L m (G) ∩ L m (RSi ).

(14)

These modular supervisors must work together to force plant G to observe all the given control specifications. Each one will constrain the plant’s behavior to a subset of the language Lm (G), so their joint control actions result in the intersection of all the languages allowed by the n modular supervisors, that is, i=1 L m (Si∗ ). Furthermore, the intersection of the languages can be achieved by the conjunction of their associated automata [30]. Let MS := S∗1 ∧ S∗2 ∧ · · · ∧ S∗n Springer

(15)


and therefore L m (MS) =

n

L m (Si∗ )

(16)

i=1

Then the final behavior of plant G under modular supervisors Si∗ , i = 1, . . . , n, is described by automaton MS. These modular supervisors, however, are configured individually without considering their mutual interaction. Hence, they might come into conflict when combined together and so might cause MS to be blocking. In this case, the plant under the supervision of the modular supervisors fails to be nonblocking, and the required system behavioral property cannot be ensured. To overcome the problem, we must ensure that the modular supervisors for the given plant G can be successfully combined to effect a nonblocking process. Wonham [30] provides a sufficient condition for checking whether a group of modular supervisors Si , i = 1, . . . , n, possibly reduced, can be combined into a global nonblocking supervisor for the plant G. Theorem 2. MS := S1 ∧ S2 ∧ · · · ∧ Sn is a nonblocking supervisor for G if 1. For all i = 1, . . . , n, Si are all nonblocking supervisors for G 2. MS is nonblocking, 3. Automaton SG := MS ∧ G is nonblocking. This theorem spells out the feasibility and validity requirements for a group of modular supervisors. Moreover, if a group of modular supervisors does not satisfy the theorem, we can further synthesize a coordinator [29] to resolve the conflict and ensure the nonblocking property. Because the nonblocking DES control problem has been shown to be NP-hard [10], the verification of modular supervisors and the design of coordinators are generally as complex as synthesizing a monolithic supervisor. Fortunately, compositional computation of the coordinator is possible when systems enjoy certain structure [1, 19, 27]. Our experience shows that many practical problems like the communicating process in this paper are amenable to compositional synthesis. For our communicating system, we will have one modular supervisor for each of the three control specifications. The optimal and reduced supervisors for each control specification can be obtained as follows. S∗1 := supcon(G, MQ)

(17)

RS1 := supreduce(G, S∗1 )

(18)

S∗2 := supcon(G, BC)

(19)


(20)

S∗3 := supcon(G, SQ)

(21)


(22) Springer

Form Method Syst Des Table 1

Computational results for the modular supervisors

Supervisors

State#

Trans#

Supervisors

State#

Trans#

S∗1 S∗2 S∗3 SG

90 32 240 540

450 160 1156 2348

RS1 RS2 RS3 MS

3 2 7 42

39 22 87 392

Fig. 6 The reduced supervisor RS2

Grntm, Grnt

2

| 0

1 | Trnsf, Rsd, Trnsf 2 , Rsd 2

Selfloop Other Events

The computational results are presented in Table 1. The state and transition sizes of the six automata obtained in Eqs. (17)–(22) are given in the first three rows of the table. We have pleasing results for the reductions of the three modular supervisors: they have small state sizes and are easily understood. Next we should check the validity of the three modular supervisors against Theorem 2. Owing to Eq. (10) supervisors RSi , i = 1, 2, 3, are all nonblocking supervisors for plant G. Hence condition (1) holds. Let automaton MS := RS1 ∧ RS2 ∧ RS3 and automaton SG := MS ∧ G. It can be verified by XPTCT software that they are both nonblocking, so conditions (2) and (3) hold. The computational result is presented in the last row of the Table 1. Automaton SG represents the controlled behavior of G under the supervision of the three modular supervisors. We can also verify with XPTCT that SG is isomorphic to the monolithic supervisor S∗ obtained in Eq. (9). Therefore, the joint control of the three modular supervisors is the same as the monolithic supervisor; namely, they implement optimal control on the plant. The state transition diagrams of RS1 and RS3 are the same as those of MQ and SQ shown in Figs. 3 and 5. The state transition diagram of RS2 is drawn in Fig. 6. The only difference between automata BC and RS2 is that states 1 and 2 in BC merge into one state in RS2 . In SCT, the control logic of a supervisor is explicitly presented as the event disablements at the states of an automaton. We tabulate the control logic of the three reduced supervisors in Table 2. In the table, we only list states that disable some events; those states that do not disable any events are not listed. As required, all the events disabled by the supervisors are controllable events.

5. Constructing the CTP model We now turn to the last step in the model construction process, namely, extracting a CTP model from the DES model obtained using SCT as explained in the previous sections. This is a step involving design experience and insight. While our ultimate objective is to find an algorithm that converts the SCT results to CTP models, this paper, subject to its space Springer

Form Method Syst Des Table 2

The control logic of the three reduced supervisors

States

Event(s) Disabled

States

Event(s) Disabled

Control logic of reduced supervisor RS1 0

Trnsf

1

Grntm , Grnt2

m

Localm

Control logic of reduced supervisor RS2

Control logic of reduced supervisor RS3 0 w1 , . . . , wk−1 n − 1, . . . , 1

Deqs , Rsd Trnsf Trnsf

1, . . . , n wk 0

Rsd Grntm Deqs , Trnsf

limitation, aims only to demonstrate an initial contribution of SCT to the new domain, and constructs the CTP models for the example by hand. Even without an algorithm to construct CTP automatically, the design still benefits from SCT because the power of SCT is automatically to resolve any blocking problem that may intrude. The algorithmic construction of CTP models is a major research topic that currently lies outside our scope. Because CTP is a highly structured modeling tool that is designed to be understood by human designers instead of machines, we believe that the construction of CTP models cannot be fully automated and that human intervention at some point is unavoidable. Moreover, CTP may describe a wide variety of communicating processes and the model of a given process is often not unique. Critical decisions to enhance comprehensibility, and maintain a balance between control flow at the framework level and communication details at the transaction level, must be made by a human designer. These critical decisions are pointed out in the following construction process. Other procedures that may be realized automatically in the future are also suggested. Here we will present the CTP model only informally using our illustrative example. The interested reader is referred to [25, 26] for a formal definition of the model and its operational semantics. 5.1. Framework level The framework level is a network of interacting automata which convey three items of key information: (1) The components involved in the communication process, (2) the transaction schemes each component generates, and (3) the interactions among these components. Every communicating component (that is, its control flow) should be described by as simple a labeled automaton as possible. Hence, the control flow complexity among the components and the number of transaction schemes will be minimized. However, the fewer the number of transaction schemes, the more complex the MSCs of these transaction schemes may be. Therefore, a human designer should balance these two factors and decide on the transaction schemes at this level. In the illustrative example, the framework level model is derived from the plant and the supervisor models by integrating related events into transaction schemes. As mentioned in Section 4.1, the slave S2 does not influence the communicating process. Hence we need not introduce it into the CTP model. Since the main concern about master interface Im is the coordination of events Grntm , Splitm , Trnsf, and Rsd, we integrate them into one transaction Springer

Form Method Syst Des Fig. 7 The framework level CTP model

0 Local m

0

Cmnt

Enqm 1

1

M1

0

Cmnt 2

2

Rqt 2

Rqt

Cmnt 2 1

Im

M2

0

0

Cmnt

Bus

0

Deq s

Local s

1

1

Is

S1

scheme (Cmnt) and will specify the detailed control logic by MSCs at the transaction level. Similarly, events Grnt2 , Split2 , Trnsf2 , and Rsd2 of master M2 are also integrated as a transaction scheme (Cmnt2 ). Then these events in the automaton models of the plant and supervisors are replaced by the transaction schemes and the automata are accordingly simplified. The simplification may be completed by algorithm. Consequently we get the synchronous product system shown in Fig. 7. In this diagram, except for Cmnt and Cmnt2 , the transaction schemes have the same names and meaning as the events defined before. Common actions are shown in bold and to reduce visual clutter they share the same labels when they are neighbors (such as Enqm ). Figure 7 shows that the communicating process involves six components, where each component generates the transaction schemes labeled in its automaton model. These components synchronize at joint transaction schemes that are labeled in bold. We note that, compared with the automaton models in Section 4, the framework level CTP model is much simpler. The detailed information and control logic will be elaborated by MSCs at the transaction level. For instance, Fig. 7 shows that master M1 repeats the actions of internal computation (Localm ) and saving a datum (Enqm ) in the queue (mq) in master interface Im . However, to avoid overflow of master queue mq, the action Localm must be disabled at a certain point, which cannot be derived from the framework level model. This information is provided by the transaction level model. 5.2. Transaction level We unfold each transaction scheme to a group of guarded MSCs, which must reflect all the details about the communicating processes and the control logic achieved by SCT. As this information is already completely encoded in the automaton models, we need to convert the automata into logical formulas. To realize this conversion, designers must define a set of variables, predicates, and propositional formulas that can distinguish the states of automata. The variables and the formulas should be natural, transparent, and amenable to easy realization. Different designers may choose different sets of variables and predicates Springer


for the same automaton supervisors. Hence the model for a given process is not unique. The designer’s experience and taste determine the readability and style of the CTP model, but the performance and function of the models should be the same. For the illustrative example, we define the following variables and predicates. They suffice to distinguish the states of all the automata in Section 4. Here D denotes the data type of the data transmitted via the bus. Queue := {mq, sq} denotes the set of queues. 1. Variables:

r grantm , grant2 : Boolean. True when supervisor RS2 is at state 0, where the request for the bus by master interface Im or master M2 may be granted. False when RS2 is at state 1, where requests cannot be granted. They are located at the bus. r splitm : Boolean. True when supervisor RS3 is at state wk , where the master interface is split from the bus and its request cannot be granted. False otherwise and the request may be granted. It is located at slave interface Is . r mq, sq: Queue. They represent the master queue of master interface Im and the slave queue of slave interface Is . r dn, dw: D. They store respectively the new datum coming from master queue mq and the waiting datum when queue sq is full. They are both located at master interface Im . r wcnt: Integer. It counts the number of cycles for which dw has waited. It is located at slave interface Is . 2. Predicates:

r full: Queue → Boolean. Predicate full(q) is true if and only if q is full. r empty: Queue → Boolean. Predicate empty(q) is true if and only if q is empty. We identify the states of the automata obtained by SCT with the logic formulas of the variables and predicates. Then the guards and MSCs of the transaction schemes may be derived automatically. Here we only provide the details for transaction scheme Cmnt and display its guarded MSCs. For the remaining transaction schemes, we specify the propositional formulas but omit the MSCs. Since the transaction scheme Cmnt depends on DES events Grntm , Splitm , Trnsf, and Rsd, we must derive the propositional formulas for the disabling conditions and the effect of each event. They can be derived from the models of the plant IM and the three reduced supervisors RS1 ,RS2 , and RS3 . According to Table 2, event Trnsf is disabled at state 0 of supervisor RS1 , states w1 to wk−1 , and states 0 to n − 1 of supervisor RS3 . State 0 of supervisor RS1 can be expressed as predicate empty(mq). States w1 to wk−1 and states 0 to n − 1 of supervisor RS3 can be described as proposition wcnt > 0. Therefore Trnsf is disabled when: empt y(mq) ∨ wcnt > 0.

(23)

Event Rsd is disabled at states 0 to n of supervisor RS3 , where the datum waiting count (wcnt) is 0. Rsd is disabled when: wcnt = 0.

(24)

Event Grntm is disabled at state 1 of supervisor RS2 , where variables grantm and grant2 are false, and at state wk of supervisor RS3 , where variable splitm is true. Gr ntm is disabled when: ¬grantm ∨ splitm .

(25) Springer


Since event Splitm is never disabled by the three supervisors, we do not need a disabling condition for it. After identifying the disabling conditions, we next define the transition consequences of each event. The occurrence of event Grntm can only change the status of supervisor RS2 , as it appears as selfloops in supervisors RS1 and RS3 . Therefore its occurrence will only change variables grantm and grant2 but not the status of master and slave queues mq, sq, and waiting count wcnt. Gr ntm causes: grantm := false ∧ grant2 := false.

(26)

Event Trnsf changes the states in all three reduced supervisors. In RS1 it removes a datum from master queue mq. In RS2 it resets variables grantm and grant2 as true. In RS3 , if slave queue sq is not full, event Trnsf saves the new datum in it; if slave queue sq is already full, it assigns the new datum to variable dw and initiates the waiting cycles; thus Trnsf causes a sequence of atomic actions. Trnsf causes: dequeue(mq, dn); grantm := true ∧ grant2 := true; enqueue(sq, dn), when ¬full(sq); wcnt := wcnt + 1 ∧ dw := dn, when full(sq).

(27)

Here dequeue denotes an atomic action defined for queues in Queue and data of type D. Action dequeue(mq, dn) means that a new datum is removed from queue mq and saved into variable dn. Likewise, action enqueue(sq, dn) means that the new datum saved in variable dn is recorded into slave queue sq. Event Rsd changes states in supervisors RS2 and RS3 . In RS2 it resets the values of variables grantm and grant2 . In RS3 it is defined at states w1 to wk−1 and 0 to n − 1. At states w1 to wk−1 slave queue sq is full, so the waiting datum stored in dw cannot be saved in it and the waiting count (wcnt) increases by one. After the increase, if variable wcnt reaches the predefined threshold (maxwait), variable splitm will be set true, signifying that master interface Im is already split from the bus. In contrast, states 0 to n − 1 signify that slave queue sq is not full, so the waiting datum can be successfully saved in the queue and the waiting count reset to 0. Rsd causes: grantm := true ∧ grant2 := true; enqueue(sq, dw) ∧ wcnt := 0, when ¬full(sq); wcnt := wcnt + 1, when full(sq); splitm := true, when full(sq) ∧ wcnt = maxwait.

(28)

Event Splitm does not influence these defined state variables. Finally, to show how the state variable splitm is reset false, we must identify the disabling condition and transition consequences of event Deqs here. From Table 2 event Deqs is disabled at states 0 and 0 of supervisor RS3 , where slave queue sq is empty. Deqs is disabled when: empt y(sq) Springer

(29)


When event Deqs takes place, a datum will be removed from the slave queue and sent to slave S1 . If variable splitm is true, it will be reset to false at the occurrence of this event. Deqs causes: dequeue(sq, d); splitm := false, when splitm .

(30)

We now determine all possible transactions for each transaction scheme according to the DES models obtained in the last section. As the transaction schemes are abstracted from DES events, the transactions of a transaction scheme can be derived from the possible occurrences of the underlying DES events. Taking transaction scheme Cmnt as an example, we can immediately identify three possible event occurrences from automaton IM in Fig. 2(b), (1) Splitm , (2) Grntm plus Trnsf, and (3) Grntm plus Rsd. Event Splitm means that Im cannot access the bus and an empty transaction happens. Events Grntm plus Trnsf mean that Im transfers a new datum to Is . However, according to the status of queue sq in Is , two transactions may occur. One corresponds to a successful datum transfer and the other initiates waiting cycles. Event Grntm plus Rsd represent that Im resends a waiting datum to Is . Based on the status of sq and the value of counter wcnt, three transactions may occur. Correspondingly, master interface Im may (1) continue to hold and resend the waiting datum, (2) save it successfully into sq, or (3) may be split from the bus. Totally there are six possible transactions for transaction scheme Cmnt, including no operation, transferring a datum normally, initiating waiting cycles, resending a waiting datum, terminating waiting cycles, and being split. In addition, to show the reconnection of master interface Im , we also present one more MSC that belongs to transaction scheme Deqs , which reconnects Im with the bus. 1. ¬grantm ∨ splitm ∨ (empty(mq) ∧ wcnt = 0). Owing to disabling condition (25), we know that event Grntm is disabled when ¬grantm ∨ splitm . Thus master interface Im can do nothing because its request cannot be granted. When empty(mq) ∧ wcnt = 0, according to disabling conditions (23) and (24), both events Trnsf and Rsd are disabled and there is no operation for transaction scheme Cmnt under this circumstance. The corresponding MSC is trivial and we will ignore it in this work. 2. grantm ∧ ¬splitm ∧ ¬empty(mq) ∧ ¬full(sq) ∧ wcnt = 0. Due to disabling condition (24) and the fact wcnt = 0, we know that event Rsd is disabled and the master interface may only transfer a new datum to the slave interface. Moreover, according to transition consequence (27) the datum can be successfully saved into slave queue sq. This condition corresponds to the normal data transfer process in which a datum is successfully transferred from master interface Im into slave interface Is . The corresponding MSC is shown in Fig. 8. Before master interface Im transfers a datum to slave interface Is , its request must first be granted. Consequently, according to transition consequence (26) and disabling condition in Eq. (25), the request of master M2 cannot be granted until the transfer completes and variables grantm and grant2 are reset as true, which means the bus becomes free again. 3. grantm ∧ ¬splitm ∧ ¬empty(mq) ∧ full(sq) ∧ wcnt = 0. This case has the same propositional conditions as the second one except for the predicate full(sq). By the same disabling condition in Eq. (24) as applied in the previous case, only the actions of transferring a new datum are allowed. However, the consequence of the event Trnsf is different from that in the prior case. Because of the condition full(sq) and transition consequence in Eq. (27), the new datum cannot be saved in slave queue sq and the waiting cycles start. The chart for this case is shown in Fig. 9. Springer


grantm ∧ ¬splitm ∧ ¬empty(mq) ∧ ¬f ull(sq) ∧ wcnt = 0

grant (I m )

SPLIT (M 2 ) grant 2 = grant m

SPLIT_ACK

= false dequeue (mq,dn )

TRANSF (dn) enqueue (sq,dn)

READY (true) CONNECT (M 2 ) grant 2 = grant m = true CONNECT_ACK Im

Bus

Is

Fig. 8 MSC2: transferring a datum normally

grantm ∧ ¬splitm ∧ ¬empty(mq) ∧ f ull(sq) ∧ wcnt = 0

grant (I m )


SPLIT_ACK

= false dequeue (mq,dn )

TRANSF (dn) wcnt

READY (false)

= wcnt + 1

dw = dn

CONNECT (M 2 ) grant 2 = grant m = true CONNECT_ACK Bus

Im

Is

Fig. 9 MSC3: Initiating waiting cycles

4. grantm ∧ ¬splitm ∧ f ull(sq) ∧ (0 < wcnt < maxwait − 1). According to disabling condition in Eq. (23), master interface Im cannot transfer new datum to slave interface Is . The waiting datum saved in dw must be resent instead. Furthermore, considering transition consequence in Eq. (28) and the fact that f ull(sq) ∧ wcnt < maxwait − 1, the waiting datum has to continue waiting and the waiting cycle proceeds. The chart for this case appears in Fig. 10. Springer


grantm ∧ ¬splitm ∧ f ull(sq) ∧ 0 < wcnt < maxwait − 1

grant (I m )

SPLIT (M 2 ) grant2 = grantm

SPLIT_ACK

= false

RESEND (dw ) wcnt

= wcnt + 1

wcnt

= wcnt + 1

READY ( false)

CONNECT (M 2 ) grant 2 = grantm = true CONNECT_ACK Bus

Im

Is

Fig. 10 MSC4: Resending a waiting datum

grantm ∧ ¬splitm ∧ f ull(sq) ∧ wcnt = maxwait − 1

grant (I m )


SPLIT_ACK

= false

RESEND (dw)

split m = true CONNECT (M 2 )

READY (false)

grant 2 = grant m = true CONNECT_ACK Bus

Im

Is

Fig. 11 MSC5: Being split from the bus

5. grantm ∧ ¬splitm ∧ full(sq) ∧ wcnt = maxwait − 1. This scenario differs slightly from case 4 by the condition that wcnt = maxwait − 1. By the same argument, only event Rsd may occur under this scenario. Based on transition consequence in Eq. (28), variable wcnt increases by 1 and then reaches the predefined threshold. Consequently, master interface Im must be split from the bus by setting variable splitm as true. The chart is shown in Fig. 11. 6. grantm ∧ ¬splitm ∧ ¬full(sq) ∧ wcnt > 0. As in the last two cases, master interface Im still cannot transfer a new datum to slave interface Is . However, since slave queue sq is no Springer


grantm ∧ ¬splitm ∧ ¬f ull(sq) ∧ wcnt > 0 grant (I m )


SPLIT_ACK

= false

RESEND (dw) enqueue (sq,dw ) wcnt CONNECT (M 2 )

=0

READY (true)

grant 2 = grant m = true CONNECT_ACK Im

Bus

Is

Fig. 12 MSC6: Terminating waiting cycles

longer full, the waiting datum can be safely saved according to transition consequence given by Eq. (28) and the waiting cycles terminate. This case is shown in Fig. 12. 7. ¬empt y(sq) ∧ splitm . This is a condition for the MSC of transaction scheme Deqs . Since variable splitm can only be reset as false by event Deqs , we draw this chart in Fig. 13 to highlight when master interface Im , if previously split, will be reconnected with the bus. This chart corresponds to the transition consequence of Deqs given in Eq. (30). We have now obtained the complete collection of MSCs for the transaction scheme Cmnt. The guarded MSCs for the other transaction schemes can be derived in the same manner. We shall not draw their MSCs here, but only present the conditions and main actions for each of them. 1. Transaction scheme Localm . This represents the local computations of master M1 and has only one participating component. The only control action on the event Localm is at the state m of supervisor RS1 . Therefore the MSCs of the transaction scheme Localm

¬empty(sq) ∧ splitm split m = false dequeue (sq,d )

TRANSF (d) local (S 1 ) READY (true) Is

Fig. 13 A MSC of Deqs that reconnects Im with the bus Springer

S1


2.

3.

4.

5.

6.

implement two conditions: (1) full(mq) so that event Localm is disabled and (2) ¬ f ull(mq) and the action represented the event Localm is allowed. Transaction scheme Enqm . This designates the action of saving new data produced by master M1 into master interface Im and is an action common to master M1 and master interface Im . Since event Enqm is declared as uncontrollable in the DES model, it can always occur whenever it is defined in the framework level CTP model. Hence there is only one condition and one action for this transaction scheme, that is, true and event Enqm is allowed. Transaction schemes Rqt and Rqt2 . These are all internal actions of the master interface Im and master M2 . As in transaction scheme Enqm , the two events are also uncontrollable. Thus each has only one condition and one action. Transaction scheme Cmnt2 . This transaction scheme has function similar to that of Cmnt, but with much simpler logic. It stands for the communication between master M2 and slave S2 via the bus, involving events Grnt2 , Split2 , Trnsf2 , and Rsd2 . Based on Table 2 the only control action on these events is to disable event Grnt2 at state 1 of supervisor RS2 . Therefore two cases can occur in the transaction scheme: (1) grant2 and event Grnt2 is allowed; (2) ¬grant2 so that event Grnt2 is disabled and only Split2 can occur. In the first case, when event Grnt2 occurs, we have the transition consequence that grant2 := false ∧ grantm := false, which has already been stated in Eq. (26). Following event Grnt2 , the two events Trnsf2 and Rsd2 may take place. Similarly to transition consequences in Eqs. (27) and (28), they also reset state variables: grant2 := true ∧ grantm := true. Transaction scheme Deqs . This transaction scheme corresponds to the DES event Deqs , for which the disabling condition and transition consequences are already given in Eqs. (29) and (30). We can identify the following three cases for the transaction scheme: (1) empty(sq), so that event Deqs is disabled, (2) ¬empt y(sq) ∧ ¬splitm , and (3) ¬empt y(sq) ∧ splitm . The corresponding MSC for the third condition has been drawn in Fig. 13. Transaction scheme Locals . This represents the internal operation of slave S1 . As it is an uncontrollable event, we can depict the transaction scheme by only one MSC under the guard: true and event Locals can always occur.

6. Conclusions This work presents a new paradigm for designing CTP models of reactive systems. In contrast to current iterative design processes, the new paradigm consists of two main steps.

r Model the system as a Discrete-Event System (DES) and then derive the detailed interaction and the control logic by Supervisory Control Theory (SCT);

r Translate the obtained DES supervisors and their control logic into propositional formulas of the guarded MSCs of transaction schemes and thus construct the CTP model. Since the control logic generated from SCT is guaranteed to be correct, complete and optimal for both operational constraints and the system’s behavioral properties, the CTP model achieved after the above two steps will possess all the required properties and be optimal. Consequently the time-consuming design iteration is avoided and in principle no simulation or formal verification is needed. The main contribution of this paper is not to develop new theory, but to introduce Supervisory Control Theory into a new application area. A new application should in turn stimulate the theory. In respect to formal methods, we hope that SCT may engage other researchers. Springer


In this paper the supervisory control method is illustrated through a specific example. Like controllers for conventional dynamic systems, a supervisory controller for a discrete-event system is plant dependent. This means that the control logic (process controller) needs to be re-designed (reconfigured) to account for different communicating processes and protocols individually. Nevertheless, the method is formal, and allows systematic derivation of the control logic for any (static) network of (finite state) communicating processes according to the procedure addressed in Section 4. To summarize, the first main step can be decomposed into four sub-steps. 1. Treat the autonomous components as the plant and model them as a set of automata in the framework of SCT; 2. Partition the events into controllable and uncontrollable event set; 3. Treat the physical and logical constraints among the plant components as the control specifications and model them as a set of automata; 4. Derive the proper nonblocking supervisory controllers, either monolithic or modular, via control synthesis algorithms. This is then to be followed by the derivation of the CTP model. Actually the model obtained by the four step procedure above is itself an executable model and in many applications one may wish to make this the basis for an implementation. However, in the context of embedded systems design it is becoming increasingly important to present designs in which computational and communication aspects are clearly separated. Consequently it should be fruitful to present the result of the model derivation procedure as a CTP model rather than as a network of automata.

References 1. Åkesson K, Flordal H, Fabian M (2002) Exploiting modularity for synthesis and verification of supervisors. In: Proceedings of the 15th IFAC World Congress on automatic control, Barcelona, Spain, 2002 2. Balarin F, Lavagno L, Passerone C, Sangiovanni-Vincentelli A, Watanabe Y, Yang G (2002) Concurrent execution semantics and sequential simulation algorithms for the metropolis meta-model. In: International symposium on hardware/software codesign (CODES), May 6–8, pp 13–18 3. Cadence Berkeley Laboratories (2004) The SMV model checker, www-cad.eecs.berkeley.edu / ∼ kenmcmil/smv 4. Brandin BA, Charbonnier FE (1994) The supervisory control of the automated manufacturing system of the AIP. In: Proceedings of the fourth international conference on computer integrated manufacturing and automation technology. IEEE Computer Society Press, New York, USA, pp 319–324 5. Cao X-R, Cohen G, Giua A, Wonham WM, van Schuppen JH (2002) Unity in diversity, diversity in unity: retrospective and prospective views on control of discrete event systems. Discr Event Dyn Syst: Theory Appl 12(3):253–264 6. Cassandras C, Lafortune S (1999) Introduction to discrete event systems, 2nd edn. Kluwer, Boston, USA 7. Chandra V, Huang Z, Kumar R (2003) Automated control synthesis for an assembly line using discrete event system control theory. IEEE Trans Syst Man Cybern—Part C: Appl Rev 33(2):284–289 8. Cohen G, Gaubert S, Quadrat JP (1991) Algebraic tools for performance evaluation in discrete event systems. In: Discrete event dynamic systems: analyzing complexity and performance in the modern world. IEEE Press, New York, USA 9. Gajski D, Zhu J, Dmer R, Gerstlauer A, Zhao S (2000) SpecC: Specification language and methodology. Kluwer, Boston, USA 10. Gohari P, Wonham WM (2000) On the complexity of supervisory control design in the RW framework. IEEE Trans Syst Man Cybern—Part B: Cybern 30(5):643–652 11. Grotker T, Liao S, Martin G, Swan S (2002) System design with system C. Kluwer, Boston, USA 12. Harel D, Kugler H, Marelly R, Pnueli A (2002) Smart play-out of behavioral requirements. International conference on formal methods in computer aided design (FMCAD), pp 378–398 Springer

Form Method Syst Des 13. Ho YC (1992) Discrete event dynamic systems: analyzing complexity and performance in the modern world. IEEE Press, New York, USA 14. Holloway LE, Krogh BH, Giua A (1997) A survey of petri net methods for controlled discrete event systems. Discr Event Dyn Syst: Theory Appl 7(2):151–190 15. Holzmann GJ (1997) The model checker SPIN. IEEE Trans Softw Eng 23(5):279–295 16. International Telecommunication Union (1996) Z.120: Message Sequence Charts, http://www.itu.int/ITUT/studygroups/com10/languages, 1996. 17. Jafari MA, Darabi H, Boucher TO, Amini A (2002) A distributed discrete event dynamic model for supply chain of business enterprises. Proceedings of the sixth international workshop on discrete event systems (WODES’02), pp 279–285 18. Kozák P, Wonham WM (1996) Design of transaction management protocols. IEEE Trans Autom Contr 41(9):1330–1335 19. Lee SH, Wong KC (2002) Structural decentralized control of concurrent discrete-event systems. Eur J Contr 8(5):477–491 20. Peterson JL (1981) Petri net theory and the modeling of systems. Prentice-Hall, Upper Saddle River, NJ, USA 21. de Queiroz MH, Cury JER (2000) Modular supervisory control of large scale discrete event systems. Discr Event Syst: Anal Control. Kluwer, Boston, USA, pp 103–110 22. Ramadge PJ, Wonham WM (1987) Supervisory control of a class of discrete event processes. SIAM J Control Optimization 25(1):206–230 23. Ramadge PJ, Wonham WM (1989) The control of discrete-event systems. Proc IEEE 77(1):81–98 24. Ricker S, Sarkar N, Rudie K (1996) A discrete-event system approach to modeling dexterous manipulation. Robotica 14(5):515–526 25. Roychoudhury A, Thiagarajan P (2003) Communicating transaction processes. IEEE international conference on applications of concurrency in system design (ACSD), June 18–20, pp 157–166 26. Roychoudhury A, Thiagarajan P (2003) An executable specification language based on message sequence charts. Formal methods at the crossroads: From panacea to foundational support, LNCS 2757. Springer Verlag 27. Schmidt K, Reger J, Moor T (2004) Hierarchical control for structural decentralized DES. Proceedings of the seventh international workshop on discrete event systems (WODES’04), pp 289–294 28. Su R, Wonham WM (2004) Supervisor reduction for discrete-event systems. Discr Event Dyn Syst: Theory Appl 14(1):31–53 29. Wong KC, Wonham WM (1998) Modular control and coordination of discrete event systems. Discr Event Dyn Syst: Theory Appl 8(3):247–297. 30. Wonham WM (2005) Supervisory control of discrete event systems and XPTCT software (Version 85). Department of Electrical and Computer Engineering, University of Toronto, http://www.control.toronto.edu/DES 31. Wonham WM, Ramadge PJ (1987) On the supremal controllable sub-language of a given language. SIAM J Contr Optim 25(3):637–659

Springer