|
Originally Posted by Just the fax maam
(Post 10420102)
Likely a source of puzzlement in the Pâtisseries of Toulouse, and no doubt a genuine point, however there might yet be an argument to be made along the lines of:
The likelihood of any inherent 73M aerodynamic instabilty issues causing a genuine and dangerous upset, in such a narrow and rarely visited corner of the flight envelope, is sufficiently remote as to not require constant monitoring of just AOA in all conditions. Or in other words, software (logic) might yet be able to reliably determine when such a minimal risk exists, based on multiple other available inputs, even if only 2 of those are AOA sensors... Non? |
Originally Posted by RickNRoll
(Post 10420855)
All raw data is suspect and all systems working with raw data must be able to tolerate faulty data. It should be a part of the system design and testing that faulty data is going to have to be dealt with.
First. At end of the day, control laws works as the data is reliable. Yes, they can work with unreliable information, but the information is made reliable by some means (e.g. (Kalman) filtering, fuzzy sets e.g. in a simple cases). Second issue is in the testing. There might be hughe testing set to cover all the possible cases. Unfortunately, impossible failure modes that are not recognized and are not tested... Third is money. Redundancy is kept minimal to avoid costs. Largely maintenance costs. Sensors tend to break down and nobody wants hangar queen. If you have only two sensors you can disable the whole feature with three you can vote one out. One additional problem with modern distributed automation system, where signals are digital "messages", is that you can't relay even to the causality in the trouble shooting. There are signals with different priorities and paths. So the response can sometimes seen before the action. It can make simple fault analysis complicated. There is role for the humans also in the future. Fortunately, human is very good in the trouble shooting. When seen MAX as a control system, MCAS can cause positive feedback in main control loop by trimming plane badly. When the nose goes down, the speed increases and stick force increases and speed tend to increase even more. In control theory positive feedback means instability. It can be tolerated in some subsystems but never in the main control loop. That is why, I think that the whole automation system should have consistent "process image" about trimming decisions and it can not be based on opinion of distinct subsystem (beyondtrimming where stick forces are reasonable when speed increases). The automatic nose down action should be implemented so that it can be reversed without long delays. If not, how can the pilots override control "mad" automation system? When working, the automation system can override pilot actions. It increases safety. On the other hand, automation system has to keep the plane in a condition where the pilot can take the plane in his/here control at any moment, also for safety reasons. Edit: I forget to mention one largely ignored fact: In a closed loop systems, the feedback (autopilot, pilot, etc.) restricts the possibility to identify the “state” of the system. So, the automation architecture has to be defined so that it does not restrict pilots situation awareness too much. |
seems to me that even with an AOA compare- some tolerances must be carefully derived due to yaw and banking and turns. OK- when outside those deined parameters, AOA makes one inout and then quits .-- sound good. But then come cert problems again.
IMHO a third sensor it needed for the above to resolve and act as a uncorruptible judge and jury . . What I do not understand is whyn BA does not /did not incorporate an INS ( Inertial navigation system ) essentlially as used on 787 ?? measurement in 3 axis plus time can give a reasonable independant compare for much of the same inputs used with AOA see pages 40 and 41 of the pdf following IntroducingtheB-787.pdf https://www.google.com/search?client...ducing+the+787 |
Hmmm, the 737 MAX should have an IRS (Inertial Reference System) at least. It has bigger drift, therefore not suitable as the only source for long distance / time navigation. Usually it is backed up by other NAV systems (DME/DME or VOR/DME or GPS).
It will only give position data, though. Especially at the limits of the flight envelope it won't be able to replace air data. |
Originally Posted by EDML
(Post 10422052)
Hmmm, the 737 MAX should have an IRS (Inertial Reference System) at least. It has bigger drift, therefore not suitable as the only source for long distance / time navigation. Usually it is backed up by other NAV systems (DME/DME or VOR/DME or GPS).
It will only give position data, though. Especially at the limits of the flight envelope it won't be able to replace air data. IntroducingtheB-787.pdf shows just how a INS can be an approx backup or judge https://www.google.com/search?client...ducing+the+787 |
Originally Posted by Vilters
(Post 10420820)
Stick pusher? ?
Just another system that will bring you the same result. => With a bad AOA input it will PUSH you into the ground. MCAS will trim you into the ground, the stick pusher will push you into the ground. => The size of the debris field will be the same. By the All mighty, attack the problem where it is ; The AOA sensors. |
stick pusher easily overridden by a tug on the control column rendering the aircraft totally controllable at all times, |
Originally Posted by CONSO
(Post 10422093)
NOPE- on MAX it does NOT cutout MCAS. And MCAS simply pauses for 5 to 10 seconds and then starts again . . but pauses only with trim swiches !
|
Originally Posted by ironbutt57
(Post 10422095)
exactly! Therein lies the problem...this “el-cheapo” alpha prot system is a can of worms, need to rethink the whole thing A grand jury in Washington, D.C., issued a broad subpoena dated March 11 to at least one person involved in the 737 MAX’s development, seeking related documents, including correspondence, emails and other messages, one of these people said. The subpoena, with a prosecutor from the Justice Department’s criminal division listed as a contact, sought documents to be handed over later this month. Its just a start ! |
Originally Posted by CONSO
(Post 10422093)
NOPE- on MAX it does NOT cutout MCAS. And MCAS simply pauses for 5 to 10 seconds and then starts again . . but pauses only with trim swiches !
IMHO the only reason the Lion crash happened after being somewhat controllable for 10 minutes, is that the captain who had re-trimmed to neutral over 15 times (I think), handed over control to the FO, who also retrimmed, but much smaller inputs, letting MCAS run the trim full AND. |
from seattle times
If the final safety analysis document was updated in parts, it certainly still contained the 0.6 limit in some places and the update was not widely communicated within the FAA technical evaluation team.“None of the engineers were aware of a higher limit,” said a second current FAA engineer.The discrepancy over this number is magnified by another element in the System Safety Analysis: The limit of the system’s authority to move the tail applies each time MCAS is triggered. And it can be triggered multiple times, as it was on the Lion Air flight.One current FAA safety engineer said that every time the pilots on the Lion Air flight reset the switches on their control columns to pull the nose back up, MCAS would have kicked in again and “allowed new increments of 2.5 degrees.” “So once they pushed a couple of times, they were at full stop,” meaning at the full extent of the tail swivel, he said.Peter Lemme, a former Boeing flight controls engineer who is now an avionics and satellite-communications consultant, said that because MCAS reset each time it was used, “it effectively has unlimited authority.” |
I don't write much, which is why I can't paste a URL. The Boeing and Aerospace piece in the 17 March Seattle Times is very interesting, the say the least. Some lawyers about to make a lot (more) of money.
|
Originally Posted by JPcont
(Post 10421019)
It sounds reasonable but I am afraid it is in reality only a pipe dream. There are few fundamental issues. For example:
First. At end of the day, control laws works as the data is reliable. Yes, they can work with unreliable information, but the information is made reliable by some means (e.g. (Kalman) filtering, fuzzy sets e.g. in a simple cases). Second issue is in the testing. There might be hughe testing set to cover all the possible cases. Unfortunately, impossible failure modes that are not recognized and are not tested... Third is money. Redundancy is kept minimal to avoid costs. Largely maintenance costs. Sensors tend to break down and nobody wants hangar queen. If you have only two sensors you can disable the whole feature with three you can vote one out. One additional problem with modern distributed automation system, where signals are digital "messages", is that you can't relay even to the causality in the trouble shooting. There are signals with different priorities and paths. So the response can sometimes seen before the action. It can make simple fault analysis complicated. There is role for the humans also in the future. Fortunately, human is very good in the trouble shooting. When seen MAX as a control system, MCAS can cause positive feedback in main control loop by trimming plane badly. When the nose goes down, the speed increases and stick force increases and speed tend to increase even more. In control theory positive feedback means instability. It can be tolerated in some subsystems but never in the main control loop. That is why, I think that the whole automation system should have consistent "process image" about trimming decisions and it can not be based on opinion of distinct subsystem (beyondtrimming where stick forces are reasonable when speed increases). The automatic nose down action should be implemented so that it can be reversed without long delays. If not, how can the pilots override control "mad" automation system? When working, the automation system can override pilot actions. It increases safety. On the other hand, automation system has to keep the plane in a condition where the pilot can take the plane in his/here control at any moment, also for safety reasons. Edit: I forget to mention one largely ignored fact: In a closed loop systems, the feedback (autopilot, pilot, etc.) restricts the possibility to identify the “state” of the system. So, the automation architecture has to be defined so that it does not restrict pilots situation awareness too much. |
The possibility that a single sensor failure can lead to a potentially catastrophic result must not be possible. In system safety terms, the probability of such an event must be Extremely Improbable. This system design apparently accepts a single source of AoA, which cannot possibly meet that fundamental requirement. Neither is there comparison between the two AoA sensors, apparently, to detect an integrity failure and prevent use of an invalid signal. While it may be unlikely that two AoA sensors will be simultaneously erroneous at similar values, that possibility, too, must be considered. News reports (Seattle Times) say that the system safety classification of an MCAS failure condition was Hazardous. But it should have been Catastrophic, and I’m not sure the exact failure condition of these accidents was even analyzed. The possibility of invalid AoA input to the MCAS must be prevented. Will a software enhancement remedy this? I don’t know, but I’m not confident of it. AoA validity/integrity must be ensured. Invalid signals must be detected and not used by MCAS. Personally, I don’t think comparison between two sensors is sufficient. |
A challenge for Boeing via investigators is to identify how ‘AoA’ came to dominate these accidents, whilst apparently using the same / similar AoA probe on older 737s. Some confusion for Ppruners is not knowing where the FDR AoA value is taken from - https://www.pprune.org/tech-log/6157...l#post10419333 The implication is that something other than the probe / probe output might contribute to the problem - wiring. Whilst the mechanism involves AoA, exactly where an error originates and interacts with MACS system is not known. If the error is not in the computation, then more attention is required on the Max probe failure rate and the aircraft wiring / build standard. MCAS enhances stability to meet certification requirements. Any other (unidentified) failures affecting MCAS (input or computation) could similarly invalidate the certification; failures might be acceptable for rare occurrences and a safe recovery, but not so for frequent failures, MEL, or a high probe failure rate. Whether the aircraft can be recovered safely with trim malfunction is central to these accidents. Thus the integrity of the overall trim system (tail jack stall) may require reassessment, including crews’ ability to fly a runaway trim recovery procedure (irrespective of MACS). The FAA should re-evaluate the trim runway procedure because in these accidents the crew were apparently unable to recover from a severe trim malfunction. Would the failure and procedure discussed in https://www.pprune.org/tech-log/6193...izer-trim.html still be considered tenable. Should there be an altitude limit to allow time for recovery, or is the procedure so unrealistic that any cause, risk of failure should similarly be improved. |
Originally Posted by CONSO
(Post 10422054)
Thism may be a repeat- but having problems withn link my apologies
IntroducingtheB-787.pdf shows just how a INS can be an approx backup or judge https://www.google.com/search?client...ducing+the+787 |
Originally Posted by PEI_3721
(Post 10422674)
[left]A challenge for Boeing via investigators is to identify how ‘AoA’ came to dominate these accidents, whilst apparently using the same / similar AoA probe on older 737s.
Some confusion for Ppruners is not knowing where the FDR AoA value is taken from - Edit: Gums has pointed out that apparently it's not the same as the NG, so probs best to disregard most of my speculation... FCC is listed as receiving digital AOA from the on-side ADIRU (not the SMYD). ADIRU is not listed as getting digital AOA from SMYD, SMYD is not listed as sending digital AOA to ADIRU or to FCC. All of which could mean that ADIRU also gets the analog inputs from AOA sensor - but I can't find confirmation of this in the manual, only in some non-Boeing diagrams online. The implication is that something other than the probe / probe output might contribute to the problem - wiring. Peter Lemme at satcom.guru did some analysis of possible wiring failures and results on AOA decoded values without coming up with much, however he didn't consider a short (or partial short) between sin and cos. I reckon this might give a fixed AOA offset over a range of AOA - but I am not sure what range, depends on offset and gain values that I don't know. Also I considered only resistance of the short, throw in capacitance, AC signals and result of phase shift on resolver decoding, and, er, well at that point I realised how long it is since I did analog stuff and how much I have forgotten... Just spotted this from Reuters (https://www.reuters.com/article/us-e...-idUSKCN1QZ1R9 ): now saying that ET FDR shows AOA data "very very similar" to Lion Air. :eek: |
Salute!
@ infrequent IF it's same as NG, then according to the AMM (CH27 - 27-32-00) the SMYD (Stall Management Yaw Damper) receives analog AOA inputs from sensor and sends digital AOA to FDR (via FDAU). Lemme has posted after the Lion Air tragedy that the SMYD functions have migrated to the FCC. Also. the elevator trim/elevator feel shift (EFS) function is a "module:' not a dedicated box like the "old", pre-MAX SYMD. GASP!!! https://www.satcom.guru/2018/11/737-...mand.html#more 20 November blog The EFS used to get its data from the ADRIU, and looks like the left/right logic was unchanged. So now we have two processors in the FCC and unless we can find a directly connected box or two, then the FCC is the driver for mach trim, STS, stall warning(shaker), basic trim functions and now the new MCAS. The description for EFS does not sound like the basic control column feel implementation. Some aspects of it include 1) radar altitude >100 feet, 2) a/p disengaged, 3) nose down trim and 4) no indication light it is active. So add this to the STS which 1) waits 5 seconds to activate after manual trim command and 2) doesn't work until 10 seconds after wow. I am sarting to see some connections with the numbers, and they are all in sfwe!!!!! Remember, the stab is basic trim and elevator trim is used for mach trim, maybe a/p functions but have to review the scant description we have. And now they are telling us they are gonna do a sfwe mod to "help" !!!! BEAM ME UP!!!!! Gums sends.... |
Originally Posted by gums
(Post 10422997)
Salute!
@ infrequent A big "if" and I do not believe it applies now. I guess I'll add reading comprehension to my lost skills :} - I had read that blog post (more than once) and totally missed that paragraph. Scratching my head to figure out the MAX, seems to be a frankenmix of old and new bits, what design goals required them to change flight proven stuff like the SMYD and EFSM from the NG (nothing to do with the engines) and then hide the differences and claim the MAX is just like the NG?:confused: |
Not sure how single trim output can work for MCAS stabilisation
What information is available points to a MCAS software update that increases the robustness of the AoA input but restricts stab trim output to one cycle only.
However, I don't understand how a single trim cycle could really create a particularly effective augmented stability. The trouble is, we really don't know much about the characteristics of MAX stability, and only part of the MCAS algorithm parameters. But it is likely that the Cm versus alpha curves for the unaugmented MAX tend to show a pre-stall region of decreased stability (not instability) due to Nacelle lift as below. This makes it easier to pull through the pre-stall region than at lower AoAs, and breaks certification. A control loop more robust and sophisticated than MCAS that senses AoA and actuates stab trim to make the desired Cm vs. alpha plot might be possible (although not necessarily a good idea). However, an MCAS2 that outputs only one trim event should produce something more like the plot below. Apologies for the large amount of assumptions and simplifications for this plot, but for want of more accurate values, the nacelle lift region stretches from AoA 8' to 14' (where the wing stalls). The MCAS-like system is putting in a single trim event (triggered at 10' AoA) that is effectively trimming the aircraft from AoA 5' to 2' (if the column was returned to neutral). The single trim event augmented performance is a very ragged approximation of the desired behaviour, in fact if you resisted the trim message from this MCAS2 by pulling through it, you would be back in the lower stability regime again until stall. If the lower stability region breaks certification it seems rather an ineffective fix. https://cimg7.ibsrv.net/gimg/pprune....0bd62f9898.jpg |
| All times are GMT. The time now is 22:13. |
Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.