PPRuNe Forums

PPRuNe Forums (https://www.pprune.org/)
-   Tech Log (https://www.pprune.org/tech-log-15/)
-   -   AF 447 Thread no. 4 (https://www.pprune.org/tech-log/454653-af-447-thread-no-4-a.html)

Chris Scott 2nd July 2011 11:29

Quote from Linktrained:
The PF on AF447 may have seldom hand flown at cruising level. If, and just if, he had gripped the SS too firmly with his fingers, would this, could this, induce a NU, which in turn would be taken as an order by the trimmer, slowly to wind on full NU ?

I think a number of us are of that opinion, and the PF had lateral-control issues to cope with. These might have distracted him from pitch control, as well as causing him to tighten his grip.

Quote:
A gradual change of whatever indication there may be of the amount of trim might have been overlooked - there was a lot going on. ( I might have a light flash on when more than 75% has been used, just to remind me.)

Many aircraft have aural warnings, such as the "whooler", whenever the THS is in motion. I quickly learned to prefer Airbus's philosophy of a "quiet, dark cockpit". But in the case of an abnormality such as Alternate Law, perhaps something like the whooler should be provided.

IIRC, THS position is not normally displayed on the centre panel en-route, so the PF has to avert his gaze to the trim wheel if he wants to check its position or movement

Linktrained 2nd July 2011 12:05

Retired F4's flight deck sounds ideal, just red, yellow and green actions to worry about. ("simples !") Even I might cope...

AF447's PF was for the time Acting Captain. They had not been able to contact Dakar. I do not know who they might have been able to contact. There were drills for loss of airspeed. ( From NWA and TAM we now know that this may have been of relatively short duration. Jetstar's was a few months later. All four were over water- although that may not be relevant. Different makes of Pitot appear to have been used.)
If one could reasonably anticipate the loss of Pitots leading to the need for hand flying for,say, half an hour, ought one to try to reduce ones flight level by say 4000 ft. This should give a greater speed range within which to fly, not too slow and not too Mach.

Earlier aircraft had a Penetration Speed for going through Cbs, without any radar, day or night. For me, this was until the 60s.

PA 18 151 2nd July 2011 12:16


Originally Posted by A33Zab (Post 6548366)
Remarkable, Engines have only 2 channels for control, 2 sensors for each parameter; B777 has only 2 AOA vanes fitted.

And usually two pilots.


What happened with redundancy here? even more 'ridiculous' design or clever engineering?
Clever engineering, risk assessment and mitigation.

Pitot tubes are here for the foreseeable future and the public demand for air travel requires flight into known icing conditions. The failure modes for pitot tubes are well understood but cannot with current technology be 100% engineered away.

Part of the risk mitigation is having two pilots (who have regular medicals etc etc), and a computer which recognises problems with the pitots and hands control over to these humans at an appropriate point. That recognition/handover appears to have been done properly.

Arguing about redundancy in pitots appears to be missing the point. The drama was turned into a crisis elsewhere.

RR_NDB 2nd July 2011 13:05

Diversity of methods and Pattern Recognition
 
MachinbirdIn dealing with the product limitation of current Pitotīs, Diversity could be implemented (for "brief" AS fluctuactions) and probably could be better than the use of a "memory mode" band aid. In this aspect Turbine D approach could be one method.

Pattern recognition techniques are powerful in preventing and after the (possible and improbable) UAS events.

This can be done and the on board redundant processing power allow the implementation. The required R&D could optimize defining the extra required hardware.

Ideally diversity could perhaps help in some (extreme) cases (Birgenair and perhaps even Guam B2) providing less precise data but avoiding abrupt a/c config changes.

Diversity (inside the Redundancy concept) should be applied to reduce surprising and dangerous abrupt transitions from "Normal Law" to "Murphy Law scenarios":} with unpredictable consequences. All this for creating degraded, but administrable situations. Obviously always we will face limitations. There are some possible but improbable issues that could be considered in the System (a/c+operation) R&D without incurring in initial prohibitive costs. The 737 rudder (PCU) issue is an example of this "costs" (without mention the lost lives in FLTīs 585, 201 and 427). Competent designers in good R&D teams know well this matter.

Drifting a little bit:

L1011-500 superb characteristics may be could be mentioned in this aspect. The challenges they faced were very "high" And they also put an angel to fly (high :)} at FL600 in 80 days

RR_NDB 2nd July 2011 13:36

Adequate redundancy (always under K.I.S.S. constraints)
 
A33Zab, the point is: We must consider in the System design (a/c+crew operation) everything to avoid going straight from "Normal Law" to "Murphyīs Law":}

And remember, i am against the (ridiculous) redundancy (wrongly applied) when critical System elements are prone to fail simultaneously. Your examples doesnīt fit in this category. And even if this occur, you can save the day in most of cases. (Looking to your question, BA 38 and FLT 1549 came to my mind)

PA 18 151 mostly :ok: in here and here

RR_NDB 2nd July 2011 14:10

Causality
 
PA 18 151, Technically speaking (from an instrumentation point of view) this figure can be negative. I.e. you receive the information on UAS before you lost AP, etc. I commented something related here and in earlier post(s).


Contributing factors are not yet known but may include other man/machine interfaces. Re: :ok:

fyrefli 2nd July 2011 14:23


Originally Posted by PA 18 151
Absolutely. And the evidence released by the BEA says the time between autopilot disconnect and recognition by the crew ("lost the speeds/alternate law") was 9 seconds.

9 seconds is pretty quick, hard to see how that can be improved. This suggests that specific interface between man/machine was working and the PNF was on the ball.

You're conflating UAS, AP disconnect and the law change. But, hey, you're not the first, and you probably won't be the last :)

RR_NDB 2nd July 2011 14:26

Causality
 
Linktrained, Technically speaking we perhaps could anticipate just in the "seconds range" (before System degradation). Allowing the PF to prior known the reason for Law change. The rationale is that he could be better prepared to cope with the event knowing in advance the probable reason of a subsequent Law change. That could occur or not.

CONF iture 2nd July 2011 14:40


Originally Posted by AZR
My understanding of the ALT2 being latched is that as soon as you've got an ADR disagree, the system cannot be sure that the equation you write above is true.

If the ADR disagreement disappears, ALT2 is still latched, but in my understanding, AoA protection can be back.
Could you confirm that A33Zab ?


Originally Posted by PA 18 151
Consistent AND valid = Correct

Not necessarily ... can be incorrect as well.


Originally Posted by PA 18 151
Computers solve these engineering problems very well, better than humans, and it is clear that automation of the nature used by Airbus has saved many lives.

The nature of the automation by Airbus is about protection. How is it clear that it has saved many lives ?

BOAC 2nd July 2011 14:58

All this discussion of 'forewarning' is to my mind a waste of time. The thing to do is to PREVENT HAL doing something stupid when things do 'off schedule' as he did in the 2001 A340 case. Providing his sticky little electrons can be kept AWAY from any flight controls all will be well. Airliners generally fly in a stable manoeuvre environment and the 'Oh my god' need to pull/push immediately on a control is unnecessary. There will normally be time to pause and assess - no need to 'forewarn' - yet another ECAM/chime'/flashing light to confuse the poor human?

Unless something has fallen off or the a/c is wildly out of trim for some reason, sit on your hands, think about it, leave everything where it was for a few moments and THEN do something - as I say, thisi is fine as long as Hal is not doing something else..

Link - "If one could reasonably anticipate the loss of Pitots leading to the need for hand flying for,say, half an hour, ought one to try to reduce ones flight level by say 4000 ft." - no! No-one is going to do that. In which world did you fly? I suspect most pilots would be thinking hard about "doing a 360 and getting out of there" as a navigator once said..

Mr Optimistic 2nd July 2011 15:11

That navigator wouldn't have got there in the first place so no harm done.

BOAC 2nd July 2011 15:27

T'was brave pilote de chasse wot got him there.

Chris Scott 2nd July 2011 15:47

Warnings, hierarchy and ECAM
 
RetiredF4,
The warnings and their hierarchy are not so different from yours in principle. On current Airbuses, there is no WLDP (warning-lights display panel), but the system PBs (push-button switches) have an amber "FAULT" W/L built-in. (If a PB's normal position is on, it will show a white "OFF" warning when off. The handful that are normally in the off position, like wing anti-ice, have a blue "ON" light.

There are 3 levels of warnings and, below them, advisories.
Level 3 gives a Master W/L (red) to each pilot plus CRC (continuous repetitive chime).
Level 2 gives a Master-Caution W/L (amber) to each pilot plus SC (single chime).
Level 1 gives only a local (PB) amber FAULT light.
ADV (advisory) triggers the relevant system page on an ECAM display, highlighting a system parameter that needs monitoring in flashing green.

Master and Master-Caution W/Ls are cancelled (and hence re-armed) after agreement between the pilots, prior to any drill. This action also stops and re-arms the chimes.

On the upper ECAM DU (display unit), level 3 faults are written in red; levels 2 and 1 in amber; advisories in green. The lower DU shows the system schematic, when necessary. ECAM provides the drills and recognises the completion of each step. There is a recall button if you are uncertain that something was properly actioned. Some of the drills are inevitably long-winded, and must be cross-monitored...

The first Airbuses without flight-engineers, the A310 and A300-600, pioneered ECAM but retained a WLDP. With the next generation, the A320, this was deleted.

Hope this helps, and that any errors will be corrected by others.

SDFlyer 2nd July 2011 15:57

As a humble ASEL-I all of this is far too recondite for the likes of me. All's I can say is, I'd rather be sitting in back with the fellow who posted #645 at the controls than some jumped-up jockey looking to grab the reins and FIX THE PROBLEM RIGHT NOW.

<sigh>

Chris Scott 2nd July 2011 16:06

BOAC,
Never knew a navigator demand a 360... ;)

Quote:
The thing to do is to PREVENT HAL doing something stupid when things do 'off schedule' as he did in the 2001 A340 case. Providing his sticky little electrons can be kept AWAY from any flight controls all will be well. Agreed, but you evidently think – like I do – that "Hal" did not put AF447 into its climb.

Quote:
There will normally be time to pause and assess - no need to 'forewarn' - yet another ECAM/chime'/flashing light to confuse the poor human?

There has to be a warning to the crew. What I've in mind is a warning that flight controls have degraded to ALT 2, that speed/AoA protections have also been lost, and that flight controls will degrade to Direct Law in 20 seconds, 19, 18, 17, 16....

We always "sit on our hands" while reading ECAM warnings (except the hand on the stick).

DozyWannabe 2nd July 2011 16:10

Apologies for delay - helluva busy week!


Originally Posted by galaxy flyer (Post 6542065)
The pilots clearly did not grasp what the computers were trying to do

How many times is it possible to say that the computers were not "trying" to do anything other than that which they were told to do by the stick inputs from the flight deck? "NO PROT" means just that. There's no released evidence whatsoever that indicates the pilots were "confused" by anything the aircraft was doing.


probably did not understand what the THS was doing and how that might have impacted their recovery attempts, and how they may have reacted properly.
I may be contradicted by the report when it finally arrives, but it would not surprise me in the least to discover that what the trim system was doing didn't even factor into the troubleshooting mode (by which I mean mental model) they were in. Again, witness the Birgenair case where, despite the escalating warnings that went on to include stick shaker, stall call-out and eventually the dreaded "WHOOP WHOOP PULL UP", the pilot spent most of his time continuing to troubleshoot the initial explicit warning he got, which was the erroneous overspeed.


Unfortunately, pilots learn to fly on planes that fly like all the planes built since the Wright Flyer, version 1908, not like Airbuses.
We all (or most of us) learn to ride a bicycle on stabilisers/training wheels, learn to drive in low powered "city" cars and learn to read with basic picture books. We can't rely on those forever, because they all limit the ability to master the thing you're trying to learn. The same is true of learning in a Cessna and piloting an airliner - the former is designed to have forgiving characteristics and be easy to fly using the simplest technology, whereas the latter is designed to get as many people from one place to another as quickly, efficiently and as economically as possible using the best technology available for the job.


There have been a disproportionate number of LOC accidents/incidents in Airbus aircraft. Since the A320 Habeshiem accident, there was the NAT incident, the Australian incident, the Perpignan crash, amongst others.
Not true. Every aircraft has its fair share - notwithstanding the fact that Habsheim was down to pilot error (with, IMO, significant corporate negligence on the part of Air France) and the Perpignan crash was largely attributed to failure of the pitot-static system due to improper cleaning/maintenance.


Originally Posted by RR_NDB (Post 6542093)
I.e. BADLY! This redundancy implementation is USELESS specially at "cruise FL". Or worse, creating a CRTICAL design.

The use of a "voting scheme" capable to "major a/c reconfig" using identical (sub heated) not adequate Pitotīs is a direct path to PROBLEMS!

...

1) Ridiculous AS sensors redundancy (useless)*
2) The use of this voting scheme to not adequate AS sensors (sub heated)

Note: IMO this design EXACERBATES Pitotīs icing susceptibility

I disagree strongly. The system was designed down to a worst-case scenario where one pitot had failed. The thought of two or more failing was thought to be exceptionally remote. Until Birgenair and Aeroperu, the concept of air data failure wasn't even headline news to the aviation industry and by then the A330 had been in service for over two years. The combination of the less-than-stellar performance of the Thales AA pitot probes in foul weather conditions with the voting logic of the FCU and FMC didn't raise its head until a decade later, and they've been trying to fix it since.

Now, regarding the traditional method of redundancy where the pitot data is directly fed to one of three instrument clusters (CPT/FO/STBY), I'm not sure if the Airbus design reverts to this behaviour in the event of ADR DISAGREE - or indeed if that's how it works anyway and the filtered data only applies to the automatics - and I will try to find out ASAP. However I'd like to throw in that even if this method is used, it still takes time to diagnose which of the pitots has failed (Birgenair F/O : "Mine [ASI] is broken too" [it wasn't]), have the presence of mind to fly pitch and power while doing so (no mean feat at night in turbulence with warnings blaring at you) and resist any attempt to re-engage FMS until you're absolutely sure the failure has been isolated. Birgenair's FMS did actually try to fly the aircraft with the bad data, causing a pitch-up to the AP's limit of authority due to erroneous overspeed indication - which Airbus's design would not have allowed to happen, so in that aspect it is actually a "better" design.


Originally Posted by BOAC (Post 6546177)
JD-EE, I disagree - it was the 'system' that trimmed the tail at AMS, PGF and with 447 (and several other cases), not the 'pilots'. In all cases they made no deliberate attempt to trim that far.

With respect, we have no idea what they did or did not attempt - let's wait for the report before we start blaming the system, the pilots or a combination of the two, eh?


Originally Posted by Chris Scott (Post 6548336)
That is why Dozy Wanabee and I are suggesting that, in the UAS case, the reversion should be all the way to Pitch-Direct, requiring the PF to do the pitch-trimming.

Chris, again with all due respect I *never* suggested that. I asked Smilin'_Ed if that's what *he* was suggesting, but my position is that the designers had a very good reason for implementing Alt 2 in this scenario and I intend to find out at some point. I'm still not convinced by the "G-loading causes nose-up trim" argument and I'm trying to find the info that will confirm or disprove it.

Linktrained 2nd July 2011 16:28

Obeisance
 
I bow to BOAC's response... I was only asking, due to my own inexperience of operating much above M .5 and F/L 25.0. I usually had fans on the wings, which I could see rotate at a reasonable speed and quietly.
My world was flat, when I was acting as a Navigator. I understood that it was said to be an oblate spheroid - but I never really believed them. Why didn't they give me a Globe ?

PA 18 151 2nd July 2011 16:34


Originally Posted by fyrefli (Post 6548625)
You're conflating UAS, AP disconnect and the law change. But, hey, you're not the first, and you probably won't be the last :)

No I'm not. I'm giving an example of two milestone events and the time between. My intention was to demonstrate that the crew were quickly aware of the critical 'need to know' information within seconds of the aircraft passing over control i.e. the aircraft was efficient at providing this information in a format which could be understood. Within seconds.

RR_NDB 2nd July 2011 16:43

Human machine interface issues and redundancy
 
BOACCertainly the System must be predictable to not add extra issues specially when we are facing extreme conditions. And this "predictability" is intrinsically related to "testability" and in complex (feedback Systems) machines this will be ever an concern. (Naturally a concern for the designer and something that should be told to the operator).

A "forewarning" (perhaps technically feasible on AS issues) was just mentioned because could provide a faster understanding to the PF. Actually N805NW (A330-323) was equipped with an optional to "help" in this.

DW

The system was designed down to a worst-case scenario where one pitot had failed. The thought of two or more failing was thought to be exceptionally remote.
1) Current Pitotīs are just, sometimes, inadequate with a known limitation.
2) The simultaneously "failing" is because the mentioned, limitation.

The worst case scenario is just one failing?

Redundancy is "powerful" when critical elements do not fail simultaneously. And UAS cases show clearly simultaneous "failing" (due product limitation)

Question (yet posted earlier): Why they put this redundancy? For what reason? What benefit?

Simultaneous "failure" of critical elements should be reported immediately.

OK465 2nd July 2011 16:52


I recall a post in the previous thread from someone who had hand-flown one of the above AB models in alternate law, and who reported the actual a/c was significantly more sensitive than the simulator.
Previously, one of the most often heard complaints about simulators during training was that they were generally more "sensitive" than the real aircraft while hand flying. (The workman blaming his tools.)

Even from aircraft to aircraft of the same type there are minor differences in feel and sensitivity, though less so in FBW aircraft I would guess. Depends on how bent the aircraft is from firm landings.

Line pilot critiques of simulator performance and fidelity these days are consistently pretty complimentary.


I'm still not convinced by the "G-loading causes nose-up trim" argument and I'm trying to find the info that will confirm or disprove it.
Would my confirmation be of any value? CS is entirely correct from what I can tell.

Chris Scott 2nd July 2011 16:53

Dozy Wanabee,

Sorry, and I couldn't find where you'd said it either. Guess you were misquoted.

Re the THS trimming. It occurred while the aircraft was in a semi-parabolic trajectory, having run out of lift. So G was well below 1.0, and stick was neutral or back, therefore commanding 1G or more. In the absence of high-AoA protections, I don't understand your problem. The up-elevator delivered by the EFCS would be backed up by THS movement. By the way, I cannot claim to be the originator of this simple theory.

DozyWannabe 2nd July 2011 17:03


Originally Posted by RR_NDB (Post 6548789)
The worst case scenario is just one failing?

Well, the worst-case scenario where the automatics can continue to function is, yes, because a software-driven triple-redundant quorum can only be effective if two components are working correctly (in this case giving readings within the acceptable tolerance range)

I've moved your quoted post around a bit so that my reply can deal with the questions properly - hope you don't mind.


Question (yet posted earlier): Why they put this redundancy? For what reason? What benefit?
Simple - as has always been the case, computers are better than humans when it comes to monotonous, repetitive tasks like comparing readings in a data stream. A computer will be much quicker at flagging a pitot failure problem specifically than a human will be able to. Compare the previous generation's B757 - classic triple redundancy with the flight computers linked to a single air data input at any one time - where, originally, the first warning you got was "MACH TRIM - RUDDER RATIO". This is logical in terms of the systems engineering, but to a pilot the message could be confusing. They later added an "AIRSPEED DISAGREE" warning if I recall correctly.


Redundancy is "powerful" when critical elements do not fail simultaneously. And UAS cases show clearly simultaneous "failing" (due product limitation)

Simultaneous "failure" of critical elements should be reported immediately.
They were, and there was a service bulletin in effect to replace the components (along with pilot information to assist recovery from the issue) - unfortunately the airframe that became AF447 had not been taken into MX for that fix yet.

@Chris Scott re: misquoting, no problem. The problem I have is how the system would attempt to calculate G-loading in this scenario. The whole design ethos seems to have been based around making sure that the computers did not interfere if any data was missing, because at that point the pilot is best suited to keeping the shiny side up. Of course, even if this was the case, you've got 3 ADIs in front of the crew telling them they're too nose high, so why is the stick neutral or back? IMO this is the 300-pound gorilla in the room that the people who want to blame the aircraft are wilfully ignoring.

fyrefli 2nd July 2011 17:26

PA 18 151, sorry old bean but you said:


the evidence released by the BEA says the time between autopilot disconnect and recognition by the crew ("lost the speeds/alternate law") was 9 seconds.
Whereas the report says:


From 2 h 10 min 05, the autopilot then auto-thrust disengaged and the PF said "I have the controls".
i.e. straight away. The way you've phrased the quoted statement it comes across that you're interpreting "lost the speeds/alternate law" as recognition of AP disconnect, whereas it seems more likely that it's, again, immediate recognition of the latching of ALT2 at the end of the much-discussed monitoring period.

vbp.net 2nd July 2011 17:38

AoA and AS
 
To Gallerypower #632. Very interesting. Although, correct me if I'm wrong, it seems AoA is of paramount importance in these instances, and it is not directly available to the pilots on AB machines ?

To DozyWannabe #657. OK, AS is derived from 3 pitot tubes that could lead to problems if two of them are wrong but close enough to be taken as valid. Then why not compare AS history with GPS derived speed (history) together with thrust/attitude. I mean : compare the trends. If the plane is level flight, if thrust is not changed (even in turbulent weather) and a dire discrepency is noted (IAS significantly increasing/falling while GPS speed no change) wouldn't that be the case that AS should be highly suspected to be wrong ?

I don't mean the A/C should do something with that ! But the pilots might be warned.

Chris Scott 2nd July 2011 18:09

Dozy Wanabee, quote:
The problem I have is how the system would attempt to calculate G-loading in this scenario.
Not sure exactly what you mean by "calculate", but if not fully capable how could it offer Pitch-Alternate Law?

jcjeant 2nd July 2011 18:44

Hi,

DozyWannabee

The thought of two or more failing was thought to be exceptionally remote
be exceptionally remote :confused:

A short one ...
Put 3 fingers in water .. they will be all wet


Thales AA pitot probes in foul weather conditions with the voting logic of the FCU and FMC didn't raise its head until a decade later, and they've been trying to fix it since.
Airbus. December 1995 TFU 34.13.00.005: Ŧ STRONG CUMULO-NIMBUS (Cb) CONTAINING A HIGH DENSITY OF ICE CRYSTALS CAN BEEN ENCOUNTERED, PARTICULARLY IN THE INTERTROPICAL CONVERGENCE ZONE (ITCZ). IN SUCH AN ICY AND TURBULENT ATMOSPHERE, THE A/C AIR DATA PARAMETERS (PRESSURE DEPENDANT) MAY BE SEVERELY DEGRADED, EVEN THOUGH THE PROBE HEATERS WORK PROPERLY. IT HAS APPEARED THAT THE CHARACTERISTICS OF SUCH AN ENVIRONMENT COULD EXCEED THE WEATHER SPECIFICATIONS FOR WHICH THE PITOT PROBES ARE CURRENTLY CERTIFIED. ŧ

January 1999. Report BFU accident 5X002-0/98 : Ŧ The specification for the pitot tubes should be changed so as to allow unrestricted flight operations in heavy rain and under severe icing conditions. The installation of the improved pitot tubes already designed should subsequently be prescribed for all types concerned by the SIL no. 34-0147 (A 320, A 321, A 330, A 340). ŧ

Cool Guys 2nd July 2011 19:41

The Interface
 
My first post, please be nice to me. I am not a pilot or an aeronautical engineer but I am an electrical engineer who deals in automation that can kill people if it goes wrong, such as transporting 150ton crucibles of molten steel around steel mills. I prefer to read the intelligent and enlightening discussions here than listen to some of our other sources of "entertainment".

There is lots of talk about the man-machine interface. What is the man machine interface? The machine is ideal for multiple repetitive monotonous, tasks. The human works best with minimal tasks at once, 2 or 3 tasks at once is ideal, 4-5 max. A machine can only perform tasks that it has been programmed to do. A human trained in the basic and fundamental technologies of his job can make decisions based on this training without ever having encountered or trained on the scenario in the past. So if the machine encounters a scenario that it is not programmed to deal with, it should naturally pass it over to the human. However the designer and programmers are responsible for passing it over in a format that can be easily handled by the average person. Ie a maximum of 5 tasks. Monitoring the planes speed, AOA, Multiple ECAM messages, A WOOP WOOP STALL, an auto pilot kicking out, a change in handling characteristics, changing trim settings etc. It seems excessive to me.

If one of my designers or programmers came up with such a scenario I would sit down with him and explain to him the situation as I have mentioned above and tell him to go back and redesign the system or rewrite his code.

A33Zab 2nd July 2011 19:49

CONF iture:
 

If the ADR disagreement disappears, ALT2 is still latched, but in my understanding, AoA protection can be back
Edit: NOT Confirmed! (did read AOA stall warning i.s.o. protection)

Stall Warning:
If CAS <60Kts AOA = set to 0 degrees and System status matrix (SSM) set to NCD.
(Changed to 30 Kts if 'BUSS' option is installed, this A/C did not had 'BUSS' installed)

When any CAS => 60 Kts (30 @ BUSS), highest AOA value is taken.

Add: Hi-AOA protection:

Cryptic to me:


AOA is still monitored but warnings relate now to stall speed (Vsw) rather than AOA, if in dual ADR Failure Low speed stability* is lost so is Vsw.
If VS1G cannot be calculated due to loss of weight or s/f position information then there is no AOA protection at all.

* Low Speed stability:

An automatic nose down command is introduced to increase speed. No reference to AOA, only speed. Operates 5 to 10 kts above stall warning depending on weight &
slat/flap configuration. The pilot can override.
"STALL" announces and crickets heard prior to stall speed being reached. PFD shows black and red barber’s pole for stall warning speed. V-apha-prot and V-alpha-max are

replaced by Vsw (stall warning speed). No alpha-floor protection is available.



The nature of the automation by Airbus is about protection. How is it clear that it has saved many lives ?
That would be hard to prove as is in general.
This one would not have happened for sure, can't say about 5A-ONG (Tripoli). Are there any others? (besides Test flight)

OK465 2nd July 2011 20:57

What exactly does the flight control system do to provide AOA protection in ALT2?

OK465 2nd July 2011 21:21

Are you referring to low speed stability again being active when both ADR's are recovered?

Please explain to me FCS-wise what occurs as you approach stall AOA in ALT2 with both ADR's recovered.

A33Zab 2nd July 2011 21:47

The Interface
 
Well there is task sharing and a few rules,

* PF Fly, Navigate & Communicate.
* PNF Manage failure on PF command.

* Secured, Guarded switches and Clear P/B to be confirmed before switching.
* PNF NEVER touches the T/L.
* Read out load all actions.

For handling:

Failure announcement:
- Attention getter Visual [Master Warning/Master Caution] Audible [ CRC/SC/Special (e.g. Fire Bell/Calvary)/Svoice (e.g. STALLSTALL)]
- Check ECAM (format SYS msg) in red or amber.
- Perform Crew actions (next line ident) in Cyan
System panels are uncluttered and identified by SYS (in white letters) on the side.
- Identify Amber FAULT P/B (Local warning)
- Call SYS, SELECTOR, PROCEDURE (e.g. NAV, ADR 1, OFF) before switching. (In general action clears appropriate crew action line on ECAM
- check action result on SD (if any)
If all crew actions performed:
- PNF CALL SYS CLEAR, PF CONFIRMS.
- Clear SYS or Emergency Clear on ECAM control panel.

Done!

Next warning (if any)

Warnings are displayed by priority top-down.

If you apply the rules even a guest B. pilot can do this.:D

gums 2nd July 2011 21:49

Gee sensing for FBW systems
 
As with Chris, I too wonder what does Doze think the "system" uses to sense and use Nz.

I don't have the box specs in front of me, but I doubt that the confusers use the basic inertial and attitude system data for anything other than the plethora of "protections" and all the approach, cruise, climb, descent, flare and other stuff that enables a pinball wizard to fly the jet ( sorry for the rant).

The system likely uses its own accelerometers and rate sensors. That is the core of the entire flight control system, fer chissakes. No shabby sensors to freeze up, no cosmic autopilot or flight phase inputs, just the basics.

We tried various core principles 40 years ago. AoA, body rates, attitude, mixes of all..... The Nz control law is the one that allowed humans to fly the FBW systems when compared to older systems, and it was very easy to implement internally, without a lotta data inputs from the outside. A basic FBW system would only emulate the hydraulic pressures to the control surface actuators via servos. Big deal. Kinda sounds like the 'bus "direct law". However, we then had the opportunity to control deflection rates and total surface movement and such that we didn't have with the systems that went back to the early 1950's. We could also use a few bits of outside data like dynamic pressure and AoA to provide some "limits", not "protections". Could also use those bits of external data to keep the jet smoother and less susceptible to PIO's and overstress and STALL!!!! We could also adjust the lag of AoA and body rate inputs to make rolling into a turn smooth, but "freeze" the rate command more quickly when relaxing stick pressure. Same for pitch/gee.

For the life of me, I can't understand why the core principle for the 'bus is not an AoA versus Nz principle. A gee command that uses AoA to limit the gee command. So you can pull as hard as you want, but your command will be reduced when at an AoA limt. In other words, work back up from a well-defined control philosophy and add bells and whistles along the way. The existing system starts the other way, and it's hard to figure out what HAL decides is necessary or will do that the human does not anticipate or fully understands.

Same goes for the "gains" that go south when the sensors freeze up. Good grief, use a fixed value for "q" and keep HAL happy. If and when the air data comes back, the humans can enable it for a smoother ride and such. That is one feature lacking that I cannot fathom about the 'bus design. And that lack of feature seems to have played a role in several instances. AoA is a different story, and the design should have a sufficient bias by body rates to keep the jet flyable if the humans use airspeed as an aid, kinda like the old days.

sorry for the rant.....

RetiredF4 2nd July 2011 21:51


ChrisScott
The warnings and their hierarchy are not so different from yours in principle. On current Airbuses, there is no WLDP (warning-lights display panel), but the system PBs (push-button switches) have an amber "FAULT" W/L built-in. (If a PB's normal position is on, it will show a white "OFF" warning when off. The handful that are normally in the off position, like wing anti-ice, have a blue "ON" light.
I think the warning systems are quite different. They are overloading and iīm also not happy with the detail of the warning, if a understand the events of AF447 correctly.

If the speed gets unreliable, i want to be informed about it when the information is available. No need to backtrack it and second guess it from other indications like disconect of autopilot and autothrust.

If the system reverts to another LAW, it should say exactly that.

The message "use man Pitch Trim" is weird as well. If i dont want to use it, iīm gonna disregard that message probably, becaue i anyway never used it before. So the trim stayed all the way nose up. Wouldnīt a THS Full nose up warning be more appropriate?

The Warning logic seems to be a kind of advisory logic like do this and do that without stating the big WHY you should do it.

And concerning chimes and chords or bells, very nice if they come single, noisy when they come repetitive and useless when they are overloading when multiple systems fail. They are momentary as well, if you miss one, the info seems to be gone.

Pushbuttons with fault indications are nice, but do i see that correct, 60 lights distributed over 5 mē cockpit space? How long does it take to check all in a night with adverse WX or on a day with bright sunlight?

Iīm not convinced that this system is to the best benefit of pilots in abnormal situations.

Smilin_Ed 2nd July 2011 21:58

Trim System Factor
 
Dozy:

I may be contradicted by the report when it finally arrives, but it would not surprise me in the least to discover that what the trim system was doing didn't even factor into the troubleshooting mode (by which I mean mental model) they were in.
I agree that they didn't factor the trim system into their troubleshooting.

Because the trim system (following the sidestick input) held the nose up and kept the Angle of Attack in the stall range, the aircraft continued its plunge to the ocean.

Why didn't one of the pilots do something about that? It seems apparent that they didn't even notice it.

Why didn't they notice it? It wasn't in their scan because they apparently were trained not to touch the pitch trim wheel(s) since pitch trim is always automatic and since it's automatic, why would you care?

I continue to believe that autotrim should disconnect along with the autopilot. That way, there is no doubt who is in control. That is a pilot's perspective.

The next report will confirm whether or not the plane did just what the pilot(s) told it to do. The bigger question is why did they tell it to do that?

infrequentflyer789 2nd July 2011 21:59


Originally Posted by OK465 (Post 6549102)
What exactly does the flight control system do to provide AOA protection in ALT2?

Nothing. There is no AOA protection outside of normal law.

PFD and speed scale changes to indicate this.

There is a stall warning based on AOA (if the plane thinks it has a valid AOA), but nothing else protecting AOA.

OK465 2nd July 2011 22:24


Nothing. There is no AOA protection outside of normal law.
Exactly.

Then why are some folks claiming it is available when both ADR's are recovered?

@RetiredF4:

When an ADR fails there is no doubt that airspeed is unreliable. The airspeed tape on the PFD is blanked (black) and all that remains is a big red speed flag.

rudderrudderrat 2nd July 2011 22:36

Hi Smilin_Ed,

I continue to believe that autotrim should disconnect along with the autopilot.
I agree. Unfortunately even the loss of stab autotrim won't return speed stability.

The aircraft has been designed to cope with the loss of B & Y Hydraulic systems (hence NO Stab trim). Despite no stabiliser movement, the elevators are powerful enough to control the aircraft from cruising speed to approach and landing. So even if the autostab trim was disabled (or the trim wheel held still by the pilots), the elevators would be repositioned automatically to maintain 1g stick free attitude stability.

Edit. B & Y corrected iaw CONF iture's post 689

bubbers44 2nd July 2011 22:37

Originally Posted by OK465
What exactly does the flight control system do to provide AOA protection in ALT2?

Nothing. There is no AOA protection outside of normal law.

PFD and speed scale changes to indicate this.

There is a stall warning based on AOA (if the plane thinks it has a valid AOA), but nothing else protecting AOA.

So the PF with less than a year experience in the Airbus used full nose up SS with this knowledge???? Did he forget? Why did both pilots use full up pitch control if they knew they had no stall protection? All us conventional airline pilots know exactly what would happen. Exactly what their profile did putting them in a deep stall.

The initial report left all the important stuff out like if they pulled up and with frozen pitot tubes and static pressure dropping did they get an erroneous overspeed warning.

They must have a reason to keep this quiet but eventually they will have to tell us what really happened up there.

infrequentflyer789 2nd July 2011 22:53


Originally Posted by Smilin_Ed (Post 6549172)
Dozy: I agree that they didn't factor the trim system into their troubleshooting.

Because the trim system (following the sidestick input) held the nose up and kept the Angle of Attack in the stall range, the aircraft continued its plunge to the ocean.

Wrong. Look at the timeline A33Zab (I think) posted a while back (post 379 - found it) - the elevators alone took them up to 15+deg pitch and right into stall, the trim followed later (as it is supposed to).

Had the auto trim done nothing, as far as I can see they would have stayed stalled all the way down from the elevator input.


Why didn't one of the pilots do something about that? It seems apparent that they didn't even notice it.

Why didn't they notice it? It wasn't in their scan because they apparently were trained not to touch the pitch trim wheel(s) since pitch trim is always automatic and since it's automatic, why would you care?
If trim is manual, why on earth would you trim nose-down and hold the stick hard back ?

If they had noticed the trim they would have noticed it was doing as asked - they were asking for full nose-up.

I think autotrim is a complete red-herring and a diversion form the real question (in terms of recovery from stall, not why they ended up there) which is why did PF pull stick hard back through 30s or more of stall warning. I have no answer to that, except to say that in the history of aviation accidents, he is not the only one, and we can't ask any of them "why".


I continue to believe that autotrim should disconnect along with the autopilot. That way, there is no doubt who is in control. That is a pilot's perspective.
Yet doing it that way has killed or nearly killed a lot of people already (schipol, perpignan, bournemouth...) - tyring to recover when the autos have trimmed full up (for whatever reason) and then stick forward doesn't overrider the trim. Based on that accident and incident history, pilots tyring to recover a (approach to or) stall don't always grasp the need to re-trim.

Look at the pilot action / trim possibilities:

Stick-forward, manual trim
- may not recover unless pilot re-trims, may not have pitch auth to override trim

Stick forward, auto trim
- best chance to recover, without need to re-trim, reducing workload in emergency

Stick backwards - no chance of recovery, whatever the trim does.

What should the a/c designer do ?

RR_NDB 2nd July 2011 23:02

Interfacing issue
 
Cool Guys

There is lots of talk about the man-machine interface. What is the man machine interface? The machine is ideal for multiple repetitive monotonous, tasks. The human works best with minimal tasks at once, 2 or 3 tasks at once is ideal, 4-5 max. A machine can only perform tasks that it has been programmed to do. A human trained in the basic and fundamental technologies of his job can make decisions based on this training without ever having encountered or trained on the scenario in the past. So if the machine encounters a scenario that it is not programmed to deal with, it should naturally pass it over to the human. However the designer and programmers are responsible for passing it over in a format that can be easily handled by the average person. Ie a maximum of 5 tasks. Monitoring the planes speed, AOA, Multiple ECAM messages, A WOOP WOOP STALL, an auto pilot kicking out, a change in handling characteristics, changing trim settings etc. It seems excessive to me.
We dontīt have yet the required information to be able to understand what really happened in AF447. During 2 years + diligent professionals are trying to "model" possible scenarios based on some reliable (scarce) pieces of information. The analysis being performed is trying to cover all aspects. The interface of a complex System as you know very well must be "simple enough" to allow a safe operation in all scenarios before or during a "crisis". Even after a crisis if you implemented a true "Fault tolerant" and "Graceful degradation" System, the System and its interfaces ideally should work in a degraded mode still able to minimize consequences. E.g., Fukushima Plant dramatic failure.

In an highly dynamic environment, (a jet facing adverse conditions, sensor limitations, etc.) the interface requirements are severe. And is in this situations your design team must deliver what they developed during the R&D phase, to cover not only the probable faults but also the possible ones.

I pointed what seems to me a concerning conceptual error probably affecting several designs. In AF447 it seems this (design error + sensor limitation) triggered a major System reconfig and the subsequent lack of reliable Air Speed + probable human interfacing issues, probable played a role in the final result. Actually the plane in few minutes departed from an absolutely normal operation going to the bottom of the sea. And apparently without any more important "mechanism" problems other than Pitot tubes non compatible to the air space the plane entered. The first leak of information from the BEA investigation team surfaced in a French newspaper, Le Figaro, "suggested" crew faults. Also the BEA report (issued to stop damaging speculation before Paris Air Show, trade fair) emphasizes crew actions much different than the "normal", thus indirectly suggesting crew fault (from the pilot "flying" the plane during most of the crisis).

And as you know, itīs easy to put responsibilities in an operator if a Human machine interface (even a poor designed one) is working as designed. Always the management could point to lack of "training", etc. exempting the System.

Sounds intriguing (suggesting interfacing issues or even a possible System glitch that may have occurred during the critical moments) what we learned since the beginning. At least the trigger seems to be caused by improper sensors (product limitation) put in a System lacking the required redundancy in respect to a basic input, the Air Speed. The sensors (French company) were being replaced after showing itīs limitations, also existing (in a lesser degree) in itīs (US company) competitor.

You, being outside Aviation industry could eventually contribute to the discussion in respect the issues you face daily in your work.

On interfacing issues, take a look on the challenge an experienced crew faced when climbing out of Changi airport (SG) in a Airbus 388. They took a good time just to understand what happened and was going on after an uncontained engine failure in the inner left wing Rolls Royce engine. They eventually landed the plane in the same airport facing a complex situation.


All times are GMT. The time now is 13:13.


Copyright © 2026 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.