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

Common mode errors
 

Hi,

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

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?

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

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.

@Diversification
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

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.

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

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

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.

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

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.

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.


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

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

- news to me - got a pic?

Boeing 737 Flight Instruments

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

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.

takata,

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:

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.

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

Hi,

In the press

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

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.

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

kilomikedelta, #2276

Ok, I give in. Looks like I have exposed one of my more anorak
tendencies http://images.ibsrv.net/ibsrv/res/sr...s/embarass.gif. 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...

syseng68k; 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... Modern work is dependent on all that early work, which is why it is still relevant but no longer taught. Pity how new engineers are poorly grounded in the broad aspects of their craft. It's like my business - recently trained practitioners can't make a diagnosis in the basis of conversing with a patient - they need the imaging technology. Cheers, K PS - I could probably still write a RTOS in 16K of machine code.

AF447 latest info
 

Just received.

Black Boxes Point to Pilot Error

By ANDY PASZTOR And DANIEL MICHAELS

(WSJ) The pilots of an Air France jet that crashed into the Atlantic Ocean two years ago apparently became distracted with faulty airspeed indicators and failed to properly deal with other vital systems, including adjusting engine thrust, according to people familiar with preliminary findings from the plane's recorders.

The final moments inside the cockpit of the twin-engine Airbus A330, these people said, indicate the pilots seemingly were confused by alarms they received from various automated flight-control systems as the plane passed through some turbulence typical on the route from Rio de Janeiro to Paris. They also faced unexpectedly heavy icing at 35,000 feet. Such icing is renowned for making airspeed-indicators and other external sensors unreliable.

Ultimately, despite the fact that primary cockpit displays functioned normally, the crew failed to follow standard procedures to maintain or increase thrust and keep the aircraft's nose level, while trouble-shooting and waiting for the airspeed sensors and related functions to return to normal, according to these people.

Slated to be disclosed by investigators on Friday, the sequence of events captured on the recorders is expected to highlight that the jet slowed dangerously shortly after the autopilot disconnected. The pilots almost immediately faced the beginning of what became a series of automation failures or disconnects related to problems with the plane's airspeed sensors, these people said.

The crew methodically tried to respond to the warnings, according to people familiar with the probe, but apparently had difficulty sorting out the warning messages, chimes and other cues while also keeping close track of essential displays showing engine power and aircraft trajectory.

Spokesmen for Air France, a unit of Air France-KLM, and Airbus, a unit of European Aeronautic Defence & Space Co., have declined to comment on any details of the investigation. Airbus last week, however, issued a bulletin reassuring airlines that the preliminary readout of the recorders hasn't prompted any "immediate recommendation" regarding the safety of the global A330 fleet. French investigators, who gave the green light for that statement, also have said their preliminary findings don't highlight any major system failures or malfunctions that could have caused the fatal dive.

The Air France pilots were never trained to handle precisely such an emergency, according to safety experts and a previous report by France's Bureau d'Enquetes et d'Analyses, which is heading up the investigation. All 228 people aboard Flight 447 died in the accident.

The senior captain, Marc Dubois, appears to have been on a routine rest break in the cabin when the fatal chain of events started, according to safety experts familiar with the details, but the cockpit-voice recorder suggests he may have rushed back to the cockpit to join the other two Flight 447 pilots.

Though Friday's announcement won't provide final conclusions or specific causes, investigators believe Air France didn't train its pilots to cope with such automation problems in conjunction with a high-altitude aerodynamic stall, an emergency when the wings lose lift and the plane quickly becomes uncontrollable. Since the crash, Airbus and a number carriers, including Air France, have emphasized such training.

According to a report issued by French investigators in November 2009, Airbus identified 32 instances involving similar model jetliners between 2003 and 2009 in which external speed probes, known as pitot tubes, suffered ice buildup at high altitude and caused "erroneous air speed indications." Over the years, the same models also suffered numerous failures of external temperature-sensors because of icing. Both issues were known to Air France.

Most of the incidents with speed sensors involved probes similar to those on the A330 that crashed. Many were on Air France planes, according to the BEA report.

Friday's update follows sniping between senior officials of Air France and Airbus, usually close corporate allies, who in this case have tried to shift the blame for the accident to each other.

Air France began addressing problems with its pitot tubes almost a year before the crash. Amid several incidents in which air crews lost speed indication at high altitude during 2008, Air France reported the icing problems to Airbus. The two companies discussed solutions and Airbus talked to its supplier.

In April 2009, roughly 45 days before the crash, Airbus proposed that Air France swap out its pitot tubes for a different model believed to be less prone to icing, according to the BEA report. Air France began the work on April 27, 2009, and it received the first batch of new pitot tubes six days before the crash. The plane that crashed hadn't yet received the new equipment.

According to the 2009 report published by investigators after the crash, experts examined 13 other incidents of airspeed-sensor malfunctions on Airbus widebody jets at cruise altitudes. During most of those global incidents-none of which resulted in a crash-both the autopilots and automated engine-thrust systems disconnected on their own, and it took many of the flight crews up to a minute to manually adjust engine thrust.

The earlier report found that pilots in nine of those 13 events received warnings of an impending stall. And in a finding that may have particular relevance to the upcoming update, accident investigators in 2009 also concluded that when airspeed-sensor malfunctions kick off automated thrust controls, "the absence of appropriate manual adjustments" to engines "can present a risk" of a mismatch between power settings and the jet's orientation in the air.

Investigators began focusing on pitot problems from the start, because Flight 447's automated maintenance system broadcast 21 separate messages related to such malfunctions during roughly the last four minutes of the fatal flight. But the final report, which may not be released until 2012, also is expected to delve deeper into how European air-safety regulators dealt with persistent reports of pitot-tube icing prior to the crash.

The previous interim report indicated that in late March 2009, less than three months before the crash, European aviation regulators decided that the string of pitot-icing problems on widebody Airbus models wasn't serious enough to require mandatory replacement of pitot tubes

I wonder if the WSJ author's have just watched the year old BBC/Nova documentary?

No mention of a control system protection triggered zoom-climb for a while?

Smilin Ed quoting slats "If these systems fail, then control is thrown back to the pilots...."

As Self Loading Freight I find the thought that the automation flies the plane almost exclusively when things are going well and then when things get tough toss it into the laps of pilots who might otherwise get fired if they try to actually fly the plane rather than babysit some automation to be rather troublesome.

Something must be done so that the pilots, even if they are sitting there yawning with nothing to do, are intimately aware of the feel of the plane as a plane at all times. That way when things get tough the transition is not quite such a hostile appearing event.

The current situation might even be made nicer of a row of buttons appears on a touch screen display with options like, recover stall, slow down, TOGA thrust, AOA, and so forth so that the pilot can assist the automation in picking the strategy to deal with data that confuses the automation. The automation can probably react quicker. But the meatware can probably solve the problem quicker - today. (Yeah, I gotta add that proviso. I've seen some amazing "stuff" in the software world. One begins to feel redundant.)

As SLF who is old enough to remember such comedy routines as "Grace L. Furgesun Airline and Storm Door Company" or Bob Newhart's gems I surely can... surely can... surely can... surely can...

(Is it time to panic yet?)

I recall that after the initial advice (following 447) to replace the dodgy Thales probes, there were not enough Goodrich ones to go round, so it was suggested to use a mixture. I don't have a reference to hand though and not sure if it was AB recommendation or regulator or both. Also, it may only have been allowable as temporary measure.

I would have a general concern (maybe you share) that different probe types with slightly different calibration & response might lead to more (spurious) unreliable airspeed events. Now, if the problem is all probes failing in same way pushing the a/c out of the envelope before the unreliable airspeed reported, then maybe this is good... but if the problem is pilots mishandling reported unreliable airspeed, then maybe this makes things worse.

wozzo, if that WSJ quote resembles what actually happened I do not figure that is pilot error. I take that as a system design failure, which falls into the AirBus lap.

ion berkeley, I'm glad I am not the only one here who might defend Ada. I have seen it work very well to produce military grade software under budget and with far fewer bugs than normal for the size of program involved. They performed to spec and that's what made the company money. If the spec was wrong, that's the DoD's problem (and, sadly, the soldier's problem.)

Ada works very well because you cannot write software with it without very clear "premeditation" for what you are doing. (Yes, I know, a real hairy chested programmer can write FORTRAN in any language. Trust me, it's harder in Ada than in most languages.)

It is also current. The latest release of the Ada specification is a preview of the scheduled 2012 version.

For commercial stuff Ada doesn't work very well because commercial software is seldom thoroughly defined and then developed without massive changes in direction. It is a very capable language. It is rather inflexible, resistant to changes and errors.

I would have a general concern (maybe you share) that different probe types with slightly different calibration & response might lead to more (spurious) unreliable airspeed events

Probably not something to worry about.

Caveat - the following is generic, not AB specific.

The pitot tube basically is a bit of water pipe facing forward into the wind (it can tolerate modest out of into wind alignment) and with the other end hooked up to the aircraft's innards. One bit of tin pipe is going to be much the same as another. The only fancy bit is some heating to avoid the thing's icing up.

Generally, system errors (providing the pipe hole is not blocked) are not due to the pitot - but may well be due to static port problems. Apart from icing and like physical obstruction, pitot installations are remarkably reliable.

Mixing up the OEM pitots provides some interim redundancy for icing considerations pending the supply chain's catching up with demand for OEM changeover.

A more pressing question is: whose conclusion is it at this point? 1) BEA's, 2) the paper's sources (which I would presume is somebody at or close to NTSB) or 3) the journalist's (as a conclusion of his gathered information)?

At least in respect to 1) we will know more Friday.

Wall Street Journal Report

There is something rather obvious in the WSJ story, i.e. there is absolutely nothing new, and furthermore the unnamed source(s) would appear to be "pick ups" from European papers. The authors IMO have created a story to fill a void, and in doing so have joined the likes of the News of the World etc..

There are better stories on this thread, though not everyone agrees.;)

Hi,

From the day one of the first leak (printed in Le Figaro and coming from ?) it's nothing new ..
Just parrots who repeats at length of articles:
The pilots made mistakes and the Airbus A330 is not an issue

It's a long time ago that I worked on military stuff, but "thoroughly defined" and "developed without massive changes in direction." are not really characterisitcs I'd associate with it ! "Sufficiently ill-defined that the contractor can absolutely guarnatee to claw back overruns (and under-quotes) in change control," and "subject to random changes in direction so often that by the time you go live no one can remember what the original threat was" would be more like it. Maybe I'm too cynical though.

Also, I think those that think Ada has dropped out of use just don't appreciate mil-spec project timescales. I've used Coral 66 (predates Ada by a lot of years) and the last time I was offered work in it (by idiots who just keyword search CVs without reading them) was not many years ago - I suspect it is still in use today...

Having throttles move via actuator to show current thrust level and trending, like Boeing does, would be a start.

Watching throttles physically retard during cruise might have been helpful to this crew in keeping SA.

The Problematic Surface Currents - some answers?
Thanks for posting the link to this well presented Ifremer summary (in French) of the surface current research they have undertaken.

Additionally, detailed research by the University of Massachusetts' FVCOM group based at Dartmouth, MA, supported by the Woods Hole Oceanographic Institution at Cape Cod, MA, has resulted in methodology that is now capable of making sense of the surface currents in what was a poorly understood area of circulation in the equatorial latitudes of the North Atlantic.

The currents and resulting drift patterns in this area are irregular and the drift tracks so found also provide some answers as to why the aerial and surface searches failed to find debris and bodies in the first 5/6 days of searching.

Both UMass Dartmouth and WHOI were represented on the BEA's Drift Group, and in the intervening period since then have continued their research, which I am advised will be made public in due course.

That would be the moment the aircraft instruments are turned on. Air moves independently (more or less) of the ground below. Planes go through fronts. The trick is to isolate a set of "signatures" for pitots freezing up. Then you pray that set is exhaustive while knowing in your heart it's not even close.

KMD - 16k seems to be a very fancy advanced RTOS to me. The OM-55 Navy SatCom modem used 32k for the entire program and had 16k, with spare space, for RAM. This involved a full multi-tasking (time sliced) operating system - on an 8080. (They cost $100 a pop when it was designed.) The kernel portion was under 1k. The IO routines were small. The rest involved maintaining the DSCS satellite communications protocols running, demodulating the data, and feeding it all to the output while running the modest control panel.


edit: By the way Philbrick is in my engineering DNA. I started designing professionally in about '65 - as in getting real pay for it. And the first job or two involved operational amplifiers with these new fangled RA-909's.

Unfortunately, a number of people already died in a field near Schipol to disprove that.

If it's handled properly, unreliable airspeed in cruise in a Bus is not fatal - long list of previous incidents show that. Something else happened to 447 - either something else went wrong with the a/c, or the crew; we don't know what yet (whatever the press says).

Yankee Whiskey, that report certainly looks fully as self-serving for "certain parties" as the other "leaks" I've seen. I am betting these are "leaks" from various interested parties rather than from inside BEA. If they are from people privy to the BEA deliberations I bet the data being released is very carefully selected and given a proper propagandistic spin. It's becoming somewhat of an embarrassment to the whole industry.

infrequentflyer789, the proper way to handle changes like that is to charge what it costs and profit margin to recode and KNOW what that cost is. With Ada that is expensive. It tends to get the military to better define the problem.

(It helped that this was on the DSCS satellite and that Magnavox (in Torrance Ca) was the major ground systems developer. We understood the machines. And we understood how to use then in networks. The military provided the controls they wanted and we provided the rest. We came in under budget even after the changes requested. Two other projects not so intimately related to the company's hardware work also came in under budget on Ada. They all worked very well going through formal acceptance tests without failures.)