Posts about: "ARINC" [Posts: 14 Pages: 1]

Thanks for posting this. I read it quickly and glanced at the drawings, which are adequate for the patent application but not nearly adequate to understand the system in any depth.

I note that, unless I missed it, the patent application doesn't address a mechanism for determining whether an aircraft is actually on the ground. I suppose that will depend on some of those "several other digital inputs."

. Emphasis added.

I'm still looking for identification of the relevant inputs for TCMA on the GEnx-1B. If anyone has suggestions, please share.

I preface this post by acknowledging all the previous posts in this, and the now-closed thread, about the TCMA, in particular the excellent posts by tdracer. (Ditto the noise analyses by Kraftstoffvondesibel and First Principal.)

I also note that the primary source of the information on which I’m basing my post is the content of Boeing’s patent application which, of course, does not contain any of the actual wiring diagrams or modification details of the TCMA, even assuming it has been implemented. (I understand from the now-closed thread, that there is an unresolved question as to whether a petition for an exemption from the TCMA requirement had been successful.)

The point of my post is to get other’s thoughts on one of the design principles of the TCMA system proposed in the patent application.

The ostensibly simple and elegant concept is described in the schematic of the system at figure 1 of the patent application. A copy of figure 1 is below.

The TCMA is the part of the schematic inside the dotted box numbered 16 , sitting with the EEC (others would call it the FADEC) in the solid box numbered 18 .

The heart of the TCMA comprises two switch relays, numbered 22 and 28 in the schematic, wired in series. Each of those switch relays is controlled by its own, dedicated engine control malfunction software, identified as the blobs numbered 130 . (The patent application identifies component 34 as a dedicated processor and 32 as the diode connected to the switch relays, but that is evidently a mistake. Component 34 is the diode and I can’t find a component number 32 anywhere in the schematics.)

Each relay switch and its controlling software is described as a ‘channel’, one A and one B. Both channels run continuously, monitoring throttle position (36 in the schematic) versus engine data fed from ARINC data bus lines (46 in the schematic) and “dedicated input sensors” not shown in the schematic. Those sensors presumably detect things like weight on wheels and perhaps RADALT.

This design is said to achieve redundancy, because if only one ‘channel’ detects the engine is producing excessive thrust while the throttle is set to idle, that channel will set its switch relay to CUTOFF and that is enough to change the state of the high pressure fuel shut off valve (58 in the schematic). No more motion lotion. In the words of the patent application: Both channels are “always actively monitoring engine function and independently have the capability of shutting down the engine.”

That arrangement wrinkled my crusty old avtech brow. In my mind – and this is why I’m seeking other’s thoughts – the advantage of redundancy arising from the two channels, either or both of which can shut the engine down, is not without risk. If it is possible for one of the channels to have some ‘glitch’ or hardware failure such that it does not detect an actual out of envelope condition justifying immediate shut down, with the other channel detecting the condition and shutting the engine down, it inexorably follows – does it not – that it is possible for one (or both) of the channels to have a ‘glitch’ or hardware failure that results in a shut down when there is no out of envelope condition?

Further, even if there are completely separate, duplicated sensors telling each channel things like the position of the throttle and whether or not there is weight on wheels, there remains the possibility of a combination of sensor failures/disconnects resulting in one channel being ‘convinced’ that an out of envelope condition exists, with a consequential cutoff of fuel to the engine.

I of course acknowledge the valid observations made about the remote probabilities of these kinds of glitches and failures.

I’ve heard rumours that there was much resistance to the mandating of TCMA systems. Having seen many, many strange faults caused by random shorts, open circuits, liquid ingress and other foreign objects, I can understand why there was that resistance. Every time you add something to a system and that added thing has electronic components and software and electrical connections and data inputs, you add risk of that thing malfunctioning or working perfectly but with erroneous inputs. In this case, there are effectively two added new things: two channels, each one of which has the ability to shut off the motion lotion to the engine to which they are strapped.

I make no comment on whether TCMA systems, if fitted, have anything to do with this tragedy.

My profound condolences to the families and friends of those killed or injured. My thoughts also go out to the many people who will be agonising over the potential causes and responsibility for it. And thanks to those who are working out the causes.

...

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.

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

Thanks for that, Luc Lion .

What are the probabilities of a crew member spilling a cup of coffee over the centre console, causing a current path between the instrument lighting buss and the trim up command wire from the control column trim thumbswitch and the ARINC connector to the FMS controller, and what will the effects of those current paths be ? (It is for this reason, among others, that 'fluid spill' protection has been built into some instrument consoles.) It's the second bit - the almost completely unpredictable range of effects - that presents the more substantial challenge.

Yes. Other aircraft systems get the information through the FADECs (including the DFDRs) but the FADECs itself are isolated including independent alternators (PMG). There are two FADECs per engine and each has it's own throttle position sensor. That was explained by tdracer at some point in the old thread.

In his reply to your question above, EDML said that tdracer explained this specific wiring in a comment of the old thread (I had missed this detail too), and indeed, this is what he said:

For reference, this is the permalink of the said comment .

I (and I think everyone else here) have been assuming that the FADEC does in fact have a dedicated permanent-magnet alternator, as is the case on the Airbuses (confirmed by FCOM) and surely the 737.

I have been told elsewhere that this is not the case. A read of the draft FCOM available online for the 777 & 787 makes no mention of a FADEC generator, but then neither does the 737 manuals. Is this simply a case of "Boeing thinks you don't need to know"?

It has been proposed that the primary source of power for the FADECs is actually the flight control PMGs, mounted on the engine gearbox, but that this power goes to the avionics bay, has failover switching gear, and comes back to the EEC.

Can anyone shed concrete light on this (e.g. a source that clearly states there is both an EEC alternator and a flight control PMG on the accessory gearbox)?

Alternator and generator seem to be used interchangeably in this context.

It's not quite that, but there is a list of received channels for a GEnx 787 in the FDR report into one of the original battery fires . Unfortunately, it is only a list of parameters that they used and verified in the investigation - the only ones listed for the engines are N1 and cutoff switch. Other accident/incident FDR reports might be more focused on engines and include a similar table.

I don't think you'll find an actual wire list for it (or it won't be useful) as apparently most/all of the data is via an ARINC bus.

I attempted to PM this but your inbox is full.

[SLF with an electrical background and some exposure to ground-side critical facilities power]

The details don't really matter, but this is the certification requirement:

​​​​​​​ https://www.easa.europa.eu/en/docume...s-engines-cs-e

I see the logic. If the N2 exceedance functionality in the FADEC already included authority to shut off fuel in some circumstances, might as well 'piggyback' TMCA output onto that part of the FADEC functionality.

Re air/ground input to the TMCA, I am more interested in whether that is hardwired from the sensors / systems involved or - as appears to be the case just based upon what I've read here - read from ARINC or other format data.

Further to the (logical in my view) points you make in response to AAKEE's ostensibly logical conclusion that the commencement of undercarriage retraction (if it did commence) is conclusive of the aircraft being 'in the air' for aircraft systems purposes, including TCMA purposes, I make the following points:

First, whilst it may be that every system that monitors and makes decisions about whether the aircraft is 'in the air' does so on the basis of exactly the same sensor inputs, that may not be true and I'd appreciate someone with the expert knowledge on the 78 to confirm or refute the correctness of the assumption, particularly in relation to, for example, FADEC functions compared with undercarriage control functions.

Secondly and probably more importantly, what happens if one of the sensors being used to determine 'in air' versus 'on ground' gives an erroneous 'on ground' signal after - maybe just seconds after - every one of those sensors has given the 'in air' signal?

Reference was made earlier in this thread to a 'latched' in air FADEC condition that resulted in engine shut downs after the aircraft involved landed and was therefore actually on the ground. But what if some sensor failure had resulted in the aircraft systems believing that the aircraft was now on the ground when it was not? I also note that after the 2009 B737-800 incident at Schiphol – actually 1.5 kms away, where the aircraft crashed in a field during approach - the investigation ascertained that a RADALT system suddenly sent an erroneous minus 8’ height reading to the automatic throttle control system.

The conceptual description of the TCMA says that the channels monitor the “position of thrust lever” – no surprises there – “engine power level” – no surprises there – and “several other digital inputs via digital ARINC data buses”.

WoW should of course be one of those "digital inputs" and be a 1 or 0. But I haven't seen any authoritative post about whether the change in state on the 78 requires only one sensor to signal WoW or if, as is more likely, there are (at least) two sensors – one on each MLG leg – both of which have to be ‘weight off’ before a weight off wheels state signal is sent. Maybe a sensor on each leg sends inputs to the ARINC data and the systems reading the data decide what to do about the different WoW signals, as between 00, 01, 10 and 11.

There is authoritative information to the effect that RADALT is also one of the “digital inputs” to the TCMA. The RADALTs presumably output height data (that is of course variable with height) and I don’t know whether the RADALT hardware involved has a separate 1 or 0 output that says that, so far as the RADALT is concerned, the aircraft to which it is strapped is, in fact, ‘in the air’ at ‘some’ height, with the actual height being so high as to be irrelevant to the systems using that input (if that input is in fact generated and there are, in fact, systems that use that 1 or 0).

If we now consider the ‘worst case scenario will be preferred’ concept that apparently applies to the TCMA design so as to achieve redundancy, the number of sensor inputs it’s monitoring to decide whether, and can change its decision whether, the aircraft is on the ground, becomes a very important matter. The TCMA is only supposed to save the day on the ground, if the pilots select idle thrust on a rejected take off but one or both of the engines fail to respond. In the ‘worst case’ (in my view) scenario, both TCMA channels on both engines will be monitoring/affected by every WoW sensor output and every RADALT output data and, if any one of them says ‘on ground’, that will result in both engines’ TCMAs being enabled to command fuel shut off, even though the aircraft may, in fact, be in the air.

Of course it’s true that the TCMA’s being enabled is not, of itself, sufficient to cause fuel cut off to an engine. That depends on a further glitch or failure in the system or software monitoring engine power and thrust lever position, or an actual ‘too much thrust compared to thrust lever position’ situation. But I can’t see why, on balance, it’s prudent to increase the albeit extraordinarily remote risk of an ‘in air’ TCMA commanded engine or double engine shut down due to multiple sensor failure – just one in-air / on-ground sensor and one of either the thrust lever sensor/s or engine power sensor/s – or, in the case of an actual in air ‘too much thrust compared to thrust lever position situation’, why that ‘problem’ could not be handled by the crew shutting down the engine when the crew decides it’s necessary. Once in the air, too much thrust than desired is a much better problem to have than no thrust. The latter is precisely what would happen if all ‘on ground / in air’ sensors were functioning properly and some ‘too much thrust’ condition occurred.

Hopefully the design processes, and particularly the DO-178B/C software design processes done by people with much bigger brains than mine, have built in enough sanity checking and error checking into the system, followed by exhaustive testing, so as to render my thoughts on the subject academic.

I am not aware of any requirement for a DFDAU (or equivalent) to store any data. I say "or equivalent" because in B717 the DFDAU is not an LRU. It is a functional partition of the VIA.

It's not clear to me that 787 EAFR even requires an external DFDAU. The GE EAFR does not -

"Provides Flight Data Acquisition function of ARINC 664 p7 data parameters – No need for a Digital Flight Data Acquisition Unit (DFDAU)."

ref https://www.geaerospace.com/sites/de...rder-3254F.pdf

In this case, there is still an AU - it's just integrated into the EAFR.

Quote:

Originally Posted by YYZjim

The preliminary report narrows things down a lot but not as much as it could have done. The report will have been approved by several people. What we see is their consensus. Why did they choose this version?

I agree that the Preliminary Report will have been a very carefully chosen synopsis, but I don't think it precludes a system behaviour that might or might not even be categorised as either an electrical or mechanical malfunction, as such.

Consider that the Preliminary Report only references the CVR contents to indicate one crew querying why he (the other) cutoff, and the other denying it. Clearly very pertinent data to this investigation, so I'm not ruling out both of the crew being sincere, until I understand the aircraft system better.

If the cutoffs weren't triggered by the crew moving the switches, then the most likely thing was that both FADECs encountered a situation that invoked cutoff, practically at the same moment. That might suggest that the data from independent Run/Cutoff switches via independent poles that possibly route via a PIP or PIPs to various RDCs and in turn the CCS (which means these paths have a common mode) resulted in data to both FADECs "failing" in a critical manner simultaneously.

The only CCS vulnerability I'm aware of is what happens if the CCS is kept powered for 51 days, shortly after which, the Time Manager data integrity for ARINC 664 messages is compromised, possibly only considered critical n conjunction with a CDN Switch failure. AD 2020-06-14 therefore requires a maintenance action of cycling the CCS power at least once every 25 days.

Two such omitted, or incorrectly executed maintenance actions in a row would have to happen for that known issue to be relevant. Perhaps there is some other input in the CCS system that influences both lanes of data to the FADECs for the Cutoff to be triggered, but I'm not aware of such.

If the data to both FADECs became good again around the same time (perhaps no longer Stale Data, or an alternative source selected, or other mechanism), and given the unavailability of APU power at this point, might Engine 1 restart be initiated first, and might Engine 2 restart be triggered 4 seconds later by the FADECs? Is that possible without the crew cycling the switches?

Regarding AD 2020-06-14, which was approved quickly, Boeing subsequently offered revised wording, which changed "may" to "will", see FAA Docket 2020-0205-0004, but as it did not alter the maintenance action, it was not adopted. A fuller description of possible consequences was in FAA Docket 2020-0205-0001_content, but it was quite wide ranging, and didn't attempt to characterise specific aircraft systems behaviour.

For anyone wanting more information on the CCS, in the context of that Airworthiness Directive, I recommend reading A Reverse Engineer’s Perspective on the Boeing 787 ‘51 days’ Airworthiness Directive at IOActive.

As a non-professional pilot, please accept that my knowledge of much beyond the CCS is patchy, but I welcome this scenario being critiqued.

Thank you for your time, and I'm just donning my hard hat and flack jacket.