Perhaps one of the most outstanding differences among the above
plant models of the Two-Pusher Example is the modeling of the
workpiece. In both the R&W framework and the TTM framework, there is
no explicit information about the workpiece. That is, in order to
keep track of the workpiece, one must keep track of the movements of
the pushers. These state-machine models implicitly assume that, at
the initial state, a workpiece is available in position 1, and that no
new workpiece ``enters'' the system until the previous one has left.
The reason for this is that, in the R&W formalism, the plant model
includes only those subsystems ``to be controlled;'' that is, those
entities capable of sending and/or receiving control signals. For our
purposes, the workpiece in this example is not much different than a
wooden block. Although this modeling feature might initially simplify
the description of the plant behavior, it might also make it difficult
to keep track of some of the resources later on, if information about
them was ever desired.
In contrast, both the Petri Net and NCES models keep track of the
workpiece in an explicit manner (one need only check markings of some
specific places). In the case of Petri Nets, however, the model complexity
increases because information about pushers' movement is ``doubled''
in order to account for interaction with the workpiece. NCES's are
capable of keeping track of the workpiece in a more compact form. This
is because their event arcs model precisely ``causal'' behavior: when
a pusher moves and a workpiece is present, this movement causes
the workpiece to move.
Except for our Petri Net model, all other methodologies followed a
modular framework to construct P. Modularity is a desirable
characteristic because it aids in the description of behavior for
large systems. The interaction among their modules, however, is
described differently in each case. What R&W call the plant model,
the recognizer of the shuffle language, does not include any
interaction among the subsystems (which are assumed to be
independent). Any such interaction must be described through
the specification model. Toward this end, some might argue that a more
accurate plant model should include the interaction among subsystems.
This is possible if we care to separate the R&W specifications into
two classes: one of ``functional requirements'' describing the
physical functions of the system, and another of ``behavioral
requirements'' which describe those desired outputs of the system. In
this case, the more ``accurate'' plant model would consist of the
intersection of the shuffled language with the functional
requirements. (So, in the above example, the recognizer of the
``legal states'' might be called the more appropriate plant model.)
In the TTM case, the interaction among modules is described implicitly
through the parallel composition of the transition sets. On the other
hand, condition and event arcs allow for an explicit description of
module interaction in the NCES modeling framework.
The means of control for the plant model is essentially the same for
all the afore mentioned methods, except for a slight difference in the
TTM framework. The main idea is that of the separation of events into
controllable and uncontrollable ones. For the controllable events, R&W
define the control map 
which describes the enabling and
disabling of the given event. This map is equivalent to the control
inputs, 
's, used in NCES's. With Petri Nets, it is typically
the case that controllable transitions are ``allowed'' to receive
input from control places, whereas uncontrollable transitions
are not. In the TTM model, the enabling function of a transition
and/or its time bounds are used as the means of control. Whenever
possible, hardware interlocks may be used to change enabling
conditions, and time bounds are given the appropriate values.