AF 447 Search to resume (part2)
Disclaimer...
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,
Chris
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,
Chris
Last edited by Chris Scott; 23rd May 2011 at 23:12. Reason: Last para simplified.
Join Date: Jul 2002
Location: UK
Posts: 3,182
Likes: 0
Received 0 Likes
on
0 Posts
john_tullamarine:
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.
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.
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!
.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...
DozyWannabe, #2114:
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...
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
Good stuff and thanks...
Join Date: May 2011
Location: Orebro
Posts: 1
Likes: 0
Received 0 Likes
on
0 Posts
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
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
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.
As for whether the ADIRU was a dud the 2nd Interm report clearly states it was not.
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.
gums said,
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!
Salute!
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.
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.
If you knew where I was coming from, you would understand my extreme embarrassment!
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.
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.
Join Date: Aug 2005
Location: London
Posts: 78
Likes: 0
Received 0 Likes
on
0 Posts
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!
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.
Join Date: Nov 2006
Location: SoCalif
Posts: 896
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
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.
Join Date: Jul 1999
Location: 58-33N. 00-18W. Peterborough UK
Posts: 3,040
Likes: 0
Received 0 Likes
on
0 Posts
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.
amos2:
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?
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!
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!
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?
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Likes: 0
Received 0 Likes
on
0 Posts
Failure mechanisms
Svarin,
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).
syseng68,
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).
However, a software versioning compatibility issue would perhaps fit the bill
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).
syseng68,
Effectively, a hardware state machine equivalent...
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.
Join Date: Jan 2005
Location: France
Posts: 2,315
Likes: 0
Received 0 Likes
on
0 Posts
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.
Join Date: Dec 2010
Location: Middle America
Age: 83
Posts: 1,167
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Join Date: Feb 2011
Location: Nearby SBBR and SDAM
Posts: 875
Likes: 0
Received 0 Likes
on
0 Posts
Crisis administration
slats11, posted:
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)
Perfect!
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.
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".
But even so, is there some truth in this?
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?
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".
Guest
Posts: n/a
TurbineD
gums 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?
gums 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?
Join Date: Nov 2006
Location: SoCalif
Posts: 896
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Join Date: Feb 2001
Location: right here inside my head
Age: 64
Posts: 178
Likes: 0
Received 0 Likes
on
0 Posts
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!
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!
