Received-SPF: softfail
 receiver=logan.com; client-ip=64.102.122.148; envelope-from=echristley@nc.rr.com
Message-ID: <439600CC.6080906@nc.rr.com>
Date: Tue, 06 Dec 2005 16:21:16 -0500
From: Ernest Christley <echristley@nc.rr.com>
Reply-To: echristley@nc.rr.com
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
MIME-Version: 1.0
To: Rotary motors in aircraft <flyrotary@lancaironline.net>
Subject: Re: [FlyRotary] Re: Intersting flight
References: <list-864978@logan.com>
In-Reply-To: <list-864978@logan.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tracy Crook wrote:

> Al is of course correct about the mathematical chances of failure on 
> the SYSTEM but I think Ed was referring to the increased chances of 
> the human involved to deal with the increased complexity.  I have seen 
> more instances of this than I have actual hardware failures.  Training 
> on the system is of vital importance when the system is more complex. 
>  
> Tracy Crook


I know a lot of designers don't do it, but I like the mindset that the 
operator is a component of the system.  A very vital, inseperable, and 
(sometimes*) unmodifiable component.  One that must be designed around, 
but can never be designed away.  How WidgetA interfaces to WidgetB is 
just as important as how each interfaces to the nut holding the stick.  
People will spend hours to make sure that all the widgets aren't 
overstressed, and not blink an eye at giving the system processor one 
more task.  I invite everyone to take any single modification they've 
made and analyze it from the viewpoint of how much of the pilot's time 
will it require under situation A, B, C, and "Oh, $H17"


*I know...I could stand to lose a few pounds and get a little smarter, 
but still...

-- 
         ,|"|"|,                                    |
----===<{{(oQo)}}>===----        Dyke Delta         |
        o|  d  |o          www.ernest.isa-geek.org  |