keith@uiucme.uiucme (11/24/85)
KNOWLEDGE AND DESIGN. First of a series.
How do we design? Can a computer design for us?
To take CAD past the stage of increasingly pretty pictures to the
point that the computer can actually generate portions of the
design, we can take two avenues:
- Establish a rigid, algorithmic approach that will allow us
to code design procedures in conventional programs.
- Reach an understanding of the human process of design that
will allow us to apply artificial intelligence programming
methods to solve the problem.
In fact, like most engineering solutions to problems, the solution
that will be proposed is a compromise. Both of the methods offer
some advantages, both have major disadvantages as well.
While my own application of design knowledge is to machines and
structures, I have learned a great deal about the approach to design
from the computer science community. Structured analysis is the
only method that I know of that deals with the early, abstract
problems in design (the really interesting problems) in a systematic
manner. I have learned that developing a quick diagram of
the functions and interactions present in the basic problem helps
to pinpoint problem areas requiring concentration, and illuminates
areas that might have been overlooked.
Computer Science has learned what the rest of us are only just
catching on to - complex systems require a disciplined, structured
design approach unless you want to spend your life debugging.
And in fact there are power plants and factories and ships and
airplanes out there - all of them incredibly complex systems -
that are still being debugged after ten, twenty, even thirty years
of service.
My basic premise has usually prompted immediate agreement or
immediate disagreement. It is simply that design is a way of
reasoning about abstract problems, and design methods are essentially
the same regardless of what you are designing. We apply different
domain knowledge, to be sure. In the sense of the engineering
involved a diesel engine has little to do with a Sony Walkman.
But both were created by combining functional units with defined
interactions into a system.
Instalments to come:
Topology and Physics
Loads, Energy, and Information
The Nature of Domain Limits in Knowledge-Based Programs
These posting are based on research on design methods I'm presently
mired in. Your comments and especially your pointers to the literature
will be greatly appreciated and may enable me to finish my dissertation
in less than twenty years.
Keith
U of Ill Mech Eng
{stuff I don't know} uiucdcs!uiucme!keith
p.s.: Of course, if the consensus is that I shouldn't be posting
this boring crap on the net, I'll go back to Murphy's - the metallurgists
don't like me either.henry@utzoo.UUCP (Henry Spencer) (11/28/85)
> Computer Science has learned what the rest of us are only just > catching on to - complex systems require a disciplined, structured > design approach unless you want to spend your life debugging. Computer Science has not yet learned what the rest of us have known for some time: even disciplined, structured design approaches don't solve all the problems. Not even close. > And in fact there are power plants and factories and ships and > airplanes out there - all of them incredibly complex systems - > that are still being debugged after ten, twenty, even thirty years > of service. This is also the case for most major programs, including the ones written by computer scientists using structured design approaches. Even the Holy Writ of computer science's Provisional Wing (the mathematical-correctness- solves-everything advocates), Dijkstra's book, which explicitly claims to teach you how to write bug-free programs, has bugs in its examples. Not many bugs, but a few, and those examples are not large programs. Now that I've offended all my Computer Science friends, I should point out that there is much to be said for disciplined, structured design, and even for mathematical correctness arguments, provided you regard them as useful techniques rather than the Answer To Everything. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
keith@uiucme.UUCP (01/21/86)
The fallacy of specialism and the chaos in design knowledge
Third of a series
The most important lesson I have learned from the structured analysis
and programming crowd is the importance of the interactions between
functional units of a design. In fact, the "data flow diagram" approach
concentrates on those interactions; the functional parts themselves
are almost incidental.
In mechanical design we blithely ignore interactions unless they really
are obvious. Material is selected for a heat exchanger for its creep
and corrosions resistance - and only after they've purchased and bent
millions of Pounds worth of tube into platens do they discover the material
cannot be welded properly to put in small support pieces. A large pressure
vessel is designed from a high-strength material which has terrible fracture
resistance - and fails during testing at half the design pressure.
The cost of correcting an error is a function of the time between the
error and the correction. The "best" errors, the ones that cost a lot
of money and company prestige, are made very early in the design.
They are then discovered during manufacturing, when material order
times and budgets have been used up. These can be incredibly expensive
to correct, costing not only money, jobs and sometimes companies are lost
in the process.
Researchers, in order to "advance knowledge", are becoming more and more
specialized. Greater detail and depth is required to be able to make a
substantial change in what is known. As specialists dig their own holes
deeper into the knowledge base, they lose sight of the other disciplines,
who are digging adjacent holes. They ignore the interactions between
the disciplines. The only problem is that tomorrow's engineers,
today's students, are being taught mostly by researchers at universities.
The interactions between disciplines are critically important in design,
especially in the early stages. Most really expensive design failures
are due to overlooked interactions (this, I think, can be documented
from case studies). Most innovation in design comes from looking at
these interactions in a new way - or noticing one that has traditionally
been ignored (this is not so easy to prove, but to me at least it
makes intuitive sense).
We rely heavily on the interactions between components to insure the
design serves its function. We rely on the interactions between subject
areas in engineering for innovative ideas in design. But we rely on
specialists, who for the most part ignore these interactions, to teach
those who will design tomorrow.
Small wonder almost every engineering firm has a 107-year-old consultant
to advise them on their design problems.
keith
U of Illinois Mech Eng
{ stuff I don't know } uiucdcs!uiucme!keith
Next instalment: A brief pause for philosophy
p.s.: I have been delinquent in posting this instalment because
Software Improvements have kept me off the net.
p.p.s.: Sorry if this repeats an instalment, I have lost track.keith@uiucme.UUCP (02/03/86)
A brief pause for philosophy. Fourth of a Series. In the last discussion I made an impassioned, if ill-documented, case for the importance of interactions in design. It is obvious that specialism will tend to make these interactions even more obscure. My earlier comments on the computer science understanding of the structure underlying design problems is based on the observation that in the formal procedure of structured analysis, attention is paid to the interactions (aka data flows) as well as to the individual functioning parts of the system. This simple thinking has (in my view) the CS version of design parsecs ahead of the mechanical design community. I stated that tomorrow's designers are being taught by specialists, thus missing an opportunity to learn about these interactions during their initial engineering education. This severely handicaps a designer as he begins learning his trade, since for four or more years he has been conditioned to ignore these interactions that will control many of the problems he will be asked to solve. Let us imagine that a suitable number of today's students, taught by specialists, go on to become professors (specialists) themselves. Since we are seeing a strong drop in the practical experience of professors, it is reasonable to assume that none of these specialists will accrue enough experience to begin appreciating the interactions between disciplines before they specialize. In the extreme it is possible to imagine the world's engineers actually losing net capability if specialism continues. Thus research into design methods is very important and has implications for education of new engineers just a grat as the potential effect on the practice of engineering. What is the difference between specialism and generalism that creates this situation? Lack of attention to interactions between disciplines. Specialism in general, and research in particular, is a depth-first, bottom-up way of thinking. Isolate a particular problem of interest, reach an understanding, then attempt to incorporate it into the greater body of knowledge. The problem is that the modern approach to research is "bottom-down". The general body of knowledge has grown complicated enough that incorporating new information takes considerable effort. That is the principal reason that new technologies are difficult to introduce to designers. Since the new concept is relatively isolated, it has no context, no connections to the knowledge the designers already are using. As a result political and management decisions are used to introduce technologies instead of technical decisions. The results can be disastrous ( a well-known British gas turbine manufacturer went bankrupt and reorganized as a result of management decisions to maximize use of plastics). To a certain extent, we have created the chaos in the general knowledge based ourselves, by not thinking about incorporating new discoveries into the general base. The situation will now grown exponentially, unless someone sits down and undertakes some housecleaning. This, basically, is the research I am involved in: demonstrating the idea of the general knowledge base for design. This incorporates two concepts: dealing with information at a more abstract level, to allow more abstract decision-making, and improving the coherence of the knowledge base. These two are hopelessly interrelated, since a great deal of the process of incorporation requires abstraction, and vice versa. Incorporating new knowledge also requires a good look at the interactions between the new information and what is "already known". These interactions between disciplines, according to my notions, are what's really important in design. My assertion is that innovation (which includes new uses of old knowledge and initial uses of new knowledge) requires a clear view of the interactions between disciplines, and requires very little understanding in depth of any individual discipline. next instalment: an abstract view of the issues in engineering keith U of Illinois Mech Eng seismo!ihnp4!uiucdcs!uiucme!keith Partial vindication: there may be a case for continuing research in design. At the ASME Winter Annual Meeting, a panel discussion mused over the problem, "Where will the next design teachers come from?"
berke@ucla-cs.UUCP (02/09/86)
In article <11800004@uiucme> keith@uiucme.UUCP writes: > >In the last discussion I made an impassioned, if ill-documented, >case for the importance of interactions in design. >I stated that tomorrow's designers are being taught by specialists, >thus missing an opportunity to learn about these interactions during >their initial engineering education. This severely handicaps a designer >as he begins learning his trade, since for four or more years he has been >conditioned to ignore these interactions that will control many of the >problems he will be asked to solve. At the risk of seeming to pick on Keith, who I don't know, I'd like to agree with his remarks while making a point of my own: By using the word 'he' to refer to all engineers, or a single generic engineer, however you care to look at it, we are patterning our minds to actually believe engineers are men. > >This, basically, is the research I am involved in: demonstrating the idea >of the general knowledge base for design. This incorporates two concepts: >dealing with information at a more abstract level, to allow more abstract >decision-making, and improving the coherence of the knowledge base. These >two are hopelessly interrelated, since a great deal of the process of >incorporation requires abstraction, and vice versa. > Yes, indeed, our abstractions determine the interactions in our knowledge, and the interactions of our knowledge form (perhaps are) our abstractions. To say that 'he' has two meanings, gender specific and gender-neutral while denying gender-neutral use to 'she' results in a lot of abstract decisions that assume people, especially engineers, are men, not women. At the very least, then, even if we don't conciously believe all engineers are men, when we speak of them as 'he' we are bound to make decisions that assume engineers are men. >Incorporating new knowledge also requires a good look at the interactions >between the new information and what is "already known". Yes, again, unless we examine our presumptions, we cannot learn conciously, we just end up trained in unconcious patterns by accepted societal word usages. So, in a very real sense, when we conciously choose words to communicate, we are conciously designing our world. That means to me, that each and every one of us is creating the world as it is, minute to minute, day by day, whether or not she is an engineer. When it is no longer an insult for a man to be called a woman, it will no longer be oppresive to call a woman a man. How do we get there from here? By designing our world conciously. In this case, I think by using 'she' everywhere instead of 'he'. As said in a popular textbook on Pascal "ten years of 'she' can't undo thousands of years of 'he', but it's a start." As to where new teachers of design come from, I assume from this group. Thank you to Keith for helping me to see this matter more clearly. By the way, this note uses Frege's convention for referring to words rather than their meanings by enclosing each word in single quotes. I use double quotes for direct discourse as in quoting the textbook in the preceeding paragraph. I put punctuation outside single quotes to avoid indicating that the punctuation is part of the word. I put punctuation inside the double quotes just because that is accepted English usage (disclaimer for occasional errors). Cheers, Peter Berke
keith@uiucme.UUCP (03/11/86)
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
keith@uiucme.UUCP (07/03/86)
What Sussman Said - and What He Didn't
eleventh of a series
One of the fine old traditions of the middle ages was the commentary. One
chose a publication of general interest and rewrote it, adding comments where
suitable. Many of the Greek and Latin authors from B.C. are preserved only
in this format - their original writings were destroyed when soldiers cleaned
up the infidel's library's.
I would like to comment on a paper by G.J. Sussman of M.I.T. The
paper was published in the late '70s, introducing the notion of solving
a problem by propogation of constraints (a concept implemented, if
incompletely, in spreadsheet programs). It is available in two, nearly
identical versions:
Sussman, G.J., SLICES, At the Boundary Between Analysis and Synthesis, MIT
AI Lab Memo 433, July 13, 1977.
Sussman, G.J., SLICES, At the Boundary Between Analysis and Synthesis, in
Latombe, J. (Editor), ARTIFICIAL INTELLIGENCE AND PATTERN RECOGNITION IN
COMPUTER-AIDED DESIGN, North-Holland, 1978. (Proceedings af an IFIP working
group conference).
My aim here is to add some supplemental comments to an existing work of great
value. Please don't misconstrue my comments as criticism - not having a
doctoral degree myself I am not permitted to criticise those who do.
We feel that analytic techniques are a necessary component of synthetic
reasoning. Why is this? The processes of synthesis (moving information
down the plan into greater detail) and analysis (moving information up the plan)
seem exactly opposite. This seems to be the root of not a dissociation but
an association. By understanding analysis methods, one can reason in reverse
in order to synthesize.
This does not mean that one can simply reverse the analysis procedure and
follow a procedure for synthesis. (One cannot reverse an algorithm - what
is the meaning of arriving at a decision through the "false" branch?)
Rather, one must invoke a problem-solving skill and exercise some judgement
in determining the steps to be taken. To some extent this is intuitive, and
those who are adept at make correct intuitive decisions are sometimes called
creative.
By better understanding not only analysis (domain knowledge) but also problem-
solving (a skill) we can be better at synthesis.
Analysis methods are not always quantitative. Qualitative reasoning, often
dismissed as "hand-waving", is essential to design. Sussman writes "Believing
in the ultimate power of mathematical manipulation is one of the most common
difficulties encountered by students learning electrical circuit [or any other
kind of] analysis. Students often grind out 'impossible' algebra in the
course of solving a homework problem, even though a little thought will reveal
an algebraically feasible approach which depends upon a small insight into
the operation of the network being analyzed. They then complain that we
give them too much homework!" This small insight is often not expressed
explicitly in lecture or textbook (in fact it may not be expressible). While
I hold strong personal feelings against difficult homework assignments, I
feel compelled to point out that we learn most readily from our mistakes,
and that grinding out the impossible solution may be the most effective method
for encouraging the student to seek and recognize the feasbile method next
time. Problem-solving is a skill, not a knowledge, and skills are developed
and maintained through vigorous exercise.
We observe that a common and vitally important kind of small insight is
knowing the form of the answer. If we can recognize the general shape the
solution will have, then it is possible to add detail to that abstract
solution by filling gaps until the design is complete (Sussman calls this
"problem solving by debugging almost-right plans"). There are methods
which we are beginning to understand for developing a picture of the solution
(more to be said in a later instalment). In simple problems the form of the
answer proposes itself directly from the form of the problem, in more complex
problems it is necessary to manipulate the problem - decomposing or filling
missing details - before the form of the solution will be perceivable.
An example is discussed in detail, a dummy load for an antenna which must
dissipate 500KW through 50 ohms. The notion of "slices" is introduced,
which are parallel (in the sense of reasoning, not in the electric circuit
sense) versions of the same circuit - for example Thevenin and Norton
equivalents. These slices each describe an important attribute of the
system and its functions. At this point the idea of knowing the form of the
answer is not applied as well as it might. In an intuitive leap, the dummy
load becomes an RLC network and the analysis seems to concentrate on obtaining
appropriate component values. The synthesis problem is perceiving the
topology of such a circuit - how the components might relate in order to
achieve such a goal - in other words the form of the solution. The bit
of knowledge needed is Ohm's law - not the calculation but the observation
that two resistors in parallel can team up to achieve a greater amount
or resistance than their sum. Added to that is the knowledge that impedances
act like resistances in this context, and the frequency-impedance relationships
of inductors and capacitors. None of this involves calculation, rather it
involves seeing a chain or relationships that can achieve the goal. To better
understand your own problem-solving, look back over a solution and ask yourself
what basic knowledge was necessary and how the bits connected together.
The key point in the paper, to me, was the notion of knowing the form of the
answer. This was not the main thrust of the paper and no doubt my detailed
interest in one aspect explains my ability to add detail to one segment of
the paper. Armed with the knowledge that the first step is to obtain a form,
rather than a complete description, one can on that basis alone work more
effectively as a designer.
keith
U of Illinois Mech Eng
seismo!ihnp4!uiucdcs!uiucme!keith
next: Naive Physics and competent design (in which it is reveals how limited
my knowledge of a.i. really is)olson@batcomputer.TN.CORNELL.EDU (olson) (07/11/86)
In article <11800010@uiucme> keith@uiucme.UUCP writes: > >My aim here is to add some supplemental comments to an existing work of great >value. Please don't misconstrue my comments as criticism - Okay... > - not having a >doctoral degree myself I am not permitted to criticise those who do. > Huh? why not? uum, that is ... Huh, PERMITED? What does the holding of a degree (or not) have to do with whether or not you can critique (sp?) or criticise someone else's work? (or did you mean to put a :-) after that remark?) Todd Olson -- Todd Olson ARPA: olson@lasspvax -- or -- olson%lasspvax.tn.cornell.edu@cu-arpa UUCP: {ihnp4,allegra,...}!cornell!lasspvax!olson US Mail: Dept Physics, Clark Hall, Cornell University, Ithaca, New York 14853-2501
tedk@bcsaic.UUCP (ted kitzmiller) (07/16/86)
In article <11800010@uiucme> keith@uiucme.UUCP writes: > > >My aim here is to add some supplemental comments to an existing work of great >value. Please don't misconstrue my comments as criticism - not having a >doctoral degree myself I am not permitted to criticise those who do. > > I wasn't aware that the AMA was governing the work in this field.
keith@uiucme.UUCP (10/01/86)
Naive Physics and Competent Design
Twelvth of a series {after a longish hiatus}
P. Hayes has in a number of different papers proposed a reasoning
problem known by the name, "naive physics". The concept is fairly
simple: when we play tennis we don't solve vector sums to get to where
we can hit the ball, how to hit the ball, where it will travel, how
it will bounce. Speaking from personal experience, how do I know I'll
never get there in time to hit the ball, so there's no point in trying?
We have through experience developed some form of understanding of the
physics of the world around us.
I am learning a great deal about physics from my two-year-old daughter
(see also: propogation of roommates). She doesn't know some of the
things I know, and it's sometimes frustrating as she has to discover these
things for herself. Why can't she crawl through the same opening the
cat just did? What is it about doorknobs that makes them hard to turn
when they're locked? I'm learning to appreciate just how much I know
which I'm not concious of knowing.
So how are two-years-olds and proposed a.i. problems related? Well,
the reasoning behind the proposal is that by understanding the reasoning
we use to deal (intuitively?) with everyday physics problems, we can
develop a better understanding of what is called common sense. After
naive physics comes naive economics, naive law, and eventually (next
Christmas) we will have succeeded in building a consolidated model
of how people (in general) solve problems (in general).
An area of naive physics that recieved some examination is the behavior
of fluids. To connect this directly to your personal experience, I
will discuss a particular behavior-of-fluids problem I am presently
researching with the assistance of my daughter. When you pick something
up on a spoon, why does or doesn't it fall off? I suggest you carry
out some experiments, either in thought or with appropriate lab
equipment, as you follow along through the related questions. What
is it about pudding that it only falls off slowly? What is it about
macaroni and cheese that it almost never falls off? What is it about
soup and cereal that part will fall off, but part may stay on the
spoon? Is there any correlation between the orientation of the spoon's
bowl the the tendency to fall off? Is there any correlation between the
speed with which the spoon is moved and the tendency to fall off? Why do
some things stay level (like broth) and some things pile up (like pudding),
and some things pile up a lot (like macaroni and cheese). Is there any
correlation between the ability to pile up on the spoon and the tendency to
fall off?
I leave the answers to these questions as an exercise for the reader. But
there are some interesting points to notice:
- Your answers, in a triumph of the intellect, can run into concepts
like viscosity, surface attractions, gravity, and the tendency to
continue travelling in a straight line (centrifugal "force"). My
daughter {italics} will know the answers without knowing how to
define any of these terms {end of italics} after a few years additional
exposure to the experiments. (Dinner time is learning time).
- These questions are explored in three daily events that total roughly
an hour per day and only a few minutes of actual experience with the
problems per day. How long (in time, and labor-time) by heavily-
educated researchers would it take to reach a level of understanding
held by almost every five-year-old?
- In an application to my own area of interest, what has been developed
can reason about fully-described situations. But design is the act of
conceiving of situations that have not been described, then developing
the description. To what extent can the same knowledge, or even the same
kind of knowledge, be applied to this class of problem?
Darn. Now it looks like I'm criticising the concept of naive physics.
Actually, as areas of research in a.i. go, naive physics is an interesting,
promising area that addresses some core questions in cognition and modeling
cognition on the computer. But it is essential that we recognize the
limits of a model, rather than accepting the model's results at face
value and resenting reality for failing to cooperate.
keith
U of Illinois Mech Eng
seismo!ihnp4!uiucdcs!uiucme!keith
In what can only be described as a deliberate attempt to alienate the audience,
next postings will consist of a series of complaints:
- knowledge representation problems
- the limits of models
- the assumption of rationality
- can an analysis tool help design?