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.
To
the right is a plant P
and to the left two specifications for its intended behavior. The specification
|
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.
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 |
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.
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