A33Zab

Svarin:

What's taken place inside FCPC's and FCSC's is not open to the public,
The only thing we know is: What is going in and what should be coming out.

I know the system only like it is advertised to operate in normal and outside the normal conditions.

If system had act like you say it did, it is NOT how it is advertised and would be a serious flaw.

There's only 1 PRIM in control and that will be the one which is capable of computing the highest level of law. (=NORMAL LAW, ALTERNATE, DIRECT).
The priority order is PRIM 1, 2, 3, FCSC.

This would maybe be the easiest part to design, and is common in all kinds of systems having multiple controllers.
Just take the output of controller 1 and use it as inhibiting input for the other controller(s). There you would have ensured the only 1 in control logic.
This inhibit could fail so it would be monitored and a message would be set if it did.

There is only 1 in control doesn't mean the others are doing nothing, the others are computing the 'same' output but this output is not used for servo command but for monitoring the output of the PRIM in control.
These other PRIMS are in MONITORING mode.

If the MONITORING PRIM's decide that the output of PRIM in CONTROL is not in agree with their own output a message would set and PRIM in CONTROL role will be transferred to the next PRIM acc. the priority rules.

At that time there were no messages present which would justify a PRIM in CONTROL change.
The wiring issue of FCPC 2 would possible be a reason to outvote this PRIM for taking CONTROL until there was no other PRIM left.

You are right by saying that (elevator only) all servos can operate simultaneously under certain conditions e.g. when inb. servos are unable to perform the commanded elevator position (due to aerodynamic load) the outb. servo’s (controlled by the executing part of PRIM 2) will assist and become active (i.s.o. dampening) parallel to Inb. (PRIM 1) servo's.

But NOT in the way you suggest (2 PRIM's) in control at the same time.
To explain this behavior you need to know a PRIM consist of 2 seggrated parts, a CONTROL part and an EXECUTING part.
For the CONTROL part there remain only 1 control and it is this 1 in control which demands the EXECUTING part of the other to assist its own EXECUTING part.

There are more situations were PRIM 1 in CONTROL needs output confirmation of other PRIM (e.g. Ground Spoiler) or other specific PRIM 1 function but that would take place in another flight phase.

Image below could clear some mis-interpretations,
Crosslinks between PRIMS and FCSC inputs are omitted for clarity.

Svarin

Thank you very much A33Zab for this great technically enlightening information.

I will repeat again that I do not believe this design would be flawed in general, but that it ended up in an unexpected/unforeseen/viewed-as-impossible condition in this particular case.

What brings me to this view is the simultaneity/combination of unreliable airspeed (the Probe stuff) with unexpected loss of ADR1 by PRIM2 (the Wiring stuff). I do not believe such scenario was ever considered in design. It is way too far out of bounds, and I do not expect any design to take this strangest of cases into account.

I am therefore not discussing a design flaw, but a very strange failure combination, that is so strange as to put the whole flight controls system out of its designed domain. According to logical consequences of this dual failure, PRIM2 could have returned alone to Normal law (an undesired outcome) while PRIM1 & 3 would have correctly latched Alt2.

A33Zab :
According to this, if PRIM2 had reverted to Normal it should take over control. This would fault PRIM1, if I understand right. PRIM1 was indeed faulted, but much later in the sequence.

However, PRIM1 is perfectly justified in operating Alt2 because of the UAS situation which triggered the 10 seconds monitoring process.

Remember this process did not trigger the NAV ADR DISAGREE condition immediately (as was the case in the Air Caraibe incidents) but at 02:12 approx.

PRIM1 being justified in operating Alt2 because of UAS, it can see no reason to defer to PRIM2 and its Normal law. Logically, the maximum control law should be Alt2. This is not an internal fault from PRIM1 which prevents it from computing Normal law, it is an external condition that justifies its operating Alt2.

The second interim report does hint at such a problem regarding the FMGEC1 FLR message. But again, this is later in the sequence.

However, if PRIM1 had remained Master, while PRIM2 had reverted to Normal and PRIM1 & 3 had latched Alternate 2, this means that PRIM1 is in COM (command) role, and both PRIMs 2 & 3 are in the MON (monitor) role.

But if PRIM2 reverted to Normal while PRIM3 latched Alternate 2, how would they agree on the fact that the COM from PRIM1 is wrong, for example ? I understand that PRIM1-COM could be outvoted by both other PRIMs-MON, but what if the monitoring PRIMs disagree ?

I take it that it would seriously delay recognition of trouble by the system. Such delay appears in the ADR DISAGREE and FMGEC1, PRIM1 and SEC1 faults/resets.

PRIM2 is never faulted. Its returning to Normal law would be the logical consequence of its losing ADR1 connection while searching for the outlier ADR.

Both PRIM1 and PRIM2 would have ended up in a condition where both would be justified by their programming in taking control.
-PRIM1 because it correctly recognized the UAS and correctly applied Alt2
-PRIM2 because it operates a "better" law : Normal (but it should not and fails to see this)

This looks like crossing logics with non-intersecting parameters where a decision cannot be made by logic alone.

How is this sorted out ?

BOAC

- err (yes, whatever that means) - by a pilot, or is it appearing that the a/c was probably 'un-flyable' in this condition?

fyrefli

Is there not an inherent contradiction in the above two rules? If one PRIM can compute a higher law than the other two, surely they're quite likely to disagree with it??

(Excuse me for butting in - I fly somewhat simpler aircraft, and have only contributed to these threads three or four times on matters I know quite a bit about, but I have read all of all four of them in some detail as they've developed and, FWIW, I *am* a software engineer.)

A33Zab

RR_DNB:

I am not in the position (no crew role) to justify or debate this matter.

I would suggest to take a look at ECAM as an example how it is presented to a crew, besides the local, aural warning and STATUS page with more information.

But if I am allowed (as technician) to comment:

UAS (ALT LAW DUE TO 3 PITOT BLOCKED) is not acc. ECAM protocol (missing preceding header) and too many characters (24 available) but more of all this can't be determined by EFCS.
EFCS don't know if the UAS is caused by PITOT, ADM or ADIRU failure, they only know FCPC's have no or conflicting ADR input.

Up to 1 minute after the event the CMC correlates this ADR disagree with the PITOT failure.
Don't think a crew will wait that long to be clearly notified.

GarageYears

If I am following all this correctly, then the issue in hand is not one of whether it was flyable, but simply which mode (Law) the control system was operating i.e. was it Normal or Alt.

Now, not withstanding the actual control law in effect, no matter what it was, the aircraft intrinsically was flyable. The question is still centered around what caused the zoom-climb?

In Alt Law I can only get to FL380 via PF input, I can't figure any other plausible explanation.

In Normal I believe the postulated theory is the aircraft, due to blocked pitots, believed it was in an overspeed condition and applied a pitch-up command, resulting in the climb and ultimately 13 degrees NU on the THS.

The part I don't follow is how we arrive at the overspeed? Since altitude sensing (static ports open) appears to have operated throughout, then with the dynamic port (ONLY) blocked, indicated speed would fall (which appears consistent with what BEA is reporting).

There are other parts related to Normal Law operation that I am not following, but the fundamental issue is this overspeed theory. Please enlighten me?

BOAC

- ok - so how is this countered? Does the system 'know better' and ignore any 'human' pitch down elevator commands by increasing THS angle? I still cannot readily accept that 2 pilots would sit, apparently silently, while their a/c launches into orbit What was said?

A33Zab

"Is there not an inherent contradiction in the above two rules? If one PRIM can compute a higher law than the other two, surely they're quite likely to disagree with it??"

Maybe I was not clear enough.

Priority (for the CONTROL)
1/FCPC 1 NORMAL LAW
2/FCPC 2 NORMAL LAW
3/FCPC 3 NORMAL LAW
4/FCPC 1 ALTERNATE LAW
5/FCPC 2 ALTERNATE LAW
6/FCPC 3 ALTERNATE LAW
7/FCPC 1 DIRECT LAW
8/FCPC 2 DIRECT LAW
9/FCPC 3 DIRECT LAW

10/FCSC 1 AND/OR* FCSC 2 YAW ALTERNATE/DIRECT LAW
* system setup is different and depends on several configurations.

11 MANUAL (THS) with Elevators centered.

If one PRIM is not capable of computing a higher law this doesn't mean it is NOT capable of computing a lower law or failed totally.

Machinbird

Sorry, that is backwards. When you climb with a blocked pitot, the airspeed winds up, not down. Static is dropping and pitot pressure (trapped) stays constant. Delta P is higher which indicates higher airspeed. If I hadn't wound an airspeed completely around once climbing on top of an overcast, I'd probably be confused also.

GarageYears

So you're assuming unequivocally that the DRAIN port was also blocked? Because most of what I can find relating to block pitots DOES NOT support that as the 'usual' failure mode. With the drain OPEN and the main port blocked, the pitot internal pressure drops to near static, resulting in decreasing speed indication. I can't find the reference to hand now, but in something like 90% of recent pitot icing incidents this was the failure mode - blocked main port and open drain.

Secondly, how does that tie into the BEA reports of the speeds dropping below 60kts and then recovering?

PickyPerkins

Thanks for your comment.

Looking at Fig. 6 (see below) of the NASA report "Dynamic Modelling and Simulation of Large Transport Aeroplanes in Upset Conditions", I see that for the generic twin jet transport model used in that study there was no reversal of pitching moment, Cm, for any elevator angle (between +20 and -30) or any AoA (between -5° and +85°).



Although those results were with "CG=mid", these results are not dependent on the position of the CG.
The efect of a different THS setting might be another matter.

Note: This report was originally pointed to by BJ-ENG on 8th May 2011 in post 943, then again by Beispiel on 9th May, 2011 in post 990, and by Hazel Nuts on 18 June 2011 in post 143.

RR_NDB

Hi A33Zab,

Processors (i was fascinated when received the Intel 4004 chipset to design and construct my first computer) computers and Systems are so integrated to our lives making us sometimes forget there other ways to "process and present" the information we need to perform our tasks.

My concerns perhaps can be expressed saying: Are this impressive arsenal of computational power being capable to allow the crews to properly exercise his capabilities (of simply keep flying the a/c or operate it safely) in all possible situations? Observe, here we cannot say just "probable situations". This is simply not affordable in the design of an airliner.

I´m not against automation or the growing use of "advanced System´s", etc.

PJ2

Svarin;

Thanks for your response. Respectfully, I would like to continue challenging your theory as a way of proving-disproving through "finding out". In the end, we may find that it cannot be settled. The theory, engaging and "possible", may still be trying to fit known facts "into the box" as opposed to examining why the PF pitched the aircraft up and continued to do so.

Regardless of how it is put in your theory, in the above responses to my post, it is being claimed that two PRIMs, #1 and #2, are contributing to or co-sharing control of the aircraft....#2 providing those responses which apply in Normal Law and #1 giving those responses expected in Alternate Law.

The Priority Logic of the EFCS which is located in the FCPCs but independent of the controlling/monitoring functions of the FCPCs plus PRIM #2's failure to remain in Alternate Law due to a programming error, are, (as A33Zab has also said about the latter), two very serious flaws emerging independently and concurrently.

I agree completely with your comment therefore, that this is indeed a "very strange failure combination, so strange as to put the whole flight controls system out of its designed domain."

On another post...I suggest respectfully that it cannot be "sorted out" because it has not been established that this is what happened. It remains a theory. One can only "sort out" inconsistencies in theories through a tautology or by broadening the theory to reasonably account for inconsistencies.

If I may, it is claimed that there is a "Master PRIM", but that there is another, working independently which materially affects control of the aircraft. The theory cannot have it both ways. Instead of asking the question of how to sort it out, (see "Byzantine failures" in previous threads), it needs to explain, beyond claiming rogue programming or rare events, why the Priority Logic as thoroughly explained by A33Zab's substantive posts, and the PRIM2 control in Alternate Law did not fully apply and instead caused a pitch-up of the aircraft in response to a false CAS > VMO + 4kts (where does that indication come from? - it can't be just "spurious"), the evidence for which, it is claimed, is some nose-down inputs during the pitch-up. Remember, the FMGECs supply orders to the FCPCs and the FCSCs and are also monitoring inconsistencies in output.

The Overspeed pitchup is a limited response in Nz Law...+ 0.3g (on top of Nz 1g) and a 22.5deg pitch up IIRC but more importantly, the High Speed Protection Law is overrideable in Alternate Law (specifically, VMO 2 Law) but not in Normal Law until the speed falls below a certain threshold. If it was overrideable as claimed, (reduced climb rate in response to ND stick inputs in the pitch-up), then Normal Law clearly did not apply at that point, so at what point did PRIM 2 stop "interferring" and why?

The other theory about the pitch up was re-introduced by sensor validation in response to HN39's question, What caused the pitch-up? I think the AAIB Report, which deals mainly with the TCAS - AIRPROX event, does not explain the AoA response accurately and perhaps even glosses over some characteristics of the A340 (and A330) Alpha response in 2001, which were changed as a result of an ADR/Pitot incident on the A330 in 1996 which also resulted in changes to the stall warning and brought in te notion of returning to Normal Law after a short period of time, (because the aircraft involved in the incident latched in Alternate Law, period). The change in question concerns the Alpha Prot Law which was and is inhibited above M0.53 by the updated FMGEC Standard.

Svarin

PJ2,

Thank you for this discussion opportunity. Such is what I am looking for.

The failures that I am putting forward are very simple :
- the probes failure, triggering the monitoring process
- the "wiring" failure, which deprives PRIM2 of critical information (ADR1) at a critical moment (inside the monitoring process itself)

The "programming error" I posit would only be an oversight in a newer version software that fails to consider compatibility with a previous version of software on another type of computer (i.e. ADR x FCPC, different manufacturers) only in the very specific instance of the monitoring process that is triggered inside the PRIMs by the probes failure. This would entail misunderstanding between ADR1 and PRIM2 at this very moment. This explains the sheer coincidence.

edit : But whatever its cause, the wiring fault did happen and it is a loss of connectivity. The wiring fault is not a hypothesis but a fact. The timing of this fault compared to that of the probe fault begs for a sub-theory that explains the coincidence.

The design "backdoor" is the possibility for PRIMs to revoke Alternate 2 law and return into Normal after 10 seconds if ADR values appear more or less consistent. This "backdoor" was likely breached when PRIM2 lost ADR1, thus fooling its overview of the UAS condition.

This possibility overall could not be foreseen. There is no way a design would be prepared against this.

Sorting out :

I asked that question with regard to the priority logic among PRIMs.

PRIM1 is Master and Alt2. It does not go to Alt2 because it fails to compute Normal, it goes to Alt2 because it is the right thing to do in an UAS context which it correctly identified. It is rightfully Master PRIM because Alt2 is the correct law to use because of UAS.

PRIM2 is not Master, but in Normal. Its "wiring" failure fooled it into believing itself out of the UAS context. However, Normal is the preferred law, which would make PRIM2 entitled to challenge mastery of PRIM1 according to the priority logic. It views itself as the one which can compute Normal, while the others cannot.

The priority logic looks to me very much strained here. This is what I would like to see sorted out.

Unless this very curious mastery dilemma is clearly broken, flight controls look very much compromised to me.

High Speed Protection is only the simplest way of seeing how a rogue PRIM would interfere. I would think the real events were infinitely more complex, but as A33Zab wrote, this requires knowledge of PRIMs inner workings.

barit1

Evidently the A330 pitot and the 727 pitot (NWA accident) behaved differently when iced up. The 727 was climbing, low-altitude pitot air was trapped in the system, and as static pressure dropped with altitude, the IAS display kept increasing.

But this is explained by the fact the 727 crew DID NOT TURN ON pitot heat at all, so both the ram and drain ports were blocked.

Smilin_Ed

They are part of the same thing. If the man/machine interface is not adequate, the human pilot can't fly it properly.

Machinbird

GY,
Some have speculated that the RHS airspeed oversped. Since that side is not monitored by the DFDR, there is some possibility that this happened.

I personally don't hold to this notion, but with the information we have at the moment, it is still a possibility.

I tend to believe that the PF accidentally got some back stick mixed in with his lateral control efforts, causing a net nose up input over time.

HazelNuts39

Agreed.
I don't share that view either. If that had happened, ADR2 would have been the outlier and would have been rejected by the PRIMs. If, as svarin speculates, PRIM2 was deprived of ADR1, it would have declared ADR DISAGREE.

The occurrence of stall warning and stall point towards Alternate Law2. Is there anything in BEA's Update that points towards Normal Law?

BEA tells us that nose-up sidestick commands were made, and nose-up pitch and climb followed. In response to nose-down ss input the rate of climb reduced from 7000 to 700 fpm. We don't have all the data yet, but I expect we will get them. If the airplane response had been obviously at odds with the sidestick commands, wouldn't BEA have observed that?

A33Zab

PRIMS workings

I think it makes more clear to copy your posting in whole and comment on specific parts of it.

I call this a most serious design flaw if it leads to such A/C behaviour,
why are you convinced PRIM 2 reverted to NORMAL LAW?
Why should PRIM 2 revert (as the only one) to NORMAL while there is a common ALT 2 situation declared?

According to this, if PRIM2 had reverted to Normal it should take over control. This would fault PRIM1, if I understand right. PRIM1 was indeed faulted, but much later in the sequence.
[/quote]

Not faulted PRIM 1, being only capable of computing a lower law than other PRIMs would not fault a PRIM, only sets a maintenance message.
PRIM 1 was indeed faulted later in the sequence, however I will not be surprised if the outcome will be the result of pilot action as is SEC 1 message.

Just because! the NAV ADR DISAGREE was triggerd much later in the sequence the speeds didn't disagreed that much and/or that long enough initially to set the NAV ADR DISAGREE.
I really don't know how much time it will require to trigger this message.

EDIT: In our A330 manual (Enhanced - equipped with BUSS mod) is stated:
if the ADR disagree last for more than 10s the PRIMs trigger the NAV ADR DISAGREE ECAM Caution.
The flight controls revert to ALTN 2 LAW

BEA:

Note: The inconsistency between the speeds displayed on the left side and on the ISIS lasted a little lessthan one minute.

Why didn't it trigger NAV ADR DISAGREE earlier?


If and only if PRIM 2 could compute NORMAL LAW it would become the PRIM in control, no doubt about that, if not this would be the serious system flaw and BEA/AIB should ring all available alarm bells.

AMM:

The Law is such that:
- each computer (FCPC) establishes the highest level of law (normal, Alternate or Direct) it can engage,
taking into account the results of the internal monitoring functions and the availability:
- of the ADIRUs.
- of the control components
- of the control surfaces, THS and S/F.
among the FCPC which can engage the highest level of law, the FCPC having the top priority is chosen.
If only 1 FCPC is capable of the highest level of law, this FCPC is selected whatever its priority level.




FMGEC is different, there are only 2 a COM and a MON, if they disagree the 3rd reference is the crew. They have to decide which FMGEC failed.

Very remote (MON disagree) because all the FCPC's get the same information - ADR 1 + ADR 2 + ADR 3 - being valid or false.
(Except as you say PRIM 2 is missing ADR 1 data, but then again that could be a reason to prevent PRIM 2 to become in CONTROL, maybe only as last resource)
To give you an answer I guess the MON closest to COM will be validated and other MON declared due for maintenance.


PRIM 2 (or its connection with ADR 1 bus) is faulted but for maintenance only, this was no reason to declare it a total failure.
A total failure would mean the EXECUTION part is also not available.

IMO the logic did sorted this out as designed, only - with respect - couldn't convince you yet.

Anyway we have to wait until end of july what actually happened untill then we will debate this matter.

PJ2

Yes indeed, I should think so. If known to be the case, it would be a serious abberation in computer behaviour that would demand of the appropriate parties prompt action and suitable cautions/warnings to operators, none of which occured.