Nonlinearity
Preface: We don't know if FBW played any part in the chain of events. We don't know if crew response played any part in the chain of events. We'll hopefully know by tomorrow.
The comments below are my personal views as a pilot, and may differ significantly from other pilots. the engineering disciplines behind the systems that are there, which are designed to assist the pilots - and nothing more - are every bit as stringent, if not more so, than the mechanical and hydraulic engineering disciplines So why is it that it's considered OK to bash FBW Airbus designs on here with absolutely no evidence that software had anything to do with the accident? We don´t know "the algorithms" used. I am assuming the Pitot´s are not "transformed in "altimeters", etc." immediately. The events are gradual, i guess. And we need testing to understand how the sensors "freeze" (temperature. and valid signal) This is an "analog world" with the "richness of mother nature". Lets look at this explanation from infrequentflyer789. As I read it, the computers will tolerate a transient (<10 seconds) period of dodgy values and revert back to normal if everything comes back into line - but if the values stay out of expected range, you are in alternate law etc for rest of the flight. PS: I know fluid dynamic systems can exhibit nonlinearity, as in say, the soliton wave, popularly known as a tsunami. But I think we can safely, discount these extreme cases from the operating ranges of sensors like pitot tubes. |
@ jd
"who knows what the handling feels like when the computer has been flying? And then the computer, where all this handling data lived as bits and bytes, flips the pilot the bird and says he has the stick. No WONDER pilots get confused when things pickle. They don't have critical data and there may be no good way to transfer that critical data to the pilot in time"
Is that any worse that if the A/P trips out on you leaving you in a seriously out of trim situation? one has an out of trim "normal" aircraft on ones hands when you least want it.. in theory at least (and I doff my cap to contributors on here who know far more as to the subtleties of the Airbus fbw system than most do).. you do still have an airframe that wants to fly at 1g/zero roll rate IF one remembers that one is not flying a "normal" airframe. |
Originally Posted by CogSim
(Post 6475643)
That maybe the case. However, there is more to performance than "quality". There is a fundamental difference between how "software" performs and how the other systems you mention behave. I believe it was RR_NDB who brought up Taleb's "Black Swan". So I'll invoke that concept. Hydraulic pressure cannot go to infinity. Similarly the pressure cannot go zero 0 in zero time. See RR_NDB's comments below about analog systems. Yet, it is too easy for this sort of nonlinearity to crop up in software systems, especially at the points where the software system fails/degrades (a.k.a bugs).
My position is that I don't know any better than he does, and the fact is that none of us will until the investigation has run it's course. However, as someone who is pretty well-versed in software disciplines, I'm simply trying to put forward what I know about what my peers have done to try to aid pilots in the day-to-day running of their aircraft. Not to de-skill their jobs, and definitely not setting in motion a trend towards pilotless airliners, but simply to assist. I of all people am well aware of the ways in which digital systems can behave bizarrely when the inputs are outside of their design limits - in fact I deal with it almost every day, which is why I've been at pains to point out that the design of the systems took as near as damn-it every possible input into account before the systems were even let near an airframe. The story of the DC-10 proves that even with the best intentions, unexpected failure modes can cripple mechanical and hydraulic systems in unforeseen ways, which is why I get so frustrated when people assert that such things did not happen before the advent of computer control in transport-category aircraft. Perhaps conditioned by the blue screen of death. I kid. I understand this was the point you were trying to make that mission critical software systems are not like your average windows pc. In my book this only means, its damn hard to "beat" these "ultrareliable" systems. However, when they do fail (for whatever reason) they exhibit the same kind of nonlinearity that any old windows computer would. If you can find me a single fatal incident that was entirely caused by the software systems on a FBW airliner - Airbus or otherwise - then I'll cheerfully take my ball and go home. Otherwise, I'm happy to go round the houses for as long as is necessary - refuting some of the falsehoods routinely propagated about computer-controlled aircraft. |
The story of the DC-10 proves that even with the best intentions, unexpected failure modes can cripple mechanical and hydraulic systems in unforeseen ways, which is why I get so frustrated when people assert that such things did not happen before the advent of computer control in transport-category aircraft. And when they do fail they are designed to fail gracefully. In the case of a severe failure they will do exactly as many demand, which is to hand control back to the pilots in the form of Direct Law. |
If you take the time to read this primary report from the group of judiciary experts (près du tribunal de grande instance de Paris) .. they point responsabilities to Air France and Airbus (and some others) for many reasons but not for softwares problems. It's seem they also exonerate pilot errors so far .. This is not tabloîd blah blah ...... Thank you. PS: When you are looking for deep pockets, pilots would be your last target. |
If you take the time to read this primary report from the group of judiciary experts Anyone here should read it, PJ2 especially would love it too, but keep that for the after holidays, we'll still have a lot to say on AF447, and so for a long long time.
Originally Posted by DozyWannabe
CONF, with the utmost respect - you're sounding like a broken record. I have yet to see any assertion supporting your statement claiming the pilots were unhappy with how the aircraft responded. In fact I haven't ever seen anyone other than yourself bring it up.
Prove me wrong on those data. |
Pitot Economy
We know how hard the airframes work to meet fuel economy and range guarantees they have made to their customers. Weight and power savings are paramount. It takes a lot of heat (fuel) to keep a pitot from freezing at 275Kt IAS and -40C.
Just maybe Airbus squeezed the specs just a little too tight, and ended up with pitot that are fine nearly all the time, but without enough reserve heating energy for every case of high altitude icing conditions. Or maybe the pitot heat power supply or wiring is not up to the task, as suggested by this: On 28 October 2009, an Airbus A330-202 (A330) aircraft, registered VH-EBA (EBA), was being operated as Jetstar flight 12... The airspeed disagreement was due to a temporary obstruction of the captain's and standby pitot probes, probably due to ice crystals. A similar event occurred on the same aircraft on 15 March 2009. The rate of unreliable airspeed events involving the make of pitot probes fitted to EBA (Goodrich 0851HL) was substantially lower than for other probes previously approved for fitment to A330/A340 aircraft. |
GB
I beg to differ on your comment.
QUOTE Please go back to BEA interim report #2 page 63 :Just maybe Airbus squeezed the specs just a little too tight, and ended up with pitot that are fine nearly all the time, but without enough reserve heating energy for every case of high altitude icing conditions. UNQUOTE QUOTE The set of icing tests to be performed to meet the Airbus specification includes 26 test points in all (10 for covering appendix C and 16 additional tests), thus covering a wider envelope than that defined by the JAR25 regulations. The Airbus specifications used for the certification of the probes are therefore stricter than those of JAR 25 (annex 4). UNQUOTE |
Originally Posted by JD-EE
(Post 6475397)
sensor_validation, I get the impression that one of the best improvements for a pitot would be some form of airflow measurement out of the drain hole. If either the probe or the hole ices the airflow through will diminish. With a moniker like yours that's a design challenge for you. Measure the existence of airflow without increasing the chances of the probe icing.
If you want to know if the holes are open I'm sure it could be done by just listening to audible high frequency noise on the sum of, and difference between analogue measurements of total and static pressure - I've seen the evidence similar (patented) idea worked in a coal fired power station with dust in DP instrument impulse lines. Could also listen out for the mud dauber! But I feel the current circumstances would be better served by small increments to the Pitot design making the chance of individual 'stuck' failure much lower and hence common mode potential failure even rarer. Should be possible with improvements to the heat transfer to the inner walls and especially the drain hole and/or increasing raw input power. BUT current probes meet current specs, what is needed is a repeatable objective test that encourages investment, and a change in procurement specification. Truth is that Pitot tubes are cheap items with considerable risk in getting a change wrong, 0.1% fuel efficiency target more likely to receive investment! |
pitot icing
Can't they just make the pitots physically bigger all round and increase the heating ? Is there any need to 'be clever' ?
|
Latest BEA factual report, of Frid May 27th (in English):
http://www.bea.aero/fr/enquetes/vol....mai2011.en.pdf AGB which - rather oddly - is markedly dissimilar to the official French-language version... http://www.bea.aero/fr/enquetes/vol....mai2011.fr.pdf AGB |
I'm not a fan of getting into redesign concepts for complex aircraft systems since it encourages the sciolists among us to up their post count.
A little history When most of the current aircraft and engine systems were designed there was little knowledge of the occurence of ice crystals at altitudes sufficent to block probes or mess up systems. Thus the design and cert standards were caught by surprise when incidents began to occur on multiple designs. Intially these incidents appeared minor in nature and/or confined to only a few product designs. But as more and more flights flew over weather more incidents appeared and on wider ranges of products and some of them were not easily accomodated by the system (crew actions, computer or fadec actions, etc.) itself so the results appeared to more seriously affect safety of flight. The problem typically manifested itself in the small probes and there affect on the sytem itself. The heat in the probe itself anticipates icing and the need to melt it as it forms, however these ice crytals at altitude were much mure numerous in quantity and lower in temperature. The result was that as they befgin to impact on the heated surfaces and melt they are unable to slip off the surface before themselves being impacted by still colder crystals and the net effect slush begins to insulate the heat from reaching the latter impacting crystals until finally the windage effect (flow) sheds the blob of the heated surface. In some cases in engines, the blob itself causes FOD while in other cases the engine control system is fooled and the engine loses power. The effect on aircraft Pitot systems has been well discussed for a hundred pages or so in this thread. OK, enough data is now available to now define the encounter conditions and effects and as long as these encounters can not be avoided the probe designs and/or the systems that they attach need to accomodate the possible encounter. There are lots of engineers and scientists involved with this advanced knowledge so I tend to skip over posters in this section that believe that they have a better way. On the other hand discussions of how existing systems works is interesting reading. |
Svarin : [...] Then why the aircraft that can be flown by "concierges" ? [...]
DozyWannabe : these controversial things 24 years ago [...] this should be disregarded [...] Airbus have acknowledged this [...] I am genuinely interested to read when, how, in what terms, such official acknowledgement took place. I may not have met the right people. I am genuinely interested in acquiring a better opinion. Many engineers over this forum state that they take their craft seriously. I do not doubt it for an instant. Then, please, do not doubt that airline pilots do take their craft with deadly seriousness, too. They are the ones who do the dying along with all those poor trusting souls. I have never ever met an airline pilot whom I could call a "chancer", and I tend to be rather unforgiving on this matter. Again, all modern airliners are safe and reliable. This is not the issue. Whether the following particular item is relevant to the current accident or not, I do not know. But this is again a philosophy issue. As an example of claimed authority that should come with responsibility : A respectable manufacturer states in its FCOM, regarding some "flight envelope protection" system (in Normal law) : "a progressive nose-up demand is introduced [by the FBW system]. The pilot cannot override this demand." (bolding mine) Such authority cannot be separated from the associated responsibility. Given this authority that the aircraft (or its design team) claims, any investigation should start by examining in its most intimate detail what the FBW system did, and whether it was done by design, intent or mistake. Then we can start looking at how the system interacted with the pilots, and then look for blunders on their part. In that order, as the manufacturer obviously decided it itself ! And back to our subject matter, three ACARS maintenance messages are related to Flight Controls, affecting its Fly-By-Wire core components : EFCS1 X2,EFCS2X,,,,,,,FCPC2 (2CE2) / WRG:ADIRU1 BUS ADR1-2 TO FCPC2,HARD F/CTL PRIM 1 FAULT F/CTL SEC 1 FAULT (bolding mine) That makes three components out of five affected in one way or another. This is largely enough to deeply inquire first about Flight Controls. Given the authority claimed by this system, anything less would be dishonest. |
Sadly, most of what the BEA has announced had already been discussed in this thread.:sad:
The recordings stopped at 2 h 14 min 28. The last recorded values were a vertical speed of -10,912 ft/min, a ground speed of 107 kt, pitch attitude of 16.2 degrees nose-up, roll angle of 5.3 degrees left and a magnetic heading of 270 degrees |
As mm43 just stated, most has been discussed here. The only thing that stuns me in the BEA update:
2h 10m 51s "The trimmable horizontal stabilizer (THS) passed from 3 to 13 degrees nose-up in about 1 minute and remained in the latter position until the end of the flight." and 2h 13m 32s "...PF said "we’re going to arrive at level one hundred"." I feel very sad with regard to the people on board. That were horrible 3m and 30s until impact. Denis |
Hi mm43,
Originally Posted by mm43
Sadly, most of what the BEA has announced had already been discussed in this thread.http://images.ibsrv.net/ibsrv/res/sr...y_dog_eyes.gif
PS.. PJ2 is in the air, so don't expect any comment from him in the short term. S~ Olivier I'm posting this BEA map: http://takata1940.free.fr/LastFlight.jpg |
A little less information in the report than I expected, to be honest. But it goes a long way to answering the question as to why / how this happened.
I've never flown an airliner, so maybe there was something in the crew's insistance on maintaining a nose-up attitude that makes sense to those who have done, but from my flying experience that's tantamount to suicide when you're in a stall environment, with stall warnings sounding. They acknowledged that they were in alternate law, so why didn't they configure accordingly? Very sad to read, but also appears to me to be quite a disturbing mistake from experienced proffessional pilots. |
THS nose up
I also am stunned.
Do we know who or what caused the THS to go to 13 deg and stay there. Surely this extreme setting is a major contributor to the disaster. If this was HAL then surely Airbus has some explaining to do. I think this is not the first time the THS on an Airbus in trouble has gone to a high setting and the crew didn't notice, or am I wrong? |
BEA facts document
If mm43 looks disappointed, I find much in this factual report.
The main theory of a deep stall from altitude is validated. An initial climb, preceding the final descent, is established. Many theories can be trashed (now we can concentrate on useful stuff) : - reengagement of A/P - only one pilot at the controls (all 3 were in !) - vertical stabilizer separation - blindly entering CBs - dual flameout or other engine problems - longer than ~4min flight time - manual reset of PRIM1 and SEC1 - attempted ditching - multiple upset sequence - exotic impact attitudes - extreme turbulence - lightning - grossly unprofessional behavior BEA wrote : The airplane’s angle of attack increased progressively beyond 10 degrees and the plane started to climb. The PF made nose-down control inputs and alternately left and right roll inputs. The trimmable horizontal stabilizer (THS) passed from 3 to 13 degrees nose-up in about 1 minute and remained in the latter position until the end of the flight. The airplane was subject to roll oscillations that sometimes reached 40 degrees. The PF made an input on the sidestick to the left and nose-up stops, which lasted about 30 seconds. Too bad the right side speed indication is absent from recordings. Overspeed reading, prompting a climb reaction from PF ? Or overspeed sensed, triggering a nose-up reaction by FCCs ? Or just plain stress degrading finer motor control and producing arm tension on the sidestick ? Heading on impact seems consistent with the wreckage field now. Note 1: The angle of attack is the angle between the airflow and longitudinal axis of the airplane. This information is not presented to pilots. Many things to say about training for high-altitude stall recognition and recovery... Such training had been discarded because "protections" would prevent it... :{ Some of us were having a discussion about deliberate pilot "dumbing-down"... It seems it is only the start of it... As a general comment, I would say this initial sharing of facts describes only one side of the accident, pilot reaction (as usual). I rest my case : Flight Controls still need a very detailed inquiry regarding their behavior in this, for the philosophical and technical reasons I exposed earlier. I am disappointed at the lack of "facts" made available regarding this touchy subject. At the very least, correlation between sidestick commands, individual FCCs reaction to them, aircraft reaction to these processed commands, and the established anomalies affecting certain FCCs, will certainly get my attention. Svarin |
The trimmable horizontal stabilizer (THS) passed from 3 to 13 degrees nose-up in about 1 minute and remained in the latter position until the end of the flight. |
Still, there remain many many questions unanswered, especially in regard to the ACARS and what the situation was on the flight deck accordingly.
NAV TCAS FAULT (2h 10m) and FCPC2 (2CE2) WRG:ADIRU1 BUS ADR1-2 TO FCPC2 (2h 10m) - disappearance of FPV incl. angle of attack New info: At 2 h 10 min 51 + 60 seconds The trimmable horizontal stabilizer (THS) passed from 3 to 13 degrees nose-up in about 1 minute and remained in the latter position until the end of the flight. |
HN39, we seem to have a misunderstanding barrier issue here, in re the word tolerance. I am not suggesting you tolerate abrupt control motions as in "I'll put up with that, no problem" but am rather meaning "tolerance" in terms of fault tolerance, or what it does to you, as a pilot, when you have abrupt and uncommanded pitch inputs. How do you as a pilot respond to this sort of fault ... so it's more like fault tolerance. Sorry about that semantic ambiguity.
|
Hi Poit,
Originally Posted by Poit
A little less information in the report than I expected, to be honest.
If they don't say what put the THS at this setting (where it was not until a while), it doesn't mean they don't have any idea about it but that it is not settled. They won't make any "guess". One may also suspect that if you are pitching up during a long time, the THS would also follow what you want, and if the pilot idea was to climb or to keep the nose up, then it may also have been settled thru the trim wheel. For my part, what bother me particularly is that plenty of parameters are not recorded at all: only LH speed and stand-by, for example. This is not good if one want to fully understand this system logic. |
LandIT THS nose up I also am stunned. Do we know who or what caused the THS to go to 13 deg and stay there. Surely this extreme setting is a major contributor to the disaster. If this was HAL then surely Airbus has some explaining to do. I think this is not the first time the THS on an Airbus in trouble has gone to a high setting and the crew didn't notice, or am I wrong? However in that case i would assume, that HAL was trimming until running out of ideas due to the wrong airspeed indications. franzl |
I've never flown an airliner, so maybe there was something in the crew's insistance on maintaining a nose-up attitude that makes sense to those who have done, but from my flying experience that's tantamount to suicide when you're in a stall environment, with stall warnings sounding. Aircraft gives up on you, and you've never had to be violent with the aircraft before, especially at high altitude. You'd be a bit reluctant to do anything drastic, especially if you don't normally even "fly" the thing. The crew will be blamed, but they were set up by the system. |
Originally Posted by LandIT
(Post 6476382)
I also am stunned.
Do we know who or what caused the THS to go to 13 deg and stay there. Surely this extreme setting is a major contributor to the disaster. If this was HAL then surely Airbus has some explaining to do. I think this is not the first time the THS on an Airbus in trouble has gone to a high setting and the crew didn't notice, or am I wrong? However, this is not a FBW issue, nor just a Bus issue - this sequence:
Note: I am unclear as to why THS went up in this case, first reading of latest BEA document suggests it was in response to PF nose-up inputs, not HAL It's also not clear if autotrim ever dropped out (or stopped working) in this event. |
|
All times are GMT. The time now is 08:41. |
Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.