Is it a habit we prefer mechnical instruments?

"Le Chaud Lapin" wrote in message Yes
proper nomenclature is really important. But in fact, I do mean
both the instruments and the controls. They should be brought as deep
into the digital domain as possible. Again, as an electrical/software
engineer (but not a pilot), I am biased.

And from your lack of experience and your bias you are accusing us of being
stupid and reactionary. Clearly we should see this the same way you do.

To us you appear as incredibly ignorant. You suggestions are incredibly
naive and ignorant.

Learn to fly. Get an instrument rating. Put your life on the line. THEN
come back and convince us.

Highflyer
Highflight Aviation Services
Pinckneyville Airport ( PJY )

On Tue, 25 Apr 2006 00:07:37 -0500, "Highflyer" wrote:


"Le Chaud Lapin" wrote in message Yes
proper nomenclature is really important. But in fact, I do mean
both the instruments and the controls. They should be brought as deep
into the digital domain as possible. Again, as an electrical/software
engineer (but not a pilot), I am biased.

And from your lack of experience and your bias you are accusing us of being
stupid and reactionary. Clearly we should see this the same way you do.

To us you appear as incredibly ignorant. You suggestions are incredibly
naive and ignorant.

Learn to fly. Get an instrument rating. Put your life on the line. THEN
come back and convince us.

Highflyer
Highflight Aviation Services
Pinckneyville Airport ( PJY )


got it exactly correct in those 3 paragraphs.
Stealth Pilot

Highflyer wrote:
"Le Chaud Lapin" wrote in message
oups.com...

I think if you're about to take a trip, waiting the whole 17 seconds
for the OS to boot (Windows) won't hurt too much.


That is all very well when you are sitting in the coffee shop playing with
your laptop.

17 seconds without instruments on an instrument approach in solid IMC and it
will hurt a lot, but not for long.
Requiscat et Pacem ...

Don't turn PC off during flight.

-Le Chaud Lapin-

Highflyer wrote:
And from your lack of experience and your bias you are accusing us of being
stupid and reactionary. Clearly we should see this the same way you do.

Whose making accusations? I was talking about digital controls, not
stupidity and reactionism.

To us you appear as incredibly ignorant. You suggestions are incredibly
naive and ignorant.

There is an echo in here somewhere...

Learn to fly. Get an instrument rating. Put your life on the line. THEN
come back and convince us.

It is not necessary to be skilled in the utilization of a tool to know
how to implement that tool.

-Le Chaud Lapin-

"Le Chaud Lapin" wrote in message
oups.com...
Highflyer wrote:
"Le Chaud Lapin" wrote in message
oups.com...

I think if you're about to take a trip, waiting the whole 17 seconds
for the OS to boot (Windows) won't hurt too much.


That is all very well when you are sitting in the coffee shop playing
with
your laptop.

17 seconds without instruments on an instrument approach in solid IMC
and it
will hurt a lot, but not for long.
Requiscat et Pacem ...

Don't turn PC off during flight.

-Le Chaud Lapin-

I've got a great idea for you, Le Chaud.

Especially since the odds are that your plane of reality is in a different
state than mine and certainly hundreds of miles away: I think that you
should develope and test this whole concept, including the fly by wire
(a/k/a drive by wire) in your car. It should be pretty safe, not much new
to learn and you're already on the ground...

"Le Chaud Lapin" wrote in message
oups.com...
Highflyer wrote:
And from your lack of experience and your bias you are accusing us of
being
stupid and reactionary. Clearly we should see this the same way you do.

Whose making accusations? I was talking about digital controls, not
stupidity and reactionism.

To us you appear as incredibly ignorant. You suggestions are incredibly
naive and ignorant.

There is an echo in here somewhere...

Learn to fly. Get an instrument rating. Put your life on the line.
THEN
come back and convince us.

It is not necessary to be skilled in the utilization of a tool to know
how to implement that tool.

-Le Chaud Lapin-

This entire thread started off because some poor technician, apparently
living in the R.O.C. according to this sender address, asked a question
which could be paraphrased as: Do we [humans and/or pilots] still use
mechanical analog meters purely from habit or, if given a free choice, would
we prefer electronic digital displays, electronic analog displays, or both
displays superimposed?

You, Le Chaud, took his question far beyond the next level, by suggesting
that the entire instrument and navigation systems could be combined into a
single inexpensive package, and then asserted that you were only agreeing
with the OP.

So, by the time that you were "only agreeing" you were already saying that
our crude, but redundant, displays should be combined into a single system.

That did still leave our crude, but redundant, primary flight controls and
trim controls relatively intact. But wonders did cease.

Since then, an autopilot seems to have been added; and now a complete,
though not redundant, fly by wire...

A few minutes ago, I suggested elsewhere in the thread that you try it first
in your car. I have reconsidered my rash statement, and now suggest that
you try it first in a go-cart. Less collateral damage!

In article .com,
Le Chaud Lapin wrote:
Highflyer wrote:
And from your lack of experience and your bias you are accusing us of being
stupid and reactionary. Clearly we should see this the same way you do.

Whose making accusations? I was talking about digital controls, not
stupidity and reactionism.

You have made disparaging comments about those who have the temerity to
disagree with your assessment of the 'value' of integrated digital
functionality.

To us you appear as incredibly ignorant. You suggestions are incredibly
naive and ignorant.

There is an echo in here somewhere...

Yup. in that empty space between your ears.

You are *so* ignorant of the field (flight instrumentation and aircraft
operation) that you can't even use the basic terminology correctly.

Do you know what 'controls', as in 'flight controls' even _means_?

If you do, why do you persist in using in the *grossly**incorrect* manner
you do?

What would _you_ think of the electronics skills of someone who made continuing
reference to a "500 micro-farad resistor"?

Learn to fly. Get an instrument rating. Put your life on the line. THEN
come back and convince us.

It is not necessary to be skilled in the utilization of a tool to know
how to implement that tool.

But a thorough knowledge of the environment in which it will operate *is*
=CRITICAL=.

You have _demonstrated_ a clear lack of comprehension of:
1) the physical environment
2) the potential size of the market
3) the regulatory issues (and *costs*) involved in selling beyond the
miniscule 'experimental' (aircraft) market.
4) Murphy's Law. (I'll bet you don't even know what field Murphy worked
in. And, yes, he is a -real- person.)
5) O'Brien's Law.

Trivial example of your 'ignorance in action' -- promoting USB for
sensor-processor interconnect. _ONE_ sensor on the bus malfunctions
in a manner such as to 'hang' the bus, and *none* of the other sensors
can pass status data. e.g. tire-pressure flakes out and you lose
air-speed, turn-and-bank, and altimeter, too. Ah well, that's no
problem I guess, given you've got the 'cat and duck' emergency reserve
system.


*INDEPENDENT* hardware systems have this inconsequential little
characteristic known as 'no common single point of failure'. As soon
as you start 'integrating' multiple functions within a system, the
difficulty of maintaining that autonomy among functions increases
radically.

And the more functions you 'integrate' together, the *harder* it gets
to prevent compound, _catastrophic_, failures.

Even the famed "triple-redundant hardware w/ 'voting'" architecture
doesn't protect against a _software_ error, assuming all 3 sets of
hardware are using the same software. And, if they're _not_ using
'identical' software, you have to (a) vet 3 separate implementations,
(b) make sure the installed versions are the 'equivalent' at all times,
and (c) ensure that all modifications and updates are done differently
on the three 'unique' versions.




That which you have proposed _could_ be done relatively easily as you
suggest. But *ONLY* for 'toy `value' reasons, and _IN_ADDITION_TO_ the
existing tools.

For reasons -- only _some_ of which have been alluded to above -- which
are outside of your realm of expertise, no PIC in his right mind would
trust his life (or that of his passengers) to a system of the type you
have described. The 'downside risk' in a worst-case scenario is un-
acceptable, and the probability of worst-case scenarios is far, *FAR*
too high.


BTW, did you know that 'flight instrumentation', not to mention 'flight
controls' is classified as a 'life critical' use; and *NO* commodity
operating system license allows you to use it for life critical applications?
`
You _wouldn't_believe_ how expensive a life-critical-certified O/S is.
And how _LITTLE_ functionality it includes.

Robert Bonomi wrote:
Yup. in that empty space between your ears.

You are *so* ignorant of the field (flight instrumentation and aircraft
operation) that you can't even use the basic terminology correctly.

Do you know what 'controls', as in 'flight controls' even _means_?

If you do, why do you persist in using in the *grossly**incorrect* manner
you do?

I used terms that are considered normal in control theory. I regard the
aircraft as a machine that is being engineered, not any more or less
than I would an automobile, a conveyor belt, etc. Regarded in that
way, the proper terms are controls and sensors.

Note that I am not attempting to change what aviation calls these
things, but I use the term to be clear. In my model, it would be hard
to find the "instruments", because they would be supplanted by a purely
digital display that could very well have 80% of monitor taken up by
picture of the house pet. If we were to revert to what many pilots
seem to prefer, which is not what I was promoting, then I would use the
terminology that they are using.

What would _you_ think of the electronics skills of someone who made continuing
reference to a "500 micro-farad resistor"?

Perhaps that person has found a resitor with absolutely huge intrinsic
capacitance.

It is not necessary to be skilled in the utilization of a tool to know
how to implement that tool.

But a thorough knowledge of the environment in which it will operate *is*
=CRITICAL=.

You have _demonstrated_ a clear lack of comprehension of:
1) the physical environment
2) the potential size of the market
3) the regulatory issues (and *costs*) involved in selling beyond the
miniscule 'experimental' (aircraft) market.
4) Murphy's Law. (I'll bet you don't even know what field Murphy worked
in. And, yes, he is a -real- person.)
5) O'Brien's Law.

Perhaps the reason that the market is so miniscule is that it is cost
prohibitive to many people who might consider it. And regulation is
regulation. The device either works or it doesn't. As far as the
1000-unit count that was stated by someone else, I never pegged the
unit count at 1000. I do know that if the cost drops below a certain
threshold, along with the cost of ownership, there would be many more
people who would consider flying as a hobby, especially if the
components were significantly more commoditized than they are now.

Trivial example of your 'ignorance in action' -- promoting USB for
sensor-processor interconnect. _ONE_ sensor on the bus malfunctions
in a manner such as to 'hang' the bus, and *none* of the other sensors
can pass status data. e.g. tire-pressure flakes out and you lose
air-speed, turn-and-bank, and altimeter, too. Ah well, that's no
problem I guess, given you've got the 'cat and duck' emergency reserve
system.

Any problems of this nature can be cicumvented with proper engineering.

*INDEPENDENT* hardware systems have this inconsequential little
characteristic known as 'no common single point of failure'.

I guess that's why most aircraft come with spare engines.

As soon
as you start 'integrating' multiple functions within a system, the
difficulty of maintaining that autonomy among functions increases
radically.

True. But that hasn't stopped people from using software to control
"life critical" systems.

And the more functions you 'integrate' together, the *harder* it gets
to prevent compound, _catastrophic_, failures.

Same.

Even the famed "triple-redundant hardware w/ 'voting'" architecture
doesn't protect against a _software_ error, assuming all 3 sets of
hardware are using the same software. And, if they're _not_ using
'identical' software, you have to (a) vet 3 separate implementations,
(b) make sure the installed versions are the 'equivalent' at all times,
and (c) ensure that all modifications and updates are done differently
on the three 'unique' versions.

All systems are susceptible to faulty design. The key is whether the
engineer has realized what s/he thinks s/he has realized, with
sufficient provision for oversight.

That which you have proposed _could_ be done relatively easily as you
suggest. But *ONLY* for 'toy `value' reasons, and _IN_ADDITION_TO_ the
existing tools.

I disagree. I do believe that the day will come where the so-called
"too complex to leave to software" designs will be the nom. It will
happen slowly as people drag their feet.

I remember reading that when cars came out, people were terrified of
the though of two vehicles going in opposite directions at more than 40
mph in opposite with no median on the road. Today it's no big deal -
just this morning I was doing 80mph on on such road as the person
approaching me was doing 70. What if my brakes gave out? What if the
power steering developed a mind of its own? What if the nuts worked
themselves loose and a tire came off (1 nut did come off once)? What if
the ECM decided to lock in speed control as I approached the curve?

What if...what if....what if..?

What if does happen, but not frequently enough to keep me from driving,
or taking elevators, or climbing into a computerized axial tomography
machines, or letting a software machine control the positions my jaw at
the dentist, or let a software machine limit bombardment of my chest by
radiation, or let a software machine control the injection of lasers
into my eyes...

One day, as it most often does with advancement in the application of
technology, "What if..?" is going to turn into just "What?"

For reasons -- only _some_ of which have been alluded to above -- which
are outside of your realm of expertise, no PIC in his right mind would
trust his life (or that of his passengers) to a system of the type you
have described. The 'downside risk' in a worst-case scenario is un-
acceptable, and the probability of worst-case scenarios is far, *FAR*
too high.

If you simply replaced "PIC" with "person" in the above paragraph, you
could be restating an assertion made about any of many inventions that
have been built over the last 300 years, including aircraft.

BTW, did you know that 'flight instrumentation', not to mention 'flight
controls' is classified as a 'life critical' use; and *NO* commodity
operating system license allows you to use it for life critical applications?

No I didn't know that, but things change. If the price is right, and
the demand is high enough, peopole will find a way to revisit
"technicalities" to accommodate their new perspective on the matter.

You _wouldn't_believe_ how expensive a life-critical-certified O/S is.
And how _LITTLE_ functionality it includes.

So basically what you're saying is that the program that controls the
flaps should not have Web popups that promote gambling?

-Le Chaud Lapin-

In article .com,
Le Chaud Lapin wrote:

Robert Bonomi wrote:
Yup. in that empty space between your ears.

You are *so* ignorant of the field (flight instrumentation and aircraft
operation) that you can't even use the basic terminology correctly.

Do you know what 'controls', as in 'flight controls' even _means_?

If you do, why do you persist in using in the *grossly**incorrect* manner
you do?

I used terms that are considered normal in control theory.

Unfortunately, you comingled/confused/aggregated 'inputs' and 'outputs'.
either deliberately, or through ignorance of function in regard to aircraft.
Or, possibly a failure to understand that they are qualitatively different..

I regard the
aircraft as a machine that is being engineered, not any more or less
than I would an automobile, a conveyor belt, etc. Regarded in that
way, the proper terms are controls and sensors.

Note that I am not attempting to change what aviation calls these
things, but I use the term to be clear. In my model, it would be hard
to find the "instruments",

Bull****. An 'instrument' has three uniquely identifiable functional parts,
Sometimes these parts are distinct components, which may, or may not be
in physical proximity; sometimes they are inextricably co-mingled.
the components a
1) an input source -- to which the name 'sensor' usually applies.
2) a translation unit, for lack of a better name
3) a display of some sort.
`
because they would be supplanted by a purely
digital display that could very well have 80% of monitor taken up by
picture of the house pet. If we were to revert to what many pilots
seem to prefer, which is not what I was promoting, then I would use the
terminology that they are using.

That digital display is still the visible part of the 'instrument'.
They're usually referred to as 'soft instruments', when you're dealing
with a full "glass cockpit", because the location of the 'instruments'
can be relocated at need. This is generally _not_ done at whim, because
pilots expect to find the same instruments in the same place. However,
in case of a partial failure, it can be necessary to 'relocate' critical
instruments to a functioning display.

It is not necessary to be skilled in the utilization of a tool to know
how to implement that tool.

But a thorough knowledge of the environment in which it will operate *is*
=CRITICAL=.

You have _demonstrated_ a clear lack of comprehension of:
1) the physical environment
2) the potential size of the market
3) the regulatory issues (and *costs*) involved in selling beyond the
miniscule 'experimental' (aircraft) market.
4) Murphy's Law. (I'll bet you don't even know what field Murphy worked
in. And, yes, he is a -real- person.)
5) O'Brien's Law.

Perhaps the reason that the market is so miniscule is that it is cost
prohibitive to many people who might consider it.

Much more likely, it is because it is "time prohibitive" for most people.

The 'experimental' market is the _build-it-yourself_ crowd.

Visit the FAA database, and see how many _actively_flying_ craft there
are in that category. and see how many -additions- there are in a years
time.

Then look at the size of the actively flying 'general aviation' category.

To sell to _that_ group, you have to get your toy 'government certified'
in *each* type of aircraft you want to have it installed in.

Assume the certification cost is 'only' $1,000,000 per type.
Assume that you sell to 10% of the planes flying in that type.
How much does that 'certification' alone add to your cost of production?
How much do you have to raise the prices to compensate?
How many _fewer_ sales will you make because of that price increase?

And regulation is
regulation. The device either works or it doesn't. As far as the
1000-unit count that was stated by someone else, I never pegged the
unit count at 1000.

Of course you didn't. that's just one more of the things you "Don't know".
It is a reasonable estimate of the _entire_ *active* experimental aircraft
marketplace that might be interesting buying such a critter.

For break-even, you'll have to amortize you *entire* development costs
over some (relatively small) fraction of that market.

If you're lucky, you'll get 25% market penetration. Over a period of years.

But, lets say your product is*really* good, and you get a 50% share.
How much do you have to charge to recoup all your development, marketing,
and production expenses, with a projected sales volume of a whopping 500
units?

How many of those people will be 'priced out of the market' at that point?

It's _not_ just an engineering matter. grin

I do know that if the cost drops below a certain
threshold, along with the cost of ownership, there would be many more
people who would consider flying as a hobby, especially if the
components were significantly more commoditized than they are now.

"if dog, rabbit." Postulate (by faith) the right assumptions -- regardless
of congruence with the real world, and you can prove *anything*.

Owning an airplane is *expensive*.

Purchase price is, actually, a relatively *SMALL* part of that cost.

insurance, storage, maintenance, are all 'non-trivial', and that's *before*
you go flying at all. Now add in 'consumables', gas, oil .etc.

Recurring costs in the mid to upper 4 figures a year. mid to upper 5 figures
over 10 years. a mid-5-figure purchase price (used), that you can sell
10 years later (properly maintained) for. say, 80% of purchase, is not a
big part of the picture. drop the purchase price to 'low 4 figures'.
it doesn't make a noticable dent in the TCO.

Trivial example of your 'ignorance in action' -- promoting USB for
sensor-processor interconnect. _ONE_ sensor on the bus malfunctions
in a manner such as to 'hang' the bus, and *none* of the other sensors
can pass status data. e.g. tire-pressure flakes out and you lose
air-speed, turn-and-bank, and altimeter, too. Ah well, that's no
problem I guess, given you've got the 'cat and duck' emergency reserve
system.

Any problems of this nature can be cicumvented with proper engineering.

Since you proposed USB as the way, you must now be admitting your proposal
was not proper engineering. Which the rest of us already knew. grin

*INDEPENDENT* hardware systems have this inconsequential little
characteristic known as 'no common single point of failure'.

I guess that's why most aircraft come with spare engines.

You just demonstrated, again, how much you _don't_know_ about aircraft and
flying.

If you look at the planes in commercial use today, you'll find that
_almost_all_ of them *ARE* equipped with a 'hot spare' engine.

Until recently in fact, for long-distance over-water flights, you had to
carry *TWO* 'hot spares'. The latest Boeing, and a few other newer planes
are allowed to make that kind of flight with only one 'hot spare'.

Yes, you can fly faster with additional engines, but _AT_LEAST_AS_IMPORTANT_
is the fact that you *can* keep flying if you lose one. or two.

And, with the exception of some homebuilts using 'conversion' engines,
there are 'close to' two engines behind that single propeller. dual
spark-plugs per cylinder. dual magnetos to generate the power to the
plug, frequently dual carbs, dual fuel feeds, etc.


As soon
as you start 'integrating' multiple functions within a system, the
difficulty of maintaining that autonomy among functions increases
radically.

True. But that hasn't stopped people from using software to control
"life critical" systems.

Agreed. but you *don't* do it 'on the cheap'. It is, by nature, *NOT*
a 'commodity' market. This is stuff you want 'done right', _not_, "by
the lowest bidder".

And far-and-away the fast majority of 'life-critical' software is in
essentially single-function devices.

E.g.,in a hospital, f you're getting three different meds in the IV,
they'll hand a -separate- monitoring computer for each drug, rather than
one computer that monitors all three bottles.

And the more functions you 'integrate' together, the *harder* it gets
to prevent compound, _catastrophic_, failures.

Same.

And the *more* expensive it is, _per_function_.
complexity of interactions goes up at a rate _far_above_ linear.

The "law of diminishing returns" _inexorably_ bites you in the pocketbook.

Why do you think the hospital 'crash cart' has a whole bunch of _independent_
computerized devices, rather than one computer with a collection of
peripherals?

Even the famed "triple-redundant hardware w/ 'voting'" architecture
doesn't protect against a _software_ error, assuming all 3 sets of
hardware are using the same software. And, if they're _not_ using
'identical' software, you have to (a) vet 3 separate implementations,
(b) make sure the installed versions are the 'equivalent' at all times,
and (c) ensure that all modifications and updates are done differently
on the three 'unique' versions.

All systems are susceptible to faulty design. The key is whether the
engineer has realized what s/he thinks s/he has realized, with
sufficient provision for oversight.

That which you have proposed _could_ be done relatively easily as you
suggest. But *ONLY* for 'toy `value' reasons, and _IN_ADDITION_TO_ the
existing tools.

I disagree. I do believe that the day will come where the so-called
"too complex to leave to software" designs will be the nom. It will
happen slowly as people drag their feet.

That's ok. You "don't know what you don't know".

You can't even state the problem proposition correctly.

The issue is -not- 'too complex to leave to software'; it is "too expensive
to create the software of the necessary quality and reliability" combined
with "weighs more than the alternative."

You don't know aircraft design.

You don't understand the "trade-offs".

Weight - reliability - cost - failure-modes


I remember reading that when cars came out, people were terrified of
the though of two vehicles going in opposite directions at more than 40
mph in opposite with no median on the road. Today it's no big deal -
just this morning I was doing 80mph on on such road as the person
approaching me was doing 70. What if my brakes gave out?

Why do you think cars have an "emergency brake"?

Why do you think that that brake control is a _mechanical_ parallel to the
hydraulic system?

What if the
power steering developed a mind of its own?

Odd you should mention that one. Why do you think that there is still a
*direct*mechanical* connection between the wheel and the tires?

Why haven't we gone to 'drive by wire' for automobiles?
Drive-by-wire steering, using nothing more than simple selsyn motors
could have been done 40-50 years ago. Eliminating that long steering
column, and saving (probably) the lives of all those people who have
died from being 'impaled' on the column.

What if the nuts worked
themselves loose and a tire came off (1 nut did come off once)?

Why do you thing wheels are held on with multiple nuts?

Note: _I_ *have* lost a wheel (completely) at highway speeds. A bad
wheel bearing chewed up the axle, and it broke. tire, wheel, brake
drum and all came off. car ran over the tire, and the rear end bounced
about 4 feet in the air. Came down with a slam, and went skidding down
the highway, grinding off the bottom of the plate behind the brake drum.
"Gyroscopic action" caused the tire to recover onto its tread, and it
got impatient with the way the car was slowing down, and swung out and
_passed_ me. I looked out the driver's window, and there was my left
rear tire. it ended up about 1/2 mile further down the road from where
I, and the car, came to a stop.z.

What if
the ECM decided to lock in speed control as I approached the curve?

Why do you think the brake-pedal interlock on the speed control
_mechanically_ disconnects the throttle control, as well as sending
a cut-off signal to the software?

Why have all those separate computers under the hood? Why not 'integrate'
all the functionality? Why not have the ECM also handle the ABS? And the
climate control. And the radio. And the smart-key entry. And the remote
door-lock/unlock.

What if...what if....what if..?

What if does happen, but not frequently enough to keep me from driving,
or taking elevators, or climbing into a computerized axial tomography
machines, or letting a software machine control the positions my jaw at
the dentist, or let a software machine limit bombardment of my chest by
radiation,

God thing you weren't treated by one of those buggy X-ray machines a few
years back, isn't it? grin

or let a software machine control the injection of lasers
into my eyes...

One day, as it most often does with advancement in the application of
technology, "What if..?" is going to turn into just "What?"

For reasons -- only _some_ of which have been alluded to above -- which
are outside of your realm of expertise, no PIC in his right mind would
trust his life (or that of his passengers) to a system of the type you
have described. The 'downside risk' in a worst-case scenario is un-
acceptable, and the probability of worst-case scenarios is far, *FAR*
too high.

If you simply replaced "PIC" with "person" in the above paragraph, you
could be restating an assertion made about any of many inventions that
have been built over the last 300 years, including aircraft.

BTW, did you know that 'flight instrumentation', not to mention 'flight
controls' is classified as a 'life critical' use; and *NO* commodity
operating system license allows you to use it for life critical applications?

No I didn't know that, but things change. If the price is right, and
the demand is high enough, peopole will find a way to revisit
"technicalities" to accommodate their new perspective on the matter.

*snicker* You *really* "don't know what you don't know" on that one.
The _owner's_ of the software expressly disallow it's use in such
applications because of the risk of a lawsuit in the event something
"bad" happened. Whether it was their fault or not, they *will* get sued,
because they are in the 'deep pockets' class.


You _wouldn't_believe_ how expensive a life-critical-certified O/S is.
And how _LITTLE_ functionality it includes.

So basically what you're saying is that the program that controls the
flaps should not have Web popups that promote gambling?

Hell, _that_ programming shouldn't even have the ability to do any sort
of filesystem activities, sure as hell doesn't need any graphical display
capabilities, MIDI output, voice-recognition, 'help' on usage, multi-lingual
support, unicode support, etc., etc., ad nauseum.

it's hard to make a case _against_ putting that programming in the on-chip
EPROM on a dedicated 8031. grin

Robert Bonomi wrote:

Why have all those separate computers under the hood? Why not 'integrate'
all the functionality? Why not have the ECM also handle the ABS? And the
climate control. And the radio. And the smart-key entry. And the remote
door-lock/unlock.

This is the thesis of my argument.

It is very often the case that a person with expertise in one area
will, ideally, seek expertise in a complementary area but decide, for
whatever reason, not to seek it. The result is usually higher cost,
reduced inefficiency, and often less elegance than would have been
achieved if each expert had applied his/her expertise to their
respective fields of competence. In the case of the devices you
mention, redundancy surely would have been a reason for separting the
computers, but even if there had been a 100% guarantee that no fault
would have ever occured, the components would probably have still been
separated, because the engineers who make these things are not in the
mind set of commoditizing the components.

And for all the redundancy, failsafe-ness, etc... the fact is that
relatively few devices that are well-engineer malfunction. In fact, we
should be surprised that they function as well as they do. One the
magic price point has been it, most people are going to ask a simple
question that they have always asked historically: "What are the
chances that I am going to die or become seriously injured from using
this device, and what is the relative benefit that I get."

I am confident that real engineers can get their systems to a point
where the answer to the first part of this question is "relatively
small". Once that happens, it is pointless to talk about what-ifs,
becaause people will already be using the "things."

That day is going to come one day. If you look around hard enough, you
will see that it already has.

-Le Chaud Lapin-