Received-SPF: softfail
 receiver=logan.com; client-ip=64.102.122.148; envelope-from=echristley@nc.rr.com
Message-ID: <44A14E4E.7070003@nc.rr.com>
Date: Tue, 27 Jun 2006 11:27:10 -0400
From: Ernest Christley <echristley@nc.rr.com>
Reply-To: echristley@nc.rr.com
User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929)
MIME-Version: 1.0
To: aeroelectric-list@matronics.com,
        Rotary motors in aircraft <flyrotary@lancaironline.net>
Subject: Software in the cockpit
References: <200606270655.k5R6tTMX023172@mail.matronics.com>
In-Reply-To: <200606270655.k5R6tTMX023172@mail.matronics.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

AeroElectric-List Digest Server wrote:

________________________________  Message 24  ___________________________=
_________


Time: 06:25:55 PM PST US
From: "Alex Peterson" <alexpeterson@earthlink.net>
Subject: RE: TruTrak - Was: AeroElectric-List: Re: Glass Panel Layout and=


--> AeroElectric-List message posted by: "Alex Peterson" <alexpeterson@ea=
rthlink.net>


>> Pilots who *think* they understand computers will trust their=20
>> lives to them, and pilots who truly *do* understand computers=20
>> will not.
> =20
>

>Except for those pilots driving cars less than about twenty years old to=
 the
>airport, and who may pull out in front of another car, trusting that the=

>car's computer will keep shoving gas and spark in!


That is an insiduous mistake, Alex.

A) My car has mechanically actuated brakes.

B) I expect the other car to have mechanically actuated brakes.

C) I am able to validate the health of the onboard computer in a very low=
-risk environment before performing the high-risk maneuver.  The engine i=
s running while sitting at the stop light, after all. =20

D) I 'trust' that the engine computer's software is not built on top of a=
 hacked version of DOS3.1 with three different graphic libraries, a widge=
t library, a tftp server, a TCP-IP stack, a general purpose command line =
interpreter, a Java byte-code interpreter and Perl.  Think I sound ridicu=
lous.  I've worked on embedded systems built this way.=20

E) Car makers have huge engineering staffs with salaries amortized over t=
housands if not millions of units.  Staffs that are paid well to do the b=
oring and tedious jobs of software validation.  This job is boring, thank=
less (nobody likes the guy that says the software doesn't work), and suck=
s in general.  I wouldn't do it if it didn't allow me to buy so many airp=
lane parts.

The point is, software ain't software ain't software, anymore than bolts =
is bolts is bolts.  People who would faint at the idea of using a course =
thread bolt from the BigBox Hardware store will happily throw a mission c=
ritical box in their panel without a thought.  Well, actually there is a =
thought.  The thought is, "Those software guys are all so smart.  Just lo=
ok at what Bill Gates and Steve Jobs did in their garages.  This new Supe=
rEFIS is all bright and shiny, with cool graphics and lots of buttons, an=
d if it breaks it will phone home through a satellite connection to the I=
nternet and update itself.  It's going to make my flying so easy."  That =
thought should receive the same esteem that would be received from the gu=
y walking down the bolt section at Lowe's going, "Ooh! Shiny stuff."

Someone asked me if I were endorsing Dynon over BMA.  I'm not; though, my=
 current plan is to purchase a Dynon unit.  I'm endorsing a set of criter=
ia to choosing what software goes in your cockpit.  When evaluating a uni=
t, conisider these questions:

1) Does the level of glitz and functionality correlate with the size of t=
he company and the number of units they expect to sell?  There is no free=
 lunch.  Software has to be validated, and that's expensive, because it i=
s boring, tedious and no one wants to do it.  If the company has three em=
ployees, and the unit has more functionality that a Garmin396 at 1/2 the =
price....you'll probably be a beta tester.

2) Do you get the feeling that the software would be useless without the =
hardware, or is this something ported from a PC game?  General purpose so=
ftware is just that 'general purpose'.  Lots of compromises and obfuscati=
ons are made on the way from here to there.  The idea that the software i=
s tied to the hardware will mean that the software knows the limits of th=
e hardware and can check that data recieved from the hardware is not out =
of bounds.  The more 'stuff' that is inserted between the hardware and th=
e decision making portion of the software, the more chances there are for=
 things to screw up and the more time the processor spends bookeeping dat=
a that has nothing to do with showing you which way is up.  Nothing is mo=
re fun in a development organization that watching the software side sayi=
ng a problem is a hardware issue, while the hardware guys say that a soft=
ware fix is needed.  Those issues occur less and less the closer the two =
are tied together.

3) How often are updates released?  'Update' is an interesting word in th=
e software field.  An update used to mean additional code to add function=
ality for a changing world.  It has slowly been morphed by companies not =
wanting to admit that they have sold you crap-in-a-box.  It now means "a =
self-administered field repair".  If your looking at a car that has a his=
tory of needing a repair once a month, would you drive off the lot with i=
t?  And yet you would call that a 'feature' in a piece of software?  A pi=
ece of software that you expect to tell you which way is up when you can'=
t see the ground?  An EFIS, or any other embedded software, doesn't live =
in a changing world.  It is spec'd to tell up from down.  Up is up and do=
wn is down.  Until those change, an update isn't.  It's a field repair.

4) Are the company representatives 'excited' about new technologies?  You=
 can leave this one off if you'd like.  It's my bias showing.  My experie=
nce is that older engineers tend to view new software 'methodologies' wit=
h a critical eye.  The younger guys tend to jump on the latest software f=
ad with exuberence, generally breaking things that were working and needi=
ng more hardware horsepower to do boot.  I've watched myself get less exu=
berant and more critical as the years have passed.  A representative that=
 is ready to jump in an unproven software technology without careful cons=
ideration of the cost/benefit equation is a red flag for me.  The experie=
nced guys know that it is the same ol' stuff, with a different set of hea=
daches.

I'm not trying to steer anyone away or to a particular unit.  I'm just sa=
ying that the software in the cockpit deserves the same amount of conside=
ration as any other piece of the airplane. =20

Bob K, I'm going to vehemently disagree with the assertion that we can bu=
ild a simple autopilot and have it controlled by PocketPC type device tha=
t we would not rely on.  Humans don't work that way.  Once it is discover=
ed that the PocketPC will fly the plane just dandy on a smooth air day, w=
e start to trust it.  Still works in minor turbulence, we trust it a litt=
le more.  We take it into IMC and it starts to get the leans...unfortunat=
ely, we trust it as it flies us into cumulous granite.  Do not put any so=
ftware in control of your airplane unless you trust it completely from th=
e outset.  I'm not saying a autopilot should not be done, I'm saying that=
 software that can not be fully validated should not be considered.


--=20
         ,|"|"|,              Ernest Christley       |
----=3D=3D=3D<{{(oQo)}}>=3D=3D=3D----    Dyke Delta Builder      |
        o|  d  |o        http://ernest.isa-geek.org  |