Search Area Refinement
Additional to 'noske's post 1915
BEA posted this summary of the sea search operations on Monday already, but I haven't seen it mentioned here before: http://www.bea.aero/fr/enquetes/vol....16.05.2011.pdf Most interesting in my opinion are fig.5 and fig. 6. One is a diagram of nine marker buoys and their drift paths, from an experiment made in June 2010. Look at those crazy loops! I guess that is what persuaded them to abandon any predictions about the crash site based on the location of floating debris. The other is a map used for planning phase 4 of the search, indicating the most likely places to find the wreck. It is based on the assumption that most (but not all) areas already covered by sidescan sonar need not be searched again, and (in contrast to phase 3) that the pingers were probably just not working. http://wwz.ifremer.fr/lpo/layout/set...A9mentaire.pdf |
OK465
Thick skin also, but the brain has some catching up to do. I know the pilots of A330 here are top notch, and most of this is well above my head, but I get the definite feeling that if not completely conversant with the Law, a guy could get real behind, real quick, and perhaps not even be aware of how far behind until the thinker goes to overwhelm. I'm sure it's just me, and my archaic skills. I am so waiting to hear from the pros here when the data hits the fan instead of the s. Perhaps at that point we can truly appreciate their (your) presence here. TurbineD, PJ2, Hazelnuts39, takata, Chris Scott, gums, Machinbird, Smilin Ed, Tubby Linton, mm43, y'all know who yar. |
a guy could get real behind, real quick, and perhaps not even be aware of how far behind until the thinker goes to overwhelm. I'm sure it's just me, and my archaic skills. |
My Wild Speculation
Basically everything working well: the radar and crew spot a wet cb and avoid it, perhaps even begin to think they have gotten through the ITCZ.
The radar and crew do not see a humongous dry/ice crystal updraft and fly into it. The temperature is so much warmer than standard that the a/c stalls somewhere in the updraft. Pitots may or may not be clogging while this is happening. I am waiting for the BEA to learn how this or a different situation was handled by the crew. Once both engines stall because because of high alpha, pulling one back to idle will not induce a roll. |
Didn't work too well in QF72's case, where one dud ADIRU brought the whole show to it's knees and completely out of the control of the pilots for some time.. AFAIK this is untrue. The last report I have seen they have not be able to duplicate the anomalies. They do not know if the ADIRU was a dud, if there was some outside interference, or what. |
Radar capability
humongous dry/ice crystal updraft Simple model! |
how could the capt. enter through the secured cockpit door unless the situation took minutes to unfold.
Originally Posted by Mountainbear
Didn't work too well in QF72's case, where one dud ADIRU brought the whole show to it's knees and completely out of the control of the pilots for some time.. |
Lightning
Hi,
EDLB Sure they are but might be a bit destructive on the airframe donaldt Impressive information; In one mission of STS they studied the phenomena with impressive findings. Very long bolts, etc. Frightening. Some interesting info. on lightning in a/c: triple whyskey dot niar.wichita.edu/agate/Documents/Lightning/WP3.1-031027-043.pdf Posting just to close the issue unless something related is reported by BEA. |
It is true. Read the reports. Why ADIRU 1 put out spurious signals is irrelevant: the system didn't isolate it and the pilots could not control the aeroplane... twice. As for whether the ADIRU was a dud the 2nd Interm report clearly states it was not. As outlined in the first Interim Factual Report, the ADIRU (serial number 4167) and an exemplar unit were subjected to a range of tests and examinations, and no faults were found that provided any information relevant to furthering the understanding of the accident. http://www.atsb.gov.au/media/1363394...8070_ifr_2.pdf |
NWR
Thanks for posting the link to the Ifremer report.
Quite technical but pretty interesting. That's another evidence to which length the BEA was ready to go to find the wreckage (sorry for our beloved conspiracy theorists who are sure that the BEA / AF /AI do not want the wreckage to be found :ugh:). |
bearfoil
Presume you are referring to the DC10 at Chicago. If my grey cells are still functioning correctly... The DC 10 had no protection on the slats for hydraulic failure. When the engine disappeared over the wing it took out the hydraulic lines which allowed the slats to retract. The crew had no knowledge of this and rotated the aircraft to obtain V2+10 which was below the stall speed of the wing on the side where the slats had blown back into the retracted position. Not very dissimilar to the Trident captain who didn't notice that the droop had been retracted and after stick push recovery went back to try and fly V2+10. Another question. In the 80s there was talk of fitting A of A indicators to civil aircraft - did it ever happen? |
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!
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! Wannabe pilots who never made the grade, and want to tell pro's who did cut the mustard how to do it, should listen to what Chris and his fellow professional airline pilots have to say! |
Wiring fault
RR-NDB wrote and quoted one of my posts :
Svarin, 02:11:55 EFCS1 X2,EFCS2X,,,,,,,FCPC2 (2CE2) / WRG:ADIRU1 BUS ADR1-2 TO FCPC2, HARD This is definitely a wiring fault, where FCPC2 and ADR1 lose their connection. The importance to me is not related to what this "wiring fault" could make to a redundant architecture. I would like to understand what can create a "wiring fault". Other than a Kapton issue. http://images.ibsrv.net/ibsrv/res/sr...ilies/evil.gif As to your question, lightning was suggested quite early after the accident in June 2009 by Mr Feldzer. I do not believe it. Coincidence is too great. However, a software versioning compatibility issue would perhaps fit the bill. As to my question, takata, in an uncharacteristically broadly sweeping answer, made a reference to BUS 2 and BUS 1. Takata, would you care to enlighten us on this BUS structure, please ? Just how many BUSes are there on them 'Buses ? And more importantly, how do they connect all relevant computers (ADRs, FCPCs) together ? Takata, PJ2, Lemurian, mm43, and other knowledgeable individuals, please tell us, could multiple FCPCs retain their own personal flight law, differing with their "clones" ? What would a trio of clones become after a highly suspicious wiring fault affected only one of them ? What do you make of an airspeed probes fault appearing near simultaneously with a wiring fault ? What becomes of redundancy in this cr@ppy situation ? Why is there no "ADR 1(2)(3) FAULT" message in the sequence ? Why is there a PRIM1 FAULT and no PRIM2 FAULT ? Best regards PS : to all who take the time to read my modest posts, thank you for your patience. Please understand that my attitude here is about working with available first-hand evidence only. And so far, ACARS sequence is one very good source for such. Primarily, a maintenance sytem will not tell about crew deficiencies, only aircraft deficiencies. Thus, the reason why I appear strictly one-sided at this time. |
...and I rest my case! :ok:
|
...and I rest my case!
|
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. |
QF72 interrim report 2
Cited from the report:
"As outlined in the first Interim Factual Report, two significant safety factors have been identified with the aircraft’s systems: • an air data inertial reference unit (ADIRU) provided erroneous data that was not detected by the ADIRU itself • the flight control computers did not filter spikes in angle of attack data in a specific situation. The investigation is examining the context and origin of both of these factors." It looks to me that the ADIRU is still suspect although the problem remains undetected.. However, more interesting, and perhaps relevant to AH447, is the fact that a program update brought an earlier unidentified bug into operation. There is a remote possibility that the software running on the computers on AF447 was a unique combinations of updated and un-updated programs leading to a unique system behaviour in comparison with other flights having speed-measurement problems. |
Safety Concerns, your post brought me back to one of my hobbyhorses, the plane being out of communications.
Suppose the storm looked too large for them to go around without contacting DAKAR. That could lead to their trying to thread a hopeless needle and eventually going down. Revealing such an assumption most likely will lead to an international incident. So it needs to be nailed down tighter than a drum before they release it in particularly delicate language. This could be getting quite interesting to watch. DAKAR would no doubt point to Brazil's failing. Yet, DAKAR had the final responsibility here. (I believe planes have dual HF radios. One should have been on Brazil with SelCal on. The other should have been on DAKAR with SelCal on after an alert to DAKAR they were coming but not in DAKAR's region of concern, yet. I tend to believe in "communicate early and often.") |
Ref this post my limited knowledge of cutting code suggested that the sentiments were a bit optimistic. A specialist colleague provided the following commentary as an observation and invited me to post it for information.
"The contributor who goes by the name of syseng68k has a rosy, and, I fear, misleading idea of the quality of software and software development. It is not error-free, even in critical systems. There is probably no substantial system (of the order of tens of thousands of lines of code or larger, the size of all flight control systems in commercial aircraft nowadays) which has ever been built that was or is error-free. For the state of the art, see the last paragraph. I have worked in the reliability and safety of software-based systems for a quarter century, am a member of my country's standardisation committe on functional safety of computer-based systems, have an international reputation in the field, and indeed shall be giving a keynote talk at a major international conference on the subject later in the year. A famous study by Robin Lutz of Iowa State University twenty years ago on the source of about 200 mission-critical software failures for NASA showed that over 98% were due to the requirements not covering adequately the actual situation the system encountered. (syseng68k prefers not to call these "bugs" but most people working in ultrareliable software do.) A more recent study by Lutz and Mikulski from 2004, published in one of the premier journals for software engineering, may be found at http://www.cs.iastate.edu/%7Erlutz/publications/tse04.pdf 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. A check of Peter Neumann's "illustrative risks" Section 1.6, Commercial Aviation, gives some sense: http://www.csl.sri.com/users/neumann/illustrative.html#9 The Risks Digest archive is also available on-line at http://catless.ncl.ac.uk/risks Kevin Driscoll of Honeywell, along with Brendan Hall, Hakan Sivencrona (of Chalmers Institute of Technology) and Phil Zumsteg, published a paper recounting a so-called "Byzantine anomaly" with the FBW control system of a major airliner, that almost caused the airworthiness certificate to be withdrawn: http://www.cs.indiana.edu/classes/b649-sjoh/reading/Driscoll-Hall-Sivencrona-Xumsteg-03.pdf Driscoll gave a recent keynote talk at SAFECOMP 2010, "Murphy was an Optimist" on such kinds of failures, which are ongoing. Estimates by colleagues who know put the general coding error rate in safety-critical software at about one error per 1,000 LOC (lines of executable source code). Obviously, this is a very general statement. How often behavioral anomalies are triggered by coding errors depends of course on the operational profile of the software. For example, the bug in the configuration control software on the Boeing 777 aircraft was present throughout the lifetime of the aircraft but only manifested after a decade of line service http://www.atsb.gov.au/publications/investigation_reports/2005/aair/aair200503722.aspx and recent anomalies, also triggered by issues with ADIRUs affecting the primary flight control, in Airbus A330 took a similar length of time to manifest : http://www.atsb.gov.au/media/1363394/ao2008070_ifr_2.pdf There are some companies, such as Altran Praxis (formerly Praxis High Integrity Systems), who have instrumented their error rates and demonstrably achieve much lower rates, of the order of one error per 25,000 LOC. Altran Praxis have recently engaged on the Tokeneer project funded by the NSA, whose object was to develop error-free software http://www.adacore.com/home/products/sparkpro/tokeneer/ Despite apparent initial success, five errors were eventually found: http://www-users.cs.york.ac.uk/~jim/woodcock-hoare-75th-final.pdf (note, this is a paper for a celebration of the 75th birthday of a UK pioneer in reliable software technology, Turing Award winner Sir Tony Hoare, co-inventor 40 years ago of the original method for mathematically proving that sequential programs do what they are supposed to do). Summary: Five errors is as good as it gets in software with many tens of thousands of LOC. This is the order of the first civil aircraft flight control systems a quarter-century ago (Airbus A320, 1988, about 60,000 LOC). However, since then the size of the systems has increased by two orders of magnitude, and of course they are also very highly distributed, which brings many subtle additional sources of potential error into play (e.g., Byzantine failures)." |
"Wiring Fault" ?
Svarin:
02:11:55 EFCS1 X2,EFCS2X,,,,,,,FCPC2 (2CE2) / WRG:ADIRU1 BUS ADR1-2 TO FCPC2, HARD ATA: 279334 Source: *EFCS1 Identifiers: *EFCS2 Class 2, HARD This message indicates that FCPC 2 no longer considers as valid the information that is delivered to it by ADR 1 (via bus 2). The ATA code beginning with 27 indicates that the fault was not detected by any other FCPC during the three seconds that followed (otherwise this message would have been classified ATA 34). This message has not been fully explained at this stage of the investigation. In my knowledge the slash "/" is used when an ambiguous fault occurs. Up to 3 possible failures may be indicated with the most probable possibility on the left. (FCPC 2 FIN 2CE2) A "+" sign is used when there are multiple faulty components involved. could multiple FCPCs retain their own personal flight law, differing with their "clones" The Master transmits it's deflection orders to the other computers, which executes these to their own sets of servo's. A FCPC is able to engage Normal law(all protections), Alternate Law(reduced protections) and Direct law(No protections), FCSC can only compute Yaw alternate law and Direct Law. After Loss of normal laws the reconfiguration of control laws is different for the pitch axis and for the lateral axis. |
All times are GMT. The time now is 06:28. |
Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.