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 |
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. |
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:
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... |
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 |
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. 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,
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. 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. |
Fact Sheet
http://i56.tinypic.com/qqo94j.jpg
Just a little reminder, as I stated yesterday, we do not really know much more than three months ago. |
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. |
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. 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. |
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:
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! 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? |
Failure mechanisms
Svarin,
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). |
Originally Posted by JD-EE
(Post 6467889)
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. Never seen the animations for the Concorde crash, or the one for the "Hudson glider"? |
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. |
Crisis administration
slats11, posted:
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". |
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? |
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. |
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! |
All times are GMT. The time now is 20:06. |
Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.