Basics

A specification is an automaton  that expresses the intended behavior of a given plant P. The plant is typically assumed unmarked and with no forbidden states. The specification marks a number of desired states, , and forbids a number of states . The benefit of the marked states is obvious, since the plant is always assumed non-marked, but what is the reason behind the forbidden states? Why would we want to introduce a number of states into the specification just to forbid them? Can they just not be removed to make ?

The inclusion of  actually servers several useful purposes. It allows us to make the specification uniquely well-defined in the case that the specification is static. For traces of P that reach the same state in P,  allows us to forbid some of those while allowing the others. Also,  has its usefulness during the synthesis stage, when we calculate the actual controller.

Specification

To the right is a plant P and to the left two specifications for its intended behavior. The specification  forbids one trace of the plant ab and marks another trace ba. Note that both of those traces reach the same state in P. The other specification merely marks the single event traces a and b.

Given a specification  we cannot assume much about its structure, other than it being an automaton. The specification is intimately tied to the process model, and we cannot know, for instance, if the specifier had the same model in mind as we have. The only assumption that we can reasonable make is that . This is a consequence of the fact that we cannot specify more than what the plant can achieve, we cannot require the execution of events not in the plant[1]. Note particularly that we do not assume that . This may seem surprising, since at first glance this would seem to allow the specification to require more than what is possible in the plant. However, the reason for not requiring language inclusion is that we must allow the specification to express less than the plant. Events not present in the specification alphabet cannot occur in any trace of the specification. However, such traces may be partial traces of the plant, and must therefore be allowed.

Partial and Total Specifications

The only assumption we will make about a given specification is that its alphabet is a subset of the plant alphabet. However, to give us more knowledge and control over the structure of a specification we will manipulate it with respect to the plant. It is important, though, that the manipulations we make retain the intention of the original specification. Conversely, when formulating the original specification it is sometimes necessary keep in mind the manipulations we allow ourselves to make.

A specification for which the alphabet is a strict subset of the plant alphabet is said to be a partial specification. Otherwise, when the specification alphabet is equal to the plant alphabet, the specification is said to be total.

A partial specification does not specify the entire desired and allowed behavior, since not all events are under the “jurisdiction” of the specification. Consequently, the traces of the specification are not necessarily present in the plant language, they are merely partial traces of the plant language. Those traces can be viewed as having “holes” in them where adding a plant event not present in the specification alphabet would make the trace a plant trace. Thus, the plant behavior is allowed to “shine through” where such events occur in the traces. A partial specification essentially says, “the events in my alphabet I care about, those not in my alphabet the plant may do with as it wants”. Thus, in the closed-loop system, traces may occur which are not in the specification.

A total specification, on the other hand, leaves no such freedom to the plant. It specifies the entire desired and allowed behavior. In the closed-loop system, traces not in the specification may not occur. Thus, for a total specification, the language of the closed-loop system is a subset of the intersection between the languages of the specification and the plant, that is, .

To synthesize a controller form a specification it must (generally) be total. A partial specification includes design choices that we cannot make during the synthesis procedure. Thus, given a partial specification we must somehow make it total. The trick for doing this to synchronize the (partial) specification with the plant. This will “fill in the holes” of the partial specification so that the behavior of the plant is allowed to “shine through” where the specification does not fully describe the allowed and desired closed-loop behavior. So, given a partial specification Sp and a plant P we generate a total specification . This has the added consequence of making the language of the specification  a subset of the plant language. Though this is not something that we require of the given specification Sp, nor something that is guaranteed by it, it is a natural property. Again, it is natural since we can never achieve anything that lies outside the physical boundaries of the process, that is, outside the plant. All traces of the closed-loop system must also be traces of the uncontrolled system.

If the specification Sp is total, then synchronizing it with the plant is strictly not necessary. However, such a composition  makes the language of the specification  a sublanguage of the plant, just as above. In fact, in this case, the language can be exactly determined as . Since Sp is total, no new behavior will arise in , traces outside the plant will merely be removed. This is harmless, since these traces would in any case add nothing to the closed-loop system behavior.

Partial and Total Specifications

The specifications  and  in the previous example are total (with respect to the given P), since their alphabets contain the entire plant alphabet. This can also be seen in that their respective synchronous composition with the plant does not contain traces not in the specification. The specification  above is, however, partial since the b event is not in its alphabet. Thus, in the composition  traces not in Sp3 arise. Note that if Sp3 had had b in its alphabet, then it would have been total, of course. Then also, their synchronous composition would have been equal to Sp3.

Thus, whether a given specification Sp is partial or not, we will always synchronize it with the plant, to generate the specification . This specification will always have a language that is a subset of the plant language. In fact, we can even say more about the structure of . It refines the plant.

Static and Dynamic Specifications

A specification such that it can be expressed as sets of marked and forbidden plant-states is said to be static. A static specification can only express desired and/or forbidden states of the plant. This means that if the static specification marks (or forbids) a certain state of the plant, then all traces reaching that state are marked (or forbidden). Thus, a static specification has a limited degree of freedom in what it can express. Note that we define a static specification as one that can be expressed as sets of marked and forbidden plant-states. This does not necessarily mean that all static specifications will always be given in this way. For instance, a specification that is not total may still be a static specification, though in disguise. The resulting total specification is often easily identified as being static, though.

A static specification is important for two reasons. One is that it is not necessarily given as an automaton at all, but merely as two sets of marked and forbidden plant states, respectively. In that case, the transformation to a total specification in automata form is trivial. Typically, the informal specification expresses sets of marked and forbidden states of the plant. Naturally, this also depends on the plant itself. A given specification can be static for one model but dynamic for another, even for different models of the same process.

The second point of importance is that a static specification will give rise to a static controller (assuming full observation of the plant state-space). A static controller is one that bases its control-decision entirely on the observation on the current plant-state. Such a controller needs no memory of its own, the plant holds all information necessary for the control task. This is of course a benefit when it comes to implementing the controller.

For a total static specification, , its non-marked and non-forbidden counterpart  is equal to the plant. Note that a static specification is one that can be expressed as sets of marked and forbidden plant-states. It is not necessarily given in that way. On the contrary, we will assume that a static specification is given as an automaton equal to the plant, though with marked and forbidden states added. This guarantees that the specification refines the plant. A property that we need to prove the correctness of the synthesis procedure presented in Chapter 4.

That every static specification is a sub-automaton of the plant is obvious. However, that not every specification expressing a sub-automaton of the plant is a static specification, is not as obvious. Assume that we are given a specification that is a sub-automaton of the plant. Intuitively, we would be able to forbid all states in the plant not in the sub-automaton. However, our intuition deceives us. Assume that there are two traces in the plant reaching the same state and that the specification defines only one of these but not the other. Then we cannot forbid the reached state since that would forbid both traces, nor can we mark the reached trace since this would mark both traces. Thus, due to the structure of the plant a sub-automaton may or may not be a static specification. Note that a static specification marking (or forbidding) a certain state in the plant, marks (or forbids) all traces reaching that state.

Every static specification will result in a static controller. However, there is no equivalence here. A controller may be static although the specification that “produced” it was dynamic. This can be understood as the “non-dynamic” parts of the specification are removed by the synthesis procedure. This is under the assumption that the controller can observe (enough of) the plant states. If we have no observation of the states then the controller must be dynamic whatever specification it is to fulfill.

To conclude, the given specification whether partial or total, whether static or dynamic, can always be synchronized with the plant to produce a new specification that we will call S0. Because of the synchronization, the (final) specification S0 will always be both total and refine the plant. This S0 is also our initial candidate for a controller. Since S0 refines the plant, if it could be used as a controller (which it sometimes can) we would have that . This surely meets the criterion of “satisfying the specification” (and by any definition of equality).

Static and Dynamic Specifications

All the specifications above for P are dynamic specifications. None of them can be expressed as forbidden and/or marked states in P. Note that even Sp3 in its simplicity is a dynamic specification. Marking p2 marks all traces reaching p2, a as well as aba, baa, and many others. There is no way we can mark and forbid states in P to express Sp3. This is also revealed by the synchronous composition .

Regard above the two plants P1 and P2 that may be two models of the same process. It may be claimed that P2 is more detailed than P1. Obviously, there exists some way to distinguish states reached by the traces a and abc, respectively. For some reason, this is not modeled by P1. This may be by choice or by accident.

The specification Sp has its initial state marked. Sp is a dynamic specification in relation to P1 but static with respect to P2. Consider, for instance, a controller trying to control P1  to achieve Sp. After the trace a the controller must make the system execute b, while after abc the controller must assure that d is executed. However, both those traces reach the same state in P1. Therefore, the controller must base its control decision on something more than the current plant state. Thus, the controller must have a memory of its own. A controller controlling P2, on the other hand, need not decide much at all. Specifically, it need not base its control decision on anything but the current plant state.

Note that in both cases, synchronizing the plant and the specification results in the specification, .



[1] Strictly speaking, even this is not necessarily true. For instance, when we have several distributed cooperating controllers, the cooperation may also be specified, and then as the execution of events not in the plant. This lies outside the contents of this course, though