AF 447 Search to resume (part2)

[kilomikedelta]

syseng68k; as chronicled in the "Lightning Empiricist" www.me.utexas.edu/~longoria/paynter/hmp/LITENING.pdf

[RR_NDB]

Common mode errors

Hi,

Could a scenario like this have robbed the crew of precious time needed to make corrections?

Difficult question! (Presented by an "instrumentation professional")

We could pinpoint the moment the AS started to change in respect to "ground speed" (supposing AS sensors LYING and presenting the "identical" info.) BEA is doing all necessary correlations.

But i understand your question is no about BEA task. Is for the System: Until the point (time) the sensors present different info. how to detect they are "failing"?

The "band-aid" we learned is being considered using (for short periods) other references could reduce the criticality of the issue: Reliable "speed info." required by the System.

But the only way to "kill" adequately the issue is with really redundant AS sensors. The ideal is to have at least three (methods) allowing a "voting scheme".

Again AoA comes to my mind...

How the System could work properly if ALL AS SENSORS "lie" to it? How it can detect? Detectors, (sensors) if the System requires (the truth) the real AS, can not LIE together. It´s simply dangerous (to the a/c). And can (i guess) today generate undetectable "strange behavior". Introducing "extra components", not just "robbing precious time".

[Golf-Sierra]

Simply, because (it seems) there are no solutions yet available (sensors) to have the (could provide) required redundancy.

Or is it more a question of history and evolution? First: why is airspeed so relevant? (a) It is a measure of the performance of the aerofoil/airframe (stall/buffet/structural limits), (b) It allows ground speed and track to be calculated, (c) it is a convenient way to ensure separation of aircraft within the same moving mass of air.

1. Initially - given the availability of purely mechanical instruments - the pitot-static system was the easiest way to calculate airspeed.

2. As the aircraft became more complex, the system was multiplied to ensure redundancy.

3. As aviation evolved - everyone got used to using airspeed for the reasons (a)-(c) mentioned above.

4. Flight control/navigation systems evolved - in order to make them 'user friendly' (and backward compatible) designers retained airspeed as a key concept in these systems.

5. Digital data buses were introduced. To minimize the cost/risk of introducing these novel systems - rely as much on existing technology (ain't broken - don't fix it) - hence we rely on the pitot system (btw - invented in the 18th century).

Has anyone ever stepped back and asked - given today's technology - what is the best way to achieve (a), (b) and (c)? A 'clean sheet' approach, without the legacy of the past?

I find it hard to believe there is no other way (as an additional, redundant system) to measure airspeed. Even yet another pitot tube - albeit a retracting one - could provide a working alternative if all the other ones fail. But has anyone ever thought about it?

In an earlier post you could find patents filed by Airbus SAS on sensors (laser based).

Thanks - I'll try to find it ;-)

[CogSim]

such a common mode degradation would not be detected initially and would fool the system into believing that the A/C was traveling faster than it really was.

Difficult to know. All depends on the nature of icing/ice accrual, which we may never fully know/understand. My guess would be that the crew may have known for some time before AP disconnect that something was wonky with their KIAS. Now, in the a/c that I fly, it would take me, oh, I would say, a few seconds to suspect that something was up with the pitot-static system. That is because I have the luxury of flying a non-FBW a/c. I can't comment on how Airbus drivers are trained to respond. Are the bus drivers at this point thinking "is it the probes or is it the computer". Remember, they probably are not expecting ice at FL350. If this kind of 'thinking' occupies the pilots for, say, a few minutes, we can begin to understand how they can be distracted/fixated. Then we are back to the nature of the ice build up and how aggressively automatics responded.

[BJ-ENG]

@Diversification

"Given the availability of technologies such as GPS, Inertial navigation,
radio navigation, radar, AOA sensors - is it possible to build an avionics
package which could automatically control (and provide pilots with
information to manually control) the flight throughout all phases without requiring a pitot-static system at all?"

Thanks for the link. Nice idea, but from the description of its limitations it sounds like it would not have been of much help. One of the principles I learnt as a systems eng is the concept of Observability and Controllability(Kalman). If the controller can't observe a system state, then the system remains stable only as long as the unobservable state is also stable. ie; if a critical data measurement such as airspeed is lost (say gets stuck at some value Vk=Vk+1 etc) but nothing else changes, then the system will appear to be stable. Perturb the system, and instability is inevitable. Some systems use an Estimator/Observer swapping system to get over transients, but these are only so good close to regions of stable Operation. Redundancy of data measurement can help, but if all are afflicted by the same malaise, then failure will ensue. Maybe an AoA sensor/ sensors is the answer. If the control system is smart enough to detect the fault, then it needs to degrade gracefully and present the human operators (the pilots) with options, and not overwhelm with information overload. Automation is only as good as the interface between it and the operator, and operator skills when applied to interaction with complex automation, only as good as the procedures (human factors influenced) laid down by the systems designers. If blame is to be apportioned, do NOT lay it in the lap of the pilots.


@deSitter

Dozy and syseng68k are correct in their assertions. APL, FORTH etc are nice tools, but are not as robust as some of the stuff used for safety critical applications - type checking etc. All done to keep the programmer from inflicting bugs on the unsuspecting. In the past I have had to use assembler for time critical embedded underwing stores Mil apps, where thecode produced from the C compiler was simply to inefficient (too slow) or the task - with faster processors, and more I/O functionality on chip, this is no longer necessary. What has not been mentioned here is that software requirements devolve down from system requirements. When I retired a few years back, there was a push in various safety critical industry sectors towards a design process where a system is modelled and simulated (hardware and software) under Matlab and auto coded by the Matlab compiler. The desired effect, theoretically, is to remove the programmer from the loop, and place more of the design task in the lap of the systems engineer. Some proponents have even suggested that simulations should produce straight raw code and forget any intermediate high level code. Nice idea if you can get it to work, but in the real world, it removes a level of validation (programmer checking the high level code),and to my mind is potentially dangerous.

@mm43

I redid the calculation, and basically it is impossible to determine from it what the terminal RoD was, as depending at what time the Advisory happened, and allowing or not ACARS queue times, the outcome can be very much different.

Tend to agree. However, have you considered a crude calc to guess how
long it would take to reach VT assuming a stall with min or zero lift from
upset to sea level.

The non linear diff equation for a falling object that experiences drag is:

mdv/dt = -m.g +1/2.Cd.p.A.v.v ...... (1)

So, with terminal VT = root(2.m.g/p.Cd.A) ......(2)

Sol is v(t) = VT.tanh(g.t/VT)

From (3) you can make an estimate of the time to reach VT for step
increments in t, and then use (2) thereafter, adjusting for density p. I
suggest a Cd of 1.2 or 1.3, or else just plug in a value, say 70m/s, for VT.

[gums]

Questions for the 'bus drivers

Was wondering about training flights.

- Do you 'bus drivers ever get to see "an approach to stall" during checkout?

- How many of you have ever "felt" the burble or buzz or wing rock or other indications that your AoA is a bit high or mach is too high?

- How many 'bus drivers can recite from memory in 5 seconds what levels of protection "go away" or replaced by other sensor inputs to the FBW system going from "normal;" to "alt 1" to "alt 2" to "direct"?

[HazelNuts39]

Originally Posted by takata

In fact, in normal flight, all the sensors are already not displaying the same data by a certain margin due to their airframe location: an aircraft is almost never flying in a perfect symetrical attitude and this will cause some noticeable variation between the various sensed pressures.

I'm not quite sure how relevant this is but, IMVHO, that cannot be said of the pitot pressures.

[OK465]

I'll ask the Airbus drivers a question that has come up before: would an AoA gage (which is apparently not common in any airliner design, and for most regimes of flight a supplemental scan item) be a useful addition to the flying display?

LW50:

(Disclaimer: This is not an A versus B comment, or an AF447 comment, hopefully just a politely informative one in response to a question. This is a tough crowd.)

Most, if not all, Boeing 737 NG’s (not sure about BBJ’s or special orders) have an AOA display directly visible on both the PFD and in the HUD. Is it useful? Depends on the guy driving.

[snowfalcon2]

Golf-Sierra: I'll give this a try even if here are many better qualified participants. Bear with me

First: why is airspeed so relevant? (a) It is a measure of the performance of the aerofoil/airframe (stall/buffet/structural limits), (b) It allows ground speed and track to be calculated, (c) it is a convenient way to ensure separation of aircraft within the same moving mass of air.

a) correct, airspeed is basic for all aerodynamics.
b) only partly correct, as wind data is also a necessary input.
c) hmm...ground speed would be just as convenient, wouldn't it? At least for the purpose of calculating safe separation distances.

Has anyone ever stepped back and asked - given today's technology - what is the best way to achieve (a), (b) and (c)? A 'clean sheet' approach, without the legacy of the past?

a) angle of attack is in some respects just as useful. But to replace a pitot tube it would IMHO need to have a resolution better than 0.1 degree - not so easy to combine with 100% icing resilience I guess. And most AoA sensors I've seen are relatively delicate mechanically, compared to a pitot tube.
b) For realtime navigation, you need to use ground speed and ground track. VOR, GPS, and inertial methods all work independently of airspeed and have long since replaced airspeed and compass-based dead reckoning. For planning and routeing, fact is that fuel economics depend on airspeed, so it's most reasonable to use it, always together with wind forecast data.
c) radar, TCAS, and more recently ADS-B for ensuring separation.

I find it hard to believe there is no other way (as an additional, redundant system) to measure airspeed. Even yet another pitot tube - albeit a retracting one - could provide a working alternative if all the other ones fail. But has anyone ever thought about it?

If there was an easy solution, it would surely have been found by now. But I'd be interested to hear if this issue has existed for a long time. Or are iced pitot tubes just a recent result of beancounters ordering pilots to save on heating electricity? Surely not...

[takata]

Hi HN39,

Originally Posted by HazelNuts39

I'm not quite sure how relevant this is but, IMVHO, that cannot be said of the pitot pressures.

What do you mean? That any pitot pressure is always perfectly the same?

[BOAC]

Originally Posted by OK465

Most, if not all, Boeing 737 NG’s (not sure about BBJ’s or special orders) have an AOA display directly visible on both the PFD and in the HUD.

- news to me - got a pic?

[Nick L]

- news to me - got a pic?

Boeing 737 Flight Instruments

One of the many customer PFD options is an analogue/digital angle of attack display. The red line is the angle for stick shaker activation, the green band is the range of approach AoA.

Also, I believe an AoA indicator was/is available as a customer option on Airbus aircraft - it is a dial next to the PFDs.

[RR_NDB]

AS sensors

Hi,

Systemically speaking it is possible ("easily" today) to use two Pitot probes from different mfrs. (Fr and US) as LH and RH (main) sensors?
Question relates to calibration, etc.

[Turbine D]

takata,

In fact, in normal flight, all the sensors are already not displaying the same data by a certain margin due to their airframe location: an aircraft is almost never flying in a perfect symetrical attitude and this will cause some noticeable variation between the various sensed pressures. This is also the main reason why a clean probe system would very very unlikely be clogged (in flight) at exactly the same rate and at exactly the same time.

I am not sure how to reconcile the above quote with this quote extracted from the EASA AD No. 210-0271 dated 22 December 2010:

It has been identified that, after such an event, if two airspeed sources become similar while still erroneous, the flight guidance computers will:
-Display the FD bars again, and
-Enable AP and AT re-engagement.

Doesn't that say that that speed sensors can go from similar to dissimilar and then back to similar? Similiar at the same time as in normal cruise flight, dissimilar at the same time causing AP & AT disconnect and removal of FD bars, and then similiar again at the same time but giving wrong speed data, e.g., somehow clogged in a similiar fashion.

[BOAC]

Nick - 'customer option' is not 'most, if not all 737 NG's' in my book..

[jcjeant]

Hi,

In the press

AFP-24.05.2011

PARIS - The associations of families of victims of the crash of Air France flight from Rio to Paris Monday wrote to Prime Minister Francois Fillon to express "their deep indignation" about "the conduct of the technical investigation chaotic" and leakage in the press.

Families "you want to share their outrage and deep concern about the chaotic progress of the technical investigation" conducted by the Bureau of Investigation and Analysis (BEA), according to this letter which AFP has obtained copy.

"Since the beginning of the operation of data" contained in the black boxes rescued early May off Brazil, "we are witnessing a broad disclosure of information that should remain confidential until the final report and within the strict framework of investigation ".

Families are surprised that these leaks tend to favor the theory of human error and exonerate Air France and Airbus' under investigation as part of the judicial inquiry. "

According to families, these facts "discredit the investigative authority", BEA, and "generate much suspicion on the independence of that body against leaks orchestrated."

The four associations of relatives of victims signed the letter asking to François Fillon "to remind the different actors demands restraint, discipline, confidentiality, justice and ethics to which they would never have departed."

The Wall Street Journal said Monday that the accident of flight AF447 in June 2009 was due to pilot error and poor monitoring procedures.

According to the German magazine Der Spiegel quoted an expert who participated in the analysis of black boxes, the captain was not in the cockpit when the first alarm sounded.

On 20 May, a spokesman for the BEA stated that the investigating agency would publish this weekend "on the factual elements of the flight that will determine the circumstances of the accident, but in no way causes.

[OK465]

BOAC & Nick:

Nick's HUD picture reference does not have the AOA display. The PFD picture in the section dealing with Integrated Approach Nav (IAN) & NPS shows it clearly.

That would be repeated in the HUD in that configuration.

BOAC, you are correct, "most" is a relative term. The NG's I've dealt with have had AOA since 2001. I'm only familiar with specific carriers and all (not most) of their NG's have it.

(If you're an NG driver, you obviously don't have it. I apologize for exaggerating.)

[HazelNuts39]

Hi takata;

I mean that as long as the pitot tube is outside the boundary layer (and it is), the pressure inside is insensitive to small variations of the local flow angle.

[Nick L]

BOAC:
Sorry for the misunderstanding on my part - thought you were questioning the availability of the AoA indicator, rather than its prevalence.

[syseng68k]

kilomikedelta, #2276

syseng68k; as chronicled in the "Lightning Empiricist" www.me.utexas.edu/~longoria/paynter/hmp/LITENING.pdf

Ok, I give in. Looks like I have exposed one of my more anorak
tendencies . Am familiar with Philbrick Research and have seen their
early brick op amps in use, as well as Analog Devices and Burr Brown
parts. And yes, I do buy and read books on early analog computers, as
well as oddball things like a half complete set of Rad Lab volumes. Sad
really, but it's surprising how much of that early work is still
relevant today. The history of electronics and computing can be a rich
source of ideas for modern day designs. For example, embedded systems
with very limited resources.

You probably know this, but if you want to be astounded, take the lid
off an early electromechanical inertial nav system. It's doubtfull if
there are many engineers left in the world now who have the
multidisciplinary skill set to even start to design such a system...