Order of Kilopi
Rule number one when I was at Boeing was "No single failure, or combination of failures more probable than one in a billion flight hours may cause a catastrophic accident." Reading just one AOA sensor sounds like a violation of that.
I'm kind of glad I'm not there any more.
Cum catapultae proscriptae erunt tum soli proscript catapultas habebunt.
Order of Kilopi
I'm sure it is, but the problem is that when things are going wrong, you don't want the pilot forgetting one memory item to result in a catastrophic accident.Originally Posted by schlaugh
As above, so below
Banned
And now we have https://www.popularmechanics.com/mil...trash-boeing/a
Have the people at Boeing simply forgotten they build a product that is dangerous? I would rather think they have people that worry about every little thing and back everything up three times over, not people who think it's fine to leave tools lying around, and occasionally think to give pilots a heads up about automatic systems that can make the planes fall out of the sky but it's OK because you can always try to remember how to turn them off before you hit the ground.
I'd say they need somebody there with a drill sergeant mentality who can line some people up and read them the riot act while the company still has some credibility for safety left. They actually claimed that leaving tools lying around the plane was not a safety concern, just some kind of litter problem! (Note to Boeing: when you leave tools lying around in random places in a plane you deliver to someone, you need to be the most concerned about that as anybody-- not the ones trying to say it's no big deal.)
Last edited by Ken G; 2019-Mar-20 at 12:17 AM.
Order of Kilopi
extraordinary news in both debris and software reports! I have visited the enormous Boeing factory for "the tour" and it reminded me of my apprenticeship in the Concorde hangar. Since then I have also worked with software writers and there can be a narrow focus issue. It's a situation where you need a narrow focus expert teamed with a broad experience person who can think of the ways a working system can go wrong. It's not just bugs and it's not just "what if?" the interface between the system and the human has always been tricky and never more so than for a pilot at take off. The danger I could pontificate about is automating the situation so that the pilot has less to do. You would hope every pilot has had plenty of experience of non automated flying including in the sophisticated planes we have today but fly by wire has its strengths and weakness when considering that ergonomic interface. There is so much simulator work now, I would have hoped that particular new stall prevention software was tested as part of pilot training but it sounds like the pilots are saying "no".
sicut vis videre esto
When we realize that patterns don't exist in the universe, they are a template that we hold to the universe to make sense of it, it all makes a lot more sense.
Originally Posted by Ken G
Order of Kilopi
I've gotten lost in that factory more than once.
Cum catapultae proscriptae erunt tum soli proscript catapultas habebunt.
Insert awesome title here
That's concerning. Do they not have a tally system? I've worked in hangers where a tool not accounted for is considered an emergency.
Order of Kilopi
I worked there more than 20 years. At Boeing, quality is king, but the schedule is God.
Cum catapultae proscriptae erunt tum soli proscript catapultas habebunt.
Order of Kilopi
it was claimed in the Telegraph yesterday, that the previous day to the crash an off duty pilot rushed to the cabin to disconnect the new anti stall system. I guess that pilot was either more experienced or better trained. And he/she was not on the doomed flight next day. Something very wrong there.
sicut vis videre esto
When we realize that patterns don't exist in the universe, they are a template that we hold to the universe to make sense of it, it all makes a lot more sense.
Originally Posted by Ken G
Order of Kilopi
Just to be clear, that was the Indonesia crash, not the one in Indonesia. And I think the off-duty pilot was in the cockpit, in a foldable seat like the ones that flight attendants use.
Sent from my iPhone using Tapatalk
As above, so below
Order of Kilopi
To be clear the pilot in the jumpseat recognized a runaway trim situation and applied the correct procedure-turn off the electric trim switches.
Today, the pilots cannot turn off MCAS; although the ability to do so is now under discussion.
ETA: From the story:
The so-called dead-head pilot on the earlier flight from Bali to Jakarta told the crew to cut power to the motor driving the nose down, according to the people familiar, part of a checklist that all pilots are required to memorise.
Last edited by schlaugh; 2019-Mar-22 at 01:10 PM.
Order of Kilopi
For those interested, the preliminary report has been issued by the Ethiopian Ministry of Transport on ET 302. It looks like the crew really struggled with trying to control the aircraft even after following the Boeing emergency procedures.
Still unanswered is why the pilots allowed the aircraft to accelerate to an overspeed condition at such a low altitude, so pilot interaction (or lack) is still a potential contributing cause and almost certainly brought on by a lot going on in the cockpit; stick shakers, warnings of "do not sink", overspeed indication clackers and (it appears) a Deicing Control that announced itself (with the exterior temperature at 16C.)
Current speculation is that a bird strike may have damaged one or more external instrument sensors, including the portside angle of attack sensor that fed the MCAS.
The flight timeline is on pages 9 - 12 in the PDF.
https://assets.documentcloud.org/doc...X-Ethiopia.pdf
Last edited by schlaugh; 2019-Apr-05 at 07:02 PM.
Established Member
I didn't hear of the bird strike but I did hear about false data from an external instrument.
Order of Kilopi
I saw the bird strike comment in a Reuters story, so take it with a salt shaker.
A key sensor had been wrecked, possibly by a bird strike. As soon as they retracted the landing gear, flaps and slats, it began to feed faulty data into the Maneuvering Characteristics Augmentation System (MCAS), designed to prevent stalls
Order of Kilopi
I Heard that the software had a faulty reset feature that instead of operation within the pilot over-ride zone, allowed the MCAS to tafe the trim past the point where the pilots could counter act it. I don't know if the faulty sensor then caused that reset to operate and force the nose down into a slow dive. Maybe the pilots tried to use the positive rotation effect of increased engine power to correct the fall?
sicut vis videre esto
When we realize that patterns don't exist in the universe, they are a template that we hold to the universe to make sense of it, it all makes a lot more sense.
Originally Posted by Ken G
Order of Kilopi
BBC article from today, detailing what is know so far about what went wrong. Many drawings and charts.
https://www.bbc.com/news/world-africa-47553174
Do good work. —Virgil Ivan "Gus" Grissom
Order of Kilopi
Maybe, but it’s also possible they just got overloaded with tasks and trying to figure out the problem.
The report talks about them using the trim toggles to make adjustments but it wasn’t adequate. And then they reenabled the trim circuit.
Established Member
Well we're all just speculating, until the full report is published and analyzed.
Banned
I think we can all agree, however, that the failure of a single sensor should never, ever, under any circumstances and for any set of pilot errors, create a roller coaster ride in which the pilots are fighting in vain against the software. That's just really obviously not a way you want to design anything. I fear the entire concept may be flawed, in which case there might not be a simple fix, but the most obvious thing would seem to be to have three sensors instead of one in any situation where it can cause that kind of issue.
Last edited by Ken G; 2019-Apr-05 at 10:39 PM.
Order of Kilopi
Boeing cuts/slows production of 737 MAX
https://www.nytimes.com/2019/04/05/b...roduction.html
Boeing finds second software issue with 737-MAX
https://www.wsj.com/articles/boeing-...ax-11554460806
Do good work. —Virgil Ivan "Gus" Grissom
Order of Kilopi
It was mentioned that turning the trim wheels manually is difficult. That would be with all power off. I saw the Mentour Pilot demonstrate that in a simulator in a YouTube video. However it should be slam-dunk common sense to enable disengaging the automation software should it malfunction but still have the electric power on the stabilizer jackscrew so the pilot can spin it either way by pushing the buttons on the yoke. Doing that is just normal flying skill for controlling a large airplane manually.
Order of Kilopi
This fellow has a good analysis of the timeline and the implications of each decision by the crew, and how difficult it was to manually trim the plane at those high speeds (and what they could / should have done).
https://youtu.be/HBqDcUqJ5_Q
ETA: Added correct link.
Last edited by schlaugh; 2019-Apr-06 at 01:00 PM.
Order of Kilopi
three sensors plus voting is often used as a design principle although it leaves room for stupid error. If one sensor can fail, then two can and the voting is useless. These systems are to detect pilot error and in the case of stall, there is a massive feedback which any pilot would recognise. Super stall is hopefully in the past now, designed out. I would have though that with just two sensors, any disagreement would drop the system out with a warning to the human pilot or to other redundant or back up safety systems. Stall is easily detected on the wing pressure sensors too as well as the fall state by the oldest of aviation instruments, the barometer. I feel These accidents have much wider implications than just for Boeing.
sicut vis videre esto
When we realize that patterns don't exist in the universe, they are a template that we hold to the universe to make sense of it, it all makes a lot more sense.
Originally Posted by Ken G
Established Member
This seems to be a video concerning salt.
Order of Kilopi
Whoops! Sorry about that. Let's try again.
https://youtu.be/HBqDcUqJ5_Q
Established Member
Seems like a perfect storm, equipment malfunction (AOA), MCAS sensing one bad(?) sensor for its functioning, the pilot(s) turning the autopilot back on allowing the MCAS to continue functioning, keeping the engine at 94%(maybe reduce so that the airspeed doesn't get higher and higher. Now I assume the pilots were attempting to gain altitude as their functioning indicated this and they may not wanted to turn back the engine percentage to help gain altitude.
Plenty of blame to go around it seems to me.
Anyway this is my take remembering I'm not a pilot and I may have made errors in this evaluation.
Order of Kilopi
I’m not a pilot either, but I am a programmer, and this looks like primarily a software design issue to me. Redundant sensors were available, but not used. The software went into a type of infinite loop, making recovery more difficult, and it appears the issue is correctable without hardware changes. Of course, as such things happen, it took special circumstances for the problem to manifest. Perhaps better trained pilots could have recovered, but they didn’t have much time and it shouldn’t have been an issue in the first place. I wonder if there were other unreported cases where the pilots did recover?
I do feel for the programmers. Obviously, they were under time pressure to deliver. I’m glad I never worked on anything with direct life and death implications.
"The problem with quotes on the Internet is that it is hard to verify their authenticity." — Abraham Lincoln
I say there is an invisible elf in my backyard. How do you prove that I am wrong?
The Leif Ericson Cruiser
Order of Kilopi
I'm not a pilot, nor a programmer, but am an aerospace & mechanical engineer who spent 21 years at the place in question. It's not a software design issue, it's a management issue. Quality is King, but the Schedule is God.
Cum catapultae proscriptae erunt tum soli proscript catapultas habebunt.
Banned
It certainly looks like a classic case of concealing the problem to avoid having the pilots object to it. What else could justify how little the pilots were told about how the software actually worked?
Order of Kilopi
Good video. I was pointed to it by someone else, as well.
Banned
I'm also not a pilot, but there would seem to be two extremely obvious design flaws to the MCAS system. I realize hindsight is 20-20, but this doesn't feel like hindsight at all, it seems like no-brainer logic:
1) There are two AOA sensors. Why on Earth would the pilot not be given the power to swap the one that the MCAS uses if the pilot thinks the MCAS is clearly malfunctioning (and I'm sure these pilots felt their MCAS was malfunctioning)?
2) The MCAS is able to physically tilt the stabilizer as far as it will go in the nose-down direction. Is there really any situation where that would be necessary? It seems obvious that if the stabilizer is that far from normal trim, you would not need an automatic system to try to prevent a stall, the pilot would know something is badly amiss and would be trying to do it manually. In other words, why doesn't the MCAS have a sensor on the stabilizer itself, rather than just AOA, such that the software could figure out that if one AOA says you are nose down, the other says you are nose up, and the stabilizer is abnormally nose-down, you might want to pay attention to the AOA that agrees with the physical position of the stabilizer?
So I really just don't understand why the design seemed to assume that just using one AOA would be all you ever need, even though you have both a second AOA, and a physical position of the stabilizer, to help the software assure it is not literally flying the plane into the ground. I cannot think of any situation where it would be viewed as fine to let the software crash a plane without using all the information that the flight recorder is completely aware of!!??
That said, the video does make the point that there were apparently two pilot errors. One was to maintain 94% thrust, which produced a dangerously high airspeed (and is probably the intuitive thing to do if you are in control of your stabilizer, but seems like a bad idea if you are fighting MCAS for the control of your stabilizer). The other was to turn MCAS back on (which presumably they did when they literally did not have the strength to turn the wheel to bring the nose up). But you can see how they might not have felt they had much choice, if they were worried about maintaining altitude they might have felt they needed to maintain high thrust, and if they couldn't turn the wheel they would have been pretty desperate to get help on that stabilizer and so turned to what was at that point their worst enemy: an MCAS system that was not using the information that other systems, like the flight recorder (and probably the pilots themselves), were perfectly aware of. That's the part I cannot make any sense of, it seems like a glaring and obvious design flaw to cripple the information the MCAS uses when it has the power to literally nose a plane right down into the ground.
Last edited by Ken G; 2019-Apr-07 at 04:03 PM.
Posting Permissions
Reply With Quote