Redux has given rise to a subtheory, Redux' (redux prime), of
coordinating among design agents. The import of there being a
general theory is that
1) not only has it been shown to be a sufficient design theory, but
2)there is evidence that it can be "retrofitted" to many
design systems.
This means that it has the potential to be adapted to
coordinate heterogeneous systems. Lines of code in the native
system can be identified as corresponding to decisions
in the Redux theory.
"Daemons" can then fire a message to the Redux' agent whenever
these lines of code execute. The message identifies the
decision to Redux'. Whenever the native code will be changed
by decisions of other agents, Redux' sends a change notification
message.
This is being tested in the NEXT-LINK project. In this project, the agents are homogeneous and are already passing messages to one another. We have only to also exchange messages with a Redux' agent and concentrate on using Redux to improve the coordination of the agents.
Of what would such coordination consist? Let us consider a
problem from another domain. Suppose several engineers are
designing a planar manipulator for a robot.
The first engineer, RDX-1, chooses motor-1 over motor-2
because of cost. In Redux, this is decision is represented
as follows:
In this example, the decision reduces one goal into another
goal and an assignment. The new subgoal, to design the
motor decoder, may be taken up by another engineer, RDX-2.
It may be that the motor choice is also necessary for a
third engineer, RDX-3, to decide how big a mounting hole
to drill. Now, if the motor choice is rejected for any
reason, including RDX-1 changing his/her mind, then RDX-3
needs to be notified.
Redux' tracks the effects of such a change and knows to
notify RDX-2 and RDX-1. Redux' does so by keeping track
of the properties of various properties and their owners.
Although, there are various useful notifiactions Redux' can
send, one in particular has to do with backtracking. Let
us suppose that RDX-1 had to reject motor-1
and go with motor-2 because motor-1 conflicted
with another engineer's (RDX-4) decision to use some
exotic metal with which motor-1 was incompatible.
But suppose further that RDX-4 later changed his mind
and used a less expensive, more compatible metal.
In such a case, Redux' would remember (automatically) that
motor-2 is being used when motor-1 is
the better choice because of the use of the exotic metal,
which is no longer true. Redux' would then notify RDX-1
of the possibility of improving his motor decision. If
RDX-1 thinks this is worthwhile and makes the change,
Redux' would notify the other engineers appropriately.
The interface for such Redux' messages is subject to
implementation. It is certainly the case that the engineer
need not bother with the representations above. Rather,
RDX-1 might see something like:
In this display, Redux' tells the engineer that the decision
to use motor-2 is "suboptimal" because it was
based on the rejection of motor-1, but this rejection
is no longer necessary. Without such a notification,
the engineer might miss an opportunity to improve the
design.
For a paper with a complete discussion of this example
and a complete predicate calculus model of Redux', see
The Redux' Server:
Abstract or
Report .
A strongly related follow-on paper is Design Space Navigation :
Abstract or
Report .
Return to the Next-Link home page. ______________________________________________________
Charles Petrie