Received-SPF: softfail
 receiver=logan.com; client-ip=216.240.18.37; envelope-from=echristley@nc.rr.com
Message-ID: <4B9E86DE.7010907@nc.rr.com>
Date: Mon, 15 Mar 2010 15:13:34 -0400
From: Ernest Christley <echristley@nc.rr.com>
Reply-To: echristley@nc.rr.com
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Rotary motors in aircraft <flyrotary@lancaironline.net>
Subject: Re: [FlyRotary] Re: Ut-Oh...
References: <list-4166254@logan.com>
In-Reply-To: <list-4166254@logan.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Al Wick wrote:
> As soon as one of these ECU suppliers adds the "Are you sure?" logic, 
> then all of these failures disappear. Pretty simple logic statement. 
> Actually, there are a whole bunch of ways this can be handled. I had 
> to do this type of programming with industrial plc's because these 
> same "oops" were so common. Think about this. If engine has been 
> running for more than 5 minutes, only allow small mixture changes. 
> Never enough to shut down engine. So let's say that 100 will shut down 
> engine, then we only allow a change of 20 each minute.
Staying with your scenario, 100 will shut down the engine, but it takes 
80 to go from climb ROP to leaned for cruise.  Your fix would require 4 
minutes to effect the change.  4 minutes of constant power changes, 
requiring constant pitch trim modifications.  And if you hit the cold 
start by accident, you wouldn't see a drastic and immediate power 
change.  You would see a slow decrease, possibly preceded by a slow 
increase, that would not necessarily tie directly back to the initial 
control change.

Not to belittle your idea for a fix.  It was probably an off-the-cuff 
solution that you haven't spent lots of hours thinking about 
specifically.   I'm just trying to highlight the point that "providing 
assistance" in software quite often means introducing a PITA. 

The design pattern is that powerful controls are presented to the 
operator of the system in order to supply necessary functionality.  This 
creates the delimma of a necessary control opening the system to severe 
problem scenarios in the case of user error.  There are many ways to 
break the delimma.

-One solution is to remove the control, which means the control wasn't 
really necessary in the first place.  This solution does apply to those 
using the EC2 in warmer climates.
-One solution is more user training. 
-One solution is ergonomic enhancements, in this case moving the switch 
close to the start button, which are then both moved physically to an 
area remote from other switches.
-One solution is a design that gets around the need for the control.  
The Megasquirt uses a temperature sensor to enrichen the mixture on a 
cold morning.  (I'll let you know how that works out for me after I get 
my system running.)
-IMHO, the worst of all solutions is a software fix that presents a 
control that behaves differently under varying conditions.  The operator 
has one control that he must correlate with the current situation when 
using.  This situation is would be made worse in this case, since the 
data to correlate with would have to be an abstract number for a 
temperature sensor.

I would first look to eliminate exposing the control to the operator.  
Is it necessary?  Can I get the information I need to turn on cold start 
from existing sensors?  I would then look to ergonomically protect the 
switch.  Remoting the location.  Installing a toggle protector.  My last 
resort would be increased operator training.