I read his book and though I agree making powerless landings would help your confidence level in a situation like Sully's he doesn't credit it to his success.

HN39
Thank you for the corrections on French gliding licences. ( I did say "used..." I should have added that this was in the early 1950s. Things change...) I held a Brevet D, there was no question of a licence, then, as an option or a requirement at three National Centres.

It would be reasonable to suppose that PF WAS quite experienced as a glider pilot.

On three different Fight Engineered aircraft that I flew, it was usual for the pilot flying that leg, (now called PF) to have his hand forward of the throttles until V1, so that he could cut the power quickly. For the rest of the flight the F/E would control the power following verbal orders, "Zero boost", "30 inches " or "300 Torque", depending on type. If a constant powered approach was made then this would be something similar to a glide approach ( but with that constant power - and never below a certain figure, to allow for a low overshoot.)

Conf: I apologize for the poor explanation. It is only the last (fourth) stage of degradation that takes the boost cylinder our of the AFCS servo package (perhaps more like "direct law) while the previous three work you to something more like varoius ALT laws, with SAS off being closer to Alt 2 or Alt 2 B in terms of flight control sensitivity.

Again, a very difficult to make comparison, but the issue with " you have to fly more manually" and "it will feel very different" is the issue at hand, not precisely the detail of which system has run amok.

I admit that I was being a bit apples to oranges. :O

Could well be - it's a dim and distant memory, but I was distinctly told that the maximum attitudes were computed and held at the limit before transmission to the flight surfaces rather than the other way round (which makes sense as it's a far less process bandwidth-intensive way of doing it).

CONF might be right and the THS might be an exception (I still haven't got to the bottom of the sim behaviour), but I do know that the general design was to hold attitude with all flight surfaces available rather than put a hard limit on the flight surfaces themselves.

Slight change of direction.

On the 320, an ECAM Instructing the pilots to perform UAS procedures is displayed after a pitot failure.

If the system can come to that logical conclusion, could it not also make a reliable determination of plugged pitot's?

If the answer is buried in another string, please point me there.

What kind of determination? That there has been a problem with the pitot tubes, or an attempt to ascertain which of them is correct?

The problem with the latter is that you have three data sources - enough for a quorum, but limited in what can be applied. Earlier in the threads it was pointed out that were two to fail simultaneously, a risk is run of the systems interpreting the failed pair as correct and voting out the one that's still working. Now - the chances of this happening are miniscule, but it limits what can be done with that data.

Do you have to hand the ECAM message to which you refer?

Thanks.

Doesn't really matter. If the system can sense a pitot problem, would it not be prudent to suggest the UAS procedure? Remember, the UAS procedure does not demand action as long as safety of flight is not affected, so applying it can only help.


ANTI ICE Capt and FO Pitot is the ECAM.

Edit: I should have not asked the question in the way I did. I was trying to ask why the ECAM couldn't suggest the UAS procedure in a pitot failure.

@TTex600 - with you.

OK, so if I've got this right that ECAM message relates to the failure of the anti-ice system on the pitot tube rather than the pitot tube itself. Being an internal systems failure it can be easily determined which of the three, or which combination of the three have failed.

A blocked pitot tube scenario involves a failure from outside the system, so it cannot reliably monitor where the failure is. Having the ECAM suggest or instruct UAS procedure might be technically feasible, but I'd be inclined to worry about edge cases, such as a false indication scenario or a point in the flightpath where a strict interpretation of UAS procedure might be inadvisable.

I would think you could conduct an entire flight using UAS procedures.

@ Dozy,

I would have thought that a comparison of change in relative differences between the Inertial and Air data sources would give a reliable indication of single or multiple pitot failures, be they external or internal.

All to do with what you "trust".

Possibly, but there are times when it's better than others to do so - remember we're talking edge cases here.

One thing I should have said is that ECAM is there to help the flight crew diagnose technical problems and occasionally suggest remedies to those technical problems - it was never intended as a guide to how the aircraft should be flown.

@mm43 - Feasibly, but how far would you trust it? Remember that the inertial sensors could have problems simultaneously... As a "computer guy" I'd still be more inclined to trust a human pilot with a pitch/power chart.

Obviously it could suggest the UAS procedure. In hindsight it does look like a better option (to a non-pilot).

I suspect that it doesn't suggest the UAS procedure because nobody anticipated common mode pitot failures. Nor thought about their implications after they started to happen.

Personally I think that the warning could/should be given even earlier in the process, when the computer first recognised that a pitot failure may have occurred [*]. I think you might gain a few tens of seconds that way.

... during which time it might be a good idea if the pilots were encouraged to disengage the autopilot, until they can see that all is well. I doubt that autopilots should be relied on in situations where UAS may occur.

* I suspect that there is some intentional delay in the process. Not least to smooth over transient failures when the plane has just "flown through a puddle" and overloaded the pitots.

Pitot Failure Detection
 

The voting logic as described makes sense, unless as postulated two pitots block simultaneously and the remaining good pitot is out-voted by the logic. However, this approach is decidedly simplistic and I propose that it’s possible that the explanation of the voting system lacks a thorough knowledge of the low-level workings of the system. I do not possess such knowledge, however, if I were to design an air-speed sensing system one of the features (the design of which has been possible and therefore available to aviation designers/engineers virtually since the invention of the transistor) that I would incorporate is ‘signature’analysis. Basically, the electrical ‘signature’ of a valid signal from any pitot that is being impacted by air molecules will appear decidedly different to the ‘signature’ from a blocked pitot. Essentially, the signal from the blocked pitot will lack the ‘noise’ of the unblocked pitot. Sure, the block pitot can yield data, albeit invalid, and may function more as an altimeter than a speed sensor; but the absence of the minutia of the electrical information from the transducer that is being bombarded by air molecules is something for which the designers can easily test and its absence should inform the system to preclude the data from the ‘known’ blocked pitot. Then the notion of simultaneously blocked pitots being used to out-vote a functioning pitot is rendered moot.

OK, I agree, all they had to do was hold about 2.5 degrees nose up and hold altitude because the altimiter worked. Maintain cruise power and fly out of the precipitation.

However I don't think either of these pilots knew how to hand fly. That was the problem. Cost analysis says hire the new guys cheap because this is an automatic airplane. You don't need real pilots.

@ andianjul...

"However, this approach is decidedly simplistic and I propose that it’s possible that the explanation of the voting system lacks a thorough knowledge of the low-level workings of the system."

precisely...

The time to initiate a pilot cue inre suspect ias is when the initial sensing is suspect, not after the data is displayed as a product (airspeed).

+1 for the man from Australia...

Unreliable Speed - by Joelle Barthe, Airbus Engineer
 

Hi,

This paper is from the design group:

" By Joelle Barthe
Flight Operations Engineer

Published on SafetyFirst #5
December 2007

1 Introduction

Unreliable speed is one of the difficul situations that a pilot has to face. Once the failure has been identified, a procedure, based on pitch angles and thrst settings, will assist the pilot in safely flying the aircraft.

But the main difficulty is to rapidly detect an unreliable speed situation. Reaction time is crucial, since the aircraft may stall and overspeed conditions could cause aircraft damage.

The effects of pitot probes obstruction on ground

It intended to make ground and flight crew more sensitive to the consequences of obstructed probes, and to prevent take-off with unriliable speed.

But once airborne, how can the crew handle an unreliable speed situation?

This article is based on A320/A330/A340 design. Cockpit effects, identification and troublshooting, remains similar for wide body aircraft and A380, with some specificities covered in the operational documentation.

2 Effects and consequences in the cockpit

Water, ice, dust, ashes, etc. may pratially or totally block pitot probes and static ports. Equally,tubes misconncected to the Air Data Modules (ADM), plastic covers not removed from probes, insect nest, radome damage, may lead to enrroneous pressure measurements.

The consequences of this erroous pressure information, once used by the ADRs, and/or the standby instruments, are the computation and the display of unreliable speed and/or altitude for all users.

Erroneous speed or altitude indications can be suspected, among others, in the following cases:

- Speed discrepancy (between ADR 1, 2, 3 and standby indication),
- The flutuction of the Indicated Air Speed or of the Pressure Altitude.
- Abnormal correlation between basic flight parameters (IAS, attitude, pitch, thrst, climb rate),
- abnormal AP/FD/ATHR behaviour,
- STALL and OVERSPEED warnings or FLAP RELIEF on ECAM that are in contradiction with ar least one of the indicated airspeeds,
- Inconsistency between radio altitude and pressure altitude,
- Impossibility of extending the landing gear by the normal landing gear system.

Nevertheless, it should be emphasized that identifying an unreliable speed indication is not wlways obvious: no single rule can be givien to conclusively identify all possible erroneous indications and the display of contradictory information may confuse the flight crew. Pilots should therefore be aware of unreliable speed symptoms and consequences.

Depending on the effected probe, i. e. pitot probe os static port, differente indications in the cockpit will become unreliable. Therefore the crew should be aware that some of the usual cues to fly could be unreliable as indicated:




3 Identification and Handling of Unreliable Speed situations

Airbus has developed procedures and guidelines to help crews identify and handle an unreliable speed situation.

The Volume 3 of the FCOM and QRH provide the UNRELIABLE SPEED INDIC / ADR CHECK PROC procedure.

In addition, Airbus has developed training material in the Flight Crew Training Manual ( FCTM, available for A320/A330/A340/A380). The FCTM provides information about the causes and consequences of unreliable ADR computations. It also provides information on how to apply the UNRELIABLE SPEED INDIC / ADR CHECK PROC of the QRH.

An interative trainin tool, the e-Briefing, is also available on https://w3.airbus.com/ in the Flight Operations community, under ther heading "Safety and Operational materials".

4 - Procedures

As soon as a doubt about airspeed indication arises, or a relevant ECAM alert is triggered (relative to ADRs failure or discrepancy for instance), the UNRELIABLE SPEED INDICATION/ADR CHECK PROC procedure should be applied by the crew, following this sequence:

1) If the safe conduct of the flight is affected, APPLY THE MEMORY ITEMS, i. e. fly a pitch with TOGA or CLB thrust,

2) If the safe conduct of the flight is not affected, or once the memory items have been applied, LEVEL OFF, if necessaru, and start TROUBLESHOOTING,

3) If the affected ADR can be identified, fly with the remaining ADR.

4) If the affected ADR cannot be identified or all airspeed indications remain unreliable, FLY WITH PITCH/THRUST REFERENCES.

4.1 Memory Items

If the safe conduct of the flight is affected, the flight crew applies the memory items: theses allow "safe flight conditions" to be rapidly established in all flight phases (take-off, clim, cruise) and aircraft configurations (weight and slats/flaps). The memory items apply more particularly when a failure apprears just after take-off.
Once the target pitch attitude and thrust values have been stabilized at or above minimum safe atltitude, or when the safe conduct of the flight is nor affected, the flight crew enter the 2nd part of the QRH procedure: level off the aircraft and perform troubleshooting.

4.2 Troubleshooting and isolation

The table provided in the QRH gives the pitch (º) and thrust (%N1) to be applied to level off the aircraft according to its weight, altitude and configuration, along with flying technique advices.
In situations where most primary flight data are erroneous, some indications may stil remain correct and should consequentely be used to help the crew stabilize the flight path. This is the case for the Flight Path Vector (FPV), reliable if the static ports are not blocked, and for the GPS altitude displayed on the MCDU, when GPS is installed.

When the flight path is stabilized, the flight crew will start the troubleshooting, keeping in mind that sometimes two or even all three ADRs might provide identical but erroneous data (e.g. due to icing conditions, flight in volcanic ashes, etc).Therefore, do not instinctivelu reject an ADR that is suspected to be affected.


If the troubleshooting procedure enables the crew to identify the affected ADRs, then a normal situation can be. resumed.

But if the affected ADR cannot be identified, or all ADRs are affected, then the flight crew will fly without speed reference, using the pitch and thrust tables.

4.3 Flying using pitch/thrust tables

First, the crew has to switch OFF two ADRs and keep one ADR ON, to keep the Stall Warning Protection.
Then, the crew will [bold] fly the aircraft without speed references, using pitch (º) and thrust (%N1) settings.

To fly the aircraft using pitch and thrust settings, the crew will find in the QRH the tables relative to each phase of flight: Climb, Cruise, Descent and Approach, talking into account the aircraft weight, configuration and altitude. With theses tables, the crew will be able to safety land the aircraft.

5 Back UP Speed Scale (BUSS)

In order to dedrease the crew workload in case of unreliable speed, Airbus has developed the Back-UP Speed Scale (BUSS) that replaces the pitch and thrust table. The BUSS is optional on A320/A330/A340. It is basic on A380, being part of the ADR Monitoring functions.

This indication is based on angle of atack (AOA) sensor information, and is therefore not affected by erroneous pressure measumements.

The BUSS comes with a new ADIUR standar (among other new system standards), where the AOA information is provided through the IRs and nor through the ADRs. This enables selecting all ADRs off without loosing the STALL WARNING PROTECTION.
The AOA information provides a guidance area in place of the speed scale. When the crew selects all ADRs OFF, then:

- The Back-Up Speed Scale replaces the PFD speed scale on both PFDs,

- GPS Altitude replaces the Altitude Scale on both PFDs.

The Back-Up Speed Scale then enables to fly at a safe speed, i. e. above stall speeds, by adjusting thrust and pitch.
The BUSS will be displayed once all ADRs are switched OFF. Therefore, on aircraft that have the BUSS, when the flight crew cannot identify the faulty ADR(s) when performing the troubleshooting, or when all ADRs are affected, the flight crew will switch OFF ADRs, and will fly the green area of the BUSS.

However, if the safe conduct of the flight is affected, the memory items must still be applied before troubleshooting.
As the BUSS is associated to the ADR monitoring funcitions, some unreliable speed situations can be automatically detected (e. g. new ECAM warning "NAV ADR 1+2+3 FAULT"), and some ECAM procedures will lead to the BUSS activation by requesting to switch OFF all ADRs.


6 Conclusion

An unreliable speed situatio may be difficult to identify, due to the multiple scenarios that can lead to it. Therefore, training is a key element: indeed the flight crew's ability to rapid detected the abnormal situation, and to correctely handle it, is cricial.

In case of any doubt, the pilot should apply the pitch/thrust memory items, and then refer to the QRH to safely fly the aircraft, and to positively determine the faulty source(s) before eliminating it (them).

In addition, to further assit the pilot in detecting the failure and safely fly the aircraft, Airbus has developed the BUSS, which provides a safe flying range indication.

Finaly, to reduze the probally of experiencing unreliable speed situations, on-ground actions, such as comprehensive maintenance and through pre-flight exterior inspection, should be stressed. "

In Re RR NDB's post of a 2007 discussion of Unreliable Airspeed in the Airbus family ...
Did the gent in the right seat interpret "safe conduct of the flight" to mean "don't overspeed the aircraft?" There have been a number of estimates that a concern of his was overspeed, and wanting to not do so.
The crew never got into the logic tree of methodical trouble shooting that got to this decision point, if their lack of discussion on "which ADR is out at this point" is an indicator.

Anyone at AF have a handle on how to train for this? Some lawyers are probably contemplating villas in St Tropez, betting on the answer being no.

WHICH memory items? The ones for TOGA and nose up?

Granted, as has been discussed over and over, most succinctly by PJ2 but also by others, at their flight level, pitch and power for level flight is what was called for, to allow them time to trouble shoot and work through the systems faults. But what was the pilot trained for, and what was his most recent training scenario regarding this malfunction?

This takes us back to question 1, which is what the guy at the controls believed the risks to be to the flight.

...the main difficulty is to rapidly detect an unreliable speed...
 

Worse than that is complete loss of SA due (partially) misleading info presented by the System to a (non properly trained) crew after erratic and inconsistent data contaminated System

My rationale simply is:

Delegate to the crew the task (as per Airbus SAS) is an error. Using proven DSP techniques an A/C subsystem may warn on impending UAS. And deterministically inform of an important issue.

I posted several times this earlier

DSP and Signature analysis comment by andianjul:

:ok:

Do you think you could meet the reliability requirements? Remember that adding complexity adds potential points of failure.

Is this an honest question in relation to technical feasability or in relation to beancounters available assets?

Just remeber, the moon landing was 43 years ago.

Doze...

You miss the point completely. Adding complexity (sic), is done by the ADRs, when they act on deviant raw data at the pitot aperture, then synthesize and report to the pilots a value that is already known to be false.

By the time the aircrew heard the Cavalry and Saw Master Caution, the computer had been stumped for ten seconds. Had the crew been privy to an amber caution the instant the ADR was evaluating, we may not be here three years later. Add to that a Law degrade that is annunciated after the fact, and the stage is set.

Basic cf at the interface....

DSP,Signature analysis and automation
 

Hi,

Few days ago we celebrated the RTW in a PA46 (piston powered) of a friend (20) and my third son (23) both aviation students.

During the mission preparation, flying to met an aviation ace in Rio de Janeiro i emphasized to them on the limitations of the A/C instruments.

And when flying in russia (single pilot due ferry tank weight) the Capt. faced a serious engine oil issue, when overhead UEMO PSN bound to Yakutsk airport.

The plane landed there in emergency conditions and during the analysis of the incident discussing with the pilot we concluded on the convenience to have an oil level meter.

To learn on low oil level just by oil pressure indications is very dangerous.

So, what this relates to F-GZCP?

To learn on UAS by System output proved to be dangerous. You may just never understand the reason of System anomalies.

In both cases, the Signature analysis of the analog signals can provide to the crew a very useful information in order to allow a good crisis management, before worms could infect the scenario.

Some posters here worked with DSP (Digital Signal Processing) and know how feasible is a subsystem capable to help decisively at UAS onset.


In the carter oil Liquidometer case it seems in a first analysis you may have a pretty good signature by some temp. sensors installed in the carter. The splash is distinct at decaying oil levels during long flights.

RTW1

RTW2

You should be very proud of your sun and his friend!
Congrats!

"To learn on UAS by System output proved to be dangerous. You may just never understand the reason of System anomalies."

That is my point, exactly. It is more than that, it speaks of an ignorance at the most basic level of how things work, and how a pilot needs to assimilate data.

More than any other "improvement", the logic needs a laundering. Positioning a stick to a percentage, to gain a deflection, and waiting for the response of the airframe is lunacy.

At the most basic level, the airbus forestalls the decision a pilot must make immediately, or....Pay the consequences of starting behind, and having to catch up.

36 prior UAS? Nothing to exonerate the bus there, no specific procedure, mostly dumb luck...
How does a pilot stay ahead of the airbus?

I don't doubt for a second that it's technically feasible to do, but the level of reliability required to meet certification necessitated the use of simplistic logic.

I know it's a good-natured joke, but this is where the "HAL" references stop being funny and start being a serious barrier to understanding. The reason for this is that the fictitious HAL was a central computer that had very complex programming and sole control over the entire vessel. What you have in aircraft like the Airbus and Boeing FBW types is a network of computers that are constantly cross-checking each other. The subsystems within are essentially a collection of finite state machines - each one not much more complex than those you'd find in your washing machine, but interlinked together to build a complex interoperating system out of simple parts.

These parts had to be rigorously tested individually and gradually pieced together in a programme that took the best part of a year. My old prof's class started with tales of making safety-critical software reliable and the exciting stuff software could be used for, but most of it was spent poring over graphs from the various regression tests that were run during that programme in order to prove the technology and determining with algebraic functions whether they would meet the stringent reliability requirements imposed by the aviation system.

It's funny that you should mention Apollo, because I've been diving into that a lot recently - Apollo 14 in fact holds the distinction of being the first software patch applied to a mission-critical system on an aircraft, and they did it *in space*. But the Apollo crews were almost all engineering test pilots with the ability to call on 400,000 people to help them solve any issue that came up, and they all accepted a significant degree of risk in order to attempt the journey. That's a far cry from being a line pilot out over the ocean, responsible for a couple of hundred lives and some distance from technical assistance. And as such, the systems need to look after themselves to a greater degree in that situation.

To be honest, I'd be surprised if the A380 systems haven't had a significant upgrade in that area compared to the older types, and the A320NEO will probably have systems derived from that work. But the original FBW series will still be using hardware of a mid-80s vintage, and I doubt it would have excess process bandwidth to cope with such a function - which is why Airbus produced the BUSS option (which can be retrofitted) as a stopgap.

I haven't had time to be on here for a while, looks like it's got interesting and informative again, but the magic "DSP" solution is getting a bit silly.


Exactly what misleading info was displayed prior to the stall ?

As far as I can see the only misleading info at that point would have been speeds which were briefly too low before they disappeared. Why would seeing a suddenly low speed lead PF to stick the nose 15deg up ? If, prior to close of monitoring window, the indicated speed had been M1.5 then I could see a point, but it wasn't.

What proven DSP techniques would this be ? You keep mentioning DSP as if it were some kind of magic that Airbus engineers have never heard of. It's not magic, and of course they have.

Read the Airbus text properly - it states that one human cannot explain to another the set of rules for determining UAS, because it is too complex [it seems so complex that some humans cannot write a coherent procedure for dealing with it either:(]. Yet with your "proven DSP techniques" the machine can solve a decision problem that humans can't.:confused:

That's not DSP, it's AI, and it doesn't exist (at least that we know of). I doubt very much that we will have it any time soon either (I may have been out of DSP research for 20 odd years but I know people still in the field, and in machine learning / AI).

It's not a beancounter problem that we don't have this kind of tech either - the amount of money and brain power thrown at it is enormous - it is hard (and maybe impossible).

And how exactly does that stop the crew stalling the a/c when so informed ? How deterministic ? What level of false alarms ? How would crew reaction to a false UAS alarm be different to crew reaction to a real one [i.e. how many 447s are you going to cause] ?

What exactly is the rest of the a/c system going to do when it gets your DSP warning / alarm ?

- drop the a/p (you can't keep it in on suspected-invalid speeds) ?
- drop the protections (ditto) ?
- change control law (you aren't proposing a new FCC, just a new UAS detection, right) ?

And is that not exactly what happened ? And what did the crew do as a result ?


If only repeating it made it right, or made it that simple.

Let's try some real info shall we ?

https://data.epo.org/publication-ser...45&ki=A1&cc=EP

Note that:

1. It's a patent so it's a PITA to read - but it gives us the benefit that its contents are legally stated under penalty of perjury (I think - may vary a bit with jurisdiction).

2. Note the filing date. This is state of the art, and post-447.

3. From the background statements on P3:
4. The technical detail clearly states at least one reason why the suggestions you've made and linked to above are somewhat over-simplistic (being kind).

5. The proposed solution is not DSP (it might use it but it is so insignificant that DSP is not mentioned). It's about the sensors and the physics. Always assuming this idea even works at all and at an acceptable error rate [neither of which is a requirement for filing a patent]



Finally, this crew knew they had UAS - "we’ve lost the speeds". That isn't the problem.

To what level of conciousness that knowledge penetrated at that time of night may be relevant - neither pilot seems to have processed "15degrees up at MAX ALT".

More relevant, however, is that when correct speed information came back (30s) and needed to be acted upon (in the window before they went so far out of the envelope that all airdata was bunk), it was (probably) not believed.

Detecting and alerting UAS is only (or less than) half the problem - you also need to detect and inform when the UAS event has ceased.

Feel free to post your patent number when you file :-)

UAS early warning. A K.I.S.S. approach
 

Hi,

infrequentflyer789:

Quote:

---

...but the magic "DSP" solution is getting a bit silly.

---

I am here looking for aviation safety and motivated to discuss concepts, etc. related to it. I am a R&D professional always motivated to look for solutions. Your comment sounds a little bit "non motivating" for me to reply in detail on the improvement that IMO can be made to the important UAS issue. Anyway i will try to explain something feasible.

You need to process the analog signals before entering the System. Doing that you may have an information very useful mostly if System degrades the A/C and (currently) not present properly the reason for. The idea is to have an analog signal processing helping the crew with a redundant information. False positives would not cause problems and the sensitivity could be adjusted.

I dont´t like the approach to just rely on System output to diagnose what´s going on.

The UAS processor would not be there to solve anything. The machine would be an extra (IMO important early warning) resource to help the diagnose.

I mentioned the Airbus SAS paper but the other companies could also benefit from this approach, for the crew decision making. (The subsystem just presenting information to the crew)

Nothing automatically.

No method? :mad:

The concept is simple: Process the analog signals and present it to the crew, immediately. How? There are simple and effective ways to do.

A "half" that triggered a cascade of events

No problem

Some ideas an R&D professional could publicly with the sole intent to a faster implementation. :) (IBM PC x Mac, as an example).

Not magic, just a powerful processing to help the crew. This can be implemented!

I am not in this business. And no intentions to invest in it, currently.

On the "misleading", this is to be covered in another Thread. Will do it ASAP.

HF and training
 

Hi,

infrequentflyer789:

Quote:

---

Finally, this crew knew they had UAS - "we’ve lost the speeds". That isn't the problem.

---

IMO, problem is When you lost confidence in the machine you are operating.

If you bury (or not present assertively) an information of this magnitude you may have a situation when a non properly trained crew could be confused. I commented in an early post on the Albert Schweitzer quote. "Confidence is the greatest asset of any successful enterprise..."

Pitot-static failure
 

Gotta admit, but detecting the pitot-staic failures due to icing and bugs or tape over the ports is different than detecting an electrical failure to the probes.

Only incident I had was a static freeze as I descended thru icing conditions ( heaters had failed). Was a no-brainer, as altitude on the steam gauges froze and IAS increased as I descended at a constant pitch. The HUD flight path marker stayed where it was supposed to, so very obvious what the problem was.

With AF447, a convenient flight path marker( derived from inertial data) on a HUD or some other display might have saved the day.

Comparing inertial/GPS data with the pitot-static measurements is hard in the cruise mode. The inertial data is noisy with altitude, and GPS altitude data is worse. The best display for we pilots is a flight path marker that shows what we are doing WRT the local horizontal. Don't even need AOA.

No comment/critique on PF actions, especially after comment "lost speeds".

Man-machine interface
 

Hi,

gums:

Quote:

---

With AF447, a convenient flight path marker( derived from inertial data) on a HUD or some other display might have saved the day.

---

:ok:

Following procedures from the start certainly would have as well...

Hunter is absolutely right. Round and round we go trying to produce the foolproof system, and we need to remember what they say about those.

As I said on 27 Aug here - all jolly good stuff, but we have - as 'standard' - 2 pilots and triple sets of instruments to allow us to try and determine the 'valid' indication, using Human intelligence. Trying to present yet another 'AI' system which will 'solve' the problem is asking for trouble, and also assuming that the human part of the system is:-
a) Going to notice
b) Going to understand
c) Do the right thing.

AF447 blows that out of the equation. Here you all are looking presumably at yet another set of chimes/mail or female voice messages/ECAM indications/flashing lights whatever. I suspect all would have been wasted in AF447 and they would have hit the SA with even more warnings.

Icarus rules, in a way? Don't fly too high, son.

BOAC

a) Going to notice
b) Going to understand
c) Do the right thing.

No new chimes, no new nuthin. 'Display the results from each Pitot head'* and let the pilot consider turbulence, Windshear, P-Heat, etc. for the cause of the discrepancies.

447 did NOT have a redundant air sampling system. It was repetitive, not redundant, there is a major blunder in merging data from three sources that use the same equipment in three different locations. Using different models would only be partially better. If all the computer is doing is averaging within parameters, that isn't Ai at all, it is not even modern computing.

Would you be happy with a common N1? An average heading? Listening to two radios on different freqs?

* displaying separate results to the pilots as well as the computer is redundancy.

- think about that - these guys could not even read an AI or altimeter.. - you have lost me there - wtf is one of those?
I don't believe there was a problem with N1 (apart from 'too many') or heading? Radios - did it a lot of the time. Most pilots do. Lost me again!

Lyman - I think I'm going to have to pass on your posts:ugh:

Lyman,

sure you know the difference between the median and the mean?

What told the AP and AT to disconnect?

The ADR fault detection consequent to the blocked pitot tubes. If there's an air data fault, AP and A/THR are automatically disconnected.

Chapter 10. Navigation

TTex600


TTex600 What told the AP and AT to disconnect?


There's a civil question. My question from the beginning, since it is likely that the crew had more experience with autopilot loss due to exceeded control limits than
"UAS". "vitesse douteuse". At 447's date with fate, the abnormal was called

Unreliable speed.

Tex, I believe the crew did NOT know exactly what caused the loss of autopilot, not immediately. Immediately is the standard. It was referenced at 2:16.0, when the PNF said "lost the speeds". It was at 2:22.0 when the PNF said " Alternate Law".

Rather than repeat the propaganda that has most here believing the speeds problem was known right away, I will simply say that bit is not known except at those two indexed times, from the CVR.

So it occurs to me that a conference among computers should have extended an invitation to the flightcrew to be privy...

If, since the timing is not known except at 2:16:0, the PF may have thought the a/p quit due to its computed conclusion that it was unable to command sufficient controls deflection by its Parameters of operation. There was turbulence, and it would have been a possible determination. Possible.

A casual look at the graph of Vertical speeds and g shows a heavy moving around like a trainer, at least possibly. Possible.

PF could have missed the speeds issue on his PFD, he also could have missed the Law degrade, which is very important. It is important because when the a/p quits due handling in turbulence, on this aircraft, it remains in NORMAL LAW.

Was this possibly his foundation? Possible?

Final report:
1.16.3.1 Analysis of the initial sequence
Analysis of the FDR parameters and of the data contained in the two FMGECs’ nonvolatile memories showed that:
ˆˆ The ADR 2 speed fell between 2 h 10 min 03.5 et 2 h 10 min 05;
ˆˆ the ADR 1speed fell for less than one second from 2 h 10 min 04 s to 2 h 10 min 05, causing:
- the disconnection of the autopilot,
- the triggering of “PITOT PROBE” monitoring in the FCPC causing the transition to alternate 2B law;
ˆˆ The ADR 3 speed fell temporarily from 2 h 10 min 07 s to 2 h 10 min 10 s, causing, in the following second, the loss of autothrust and the disappearance of the Flight Directors; it then fell again at 2 h 10 min 14,
ˆˆ The speed on ADR 1 fell again at about 2 h 10 min 08 s, causing the loss of the autothrust and of the flight directors within the next second.