syseng68k; as chronicled in the "Lightning Empiricist" www.me.utexas.edu/~longoria/paynter/hmp/LITENING.pdf
|
Common mode errors
Hi,
Difficult question! (Presented by an "instrumentation professional") We could pinpoint the moment the AS started to change in respect to "ground speed" (supposing AS sensors LYING and presenting the "identical" info.) BEA is doing all necessary correlations. But i understand your question is no about BEA task. Is for the System: Until the point (time) the sensors present different info. how to detect they are "failing"? The "band-aid" we learned is being considered using (for short periods) other references could reduce the criticality of the issue: Reliable "speed info." required by the System. But the only way to "kill" adequately the issue is with really redundant AS sensors. The ideal is to have at least three (methods) allowing a "voting scheme". Again AoA comes to my mind... How the System could work properly if ALL AS SENSORS "lie" to it? How it can detect? Detectors, (sensors) if the System requires (the truth) the real AS, can not LIE together. It´s simply dangerous (to the a/c). And can (i guess) today generate undetectable "strange behavior". Introducing "extra components", not just "robbing precious time". |
Simply, because (it seems) there are no solutions yet available (sensors) to have the (could provide) required redundancy. 1. Initially - given the availability of purely mechanical instruments - the pitot-static system was the easiest way to calculate airspeed. 2. As the aircraft became more complex, the system was multiplied to ensure redundancy. 3. As aviation evolved - everyone got used to using airspeed for the reasons (a)-(c) mentioned above. 4. Flight control/navigation systems evolved - in order to make them 'user friendly' (and backward compatible) designers retained airspeed as a key concept in these systems. 5. Digital data buses were introduced. To minimize the cost/risk of introducing these novel systems - rely as much on existing technology (ain't broken - don't fix it) - hence we rely on the pitot system (btw - invented in the 18th century). Has anyone ever stepped back and asked - given today's technology - what is the best way to achieve (a), (b) and (c)? A 'clean sheet' approach, without the legacy of the past? I find it hard to believe there is no other way (as an additional, redundant system) to measure airspeed. Even yet another pitot tube - albeit a retracting one - could provide a working alternative if all the other ones fail. But has anyone ever thought about it? In an earlier post you could find patents filed by Airbus SAS on sensors (laser based). |
such a common mode degradation would not be detected initially and would fool the system into believing that the A/C was traveling faster than it really was. |
@Diversification
"Given the availability of technologies such as GPS, Inertial navigation, radio navigation, radar, AOA sensors - is it possible to build an avionics package which could automatically control (and provide pilots with information to manually control) the flight throughout all phases without requiring a pitot-static system at all?" @deSitter Dozy and syseng68k are correct in their assertions. APL, FORTH etc are nice tools, but are not as robust as some of the stuff used for safety critical applications - type checking etc. All done to keep the programmer from inflicting bugs on the unsuspecting. In the past I have had to use assembler for time critical embedded underwing stores Mil apps, where thecode produced from the C compiler was simply to inefficient (too slow) or the task - with faster processors, and more I/O functionality on chip, this is no longer necessary. What has not been mentioned here is that software requirements devolve down from system requirements. When I retired a few years back, there was a push in various safety critical industry sectors towards a design process where a system is modelled and simulated (hardware and software) under Matlab and auto coded by the Matlab compiler. The desired effect, theoretically, is to remove the programmer from the loop, and place more of the design task in the lap of the systems engineer. Some proponents have even suggested that simulations should produce straight raw code and forget any intermediate high level code. Nice idea if you can get it to work, but in the real world, it removes a level of validation (programmer checking the high level code),and to my mind is potentially dangerous. @mm43 I redid the calculation, and basically it is impossible to determine from it what the terminal RoD was, as depending at what time the Advisory happened, and allowing or not ACARS queue times, the outcome can be very much different. long it would take to reach VT assuming a stall with min or zero lift from upset to sea level. The non linear diff equation for a falling object that experiences drag is: mdv/dt = -m.g +1/2.Cd.p.A.v.v ...... (1) So, with terminal VT = root(2.m.g/p.Cd.A) ......(2) Sol is v(t) = VT.tanh(g.t/VT) From (3) you can make an estimate of the time to reach VT for step increments in t, and then use (2) thereafter, adjusting for density p. I suggest a Cd of 1.2 or 1.3, or else just plug in a value, say 70m/s, for VT. |
Questions for the 'bus drivers
Was wondering about training flights.
- Do you 'bus drivers ever get to see "an approach to stall" during checkout? - How many of you have ever "felt" the burble or buzz or wing rock or other indications that your AoA is a bit high or mach is too high? - How many 'bus drivers can recite from memory in 5 seconds what levels of protection "go away" or replaced by other sensor inputs to the FBW system going from "normal;" to "alt 1" to "alt 2" to "direct"? |
Originally Posted by takata
In fact, in normal flight, all the sensors are already not displaying the same data by a certain margin due to their airframe location: an aircraft is almost never flying in a perfect symetrical attitude and this will cause some noticeable variation between the various sensed pressures.
|
I'll ask the Airbus drivers a question that has come up before: would an AoA gage (which is apparently not common in any airliner design, and for most regimes of flight a supplemental scan item) be a useful addition to the flying display? (Disclaimer: This is not an A versus B comment, or an AF447 comment, hopefully just a politely informative one in response to a question. This is a tough crowd.) Most, if not all, Boeing 737 NG’s (not sure about BBJ’s or special orders) have an AOA display directly visible on both the PFD and in the HUD. Is it useful? Depends on the guy driving. |
Golf-Sierra: I'll give this a try even if here are many better qualified participants. Bear with me :)
First: why is airspeed so relevant? (a) It is a measure of the performance of the aerofoil/airframe (stall/buffet/structural limits), (b) It allows ground speed and track to be calculated, (c) it is a convenient way to ensure separation of aircraft within the same moving mass of air. b) only partly correct, as wind data is also a necessary input. c) hmm...ground speed would be just as convenient, wouldn't it? At least for the purpose of calculating safe separation distances. Has anyone ever stepped back and asked - given today's technology - what is the best way to achieve (a), (b) and (c)? A 'clean sheet' approach, without the legacy of the past? b) For realtime navigation, you need to use ground speed and ground track. VOR, GPS, and inertial methods all work independently of airspeed and have long since replaced airspeed and compass-based dead reckoning. For planning and routeing, fact is that fuel economics depend on airspeed, so it's most reasonable to use it, always together with wind forecast data. c) radar, TCAS, and more recently ADS-B for ensuring separation. I find it hard to believe there is no other way (as an additional, redundant system) to measure airspeed. Even yet another pitot tube - albeit a retracting one - could provide a working alternative if all the other ones fail. But has anyone ever thought about it? |
Hi HN39,
Originally Posted by HazelNuts39
I'm not quite sure how relevant this is but, IMVHO, that cannot be said of the pitot pressures.
|
Originally Posted by OK465
Most, if not all, Boeing 737 NG’s (not sure about BBJ’s or special orders) have an AOA display directly visible on both the PFD and in the HUD.
|
- news to me - got a pic? One of the many customer PFD options is an analogue/digital angle of attack display. The red line is the angle for stick shaker activation, the green band is the range of approach AoA. |
AS sensors
Hi,
Systemically speaking it is possible ("easily" today) to use two Pitot probes from different mfrs. (Fr and US) as LH and RH (main) sensors? Question relates to calibration, etc. |
takata,
In fact, in normal flight, all the sensors are already not displaying the same data by a certain margin due to their airframe location: an aircraft is almost never flying in a perfect symetrical attitude and this will cause some noticeable variation between the various sensed pressures. This is also the main reason why a clean probe system would very very unlikely be clogged (in flight) at exactly the same rate and at exactly the same time. It has been identified that, after such an event, if two airspeed sources become similar while still erroneous, the flight guidance computers will: -Display the FD bars again, and -Enable AP and AT re-engagement. |
Nick - 'customer option' is not 'most, if not all 737 NG's' in my book..
|
Hi,
In the press AFP-24.05.2011 PARIS - The associations of families of victims of the crash of Air France flight from Rio to Paris Monday wrote to Prime Minister Francois Fillon to express "their deep indignation" about "the conduct of the technical investigation chaotic" and leakage in the press. Families "you want to share their outrage and deep concern about the chaotic progress of the technical investigation" conducted by the Bureau of Investigation and Analysis (BEA), according to this letter which AFP has obtained copy. "Since the beginning of the operation of data" contained in the black boxes rescued early May off Brazil, "we are witnessing a broad disclosure of information that should remain confidential until the final report and within the strict framework of investigation ". Families are surprised that these leaks tend to favor the theory of human error and exonerate Air France and Airbus' under investigation as part of the judicial inquiry. " According to families, these facts "discredit the investigative authority", BEA, and "generate much suspicion on the independence of that body against leaks orchestrated." The four associations of relatives of victims signed the letter asking to François Fillon "to remind the different actors demands restraint, discipline, confidentiality, justice and ethics to which they would never have departed." The Wall Street Journal said Monday that the accident of flight AF447 in June 2009 was due to pilot error and poor monitoring procedures. According to the German magazine Der Spiegel quoted an expert who participated in the analysis of black boxes, the captain was not in the cockpit when the first alarm sounded. On 20 May, a spokesman for the BEA stated that the investigating agency would publish this weekend "on the factual elements of the flight that will determine the circumstances of the accident, but in no way causes. |
BOAC & Nick:
Nick's HUD picture reference does not have the AOA display. The PFD picture in the section dealing with Integrated Approach Nav (IAN) & NPS shows it clearly. That would be repeated in the HUD in that configuration. BOAC, you are correct, "most" is a relative term. The NG's I've dealt with have had AOA since 2001. I'm only familiar with specific carriers and all (not most) of their NG's have it. (If you're an NG driver, you obviously don't have it. I apologize for exaggerating.) |
Hi takata;
I mean that as long as the pitot tube is outside the boundary layer (and it is), the pressure inside is insensitive to small variations of the local flow angle. |
BOAC:
Sorry for the misunderstanding on my part - thought you were questioning the availability of the AoA indicator, rather than its prevalence. |
kilomikedelta, #2276
syseng68k; as chronicled in the "Lightning Empiricist" www.me.utexas.edu/~longoria/paynter/hmp/LITENING.pdf tendencies http://images.ibsrv.net/ibsrv/res/sr...s/embarass.gif. Am familiar with Philbrick Research and have seen their early brick op amps in use, as well as Analog Devices and Burr Brown parts. And yes, I do buy and read books on early analog computers, as well as oddball things like a half complete set of Rad Lab volumes. Sad really, but it's surprising how much of that early work is still relevant today. The history of electronics and computing can be a rich source of ideas for modern day designs. For example, embedded systems with very limited resources. You probably know this, but if you want to be astounded, take the lid off an early electromechanical inertial nav system. It's doubtfull if there are many engineers left in the world now who have the multidisciplinary skill set to even start to design such a system... |
All times are GMT. The time now is 02:02. |
Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.