[OT] “Raise the nose, HAL.” “I’m sorry, Dave, I’m afraid I can’t do that.”
Paolo Invernizzi
paolo.invernizzi at gmail.com
Tue Apr 23 08:06:14 UTC 2019
On Monday, 22 April 2019 at 20:35:31 UTC, Walter Bright wrote:
> On 4/21/2019 10:54 PM, Uknown wrote:
>> I'm sure you wouln't fly in one until the fix has been
>> published and the pilots have been trained.
>
> Actually, I would even in an unmodified 737MAX. The reason is
> that the way to deal with it, even if pilots don't know about
> it, is to follow their training for runaway stab trim. This is
> what the pilots did in the first Lion Air incident, and they
> landed without incident. In the second LA incident, and in the
> Ethiopian one, they did not and crashed.
>
> It's simple:
>
> 1. The electric trim switches on the control column override
> the MCAS commands.
>
> 2. When trimmed, shut off the stab trim with the cutoff
> switches on the console.
>
> Both pilots in the crashes were performing (1). The mystery to
> me is why they did not continue to do it, then perform (2).
> We'll have to wait for the NTSB report which hopefully can
> explain that.
>
> I would expect with all this publicity even an incompetent
> pilot would be able to accomplish this.
>
> BTW, I only saw one article publish (1) and (2). (The wording
> is from memory, I don't recall the exact words in the Boeing
> instructions.) All the other articles leave it out and prefer
> to publish hysterical clickbait articles.
Here we are the details, right from Boeing...
http://www.b737.org.uk/mcas.htm
>
> Boeing still needs to fix the MCAS system, because how
> airplanes are made robust is to fix every point in the string
> of failures that led to a crash.
>
> BTW, I was a nervous flyer before I worked at Boeing on flight
> control systems. Knowing how things actually worked and how
> things were built changed it all for me. An awful lot about
> what is written in newspapers about technical airplane issues
> is complete trash. Journalists don't know **** about airplanes,
> and they garble it all up. If you want the straight dope, read
> the NTSB incident reports.
That's what usually I do, but the point is another... see below...
> The pilot's article linked to sounds authoritative, until one
> notices he's not an airline pilot, and (for instance) does not
> realize that all swept wing airplanes are fundamentally
> unstable, and that Rosie the Riveter knows nothing about
> stability issues.
>
> You don't need to believe anything I say - so I recommend
> withholding judgement until the NTSB report(s) come out. You'll
> learn a lot reading them. The NTSB does a good job thoroughly
> stating the facts and leaving off the hysteria.
And that's fine. What I want to discuss, is the last part in the
link that I've included in this port, I quote it for convenience:
"""
The Proposed Fix
Boeing have been working on a software modification to MCAS since
the Lion Air accident. Unfortunately although originally due for
release in January it was not released due to both engineering
challenges and differences of opinion among some federal and
company safety experts over how extensive the changes should be.
"""
Please note the "engineering challenges" and "differences of
opinion". Moreover:
"""
Note that as MCAS is an FCC function, the modifications to MCAS
are made in the FCC software. The revision will be known as FCC
P12.1
There are three significant changes to MCAS software being worked
on by Boeing:
1) To give the system input from both angle-of-attack sensors,
Currently MCAS only uses data from the angle of attack sensor on
the side of the active FCC, (see AoA source). The system will
have split vane monitor and Mid Value Select (MVS) input. This
will both enhance detection of erroneous AoA vane behaviour and
the MVS signal selection will pick the average of ADIRU L & R and
the previous MVS output. If the output of the two AoA vanes
differ by more than 5.5 degrees MCAS will be disabled.
"""
So, only one sensor was used: no redundancy, no cross check, no
taking in account other inputs to find out anomalies. Taking
differences in account, it resembles me something like not having
"asserts", or better, throwing 'error' in the codebase ("hey, we
CAN'T reconcile that AoA with the current increasing of speed and
decreasing of altitude! Assert, abort! throw 'error', abort!)
Moreover:
"""
2) To limit how much MCAS can move the horizontal stab to
guarantee sufficient handling capability using elevator alone. In
its original report, Boeing said that MCAS could move the
horizontal stabilizer a maximum of 0.6 degrees. However, after
the Lion Air crash, it told airlines that MCAS could actually
move it 2.5 degrees, or half the physical maximum. Boeing
reportedly increased the limit because flight tests showed that a
more powerful movement was needed at high AoA rather than at high
Mach.
"""
Half of the physical maximum! Moreover:
"""
3) A modification to the activation and resynchronisation
schedule. MCAS will be limited to operate only for one cycle per
high AoA event, rather than multiple. At present it will operate
for 10s, pause for 5s and repeat for as often as it senses the
high AoA condition is present. Furthermore the logic for MCAS to
command a nose up stab trim to return to trim following pilot
eletric trim intervention or exceeding the forward column cutout
switch, will also now be improved.
"""
What to say?
In my humble opinion, that's the result of "pressure" to have a
"solution" for some "not disclosed goal" (hint, the MCAS should
be "transparent to pilot", as "that's simply a 737!")
Pressure over engineerings coming from management, I'm meaning
(again, personal opinions).
So, here we are back to us: what's the current state of affair in
having sloppy designed systems (or sloppy implemented system!)
caused by time pressure, management pressure, cost pressure?
I mean, D pushing hard, to be a memory safe language, for
example, but it seems that safety and good design are falling
down in the list of priorities... no?
More information about the Digitalmars-d
mailing list