-----Original
Message-----
Dear Sir
What does the term "fish tailing" mean for the A300?
Justin |
||||||||||
Justin You will find reference to it in an extract from an official report on this page (also here). Also search on the IASA site search engine (or Google) for AA587 and you will find other amplifying references under Fish tail Fish tailing Fish-tailing Fishtailing
The term is a graphic analogy that describes the official and anecdotal (flight attendant and passenger) evidence of an A300’s frequent fish-like characteristic (left/right wagging of its tail under certain flight conditions). It has been suggested that it is a flight-control feedback loop that permits either an external excitation (such as a wake encounter, atmospheric or clear air turbulence) or an internal input (pilot’s feet on pedals or hydraulic glitch) to start a yaw cycle. By design, such a yaw cycle should be damped by the great stabilizing influence of the tall vertical fin – and the yaw dampers. However if a corrective input is (or becomes) slightly out-of-phase, the stabilization might be slowed (i.e. it will overshoot the null position slightly, but to an ever decreasing degree – and finally sort itself out in accordance with the Law of Diminishing Returns). However if the initiating force is unusually high, a divergent phugoid might result in a destructive amplification of that process (and this may well have been the case for American Airlines Flight 587). It may just depend upon the size of that initial excitation (or subsequent input – such as the second “bump” felt on exiting the other side of a preceding aircraft’s wake). If the corrective rudder input becomes out-of-phase (for some reason), the yawing will be progressively amplified. The same effect can be seen at air displays where fighter and Jet Trainer type aircraft pilots would introduce a rudder pedal input at just the right moment to accentuate the aircraft’s yaw to a visually alarming degree. I incorporated just such a fish-tailing in my low-level act. The F-4 Phantom was one of the best exponents of this - as seen in its crowd-pleasing, high angle-of-attack, high yawing Phantom “wing walk”.
As to what (other than an inept pilot) might cause (induce or reinforce) this feedback loop, well that is the big question. It is apparently a question that Airbus isn’t eager to answer (nor one that has been clearly asked). FEDEX had a rudder actuator break in its hangar (at Memphis I think it was) during maintenance. The FAA then brought out an airworthiness directive that addressed the possible lack of harmonization that could cause such an event. So, being under no air loads in the hangar, that would point to it being a flight control system induced hydraulic glitch. It’s also been theorized (by me) that water trapped in the static pressure lines could cause erroneous pressure signals to be transmitted to the Air Data Computers (and onwards from there to the yaw dampers and rudder limiters). Why would that be? Well usually static pressure is sensed on each side of the aircraft in order to iron out any anomalies introduced by yawing (which can expose the static port on one side to a suction and the other side’s port to a dynamic inflow). If however the arrangement to overcome (i.e. neutralize) this latter phenomenon is compromised by water trapped in the system’s “designed in” low points, water (having inertia) is going to flow aft on one side and forward on the other during each yaw cycle. The net effect of this would be contrary to the desired effect (of neutralizing the “suck and blow” during yaw that’s felt by the port and starboard static ports). The CADC (Air Data Computer) would be converting erroneous analog signals to digital data and, due to its high sampling rate, might then create the conditions for a yaw damper to start the destructive cycling.
A few more FAQ pointers here: a. Ques: How would water become trapped in the system? Answer: During an aircraft wash, as a result of ice melting (in flight or on the ground), failing to install bungs in the static ports while on the ground. However, also see b.
b. Ques: Even if you install bungs whilst the aircraft is being washed or in heavy rain whilst parked overnight, can water still get in? Answer: Yes it can. Normally static port bungs are angled downwards so that water can’t flow uphill. However water flowing down the fuselage and over the bungs can be sucked up into and through the bungs by capillary action – in particular if the atmospheric pressure is changing quickly (which is often the case during heavy rain).
c. Ques: But aren’t the bungs solid rubber? Answer: In my experience they have a thin capillary (i.e. a hollow shaft) running up the centre because pneumatic instruments must be allowed to “breathe”. That’s why you will always see, whilst the bungs are still in, the atmospheric pressure changes (that have occurred since the aircraft was parked) reflected on the standby non-digital altimeter in the cockpit. The reason for doing this is that large rapid pressure changes (such as bung removal) might otherwise be injurious to the pneumatic bellows and delicate gearing that you find in instruments or sensors that are pneumatically plumbed direct into the static pressure. In fact a person blowing into a static port or pitot tube can destroy delicate flight instruments (or at least require them to be recalibrated).
d. Ques: But aren’t the static lines checked for water? Answer: They are, but infrequently (probably only at major servicings – and I doubt that quantities removed would be recorded). A small amount of water would have little effect (and in modern aircraft, unlike unpressurized airplanes, cannot freeze when the aircraft flies above freezing level – which is a wholly different pitot-static dilemma). Once the amount of accumulated water built up to the point that it filled the line at a low point, then you have the inertia problem that I spoke of above. And of course, the more water, the greater will be the inertia effect. And it is possible that a static line low point might be situated short of where the port and starboard lines are plumbed (i.e. Y’d or T’d) together. That opens up the possibility of only the “weather” side having its line’s low point full of water. Think about that (for its effect upon what is sensed airborne (during extreme yaw) at the ADC or its transducers). The trapped water phenomenon might also explain why some aircraft exhibit the characteristic at some stage - but at others just don't (i.e. depending upon whether water is present in sufficient quantity - or isn't).
e. Ques: What is a transducer? Answer: In a digital system you sense analog data (i.e. ambient air pressure) but must at some stage do an analog/digital conversion in order to get a signal that the ADC can process for its computer data input. ADC’s have transducers either at the ADC or somewhere in the static lines. Logically they would (in my opinion only) be located somewhere DOWNstream of where the port and starboard lines came together. Within the ADC there are tables for PEC (pressure error corrections that accommodate slight errors due to static port position errors that change with changing IAS). These PEC tables may well introduce another factor enabling a rogue feedback loop.
f. Ques: So why hasn’t anyone rung alarm bells if they’ve found amounts of water in the static lines? Answer: I’m not sure how often the lines are checked, but there are usually drain-taps located at the low-points (in fact that’s why there are designed-in low points – so that the water will pool there and can be drained). If the work is done at a contractor, I doubt that they’d even record the fact that water was found in the lines. If you think about it, I doubt very much that there would be any snags recorded by a pilot or engineers that would cause them to investigate water in the static lines. AA587 had a yaw-damper self-test glitch prior to start on its final flight and that was “fixed” by resetting the system (which probably means cycling the breaker). Intermittent glitches are often made to just go away by such system reboots or resets.
g. Ques: What are the outputs from the ADC that might be affected? Answer: Well obviously rate-of-climb, airspeed, altimeter, transponder height ATC reporting (Mode Charlie), Machmeter, rudder limiter, yaw-damper (and systems various that utilize these signals – autopilot being one). But at this point you need to start considering that digital data systems have sampling rates (rates at which they take up and convert their analog inputs). These sampling rates can be the “fly in the ointment” Think of it as similar to a sudden alcohol-induced loss of hand-eye sensory coordination that causes you to stick your fork-full of food into a closed mouth.
h. Ques: Which outputs might cause the feedback condition? Answer: Well obviously the magnitude of any yaw-damper correction to a yaw upset is going to depend upon the airspeed sensed by the ADC. Static pressure changes influence this greatly. For example, if both static ports were to freeze over, the pilot’s airspeed indicator would wind back to zero over a further climb of about 2500ft (but he’d not see that climb because the altimeter and VSI would be stuck). Now consider that instead of freezing, the pressure was cycling (due to the rush back and forward of that water in the static line’s low points). What might that do to the ADC’s outputs during its sampling intervals? Would the yaw-damper system become confused?
Other Reasons for Feedback Loops are given here |
||||||||||
You may be aware of some of these discussion threads below. The one reproduced below is my examination of just one rogue hydraulic possibility (for the quaint yaw-damper actuator set-up to have produced the feedback loop). | ||||||||||
link one (multi-page) | In particular the Wino, Belgique and Overtalk posts | |||||||||
Why
wouldn't this problem afflict every airplane model? What is it about the
A300-600 that makes it
|
||||||||||
It seems pretty clear (to
me) that Overtalk is referring to the possibility that accumulated water
trapped in the static lines could induce the air data computer to feed
faulty airspeed signals to either/both the yaw damper and rudder limiter via
the Flight Augmentation Computer. Water in the static lines would dampen the
ADC inputs considerably and create the potential for an out-of-phase
condition to develop (particularly following on from the yaw caused by the
externally applied gross stimulus of a wake encounter).. Closed loop
feedback is the most likely cause of this accident - despite all the
obfuscation by Airbus, the FAA and NTSB about pilot inputs. Overtalk is
admitting that there may have been belated pilot intervention attempts that
may not have helped (and may indeed have exacerbated the condition). That is
quite different to a pilot-input inspired event. Unlike roll and pitch, the problem in the yaw circuit is that the very large vertical fin is going to provide a powerful stabilizing force - but that can be subverted by mis-timed FAC signals to the rudder (as caused by faulty feeds from the ADC). In my view the theory is credible and might explain the A300's tail-wagging proclivities. For AA587 it was likely to have been a case of an unfortunate conjunction of a wake encounter, water in the static lines and a PF who was hand-flying and tried his best to calm the beast that was suddenly unleashed by the wake encounter. |
||||||||||
While Overtalk and I both
agree to what is the most likely_"late event" in the causal chain (a
divergent rudder oscillation caused by a control loop with negative dynamic
stability), I believe we diverge in our opinions as we progress backwards in
the causal chain to what may have been the cause of this divergent
oscillation of the control loop. Overtalk favors the Air Data Computer inputs to the Flight Augmentation Computer, whereas I believe it was induced by hi-frequency pulsing in the hydraulic system. The reason I can't "stretch" to Overtalk's theory is because the characteristics of air data are well-known in the flight control world, and have been since even before the advent of digital computers as flight control system controllers. I think the entire community of flight control engineers would be aghast if we were to find out that Airbus did not filter out hi-frequency, oscillatory effects from the air data inputs to the control laws. It is THE FIRST consideration you make once you decide to use an airspeed parameter in your control loop computation. The most typical, and easy, solution is a simple low-pass filter, so named because it only allows the LOW frequencies to pass thru to affect the control law. Low pass filters are typically characterized by a "break frequency", which is the design point at which inputs at that frequency begin to be attenuated (rejected). [Low Pass Filters are even discussed in the CVR analysis in the accident factuals.]__For airspeed inputs, the filter break frequency_is usually somewhere around the 8-10 Hz range. Any oscillation in the digital airspeed signal higher than this frequency is filtered, and will never drive the control law, for the specific reasoning of avoiding divergent oscillation caused by excessive phase lag. Such filtering is inherent to ALL flight control system designs that use airspeed programming in the control laws, and this is why hi-freq oscillations in airspeed do not plague the worldwide fleet. It would be a VERY regular occurrence (on Airbus as well as other airplanes) if such filtering did not exist....and yes, water in the lines would exacerbate such oscillations. It would be even easier than performing a flight test to see if Overtalk's theory holds water (pardon the pun). If Airbus would simply reveal their design specifics of the FAC control laws with respect to airspeed inputs to the rudder control law, any one of a multitude of controls engineers could easily perform a frequency domain analysis, and tell you if there was any potential for oscillating airspeed signals to get into the closed-loop control law. The other issue I have in accepting this theory is lack of abundant "smoking gun" evidence. Yes, we have a_fair amount_of tail wagging events in the Airbus history file. However, one cannot assume that this is all due to faulty air data processing without some hard evidence that points in that direction (it could just as easily point to my theory). However, this is where I believe my theory (rudder hydraulic_de-synchronization)_shows ample smoking-gun evidence: 1) The existing AD on de-synchronization is the biggest smoking gun! But it goes deeper: 2) The FedEx hangar event (with airspeed=0) was a clear rudder oscillation that lead to mechanical failure. The test being performed was, indeed, the test required to attempt to detect the de-synchronization problem. I'd say_they found it! 3) The AA587 subject airplane had a history of rudder system related write-ups. 4) The subject airplane had a FAC preflight test failure right before the doomed flight. It is my understanding that this pre-flight test specifically seeks to verify proper operation of_the rudder servo control loop. But again, even my theory could be dispelled by Airbus coming clean on their design details. To dispel Overtalk's theory, one only needs to know the control law filtering specifics on airpseed signals coming from the ADC to the FAC. To dispel my theory, one only needs to see actuator system frequency response test data, both under normal conditions, and under the conditions described as "de-synchronization". In the past, I have amply described how the word "synchronization" is a direct reference to a closed-loop control system's amount of phase lag. So...there's my summary! Nothing personal....just a difference of technical opinions. :-)
|
||||||||||
Belgique: Does the
expression "control law" apply to the older technology Airbus 300/310 rudder
systems as much it does to the fly-by-wire A-320/330--- systems? I have no engineering training but find the comments on this topic quite interesting, and wish I could better understand some of the complexities without a graphic flow chart in a flight manual. In my company's flight ops magazine, the Internet and in "Aviation Week & ST" magazines, the words "control law" seem to be used only in connection with the A-319/320 etc, but never with the 757/767 generation.
|
||||||||||
|