Matronics Email Lists :: View topic - Software in the cockpit

Matronics Email Lists
Web Forum Interface to the Matronics Email Lists

Get Email Distribution Too! FAQ Search Memberlist Usergroups Register

Profile Log in to check your private messages Log in

Software in the cockpit

Matronics Email Lists Forum Index -> AeroElectric-List

View previous topic :: View next topic

Author Message

echristley(at)nc.rr.com
Guest

Posted: Tue Jun 27, 2006 7:37 am Post subject: Software in the cockpit

AeroElectric-List Digest Server wrote:

________________________________  Message 24  ____________________________________

Time: 06:25:55 PM PST US

 	  Quote: 	
		  > Pilots who *think* they understand computers will trust their 

> lives to them, and pilots who truly *do* understand computers 

> will not.

 	  Quote: 	
		  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  |

FLYaDIVE(at)aol.com
Guest

Posted: Tue Jun 27, 2006 8:32 am Post subject: Software in the cockpit

In a message dated 6/27/2006 11:41:14 AM Eastern Standard Time,  echristley(at)nc.rr.com writes:

  	  Quote: 	
		  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 	


 

 ==================================================

 Ernest:

  

 O! Boy!  Are you misinformed ....

  

 A - Does your car have an ABS breaking system?

 Then they are computer controlled.

  

 A - Again ... When you take your foot off the gas and slam on the break  what do you thing tries to keep the engine from stalling?  Brakes talking  to the computer and then computer talking to the engine.

  

 B - The ENTIRE action of the car should be actuated by the BRAIN way before  the key hits Start.  But obviously that is not happening.  As for  TRUSTING in other people or their cars... Poor - Bad Idea.

  

 C - WHY the HELL are you doing a "high-risk maneuver"?  

 I fly formation, I get close to my #1 BUT the scariest thing I ever do is  driving.  I KNOW what my #1 is going to do.  I have no freeken idea  what the other drivers around me are going to do of even if they are  SOBER!  Just consider your posted response!

  

 D - I must agree with your 'D' statement.  So why is Bill Gates the  richest man in the world?  He should be sued!

  

 E - As for your 'E' statement ... I guess you never heard of Mandatory  Government Recall on cars.  

  

 Five items are enough to think about.

  

 Barry

 "Chop'd Liver"

chaztuna(at)adelphia.net
Guest

Posted: Tue Jun 27, 2006 9:05 am Post subject: Software in the cockpit

 	  Quote: 	
		  Snipped

Ernest:



O! Boy!  Are you misinformed ....



A - Does your car have an ABS breaking system?

Then they are computer controlled.



A - Again ... When you take your foot off the gas and slam on the 

break what do you thing tries to keep the engine from 

stalling?  Brakes talking to the computer and then computer talking 

to the engine.



snipped



Barry

"Chop'd Liver"


	


Barry,

  You are "almost" correct here. The ABS system has it's own 

computer. Upon starting the engine, the computer does a diagnostic 

test of all parts of the system. If everything is OK , the ABS light 

on the instrument panel will extinguish after 5-10 seconds. The 

system will then operate normally. IF there is a problem, the ABS 

light stays on and the system disables itself. This is the failsafe 

mode. You now have ab circa 1966 to 1980s brake system.



Charlie Kuss

brian

Joined: 02 Jan 2006
Posts: 643
Location: Sacramento, California, USA

Posted: Tue Jun 27, 2006 2:33 pm Post subject: Software in the cockpit

On Jun 27, 2006, at 12:07 PM, FLYaDIVE(at)aol.com (FLYaDIVE(at)aol.com) wrote:

 	  Quote: 	
		     In a message dated 6/27/2006 11:41:14 AM Eastern Standard Time, echristley(at)nc.rr.com (echristley(at)nc.rr.com) writes:

  	  Quote: 	
		  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 	


 

 ==================================================

 Ernest:

  

 O! Boy!  Are you misinformed ....''

	


Well, I don't really think he is. I actually think his point is well taken. I also think that the two of you are approaching this subject orthogonally and not really talking about the same thing.



Ernest's points about mission-critical applications (and a PFD is a mission-critical application in my book) are well taken. There are ways to develop software so as to make it more reliable and less prone to undesired interactions between modules. One of the more successful is to ensure that the software is simple enough that you know all the inputs, all the outputs, and all the possible paths through the code. This makes testing a closed-ended process. If you want a new feature, find a way to isolate it from what you already have so that you minimize any possible interaction. Putting it in a separate box with tight controls over what gets in our out is not a bad idea.



OTOH, Microsoft bases their development on the proliferation of new features, not on ensuring that the existing features are without error. In fact, Microsoft "fixes" software by layering more software on top to mitigate the behavior of underlying software. (I have been wracking my brain to think of a good mechanical analogy but I can't come up with one because mechanical things just aren't made this way.) It is a pretty scary process that precludes Microsoft from being used in mission-critical applications. OTOH, it is great if you want shiny new flashinlitez every few months.



Should we shoot/sue Bill Gates? No. He is making the product that people seem to want. They want features more than they want reliability. Would I fly behind any box that has a Microsoft product running in it? Not on your life.



Now on to the point about things like ABS and computerized engine controls. The interesting thing about these two functions is that they are very well defined functions. The automotive industry also puts them in separate boxes so there is as little interaction between them as possible. But software is complex and sometimes errors do get through and need to be dealt with. Yes, there are recalls that require new code or new boxes to be installed. But if you compare the rate of that to the rate of updates to Windows, you will see several orders of magnitude difference. The automotive code is simpler and better tested. Odds are very good it is right. The odds that Microsoft will issue new, bug-free code is about as close to zero as you can get.



They are different markets.



Now getting back to aviation. People selling low-cost PFDs (that is what we are talking about when we talk about attitude, heading, altitude, and airspeed) face the same problem as Bill Gates. You, the buyer, want as many features as you can get for your dollar. You want it to do all that and be an engine monitor and moving map too. I am with Ernest on this. I want that box to do only what it is supposed to do and have the manufacturer spend a LOT of time ensuring that it does this one, relatively straight-forward feature set flawlessly. You want an engine monitor? Put in another box dedicated to that function. Keep the functions isolated so one can't hose-up the other.



Want an example of why this is good? Ask computer geeks who went to MIT in the '70s about a critical mainframe that would crash every 28 days. Someone even figured out that it occurred at precisely the moment when the phase of the moon changed. (I forget whether it was new moon or full moon.) Can you imagine the consternation of the technical staff to learn that their computer was going to crash whenever the moon was full? Shades of the Wolfman! 



It took months to find the problem. The problem turned out to be a simple little throw-away feature that someone hacked into the real-time clock function of the machine. All the feature did was calculate the phase of the moon. It wasn't documented. It was so simple. It was probably the work of a bored programmer late some night. It is just that the programmer allocated one byte too little for one variable and the software wrote off the end of the variable into someone else's memory causing the operating system to crash. Unfortunately it took things like student registration and payroll with it when it died.



So when you build something on top of something someone else has built you inherit all their bugs into your system. Better to simplify and compartmentalize.

 Brian Lloyd                         361 Catterline Waybrian-yak AT lloyd DOT com          Folsom, CA 95630

+1.916.367.2131 (voice)             +1.270.912.0788 (fax)



I fly because it releases my mind from the tyranny of petty things . . .

— Antoine de Saint-Exupéry

_________________
Brian Lloyd
brian-yak at lloyd dot com
+1.916.367.2131 (voice) +1.270.912.0788 (fax)

I fly because it releases my mind from the tyranny of petty things . . .
- Antoine de Saint-Exupery

mprather(at)spro.net
Guest

Posted: Tue Jun 27, 2006 4:52 pm Post subject: Software in the cockpit

Great analysis..  Just a few embedded comments.

 	  Quote: 	
		   On Jun 27, 2006, at 12:07 PM, FLYaDIVE(at)aol.com wrote:


	


 snip

 	  Quote: 	
		  

 OTOH, Microsoft bases their development on the proliferation of new

 features, not on ensuring that the existing features are without

 error. In fact, Microsoft "fixes" software by layering more software

 on top to mitigate the behavior of underlying software. (I have been

 wracking my brain to think of a good mechanical analogy but I can't

 come up with one because mechanical things just aren't made this


	


snip



Sure...  Lots of things are made this way.  How about fuel delivery

controlls on cars from about 1974 to about 1990 (year varying by brand and

model)?  Smog limits were imposed.  Manufactures mostly chose to do the

minimum bandaid fix to meet the latest standard.  This led to labrynths of

vacuum lines, some of which seemed to go nowhere..  Instead of doing a

complete redesign to manage fuel flow vs. airflow precisely, they said

"well, if we mechanically compensate for altitude a little, and add a

little bit of exhaust to the intake once in a while, we'll pass the latest

criteria."  Kept glueing things on until system reliability was really

pretty horrible after a few thousand miles.



 	  Quote: 	
		   It took months to find the problem. The problem turned out to be a

 simple little throw-away feature that someone hacked into the real-

 time clock function of the machine. All the feature did was calculate

 the phase of the moon. It wasn't documented. It was so simple. It was

 probably the work of a bored programmer late some night. It is just

 that the programmer allocated one byte too little for one variable

 and the software wrote off the end of the variable into someone

 else's memory causing the operating system to crash. Unfortunately it

 took things like student registration and payroll with it when it died.




	


That's a great story..  Before the days where a kernel didn't allow

segmentation violations..  Today, we pretty much have to live with

software that mallocs, but doesn't free properly, but at least the program

can't usually crash the kernel.  They system usually just slowly runs out

of real memory, then swap..

 	  Quote: 	
		   Brian Lloyd                         361 Catterline Way

 brian-yak AT lloyd DOT com          Folsom, CA 95630

 +1.916.367.2131 (voice)             +1.270.912.0788 (fax)



 I fly because it releases my mind from the tyranny of petty things . . .

 — Antoine de Saint-Exupéry

mthomson(at)showmeproduct
Guest

Posted: Tue Jun 27, 2006 5:37 pm Post subject: Software in the cockpit

Very well put.

Ex-President, Blue Mountain Avionics! 



--

rv10(at)tpg.com.au
Guest

Posted: Wed Jun 28, 2006 1:42 am Post subject: Software in the cockpit

Brian Lloyd wrote:

 	  Quote: 	
		   Should we shoot/sue Bill Gates? No. He is making the product that people 

 seem to want. They want features more than they want reliability. Would 

 I fly behind any box that has a Microsoft product running in it? Not on 

 your life.


	


I agree completely.



You DO realise than the Garmin MX20 runs on a Windows NT Kernel, don't 

you?! 



Have fun,

Scott Lewis

RV-10 40172



do not archive

nuckollsr(at)cox.net
Guest

Posted: Wed Jun 28, 2006 6:29 am Post subject: Software in the cockpit

 	  Quote: 	
		  



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


	


     . . . an aviate issue



 	  Quote: 	
		  ...unfortunately, we trust it

as it flies us into cumulous granite.


	


    . . . a navigate issue



 	  Quote: 	
		  .  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.


	


    When you're relying on any combination of hardware/software, there

    needs to be a means by which failure to do the intended task can

    be monitored and annunciated immediately. For the dual, simple

    a/p to offer a high order of confidence (meaning that you intend

    never to touch the controls in clouds) then both a/p are powered

    up and providing course/steering data but only one motor is energized.

    You take course data from both autopilots and compare with with

    course data from a third (panel mounted nav) system. When you

    say "hold course", a $1.00 processor compares three course

    data values with the stored value of course-to-make-good and lights

    a light should any course data value vary from preset by some

    handy number, like +/-5 degrees. You also light a light when

    there is disagreement between any two sources by more than

    5 degrees and finally, light a light should any signal

    disappear (the most likely failure mode).



    This level of software sophistication is easy to validate

    and separates the aviate task from the navigate task.

    When you plug much more sophisticated software and hardware

    in to steer one of the autopilots, the light will come on

    any time the dish-washer makes a course change whereupon

    you can hit the button to store a new course-to-make good

    that is watched by the other two sources on the same

    $1 jelly-bean processor. The same event light tells you

    when the autopilot-in-command wanders into the weeds.



    The segmented, fire-walled approach encourages

    OBAM aircraft world development of convenience while

    keeping the important hardware/software free of

    inevitable variability that pops up in any development

    program. The policy and procedure protocols for

    software development in certified aviation have

    fertilized huge organizations that are prone to

    unintended consequence just because of their size

    and complexity. Honeywell has become the "microsoft"

    of GA software. But devout discipleship at the

    Altar of Validation doesn't keep them from stepping

    into the occasional gopher hole.



    I'm not suggesting that "fully validated" software

    is a bad or unnecessary goal to strive for . . . but

    in the OBAM aircraft world, it's unlikely that were going to see

    a DO-178, Level A qualification on ANY offerings.

    I'll suggest that building a firewall between simple

    save-your-life and the more complex but convenient,

    dish-washing-silver-polishing system is easy, prudent

    and greatly reduces risks.



    Bob . . .

ainut(at)hiwaay.net
Guest

Posted: Wed Jun 28, 2006 10:14 am Post subject: Software in the cockpit

Very well said, Robert.



David M.

software weenie who is writing his own personal version of FADEC, 

autopilot, highway-in-the-sky, and etc.  

Of course, it's taking me a very long time.

Robert L. Nuckolls, III wrote:



 	  Quote: 	
		   

 <nuckollsr(at)cox.net>

 

 

> 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

 

 

     . . . an aviate issue

 

> ...unfortunately, we trust it

> as it flies us into cumulous granite.

 

 

    . . . a navigate issue

 

> .  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.

 

 

    When you're relying on any combination of hardware/software, there

    needs to be a means by which failure to do the intended task can

    be monitored and annunciated immediately. For the dual, simple

    a/p to offer a high order of confidence (meaning that you intend

  <<<snip>>>

brian

Joined: 02 Jan 2006
Posts: 643
Location: Sacramento, California, USA

Posted: Wed Jun 28, 2006 7:25 pm Post subject: Software in the cockpit

On Jun 28, 2006, at 5:32 AM, Scott Lewis wrote:

 	  Quote: 	
		  --> AeroElectric-List message posted by: Scott Lewis <rv10(at)tpg.com.au (rv10(at)tpg.com.au)>

Brian Lloyd wrote:

  	  Quote: 	
		  Should we shoot/sue Bill Gates? No. He is making the product that people seem to want. They want features more than they want reliability. Would I fly behind any box that has a Microsoft product running in it? Not on your life.

 	




I agree completely.

You DO realise than the Garmin MX20 runs on a Windows NT Kernel, don't you?! 

	


Damn. No chance of buying one of those then.

 Brian Lloyd                         361 Catterline Waybrian-yak AT lloyd DOT com          Folsom, CA 95630

+1.916.367.2131 (voice)             +1.270.912.0788 (fax)



I fly because it releases my mind from the tyranny of petty things . . .

— Antoine de Saint-Exupéry

glastar(at)gmx.net
Guest

Posted: Wed Jun 28, 2006 9:29 pm Post subject: Software in the cockpit

It's true,



but it is the Windows Kernel only without any gimmicks like Windows and 

not overloaded with all this 1 million function which have bugs to the 

end of the road.



The kernel (I thinks it's even 3.51) is quite stable as it has only 

basic functionality and it is tested out also very well as well as used 

in many other processor driven parts. What is full of bugs is the 

overhead put on top, so I would (even if I'm not a Gates fan) trust on 

that product, as well as it was done from Apollo which have a very good 

reputation.



br Werner (however only my 0.02$)



Brian Lloyd wrote:



 	  Quote: 	
		  

 On Jun 28, 2006, at 5:32 AM, Scott Lewis wrote:



> 

> <mailto:rv10(at)tpg.com.au>>

>

> Brian Lloyd wrote:

>

>> Should we shoot/sue Bill Gates? No. He is making the product that 

>> people seem to want. They want features more than they want 

>> reliability. Would I fly behind any box that has a Microsoft product 

>> running in it? Not on your life.

> I agree completely.

>

> You DO realise than the Garmin MX20 runs on a Windows NT Kernel, 

> don't you?! 

 Damn. No chance of buying one of those then.

 Brian Lloyd                         361 Catterline Way

 brian-yak AT lloyd DOT com          Folsom, CA 95630

 +1.916.367.2131 (voice)             +1.270.912.0788 (fax)



 I fly because it releases my mind from the tyranny of petty things . . .

 — Antoine de Saint-Exupéry

dean.psiropoulos(at)veriz
Guest

Posted: Wed Jun 28, 2006 10:05 pm Post subject: Software in the cockpit

While I agree that software can be made more robust and less "risky" using

DO-178B level A style processes, software is still software, there are just

too many variables in all but the most simple systems for there not to be

defects present when they shoot the engineers and go into production.  That

doesn't necessarily mean the software is unsafe but it's not like the "good

old days" of mechanical analog equipment that could be characterized

completely with every nuance documented (software defects crop up over time

and it often takes a specific "line up" of the planets before the problem

rears its ugly head:-).  In the instrument panel I built for my RV-6A I

installed a Dynon EFIS D-10 as my primary instrument with old style steam

gauge Airspeed, Turn Coordinator and Altimeter for backup and cross check.

My philosophy on this panel was to add some basic steam gauges as back-up

because I want to be able to fly the bird IFR in a pinch and am not totally

comfortable relying on a software driven instrument exclusively. 



As a software safety engineer with a major aerospace company, I can tell you

the kinds of things that go haywire in software systems are numerous.  No

matter how much attention you pay to development and coding or how much

testing you do, things still show up long after certification when you least

expect.  My boss found that out first hand a few months ago when he turned

the key on his Mercedes SLK 320 sports car and the software controlled

throttle immediately went to wide open. The car jumped 15 feet and then the

computer shut down the whole works, after which the car would not run at

all.  Luckily it was after hours in the company parking lot and there were

no cars or people near by but he just cringes at the thought of this

happening on a busy street or a mall parking lot.   Needless to say, he

traded the car in almost immediately.  NEVER, EVER buy a car with a computer

controlled throttle.  I think the car companies that embrace this set up

(likely just for the "Gee Whiz" factor and bragging rights) are going to be

very, very sorry, no matter how much DO-178B Level A development they do.

Their trial lawyers are going to be very busy defending that decision for

decades.)



Dean Psiropoulos

RV-6A N197DM

Wiring the "beast"



_________________________Original Message _____________________________

Ernest's points about mission-critical applications (and a PFD is a

mission-critical application in my book) are well taken. There are ways to

develop software so as to make it more reliable and less prone to undesired

interactions between modules. One of the more successful is to ensure that

the software is simple enough that you know all the inputs, all the outputs,

and all the possible paths through the code. This makes testing a

closed-ended process. If you want a new feature, find a way to isolate it

from what you already have so that you minimize any possible interaction.

Putting it in a separate box with tight controls over what gets in our out

is not a  

bad idea.



Brian Lloyd                         361 Catterline Way

brian-yak AT lloyd DOT com          Folsom, CA 95630

+1.916.367.2131 (voice)             +1.270.912.0788 (fax)

brian

Joined: 02 Jan 2006
Posts: 643
Location: Sacramento, California, USA

Posted: Thu Jun 29, 2006 1:35 am Post subject: Software in the cockpit

On Jun 29, 2006, at 1:22 AM, Werner Schneider wrote:

 	  Quote: 	
		  --> AeroElectric-List message posted by: Werner Schneider <glastar(at)gmx.net (glastar(at)gmx.net)>

It's true,

but it is the Windows Kernel only without any gimmicks like Windows and not overloaded with all this 1 million function which have bugs to the end of the road.

	


I suspected that was probably the case. Windows NT had a lot of promise in the beginning. (It was originally written by IBM and not Microsoft. Originally it was called OS2.) The basic microkernel architecture is a good one in that it embodies the concept I was espousing -- small, simple, and testable modules that have well defined interfaces with little interaction. I have worked with several and prefer them to monolithic kernels like Linux. But any good thing can be made bad as Windows XP demonstrates.



 	  Quote: 	
		  The kernel (I thinks it's even 3.51) is quite stable as it has only basic functionality and it is tested out also very well as well as used in many other processor driven parts. What is full of bugs is the overhead put on top, so I would (even if I'm not a Gates fan) trust on that product, as well as it was done from Apollo which have a very good reputation.

	


I agree. I was just joking about the MX-20. (I should have put in a smilie in my original post.) It seems to be a reliable device.



It is interesting to see that the kind of problem we were talking about, i.e. "creeping featurism" increasing complexity and reducing reliability, has struck the certified EFIS world. The Garmin 1000 has been struck with a plethora of software updates reminiscent of Windows. A couple of avionics shops I have spoken/dealt with have complained to me of the problems they have had with that unit. This brings us back to the original discussion about the desirability of dedicated devices with clearly defined and straightforward functionality.



 Brian Lloyd                         361 Catterline Waybrian-yak AT lloyd DOT com          Folsom, CA 95630

+1.916.367.2131 (voice)             +1.270.912.0788 (fax)



I fly because it releases my mind from the tyranny of petty things . . .

— Antoine de Saint-Exupéry

etekberg(at)gmail.com
Guest

Posted: Thu Jun 29, 2006 4:39 am Post subject: Software in the cockpit

It is possible to make a software system safe.  Major avionics companies do it all the time.  There are software assurance standards as well for "how safe" it needs to be.  The safter the software needs to be the more expensive it is to make. 

  

 Same goes for the ground and space based navaids.  Ever flown an ILS approach in IMC?  If you did, chances are you just trusted your life to a computer.  The FAA evaluates all safety critical navaids for what is called Hazardous Misleading Information (HMI).  HMI is when the ILS tells your plane that it is 500 AGL when it is really 200 AGL and about to fly into a hill. 

  

 I love the experimental EFIS's out there and plan on having a few in my plane.  However, I don't trust these companies or their products any farther than I can throw them.  Just assume that the device is going give you HMI, and have backups (more than one) that you can use to validate the device in IMC. 

  

 do not archive

  

 Eric

 RV-10 (hopefully someday)

David(at)ChalmersFamily.c
Guest

Posted: Thu Jun 29, 2006 5:53 am Post subject: Software in the cockpit

This  has nothing to do with electrics but I worked on both OS/2 and Windows NT at  Microsoft and Windows NT was not based on OS/2 and not written by IBM. Windows  NT was new code - a clean sheet design and very stable. Of course they later  slapped all the old Windows code on top of it which dragged it  down. 

  

 Dave  Chalmers

  

 [quote]   --

brian

Joined: 02 Jan 2006
Posts: 643
Location: Sacramento, California, USA

Posted: Thu Jun 29, 2006 10:10 am Post subject: Software in the cockpit

On Jun 29, 2006, at 8:32 AM, Eric Ekberg wrote:

 	  Quote: 	
		  It is possible to make a software system safe.  Major avionics companies do it all the time.  There are software assurance standards as well for "how safe" it needs to be.  The safter the software needs to be the more expensive it is to make.



	


I agree with all your points.



 	  Quote: 	
		   

 Same goes for the ground and space based navaids.  Ever flown an ILS approach in IMC?  If you did, chances are you just trusted your life to a computer.  The FAA evaluates all safety critical navaids for what is called Hazardous Misleading Information (HMI).  HMI is when the ILS tells your plane that it is 500 AGL when it is really 200 AGL and about to fly into a hill.

	


The beauty of ILS is that the LOC and GS signals are generated by their respective antennas. (Phased array.) The transmitters are very simple continuous-wave, AM modulated (basically 1930's radio technology) and either work or they don't. There is no computer and no software involved. That is why ILS is so reliable. About the worst thing that can happen is if the pilot inadvertently intercepts the GS too high and tries to follow a side lobe. This is pretty obvious because it happens way too high but I understand that people have done it.



I suppose someone could cut one of the feedlines to the antenna array but I suspect that without one or the other of the two tones the receiver uses to determine whether you are in the blue or yellow sector, the receiver would flag the signal. Again, no computer involved. (Well, there is the DSP in my SL-30 which I dearly love.)



 	  Quote: 	
		   

 I love the experimental EFIS's out there and plan on having a few in my plane.  However, I don't trust these companies or their products any farther than I can throw them.  Just assume that the device is going give you HMI, and have backups (more than one) that you can use to validate the device in IMC.

	


I actually expect to trust my PFD at least as much as I trust my iron gyros. I know that it has the potential to be much more reliable (several orders of magnitude), modulo the quality of the software. Think about it -- while we are talking about how bad the software can be, I think most of us who have flown significant IFR have had to fly with a failed gyro. That said, I think that I will have an ASI, an altimeter, and an electromechanical T&B in the panel too. But then there is that neat little instrument from Tru-Trak ... <sigh>

 

 Brian Lloyd                         361 Catterline Waybrian-yak AT lloyd DOT com          Folsom, CA 95630

+1.916.367.2131 (voice)             +1.270.912.0788 (fax)



I fly because it releases my mind from the tyranny of petty things . . .

— Antoine de Saint-Exupéry

Kellym

Joined: 10 Jan 2006
Posts: 1700
Location: Sun Lakes AZ

Posted: Thu Jun 29, 2006 10:50 am Post subject: Software in the cockpit

Was not the original NT largely based on the Unix code rather than a  

clean sheet?



Quoting David Chalmers <David(at)ChalmersFamily.com>:



[quote] This has nothing to do with electrics but I worked on both OS/2 and   

 Windows NT at Microsoft and Windows NT was not based on OS/2 and not  

  written by IBM. Windows NT was new code - a clean sheet design and   

 very stable. Of course they later slapped all the old Windows code   

 on top of it which dragged it down.



 Dave Chalmers

 --

_________________
Kelly McMullen
A&P/IA, EAA Tech Counselor # 5286
KCHD

Kellym

Joined: 10 Jan 2006
Posts: 1700
Location: Sun Lakes AZ

Posted: Thu Jun 29, 2006 12:00 pm Post subject: Software in the cockpit

Right. The FAA simply installs a monitoring receiver at a fixed  

location from the transmitter, and as long as the signal gives a  

result within tolerance on an analog type meter, the ILS stays  

on-line. If it doesn't get a good signal, it trips an alarm at the  

monitoring facility...usually the tower cab, and they can flip a  

switch to shut down the transmitter. They are sensitive enough that  

snow of a certain depth in front of the transmit antenna, espec glide  

slope will cause the system to alarm.

Ex-tower controller

Quoting Brian Lloyd <brian-yak(at)lloyd.com>:

 	  Quote: 	
		   On Jun 29, 2006, at 8:32 AM, Eric Ekberg wrote:

> It is possible to make a software system safe.  Major avionics    

> companies do it all the time.  There are software assurance    

> standards as well for "how safe" it needs to be.  The safter the    

> software needs to be the more expensive it is to make.

 I agree with all your points.

> Same goes for the ground and space based navaids.  Ever flown an    

> ILS approach in IMC?  If you did, chances are you just trusted your  

>   life to a computer.  The FAA evaluates all safety critical  

> navaids   for what is called Hazardous Misleading Information  

> (HMI).  HMI is   when the ILS tells your plane that it is 500 AGL  

> when it is really   200 AGL and about to fly into a hill.

 The beauty of ILS is that the LOC and GS signals are generated by

 their respective antennas. (Phased array.) The transmitters are very

 simple continuous-wave, AM modulated (basically 1930's radio

 technology) and either work or they don't. There is no computer and  no

 software involved. That is why ILS is so reliable. About the worst

 thing that can happen is if the pilot inadvertently intercepts the GS

 too high and tries to follow a side lobe. This is pretty obvious

 because it happens way too high but I understand that people have  done

 it.

 I suppose someone could cut one of the feedlines to the antenna array

 but I suspect that without one or the other of the two tones the

 receiver uses to determine whether you are in the blue or yellow

 sector, the receiver would flag the signal. Again, no computer

 involved. (Well, there is the DSP in my SL-30 which I dearly love.)

_________________
Kelly McMullen
A&P/IA, EAA Tech Counselor # 5286
KCHD

jclarkmail(at)gmail.com
Guest

Posted: Thu Jun 29, 2006 9:25 pm Post subject: Software in the cockpit

Comment below ...



On 6/29/06, Brian Lloyd <brian-yak(at)lloyd.com (brian-yak(at)lloyd.com)> wrote: 	  Quote: 	
		   

On Jun 29, 2006, at 1:22 AM, Werner Schneider wrote:



<<SNIP>>

	
 



 	  Quote: 	
		   I suspected that was probably the case. Windows NT had a lot of promise in the beginning. (It was originally written by IBM and not Microsoft. Originally it was called OS2.) 

	
 

<<SNIP>> 

NT ("New Technology") and OS/2 are/were very different. 



As I recall  ... NT was influenced/designed/developed more so by Microsoft people from DEC (Digital Equipment Corporation for the young bloods) than from IBM. THe IBM product was **competition**!!!!.  I won't try to go into the history here. 



James

morid(at)northland.lib.mi
Guest

Posted: Fri Jun 30, 2006 2:34 am Post subject: Software in the cockpit

        I  know this is way off list parameters, but from an operators standpoint, having  had pretty much everything since the Commodore 64 in the mid 80s, I just don't  understand all this about the problems with Windows.  Even though it's a  bit bulky, XP has operated flawlessly for me since it first hit the  streets.  What exactly is it about it that's so bad?  No, I'm not a  dealer, geek, nor even a loyalist.  Just curious.

 Thanks,

 Deke

  

  

 I suspected that was probably the case. Windows NT had a lot of   

promise in the beginning. (It was originally written by IBM and not   

Microsoft. Originally it was called OS2.) The basic microkernel   

architecture is a good one in that it embodies the concept I was   

espousing -- small, simple, and testable modules that have well   

defined interfaces with little interaction. I have worked with   

several and prefer them to monolithic kernels like Linux. But any   

good thing can be made bad as Windows XP demonstrates.



 	  Quote: 	
		   The  kernel (I thinks it's even 3.51) is quite stable as it has only   


	


 	  Quote: 	
		   basic functionality and it is tested out also very well as well  as  

 used in many other processor driven parts. What is full of  bugs is  

 the overhead put on top, so I would (even if I'm not a  Gates fan)  

 trust on that product, as well as it was done from  Apollo which  

 have a very good reputation.


	


I agree. I was  just joking about the MX-20. (I should have put in a  

smilie in my  original post.) It seems to be a reliable device.



It is interesting to  see that the kind of problem we were talking  

about, i.e. "creeping  featurism" increasing complexity and reducing  

reliability, has struck  the certified EFIS world. The Garmin 1000 has  



been struck with a  plethora of software updates reminiscent of  

Windows. A couple of  avionics shops I have spoken/dealt with have  

complained to me of the  problems they have had with that unit. This  

brings us back to the  original discussion about the desirability of  

dedicated devices with  clearly defined and straightforward  

functionality.



Brian  Lloyd                          361 Catterline Way

brian-yak AT lloyd DOT  com          Folsom, CA  95630

+1.916.367.2131  (voice)              +1.270.912.0788 (fax)

Display posts from previous:

	Matronics Email Lists Forum Index -> AeroElectric-List	All times are GMT - 8 Hours
Page 1 of 1

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum