A Process Algebra for Supervisory Coordination

# A Process Algebra for Supervisory Coordination

Jos Baeten   Bert van Beek   Allan van Hulst   Jasen Markovski Research funded by C4C European project FP7-ICT-2007.3.7.c. Department of Mechanical Engineering, Eindhoven University of Technology,
P.O. Box 513, 5600 MB Eindhoven, The Netherlands,
###### Abstract

A supervisory controller controls and coordinates the behavior of different components of a complex machine by observing their discrete behaviour. Supervisory control theory studies automated synthesis of controller models, known as supervisors, based on formal models of the machine components and a formalization of the requirements. Subsequently, code generation can be used to implement this supervisor in software, on a PLC, or embedded microprocessor. In this article, we take a closer look at the control loop that couples the supervisory controller and the machine. We model both event-based and state-based observations using process algebra and bisimulation-based semantics. The main application area of supervisory control that we consider is coordination, referred to as supervisory coordination, and we give an academic and an industrial example, discussing the process-theoretic concepts employed.

## 1 Introduction

Control software development becomes an important issue due to the ever-increasing machine complexity and demands for better quality, performance, safety, and ease of use. Traditionally, the control requirements are formulated informally and, thereafter, manually translated into control software, followed by validation and rewriting of the code whenever necessary. The cycles of such a design-validate process are both error-prone and time-consuming due to frequent ambiguities in the informal specifications. This issue gave rise to supervisory control theory [23, 10, 18], where models of the supervisory controllers, referred to as supervisors are synthesized automatically based on formal models of the uncontrolled hardware, referred to as plant, and the model of the control requirements. Based on these models, the control software is generated automatically. The supervisory controller observes discrete machine behavior and sends back control signals about allowed activities. Assuming that the controller reacts sufficiently fast on machine input, this feedback loop, depicted in Figure 1a), was originally modeled as a pair of synchronizing processes [23, 10].

In this paper, we focus on the modeling of the control loop and the required process-theoretic concepts to capture the underlying behavior. The main motivation for the investigation is the oversimplification of the coupling between the plant and the supervisor in the original proposal of [23, 10], which still prevails in modern state-of-the-art approaches, like [14, 12, 21, 27, 17] to name a few. Furthermore, we consider coordination as the main application area of supervisory control, where the coordinator(s) are implemented as supervisory controllers that ensure sequencing of events, or deadlock- and livelock-free behavior of the plant, according to the given set of (coordinating) control requirements.

### Supervisory control loop

To model different aspects of the plant and the control requirements, the discrete events that can occur are split into controllable and uncontrollable events. The former can be disabled by the supervisor and typically model actuator activities, e.g., starting or stopping a motor. The latter cannot be affected by the supervisor if enabled in the plant and standardly model sensor activities, e.g., the temperature has reached a given value. We distinguish two types of prominent supervisory control loops relying on event- and state-based observations, depicted in Figure 1b) and c), respectively.

The control loop in Figure 1b) depicts that the supervisor observes events that occur in the plant and sends back as feedback the set of controllable events that are allowed for execution. The most prominent operation that captures the coupling between the plant and the supervisor is automata-style synchronous parallel composition [23, 10]. This simple operation restricts the plant by omitting (controllable) events in the supervisor, thereby preventing synchronization and disabling the events. It was quickly realized that this synchronization produces large supervisors that actually memorize the complete supervised behavior as the supervisor keeps track of the state of the plant by keeping a complete history of observed events.

To mitigate the large size of the supervisor several synchronization operators were proposed that enable the plant to independently execute uncontrollable events, provided that this does not preclude the supervisor from correctly deducing the state of the plant [15, 14, 16, 11]. We note that there are other models of the control loop that employ the input/output transition paradigm that require an input (set of controllable/actuator events) from the supervisor to produce an output (uncontrollable/sensor event) from the plant [7, 8, 26]. Nonetheless, they have been shown to be equivalent to one of the above approaches with respect to the underlying notions [8].

What synchronous parallel composition or communication fails to model is the difference between the two flows of information, their role, and the different goals of the plant and the supervisor. To this end, we propose a send/receive communication to model the different flows of communication in Figure 1 and differentiate between the contributions of the plant and the supervisor. The event-based observation flow of Figure 1b) enables communication of all observable events, whereas the control signal flow transmits only controllable events. In addition, this setting also supports asynchronous communication between the plant and the supervisor, which affects almost every implementation of supervisory controllers [9].

As a solution to the problem of large supervisors, an alternative approach was proposed in [18], as depicted in Figure 1c). The plant (or the supervisor) is augmented with an observer or a tracker that deduces the state of the plant and submits this observed information to the supervisor. The supervisor, based on this state-based information, acts as a lookup table and feeds the plant with the allowed controllable events in the observed state. In such a way, the supervisor only incorporates necessary information in order to exercise control over the plant. Nonetheless, this feedback mechanism is not formalized in [18] and, here, we propose to model this variant of the control loop using a process-theoretic approach that employs root signal emission [2] to capture the state-based observations. Alternative modeling of such control loops is by means of shared variables and synchronization [20], but such approaches do not distinguish between the different flows of information depicted in Figure 1c).

Finally, when employing supervisory control for coordination of distributed systems, the supervisor communicates the control actions to several components that have different physical locations. To this end, we propose to model the feedback control signal communication from the supervisor by means of broadcast communication [5]. To illustrate the proposed process theories that capture the behavior of the control loops of Figure 1b) and c) we revisit two cases, where we applied supervisory coordination: 1b) a simple case that introduces the main concepts and deals with coordination of an automated guided vehicle, involving event-based observations, and 1c) a part of an industrial study dealing with maintenance procedures inside complex high-tech printers, which employs state-based observations [19].

### Process-theoretic approach

The process-theoretic treatment of supervisory control theory is sustained by a behavioral relation that captures the notion of controllability, which states that supervisory control is possible only if the supervisor can achieve supervised behavior allowed by the control requirements without having to disable an uncontrollable event. Prior investigations to process-theoretic treatments of supervisory control resulted in a special prioritized synchronization operator [15, 14], while employing failure semantics. An alternative approach replaced this special operator with a refinement relation to characterize nondeterministic supervised behaviors [21]. In [27, 25] the refinement is given in terms of bisimulation and in terms of simulation in [17]. A coalgebraic approach introduced partial bisimulation as a behavioral relation suitable to define language-based controllability [24]. In essence, it states that controllable events should be simulated, whereas uncontrollable events should be bisimulated. This notion was lifted to a concurrency theory for supervisory control that succinctly captured the controllability for nondeterministic discrete-event systems [3]. Here, we extend this framework to elaborately model and formalize the behavior of the supervisory control loops depicted in Figure 1.

The rest of this paper is organized as follows. Section 2 revisits the process theory from [2] and establishes a link between partial bisimulation and supervisory control. Section 3 shows how to model supervisory control loop in the presented theory by applying supervisory coordination to an automated production line. Section 4 extends the process theory to incorporate guarded commands and root signal emission, which are employed in Section 5, where we revisit an industrial case study of coordination of maintenance procedures in a high-tech printer. We finish with a discussion of future challenges and the potential of applying process theory in supervisory control.

## 2 Process theory TCP∗

In this section we revisit the process algebra (Theory of Communicating Processes with Iteration) [2] in which we introduce generic communication actions and we adopt partial bisimulation as a behavioral relation. This process algebra has a rich syntax, allowing us to express all key ingredients of concurrency theory, including termination, which enables a strong correspondence with automata theory.

### Syntax

We presuppose a finite data alphabet and a finite set of channels. We assume that , where is a generic communication action. If , then we treat the generic communication action as a basic event, possibly parameterized with data, notation . Otherwise, we handle it as an outcome from synchronization of send and receive actions. We employ the standard notation for handshaking communication [2], i.e., for , for , and for . Intuitively, these events denote that datum is received, sent, or communicated along channel , respectively.

The set of process terms is generated by the following grammar:

 T::=0 ∣ 1 ∣ a.T ∣ T⋅T ∣  T+T ∣ T∥T ∣ T∗ ∣ ∂E(T),

where and . Let us briefly comment on the operators in this syntax. The constant denotes inaction or deadlock, whereas the constant denotes successful termination [2]. For each action there is a unary operator denoting action prefix; the process denoted by can do an -transition to the process denoted by . The binary operator denotes sequential composition that behaves like , followed by only upon successful termination of . The binary operator denotes alternative composition or choice on the first action transition of and . The binary operator denotes parallel composition (with generic channel communication actions); actions of both arguments can be interleaved or, alternatively, communication takes place that keeps track of how many send or receive actions are combined. The unary operator is iteration or Kleene star that unfolds with respect to the sequential composition. The unary operator encapsulates the process in such a way that all (incomplete) communication actions, e.g., and , are blocked for all data, so that the desired type of communication is enforced, e.g., if we were to enforce communication between processes on channel , then .

### Semantics

We give semantics to the process terms by a labeled transition relation and a successful termination predicate . We employ infix notation and write if and if . We derive the transition relation and the successful termination predicate using structural operational semantics [22], given by the operational rules in Table 1. Alternatively, we depict them as a labeled transition system , specified by the tuple .

We briefly comment on the rules. The successful termination constant can successfully terminate, whereas the action prefix enables outgoing labeled transitions, as given by rules 1 and 2. Rule 3 states that iteration can always terminate successfully, which enables sequential composition of recursive processes. The unfolding of the iteration is with respect to the sequential composition, as given by rule 4. The sequential composition can terminate only if both processes can do so, as given by rules 5, whereas if only the first component can terminate successfully, it can continue behaving as the second. The outgoing transition of the first component is the same for the sequential composition as given by rule 7. Rules 8 and 9 state that alternative composition can terminate if one of the components can terminate, whereas the choice is made on the outgoing transitions, as stated by rules 10 and 11. The parallel composition can terminate only if both components can do so. Rules 13 and 14 enable interleaving of transitions. Rules 15 states that encapsulation does not prevent successful termination. Rule 16 defines synchronization which can occur on communication actions comprising at least one sending or receiving event. The communication actions are merged to accumulate the participating send and receive parties. Finally, rule 17 states that all (incomplete) communication actions on a given channel comprising a predefined number of senders and receivers are blocked by the encapsulation operation.

We can easily extend the transition relation to traces of actions in . For and , we write if there exist such that . By we denote the empty trace for and . Every finite automaton can be described up to isomorphism (and possibly by changing the communication operation) by a term in our setting, see [4].

### Language-based supervision

Now, we can translate the central notion of a supervisor [23, 10] in our setting. To this end, we partition the channel names into two disjoint sets of uncontrollable  and controllable  channels such that and . The uncontrollable and controllable channel names induce controllable and uncontrollable actions, respectively, given by and . Next, we define the (prefix-closed) language recognized by the process term or, alternatively, the automaton represented by , as . Note that traces do not need to end with successful termination. We denote by the concatenation of the languages and .

Recall that the supervisor cannot achieve the control requirements by forbidding uncontrollable events, when synchronizing with the plant. Suppose that the plant, the control requirements, and the supervisor with respect to the former are determined by the languages recognized by the process terms , respectively. If the operation modeling the control loop is denoted by , then and , where we refer to as the supervised plant. We note that if strict equality holds, then the control requirements can be achieved completely. Often, this is not the case, so one attempts to synthesize a maximally-permissive supervisor, which makes as large as possible with respect to inclusion. For deterministic systems, this supervisor is unique, equal to the union of all possible supervisors [23, 10], whereas for nondeterministic systems, a unique maximally-permissive supervisor in general does not exist [3]. For standard supervisory control [23, 10], the operation that models the control loop is the full synchronous parallel composition of automata [23, 10]. That does not disable uncontrollable events is ensured by requesting that is controllable with respect to , expressed as  [23, 10]. Controllability is interpreted as follows. If we observe a desired trace in the plant followed by an uncontrollable event, then the supervisor cannot request that this uncontrollable event should be disabled after allowing that trace. If is controllable with respect to , then one can guarantee the existence of a supervisor , achieving the desired controlled behavior by restricting the plant by synchronization, i.e., .

### Nondeterminism and partial bisimulation

The disadvantages of working in the language domain have been discussed on many occasions, e.g., see overviews in [14, 12, 3, 2]. Therefore, a proposal was made in [3] to lift controllability to support full nondeterminism in a process-theoretic setting. The underlying behavioral relation is partial bisimulation [24, 3], which is parameterized with a bisimulation actions set that denotes which actions are to be bisimulated, whereas the other actions are simulated.

###### Definition 1

A relation  is a partial bisimulation with respect to a bisimulation action set , if for all it holds that:

1. if , then ;

2. if for some , then there exists such that and ;

3. if for some , then there exists such that and .

If , we say that is partially bisimilar to with respect to and we write . If holds as well, we write .

Note that is a preorder relation, making an equivalence relation for all  [3]. If , then coincides with strong similarity preorder and coincides with strong similarity equivalence [13, 2]. When , turns into strong bisimilarity [13, 2]. Moreover, if , then for every . We also note that partial bisimilarity is a precongruence with respect to the operators of  [3].

For given processes , representing the plant and the control requirements, respectively, we ensure that is a valid supervisor that does not disable uncontrollable events by requiring that and , where is the set of uncontrollable events [3]. This setting covers both the existing deterministic and nondeterministic definition of controllability for discrete-event systems [3]. From the definition, it is also not difficult to observe, that one obtains the same supervised behavior for every . Thus, one direct benefit from our approach is a procedure for coarsest plant minimization that respects controllability, based on the partial bisimilarity equivalence.

Next, we model the supervisory control loop with event-based observations and we illustrate our approach by a use case involving coordination of an automated guided vehicle in a production line.

## 3 Control Loop with Event-Based Observations

We employ the process theory to formalize the behavior of the control loop with event-based observations, depicted in Figure 1b). According to the scheme, the plant cannot execute a controllable event without the permission of the supervisor, whereas the supervisor must not disable uncontrollable events. Nonetheless, the supervisor is able to observe execution of uncontrollable events in the plant, so that it can correctly determine the state of the plant and transmit correct control signals. Moreover, the supervisor should not execute uncontrollable events independently, as this does not contribute to his objective. In addition, the supervisor should not introduce deadlocks or livelocks explicitly, unless deadlock or livelock behavior is inherent to the plant. Finally, we assume that the supervisor is a (global) monolithic process, i.e., it is not comprised from multiple modular or distributed synchronizing supervisors [10]. Taking into account the above observations, we can specify the syntax of the plant processes  and the supervisor processes  as given by and , respectively:

 P::=0∣1∣c?d.P∣u!ℓ?kd.P∣P⋅P∣P+P∣P∥P∣∂E(P)∣P∗S::=1 ∣c!d.S ∣ u?d.S ∣ S+S ∣ S∗,

where , , , , and . To implement broadcast communication in the case when the supervisor sends control signals to several distributed components, which do not have to receive the control signals simultaneously, one would also need to introduce action priorities, cf. [5]. Due to page restrictions, we will not employ broadcast in the general form in this paper and, instead, we enforce three-way communication by employing only the encapsulation operator.

### Supervisory coordination of an automated production line

To illustrate our approach to supervisory control and the model of the control loop, we discuss a simple example concerning coordination of an automated guided vehicle (AGV) in an automated production line, depicted in Figure 2. The AGV is responsible for transferring the preproduct made by Workstation M to Workstation N and transferring the finished product from Workstation N to the Delivery station. The workstations and the AGV are coordinated by a supervisor, which sends the corresponding control signals. We can model the automated production system depicted in Figure 2 employing , where , , , and are process terms that model Workstation M, Workstation N, AGV, and the supervisor. We note that we abstract from the delivery station, depicted by a single event , as it does not contribute to any interesting behavior. We retain the communication channel names as depicted in Figure 2, whereas the data elements are . The uncontrollable channel names are , whereas is the set of controllable channel names.

 M≜(s?make.produce(preproduct).m!preproduct.1)∗N≜(n?preproduct.process(preproduct).n!product.1)∗A≜(m?preproduct.s?move2N.move(preproduct).n!preproduct.1+n?product.deliver(product).1)∗S≜(s!make.s!move2N.1)∗.

Workstation M repeatedly waits for a command from the supervisor to make a preproduct, which is offered to the AGV once it is made. Workstation N waits for a preproduct from the AGV, which is thereafter processed and offered back to the AGV. The AGV can either pick up a preproduct at Workstation M, after which it asks for permission to move the preproduct to Workstation N, or pick up a finished product at Workstation N and deliver it. Now, the unsupervised plant is given by the process

 U≜∂F(M∥N∥A), where F={m?,m!,n?,n!}.

At this point, we note that we enforce meaningful communication of uncontrollable channels within the plant by encapsulation and this does not restrict the behavior of the unsupervised plant, but only ensures its meaningful behavior. Following the framework outlined above, it can be readily observed that the plant follows the outlined syntax.

In this first modeling instance, we assume that the AGV is responsible for delivering the final product and we propose a supervisor as given by the process . Note that the supervisor follows the outlined syntax and it does not make use of any observed information. Supervisor  repeatedly gives orders to Workstation M for new products to be made, followed by orders to the AGV to transfer the preproduct to Workstation N. Thus, the automated production system is modeled as

 U/S≜∂E(S∥U), where E={s?,s!},

which enforces communication of control signals and transfer of (pre)products. One can directly check that is a valid supervisor by establishing that the supervised plant is partially bisimulated by the original plant with respect to the uncontrollable events. To this end, we must employ renaming of events, as the original plant has open communication actions that wait for synchronization with the supervisor. This renaming function traverses the process terms and renames all open communication actions to succeeded communication actions. We note that we overload the name of the renaming function of the process terms and apply it to the communication action names as well. Also, we only specify the communication actions that are actually renamed. The definition of the renaming operation is given by structural induction in Table 2.

Now, in order to verify that the supervisor does not disable uncontrollable events, it is sufficient to verify that it holds that

 U/S≤AUξ(U), where ξ:s?d↦s!?d for d∈D,

which can be directly checked. We note that there was no restriction imposed on the control requirements, which in this case coincide with the plant and are, therefore, trivially satisfied.

### Nonblocking supervision

Unfortunately, our automated production system has a deadlock. The main reason for the deadlock is that a second preproduct can come too early, before the first product is completely finished and delivered, which is set off by sending a command too early, i.e., before the processed product has left Workstation N. Then, the AGV picks up the preproduct from Workstation M, but it cannot deliver it to Workstation N, as the latter also waits for a finished product to be picked. A trace that leads to deadlock is

 s!?make produce(preproduct) m!?preproduct s!?move2N n!?preproducts!?make produce(preproduct) m!?preproduct s!?move2N process(preproduct) 0.

Such form of blocking behavior appears often, so in many cases the supervisor is additionally required to prevent deadlock and/or livelock, or also known as blocking, behavior [23, 10]. To this end, special marked states are introduced to automata in supervisory control. We note that these states roughly correspond to successful termination in our setting. The correspondence is not strict, mainly due to the absence of sequential composition and the Kleene star operator in the supervisory control literature and the role of the successful termination in these contexts, confer Table 1. Note that the marked states do not contribute to the formation of the recognized language of an automaton, which is different from its marked language [23, 10].

So, besides the control requirements, we impose an additional deadlock-freedom requirement on the supervisor, stated formally as: there exists no trace such that . To ensure this additional nonblocking requirement, we have to modify the supervisor to accept requests for making a new preproduct only after the finished product has been loaded on the AGV, to be transferred to the delivery station. To this end, the supervisor should allow for a new product to be made only after the finished product has been loaded to the AGV at Workstation N, which can be achieved by observing this additional information on channel .

To this end, we modify the supervisor to as follows:

 S′≜(s!make.s!move2N.n?product.1)∗.

At this point, we note that communication on the channel now must occur between three parties, i.e., Workstation N that sends information and the AGV and the supervisor that receive it. In order to enforce this communication, we employ the generic communication actions, i.e., we encapsulate all (incomplete) communication actions on , except for . The definition of the deadlock-free supervised plant now becomes:

 U/S′≜∂E′(S′∥U), where E′={s?,s!,n?,n!?}.

Again, one directly verifies that the supervisor is valid by establishing partial bisimilarity between the supervised and the original plant following an appropriate renaming of the incomplete communication actions, given by for .

Next, we extend the process theory to accommodate state-based observations as well.

## 4 Control Loop with State-Based Observations

We propose , an extension of , with propositional signals [6] and guarded commands in order to support the modeling of a control loop with state-based observations. To this end, we employ the Boolean algebra

 B=(N,F,T,¬,∧,∨,⇒),

where are the propositional symbols, the constants represent false and true, whereas the operators denote negation, conjunction, disjunction, and implication, respectively. We use to denote the standard Boolean expressions of , which are evaluated with respect to a given valuation . The set of valuations is denoted by .

### Process theory TCP∗⊥

We enrich the syntax of and the set of process terms with the inaccessible process constant, guarded commands, and signal emission. The inaccessible process, notation , specifies the process in which there are inconsistencies between the valuation of the propositional variables and the emitted propositional signals. Such a state cannot be reached from any consistent state. The guarded command, notation , specifies a guard that guards a process . If the guard is successfully evaluated, the process continues behaving as or, else, it deadlocks. The root signal emission process , emits the propositional signal until the process takes an outgoing transition, provided that the propositional signal is consistent with the valuation. To be able to evaluate the propositional expressions, we couple the process terms with valuations, notation . The dynamics of the valuations, with respect to outgoing labeled transitions, is captured by a predefined valuation effect function, given by . With respect to the valuation we have to extend the successful termination predicate to and the labeled transition relation to . We introduce an additional consistency predicate that checks whether the state is consistent. The operational rules in Table 3 give the semantics of the new predicate and the transition relation with respect to the new operators. We note that the operational rules of Table 1 have to be enhanced by decorating the process terms with valuations and additional checks for consistency.

The rules ensure that when taking an action transition, the target state is always consistent. We comment the important rules that are not directly taken from Table 1 and adapted in a setting with valuations. The deadlock, successful termination, and action prefix are always consistent as stated by rules 18, 19, and 21, respectively. The target process must be consistent for the target valuation, which is determined by the effect function as given by rule 22. Rules 23-27 introduce valuations and consistency for the alternative composition, whereas rules 28-32 do the same for the sequential composition and rules 33-35 describe iteration. Rules 38 and 39 introduce interleaving in the new setting. Rule 40 shows how the effect function is impacted by synchronization. For the effect function to be well-defined with respect to the valuations by interleaving and synchronization [2], we require additionally that

 effect(c!ℓ+m?k+nd,v)⊆effect(c!m?nd,effect(c!ℓ?kd,v))∩effect(c!ℓ?kd,effect(c!m?nd,v))

for all with and . Rules 41-43 introduce the encapsulation operator in the new setting. Rules 44 and 47 show that a guarded process does not deadlock only when the guard evaluates to true. We note, however, that the value of the guard does not affect the consistency of the term, provided that the term that is guarded is consistent. This is in direct contrast with signal emission, see rule 49, where the consistency is preserved only if the emitting signal is consistent within the valuation. In that case, the process that emits the signal can continue with its normal execution.

Finally, we also have to adapt our behavioral relation in order to correctly handle the valuations. Here, we directly employ the approach of [6, 2], where this extension is shown for bisimulation. We consider a relation  to be a partial bisimulation with respect to a bisimulation action set , if for all it holds that:

1. if for some , then ;

2. if for some and , then there exists such that and ;

3. if for some and , then there exists such that and .

Again, if , we say that is partially bisimilar to with respect to and we write . If holds as well, we write . Also, we consider a process to be a supervisor of the plant with respect to the control requirements if and .

### Plant and supervisor syntax

Now, we can model the control loop with state-based observations as depicted in Figure 1c). Intuitively, the plant emits a signal that identifies the observable states. Upon observing such a signal, the supervisor checks which controllable actions are allowed in the state identified by the signal. Allowance of actions is specified in the form of guarded prefixes in which a process term is bound to a propositional formula deduced from the control requirements. These new concepts introduce further asymmetry in the control loop, where the syntax of the plant and the supervisor is again given by and , respectively:

 P::=0∣1∣c?d.P∣u!ℓ?kd.P∣P⋅P∣P+P∣P∥P∣∂E(P)∣ϕ:→P∣ϕto0.0pt\raisebox2.15pt$∧$\raisebox2.15pt$▲$P∣P∗S::=1 ∣c!d.S ∣ S+S ∣ ϕ:→S ∣ S∗,

for , , , , , and .

We note that in the state-based setting, the control requirements can be stated directly in terms of states, i.e., signals that the state is emitting, and additionally, one can specify which events are allowed with respect to the emitted signals. The control requirements have the following syntax given by :

 R::= ϕ ∣ f!m?nd⟶⇒ϕ ∣ ϕ⇒f!m?nd⟶,

for , , , and . Given control requirements are satisfied with respect to process in the valuation , notation , according to the following operational rules:

 \small51 v(ϕ)=T⟨p,v⟩⊨ϕ\small52 ⟨p,v⟩⊨¬ϕ⇒f!m?nd⟶⟨p,v⟩⊨f!m?nd⟶⇒ϕ\small53 v(ϕ)=T, ⟨p,v⟩f!m?nd⟶⟨p,v⟩⊨ϕ⇒f!m?nd⟶,

where for holds if there does not exist such that with . We note that the second form of the control requirements is introduced since it corresponds better to modeling intuition and it is equivalent to the third, which is easily seen from the operational rule 52. Furthermore, for the propositional symbols, we employ the notation , where is a signal emitted from the process, corresponding to a state in the labeled graph representation identified by . For example, in the Current Power Mode process in Figure 5, the process modeling the state with associated name emits the signal .

## 5 Coordination Control of Maintenance Procedures

We employ the process theory to model the coordination of maintenance procedures of a printing process of a high-end Océ printer [19]. The printing process consists of several distributed independent components as depicted in Figure 3a). The process applies the toner image onto the toner transfuse belt and fuses it onto the paper sheet. To maintain high printing quality, several maintenance operations have to be carried out, like: toner transfuse belt jittering, which displaces the transfuse belt to prolong its lifespan due to wearing by paper edges; black image operation, which removes paper dust by occasionally printing completely black pages; coarse toner particles removal operation; etc. Most maintenance operations are scheduled after a given number of prints, but must be carried out after a given strict threshold. To perform a maintenance operation, the printing process has to change its power mode, from Run mode, used for printing, to Standby mode, required for maintenance. However, this change can actually trigger pending maintenance operations, which may unnecessary prolong the user waiting time.

As an illustration, in Figure 3b) we depict the situation, where due to inevitable execution of maintenance operation A, the ongoing print job is suspended and the power mode of the printer is changed to Standby. However, an unwanted situation occurs, i.e., the power mode change triggers a longer, yet postponable maintenance operation B as depicted in Figure 3c). For instance, a black image operation (A) must be performed, which takes the time needed to print one page and is activated often, but the switching of the power mode triggers the much longer toner transfuse belt jittering (B), thus making the user wait unnecessarily.

The goal of the research performed for this use case was to eliminate undesired emergent behavior due to interactions of otherwise correctly-functioning distributed components, with primary focus at coordinating maintenance operations. Our approach was to synthesize a supervisory coordinator for the maintenance procedures [19], which here we model in the proposed process theory.

### Informal description of the printing process

An abstract view of the control architecture of a high-end printer is depicted in Figure 4. Print jobs are sent to the printer by means of the user interface. The printer controller communicates with the user and assigns print jobs to the embedded software, which actuates the hardware to realize print jobs. The embedded software is organized in a distributed way, per functional aspect, such as, paper path, printing process, etc. Several managers communicate with the printer controller and each other to assign tasks to functions, which take care of the functional aspects.

We depict a printing process function comprising one maintenance operation in Figure 4. We abstract from all timing behavior, which can be present in some control signals, e.g., execute a maintenance procedure after a given delay. Each function is hierarchically organized as follows: (1) controllers: Target Power Mode and Maintenance Scheduling, which receive control and scheduling tasks from the managers; (2) procedures: Status Procedure, Current Power Mode, Maintenance Operation, and Page Counter, which handle specific tasks and actuate devices, and (3) devices as hardware interface.

The Status Procedure is responsible for coordinating the other procedures given the input from the controllers. It will be implemented as a supervisory coordinator with respect to the coordination rules given below. The Current Power Mode procedure sets the power mode to Run or Standby depending on the enabling signals from the Status Procedure and , respectively. The confirmation is sent back via the signals and , respectively. Maintenance Operation either carries out maintenance operation or it is idle. The triggering signal is and the confirmation is sent back by . The Page Counter procedure counts the printed pages since the last maintenance and sends signals when soft and hard deadlines are reached using and , respectively. The counter is reset each time the maintenance is finished, by receiving the confirmation signal from Maintenance Operation. The controller Target Power Mode defines which mode is requested by the manager by sending the control signals and to the Status Procedure. Maintenance Scheduling receives a request for maintenance from Status Procedure via the signal , which it forwards to a manager. The manager confirms the scheduling with the other functions and sends a response back to the Status Procedure via the control signal . It also receives feedback from Maintenance Operation that the maintenance is finished in order to reset the scheduling.

### Plant modeling in TCP∗⊥

We model the procedures by means of processes. We retain the names of the control signals, turning them into communication actions where appropriate. The controllable communicating channels are the given by , modeled as receive actions in the plant. We note that we abstract from data elements as communication should only enforce ordering of events. The other actions are uncontrollable, also prefixed by , where only is modeled as a communication action, as the procedure Maintenance operation must send signals and reset Page Counter and Maintenance Scheduling. The signals emitted from the plant uniquely identify the state of the plant. For clarity, we also depict the processes in Figure 5, where the signal names are given next to the states that emit them. Page Counter is modeled by the process , where is modeled as a receive action, to be synchronized with Maintenance Operation:

Maintenance Operation is specified by the process , where broadcasts that the maintenance operation has finished:

Target Power Mode is modeled by :

whereas Current Power Mode is given by :

Finally, Maintenance Scheduling is specified as :

Due to the generic valuation effect function, we need to impose additional restriction on the emitted signals. More precisely, we wish that the signals emitted in a process are not ambiguous, e.g., it cannot be that both and are valid at the same time as these are two distinct states that belong to the same process. Note, however, that this situation is possible as one can easily construct a valuation effect function that always assigns the same values to the above propositional symbols. However, such misconstrued valuations can actually lead to wrong supervised behavior as the supervisor bases its decision on the emitted signals, which are deduced from the valuations. At this point, we have two viable options. One is to make the signal emission complete and rewrite all signal emissions such that the effect function leads to inconsistencies unless it uniquely defines each state. For example, then we would have to rewrite to :

 T′≜((in(TargetStandby)∧¬in(TargetRun))to0.0pt\raisebox2.15pt$∧$\raisebox2.15pt$▲$_TargetRun.((¬in(TargetStandby)∧in(TargetRun))to0.0pt\raisebox2.15pt$∧$\raisebox2.15pt$▲$_TargetStandby.1)∗,

and adapt the rest of the processes analogously. The other option is to set an invariant process in parallel to the components that will ensure that only one state can be identified per process. To this end, we define the operation for a set of propositional symbols , which ensures that only one propositional symbol, i.e., one signal, is exclusively emitted per state. Now, the invariant process that enforces this restriction can be specified as:

 I≜((⋀5i=1⨁P∈{Si}P)to0.0pt\raisebox2.15pt$∧$\raisebox2.15pt$▲$0)∗,

where for contain the signals emitted by the processes , , , , and , respectively, i.e.,

Finally, the unsupervised plant can be specified as given by:

 U≜∂F(C∥O∥T∥P∥M)∥I,

where enforces a three-way communication between , , and . We note that due to the stringent streamlining invariant, the role of the valuation effect function is now diminished and one can simply assume that for every and .

### Coordination requirements

We synthesized a coordinator that implements Status Procedure, see Figure 4, which coordinates the maintenance procedures with the rest of the printing process. The following coordination requests describe the behavior of the Status Procedure:

1. Maintenance operations can be performed only when the printing process is in standby;

2. Maintenance operations can be scheduled only if soft deadline has been reached and there are no print jobs in progress or a hard deadline is passed;

3. Maintenance operations can be started only after being scheduled;

4. The power mode of the printing process must follow the power mode dictated by the managers, unless overridden by a pending maintenance operation.

We formalize these control requirements as follows:

1. The maintenance procedure is performed if the process emits the signal , while emitting the signal as well:

 R1≜in(OperInProg)⇒in(Standby).
2. For the control signal SchedOper! to be sent to Maintenance Scheduling, either one of the following must hold: (1) A soft deadline has been passed, identified by emission of the signal , and there are no print jobs waiting, meaning that the target power mode is not in run, identified by the signal ; or (2) A hard deadline has been passed, indicated by the signal . This is captured by the following control requirement:

3. The maintenance operation can be started by sending the control signal OperStart! only if it has been scheduled, prompted by the emission of the signal :

 R3≜OperStart!⟶⇒in(ExecuteNow).
4. If we want to switch from standby to run power mode, indicated by sending the control signal Stb2Run!, then this has been requested by the target power mode manager by emitting the signal , provided that there are no maintenance operations scheduled, for which the signal should be checked:

When switching from run to standby power mode, indicated by sending the control signal Run2Stb!, the target power mode should be in standby, given by emission of the signal . An exception is made when a maintenance operation is scheduled to be executed, given by emission of the signal :

 R4,2≜Run2Stb⟶⇒in(TargetStandby)∨in(ExecuteNow).

### Supervisor synthesis

With respect to the control requirements we synthesized a deadlock- and livelock-free maximally-permissive supervisor [19]. The supervisor sends the control signals upon observation of certain signal combinations, which are given in the form of guards. The indices of the guards correspond to the indices of the control requirements that concern the control signal:

The supervisor is given by :

 S≜(g2:→SchedOper!.1+g3:→OperStart!.1+g4,1:→Stb2Run!.1+g4,2:→Run2Stb!.1)∗.

Now, the supervised plant is given by:

 U/S≜∂E(S∥U), where E={c!,c?∣c∈C}.

Again, we can show that the supervised plant is partially bisimilar to the original plant with respect to the uncontrollable events by showing that

 U/S≤AUξ(U), where ξ:c?↦c!? for c∈C.

The above form of the supervisor does not provide much information regarding the choices made. It can be visualized as a single state transition system with four outgoing guarded transitions. However, it is not difficult to deduce that initially the event Run2Stb is not possible since the initial signal is . Also, StartOper is initially unavailable as the signal is not emitted. In order to better understand the consequences of the control choices made by the supervisor and the thereafter enabled controllable events, we depict an alternative supervisor in Figure 6. We note that both variants of the supervisor produce equivalent supervised behavior (the guards remain the same), the difference being that the supervisor depicted in Figure 6 reveals the consequences of choosing a particular controllable action. We can now observe, that if the operation is scheduled while the printing process is in standby power mode, then it can be directly executed, returning the supervisor to the initial state. However, if the power mode is run, then the maintenance operation can still be scheduled, but the system has to switch to standby power mode before it can be executed.

## 6 Conclusions and Future Work

We modeled two prominent types of supervisory control loops, one employing event-based observations and the other employing state-based observations. To this end, we revisited the process theory of [2], where we introduced generic communication actions to model communication between multiple parties, and we applied the developed theory to model the control loop with event-based observations. We classified the processes modeling the unsupervised system and the controller to capture their specific goals. We illustrated our approach on an academic example of coordinating an automated guided vehicle in a production line. To model the control loop with state-based observations as well, we extended the process theory with guarded commands and root signal emission, leading to . We reiterated on an industrial study dealing with coordination of maintenance procedures in a printing process of a high-tech printer. We demonstrated that our approach is capable of modeling the interaction in the control loop precisely by distinguishing between the information flows of the observations and the control signals.

### Application of process theory in supervisory coordination

The work presented in this paper is merely the third step in our investigations regarding application of process theory in supervisory control and coordination. Our prior work identified and employed partial bisimulation as a suitable behavioral relation to capture the central notion of controllability [3]. Based on this relation we developed an efficient minimization procedure for nondeterministic plants that respects controllability. Here, we modeled the most prominent variants of the supervisory control loop and further calibrating the process algebra with respect to the notions that are needed to correctly capture the central notions of supervisory control theory.

The issues are far from resolved. We intend to proceed in several directions of research, where we expect that a process-theoretic approach can advance the theory and/or define the notion more clearly and concisely. One issue that we partially treat in this paper is the notion of partial observability, which is an inherent property of plants in which due to unavailability of sensors certain information is unobservable to the supervisor [10]. There is a lot of work regarding partial observability of events, which can be treated as uncontrollable actions that are not communicated to the supervisor or as silent steps from which the supervisor has to abstract. The first option is already present in the current setting, whereas the second approach is more than familiar in the process-theoretic community. An unavoidable complication in supervisory control is that the supervisor must not make a wrong control choice, irrespective of not being able to observe the correct state of the plant, making partial observability a global property [3]. In the setting with state-based observations, one can easily abstract from state information by emitting slightly ambiguous signals, e.g., instead of uniquely identifying as being in states or , one can emit the signal . We intend to further investigate the mechanics of state abstraction in supervisory control.

As expected, there are quantitative extensions of supervisory control theory employing real and stochastic timing, probabilities, and data. However, the supervisory control community seems to struggle with clear and acceptable definitions of controllability, as typically these follow the original approach of [23] and are, thus, given in trace semantics. There are other approaches that are instead based on games, but these often suffer from great computational complexities. We believe that here the community of process theory and verification can contribute a great deal, both in providing suitable definitions and algorithms for minimization and supervisor synthesis. Finally, the supervisor synthesis algorithms almost always have distributed, decentralized, modular, or hierarchical implementations. Concurrency is inherent to our work, and we believe that there are a lot of interesting problems, issues, and challenges that are hidden in this exciting field.

## References

• [1]
• [2] J. C. M. Baeten, T. Basten & M. A. Reniers (2010): Process Algebra: Equational Theories of Communicating Processes. Cambridge Tracts in Theoretical Computer Science 50, Cambridge University Press.
• [3] J. C. M. Baeten, D. A. van Beek, B. Luttik, J. Markovski & J. E. Rooda (2011): A Process-Theoretic Approach to Supervisory Control Theory. In: Proceedings of ACC 2011, IEEE. Available from: http://se.wtb.tue.nl.
• [4] J. C. M. Baeten, B. Luttik, T. Muller & P. van Tilburg (2010): Expressiveness modulo Bisimilarity of Regular Expressions with Parallel Composition (extended abstract). In: Proceedings of EXPRESS 2010, Electronic Proceedings of Theoretical Computer Science 41, pp. 1–15, doi:10.4204/EPTCS.41.1.
• [5] J. C. M. Baeten & W. P. Weijland (1990): Process algebra. Cambridge Tracts in Theoretical Computer Science 18, Cambridge University Press, doi:10.1017/CBO9780511624193.
• [6] J.C.M. Baeten & J.A. Bergstra (1997): Process algebra with propositional signals. Theoretical Computer Science 177, pp. 381–405, doi:10.1016/S0304-3975(96)00253-8.
• [7] S. Balemi, G. J. Hoffmann, P. Gyugyi, H. Wong-Toi & G. F. Franklin (1993): Supervisory control of a rapid thermal multiprocessor. IEEE Transactions on Automatic Control 38(7), pp. 1040 –1059.
• [8] G. Barrett & S. Lafortune (1998): Bisimulation, the Supervisory Control Problem and Strong Model Matching for Finite State Machines. Discrete Event Dynamic Systems 8(4), pp. 377–429, doi:10.1023/A:1008301317459.
• [9] H. Beohar & P.J.L. Cuijpers (2010): A theory of desynchronisable closed loops system. In: Proceedings of ICE 2010, Electronic Proceedings in Theoretical Computer Science 38, Open Publishing Association, pp. 99–114, doi:10.4204/EPTCS.38.10.
• [10] C. Cassandras & S. Lafortune (2004): Introduction to discrete event systems. Kluwer Academic Publishers.
• [11] V. Chandra, Z. Huang, W. Qiu & R. Kumar (2004): Prioritized Composition With Exclusion and Generation for the Interaction and Control of Discrete Event Systems. Mathematical and Computer Modelling of Dynamical Systems 9(3), pp. 255 – 280.
• [12] M. Fabian & B. Lennartson (1996): On non-deterministic supervisory control. Proceedings of the 35th IEEE Decision and Control 2, pp. 2213–2218.
• [13] R. J. van Glabbeek (2001): The linear time–branching time spectrum I. Handbook of Process Algebra , pp. 3–99.
• [14] M. Heymann & F. Lin (1998): Discrete-Event Control of Nondeterministic Systems. IEEE Transactions on Automatic Control 43(1), pp. 3–17, doi:10.1109/9.654883.
• [15] M. Heymann & G. Meyer (1991): Algebra of discrete event processes. Technical Report NASA 102848, NASA Ames Research Center.
• [16] R. Kumar & M. A. Shayman (1996): Nonblocking Supervisory Control of Nondeterministic Systems via Prioritized Synchronization. IEEE Transactions on Automatic Control 41(8), pp. 1160–1175, doi:10.1109/9.533677.
• [17] R. Kumar & C. Zhou (2007): Control of Nondeterministic Discrete Event Systems for Simulation Equivalence. IEEE Transactions on Automation Science and Engineering 4(3), pp. 340–349, doi:10.1109/TASE.2006.891474.
• [18] C. Ma & W. M. Wonham (2005): Nonblocking Supervisory Control of State Tree Structures. Lecture Notes in Control and Information Sciences 317, Springer.
• [19] J. Markovski, K. G. M. Jacobs, D. A. van Beek, L. J. A. M. Somers & J. E. Rooda (2010): Coordination of Resources using Generalized State-Based Requirements. In: Proceedings of WODES 2010, IFAC, pp. 300–305.
• [20] S. Miremadi, K. Akesson & B. Lennartson (2008): Extraction and representation of a supervisor using guards in extended finite automata. In: Proceedings of WODES 2008, IEEE, pp. 193 –199.
• [21] A. Overkamp (1997): Supervisory Control Using Failure Semantics and Partial Specifications. IEEE Transactions on Automatic Control 42(4), pp. 498–510, doi:10.1109/9.566659.
• [22] G. D. Plotkin (2004): A structural approach to operational semantics. The Journal of Logic and Algebraic Programming 60-61, pp. 17–139, doi:10.1016/j.jlap.2004.05.001.
• [23] P. J. Ramadge & W. M. Wonham (1987): Supervisory Control of a Class of Discrete Event Processes. SIAM Journal on Control and Optimization 25(1), pp. 206–230, doi:10.1137/0325013.
• [24] J. J. M. M. Rutten (1999): Coalgebra, concurrency, and control. SEN Report R-9921, Center for Mathematics and Computer Science, Amsterdam, The Netherlands.
• [25] P. Tabuada (2008): Controller synthesis for bisimulation equivalence. Systems and Control Letters 57(6), pp. 443–452, doi:10.1016/j.sysconle.2007.11.005.
• [26] S. Xu & R. Kumar (2008): Asynchronous implementation of synchronous discrete event control. In: Proceedings of WODES 2008, IEEE, pp. 181 –186.
• [27] C. Zhou, R. Kumar & S. Jiang (2006): Control of nondeterministic discrete-event systems for bisimulation equivalence. IEEE Transactions on Automatic Control 51(5), pp. 754–765, doi:10.1109/TAC.2006.875036.
You are adding the first comment!
How to quickly get a good reply:
• Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
• Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
• Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
The feedback must be of minimum 40 characters and the title a minimum of 5 characters