Re: ECM for 4cyl &Altitude (was 747 & 4cyls)

[Garfield Willis <garwillis@msn.com>]

On Wed, 23 Aug 2000 15:31:37 -0400, "Patrick G. Moore" <patm@cais.com>
wrote:

>Seems like a good look at what inputs are
>absolutely essential for the ECM to run
>the engine is in order.  (ie. nothing happens
>without crank sensor signal)  Then, what
>can the ECM will deal with by using some
>default if out of range.  This will, of course,
>ultimately depend on which bin you choose.  I think
>most all of them use similar strategy, but I would
>feel better with one which was completely known
>for this analysis.

Yup, zactly. The primary/essential sensors are CPS and MAP|TPS. I say
"or" because if the MAP fails, the ecm will revert to alpha-N via use
of TPS & CPS, if I understand correctly. I presume this is common on
most all GM S-B ecms(?). That's why I mentioned earlier we'd likely
adopt a sensor-sharing policy where non-criticals were shared (e.g.
temp sensors), and criticals like CPS & MAP would be redundant. We'd
like to rely less than usual on TPS, since in a high-vibration
environment like XA, mechanical TPSs are somewhat less reliable than
say all-electronic gizmos like current MAP sensors. Pots & wipers are
always less desirable as sensors in aviation environs. Probly true in
marine apps too.

>The point is, it seems like it may not be hard to
>use the check engine light output to signal a switch
>to a redundant ECM.  At 5000' yeah, you've got some
>time to mess around, but at less than 1000', you're
>landing (spray pilot in WAY previous life).  An ALDL
>monitor like turbolink on a small dash display would
>be cool too.  You might add your own input limit
>watching code in the ECM for safety.  Or the ALDL monitor
>could warn you to manually switch.

Yes, schemes like this for "automagic" switch-over have been discussed
in our XA group, but by far the most reliable "interlock", which
Bendix actually had a patent on (long since expired) for redundant
fuel injection, would be for aircraft, a sudden drop in rpm. If you're
going to mess with automatic switch-over, you're gonna do that mainly
to cover yourself during TO/L, when you don't have leisure to manually
switch to backups and recycle the starter. So you have to get the
backups switched in and working before the engine has time to spin
down to the point of needing to be restarted. (I can just hear the
mental gears turning; yes, dual fuel pumps & fuel-distribution is
common in XA & GA also).

>I know you want to avoid redundant ECMs for the wiring
>nightmare.  But how else ya gonna fire those plugs? Still
>need some sort of crank sensor even with fixed timing.
>I think a redundant ECM, whose critical sensors were
>duplicated, and non-critical possibly shared, may
>ultimately be best if not easiest.

Actually, we don't "want to avoid redundant ecms", we just want to
avoid doing it in a way that creates a wiring/switching nightmare.
This we have already worked out. We do indeed have dual CPSs to run
two independant DIS systems, which then get joined at the coils to
fire one set of plugs. These redundant DISs are then connected to
their respective ECMs. The thing we've strained to avoid is this idea
of switching in/out the ecms via some N-pole switch. We'd rather have
them both RUNNING in active redundancy, which is the safest mode
during critical low-altitude ops like TO or landing, and we do have a
way to do this now. Perhaps we need to discuss that shortly, since it
keeps coming up.

>Couldn't you make a fairly short adapter that would
>just passively splice most of the non-critical inputs.

Yes, exactly the plan on the shared inputs.

I'll take a stab at these ?s...

>1.) How long does it take for most of these units
>to perform self test and proceed to run the engine?

Well, quick enough to be on the order of key turned to start pos. If
you have to manually switch in/out an ecm, you're gonna have a restart
anyway. But you may have some other reason for askiing this?

>2.) Will it even recover properly if powered up
>to an already spinning engine? (I think yes.)

I think sure. The fact that you have many CPS pulses following
powerdown of the ecm during shutdown suggests you can also have them
before powerup; it would look just like startup, albeit a fast one!

>3.) If an unpowered ECM is seeing injector pulses
>on its drivers from a passively connected "other
>ECM" will it hurt them?

Generally, INJ and IGN drivers are low-side drivers that are off if
the ecm that owns them is in an unpowered state. However, in the
scheme we have developed for running two ecms in active redundancy,
this isn't an issue; I'll explain how/why when we discuss that scheme
further. For manual switching in/out tho, I think you're fine to have
one powered down and then bring the other one up, but like I said, we
don't plan on doing it that way.

>4.) Would it be possible to run both at the same
>time on the same sensor inputs and just switch
>the 4 injector outputs and the DIS output line
>with some sort of relays? (This would be best
>because you would know if your backup had a
>problem before you needed it.)

That's also been considered; but you end up having to switch out
grounds, if you're dealing with low-side final drivers (you have to
have some way to interrupt a short), and this is a definite no-no and
hazardous to the electrics. If failure modes for both the INJ & IGN
drivers were *only* opens, then theoretically you could even run two
*identical* ecms in simple parallelism (not even need switching), and
the outputs would simply "negative OR" in a logic sense, but reality
is never quite that simple, and after going thru the failure modes if
one of those drivers shorts, it starts to get messy and problematic.
Killing half the jugs from a waste-fire driver shorting and rendering
it's backup ineffective might give acceptable power levels for auto
limping, but not for aircraft.

As you'll see when we get into how we do the active dual-redundancy,
we can take advantage of a very nice difference between road vehicles
and aircraft; namely, the possibility of being stuck at 100% power is
a perfectly safe and useable failsoft mode for us, whereas in autos,
that would not be so. One of the possible failure modes in our
active-redundant scheme is for the engine to be stuck in WOT/max power
fueling, and this turns out is a perfectly acceptable failure mode for
XA.

And as always, it's appropriate to ask the sanity-check question of:
are the controllers so reliable that this level of redundancy is
really overkill and ADDING complexity that could decrease overall
reliability? We leave those kinda gut-feel questions to our individual
builders, and simply try to work out solutions amongst ourselves,
helping each other to achieve their own individual goals/plans. So if
one guy's comfy with a single controller that's been well checked/thot
out, or another guy's not comfy without full active redundant ecms,
while some in between are happy with a simple single backup TBI-style
manually switched in, then we got all of us covered. That way we avoid
"my dog's better than your dog" pissing-match futility in the group.
We learned this better approach the hard way, BTW. It adds to the
range of options you have to cover during development of solutions,
but it keeps most everybody happy to help each other; and in
distributed development via the net, leaving each person the freedom
and flexibility of their own tradeoffs is key to getting and keeping
the level of talent we enjoy in our group.

Gar


----------------------------------------------------------------------------
To unsubscribe from gmecm, send "unsubscribe gmecm" (without the quotes)
in the body of a message (not the subject) to majordomo@lists.diy-efi.org