Re: Open architecture automobiles

From: Mark Fergerson (nunya_at_biz.ness)
Date: 07/11/04 

Date: Sun, 11 Jul 2004 07:54:52 -0700

Edward Green wrote:

> jimp@specsol-spam-sux.com wrote in message news:<ccmfod$7s7$1@mail.specsol.com>...
>
>>Tom Potter <tdp@earthlink.net> wrote:

<snip back to topic>

>>>There is an immediate, growing need for
>>>small, low cost, rugged, energy efficient,
>>>units for farm work, transporting goods,
>>>taxis, portable power sources, etc.
>>
>>Honda, Daewoo.
>>
>>Ever been to a Korean farming village?

   I snipped this way because I was imagining how the above
"customizable" criteria might be interpreted by a Korean
farmer, a lower-middle-class Barrio kid, or Donald Trump.

> I've been repressing the urge to waste time replying at length to
> this, but I I need another posting hit!
>
> The most serious problem I see with this idea is one Mark Fergerson
> pointed out already: cars have emergent properties over the sum of
> properties of their individual parts. Now, Mark didn't use
> "emergent", but he was beating the same bush. A similar observation
> is that you cannot predict all the design interactions in a real
> machine by the functional design specs of the parts.

   Yup. We've also been assuming that there's infinite
flexibility in the system under consideration, which there
isn't for at least three reasons (which I'll get to in a bit).

   I've been thinking of this as a mapping problem; we
imagine the final product will be dictated by the design
process (what we'll use the car for).

> About the purest logical design elements you can come up with are
> computer subroutines: ideally, these parts _are_ their functional
> specs -- what they are supposed to do -- and by hooking up the right
> parts in the right logical sequence you get a composite machine
> producing the right answers. But even in this ideal world there exist
> interactions and effects outside the specs; unanticipated
> imperfections in the OS, variations in performance traceable to behind
> the scenes machine coding, etc.

   You forgot "user error". Some people draw ascii pictures,
and some use font characters as drawing elements in MSPaint.
OK, that's several levels up from what you said, but lazy
programmers grab modules and stick them where they look good
(as BAH will no doubt verify) rather than write new code
because the borrowed stuff is good enough (for some value of
"good"). The latter may sound more like a design error, but
many programmers consider their product's "finish" to be
more important than its content, and an ascii "artist" does
something similar. The individual parts don't quite match up
exactly yet overall you wind up with a map that barely
resembles the territory in all three cases but is still
functional (for some values etc).

   Now, are those actually errors, or just examples of
"creativity under pressure"?

   What do we use cars for? To carry various amounts of
people and stuff over various distances under various
conditions. So, how many kinds of car do we actually need,
and how many of each kind?

   First reason; the problem space (the ranges of "various")
is limited.

> Now, someone want to reduce a great greasy hulk of machine like a
> _car_ to interchangeable logical units!? The most obvious problem is
> all the bits have to fit together. These are not purely functional
> units existing in abstract functional space, but physical units which
> must all be shoe-horned into the same physical space -- and in modern
> engine compartments, pretty damn tightly. And then there are strength
> and weight considerations: the chasis and suspension must support the
> weight of and handle well with weight distribution of the, ahem,
> abtract functional units we are bolting to it; every component of the
> drive train must handle expected loads for an expected service life...

   That brings us to the second reason; the solution space
is limited, yet the maps we make (the cars we design) are to
an imaginary infinite space. The concrete part has to
satisfy "various" above within externally-imposed physical
limits (mechanical component properties, lane width, speed
limits, weather, yadda yadda) and the abstract part has to
satisfy the user's aesthetics.

   The mapmaking criteria are partly standardized because
they're partly random, but random within limits; we may want
a car occasionally capable of surviving Death Valley, but
never the surface of Venus.

   Aesthetics are less manageable, but I submit that there's
less range than may at first appear; frinst flame paint jobs
are still popular.

   I could point to the infamous Homermobile as an extreme
example of poor mapping, yet I understand many people would
actually buy such monstrosities.

   OTOH everybody wants to drive a Landmaster:

http://users.snowcrest.net/fox/landmaster/

   at least once, but few would want to have to drive it to
work every day. This brings us to optimization:

> Maybe I do just like hearing myself type ;-). Click, click, click ...
> any maroon could come up with this stuff. Some of these problems
> could be addressed by a _lot_ of pre-engineering before the tinker-toy
> car parts were released to the public: real engineers would ensure
> that if you only bought components for the "B" line, for example, you
> could chose any motor, any transmission, any etc., bolt them all
> together, and there would be no design interactions outside of some
> standard envelope. At this point we have created some kind of
> mega-version of customizable Hotwheels(TM). Super. We would also be
> assured that almost any car built this way would be far from the
> optimum.

   You're assuming there _is_ an optimum, which I consider
the third reason mentioned above. Well, maybe _an_ optimum
at a given time, but not always, or convertibles wouldn't
exist. A more extreme example would be suspension or 4WD
systems that reconfigure on-the-fly.

   You're suggesting a limited set of envelopes from within
which we may select our version of optimum? Isn't that
basically what we have now?

> We might achieve the mythical "simplification in servicability"
> though. That could be the real advantage of this approach.

   The old VW bug did this (four bolts and a handful of
wires and plumbing to pull the engine) but it wasn't
everybody's idea of optimum.

   Mark L. Fergerson

Relevant Pages

  • Re: Open architecture automobiles
    ... >> machine by the functional design specs of the parts. ... So, how many kinds of car do we actually need, ... > which we may select our version of optimum? ... cost, functionality, status, life, reliability, maintenance costs, etc. ...
    (sci.physics)
  • Re: What Should a Chinese Car Look Like?
    ... What Should a Chinese Car Look Like? ... THE main language spoken at the Shanghai auto show is Chinese, ... to have a lasting effect on global automotive design. ...
    (soc.culture.china)
  • Re: news of the week
    ... And as market leader, that company does not have the time to listen to ... Great, you want to use most often used options into the context menu, ... That's also the kind of reason why my last car was an Accord not a Camry ... didn't design the website for me. ...
    (rec.games.computer.ultima.dragons)
  • Re: Warning: 10.4.3 Preview app. Hang on to the old one!
    ... >>> get rid of it and get your old car back? ... why are the most expensive violins those that were made ... > That is, the design and construction of violins ... Several key parts of guitar design and build borrowed ...
    (comp.sys.mac.apps)
  • Re: Warning: 10.4.3 Preview app. Hang on to the old one!
    ... get rid of it and get your old car back? ... That is, the design and construction of violins has been so well tuned over the many years that it is harder and harder to improve upon the basic design any further. ... Several key parts of guitar design and build borrowed from other instruments have been radically modified over the last 100 years or so, and is still under a fair amount of change even today. ...
    (comp.sys.mac.apps)