@BOAC:
A nice variation on the old gag about Unusual Attitudes recovery.
Something about Shave the Bat rings a bell. This must be included in aviation vernacular, but I'm not sure what practice it ought to be applied to.

"Captain Pteropine sure shaved the bat on that one!"
(Made in reference to a hand flown landing very near stall brought on by a sudden windshear attack in the flare ... )

more automation?
 

Some nice points, Garage.

Some do not realize that one of my original jets was the VooDoo, and it had the dreaded "pitch-up". Couldn't deep stall it due to the aero and c.g., but it had two limiters when not in autopilot control stick steering - a basic AoA limiter that we could overcome with 65 pounds of back stick, and a 'pusher" that snatched the stick outta your hands. This was back in early 60's, folks. So it has been tried and flown a long time ago. FBW systems don't act like that! You can pull back at 100 pounds and the command will be "x" gees, or "x" AoA, and if more than the design then that's all you'll get until airspeed is too slow. In other words, the jet will give you all that the designers figure you'll need.

One of my problems with the 'bus is that it seems to ignore the AoA when other air data is outta the loop. I have no problem with the basic "limits" implemented for the 'bus. They seem very reasonable for the mission and the aircraft's aero capabilities. Although I have my personal ideas of implentation, I'll stick with what we have to work with today except ignoring AoA.

So we don't need bitchin' betty telling you to lower the nose! And how is the 'bus gonna do this if it has ignored the AoA? Huh? just use the AoA limiter function and the sucker will gradually lower the nose to reach the 1 gee baseline ( corrected for pitch, so it will be lower than 1 gee in a climb or dive). The problem is if you are climbing at an extreme attitude, then you run outta air molecules over the THS too quickly to get the nose down!!

I also caution folks about the "direct law". Sounds like the jet would fly like a "normal" jet, but it ain't so. There are still control surface deflection rates plus pitch rates computed independently of air data and such in the way. Further, the 'bus ain't no F-22, and getting 3 or 4 gees within a half a second might be a bit disconcerting, ya think? Only way around this, way I see it, is to employ control stick feedback as we now see in several PC flight sims. In other words, you get a "feel" of how much you are asking the beast to do. Only problem is that kinda system need some gee and "q" inputs. Gee ain't a problem, but when the design ignores speed under certain circumstances, then all bets are off. And such is the 'bus control logic at present.

respectfully,

thank you for a very imformitive post, i cannot thank all of you enough for your posts and links again i take my hat off to every professional person to post on this forum. thanks again from a slf:ok:

Machinbird;
The text I have is not the easiest to read/interpret. One could gain the impression by reading some of the statements, that once the THS is moved manually through the trim wheels, that it is in "manual, mechanical mode", period. However, the relevant statements which make me believe otherwise, are:




...........5 The mechanism is now set in the electrical control position.

I think that makes it pretty clear, that once manual input stops, autotrim is reinstated. It also makes sense from the POV of the safety of flight - you cannot have a 1g AFS function safely with manual trim requirement.

BOAC;
The THS would move, doing just as we would do in a non-AFS airplane...trim control column forces out to keep "elevator forces neutral", (bearing in mind that the forces aren't real, being masked by hydraulic servos and are artificially introduced by springs, ;).

The question that the engineers had to come to terms with however is, how do you do that in a FBW system?

For the above reasons suggested by Machinbird, you can't just rely on human input to do the trimming in a FBW automated system.

Maintaining "1g" flight is one solution. Using the elevator, (short term pitch control) as speed changes means that according to Nz Law the THS, (long term pitch control) would change position to maintain full elevator authority.

Maintaining 1g is an indirect response to increases and decreases in airspeed. A decrease in speed causes slightly < 1g as the aircraft pitch reduces, an increase, the opposite. Even in manual flight, the THS responds, both to stick and Nz laws.

Clearly, there are circumstances which you would either not want autotrim or autotrim would not be available in system or sensor failures.

Our human feedback loops are completely transparent to us but are extremely sophisticated and are the "loops" in a non-fbw airplane that we "tune" when we learn how to fly.

But those "loops" must be made visible (from their "automatic transparency!), then designed and built into a FBW system independent of humans for such a system to even function in a rudimentary way, and decisions must be made about such loops about the information signalled back to the servocontrols, the AFS and the crew.

Otherwise, any autoflight system would quickly become unmanageable, highly fatiguing and fundamentally unsafe.

PJ2
Thank you very much for the analysis with references. That is crucial information in understanding a large range of issues regarding the Manual Trim and Automatic Trim systems.:ok: The FCOM references are indeed skimpy and confusing.

This is to express my gratitude to A33Zab (AF447 Part 3 #1818 11th june) for digging up and posting the complete Stall Warning schedule of the A330. That is information I've been searching for in vain since s/w was first discussed early in the AF447 threads. So I've promptly incorporated that schedule in a graph that I posted earlier: StallWng2.

THS Answers.
 

Hmmm, doesn't the A/C makes inputs of its own in ALT law, trimming the THS ? Sure, this was due to strange PF inputs but was he really aware of the move ?
[/quote]

The actual logic inside the FCPC is not open to the public, so we have to rely on what is stated in the released documents.

"Pitch:

The side sticks and in some cases the pitch trim control wheels control the aircraft in pitch.
They act on the elevators and on the THS depending on the different laws.

1. Nz law.
This FCPC law is the normal pitch law engaged during the flight phase.
The pilot commands a load factor via a pitch action on the side stick.
The Nz law executes this command, depending on the aircraft feedbacks, so that:
- the short-term orders are executed by the elevator servo controls.
- the long-term orders are executed by the THS actuator (autotrim function).
The gains depend on Vc, on the flap and slat position and on the CG position."

From study material and answer to Machinebird's question:

"An override mechanism, which is installed in the PTA (Pitch Trim Actuator),
makes sure that the mechanical control through the trim wheels cancels the electrical control.
When a manual command is made with the trim wheels, the override
mechanism gives priority over the electrical command from the FCPCs.
It mechanically disconnects the PTAoutput from the mechanical input(via
electro-magnetic clutch) and also operates the overriding detection
switches which in turn signal the FCPC's to stop any electrical command
from the FCPC's."

It's not stated but it seems logical that when a manual pitch trim wheel
command is made or an autotrim command is cancelled by holding the
manual trim wheels (THS runaway) the side stick should be released to neutral.
In that case there is no SS input anymore and when manual input on Trim wheel stops also,
the electro-magnetic clutch is released again and THS system is ready to
take new SS orders.


Cryptic schematic but could not find any better:

http://i474.photobucket.com/albums/r...99/THS_OPS.jpg



In ALT 2: The HI AOA Protection is lost, in case of a dual ADR failure (or ADR DISAGREE).

Agreed, except that when IAS dropped below 60, then 30 kts, I think that was due to changes in the fuselage pressure distribution near the static ports (over-reading static pressure) due to high AoA, as much as or even more than due to the pitots under-reading total pressure. For what it's worth, CAS never drops below 140 kt in my simulation. That 140 kt is quite capable of pointing the AoA vanes in the right direction.

And don't forget Otto Lilienthal (recently celebrated on another PPRuNe thread), and who still knows the Minimoa?

Questions & Comments
 

PJ2, in answer to your post #258 :

More accurately, it did not remain in Normal, it would have returned to it at the end of the 10 seconds monitoring process. This ADRs monitoring process by PRIMs specifically allow return to Normal law in some cases. During the process itself, it is in Alternate 2.

No I do not. I expect it would have acted upon its sole authority following Normal law and quite possibly its protections, interfering badly with what PRIM1 was doing according to PF orders. Being in Normal while Master was in Alternate 2, it would have deemed its Normal law better than what was asked by Master PRIM (PRIM1), thus resisting it.

Not quite. Especially on elevator control, the need to activate all servos simultaneously under certain conditions make it necessary to cater for dual PRIM outputs onto parallel servos. Such thing is therefore not positively excluded from the design.

Alternate 2 law was latched by at least Master PRIM1, and likely PRIM3, thus triggering the Alternate law ECAM and PFD effects.

Not quite. Their wording was extremely careful (BEA text in italics):

From 2h10min05, the A/P then A/THR disengaged and the PF said "I have the controls". The airplane began to roll to the right and the PF made a left nose-up input.

The monitoring process takes place in Alternate 2. 10 seconds elapsed, then :

At 2h10min16, the PNF said "so, we've lost the speeds" then "alternate law [...]".
The airplane pitch attitude increased progressively beyond 10 degrees and the plane started to climb. The PF made nose-down control inputs and alternately left and right roll inputs.

The climb is not correlated with the initial left nose-up input. 10 seconds between the two. Time for PRIM2 to return to Normal. I posit these nose-down inputs were an unsuccessful reaction to the zoom-climb/pitch-up (manual THS should have been used then, easy to say now of course), and not the initiators of the following :

The vertical speed, which had reached 7000 ft/min, dropped to 700 ft/min and the roll varied between 12 degrees right and 10 degrees left.

I posit these are only the result of depleting kinetic energy. No updraft here, speed lost for height gained, no added energy. Roll variations might be the result of conflicting actions of PRIM1 and PRIM2 in different laws over ailerons and roll spoilers which the PF would therefore have had enormous difficulty controlling.
I agree that we should be questioning this action. After flight controls have cleared the investigation filter ;)

It was actually "to the nose-up and left stops".

If flight controls were compromised, as the theory I offer seriously suggests (this is no fancy), then PF actions cannot be understood without the full traces of computers states, surfaces actuation/position, and so on, simply because his actions and the aircraft reactions would make no sense to him. This could lead him to trying things which would make no sense to us.

What would cause PRIM2 in Normal to command the zoom-climb pitch-up?

same thing as that 2000 A340 AIRPROX?

PJ, thanks for that graphic, A33Zab, much thanks for your diagram.

In walking through PJ's proposed event sequence, it's the same place I get stuck as the first read through I did of the second interim report.

I still don't understand ...
Was the pilot flying (or think he was flying)
a g command,?
a nose attitude?
an AoA (with no AoA reference in the cockpit)
another profile and expecting something else to happen next?

For that matter, what response was he expecting from the aircraft?

A guess here: he expected to escape the stall alert. Apparently, we go down the timeline and the stall alert went away. Did the crew deem the maneuver successful? :confused: Based on pre-event conversation, there was still probably a concern with altitude, since they were worried about their scheduled climb and the temps at altitude not developing as forecast.

This leads to a question I still have: why no deliberate act to descend with stall warning no longer active, as they'd been concerned with altitude just a few minutes previous to all this going down. (Guess: deeply concerned with airspeed, or its lack of indication)
==
If PJ's sequence is about right, the Captain re-enters and has to figure out what's going on while they are still in a diagnostic mode. He has something between two and three minutes to assess and call for the correct remedial actions( X, Y, Z and beyond) until recovery.

It appears that he may have suggested, or ordered, engines to idle, nose down commands ... and the stall alert goes off again.

With no disrespect to the dead intended, did the next CVR recorded voice transmission come out as "what's it doing now" in three part harmony? :confused:

Whilst there's a slight break in the Tech action...

LW 50:

I think I flew with Harry Pteropine when he was an FO.

Last I heard, he retired from a fly-by-night cargo operation and became a safety consultant.

He was noted for being able to hang upside down and view all the facts from a different angle.

:ok:

"Managing and handling" advanced Systems (Human machine interfacing issue)
 

The System "output": Data (displays, aural info, etc.) and inputs to a/c flying surfaces (e.g. to THS, etc.) must be easily (and very fast) understood and understandable by the crew. It´s absolutely necessary an interface designed to present in real time a clear and reliable "picture" of "what´s going on" (and changing) in the plane.

And also even potentially creating "extra CRM issues".

My comments are not just on AF447 case. Other incidents/accidents can be related to these issues. And are not for just A (or B) but for "advanced planes", an important, "powerful" (and evolving :})trend.

Smilin Ed

I think you misunderstand - you seem to be describing the machine/human interface. Human factors does not refer to aircraft and how they operate but to people and how they respond to the situations they find themselves in. An awful lot of the discussion in these threads has focused on the possible trouble with the systems and how this has impacted on the pilots involved (a lot of this clearly ill-informed) but very little has focused the pilots themselves. Some have certainly asked questions but answers there have been few. The key to this disaster is the flight deck crew not the systems - which no doubt can be improved, systems always can. Information so far released contains hints of complacency and casualness (for example there does not seem to have been any sense of urgency in entering an area of turbulent weather). More examination of possible mental states would I believe be more fruitful. I realise that some of us don't really want to go in this direction (I am a pilot too but not on big jets) but to understand this accident I would suggest it is necessary to leave no stone unturned no matter how painful it is. Some have already shown this aversion to commenting on the pilots and I have to regretfully submit that this is not the right approach.

- I'm sure the majority here see the 'pilots' actions as a major factor in this accident and thus a subject to be examined thoroughly, but the question is 'why did they do xxx' - if indeed they did.

Could you answer #302 please?

In normal law (AoA law) no stall warning, no stall: AoA remains at alphaprot.

From the BEA Note:

So, what does it tell us ?

So we know pretty safely AoA was 4°, speed was >215 kts.
If we now assume a pitch of >10° (see first quote),
this gives a FPA of >6° at ~400kts TAS.
This equals a V/S of >4000 fpm.

Taking this together it does not seem that the depleted energy was the reason for the reduction of the climb rate.
There is only one way how with the data points we have the V/S can have gone down to 700 fpm if speed was >215 kts an AoA was 4°. And that is that the Pitch must have reduced after the initial Pitch Up.

Therefore I conclude that the Nose Down input of the pilots have not been unsuccessful. They might have yielded slower response than expected or resulted in confusing somatogravic results but going purely by the facts I tend to disagree with your scenario that the control system did not follow the Nose down commands.


Edit:
The somatogravic point is the one which is the most intreaguing for me.
If they accidentally overcontrolled the aircraft leading to the initial climb, (e.g. due to mxing up with Roll correction input) then started to deplete energy due to the steep climb, a sudden and significant lowering of the nose (reducng V/S from 7000 to 700 fpm would fall into this category) would give a 'falling sensation'. Being relatively close to the stall speed, a subsequent pull up reaction to any pitch would lead to a reasonable 1g result, because there is no more lift available.
This 1g fits well into the normal range of things and would feel like normal attitude again. in complete darkness with no external references I'm afraid these sensations can play nasty tricks on you. Once your personal G force reference system is shifted (Falling vs. stable 1g), its difficult to go back to the original one. Re- aligning this personal reference system with the instruments in a situation where you are not sure which instruments are working properly might not be easy.
During and post stall any NU input will yield </=1g and thus feel benign.

.

V/S can have been reducedby other factors as well like bank angle / roll to left and right, decaying airspeed, drag by deflected ailerons / rudder.

Concerning AOA: The relationship between AOA and pitch is not factual, theoretically a pitch of 90° with an AOA of 0° is achievable (not in an transport ac, but in a fighter ac).

I did observe lots of misunderstandings concerning unloading (stick forward) in nose high situations after more than 1 g was applied. 0,5 g already feels like a lot of unloading, stops the increase in pitch rate and reduces the AOA somewhat, but doesn´t change the (upward) flightpath immidiately and drastically. To really get the nose travel downward fast (and that is necessary in a nose high low energy state) unloading to at least zero g and below zero AOA is necessary, a vey uncomfortable thing to do if you are not used to it. And it takes some patience to wait till the nose is definitively below the horizon until further actions (like rolling wings level and applying power) have enough positive influence.

So i agree, nose down input had some effect, but not enough (Unload not high enough and not long enough).

Applying TOGA at that point was IMHO the worst thing which could be done by the crew. As long as the nose was above the horizon this TOGA produced a pitch up from the underslung engines and some noise, but no positve effect for recovery. That coupled with nose up stick input kicked the ship straight in to the fully developped stall.

That is no direct blame to the crew at the moment, as it affords training and expierience to act accordingly in a situation like this. A fighter pilot gets lots of training and application of those procedures in daily flying, the stall aproches in landing configuration or in medium altitude for air transport pilots in the simulator falls way short to that demand.

Concerning the somatogravic illiusions, spot on!

retiredf4,
No disagreement here. The only thing which I did was to derive the Flight Path Angle:
Flight Path Angle = Pitch - AoA
And consequently VS = Sin(Flight Patch Angle) * TAS
All I wanted to show is that 700 fpm at 400kts TAS means a Pitch attitude of significantly less than 10°..
In fact it would mean a Flight Path Angle of ~1° and thus a pitch of ~5°.

Regarding Roll it was stated that it varied between 10 - 12° left/right, so you would have to multiply the V/S with the Cosine of 12°, which would drecrease the Vs by less than 5%. Doesn't change the whole picture though.
Any speed reduction is already included as i assumed the 215kts IAS to be correct at that moment.

Questions & Comments
 

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.

http://i474.photobucket.com/albums/r...CHEMATIC-1.jpg

PRIMS workings
 

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 ?

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

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

Managing and handling" advanced Systems (Human machine interfacing issue)
 

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.

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?

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

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

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.

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.:}

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?

Absence of elevator control reversal
 

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°).

http://pp.home.infionline.net/fig6.jpg

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.

Complex Systems and it´s interfacing to pilots
 

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.

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.

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.

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.

Human Factors vs. Man/Machine Interface
 

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

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.

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?

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.

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.