Posts by user "syseng68k" [Posts: 30 Total up-votes: 46 Pages: 2]

No system would be designed to parallel two frequency wild generators. The output from each would be rectified to dc and conditioned before application to the load, but could be paralleled at dc level if required for redundancy. These are quarter megawatt generators, where an out of phase connection could shear drive shafts, destroy the drive train, or worse.

NOC40: "almost as soon as the wheels left the ground", Ground to flight mode ?.

C250H: Unlikely, since all sensitive electronics will have inbuilt wide margin regulators and filtering to guarantee function over a range of supply voltages and even transient conditions. Never run from a raw input supply voltages.

FrequentSLF: I would be more suspicious of the hardware that feeds TCMA. Rad Alt sensing could be in error, but possibly more likely is the hardware that senses weight on wheels. May be position sensing microswitches, or perhaps gear oil pressure, but would assume redundancy, eg: two sensors per leg, then some sort of voting logic on the sensor set to find faulty hardware.and make a decision. Doubt if the software is at fault, but is there a delay between sensor output, and command to shutdown the engines ?. Alluded to doubts upthread, but I think the post was deleted. Question: Should TCMA really have the absolute power to auto shutdown engines at all, without some sort of confirmation ?.

tdracer:

"What sort of 'confirmation' do you have in mind - the regulator mandate that resulted in TCMA basically says we can't take credit for the flight crew"

I had just that in mind, as any automated action that could shut down both engines really should have pilot confirmation, imho, but looks like the regulators may not have considered all possible scenarios.

Another question, maybe a complete red herring: Is the TCMA a completely self contained module with it's own processor and software, (possibly the best option) or is it part the FADEC software package, perhaps just a task in a real time multitasking system ?. If the latter, that would open a whole rabbit warren of possibilities.

From all the evidence thus far, it looks like the RAT did deploy, plus other data, which means there was likely a complete electrical power failure. The idea that all four generators and controls would fail at once doesn't make sense, so that doesn't leave much else as the next step.

Feathers McGraw:

Only speaking from experience, but any part of a software system that measures physical quantities or states, will have some sort of filtering to ensure accurate data. For mechanical switches, several reads at time intervals to filter out contact bounce, for example. For voltage measurement, several in a running average might be typical. No experience in transient testing specifically, but might be part of the RFI susceptability / Lightning / power transient testing, which seems to be big business these days, looking at the test gear around. They must be doing that for any safety critical system. Of course, the devil is in the detail, as usual.

DIBO:

That was a partial answer, but still too many variables. Not nitpicking , but if you are trying to trace the source of a possible engine shutdown, you first need to list all the functions that have authority to do that, at source. Then generate a diagram showing all the steps along the path from those sources to the shutdown point. Truth is, we just don't have enough data to do that.

EDML: "No. The throttle position sensors (dual per engine) are part of the FADEC. The throttle position data is not transmitted through the ARINC busses of the aircraft".

To clarify, you are saying that the throttle position sensors are wired directly to the FADEC, and nothng else ?.

JPI33600:

Thanks. From that I assume that the thrust resolver signal is fed to the FADEC alone ?. The reason for the clarification was that it was not clear if the signal is fed to other subsystems, which could affect the analysis.

PanMe: To be fair, if the fault is shown to be from the FADEC, then you can hardly blame Boeing, since both engines and FADEC come from GE.The FADEC presents a command set and interface to whatever controls it, so a possible failure mode could be at that interface, a mismatch and or race condition between the controlling sequence of commands, and the FADEC response to that.

Lead Balloon: "Yet the (a?) patent application for the TCMA addition to the EEC was filed by Boeing."

That sounds right, since it's an airframe related issue, not specific to the engine.

Your other implied question, ie: Is the TCMA software part of the FADEC , or something Boeing designed and built. Or, where is that functionality resident in the system, and who designed and built it ?. Starting to think that this tragedy may have had a far more subtle cause than has been imagined thus far.

Lead Balloon:

The requirement for TCMA may have been specified by Boeing, but that doesn' t tell us who designed and built the solution in this case, though it must have been a collaborative effort between the two parties. Anyway, TCMA may be a red herring, since we still have not defined what, if any, other sources would have authority to issue an engine shutdown command

Lead Balloon:



“The "requirement" for TCMA was "specified" by the FAA. Manufacturers seeking certification of aeronautical products subject to the requirements then had no choice but to design and instal systems that met the FAA's certification requirements”.

I think that has already been established upthread.


“I'm pretty sure it's clear what "sources", other than TCMA systems if any, have "authority to issue an engine shutdown command", though it does depend on what you mean by "engine shutdown".”

I don’t think that is clear at all. The shutdown hypothesis, if true, both engines, makes it likely that they were commanded to do so. While the discussion has centered around the TCMA subsystem, if other subsystems have the ability to do that, they need to be defined and looked at as well.

Somone Somwhere:

"But I am being told elsewhere by someone with an A&P badge that that is not quite the whole story, and that the FADEC PMGs do double-duty as the flight control PMGs."

Is that likely ?. The whole point of the PMG must be to ensure hermeticity of operation of the FADEC, when all else fails. That becomes compromised if the PMG also has a FADEC external load placed on it.

mechpowl:
Thanks for that. That begs the question, if there is overspead protection already, perhaps multiple channels and sensors, why is TCMA needed at all ?. Blanket overspeed protection already covers the underlying requirement, ie: prevention of overspeed, all cases. Seems to be adding complexity for no reason.

JPI33600:

"Dual conflicting inputs"

Limited experience, but the ones seen here were dc motorised rotary valves, with separate motor field windings and toggled limit switches for the open and closed positions. Toggled limit switches ensure that the other side cannot be energised until the first side has reached its limit, and deenergises. Modern systems might use a bit of logic to do the same thing.. Those with long memories, classic cars etc, might remember the old vacuum windscreen wipers, that used a toggled selector valve to change direction at each end of travel. Nothing new under the sun perhaps.

EDLB: Software Revision

That can usually be determined by the software / firmware update history record for the serial number. GE will have that and it can can probably be read in service using local maintenance diagnostic equipment. Definately true for all the embedded product worked with here.

i'm still going with the idea that both engines were commanded to shut down, idle or stop. Reason ?: TBD , not enough data

EXDAC: "Some critical systems are designed with processing "lanes"@

As you say, it would not find algorithmic errors , but it would detect hardware errors. Problem is that three channels are required, best of two approach, since with a two channel system, one can never be sure which one is at fault. I believe Concorde used the three channel approach for some systems.

EDLB: Shutdown.

Excellent summary, but could that command have originated via the data bus, as a message sequence to the FADEC ?. If so, where from ?.

DTA: Switch Movement

Sorry to disagree.

Have a few of that type here, so here's an up close pic of the toggle / cam end. Even applying as much force as possible, the switch does not skip the cam to the alternate position. The toggle must be lifted, and is quite heavily spring loaded. As far as I can see, there is no way that such a switch would change position, other than by lifting the toggle, which is, in fact, the way they are designed to work.