737 MAX - Synthetic AoA
Thread Starter
737 MAX - Synthetic AoA
Part of the recertification of the MAX included an undertaking by Boeing to add a third AoA source to supplement the existing 2 AoA probes/vanes from the MAX-10 onwards. It is widely believed that the third source will be "synthetic" rather than a new physical vane. I believe that synthetic AoA is used on other later Boeing types. Can somebody explain how it is computed and what sources it uses? Follow-up question: Do those Boeing types that have synthetic AoA also use synthetic airspeed as well? I would imagine that if you have the infrastructure & computing power to generate AoA, the IAS is an easy extra step. TIA
There is an "easy" way to measure AoA if you have a decent inertial system.
The inertial will portray actual flight path in space on something...... a HUD, an FD or whatever. It will be related to your airframe axis depending on the display. But the biggie is you can compare the actual flight path with your plane's axis. The difference between your longitudinal axis with the other two axis combined will show your AoA - flight path related to wing angle.
The inertial will portray actual flight path in space on something...... a HUD, an FD or whatever. It will be related to your airframe axis depending on the display. But the biggie is you can compare the actual flight path with your plane's axis. The difference between your longitudinal axis with the other two axis combined will show your AoA - flight path related to wing angle.
I'll have to go back to my systems books, but Dave has something - my experience in two planes was with a HUD and its pitch and roll display was also related to local level and such. So the inertial vector and my "attitude" were using the same coord frame. My main idea was mainly using pitch, as the flight path marker .disagreed with the aircraft longitudinal reference point on the HUD unless you were at zero gee ( well, mostly).
EDIT: Upon reflection, I ignored wind. So my official position is we can use the inertial velocity vector in low wind or at high CAS to get a crude idea of our AoA but we will need something else besides that string I taped on the side window, heh heh.
Oh well, I honestly tink we can generate a useable AoA without the vanes or cones.
EDIT: Upon reflection, I ignored wind. So my official position is we can use the inertial velocity vector in low wind or at high CAS to get a crude idea of our AoA but we will need something else besides that string I taped on the side window, heh heh.
Oh well, I honestly tink we can generate a useable AoA without the vanes or cones.
Last edited by gums; 4th Feb 2021 at 12:36. Reason: corrections
ROFL... how often were you at zero-g in the Viper?
Back when the 777 was shiny and a novelty, used to use the FPV all day long including for unreliable airspeed events, which made for low-stress procedure. about 12 years after it was shiny, Boeing came out and suggested not to use the FPV as a back up for unreliable airspeed, as somewhere along the line, the FPV has some input that could give invalid input. Looking over the architecture, no obvious reason why that would be the case jumped out. Never saw a fault that took it out, but then they nearly never faulted anyway except in the sim, and sims simulate sims not aircraft. The FPV when there is worth its weight in Guinness.
The relevance of the above boring story is merely independent synthetic information can be had, but the more inputs that are added to make it feature-rich, the more failure modes exist and usually take time to come out of the woodwork. For 199, get a Dual or a bit more for a Stratus, and have ADSB IN, syn head down vision, backup attitude without the need of an emergency battery, terrain alerting, runway entry alerting.... traffic alerting, moving map, weather overlay, etc... the software guys are reticent to add FPV which is an ongoing irritant. They have attitude from a stable MEMS AHRS, with MEMS rate gyros, they have flight path, from the GPS.... and yet we get ATT but no FPV. We get ROD and GS.... whoopee, give an FPV and get rid of the sink rate to declutter.... or not, but please give the FPV. FPV and syn vision.... life is grand. Foreflight, Garmin, please...
We operate on EDTO/ETOPS limits which are great, say 208 minuters or 180 or whatever, and we are protected from everything except for the loss of power to the flight instruments, in that case, the 2 hours that you get from your ISFD less the route distance (time) limit is less than zero. an iPad is a nice thing, so is the dozens of apps that give attitude from your android or i-fone.
The relevance of the above boring story is merely independent synthetic information can be had, but the more inputs that are added to make it feature-rich, the more failure modes exist and usually take time to come out of the woodwork. For 199, get a Dual or a bit more for a Stratus, and have ADSB IN, syn head down vision, backup attitude without the need of an emergency battery, terrain alerting, runway entry alerting.... traffic alerting, moving map, weather overlay, etc... the software guys are reticent to add FPV which is an ongoing irritant. They have attitude from a stable MEMS AHRS, with MEMS rate gyros, they have flight path, from the GPS.... and yet we get ATT but no FPV. We get ROD and GS.... whoopee, give an FPV and get rid of the sink rate to declutter.... or not, but please give the FPV. FPV and syn vision.... life is grand. Foreflight, Garmin, please...
We operate on EDTO/ETOPS limits which are great, say 208 minuters or 180 or whatever, and we are protected from everything except for the loss of power to the flight instruments, in that case, the 2 hours that you get from your ISFD less the route distance (time) limit is less than zero. an iPad is a nice thing, so is the dozens of apps that give attitude from your android or i-fone.
I assume rationale/interest in the synthetic AoA subject is on another thread, huh?
Good points, FDR. Our first good HUD plane was prolly the A-7D,. which had a very good representation of velocity vector and great FOV. Could declutter some of the data. And they always cautioned us to fly basic gauges, but I'll bet most of us flew HUD and crosschecked the steam gauges.
The AF447 cree would have seen the FPV drop out the bottom of a HUD and I venture out the bottom of the flight director. That would have told them they had a very high AoA. As their attitude system was good, a high AoA would have been clear crystal. And ask any USN jock about using the FPV for carrier landings and launches on a dark, moonless night - very comforting.
OT alert........ some pilots trimmed the VIper to zero gee before entering a fight so all they had to do was release pressure on the stick and get optimum acceleration.
Good points, FDR. Our first good HUD plane was prolly the A-7D,. which had a very good representation of velocity vector and great FOV. Could declutter some of the data. And they always cautioned us to fly basic gauges, but I'll bet most of us flew HUD and crosschecked the steam gauges.
The AF447 cree would have seen the FPV drop out the bottom of a HUD and I venture out the bottom of the flight director. That would have told them they had a very high AoA. As their attitude system was good, a high AoA would have been clear crystal. And ask any USN jock about using the FPV for carrier landings and launches on a dark, moonless night - very comforting.
OT alert........ some pilots trimmed the VIper to zero gee before entering a fight so all they had to do was release pressure on the stick and get optimum acceleration.
EASA - "… an objective to implement a 737 MAX AOA Integrity Enhancement to further reduce crew workload following single AOA failures and to improve the systems reliability, thus alleviating the aircraft architectural AOA-dependency noted previously. "
The requirement is to reduce the effects of several system's dependency on AoA, minimise consequential alerts (distraction, surprise) and crew workload.
A systems view would suggest three AoA inputs with voting 2 out of 3. However, this may be not be an easy task with the 737s old (although digital) dual architecture. e.g. dual air-data system requires comparison, an alerting 'disagree' (between two), and crew to resolve validity with comparison of a third, dissimilar input - StBy ASI / ALT.
A third AoA, real or synthetic, would have to interface with this old architecture, with 'automatic' selection and changeover for EFIS and all other systems. Probably requiring the same format and resolution as the existing AoA input, thence how accurate is the third system.
Alternatively the new input might only be used as a monitor to resolve the dual comparison after the first failure, the aircraft then continuing to operate with one AoA - been there before.
This might not as significant as emotion suggests. If one of the current AoA inputs fail, and is compared and could be isolated with aid of system 3, then the aircraft would be in a similar state as the current 737 mod with MCAS isolated, but possibly fewer alerts and consequences.
The key to this is to appropriate switching logic and alert suppression. In a fully integrated aircraft this should be possible to amend all of the component functions 'in one box' - a systems approach. However, with the 737 'individual box' architecture there could be multiple changes and consequential interface issues, operational problems, and more failure paths - not the objective.
It may be relatively easy to find an additional AoA input, real / synthetic, but its integration very complex.
Also, a reversal of an AoA to speed algorithm, as with EFIS low speed awareness, might not work if the required inputs, Inertial, AirData, etc, already use AoA. Thus if one AoA fails, these inputs may not be sufficiently reliable to compute synthetic AoA - boot strapping.
As with existing dual / StdBy installations, human logic and judgement for resolution is more adaptable than computation; if only this did not come with the baggage of distraction and workload, - around and around we go … …
With gum's sharp mind, yes there is a relevant AF 447 debate in this. Save for later to test alternative views.
From the archives; AoA to Speed.
https://www.dropbox.com/s/ljdhpbsnby...Speed.pdf?dl=0
The requirement is to reduce the effects of several system's dependency on AoA, minimise consequential alerts (distraction, surprise) and crew workload.
A systems view would suggest three AoA inputs with voting 2 out of 3. However, this may be not be an easy task with the 737s old (although digital) dual architecture. e.g. dual air-data system requires comparison, an alerting 'disagree' (between two), and crew to resolve validity with comparison of a third, dissimilar input - StBy ASI / ALT.
A third AoA, real or synthetic, would have to interface with this old architecture, with 'automatic' selection and changeover for EFIS and all other systems. Probably requiring the same format and resolution as the existing AoA input, thence how accurate is the third system.
Alternatively the new input might only be used as a monitor to resolve the dual comparison after the first failure, the aircraft then continuing to operate with one AoA - been there before.
This might not as significant as emotion suggests. If one of the current AoA inputs fail, and is compared and could be isolated with aid of system 3, then the aircraft would be in a similar state as the current 737 mod with MCAS isolated, but possibly fewer alerts and consequences.
The key to this is to appropriate switching logic and alert suppression. In a fully integrated aircraft this should be possible to amend all of the component functions 'in one box' - a systems approach. However, with the 737 'individual box' architecture there could be multiple changes and consequential interface issues, operational problems, and more failure paths - not the objective.
It may be relatively easy to find an additional AoA input, real / synthetic, but its integration very complex.
Also, a reversal of an AoA to speed algorithm, as with EFIS low speed awareness, might not work if the required inputs, Inertial, AirData, etc, already use AoA. Thus if one AoA fails, these inputs may not be sufficiently reliable to compute synthetic AoA - boot strapping.
As with existing dual / StdBy installations, human logic and judgement for resolution is more adaptable than computation; if only this did not come with the baggage of distraction and workload, - around and around we go … …
With gum's sharp mind, yes there is a relevant AF 447 debate in this. Save for later to test alternative views.
From the archives; AoA to Speed.
https://www.dropbox.com/s/ljdhpbsnby...Speed.pdf?dl=0
Join Date: Jun 2007
Location: Wanderlust
Posts: 3,403
Likes: 0
Received 0 Likes
on
0 Posts
The AF447 cree would have seen the FPV drop out the bottom of a HUD and I venture out the bottom of the flight director. That would have told them they had a very high AoA.
In all fairness to the 'bus design, that sucker seems to be really stable and have very smooth stall that lacks buffeting, roll back and forth, etc.
You donot need to be Yeager to see a huge difference between flight path and attitude, and I do not recall a real high pitch attitude for the AF jet. In other words, where was the FPM in their FD or whatever you guys use for steering suggestions ( hopefully not 100% commands). If my basic ref symbol is high and the command symbol is out the bottom of the display, maybe my AoA aint so good.
I raised the story because first thing I noticed in an airplane with a HUD and FPM was when I nudged or yanked that the actual vector did not instantly follow the basic attitude indication. I was seeing a change in AoA just milliseconds before the change in lift caused an actual flight path change. I imagine that in a "heavy" that the lag is quite evident. The SLUF showed an AoA bracket all the time, so even without knowing the actual value, you could see it moving in response to your stick commands. It was like looking at what your academics taught you concerning how planes flew.
So I have high hopes for a fairly straightforward AoA solution to be implemented in the airplane of interest here. As PEI has commented, maybe the simplest solution is a third sensor that only comes into play if the two active ones disagree. Gee, I wonder if such an implementation has been used since 1973?
You donot need to be Yeager to see a huge difference between flight path and attitude, and I do not recall a real high pitch attitude for the AF jet. In other words, where was the FPM in their FD or whatever you guys use for steering suggestions ( hopefully not 100% commands). If my basic ref symbol is high and the command symbol is out the bottom of the display, maybe my AoA aint so good.
I raised the story because first thing I noticed in an airplane with a HUD and FPM was when I nudged or yanked that the actual vector did not instantly follow the basic attitude indication. I was seeing a change in AoA just milliseconds before the change in lift caused an actual flight path change. I imagine that in a "heavy" that the lag is quite evident. The SLUF showed an AoA bracket all the time, so even without knowing the actual value, you could see it moving in response to your stick commands. It was like looking at what your academics taught you concerning how planes flew.
So I have high hopes for a fairly straightforward AoA solution to be implemented in the airplane of interest here. As PEI has commented, maybe the simplest solution is a third sensor that only comes into play if the two active ones disagree. Gee, I wonder if such an implementation has been used since 1973?
