When modeling a complex process it was beneficial to build the model out of models of less complex components identified in the physical process. In the same way, it is beneficial to be able to express a specification as a composition of simpler sub-specifications. Often the specification is given as a set of sub-specifications each meant to capture a certain aspect of the allowed and desired behavior of the overall system. Being able to exploit this modular structure of a specification can considerably simplify the specification task. Instead of formulating a single large specification, we can focus on smaller and less complex patterns, more easily grasped by our intellect. Composing those simpler specifications into the single large specification[1] that we need for controller synthesis is then a mechanical chore that a computer can perform for us. In the best case, we need not even see the single large specification.
The drawback of giving a set of sub-specifications is that they easily contradict each other. Without a global overview of the entire specification, it is not straightforward to determine if this is the case. However, when the sub-specifications contradict each other, then the resulting controller cannot fulfil them all at the same time and the result will be empty. This is a hint that there is something wrong with the specification, there may be contradictions, for instance, but a hint that comes much too late. We would want to be able to determine errors in our specifications long before that. The synthesis procedure may take a long time for large systems, time that is wasted if the specification is improper.
This is where verification can help. By verifying properties of the specification, we could determine whether it is proper or not. For instance, given a set of sub-specifications we could verify whether their composition includes deadlocks, see for instance Godefroid (1992). However, verification may also be costly, and verifying the specification does not tell us much about the properties of the specification in relation to the plant.
In any case, a modular specification is advantageous. However, when a specification is given as a set of sub-specifications, how do we compose a single specification? The intent of a single specification is that the closed-loop system should behave as specified; it should stay within the specification. In the same way, when the specification is modular, the intent is that the closed-loop system should stay within all the specifications. No specification is allowed to be broken at any time. This means that the natural way to compose the sub-specifications is to synchronize them. Remember, that every specification can be expressed as an automaton (or Petri net) whether static or dynamic, whether partial or total. Thus, their synchronous composition is well-defined. Essentially, synchronizing the specifications expresses their intersection as the single specification. Obviously, a controller that stays within this specification will not break any of the sub-specifications[2].
Thus, given a set of sub-specifications with
the
single (or full) specification
is
. Note that synchronizing
this specification with the plant results in each sub-specification being
individually synchronized with the plant. Thus, the composition becomes
so
that all the properties and aspects that we have mentioned above hold, not
only for the full specification, but also for each sub-specification separately.
Thus, the
above can be generated
by first generating a corresponding
for each sub-spec,
and then synchronizing these. This is good, since the
generation
will reveal certain inconsistencies in the specifications. If, for instance,
one of the
is the null automaton,
then this sub-specification must be let out or at least reconsidered.
[1] In some cases, a single specification need not even be built. A number of controllers can be synthesized, one for each sub-specification, and the composition of these controllers is then equivalent to what would have been synthesized for the large single specification. See Wonham (1988), for instance. Such, modular controllers are not covered in this course, though.
[2] Other, more permissive compositions may be meaningful, such as the mutually non-blocking specifications of Fabian (1996).