In the following, we will give specifications for the examples of Chapter 2, the tank process and the two users. For the tank process, a single specification will be given, but for the two users, we have three sub-specifications forming a full specification. As was the case in the modeling chapter, the specifications given here will be very small (and comprehensible) compared to what would arise in an industrial application. It is not only the case that the specification in those cases is very extensive but is mostly not fully existent or, if it is, well hidden within the design documents. For most industrial design processes, the exact specification for the desired behavior cannot be stated. Usually a specification can be given in broad terms but on a detailed enough level it is simply not known what the best behavior is. This level of detail is not necessarily very deep, at that. As we saw in Chapter 3 there were a number of design assumptions we had to make, even for such a small system. Real industrial applications are orders of magnitude larger with a corresponding number of design decisions and assumptions to be made. Though this may seem discouraging, applying formal methods with suitable computer support will eventually lead to a better understanding of how to incorporate them early in the design process. One immediate benefit from using formal methods in these areas is that some decisions must be made explicit early, rather than postponed until they have been determined implicitly by other decisions and assumptions. These decisions may be important.
Figure 1. The plant representing the tank process from Chapter 2.
Should the tank be filled, heated and drained continuously? This is an obvious assumption and probably the intention. A system that fills heats and drains just once is of limited use. However, note that the informal specification above does not explicitly say this. If someone were given this specification and returned a controller that simply went through the sequence once, the specification would be fulfilled.
Should we heat while filling the tank? There is no requirement for the controller to be as efficient as possible, so it could fill the tank, close the input-valve and only then turn on the heater. Again, though, it seems reasonable to assume that the job should be done in a less time-consuming way. We assume that we can heat as soon as the level has reached the low-level sensor, that is, after the first in has occurred.
Should we heat while draining the tank? There seems to be no reason to do this. Once we have started draining the tank the heating process would seem to be finished. There is no clear-cut surety here, though, there may be arguments for as well as against heating while draining. Here, we assume we should not heat while draining.
Should the controller aim to keep the right temperature? This question is related to the previous one. The controller should obviously turn off the heater once the right temperature has been reached. But, since we know nothing of the continuous dynamics of the process, we cannot say whether the temperature will drop below the desired set-point while the tank is still being filled. If it does, should the heater turn on again, or not? Again, we simply make a choice, this time a choice that simplifies things for us. We do not aim to keep the temperature at the set-point. As soon as the temperature is reached, we turn the heater off and that is it. This also avoids any “chattering “ effects where we may turn the heater on and off an arbitrary number of times during filling.
What does “the right temperature have been reached” actually mean? The sensor is of a simple on-off type. When the temperature is below the set-point the signal is low, and when it is above the set-point the signal is high. The rising flank between the low and high values of the signal we call the t1 event. Conversely, the falling edge we call the t0 event. If we turn the heater off when t1 occurs, the dynamics of the heater and tank will surely make the temperature rise above the set-point. However, since we have no other means of determining when to shut off the heater, this is the best we can do.
There may even be other considerations that we have missed here. In any case, the informal specification together with the assumptions we have made can be formulated by the Petri net in Figure 2.
Figure 2. Specification for the tank process.
The Petri net in Figure 2 defines formally the requirements for the plant in Figure 1. The specification initially requires the opening of the input-valve and after the low-level sensor has signaled that the level is above the heating limit (according to our assumption) the heater is turned on. The two parallel paths represent the heating and the filling, respectively. Filling continues until another in event occurs and then the input-valve is shut. Heating continues until the temperature is above the set-point, event t1, and then the heating is shut off. The two branches wait for each other, and when both the heating is off and the input is closed, the draining starts. The output-valve is opened and kept open until the tank is empty. Then the output is closed and the initial state is re-occupied. Now the sequence can begin anew. Since this is a Petri net, it has to be augmented with desired and forbidden states. In this case, the initial state is the only desired state and no states are forbidden.
One thing to note about Sp
of Figure 2 is that it does not mention t0. Since we assumed that we were
not going to keep the temperature around the set-point, there is no need to
specify anything about this event. The plant can execute t1 as it pleases (and is allowed
to) under control. This also makes Sp
partial, but as mentioned above, synchronizing it with the plant will remedy
this. The synchronous composition with the plant, that is, , is very messy
and is not shown here, even in Petri net form. However, the automata representation
of
is
given, with the desired state marked, see Figure 3.
In of Figure 3 we can see
how t0 is allowed to occur after E0 has occurred, in the states
q20 to q30, although it is not in Sp. We can also note that from the states
q14, q17 and q19
the marked initial state q0
cannot be reached. These states are blocking. Obviously, the closed-loop system
cannot be allowed to reach those. Those states represent that the tank has been
filled, heated and drained, then filled again and the heater turned on without
a t0 occurring after
the last draining. This may seem impossible, but is actually a consequence of
our plant and specification. The sequence E1t1E0E1
is possible in the plant and allowed by the specification (as a partial trace).
However, after this sequence the specification requires t1 that cannot occur after E1 unless t0 has previously occurred. Physically,
this may never happen, but our model allows it.
Figure
3. Automata
representation of the specification
for the tank process.
Note that the specification may be augmented with additional
marked and forbidden states. In fact, any manipulation of the specification
is valid, as long as the result still refines the plant. Even transitions may
be removed, since this creates a sub-automaton of
, which
refines P if
does.
Figure 4. The plant describing two users sharing a mutual resource.
For this example, we can pose three sub-specifications. In Chapter 4, we will generate three controllers, each guaranteeing the respective as well as the preceding specifications.
1. The two users should not use the resource simultaneously and each user should always be able to repeat its request-use-release cycle.
2. The user that first requests the resource should also be first granted access to it.
3. The b1 event should always occur before b2.
The first sub-specification merely formulates the fact that the resource should be exclusively used. Typically, two computers are not allowed to send print-jobs to the same printer simultaneously, or two students cannot converse with the teacher at the same time. In addition, the specification requires the repetitive execution of the requesting, using and releasing actions. The second specification guarantees fairness, or what is also called first-come-first-served. In the case of two students, it can be regarded as very unfair if the teacher lets the second one to raise his hand get the word. This also guarantees that no user will be starved. If the fairness specification is not adhered to, a requesting user may be ceaselessly overrun by newly requesting users, thus never getting the chance to use the resource. In the case that User1 produces something that User2 consumes and their communication of that something is through the mutual resource, the third specification guarantees that there will always be something for User2 to consume when it gets its turn. Typically, this occurs in computer systems when two programs communicate through shared memory.
In relation to the given plant, Figure 4, the first specification is static.
It merely says that the UU state must be avoided and the II state is marked. Thus, can
in its simplest form be expressed by
and
. However, as
discussed above, this specification can also be expressed as an automaton
, which
is shown in Figure 5. Obviously,
and
this is always the case for static specifications.
Figure
5. The
static specification .
Specification 2 essentially defines a set of forbidden traces, the traces such that one user requests access before the other but the other gets the access. Those traces look like a1a2b2 and a2a1b1. These traces can be expressed as an automaton with forbidden states. However, things are not as straightforward as they may seem at first. We must keep in mind that the specification expresses not only forbidden behavior but also allowed behavior. An event present in the specification alphabet will be “forbidden” (or rather, prohibited) to occur anywhere but where explicitly allowed by the specification.
Regard the specification of Figure 6, which is a
first try at specifying the forbidden traces for the two-user problem. This
is a dynamic partial specification. The cI
events are not present in its alphabet, and it is not a sub-automaton of the
plant. There is no need to specify or control these. Regarding
in relation to the plant
reveals a problem. Since
includes the bI events the specification does
not allow these to occur anywhere but after a sequence of a1a2and a2a2, respectively. And then they
only lead to forbidden states! This problem can be illustrated by the synchronous
composition
, shown in Figure 7.
Figure 6. A first try at specifying forbidden traces for the two-user application.
Figure 7. Synchronous composition of the plant and the first attempt specification of Figure 6.
A controller that guaranteed that the total specification of Figure 7 was never broken would not be able to allow much. Even assuming the initial state was marked. In fact, using the specification of Figure 7 to synthesize controller would result in the degenerate null automaton. Though this automaton formally fulfills all requirements, it is not useful for anything.
The problem is that specifies a much more restrictive
behavior than the sub-specification 2, above.
specifies when
the bI events should
not occur, but not when they are allowed
to happen. In the plant, after each aI
a corresponding bI
event can occur, but not in the specification. This is the core of the problem.
A useful specification must allow those bI
events to occur where they can in the plant, and it is safe to let them. Thus,
an automaton expressing the second sub-specification above must look something
like
in Figure 8, below. Again,
the cI events are not part of the
specification alphabet.
The main difference is that specifies (or allows) the
bI events to occur
everywhere they can occur in the plant and they do not break the specification.
For instance, if an a1
occurs initially, then, of course, a b1
is valid (see state 1). Likewise, after the a1a2 sequence (state 2) a b1 is valid, but not a b2. Note that the states 3 and
6 are formally not necessary. Simply removing these will result in the same
(semantically) specification. However, we feel that their inclusion results
in a more intuitive specification. What we really want to do is to express that
certain traces are forbidden. Removing the forbidden states from
would
state this rather implicitly.
The total specification resulting from the two first sub-specifications is shown in Figure 9. All states with either UU, 3 or 6 are forbidden.
Figure 8. A correct formalization of the second sub-specification.
Figure 9. The synchronous composition of the two first sub-specifications with the plant.
The third sub-specification aims to specify that User1 should always “produce”
something that User2
“consumes”. However, the informal wording is not entirely clear about this intention.
For instance, the (partial) trace b1b1b2 fulfills the given specification, as does b1b2b2.
Even would satisfy the specification
as it stands. There is no (explicit) saying that the b1 and b2 events should alternate, beginning
with b1, but this is
the interpretation we make. Thus, the third sub-specification can be described
by the automaton
of Figure 10. This automaton
explicitly forbids all traces where the bI events do not alternate, beginning
with b1. This includes
all traces where a b1
does not occur directly before a b2.
Again, the forbidden F state is
really not necessary, and in this case it may be questionable whether its inclusion
makes the specification more intuitive. It may seem more natural to specify
what we really want, that is, the alternation of b1 and b2, beginning with b1.
Figure 10. Automata representation of the third sub-specification.
The complete specification obtained by synchronizing the three sub-specifications
with the plant is shown in Figure 11. All states with UU, 3,
6 or F in them are forbidden, and the states with II are marked. This is a first candidate
for a controller and a controller will be synthesized from this in Chapter 4.
We can note that if User2
starts requesting the resource, then we are stuck. We will move to the right
from the initial-state II0A with
no way of ever getting back to reach a marked state. Since we cannot hinder
any user from requesting (the aI
events are uncontrollable) the
resource, this is a discomforting observation. The reason this problem occurs
is that the two dynamic specifications actually contradict each other. says
that whoever requests first, should also get access first, while
requires
that User1 get access
first. Obviously, if User2
requests the resource first there is no way we can satisfy both specifications
simultaneously. This is what manifests itself here.
Figure 11. The final total specification for the two-user problem.