|
|
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@earthlink.net>
Pilots who *think* they understand computers will trust their lives to them, and pilots who truly *do* understand computers will not.
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 is running while sitting at the stop light, after all. 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 widget library, a tftp server, a TCP-IP stack, a general purpose command line interpreter, a Java byte-code interpreter and Perl. Think I sound ridiculous. I've worked on embedded systems built this way. E) Car makers have huge engineering staffs with salaries amortized over thousands if not millions of units. Staffs that are paid well to do the boring and tedious jobs of software validation. This job is boring, thankless (nobody likes the guy that says the software doesn't work), and sucks in general. I wouldn't do it if it didn't allow me to buy so many airplane 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 critical box in their panel without a thought. Well, actually there is a thought. The thought is, "Those software guys are all so smart. Just look at what Bill Gates and Steve Jobs did in their garages. This new SuperEFIS is all bright and shiny, with cool graphics and lots of buttons, and if it breaks it will phone home through a satellite connection to the Internet 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 guy 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 criteria to choosing what software goes in your cockpit. When evaluating a unit, conisider these questions:
1) Does the level of glitz and functionality correlate with the size of the 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 is boring, tedious and no one wants to do it. If the company has three employees, 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 software is just that 'general purpose'. Lots of compromises and obfuscations are made on the way from here to there. The idea that the software is tied to the hardware will mean that the software knows the limits of the 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 the decision making portion of the software, the more chances there are for things to screw up and the more time the processor spends bookeeping data that has nothing to do with showing you which way is up. Nothing is more fun in a development organization that watching the software side saying a problem is a hardware issue, while the hardware guys say that a software 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 the software field. An update used to mean additional code to add functionality 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 history of needing a repair once a month, would you drive off the lot with it? And yet you would call that a 'feature' in a piece of software? A piece 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 down 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 experience is that older engineers tend to view new software 'methodologies' with a critical eye. The younger guys tend to jump on the latest software fad with exuberence, generally breaking things that were working and needing more hardware horsepower to do boot. I've watched myself get less exuberant and more critical as the years have passed. A representative that is ready to jump in an unproven software technology without careful consideration of the cost/benefit equation is a red flag for me. The experienced guys know that it is the same ol' stuff, with a different set of headaches.
I'm not trying to steer anyone away or to a particular unit. I'm just saying that the software in the cockpit deserves the same amount of consideration as any other piece of the airplane. Bob K, I'm going to vehemently disagree with the assertion that we can build a simple autopilot and have it controlled by PocketPC type device that we would not rely on. Humans don't work that way. Once it is discovered that the PocketPC will fly the plane just dandy on a smooth air day, we start to trust it. Still works in minor turbulence, we trust it a little more. We take it into IMC and it starts to get the leans...unfortunately, we trust it as it flies us into cumulous granite. Do not put any software in control of your airplane unless you trust it completely from the 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.
--
,|"|"|, Ernest Christley |
----===<{{(oQo)}}>===---- Dyke Delta Builder |
o| d |o http://ernest.isa-geek.org |
|
|