[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