Basics

Given a model P of a process to be controlled, and a specification Sp describing the desired behavior, we want to synthesize a controller S such that the closed-loop system, where S observes and influences P, fulfills the specification. This simple enough statement raises several questions.

1.    What is it that S observes?

2.    How does S influence P?

3.    What do we mean by “fulfilling the specification”?

Observation

In the interaction between the controller and the plant both events and states could realistically be observed. The controller will look very different depending on whether the states or the events are observed. This may sound strange, given that the events are intimately tied to the states; an event is associated with a change of state, and a state-change is associated with an event (assuming full observation). However, the same event may be associated with different state-changes. The states are unique, but the state-changes need not be. This is the root of the difference between state-observation and event-observation controllers.

Since the states are unique, a controller observing the plant states can base its control decision solely on the observed plant-state together with its own state. Furthermore, in some cases the controller need not even have a state of its own, but can determine the control action based on the plant-state alone. On the other hand, observing events that do not necessarily uniquely determine the exact state-change means that the controller musthave a state of its own that “memorizes” the trace leading to the current event. For example, the same plant-state can be visited several times during a trace, each time with a different control action. Thus, the controller must decide its action not only on the current event but also on how that event occurred.

Just as we could characterize the specification as either static or dynamic, we can characterize controllers as being either static or dynamic.

A static controller uniquely decides its control action based on its observation of the current plant-state. This is often referred to as combinatorial control or interlocking, since the control is based on combinations of sensor signals describing the process’ current state. A controller can only be static when it can observe “enough” of the plant-state with relation to the specification. This, in turn, can only occur when the part of the specification that can be achieved is static. Note that the given specification need not be controllable, since not all of it can be accomplished by the controller. Only the parts that can actually be accomplished have to be static, see below.

In the cases that

1.      the achievable part of the specification is dynamic, or

2.      the state-observation is not sufficient,

the controller must be dynamic. This means that the controller has its own dynamic behavior. It is an automation in one form or another. Then the control action is determined by the current plant-state together with the current state of the controller itself. Observe that event-observation only, is an extreme case of insufficient state-observation. Note also that although the specification may be static, insufficient plant-state observation can require a dynamic controller.

Static and Dynamic Controller

Assume that we have the specification aab for P1 above. To control P1 so that this specification is fulfilled the control action must be different after the respective a events. After the first one the control action is another a and after the second a it is a b. If the controller can observe the state the control action can be uniquely determined. In the p1 state an a is required while in p2 a b is needed.

If for P2 the specification is aba and bab as desired and allowed traces, different control actions are required in the q1 state depending on how it was reached. After an a reaching q1 the control action must be b, while after a b an a is required. However well the controller observes the plant-state, it cannot uniquely determine the control action in q1. The control action must be determined by the way q1 was reached, whether it was by a or by b. The only way for the controller to “remember” these events is to follow along as they occur. That is, it must be an automaton with a dynamic behavior of its own.

In the same way, if a controller cannot observe the p1 state, as when it observes only the events of P1, it must count the occurring a’s to be able to decide its control action. The only way for it to count the a’s is to follow along as they occur. That is, it must be dynamic.

Influence

The question of how the controller influences the plant is basically a matter of where the events are generated. Though the avoidance of any causality concept considerably simplifies the theoretical discussions, the question of “who generates what” will eventually turn up. In the implementation phase, if not sooner.

The supervisory control theory (SCT) of Ramadge & Wonham (1987) is the foundation for the work presented in this chapter. In the original model proposed by Ramadge (1987) the plant is assumed to generate all events. The controller, called a supervisor, is regarded as a passive follower that dynamically restricts the choices of events which the plant can generate. Thus, the plant “wildly” generates events and the supervisor influences the plant behavior, and hence the closed-loop system, by enabling or disabling events.

However, from a control-engineering point of view, it seems more natural to regard the plant as generating some kind of output in accordance with some input. Thus, it is natural to view the controller as an active device generating input to the plant. It is observed by Balemi (1992) that in most real life systems events are seldom generated spontaneously, but only as responses to commands. For instance, a manufacturing device does not start its processing spontaneously, but only because of some start signal. The plant automaton can in this way be interpreted as the (discrete event) transfer function between the input commands and the output responses. Note that the distinction between a static and dynamic controller is not the issue here. A supervisor that enables and disables plant events can still be either static or dynamic in the sense described above. A static supervisor can be regarded as a mapping between the plant states and the disabled (or enabled) events. A dynamic supervisor consists of an automaton together with a map between the plant and the supervisor states and the disabled (or enabled) events. The difference between the original Ramadge/Wonham asymmetric feedback loop and Balemis symmetric feedback loop is illustrated in Figure 20. The function f in Figure 20 is a disablement map; for a static supervisor f is a function from QP to , while for a dynamic supervisor f is a function from  to .

Figure 20. The original Ramadge/Wonham supervisor approach (left), and the input/output interpretation controller (right).

Thus, we can distinguish between two types of controllers

·        Supervisor. S influences P by saying, “I know what events you can generate in your current state, of those you may generate anyone except these”.

·        Controller. S influences P by saying, “I know what events you can generate in your current state, of those I want you to execute this one”[1].

The difference between these two types of controllers may seem superficial. After all, disabling all but one event in each state would make a controller out of a supervisor. However, with the symmetric feedback loop additional restrictions must be placed on the controller compared to the supervisor of the asymmetric feedback loop.

Let us first point out that both a controller and a supervisor must be such that it can always accept the events that it permits the plant to generate. For a static supervisor or controller this is trivially satisfied since only the states are observed. However, a dynamic controller is supposed to follow the plant and to base its control decision on its view of the plant-state. Thus, it cannot be allowed to not follow a plant-generated event since then it would not have a correct view of the current plant-state[2]. The additional constraint that must be placed on a controller in the symmetric feedback loop concerns the events generated by the controller. As a controller generates an event, it transits to a new state. Obviously, this state must accord with the current plant-state after the plant has followed the controller-generated event. Thus, the controller cannot be allowed to generate events that the plant cannot follow. So, both supervisors and controllers must be designed such that they can always follow the plant-generated events. Additionally, controllers must also be designed so that they never generate events that the plant cannot follow.

Ramadge (1987) modeled a supervisor as an automaton together with a disablement function that decided which plant-events to disable based on the current supervisor-state. Kumar (1991) showed that this could be modeled by synchronous composition. As described in Chapter 2, when two automata, M1 and M2, say, interact by synchronous composition, events in  occur if and only if they can simultaneously occur in both automata. In this way, each of them control events in their own alphabet. If an event is not defined from a state , than the event cannot be executed in any state  in the composed system. Thus, if the supervisor operated in synchrony with the plant, then an event in a state could be disabled by the supervisor not defining this event for that state. The disablement map would thus be encoded in the transition function of the supervisor. This can be understood as events disappear in the synchronous composition between the plant and the controller; events that could otherwise have been generated by the plant. This has several benefits. The most prominent one being that it is easy to show that under the restrictions we place on the supervisor (see above and below) the closed-loop system  will be equal to S, that is . This means the supervisor is a model of the closed-loop system, so that for the closed-loop system to have certain properties (such as being trim) it is sufficient to guarantee that the supervisor itself possesses those properties. This allows us to “shape the loop” in a similar sense to what can be done for “classical” control systems

Balemi (1992) showed that the symmetric feedback loop can also be modeled by synchronous composition. The added constraints on the controller do not incur any additional problems. In fact, the extra constraint that must be put on the controller is trivially satisfied if the total specification refines the plant. This is something that we can always assume about the specification. Our initial candidate for a supervisor will always be S0 of Chapter 3, or something derived from it.

Fulfilling the Specification

It is the responsibility of the controller-designer to ensure that the specification is met. However, due to limitations of the plant there are no guarantees that a given specification can be met exactly. Necessary design considerations (such as the requirements on the controller mentioned above) may result in the controlled system only fulfilling a smaller part of the specification, in the worst case nothing at all. Note that this may be (and often is) a valid fulfillment of the specification. Consider, for instance, a machining device that may breakdown if it is started. Given a specification saying that we do not want the machine to break down, not starting it actually fulfils that specification. Obviously, such a null controller avoids doing anything wrong, but only at the cost of doing nothing at all. Thus, it is not very useful. To avoid this (where possible), we require the specification to be met “as well as possible”. The intent is that this assumption, which can be regarded as a specification itself, a sort of meta specification, will give us a unique “best” (in some sense) controller. Note that the null controller may still be the only valid controller, as when the specification is too strong, for instance.

The meta specification raises the problem of defining what it actually means. Depending on the application, it may mean things like “as fast as possible”, “as robust as possible”, “as cheap as possible” and so on. We will take the meta specification to mean “with as little intervention as possible”. Thus, we want to find the controller that allows the plant the greatest amount of freedom, measured in the number of states it can visit.

Intuitively, this controller would be the one obtained by synchronizing the plant P with the specification Sp, that is, what we have called S0 earlier. This is true to some extent since it fulfills the requirements mentioned above; S0 can always accept the events that it would allow P to generate in the closed-loop system. However, there is an additional aspect that we have not yet mentioned. The alphabet of the plant contains both controllable and uncontrollable events. The controllable events are subject to influence by the controller. The controller is allowed to control those, in any way it sees fit. Thus, controllable transitions (that is, transitions labeled by controllable events) are allowed to disappear in the synchronous composition between the plant and the controller. On the other hand, the uncontrollable events cannot be influenced by the controller. This is precisely why they are said to be uncontrollable. If the plant enters a state from which it can execute an uncontrollable event, it can do so with or without the participation of the controller.

This also means that in the synchronous composition between the plant and the controller uncontrollable transitions are not allowed to disappear. This so, since if the closed-loop system reached a state from which an uncontrollable event was not defined, then the requirement above that the controller should always be able to follow the event generation of the plant is broken. The plant could still choose to execute that uncontrollable event but the controller would not be able to follow. Note that, in the model of the closed-loop system, transitions disappear from a state solely because they are not defined by the controller from its corresponding state.

A controller that is able to follow all uncontrollable events that it allows the plant to execute is said to be controllable. Let us define this formally.

Definition 1, Controllability. A controller S is controllable with respect to a plant P and a set of uncontrollable events  if

Controllability

Above, the controllability property is pictured. After the mutual trace s the plant can execute the uncontrollable event  and the two controllable events  and , but the controller S defines  only. Thus, in the corresponding state of the closed-loop system, the (dotted) transitions with  and  disappears. That  is not defined by S is fine, and means that S controls this transition not to be executed in the closed-loop system. However, the uncontrollable event not being defined by S in qS is not acceptable. The plant can execute , just because it is uncontrollable, whether S participates or not, and if it does the controller will have an incorrect view of the current plant-state. It will assume that P is still in qP. Obviously, this may cause any kind of undesired behavior from the closed-loop system. Assume for instance that S is a controller that commands the plant, then it could issue a command valid in qP that may not only be invalid in the actual current plant-state but even catastrophic.

Controllability is defined in Definition 1 from an automata point-of-view. This is usually referred to as completeness. The controllability property is usually defined from a language point-of-view, see Ramadge (1987), for instance. However, given the one-to-one correspondence between a regular language and its (minimal) automata representation it is not surprising that the language definition of controllability can be proven equivalent to the automata definition[3]. We give the controllability definition in its language formulation since this is a better known definition of controllability.

Definition 2, Controllability. A controller S is controllable with respect to a plant P and a set of uncontrollable events  if

                               q

As mentioned above, the two definitions of controllability are equivalent.

Now we are interested in finding out when (if at all) a controller exists that can guarantee that the closed-loop system fulfils a given specification for a given plant. For this, we first have to make the following observation.

Lemma 1. Given a controller S for a plant P with uncontrollable events , when S is controllable then the closed-loop system  is controllable (both with respect to the plant).

Proof. Without loss of generality can assume that . We will show this lemma by showing its contra-positive, that is, that  not controllable implies that S is not controllable.

That  is not controllable means by definition that there exists a trace s in both P and , and an uncontrollable event, such that  is defined in P after s but not in . Obviously, if  is defined in P after s but not in , then it can only have disappeared in the composition due to it not being present in S.  Thus, S is not controllable. q

The proof above can be made much more formal, but this suffices for us. To get an intuitive feel for Lemma 1, consider the controllability example above, with and without S defining the uncontrollable event.

The following theorem defines precisely when a controller does exist.

Theorem 1. Given a plant P and a specification S0, there exists a controllable supervisor S such that  if and only if S0 refines P and S0 is controllable.

Proof. We use Lemma 1 above to show this.

() Assume such an S exists so that , Then, according to Lemma 1, S0 is controllable. Furthermore, then  so that S0 refines P.

() Assume that S0 refines P and is controllable. Choose . Then S is controllable and refines P. Thus,  so that there does exist such an S.                                                                 q

Theorem 1 tells us that for the existence of a supervisor guaranteeing that the entire specification can be achieved, that specification must be controllable. This also means that for the specification to be used as the controller, it must be controllable. This is (unfortunately) something that is implicitly exploited in industrial (and other) implementations of discrete event control. For instance, SFC programming for PLCs (see Chapter 5) relies on the ability to directly program a model of the closed-loop system (that is, a specification) and to use it as a controller. Obviously, this approach will seriously (and perhaps mysteriously) fail for systems where the specification is not controllable.

Requiring the specification to be controllable essentially means that regardless of any uncontrollable events that the plant can execute within the specification, it must remain within the specification. This is sometimes paraphrased as “if we don’t know where it’s taking us, it better not take us somewhere bad”. This is illustrated in Figure 21. This is, of course, actually the exact same requirement that we place on the controller, though from a slightly different viewpoint. The specification specifies an allowed and desired sub-behavior of the plant. If the plant can uncontrollably violate that behavior, then no controller can guarantee its fulfillment.

Figure 21. The specification is uncontrollable if an uncontrollable event takes the plant outside the specification.

In general, the given specification is not controllable. In that case, we have to find the controllable sub-automaton of the specification to replace S0 in Theorem 1. This we emphasize in the following corollary to Theorem 1.

Corollary 1. Given a plant P and a specification S0 there exists a controllable supervisor S such that  if and only if there exists a controllable sub-automaton  such that refines P.

Proof. The proof is immediate from Theorem 1. Simply replace S0 in Theorem 1 with q

The idea behind this corollary is illustrated in Figure 22.

Figure 22. When the specification is not controllable, there exists a controller enforcing a controllable subset of it.

Note that Corollary 1 does not require S0 itself to refine P.  However, one way to guarantee that  refines P is to require that S0 refines P.  In the way we generate our S0 it will always refine P so that any of its sub-automata will also refine P (refine is transitive, remember?).

But, we do not want find just any sub-automaton of the specification. The null automaton is, for instance, always a solution though not a very useful one. We want to find the largest achievable sub-automaton of S0, since that is what we defined as fulfilling the specification “as well as possible”. However, before going to look for it, we must ask “does it exist” and “is it unique”. If there does not exist a “largest possible” controllable sub-automaton of S0 that also refines P, then there is no use looking for any. Furthermore, if there does not exist a unique such sub-automaton then we could be in problem asserting when we have found one of them. Fortunately, there does exist a unique largest controllable sub-automaton of S0. This is called the supremal controllable sub-automaton. Of course, when S0 refines P then this sub-automaton also refines P.

The proof of the existence of the supremal controllable sub-automaton of S0 is intricate, involving the exploration of mathematical structures that add no additional insight, see Fabian (1995). For this reason, we prove something less complicated though not necessarily equivalent. If P and S0 were the minimal automata representations of the languages  and , respectively, then the following proof would be equivalent to proving the existence of the supremal controllable sub-automaton. However, we are not guaranteed this.

Lemma 2. Given a plant P and a specification language L, there exists a unique supremal controllable sub-language of L

Proof. We show this by showing that the union of an arbitrary number of controllable sub-languages of L is also controllable.

Let  be the set of controllable (with respect to P) sub-languages of K. First we note that  is non-empty, since it will always contain the empty language. Next, we show that  is closed under arbitrary union.

Assume that  for a in some index set. Then, for the union over all indices . Furthermore, the following expressions are all equivalent[4]

                                                                                            q

The union over all sub-languages of L exists and is controllable. Since it si the union over all sub-languages it is also the unique largest one, the supremal controllable sub-language of L. Note that this language is not necessarily equal to L itself. The language L belongs to  only if it is controllable. Then, and only then, is L the supremal controllable sub-language of itself.

What about the distinction between supervisor and controller, does that affect the controllability property?

The answer is no.

Balemi (1992) showed that the commands could be equated with the controllable events, and the responses with the uncontrollable events. For a control engineer this seems an intuitive interpretation of the controllable and uncontrollable events. We are free to determine when to enforce some control action, the command, but we cannot control its outcome, the response. Therefore, the controller will be controllable if it can accept any response that it allows the plant to generate. This is exactly the controllability condition as defined above.

Uncontrollable States

Given a specification and a plant we know now that we have to look for the largest sub-automaton of the specification that is controllable. The obvious question is then how to find this.

As discussed in Chapter 3, we can always assume that the total specification S0 refines the plant. This means that there exists a mapping between the specification states and the plant states based on the mutual traces of the specification and the plant. If the specification is uncontrollable, then some of its states that are such that their corresponding plant-states define transitions labeled by uncontrollable events that label no transitions in the respective specification states. That is, Definition 1 is violated.

Such a state will be said to be uncontrollable.

The search for the largest controllable sub-automaton of the specification must always begin with identifying the uncontrollable states. Once those states have been identified, the states reaching those via uncontrollable events can be searched out. This forms the basis for the algorithms that calculate a controller given a specification and a plant. Thus, the initial problem for those algorithms will always be to find the uncontrollable states.

We can observe that if we synchronized S0 with P, then the uncontrollable states would give themselves away by making uncontrollable transitions disappear. This is obvious, since uncontrollable states were defined above as those states of the specification for which the plant defined uncontrollable transitions that had no “counterpart” in the specification.  And this is exactly the way we will find the uncontrollable states; synchronize P and S0. Synchronizing P and S0, and forbidding the uncontrollable states will generate a sub-automaton of S0[5].

However, in Chapter 3 we started with a given specification Sp from which we did not require much other than that its alphabet was a subset of the plant alphabet. To generate the total specification we then synchronized this Sp with P.  This gave us S0 that refines P. If we now synchronize S0 with P the result will be S0 by definition. Synchronizing S0 with P and forbidding uncontrollable states, would thus be the same as synchronizing Sp and P and forbidding uncontrollable states. This saves us one synchronization with P, which is good; synchronization is a time consuming operation.

So, when synchronizing P and Sp we can determine the uncontrollable states and mark them forbidden. Note that in the case that the alphabet of Sp does not contain any of the uncontrollable events, then no uncontrollable states will exist.

Non-blocking

Finally, we have one more desirable property of the controller. We require it to be non-blocking. The controller is non-blocking if the closed-loop system is such that it can always reach some marked state, that is, if it is trim. In the case that the specification defines no marked states, this is trivial. However, marking is often an essential part of specification, certain states may be of special significance and these have to be indicated in some way. Marking is the way we do that.

Though in general, the synchronous composition of two automata is not necessarily trim just because the automata themselves are trim, in the special case of controller and plant, the closed-loop system will be trim if the controller is. Obviously, this follows from the fact that the controller always refines the plant.

Uncontrollable States

When the plant P and the specification Sp above are synchronized the uncontrollable states can be forbidden. The uncontrollable events are the ci events. As we can see, after the a1 event the plant can always execute c1. However, in the synchronous composition there are two states reached by transitions labeled by a1, but from where no c1 are possible. These uncontrollable states are forbidden in S0. The problem is that Sp constrains the c1 event in its p1 state, so that the combinations q1p1 and q2p1 are uncontrollable.



[1] Note that the word controller will in this section be used with two different interpretations. For one, it will be used to name a specific type of controlling unit, as in this definition. In addition, the word will be used in the generic sense that it has been used in the previous sections, to describe a controller in general, whether a supervisor or something else. The meaning will (hopefully) be clear from the context.

[2] This could be allowed under some circumstances, such as for non-deterministic systems, see Shayman (1994). However, for deterministic controllers and plants that are assumed to have the same alphabet, those circumstances are very intricate. Thus, in practice this requirement can (and will, in this work) always be made.

[3] For deterministic state-machines, that is. For non-deterministic state-machines, language controllability does not imply a controllable state-machine, see Fabian (1995).

[4] If these expressions seem incomprehensible, try to work through them for only two sub-languages of L. This would not be a proof, though, since L is in general an infinite set with infinitely many sub-languages.

[5] Since S0 refines P, their synchronous composition is equal to S0, and a sub-automaton is allowed to forbid more than its super-automaton, see Chapter 3.