Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site uiucme
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!inuxc!pur-ee!uiucdcs!uiucme!keith
From: keith@uiucme.UUCP
Newsgroups: net.cog-eng
Subject: Knowledge and Design
Message-ID: <11800006@uiucme>
Date: Tue, 11-Mar-86 10:29:00 EST
Article-I.D.: uiucme.11800006
Posted: Tue Mar 11 10:29:00 1986
Date-Received: Fri, 14-Mar-86 05:58:45 EST
Lines: 68
Nf-ID: #N:uiucme:11800006:000:3239
Nf-From: uiucme.UUCP!keith    Mar 11 09:29:00 1986




Even more Basic:  Topology and Physics
Sixth of a series.

(The concept presented here, the distinction between topology and
physics, was suggested by Allen Newell, Carnegie-Mellon University.)

In developing a system which interacts functional units to achieve
system performance, our principal emophasis is on topology - the
"shape" (in logical space or functional space) of the system.  This
really boils down to diagramming the individual primitives and their
relationships with other primitives.

This is the basis of most programming efforts.  If one can conceive of
a primitive, which is essentially a transfer function taking input
and generating output, one can develop an algorithm capable of carrying
out the embedded function.  There is little need to consider whether
the function can be served.

We can say, broadly, that design in computer science has focused on topology,
with little attention to the physics that might affect the design.  This is
because very little physics had much effect on the outcome of a software
design.

In addition to designing components to achieve a particular functional
goal, it is also necessary for a mechanical engineer to design
components with respect to physics:  whether they are capable of carrying
out that function without failure.  In fact, attention to the physics
has dominated mechanical design.

We can say that design in mechanical engineering has focused on physics, with
little attention to the topology that might affect the system.  This is because
very little attention to functional interactions was necessary to achieve the
desired result.

This was no problem when the machines we designed were simple devices with
single, simple functions to be served.  This has become more complicated,
on both fronts:  most new designs rely on complex mechanisms and complicated
interactions to accomplish their function, and most machines are designed
for multiple functions as a means of economizing.  Consider, for example,
that "wings-backward" aircraft that is unstable and requires a computer's
intervention a few hundred times per second to avoid a crash.  Consider, for
example the multi-functioned, robot-served, numerical-control milling machine
that is, in theory, capable of any metal cutting operation you can think of.

The point I am walking around is that neither approach to design is complete.
We must account for both topology and physics as we design complex systems
that are neither software nor machines, but a combination of both.  Mechanical
designers have a lot to learn about functional units (primitives) and their
interactions from software designers.

This is a corollary to my earlier assertion:  design is a reasoning method
that can be (at least partially) separated from the knowledge being applied.

(Doesn't this sound a lot like the old inference engine argument for expert
systems?  If one of you clever fellows wants to write an inference engine
customized for design applications, I've got a knowledge base under
development.  We can make each other famous - but the knowledge base may
take a few decades to develop.)


next instalment:  digging a hole in the knowledge base

keith
U of Illinois Mech Eng
seismo!ihnp4!uiucdcs!uiucme!keith