Re: Open architecture automobiles

From: Tom Potter (tdp_at_earthlink.net)
Date: 07/12/04


Date: Mon, 12 Jul 2004 23:46:25 +0800


"Mark Fergerson" <nunya@biz.ness> wrote in message
news:AxcIc.547$3u2.196@fed1read01...
> 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.

I suggest that the "optimum" is what best
interfaces with the INDIVIDUAL customer,
speed, acceleration, power, comfort, safety, beauty, mileage,
cost, functionality, status, life, reliability, maintenance costs, etc.

"Optimum" in my world is not what the auto companies
try to brainwash me to.

--
Tom Potter     http://home.earthlink.net/~tdp


Relevant Pages

  • Re: Open architecture automobiles
    ... I snipped this way because I was imagining how the above ... > machine by the functional design specs of the parts. ... So, how many kinds of car do we actually need, ... Well, maybe _an_ optimum ...
    (sci.physics)
  • Re: Chip Foose latest car: Impression
    ... might be feasible to design something this perfect, ... And you have to consider the functionality of the finished product - ... the engine looks too "imagined" rather than functional. ... Or if you need a "car pack": ...
    (rec.crafts.metalworking)
  • Re: Language improvement: Add scope to class member fields
    ... every small subset of functionality into seperate classes. ... MyMethodwould check this flag first within a lock and only run the method ... currently stands there is no protection. ... Allowing classes to become more complex is not a terrific design goal, ...
    (microsoft.public.dotnet.languages.csharp)
  • 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)