Go Back  PPRuNe Forums > Flight Deck Forums > Tech Log
Reload this Page >

AF 447 Search to resume (part2)

Tech Log The very best in practical technical discussion on the web

AF 447 Search to resume (part2)

Old 23rd May 2011, 11:16
  #2161 (permalink)  
Join Date: Jan 2008
Location: Blighty (Nth. Downs)
Age: 74
Posts: 2,084

Quote from amos2:
Chris Scott, an A320 driver, is one of very few current pilots on this thread who knows what caused this prang... as most current professional pilots do!

Sorry to disappoint you, but I:
(1) retired some years ago;
(2) do not know the cause of this accident (yet);
(3) doubt that "most current professionals do".

In air-transport operations, finding yourself flying with someone with a tendency to arrogance and closed mindsets can be very tricky indeed, as many of us know from our own and others' experiences. In the latter decades of the last century, we made some progress in eliminating those attitudes from airline cockpits. Fortunately, their prevalence in PPRuNe is unlikely to be a threat to air safety.

With no offence intended,

Last edited by Chris Scott; 23rd May 2011 at 23:12. Reason: Last para simplified.
Chris Scott is offline  
Old 23rd May 2011, 11:25
  #2162 (permalink)  
Join Date: Jul 2002
Location: UK
Posts: 3,182

Your colleague is absolutely right, though I suspect that syseng68k was not so much being optimistic as playing to the layman crowd on this thread. I think if the average person heard from the engineer's point of view that there was any chance of failure in the things we design and build (something generally accepted by engineers) they would never get in a car, work in a tall building or even cross a bridge, let alone board an aircraft! Engineers amongst themselves tend to be more openly realistic, if not pessimistic, about the chances of failure - which is why dyed-in-the-wool engineers tend to make lousy salespeople and managers!

As I've said before, complexity is the enemy of any engineered system, whether that be civil, mechanical, or software. So we're all trying to strike a balance between enough complexity to get the job done versus making it so complex that the odds of Byzantine failure become unacceptable.

With every new generation of technology, engineers are being asked to extend the feature set and improve performance, all the while having to keep an eye on the complexity of the system - in much the same way that aeronautical engineers forty years ago were being asked to design aircraft that were larger, faster, flew further and could carry more cargo and passengers. By and large the solutions worked, but there were always issues that crept out of the woodwork, some of them many years - even a decade or more - after the aircraft entered service.

So, in terms of the software we all use at home everyday, some developers were quite happy to simply cram features in with minimal testing - the most notorious example of this being the state that the Microsoft Office suite had got itself into at the turn of the century. In terms of the real-time safety-critical software used in aviation, that is and has always been verboten. It's not perfect and it never will be, but ultimately this is something common to all aspects of engineering and always has been.
DozyWannabe is offline  
Old 23rd May 2011, 11:54
  #2163 (permalink)  
Join Date: Jun 2009
Location: Oxford, England
Posts: 297
Phew!...after reading a lot of rubbish on prune over many years this thread of 100 plus pages is the biggest load of nonsense I've ever read on prune... this has to take the cake!
It seems that your coffee displeased you this morning sir ? .

There will always be a proportion of noise in an open forum like this, but there are many, other than professional pilots reading this thread who would really like to know what happened.

Enquiring minds want to know etc...
syseng68k is offline  
Old 23rd May 2011, 12:07
  #2164 (permalink)  
Join Date: Jun 2009
Location: Oxford, England
Posts: 297
DozyWannabe, #2114:

For the techies on this thread, I've managed to dig up this report from my old Software Engineering/Reliability professor, Peter Mellor. In it, he details the visit he made to Airbus Industrie in January 1993
Interesting report and just confirms what I had seen in terms of rigorous development standards. Interesting set of references at the end as well. From the description, it looks like the code was not running continuously, but was run in a strict sequence with each module running to completion. Started by a system tick clock and probably no rtos. In those days, probably no interrupt driven hardware and no stack usage either. Effectively, a hardware state machine equivalent...

Good stuff and thanks...
syseng68k is offline  
Old 23rd May 2011, 12:19
  #2165 (permalink)  
Join Date: May 2011
Location: Orebro
Posts: 1
Details leaked

The German news magazine Der Spiegel claims that they have some inside information from the investigation. Afaict with my knowledge of German the article says:

The first pilot was not in the cockpit at first when the catastrophic events started, but he came running in, shouting instructions.

The speedometer ("Geschwindigkeitsmesser" they write in the article) was iced over (I suppose this is the pitot tube, but aren't there several?)

The plane did a steep pull-up, not clear if this was pilot induced or computer induced

No severe turbulence preceded the catastrophic events
ergaster is offline  
Old 23rd May 2011, 12:25
  #2166 (permalink)  
Join Date: Mar 2002
Location: Seat 0A
Posts: 8,129
Originally Posted by Mountainbear
I went back and read the reports to refresh my memory. I don't know where you get the idea the the design of the ADIRU was supposed to isolate the spurious signals, but that's wrong too.

As for whether the ADIRU was a dud the 2nd Interm report clearly states it was not.
I didn't say that the design of the ADIRU was supposed to isolate signals. I said "the system" didn't isolate the signals. Read my lips. Given your "no fault found" comment, you obviously have little real-world aviation experience, especially with computerised aircraft.

To put your mind at rest, that I was telling the truth, I quote from one of the ATSB reports (Interim factual tab on this page):

The investigation to date has identified two significant safety factors related to the pitch-down movements. Firstly, immediately prior to the autopilot disconnect, one of the air data inertial reference units (ADIRUs) started providing erroneous data (spikes) on many parameters to other aircraft systems. The other two ADIRUs continued to function correctly. Secondly, some of the spikes in angle of attack data were not filtered by the flight control computers, and the computers subsequently commanded the pitch-down movements.
As I said: ADIRU 1 sent dud signals to the system (FCCs), which didn't compare dud signals with the two sets of good signals and then made the aircraft uncontrollable - twice.
Capn Bloggs is offline  
Old 23rd May 2011, 12:33
  #2167 (permalink)  
Join Date: May 2002
Location: GC Paradise
Posts: 1,056
gums said,


Sorry, Flex, but the old mil-specs required approx 4 pounds per gee. The Viper approximates that very well due to the computers. Older jets had springs, dashpots, bobweights and bellows to "stiffen" the stick.
gums is right and I stand corrected! I am not sure which missing brain cell prompted me to say aft stickforce of one lbf/g for the F/A-18. I am far removed from those days. On reflection I think it was closer to 6 lbf.

If you knew where I was coming from, you would understand my extreme embarrassment!
FlexibleResponse is offline  
Old 23rd May 2011, 12:36
  #2168 (permalink)  
Join Date: Aug 2007
Location: sydney
Age: 57
Posts: 464
There is an enormous variety of problems with computer-based systems in aerospace contexts, the number of incidents is clearly increasing, and I fear will continue to do so.
The philosophy underlying all this increased technology is a bit of a challenge to come to terms with isn't it? There are a lot of agendas and factors at play.

1. Accident investigations repeatedly cite human factors (decision making, knowledge, communication, CRM etc) as the most common contributor to the accident. It therefore makes sense to try and reduce this dependence on humans as much as possible. And overall, safety appears to have increased in line with this.

2. At the same time, we have ever-increasing technology allowing us to go down this route. And huge corporations with vested interests in promoting this expensive technology as the way forward.

3. So far, so good. But (and there is always a but), this will inevitably lead to an increasing and insidious disconnect between the pilot and the aircraft. Manual flying skills have likely degraded somewhat. Pilots now may have less situational awareness than in years gone by. There is perhaps a tendency for them to not fully understand all the systems - they know how to operate them under normal conditions sure, but is it possible for them to really understand what is happening when a serious problem suddenly appears out of routine. I accept that all this is a generalization and a gross over-simplification. But even so, is there some truth in this?

4. If these systems fail, then control is thrown back to the pilots. Presumably you would then want the interface between the pilot and the aircraft to be as intuitive as possible, you would want full control authority, and you would want to encourage the pilot to actually fly the aircraft. Is this what the pilot gets however? Or do they get pages of warnings on their displays, information overload, confusion about what is happening, and some unfamiliar degraded flight law?

Overall, the statistics suggest that we are on the right track. But every now and again (and almost at random) the holes will all line up.
slats11 is offline  
Old 23rd May 2011, 12:54
  #2169 (permalink)  
Join Date: Jun 2009
Location: Hamburg, Germany
Age: 41
Posts: 38
Fact Sheet

Just a little reminder, as I stated yesterday, we do not really know much more than three months ago.
DenisG is offline  
Old 23rd May 2011, 13:25
  #2170 (permalink)  
Join Date: Aug 2005
Location: London
Posts: 78
Who knows what happened?

Chris Scott, an A320 driver, is one of very few current pilots on this thread who knows what caused this prang... as most current professional pilots do!
I am sure Chris and the other professionals on this thread are flattered by the confidence shown but I doubt any of us would claim to 'know' what happened. We don't even 'know' that the aircraft was in extreme turbulence, or that it was involved in a 'super stall', as many seem to believe. Sure, we have a few hunches and most of us would guess that the combination of unreliable airspeed, surprise, an orchestra's worth of warnings, night, and presumably turbulence, could easily overwhelm the best.

For my part I suspect that when the facts of what happened are revealed (not long now) the discussion will then dwell on how well prepared the crew (any crew) were for such an event. Most pilots learn their trade on light aircraft with straight wings, direct controls and modest performance; the transition training to high performance swept wing jets spends most of the time on systems issues, and relatively little (none?) on the subtleties of the new environment in terms of basic handling. I have said in earlier posts, on the previous 447 thread and the A320 crosswind landing event, that the outward similarity of the basic C* control laws on the later Airbuses to earlier conventional controls disguises some even more subtle differences that demand changes in the way pilots react when left in sole charge of the beast. I don't believe adequate consideration is given to these matters in training. I hope people will consider that before condemning the unfortunate AF crew.
gonebutnotforgotten is offline  
Old 23rd May 2011, 13:31
  #2171 (permalink)  
Join Date: Nov 2006
Location: SoCalif
Posts: 896
Originally Posted by Graybeard
Airspeed and altitude are separate and unique functions within the ADR, except at low speeds, and their output data bus words are separate and unique. An ADR may flag or put out erroneous airspeed without affecting altitude output.

Takata replied:
Each ADIRU module is separated in two: ADR+IR. If you are turning OFF the faulty ADR part because of unreliable airspeed, you will also reject all the associated static and AoA probes. Hence, if all three are rejected, you are only left with your standby instruments.
Do you really know the fault logic of the ADIRU, Takata? You're saying that faulty airspeed is turns off all air data and AOA outputs from the ADR? I think you have confused ACARS report with reality. The ACARS report is to aid the tech at destination in troubleshooting to the level of the offending LRU, Line Replaceable Unit.

Arinc 700 design was finalized in the late 1970s, and first adopted on a whole airframe in the 767. That design mandates multiple sensors; simple sensors if you will. The Sensors, such as LRRA, ILS receiver, ADR, IRU, etc., put out data words with Sign Status Matrix of Normal, or No Computed Data, or Fail Warn. Filtering and judgements within the sensors are not as extensive as they could be. It is up to the user of this data, FD, AP, display, to filter and compare the data from multiple sensors.

LRUs often contain unrelated functions to minimize the number of LRUs and associated wiring. The VOR receiver, for example, also contains the Marker Beacon receiver, which was a separate LRU prior to Arinc 700.

The LRU is required to put out valid data for each function when it is available. The ADR shutting off its altitude and AOA outputs when it suspects its airspeed input is faulty, is nonsensical, and would be unsafe. AOA is needed more than ever when the airspeed is faulty.

BEA stated that the TCAS Fail on 447 was due to its internal monitoring of altitude. That altitude comes from the transponder. BEA doesn't explain why there wasn't also ATC Fail. There should have been, if the altitude it received from the ADR was faulty.

Yes, my knowledge and experience suggests BEA was mistaken on its assessment of the TCAS Fail.
Graybeard is offline  
Old 23rd May 2011, 13:41
  #2172 (permalink)  
Join Date: Jul 1999
Location: 58-33N. 00-18W. Peterborough UK
Posts: 3,043
LRUs often contain unrelated functions to minimize the number of LRUs and associated wiring. The VOR receiver, for example, also contains the Marker Beacon receiver, which was a separate LRU prior to Arinc 700.
ARINC 700 doesn't have a VOR Receiver. It has a VOR/ILS Receiver and it makes perfect sense to include a Marker Receiver………it’s hardly ‘unrelated’ as you claim.
forget is offline  
Old 23rd May 2011, 13:48
  #2173 (permalink)  
Join Date: Jun 2009
Location: VA, USA
Age: 55
Posts: 561

About amos2 Licence Type (eg CPL. Pilots only)ATPLCurrent a/c Type (eg B737. Pilots only)A320LocationWybacrik
A complete waste of space from technical nerds who haven't got a clue what the hell they are talking about!
A load of nonsense from ancient aviators who flew F14s, Vipers or other military types that have NO RELEVANCE WHATSOEVER to this prang!
Chris Scott, an A320 driver, is one of very few current pilots on this thread who knows what caused this prang... as most current professional pilots do!
Presumably you will deign to climb off your (almost insurmountably) high horse and put us, the BEA and Airbus out of our misery? Not only will that save additional "100's of pages" of PPRuNe being wasted, but also a sizable chunk of change being spent poncing around in the middle of the Atlantic pulling pieces of a plane out of the Ocean.

After all Chris has 'admitted' that he does not know the cause of this accident yet, nor does he believe "most current professionals do".

Let's just see how jolly clever you are?
GarageYears is offline  
Old 23rd May 2011, 13:49
  #2174 (permalink)  
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Failure mechanisms


However, a software versioning compatibility issue would perhaps fit the bill
And the "coincidence" of this in that critical moment?

The models i imagine are "hardware based" and that was the reason of my question on "system bus wiring fault".

I don´t believe too in a "lightning issue". I asked because always we must consider everything (plausible, of course).

Effectively, a hardware state machine equivalent...
Would be useful to the thread to make a short briefing on "Finite State Machines", for me a fascinating issue.

I hope the main cause(s) of this crash are simple ones, as the leaks are suggesting. But the possibilities (failure mechanisms) we have in "complex Systems" are always a concern for us. (Hardware, Software, Interfaces and "last but no least" the "way the crew" could interact with these "fascinating" Systems during a crisis). Again, there are no ways, in design phase to simulate what could happen in the real world. (The Testability issue).

Last edited by Jetdriver; 23rd May 2011 at 17:34.
RR_NDB is offline  
Old 23rd May 2011, 13:51
  #2175 (permalink)  
Join Date: Jan 2005
Location: France
Posts: 2,316
Originally Posted by JD-EE View Post
Mr Optimistic, I'd not be at all surprised if the BEA and other organizations have at their disposal a tool that "plays back" the FDR recordings into a video animation of the plane and the cockpit.
If they don't somebody should write such a tool.
Such tools exist.
Never seen the animations for the Concorde crash, or the one for the "Hudson glider"?

Last edited by Jetdriver; 23rd May 2011 at 17:32.
ChristiaanJ is offline  
Old 23rd May 2011, 14:53
  #2176 (permalink)  
Join Date: Dec 2010
Location: Middle America
Age: 81
Posts: 1,163
Hi Bear,

The DC-10 incident at O'Hare was the result of the #1 engine and nacelle separating from the pylon attachment points to the wing causing the engine to flip over top of the wing. In doing so, major hydraulic and electrical lines were either damaged or severed and the wing itself was damaged. The Captain did not know the engine separated (couldn't be seen from the cockpit) and thought it was just an engine failure and therefore followed an emergency engine out procedure. This procedure called for reduction of air speed from the 165 knots they were at to 153 knots. However, the slats on the damaged wing retracted with the loss of hydraulic fluid and pressure as there was no mechanical lock on the DC-10. When the slats retracted, the stall speed on the wing increased from 124 knots to 159 knots, so that the wing went into a full aerodynamic stall. To make matters worse the Captain's slat disagreement and stick shaker (stall warning) was knocked out by the electrical failure and American Airlines had decided not to include a stick shaker on the FO's control column. So with the loss of left wing lift, the aircraft rolled left and went down. This stick shaker arrangement changed after the accident.

I recall there being Simulator studies conducted which basically indicated, more or less, the aircraft was not recoverable once into the wing stall phenomenon.

It was a black day for AA and the FAA when the NTSB released its findings. The change in engine removal along with the pylon using a forklift truck in place of designed rigging to first remove only the engine to save 200 man-hours of labor (cost reduction) was determined to be the root cause, all accomplished under FAA surveillance or non-surveillance depending on how you want to look at it. The same procedure was incorporated at Continental and UAL where the other damaged pylon to wing mounts were found.
Turbine D is offline  
Old 23rd May 2011, 15:03
  #2177 (permalink)  
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Crisis administration

slats11, posted:

But even so, is there some truth in this?
I think so: QF-32 (VH-OQA) incident may be is a good example. I wonder if even a design team member of the craft could understand what was going on.

And the plane was flying "normally". Suppose if it entered "strange behavior" like JAL 123 (extreme case, i agree)

Overall, the statistics suggest that we are on the right track. But every now and again (and almost at random) the holes will all line up.

AF447 perhaps presented to the (2)* crew a "strange behavior". Did they "understand" it timely during the "short" crisis? I repeat: Was possible even to understand? Just CVR probably will answer.

* Considering Capt. Marc "out of the loop". And (if entered) presenting extra "components" to the "crisis administration" resources.

Or do they get pages of warnings on their displays, information overload, confusion about what is happening, and some unfamiliar degraded flight law?
In JAL123 they were able to fly during ~30 minutes.

Real world situations presents "masks" to the real causes". Perform precisely and timely (crisis administration) was transformed in a "highly complex challenge". Even for a pilot with (hypothetically) "the design in his mind". And i suspect is becoming "increasingly difficult" despite the "friendly Systems help".
RR_NDB is offline  
Old 23rd May 2011, 15:15
  #2178 (permalink)  
Posts: n/a

has shown how an asym slats can be survived. AA could have survived.
The Falcon needs only a glance to note the control failure, and I think the Captain could see the slats retracted, though not the engine. Hind sight is somewhat easier then real life. When the roll became unrecoverable was a perceptible event, at which time one could chop #3, and fly at whatever speed necessary to avoid stalling. Better to land straight ahead than upside down with one's foot still planted against the firewall. The tragic outcome was not avoidable. Its reality can still help others fly safer. Nothing is gained by being reluctant to look at what if?
Old 23rd May 2011, 15:21
  #2179 (permalink)  
Join Date: Nov 2006
Location: SoCalif
Posts: 896
At the risk of taking this too far afield, I'll add the following about the AA DC-10.

I remember following the NTSB proceedings following the accident. A lot of discussion was on forklift leakdown rates. I don't know if it was discussed, as I learned elsewhere that the engine was suspended by the forklift, still attached to the wing at the rear point, when the lunch bell rang. The forklift ran out of gas while they were on break. They heard it crack, like a gunshot.

All DC-10 were delivered with dual stall warning computers, but only one was required for dispatch. Upon delivery of a new DC-10, AA pulled the #2 (right) and put it in stores. That's why there was no stall warning; it was unpowered.

AA engine-out procedure called for the Capt to take over flying, and to fly at two engine centering speed. The FO already had it above that speed, and just may have made it around the circuit.
Graybeard is offline  
Old 23rd May 2011, 15:33
  #2180 (permalink)  
Join Date: Feb 2001
Location: right here inside my head
Age: 62
Posts: 178
Small Correction for Turbine D re: DC10 slats.

Not that this is relevant to anything, but DC10's slats were cable driven (from a pair of actuators in the CEC that drove a large cable drum with 3/8ths" cable going outboard to the slats... The engine and pylon's departure took out that cable (on that wing)
Bear, once that wing had stalled -which happened very quickly- the only hope for recovery would have been to get it flying again -ie accelerate. There simply wasn't enough altitude for that. It was unrecoverable!
3holelover is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service - Do Not Sell My Personal Information -

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