Future of Electronics In Aviation

In rec.aviation.piloting Le Chaud Lapin wrote:
On Jun 20, 6:07?am, Bob Noel
wrote:
In article ,
And what analysis techniques would be applied to prove that the resulting
software intensive system is adequately safe?

The same techniques that employed, in general, by experts to test
software.

I don't care how many "fastidious" people look at an architecture or the
as-built system, if they don't know what they are looking for and how to
find it, the odds of proving ?anything useful are pretty small.

Well, assuming they are experts, each in their respective areas, they
would indeed know what to look for. Also, peer-review (by other
experts) is a very good way to check structural integrity of software
(or any system).

Blue Screen of Death (BSOD).

Do I need to say more?


--
Jim Pennino

Remove .spam.sux to reply.

In rec.aviation.piloting Le Chaud Lapin wrote:
On Jun 20, 8:40?am, "Peter Dohm" wrote:
In any case, while process is important, the end result is most
important. ?And the end result would be seen by many people, before
the aircraft is flown, so most defects would be recognized. ?I would
imagine that there would be people who would criticize the
architecture for free.

-Le Chaud Lapin-

There excellent counterexamples all around us--including the computers we
are using to send these messages.

Think how boring the world would be if the opposite were true, that
all software quality were the same (good or bad), no matter who
authored it.

Having your computer die while in the middle of writting a document,
controlling a power plant, running a subway system, or flying an
airplane are not events most people look upon as providing positive
excitement to life.


--
Jim Pennino

Remove .spam.sux to reply.

Le Chaud Lapin wrote:

For XC flights, a computer can do a far better job optimizing fuel
efficiency, for example, by controlling control surfaces dynamically
during flight. A computer can also minimize the effects of
turbulence, by reactively changing the same control surfaces
dynamically.

Can you actually cite some numbers and studies
or are you just making this stuff up?

It was proven back in the 30's or 40's that after
an airplane flies into a pocket of turbulence,
it's too late for either a pilot or a computer
to make much difference. The *only* way to fix
the problem is with a 20-30 foot boom ahead of
the aircraft structure that can sense and react
to the turbulence ahead of time.

As to fuel economy, perhaps you can tell me how
a computer could tune the radio and get winds
aloft readings and pick the best altitude for
cruise? Since it can't, it is unlikely that it
could do a better job than a pilot. OTOH, if
you have some concrete evidence to the contrary,
I'd love to see it.

In rec.aviation.piloting Le Chaud Lapin wrote:
On Jun 20, 5:16?am, Dylan Smith wrote:
On 2008-06-19, Le Chaud Lapin wrote:

3. Do you think electronics should retain a peripheral role ? (Garmin,
etc) but not be used in control paths (fly-by-wire)?

Fly by wire is pretty pointless on the kinds of planes we fly, it's
adding complexity where none is needed and steel cables and pulleys are
pretty reliable in airplanes, and pushrods to the swash plate in a
helicopter seem very reliable too. Changing those to electronics would
have pretty much zero benefit in a light airplane or helicopter (and
some significant disadvantages).

I disagree.

Because apparently you know nothing about real flying.

For XC flights, a computer can do a far better job optimizing fuel
efficiency, for example, by controlling control surfaces dynamically
during flight. A computer can also minimize the effects of
turbulence, by reactively changing the same control surfaces
dynamically.

A computer can take any of many objectives defined by pilot:

1. Minimum time in flight.
2. Minimum fuel consumption.
3. Altitude stabilization.
4. Minimum susceptibility to turbulence.
5. Maximum visibility of surroundings.

Total, utter nonsense.

etc...

And make the flight conform to those requirements, and warn if it can
not.

That very same computer could communicate flight plan to ground, store
minute details of entire flight on hard disk and automatically move
them to home computer for recap....

Control electronics does exist for GA, it's called an autopilot, and
they've been around for a long time (some more sophisticated than
others). Some engines are also available with FADEC.

These systems are massively expensive, and there is much redundancy.
For example, the entire radio stack could be eliminated by a software
radio, which controls fed through LCD monitor. The software radi
costs $1000. The computer would be one of same 2 computers used for
other functions.

Yeah, for one Amateur Radio grade software radio with you supplying
the computer.

The possibilities are essentially endless. GA is at the beginning,
not the end, of discovering them.

Especially for someone who gets their ideas from comic books.



--
Jim Pennino

Remove .spam.sux to reply.

On Jun 20, 11:35*am, wrote:
In rec.aviation.piloting Le Chaud Lapin wrote:

On Jun 20, 8:40?am, "Peter Dohm" wrote:
In any case, while process is important, the end result is most
important. ?And the end result would be seen by many people, before
the aircraft is flown, so most defects would be recognized. ?I would
imagine that there would be people who would criticize the
architecture for free.

-Le Chaud Lapin-

There excellent counterexamples all around us--including the computers we
are using to send these messages.
Think how boring the world would be if the opposite were true, that
all software quality were the same (good or bad), no matter who
authored it.

Having your computer die while in the middle of writting a document,
controlling a power plant, running a subway system, or flying an
airplane are not events most people look upon as providing positive
excitement to life.

Every machine can fail.

What matters so much is not whether the machine is a computer or
something else, but the probability of failure of that component, and
the probability of failure of the overall system as a result.

I read on regular basis about ICE's that failed for whatever reason.
But people still use ICE's.

One should look at the math of each situation and do what is necessary
to make likelihood of system failure at least equivalent.

-Le Chaud Lapin-

wrote:
In rec.aviation.piloting Le Chaud Lapin wrote:
On Jun 19, 9:54?pm, Bob Noel
wrote:
[...]
What makes you think that software engineering, or system
engineering, has progressed to the point that a software intensive
system would be developed "with proper discipline"?

That's fair enough. Software, perhaps more than any other discpline,
allows engineers to place themselves where they are most comfortable
on the spectrum of intellectual discipline.
[...]
In any case, while process is important, the end result is most
important. And the end result would be seen by many people, before
the aircraft is flown, so most defects would be recognized. I would
imagine that there would be people who would criticize the
architecture for free.

From the perspective of dealing with software development for about
a quarter century now, all I can say is that it is obvious you know
**** from shinola about software development, reliability, and
testing.

Well I've been programming for 35 years and been getting paid to do it for
30, so by your own metric I am presumably in some sort of authoritative
position to judge your counter arguments to Lapin re software development.
But I somehow doubt you really want to know what I think of your arguments.
;-)

In article ,
wrote:

In rec.aviation.piloting Le Chaud Lapin wrote:
On Jun 19, 9:54?pm, Bob Noel
wrote:
In article
,
?Le Chaud Lapin wrote:

I agree. Safety is paramount. ?Computers, with proper discipline on
behalf of the designer, can be programmed to speak up when they are
sick or think there is a chance that they could be sick. ?They can
even help in complaining about potential future faults in mechanical
components. ?For example, using raw data such as temperture, humidity,
pressure, fuel mixture, and power-output, a computer very easily can
calculate probability of carb icing. ?There is an essentially
unlimited number of things that a computer can assisst with in flying
that comes at no real material cost beyond having put the computer in
place in the first place.

What makes you think that software engineering, or system engineering,
has progressed to the point that a software intensive system would be
developed "with proper discipline"?

That's fair enough. Software, perhaps more than any other discpline,
allows engineers to place themselves where they are most comfortable
on the spectrum of intellectual discipline.

However, there are some engineers out there. There is a young man in
Nederlands, for example, whose work I have had a glimpse of. He has
Ph.D. in crystallography, but is breadth of knowledge is very wide.
His knowledge of mathematics and computer science is competitive with
that of Ph.D's in computer science and mathematics. His style of
engineering gives new meaning to the word "fastidious".

I would think 15 people like him should be sufficient to tackle any
software problem that might arise in the design of a PAV. I also know
a few people who studied aero/astro at university.

In any case, while process is important, the end result is most
important. And the end result would be seen by many people, before
the aircraft is flown, so most defects would be recognized. I would
imagine that there would be people who would criticize the
architecture for free.

From the perspective of dealing with software development for about
a quarter century now, all I can say is that it is obvious you know
**** from shinola about software development, reliability, and testing.

I would have phrased it a bit more delicately, but yes.

In article
,
Le Chaud Lapin wrote:

On Jun 20, 6:07*am, Bob Noel
wrote:
In article
,
And what analysis techniques would be applied to prove that the resulting
software intensive system is adequately safe?

The same techniques that employed, in general, by experts to test
software.

And exactly what level of reliability do you think you'll need to have?

Note that the cost can rise enormously for fairly small increases in end
product reliability.

And so far we haven't said much about what the lawyers will bring to
your nifty new product. (Trust me, it won't be something to make you
emit small cries of joy.)

I don't care how many "fastidious" people look at an architecture or the
as-built system, if they don't know what they are looking for and how to
find it, the odds of proving *anything useful are pretty small.

Well, assuming they are experts, each in their respective areas, they
would indeed know what to look for. Also, peer-review (by other
experts) is a very good way to check structural integrity of software
(or any system).

You *really* don't know what is involved in developing verifiably
correct software systems, either in time or money.

It's *very* difficult and expensive.

In rec.aviation.piloting Le Chaud Lapin wrote:
On Jun 20, 11:35?am, wrote:
In rec.aviation.piloting Le Chaud Lapin wrote:

On Jun 20, 8:40?am, "Peter Dohm" wrote:
In any case, while process is important, the end result is most
important. ?And the end result would be seen by many people, before
the aircraft is flown, so most defects would be recognized. ?I would
imagine that there would be people who would criticize the
architecture for free.

-Le Chaud Lapin-

There excellent counterexamples all around us--including the computers we
are using to send these messages.
Think how boring the world would be if the opposite were true, that
all software quality were the same (good or bad), no matter who
authored it.

Having your computer die while in the middle of writting a document,
controlling a power plant, running a subway system, or flying an
airplane are not events most people look upon as providing positive
excitement to life.

Every machine can fail.

True but irrelevant.

What matters so much is not whether the machine is a computer or
something else, but the probability of failure of that component, and
the probability of failure of the overall system as a result.

And establishing that probablility is generally an extremely
expensive process.

I read on regular basis about ICE's that failed for whatever reason.
But people still use ICE's.

Irrelevant

One should look at the math of each situation and do what is necessary
to make likelihood of system failure at least equivalent.

Already been done. It is called FAA certification requirements.


--
Jim Pennino

Remove .spam.sux to reply.

On Jun 20, 12:01*pm, Jim Logajan wrote:
wrote:
In rec.aviation.piloting Le Chaud Lapin wrote:
On Jun 19, 9:54?pm, Bob Noel
wrote:
[...]
What makes you think that software engineering, or system
engineering, has progressed to the point that a software intensive
system would be developed "with proper discipline"?

That's fair enough. Software, perhaps more than any other discpline,
allows engineers to place themselves where they are most comfortable
on the spectrum of intellectual discipline.
[...]
In any case, while process is important, the end result is most
important. *And the end result would be seen by many people, before
the aircraft is flown, so most defects would be recognized. *I would
imagine that there would be people who would criticize the
architecture for free.

From the perspective of dealing with software development for about
a quarter century now, all I can say is that it is obvious you know
**** from shinola about software development, reliability, and
testing.

Well I've been programming for 35 years and been getting paid to do it for
30, so by your own metric I am presumably in some sort of authoritative
position to judge your counter arguments to Lapin re software development.
But I somehow doubt you really want to know what I think of your arguments..
;-)

Please, do tell.

Being in software field, you know that there are people who have been
programming for 40 years whom you would not trust to design a flight
control computer that relies on advanced mathematics.

Obviously not saying that you are in that category. I'm merely saying
that I would look for other personal attributes beyond experience that
makes an engineer/designer predisposed to not make a mess, someone who
is acutely aware of the potential outcome of bad engineering. That
person might or might not have 35 years of experienece, but if I had
to choose between the Dutch guy mentioned above, who probably has
12-15 years experience,, and a random senior engineer with 40 years
experience, I would not hesitate to choose the Dutch guy, simply
because I already know that he possesses these attributes.

-Le Chaud Lapin-