Boeing 737 Max design error

On a sunny day (Mon, 6 May 2019 11:40:04 -0400) it happened bitrex
<user@example.net> wrote in <pzYzE.3$h75.1@fx41.iad>:

On 5/6/19 9:42 AM, Jan Panteltje wrote:

On a sunny day (Mon, 6 May 2019 06:27:34 -0700 (PDT)) it happened
trader4@optonline.net wrote in
0f4b448b-5459-4dbd-8b22-ef2f484f8752@googlegroups.com>:

On Monday, May 6, 2019 at 3:28:36 AM UTC-4, Jan Panteltje wrote:
On a sunny day (Sun, 5 May 2019 23:13:13 -0700) it happened Banders
snap@mailchute.com> wrote in <qaoj9p$1jpn$1@gioia.aioe.org>:

On 05/05/2019 08:25 PM, omnilobe@gmail.com wrote:
Weight and Balance of the 737 Max.

My opinion is that such software should be written by pilots,
not by spaced out no flying experience people.

That's ridiculous and what evidence do you have that the software developers
were spaced out?

That it did what it did!!!

When you design a safety system that relies on a single sensor to
determine whether the aircraft system is in a safety-critical state that
needs action "the AOA sensor indicates the aircraft is in stall", how do
you distinguish between a "normal" safety-critical situation "the AOA
sensor indicates the aircraft is in stall" where the plane a a whole is
in an error state but the safety system itself is still functioning
normally, vs. "the AOA indicates the aircraft is in stall...because the
AOA sensor is trashed" where the plane is still functioning normally but
the safety system is in an error state.

I don't know that I have an answer to that question either other than
"don't do that."

Indeed, software developer for embedded is also a hardware developer,
and should have refused or have sounded alarm when asked to code the system.
Indeed redundancy is required, but a lot more than that
It is possible that the sensor had nothing wrong with it,
as in the first crash that sensor was just replaced?
Or did they just replace the module with software?
Clearly not all data is released!
Had a pilot been in the software team (assuming it was a team and not some intern (on speed?)
(what I think and have stated before), something totally different would have
been created.
Now they are doing just those things, having pilot input, made a new system,
and are testing that,
And again a simple MEMS sensor can see if the attitude of the plane makes any sense
and software can then inhibit putting the nose ever more down, a 1$ sensor.
Also I have read the new system will now only correct the angle _once_.
 
On Monday, May 6, 2019 at 11:22:17 AM UTC-4, bitrex wrote:
On 5/6/19 9:27 AM, trader4@optonline.net wrote:
On Monday, May 6, 2019 at 3:28:36 AM UTC-4, Jan Panteltje wrote:
On a sunny day (Sun, 5 May 2019 23:13:13 -0700) it happened Banders
snap@mailchute.com> wrote in <qaoj9p$1jpn$1@gioia.aioe.org>:

On 05/05/2019 08:25 PM, omnilobe@gmail.com wrote:
Weight and Balance of the 737 Max.

I looked at photos of 737 and 737 Max. The 737 has the front of
the engine at the front of the wing. The Max has the rear of the engine at the front of the wing. That makes it stall easily.
Actually, tail-heavy makes for an easy stall, and nose-heavy makes for a
dive. The crash planes weren't stalling, the AOA sensors just thought
they were. So you have it backward.

This photo should put your mind at ease.
https://www.colombotelegraph.com/wp-content/uploads/2019/03/Crash-Animation-of-Ethiopian-Airlines-flight-ET302-Boeing-737-Max-pl
ane.jpg

Normally software is tested and debugged, crashes happen,
bit of a nono to debug it in flights that carry people.

By all indications it was not a software bug, from everything we've
seen the software did what the aerodynamic engineers and others spec'd
it to do. And it all was tested, including by test pilots, for
certification, including in extreme situations, where MCAS would be
involved.

After all the fatal crashes that have happened in recent history due to
fucked up/iced-up/taped-over airflow sensors they go and build in
another system that automatically points the plane at the ground if the
one fuckin' tube that the software relies on gets fucked up, as they
always seem to.

It's a vane, not a tube, but otherwise, I agree, it's hard to imagine.




Apparently having a stuck AOA sensor wasn't part of the
testing.

Not testing the edge-cases of your software, if that's indeed what they
didn't do, falls under "software bug." Just like you can build a power
amplifier that oscillates like mad at ultrasonic frequency until it
burns itself straight out when its input is removed that is a design
error, not a user error as inputs being removed is a natural thing to
happen to amplifiers, which often happens.

I don't know that it's a testing issue. Boeing aeronautical folks and
safety folks were OK with a design that did what it did. They classified
a failure as in the serious category. That means roughly that there could
be injuries as a result, even some deaths, but it's not expected to cause
the loss of the aircraft. With that classification, then
it has to have an expected failure rate of like one in hundreds of thousands.
(there is an exact number, I don't have it). So they calculated the odds
of the sensor and the rest of the system failing and it was within that
threshold and proceeded on.

It would be interesting to see how the software developers interacted
with the designers. And to know what Boeing expects from it's software
engineers, what the over-arching philosophy is. For example, are they
expected to add in features, eg checking that the sensor is reading
correctly on the ground? Is that even possible from the module that
the guy assigned is writing? Or is it expected to be part of some
flight initialization software, that checks all kind of things on
start up? If there was any checking, nothing notified the pilots that
the AOA was reading 30 deg while on the ground.




Gee whiz, I'm no aviation engineer but I probably could've thought to
test that scenario. Did they fire anyone? Are they hiring, now? That's
what I'll put on my resume "Yeah I'm an engineer from a totally
different field but I probably coulda thought to test that."

Test which scenario? And how as a software engineer would you test it?
If the sensor shows high AOA, MCAS starts putting nose down, in increasing
increments. To really see the results and consequences of a test,
you'd have to test the plane. Not clear that the software guys would
understand the total effect this would have on the aircraft.
 
On 5/6/19 12:09 PM, bitrex wrote:
On 5/6/19 10:36 AM, Joe Chisolm wrote:
On Mon, 06 May 2019 08:12:13 +0000, DecadentLinuxUserNumeroUno wrote:

omnilobe@gmail.com wrote in
news:c53fb380-eaac-4408-9422-959a9d1f8d3f@googlegroups.com:

Boeing is updating its software so the giant engines can unbalance the
airplane the same way as in the two crashes. Do you want to fly a plane
that only software is used to prevent stalling? Without software it
stalls.

   The software was for IF the plane stalled, which it did not.  It was
a sensor error.

   It is because the pilot does not always have a sense of a stall
situation, which the craft never get into anyway unless the pilot and
copilot are sleeping.

   A stalling plane is pilot error, not airplane error.

   The biggest issue to me is that there was no release switch to return
pilot control.

There is a procedure and it's a MEMORY item of what to do in a
run-away trim situation.  There are 2 switches, just below the
throttle quadrant that cuts out the electric trim (and MCAS).
Once turned off the AFM says you do not turn it back on.  It
stays off until you land.
Auto Pilot off
Auto Throttles off
Auto trim off.

A friend of mine with over 10K hours in the 737 variants explains
these are memory items drilled into your head and you practice
them every 6 months in the simulator check ride.

In the Ethiopian crash it seems they never disabled the auto throttles
and towards the end they re-engaged auto trim (and MCAS).  The aircraft
was already red-line in speed.


Boeing knows from a PR perspective that many Americans will be glad to
accept that it was the dumb filthy subhuman shithole country pilots who
caused the crash to happen and they very much hoped to roll with that
explanation if it was just one, except there were two crashes in
entirely different shithole countries with entirely different crews, to
explain.

That is to say it also starts to look kinda bad if it begins to seem
like what they're saying in every case of an overseas crash is
"(shithole country) operator error" when most of your sales of a
particular product are to said shithole countries because most domestic
carriers said "no thanks" to the product.
 
On Monday, May 6, 2019 at 11:02:30 AM UTC-4, bitrex wrote:
On 5/6/19 4:26 AM, DecadentLinuxUserNumeroUno@decadence.org wrote:
bitrex <user@example.net> wrote in news:c1RzE.535275$cD4.504076
@fx43.iad:

500-something people dead and Boeing seems to just shrug it off like
they're Microsoft and they're gonna patch a bug in Windows 10 at the
next update. "Sorry, our bad."

You are so full of shit. You have no clue what they are doing with
the families of the victims, etc.

I'd imagine they're hiring a lot more of the best legal teams money can
buy to fight all the negligence lawsuits heading their way and tie them
up in court until about the year 2045 would be my guess.

The lawsuits from the victims are the least of Boeing's problems.
They will wind up paying far more to all the airlines that have grounded
737 Maxs with no date in sight for that to end. And they are losing
orders as some airlines move away from the Max. And there could be
criminal charges too, depending on the investigation.
 
On Monday, May 6, 2019 at 11:40:09 AM UTC-4, bitrex wrote:
On 5/6/19 9:42 AM, Jan Panteltje wrote:

On a sunny day (Mon, 6 May 2019 06:27:34 -0700 (PDT)) it happened
trader4@optonline.net wrote in
0f4b448b-5459-4dbd-8b22-ef2f484f8752@googlegroups.com>:

On Monday, May 6, 2019 at 3:28:36 AM UTC-4, Jan Panteltje wrote:
On a sunny day (Sun, 5 May 2019 23:13:13 -0700) it happened Banders
snap@mailchute.com> wrote in <qaoj9p$1jpn$1@gioia.aioe.org>:

On 05/05/2019 08:25 PM, omnilobe@gmail.com wrote:
Weight and Balance of the 737 Max.

My opinion is that such software should be written by pilots,
not by spaced out no flying experience people.

That's ridiculous and what evidence do you have that the software developers
were spaced out?

That it did what it did!!!

When you design a safety system that relies on a single sensor to
determine whether the aircraft system is in a safety-critical state that
needs action "the AOA sensor indicates the aircraft is in stall", how do
you distinguish between a "normal" safety-critical situation "the AOA
sensor indicates the aircraft is in stall" where the plane a a whole is
in an error state but the safety system itself is still functioning
normally, vs. "the AOA indicates the aircraft is in stall...because the
AOA sensor is trashed" where the plane is still functioning normally but
the safety system is in an error state.

I don't know that I have an answer to that question either other than
"don't do that."

One way would be to look at other data, eg airspeed and attitude and see
if that's consistent with a stall. There is going to be a wide range
where the plane couldn't be stalling based on the other data. Including
the flights that crashed. You'd have to be doing an extreme maneuver
to get into a high angle of attack stall. And that is apparently what
Boeing is now doing as part of the new software.
 
On 5/6/19 10:36 AM, Joe Chisolm wrote:
On Mon, 06 May 2019 08:12:13 +0000, DecadentLinuxUserNumeroUno wrote:

omnilobe@gmail.com wrote in
news:c53fb380-eaac-4408-9422-959a9d1f8d3f@googlegroups.com:

Boeing is updating its software so the giant engines can unbalance the
airplane the same way as in the two crashes. Do you want to fly a plane
that only software is used to prevent stalling? Without software it
stalls.

The software was for IF the plane stalled, which it did not. It was
a sensor error.

It is because the pilot does not always have a sense of a stall
situation, which the craft never get into anyway unless the pilot and
copilot are sleeping.

A stalling plane is pilot error, not airplane error.

The biggest issue to me is that there was no release switch to return
pilot control.

There is a procedure and it's a MEMORY item of what to do in a
run-away trim situation. There are 2 switches, just below the
throttle quadrant that cuts out the electric trim (and MCAS).
Once turned off the AFM says you do not turn it back on. It
stays off until you land.
Auto Pilot off
Auto Throttles off
Auto trim off.

A friend of mine with over 10K hours in the 737 variants explains
these are memory items drilled into your head and you practice
them every 6 months in the simulator check ride.

In the Ethiopian crash it seems they never disabled the auto throttles
and towards the end they re-engaged auto trim (and MCAS). The aircraft
was already red-line in speed.

Boeing knows from a PR perspective that many Americans will be glad to
accept that it was the dumb filthy subhuman shithole country pilots who
caused the crash to happen and they very much hoped to roll with that
explanation if it was just one, except there were two crashes in
entirely different shithole countries with entirely different crews, to
explain.
 
On 5/6/19 1:34 PM, bitrex wrote:
On 5/6/19 12:02 PM, trader4@optonline.net wrote:
On Monday, May 6, 2019 at 11:02:30 AM UTC-4, bitrex wrote:
On 5/6/19 4:26 AM, DecadentLinuxUserNumeroUno@decadence.org wrote:
bitrex <user@example.net> wrote in news:c1RzE.535275$cD4.504076
@fx43.iad:

500-something people dead and Boeing seems to just shrug it off like
they're Microsoft and they're gonna patch a bug in Windows 10 at the
next update. "Sorry, our bad."

    You are so full of shit.  You have no clue what they are doing with
the families of the victims, etc.

I'd imagine they're hiring a lot more of the best legal teams money can
buy to fight all the negligence lawsuits heading their way and tie them
up in court until about the year 2045 would be my guess.

The lawsuits from the victims are the least of Boeing's problems.
They will wind up paying far more to all the airlines that have grounded
737 Maxs with no date in sight for that to end.  And they are losing
orders as some airlines move away from the Max.   And there could be
criminal charges too, depending on the investigation.


On the bright side the DC-10/MD-11 eventually became a well-regarded
aircraft and is still used by many cargo fleets today

incidentally the oldest bucket I've had the pleasure of flying on was a
DC-9, New York Air. It must have been 1985 or 1986 I was very young but
I still remember the plane with the apple on the tail. It was probably a
unit from the late 60s. What a bucket
 
On 06/05/19 15:01, trader4@optonline.net wrote:
On Monday, May 6, 2019 at 5:00:14 AM UTC-4, Sylvia Else wrote:
On 6/05/2019 1:25 pm, omnilobe@gmail.com wrote:
Hello electronics design experts. I will never fly a 737 Max.
It is so flawed that board members at Boeing, like Caroline Kennedy and
Nikki Haley (Trump UN ambassador) should use their expertise to terminate
that death trap.

Electronics design sometimes used redundant sensors in case it is for
life support. Not Boeing. Kennedy and Haley approve of

Weight and Balance of the 737 Max.

I looked at photos of 737 and 737 Max. The 737 has the front of
the engine at the front of the wing. The Max has the rear of the engine at the front of the wing. That makes it stall easily. Software cannot fix that
weights and balance mistake.

Boeing is updating its software so the giant engines can unbalance the
airplane the same way as in the two crashes. Do you want to fly a plane
that only software is used to prevent stalling? Without software it stalls.
With software it is low cost.
Nikki Haley is a Trump liar. Do not fly Trump-Boeing death traps. Don doesn't.

The Board at Boeing is packed with dunces and insurance agents who know nothing
about Weights and Balances of aircraft.


The effect of the software behaviour, as was, was to trim the aircraft
forward for no good reason.

The pilots should have treated it as a runaway trim, and acted
accordingly. Then the crashes would not have occurred.

+1

And the Lion Air pilot on the flight the day before the crash, did exactly
that. He wasn't flying, just catching a rid in the jump seat. When the
other pilots couldn't figure it out, he did. This is the most shocking
thing.

The most shocking thing is that the problem occurred so frequently.



Serious questions need to be asked about the competence of the pilots.
Would a properly trained crew have had any difficulties, even in the
absence of details about MCAS? I rather think not.

The system's entire *purpose* was to *avoid* new *training*.

"No new training" was the *reason* the system was installed.

So the concept of "properly trained" is a complete misdirection,
in the sense that magicians misdirect their audience's attention.
 
On 5/6/19 12:02 PM, trader4@optonline.net wrote:
On Monday, May 6, 2019 at 11:02:30 AM UTC-4, bitrex wrote:
On 5/6/19 4:26 AM, DecadentLinuxUserNumeroUno@decadence.org wrote:
bitrex <user@example.net> wrote in news:c1RzE.535275$cD4.504076
@fx43.iad:

500-something people dead and Boeing seems to just shrug it off like
they're Microsoft and they're gonna patch a bug in Windows 10 at the
next update. "Sorry, our bad."

You are so full of shit. You have no clue what they are doing with
the families of the victims, etc.

I'd imagine they're hiring a lot more of the best legal teams money can
buy to fight all the negligence lawsuits heading their way and tie them
up in court until about the year 2045 would be my guess.

The lawsuits from the victims are the least of Boeing's problems.
They will wind up paying far more to all the airlines that have grounded
737 Maxs with no date in sight for that to end. And they are losing
orders as some airlines move away from the Max. And there could be
criminal charges too, depending on the investigation.

On the bright side the DC-10/MD-11 eventually became a well-regarded
aircraft and is still used by many cargo fleets today
 
On 06/05/19 15:26, trader4@optonline.net wrote:
Altitude would not seem to be a parameter in determining if the plane is
stalling or not.

You can stall a plane at any attitude and any speed.
I've done that, many times.

It is particularly intense when you enter a spin
at 100ft AGL.
 
On 06/05/19 10:44, Sylvia Else wrote:
On 6/05/2019 7:37 pm, Tom Gardner wrote:
On 06/05/19 10:00, Sylvia Else wrote:
On 6/05/2019 1:25 pm, omnilobe@gmail.com wrote:
Hello electronics design experts. I will never fly a 737 Max. It is so
flawed that board members at Boeing, like Caroline Kennedy and Nikki
Haley (Trump UN ambassador) should use their expertise to terminate
that death trap.

Electronics design sometimes used redundant sensors in case it is for
life support. Not Boeing. Kennedy and Haley approve of

Weight and Balance of the 737 Max.

I looked at photos of 737 and 737 Max. The 737 has the front of the
engine at the front of the wing. The Max has the rear of the engine at
the front of the wing. That makes it stall easily. Software cannot fix
that weights and balance mistake.

Boeing is updating its software so the giant engines can unbalance the
airplane the same way as in the two crashes. Do you want to fly a plane
that only software is used to prevent stalling? Without software it
stalls. With software it is low cost. Nikki Haley is a Trump liar. Do
not fly Trump-Boeing death traps. Don doesn't.

The Board at Boeing is packed with dunces and insurance agents who know
nothing about Weights and Balances of aircraft.


The effect of the software behaviour, as was, was to trim the aircraft
forward for no good reason.

The MCAS software commanded a dive for a very *good* reason: the AoA was
dangerously high. Or so it was being told by a faulty sensor.


The pilots should have treated it as a runaway trim, and acted
accordingly. Then the crashes would not have occurred.

They were overridden by the MCAS.

The procedure for a runaway trim involves tripping two switches that
disconnect the electric trim. It prevents the MCAS, or anything else, from
moving the trim electrically.

In the Ethopian crash, they did trip those switches, and it did prevent the
MCAS from doing anything, but they also couldn't, or didn't, rotate the trim
wheels manually to get the aircraft back into trim. They then,
unaccountably, tripped the switches again, reenabling the electric trim, and
in the process letting the MCAS make the situation even worse.

You've snipped and avoided several key points from my previous post, so here
they are again.....



Disabling the MCAS wasn't trivial. Normally manually
operating the controls will disable the autopilot and
give control back to the pilots. But MCAS wasn't part
of the autopilot and was designed to prevent that.

Don't forget that the *purpose* of MCAS was to *pretend*
nothing had changed, i.e. pretend that MCAS didn't exist!



It seems likely that Boeing expected that that would happen in the event that
this> non-redundant computer system misbehaved.

Yet in both cases the pilots let the aircraft get itself seriously out of
trim. So much so, that in the case of the second crash, when the the pilots
did eventually disable the electric trim, the aircraft was so far out of
trim that the pilots were not strong enough to turn the trim wheels (or they
didn't try - it's rather unclear at the moment).

It was far more than "trim".


Serious questions need to be asked about the competence of the pilots. Would
a properly trained crew have had any difficulties, even in the absence of
details about MCAS? I rather think not.

Hiding behind "properly trained" is frequently an
inadequate figleaf. That's definitely the case here,
since the the whole purpose of MCAS is, *very explicitly*,
to *avoid* having to retrain pilots!

For a long time Boeing has trumpeted that they allow
their pilots full autonomy, unlike the Airbus fly-by-wire
system. MCAS is a complete change in that philosophy.
 
mandag den 6. maj 2019 kl. 10.12.17 UTC+2 skrev DecadentLinux...@decadence.org:
omnilobe@gmail.com wrote in
news:c53fb380-eaac-4408-9422-959a9d1f8d3f@googlegroups.com:

Boeing is updating its software so the giant engines can unbalance
the airplane the same way as in the two crashes. Do you want to
fly a plane that only software is used to prevent stalling?
Without software it stalls.

The software was for IF the plane stalled, which it did not. It was
a sensor error.

It is because the pilot does not always have a sense of a stall
situation, which the craft never get into anyway unless the pilot and
copilot are sleeping.

A stalling plane is pilot error, not airplane error.

and before that there's a stick shaker and the stick pusher

The biggest issue to me is that there was no release switch to return
pilot control.

there is, two switches to turn off electric trim and the pilots are supposed
to know how to handle run away trim by memory
 
On Monday, 6 May 2019 17:22:19 UTC+1, tra...@optonline.net wrote:

Or is it expected to be part of some
flight initialization software, that checks all kind of things on
start up? If there was any checking, nothing notified the pilots that
the AOA was reading 30 deg while on the ground.

The AOA sensors were both operating correctly on the ground and
during take-off. They both developed faults (to differing degrees)
after take-off. This is according to the preliminary accident
investigation report - which I have read.

John
 
On 5/6/19 12:07 PM, trader4@optonline.net wrote:
On Monday, May 6, 2019 at 11:40:09 AM UTC-4, bitrex wrote:
On 5/6/19 9:42 AM, Jan Panteltje wrote:

On a sunny day (Mon, 6 May 2019 06:27:34 -0700 (PDT)) it happened
trader4@optonline.net wrote in
0f4b448b-5459-4dbd-8b22-ef2f484f8752@googlegroups.com>:

On Monday, May 6, 2019 at 3:28:36 AM UTC-4, Jan Panteltje wrote:
On a sunny day (Sun, 5 May 2019 23:13:13 -0700) it happened Banders
snap@mailchute.com> wrote in <qaoj9p$1jpn$1@gioia.aioe.org>:

On 05/05/2019 08:25 PM, omnilobe@gmail.com wrote:
Weight and Balance of the 737 Max.

My opinion is that such software should be written by pilots,
not by spaced out no flying experience people.

That's ridiculous and what evidence do you have that the software developers
were spaced out?

That it did what it did!!!

When you design a safety system that relies on a single sensor to
determine whether the aircraft system is in a safety-critical state that
needs action "the AOA sensor indicates the aircraft is in stall", how do
you distinguish between a "normal" safety-critical situation "the AOA
sensor indicates the aircraft is in stall" where the plane a a whole is
in an error state but the safety system itself is still functioning
normally, vs. "the AOA indicates the aircraft is in stall...because the
AOA sensor is trashed" where the plane is still functioning normally but
the safety system is in an error state.

I don't know that I have an answer to that question either other than
"don't do that."

One way would be to look at other data, eg airspeed and attitude and see
if that's consistent with a stall. There is going to be a wide range
where the plane couldn't be stalling based on the other data. Including
the flights that crashed. You'd have to be doing an extreme maneuver
to get into a high angle of attack stall. And that is apparently what
Boeing is now doing as part of the new software.

Looks good on paper but once you start resorting to indirect heuristics
like that it can become very difficult to verify that the system is
still logically consistent and not introduce other, more subtle, bugs.

the story is that IBM charged something like a million bucks a line back
in the day to modify the Space Shuttle flight control software for that
kind of reason. and its code surely has numerous still-undiscovered bugs
but irrelevant, now.
 
mandag den 6. maj 2019 kl. 16.36.21 UTC+2 skrev Joe Chisolm:
On Mon, 06 May 2019 08:12:13 +0000, DecadentLinuxUserNumeroUno wrote:

omnilobe@gmail.com wrote in
news:c53fb380-eaac-4408-9422-959a9d1f8d3f@googlegroups.com:

Boeing is updating its software so the giant engines can unbalance the
airplane the same way as in the two crashes. Do you want to fly a plane
that only software is used to prevent stalling? Without software it
stalls.

The software was for IF the plane stalled, which it did not. It was
a sensor error.

It is because the pilot does not always have a sense of a stall
situation, which the craft never get into anyway unless the pilot and
copilot are sleeping.

A stalling plane is pilot error, not airplane error.

The biggest issue to me is that there was no release switch to return
pilot control.

There is a procedure and it's a MEMORY item of what to do in a
run-away trim situation. There are 2 switches, just below the
throttle quadrant that cuts out the electric trim (and MCAS).
Once turned off the AFM says you do not turn it back on. It
stays off until you land.
Auto Pilot off
Auto Throttles off
Auto trim off.

A friend of mine with over 10K hours in the 737 variants explains
these are memory items drilled into your head and you practice
them every 6 months in the simulator check ride.

In the Ethiopian crash it seems they never disabled the auto throttles
and towards the end they re-engaged auto trim (and MCAS). The aircraft
was already red-line in speed.

yes it does seem strange what the pilots did, but they might have had a
reason for it, I guess we will learn eventually

I saw a 737 pilot show in a simulator that it is possible at high speed
to get so much nose down trim that is near impossible to move the trim nose
up because of the aero dynamic forces, the solution is to dive while trimming but with no altitude to spare that's not an option
 
On 5/6/19 12:30 PM, Jan Panteltje wrote:
On a sunny day (Mon, 6 May 2019 11:40:04 -0400) it happened bitrex
user@example.net> wrote in <pzYzE.3$h75.1@fx41.iad>:

On 5/6/19 9:42 AM, Jan Panteltje wrote:

On a sunny day (Mon, 6 May 2019 06:27:34 -0700 (PDT)) it happened
trader4@optonline.net wrote in
0f4b448b-5459-4dbd-8b22-ef2f484f8752@googlegroups.com>:

On Monday, May 6, 2019 at 3:28:36 AM UTC-4, Jan Panteltje wrote:
On a sunny day (Sun, 5 May 2019 23:13:13 -0700) it happened Banders
snap@mailchute.com> wrote in <qaoj9p$1jpn$1@gioia.aioe.org>:

On 05/05/2019 08:25 PM, omnilobe@gmail.com wrote:
Weight and Balance of the 737 Max.

My opinion is that such software should be written by pilots,
not by spaced out no flying experience people.

That's ridiculous and what evidence do you have that the software developers
were spaced out?

That it did what it did!!!

When you design a safety system that relies on a single sensor to
determine whether the aircraft system is in a safety-critical state that
needs action "the AOA sensor indicates the aircraft is in stall", how do
you distinguish between a "normal" safety-critical situation "the AOA
sensor indicates the aircraft is in stall" where the plane a a whole is
in an error state but the safety system itself is still functioning
normally, vs. "the AOA indicates the aircraft is in stall...because the
AOA sensor is trashed" where the plane is still functioning normally but
the safety system is in an error state.

I don't know that I have an answer to that question either other than
"don't do that."

Indeed, software developer for embedded is also a hardware developer,
and should have refused or have sounded alarm when asked to code the system.
Indeed redundancy is required, but a lot more than that
It is possible that the sensor had nothing wrong with it,
as in the first crash that sensor was just replaced?
Or did they just replace the module with software?
Clearly not all data is released!
Had a pilot been in the software team (assuming it was a team and not some intern (on speed?)
(what I think and have stated before), something totally different would have
been created.
Now they are doing just those things, having pilot input, made a new system,
and are testing that,
And again a simple MEMS sensor can see if the attitude of the plane makes any sense
and software can then inhibit putting the nose ever more down, a 1$ sensor.
Also I have read the new system will now only correct the angle _once_.

I think a "safety" system that is designed to bring the system it's
managing the safety of, out of an error state, via some other action
which in a different circumstance is also an error state and a safety
risk too, has to be able to determine, with high accuracy, whether it's
the overall system or itself that is in an error state.

If I'm understanding what I've read correctly (and I accept that I do
not, I'm not an aviation engineer but it doesn't seem to stop anyone
else from offering their commentary so...) the system relied on one AOA
sensor to determine the overall state of the aircraft with respect to
what action it needed to take.

but I think there's a fundamental information theory problem there in
that with one sensor it doesn't have enough information to determine
conclusively whether it's the overall system or itself that is the one
in error. As long as everything works fine it works fine, but when it
doesn't the system can no longer "reason" conclusively about anything
anymore it's like the thought experiment of sitting in the train next to
another train and figuring out which of you is the one moving.

And it sounds like the patch is to provide more indirect information
from e.g. the airspeed and altimeter but as they don't actually measure
the true parameter of interest it would seem to fall under the category
of "heuristics" or "hacks."

It seems on paper like a reasonable thing to do and may improve things
in empirical testing, but my guess is once you start using hacks like
that there's no reasonable way to algorithmic-ally verify that this new
system is actually internally logically consistent. it probably isn't.

Automation is probably a net benefit but I don't think aircraft should
be flown by the halting problem
 
On 06/05/19 13:55, trader4@optonline.net wrote:
On Sunday, May 5, 2019 at 11:25:13 PM UTC-4, omni...@gmail.com wrote:
Hello electronics design experts. I will never fly a 737 Max.
It is so flawed that board members at Boeing, like Caroline Kennedy and
Nikki Haley (Trump UN ambassador) should use their expertise to terminate
that death trap.

Electronics design sometimes used redundant sensors in case it is for
life support. Not Boeing. Kennedy and Haley approve of

Weight and Balance of the 737 Max.

I looked at photos of 737 and 737 Max. The 737 has the front of
the engine at the front of the wing. The Max has the rear of the engine at the front of the wing. That makes it stall easily.

It doesn't stall so easily. The problem only arises at very high levels
of angle of attack, that a plane would only experience in extreme, very
unusual situations. And then the problem is
that if you let go of the controls, instead of heading back toward a
lower angle of attack, the plane can nose up more, which would stall it.
The plane likely could not have been certified with that problem.
That's what MCAS was put in there to counteract. Granted it's not the
best design and a totally new plane design would have been better.
But then that costs a lot more, both in development and then you have
increased costs for the airlines due to training, type ratings, and now
you have a mixed fleet that adds to maintenance costs, etc.

False.

The problem is that when approaching a stall, the SOP is to
increase engine power. In the 737 MAX (unlike all other 737s)
that causes a pitch up due to the changed engine position.
That pitch up increases angle of attack, thus driving further
into the stall.

MCAS was designed to sense that, and pitch down in a way
invisible to the pilot - so that no new training was required.


Software cannot fix that
weights and balance mistake.

Boeing is updating its software so the giant engines can unbalance the
airplane the same way as in the two crashes. Do you want to fly a plane
that only software is used to prevent stalling? Without software it stalls.

That's not true, except at very high angles of attack it behaves just like
any other 737.

False, or at least irrelevant.

The MAX's changed aerodynamics make it more likely to encounter
high AoA, and if it does, the changed aerodynamics force it
into even higher AoA.

MCAS was designed to detect and prevent the latter - without
the pilot being aware of any changes. "No new training
required, because it behaves the same".
 
On 06/05/19 19:03, Lasse Langwadt Christensen wrote:
mandag den 6. maj 2019 kl. 19.44.26 UTC+2 skrev Tom Gardner:
On 06/05/19 13:55, trader4@optonline.net wrote:
On Sunday, May 5, 2019 at 11:25:13 PM UTC-4, omni...@gmail.com wrote:
Hello electronics design experts. I will never fly a 737 Max.
It is so flawed that board members at Boeing, like Caroline Kennedy and
Nikki Haley (Trump UN ambassador) should use their expertise to terminate
that death trap.

Electronics design sometimes used redundant sensors in case it is for
life support. Not Boeing. Kennedy and Haley approve of

Weight and Balance of the 737 Max.

I looked at photos of 737 and 737 Max. The 737 has the front of
the engine at the front of the wing. The Max has the rear of the engine at the front of the wing. That makes it stall easily.

It doesn't stall so easily. The problem only arises at very high levels
of angle of attack, that a plane would only experience in extreme, very
unusual situations. And then the problem is
that if you let go of the controls, instead of heading back toward a
lower angle of attack, the plane can nose up more, which would stall it.
The plane likely could not have been certified with that problem.
That's what MCAS was put in there to counteract. Granted it's not the
best design and a totally new plane design would have been better.
But then that costs a lot more, both in development and then you have
increased costs for the airlines due to training, type ratings, and now
you have a mixed fleet that adds to maintenance costs, etc.

False.

The problem is that when approaching a stall, the SOP is to
increase engine power. In the 737 MAX (unlike all other 737s)
that causes a pitch up due to the changed engine position.
That pitch up increases angle of attack, thus driving further
into the stall.

afaiu and heard from pilots who fly the things all aircrafts with
under wing engines including the 737 NG will pitch up with power
the pitch up is just stronger with the 737 MAX

I wouldn't argue with that.
 
On Monday, May 6, 2019 at 1:05:00 PM UTC-4, bitrex wrote:
On 5/6/19 12:30 PM, Jan Panteltje wrote:
On a sunny day (Mon, 6 May 2019 11:40:04 -0400) it happened bitrex
user@example.net> wrote in <pzYzE.3$h75.1@fx41.iad>:

On 5/6/19 9:42 AM, Jan Panteltje wrote:

On a sunny day (Mon, 6 May 2019 06:27:34 -0700 (PDT)) it happened
trader4@optonline.net wrote in
0f4b448b-5459-4dbd-8b22-ef2f484f8752@googlegroups.com>:

On Monday, May 6, 2019 at 3:28:36 AM UTC-4, Jan Panteltje wrote:
On a sunny day (Sun, 5 May 2019 23:13:13 -0700) it happened Banders
snap@mailchute.com> wrote in <qaoj9p$1jpn$1@gioia.aioe.org>:

On 05/05/2019 08:25 PM, omnilobe@gmail.com wrote:
Weight and Balance of the 737 Max.

My opinion is that such software should be written by pilots,
not by spaced out no flying experience people.

That's ridiculous and what evidence do you have that the software developers
were spaced out?

That it did what it did!!!

When you design a safety system that relies on a single sensor to
determine whether the aircraft system is in a safety-critical state that
needs action "the AOA sensor indicates the aircraft is in stall", how do
you distinguish between a "normal" safety-critical situation "the AOA
sensor indicates the aircraft is in stall" where the plane a a whole is
in an error state but the safety system itself is still functioning
normally, vs. "the AOA indicates the aircraft is in stall...because the
AOA sensor is trashed" where the plane is still functioning normally but
the safety system is in an error state.

I don't know that I have an answer to that question either other than
"don't do that."

Indeed, software developer for embedded is also a hardware developer,
and should have refused or have sounded alarm when asked to code the system.
Indeed redundancy is required, but a lot more than that
It is possible that the sensor had nothing wrong with it,
as in the first crash that sensor was just replaced?
Or did they just replace the module with software?
Clearly not all data is released!
Had a pilot been in the software team (assuming it was a team and not some intern (on speed?)
(what I think and have stated before), something totally different would have
been created.
Now they are doing just those things, having pilot input, made a new system,
and are testing that,
And again a simple MEMS sensor can see if the attitude of the plane makes any sense
and software can then inhibit putting the nose ever more down, a 1$ sensor.
Also I have read the new system will now only correct the angle _once_.



I think a "safety" system that is designed to bring the system it's
managing the safety of, out of an error state, via some other action
which in a different circumstance is also an error state and a safety
risk too, has to be able to determine, with high accuracy, whether it's
the overall system or itself that is in an error state.

If I'm understanding what I've read correctly (and I accept that I do
not, I'm not an aviation engineer but it doesn't seem to stop anyone
else from offering their commentary so...) the system relied on one AOA
sensor to determine the overall state of the aircraft with respect to
what action it needed to take.

but I think there's a fundamental information theory problem there in
that with one sensor it doesn't have enough information to determine
conclusively whether it's the overall system or itself that is the one
in error. As long as everything works fine it works fine, but when it
doesn't the system can no longer "reason" conclusively about anything
anymore it's like the thought experiment of sitting in the train next to
another train and figuring out which of you is the one moving.

And it sounds like the patch is to provide more indirect information
from e.g. the airspeed and altimeter but as they don't actually measure
the true parameter of interest it would seem to fall under the category
of "heuristics" or "hacks."

If you know the plane if flying at 300 MPH and is in a level or close
to level attitude, has been that way for X seconds, you can definitively
rule out a stall. And more fundamentally, to address your concerns,
MCAS will now use BOTH AOA sensors and if they disagree, take no action.
 
On Monday, May 6, 2019 at 12:16:51 PM UTC-4, bitrex wrote:
On 5/6/19 12:09 PM, bitrex wrote:
On 5/6/19 10:36 AM, Joe Chisolm wrote:
On Mon, 06 May 2019 08:12:13 +0000, DecadentLinuxUserNumeroUno wrote:

omnilobe@gmail.com wrote in
news:c53fb380-eaac-4408-9422-959a9d1f8d3f@googlegroups.com:

Boeing is updating its software so the giant engines can unbalance the
airplane the same way as in the two crashes. Do you want to fly a plane
that only software is used to prevent stalling? Without software it
stalls.

   The software was for IF the plane stalled, which it did not.  It was
a sensor error.

   It is because the pilot does not always have a sense of a stall
situation, which the craft never get into anyway unless the pilot and
copilot are sleeping.

   A stalling plane is pilot error, not airplane error.

   The biggest issue to me is that there was no release switch to return
pilot control.

There is a procedure and it's a MEMORY item of what to do in a
run-away trim situation.  There are 2 switches, just below the
throttle quadrant that cuts out the electric trim (and MCAS).
Once turned off the AFM says you do not turn it back on.  It
stays off until you land.
Auto Pilot off
Auto Throttles off
Auto trim off.

A friend of mine with over 10K hours in the 737 variants explains
these are memory items drilled into your head and you practice
them every 6 months in the simulator check ride.

In the Ethiopian crash it seems they never disabled the auto throttles
and towards the end they re-engaged auto trim (and MCAS).  The aircraft
was already red-line in speed.


Boeing knows from a PR perspective that many Americans will be glad to
accept that it was the dumb filthy subhuman shithole country pilots who
caused the crash to happen and they very much hoped to roll with that
explanation if it was just one, except there were two crashes in
entirely different shithole countries with entirely different crews, to
explain.

That is to say it also starts to look kinda bad if it begins to seem
like what they're saying in every case of an overseas crash is
"(shithole country) operator error" when most of your sales of a
particular product are to said shithole countries because most domestic
carriers said "no thanks" to the product.

Show us where Boeing ever said anything you claim above. And US carriers
fly more 737Max than any other country. Southwest has 31, American 22,
United 14 and combined they have another 450 on order. There are probably
more there too, registered to leasing companies.
 

Welcome to EDABoard.com

Sponsor

Back
Top