Boeing 737 Max Software Fixes Due to Lion Air Crash Delayed

[A0283]

I stumbled upon an interesting case study on the use of memory items and (subsequent) checklists using 15 volunteer current 737 line pilots that were present at a crew base of a major US airline. Half captains, half FO’s. Half of all pilots had (varied) military experience. Pilots reported being trained in both 737 Classic and 737 NG. The 737 Classic flight deck was used.

I summarize ...

Each scenario began by describing a normal flight situation, and then interjecting cues that suggest a particular failure. Subjects were asked to react to the cues as they would inflight, performing any procedures they felt were necessary. The participants were provided with their airline QRH, and were allowed to select the checklist they felt was most appropriate for the situation.

Five non-alerted abnormal procedures that contain memory items were used.
1. aborted engine start ----- correct checklist by 10 of 15, ..
2. engine limit/surge/stall - correct checklist by 2 of 15, ..
3. rapid depressurization -- correct checklist by 14 of 15, two pilots added memory item steps,
4. runaway stabilizer trim - correct checklist by 14 of 15, four pilots added memory item steps,
5. dual engine failure ------ correct checklist by [12] of 15, this scenario had most errors in memory item steps of all 5 scenarios, multiple item steps were added by pilots.

The pilots in this study demonstrated a tendency to fixate on the most prominent cue, and perform the checklist appropriate to that cue. However, a thorough analysis of the situation can reveal that the single most prominent cue does not always lead the pilot to the correct checklist. There were 23 checklist selection errors. With three exceptions, the errors appear to be caused by the pilots’ fixation on a single cue.

There appear to be consistent patterns in the observed checklist step errors. Many of the ‘adding item steps’ errors appear to result from the pilots’ creativity (read: (experience based) troubleshooting) in dealing with an abnormal situation. It was observed that many pilots perform steps in addition to what was required based on their understanding of how the airplane systems functioned, even though their understanding of the systems may be incorrect.

You might think on reading the study that: A single study aimed at being as realistic and objective as possible does not present a ‘truth’. But, that not everybody is perfect, might be a reasonable conclusion.

[GordonR_Cape]

A0283

You might think on reading the study that: A single study aimed at being as realistic and objective as possible does not present a ‘truth’. But, that not everybody is perfect, might be a reasonable conclusion.

Very interesting! Some actual results for the skeptics to hang their hats on.

Do you think Ralph Nader's family would ever issue subpoenas to the author of this study, or is my imagination running wild?

[Arydberg]

new Question

When the 747 was designed Boeing went to great lengths to cover all bases. They included a set of standard instruments Artificial Horizon, Gyro compass airspeed etc. Are these instruments still included on the plane.

[Arydberg]

2nd question

From the pleminary report on the Lion crash found here :




https://www.flightradar24.com/blog/w...ary-Report.pdf







Perhaps others can draw conclusions from it. Note there should be a vertical line between Defect Description and Resolution Description

1.6.3

Aircraft Flight and Maintenance Log

The Aircraft Flight Maintenance Log (AFML) recorded that since 26 October 2018 until the occurrence date several problems occurred related to airspeed and altitude flag appeared on Captain (left) Primary Flight Display (PFD) three times, SPEED TRIM FAIL light illumination and MACH TRIM FAIL light illumination two times and IAS (Indicated Airspeed) and ALT (Altitude) Disagree shown on the flight Denpasar to Jakarta the day before the accident flight.

The summary of the aircraft defect recorded on AFML were as follows: No


Reported Date


Route


Defect Description


Resolution Description
1
26 October 2018
Tianjin Binhai to Manado
Speed and Altitude Flag show on Captain Primary Flight Display (no speed and altitude indication)
Performed check Onboard Maintenance Function (OMF), found maintenance message 27- 31000. Refer to Interactive Fault Isolation Manual (IFIM) 27- 31000, performed Stall Management and Yaw Damper (SMYD) number 1 system test carried out, result normal.
Maintenance light illuminate after landing
Performed check OMF, found message 27-31-000.

Performed erase maintenance message check out maintenance light goes off.
2
27 October 2018
Denpasar to Manado
Speed and Altitude Flag show on Captain Primary Flight Display (no speed and altitude indication)
Ref. IFIM task 27-32-00-810-816 REV October 2018.

Performed check OMF, found status message “Stall Warning System L”. Initial evaluation performed system test SMYD number 1, self-test result failed.
7 No


Reported Date


Route


Defect Description


Resolution Description






SPEED TRIM FAIL light illuminate and MACH TRIM FAIL light illuminate
Check correlated message found message Air Data (AD) invalid 27-31012, 34-61263, 3421107, 34-61263, 34-21123. BITE ADIRS L via CDU found message ADR Data invalid (34- 21007) and AOA SIGNAL FAIL (34-21023). Reset CBs ADIRU L DC and AC, and ADIRU L carried out, and performed system test SMYD number 1 result pass.

Reconnect and clean electrical plug of data module, check message on OMF status not active.
3
27 October 2018
Manado to Denpasar
Speed and Altitude Flag show on Captain Primary Flight Display (no speed and altitude indication)
Refer to IFIM task 27-32-00-810- 816 rev October 2018.

Perform check OMF status found message “STALL WARNING SYS L”. initial evaluation performed SMYD number 1 self- test result failed message 27-31- 12 (AD data invalid) and 27- 31015 (ADIRU data invalid).

Check OMF existing fault (34) found message 34-21107 (AIR DATA SIGNAL INVALID) and 34-21123 (AOA SIGNAL OUT OF RANGE).

BITE ADIRS L via CDU found message 34-21023 (AOA SIGNAL FAIL).

Reset CB ADIRU L AC and DC and ADIRU L carried out. System test pass. DFCS BITE result PASS. Erase status message carried out and check message not active.
SPEED TRIM FAIL light illuminate and MACH TRIM FAIL light illuminate
Auto-throttle Arm disconnect, during aircraft takeoff roll


For troubleshooting due to repetitive problem perform replaced angle of attack sensor in accordance with Aircraft Maintenance Manual (AMM) Task 34-21-05-000-001 and task 34-21-05-400-801 carried out.

Installation test and heater system test result good.
8 No


Reported Date


Route


Defect Description


Resolution Description
4
28 October 2018
Denpasar to Jakarta
IAS and ALT Disagree shown after take off
(Refer to IFIM task 34-20-00- 810-801 REV 15 June 2018).

Performed flushing Left Pitot Air Data Module (ADM) and static ADM. Operation test on ground found satisfied.
feel diff press light illuminate
Refer IFIM 27-31-00-810-803 Rev 15 June 2018, performed cleaned electrical connector plug of elevator feel computer carried out. test on ground found OK.

[NutLoose]

Interesting read on how the aircraft are coming under scrutiny

https://www.msn.com/en-gb/news/world...cid=spartandhp

[WHBM]

Originally Posted by NutLoose

Interesting read on how the aircraft are coming under scrutinyhttps://www.msn.com/en-gb/news/world...cid=spartandhp

You actually have to wonder how many more Boeing will sell as articles written like that progressively get into the mainstream media. There are an increasing number of researched articles like this that slam the whole design concept. Yes, I know that we here can make technical rebuttals to the various points, just like in the US there were plenty of justifications for turboprops on shorter regional runs - but the public just did not accept them. And as for many the Max is a 737, the turn-off is possibly going to impact the NG as well.

[crewmeal]

Interesting to note that Boeing is not the only company to have software problems. It seems rogue software was responsible for the problems with Qantas 72 back in 2008.

Qantas 72

[Vilters]

I don't understand why they keep using these "obsolete" AOA vane sensors with so many alternatives available.
As I wrote from the start; You can NOT fix a HARDWARE issue with a SOFTWARE update.

There are so many other AOA sensors systems available. => Drop those stupid 1950-1960 era vanes.

[PEI_3721]

After modification - additional layers of protection - crews should not be exposed to the hazards of extreme MCAS pitch trim. *
With up to 5.5 deg disagreement between AoA vanes, MCAS will only make ‘one input’; more than 5.5 deg (+10 sec ?) MCAS is disabled.

When would MCAS reset? With a reduction of AoA disagreement from less than 5.5 to near zero split (what is the minimum split), will this re-enable the ‘one input’ option.

When would MCAS be rest from an inhibit condition? With reduction in AoA to less than 5.5 deg, or only near zero. Do any of the reset states require an ‘on ground’ condition; and what happens if the AoA error is not detectable when ‘on ground’, as with Lion aircraft.
What would the maintenance corrective action be for an AoA Disagree - pilot report / electronic maint log?

At what value of split is the AoA Disagree alert shown? Some texts indicate 5.5 deg, what happens below 5.5 deg, how will other systems using AoA be affected ?

With ‘AoA Disagree’ how can the crew determine if MCAS is in a ‘one input’ mode or fully disabled.
What indications alert the crew to the need for careful pitch handing with MCAS disabled? Crews either do not know, or do not have indication of the MCAS AoA trigger point (AoA indicators show units not degrees).

AoA indicators are of little value; with error, which one is correct - either hi/lo or lo/hi. AoA Disagree would be shown for either of these two conditions and then for the MCAS to be either ‘one input’, or be disabled.

The additional mandated alerts and display do not provide crews with information to determine the situation or a course of action. If the AoA indicators remain in view this is misleading or even hazardous information - remove them with error.
It might be possible to determine MCAS state by inference from alerts, or even by looking at the trim, but this would increase crew workload and add distraction. And when trim is operating, is this normal or a runaway condition which still applies.

Over focus on MCAS detracts from the many other systems which could be affected by AoA Disagree - stick shake, low speed awareness, airspeed differences, IAS / ALT Disagree, Feel Diff Press, no autopilot. It could be argued that these also require protection to improve resilience to the limitations of AoA input.

* https://www.boeing.com/commercial/73...e-updates.page

[fizz57]

Originally Posted by PEI_3721

Over focus on MCAS detracts from the many other systems which could be affected by AoA Disagree - stick shake, low speed awareness, airspeed differences, IAS / ALT Disagree, Feel Diff Press, no autopilot. It could be argued that these also require protection to improve resilience to the limitations of AoA input.

Beg to differ. On the 737, before the advent of MCAS, the AOA signal was a low risk one. All the other systems you mention, with the exception of the stick-shaker, are cross-monitored and have appropriate failure indicators and checklists. Pilots are trained to handle instrument failures and carry on flying. If IAS disagree, for example, does it matter if the problem is in the pitot or the AOA sensor?

Of course, once this signal is allowed to drive flight surfaces it is no longer low-risk. But as it was OK before, it is easy to understand (though not condone) how it could have slipped through.

[PEI_3721]

fizz57, whilst your points are valid as history, we cannot accept that the outcome of previous events correctly indicate or confirm the underlying risk. With the two Lion events, completely different outcomes, but before flight, before raising flap, exactly the same risk.

Thus we should consider what could be learnt from recent accidents. Avoiding focus on MCAS, but to consider the overall event; multiple alerts immediately after takeoff, a situation which 3 crews experienced and, based on outcome, one managed ‘safely’, but in the other two did the preceding situation contribute to the accident.

Before the MCAS problems, could the workload be reduced, improve checklists, appropriate training scenarios, surprise management, crew co-ordination, choice of options, and technical understanding.

There has been significant criticism in this forum in some of these areas; given that not all of this is from a professional viewpoint, there may still be safety issues worthy of discussion.

[tdracer]

Thus we should consider what could be learnt from recent accidents. Avoiding focus on MCAS, but to consider the overall event; multiple alerts immediately after takeoff, a situation which 3 crews experienced and, based on outcome, one managed ‘safely’, but in the other two did the preceding situation contribute to the accident.

I'd take that one step further - the tendency is to evaluate failure conditions in isolation - i.e. MCAS malfunctions and puts in stab trim when it shouldn't - not as failure condition that results in multiple independent system faults.
I had dinner recently with several retired and active (but near retirement) Alaska 737 pilots. Naturally the recent MAX crashes came up. To a man they all agreed a simple MCAS malfunction resulting in unexpected stab trim inputs would immediately prompt them to turn the auto stab trim 'OFF'. Hence the understandable assessment that an MCAS failure wasn't flight critical.
However, MCAS failed because AOA was bad, which drove multiple related faults such as stick shaker, bad airspeed, and unexpected stab trim to due to MCAS - suddenly a complex and confusing combination of faults that could overwhelm a crew (and the lack of information and training just made it worse). Suddenly a no-big-deal MCAS problem is potentially catastrophic.
I did wrote several Failure Mode and Effects Analysis (FMEA) and System Safety Assessment (SSA) documents during my career. The key was to access 'and single failure or likely combinations of failures'. It's getting that second part right that seems to be lacking.

[RickNRoll]

Originally Posted by tdracer

I'd take that one step further - the tendency is to evaluate failure conditions in isolation - i.e. MCAS malfunctions and puts in stab trim when it shouldn't - not as failure condition that results in multiple independent system faults.
I had dinner recently with several retired and active (but near retirement) Alaska 737 pilots. Naturally the recent MAX crashes came up. To a man they all agreed a simple MCAS malfunction resulting in unexpected stab trim inputs would immediately prompt them to turn the auto stab trim 'OFF'. Hence the understandable assessment that an MCAS failure wasn't flight critical.
However, MCAS failed because AOA was bad, which drove multiple related faults such as stick shaker, bad airspeed, and unexpected stab trim to due to MCAS - suddenly a complex and confusing combination of faults that could overwhelm a crew (and the lack of information and training just made it worse). Suddenly a no-big-deal MCAS problem is potentially catastrophic.
I did wrote several Failure Mode and Effects Analysis (FMEA) and System Safety Assessment (SSA) documents during my career. The key was to access 'and single failure or likely combinations of failures'. It's getting that second part right that seems to be lacking.

Interesting, when they said "Auto Stab Trim" to "Off" were they thinking "Stab Trim - Auto Pilot" off? Because the "Auto Pilot" option would have been very useful if it still existed in the MAX.

[Turnleft080]

I got a good idea Boeing. Why not bring out the B727 body attach 2 leaps on the back fuselage take out the centre engine keep the wing. At least it will do Mach 0.90 mmo.
Faster and more economical than an Airbus.

[Australopithecus]

Yeah, a 1960's answer to a 1960 obsolete design. Boeing obviously needs a clean sheet design for the 180-200 seat market. As it is, all the airlines that wanted to avoid conversion training now are going to have to spend billions* when the Max gets replaced.

* of course that’ll be he next guy's problem.

[Dave Therhino]

Originally Posted by tdracer

I'd take that one step further - the tendency is to evaluate failure conditions in isolation - i.e. MCAS malfunctions and puts in stab trim when it shouldn't - not as failure condition that results in multiple independent system faults.
I had dinner recently with several retired and active (but near retirement) Alaska 737 pilots. Naturally the recent MAX crashes came up. To a man they all agreed a simple MCAS malfunction resulting in unexpected stab trim inputs would immediately prompt them to turn the auto stab trim 'OFF'. Hence the understandable assessment that an MCAS failure wasn't flight critical.
However, MCAS failed because AOA was bad, which drove multiple related faults such as stick shaker, bad airspeed, and unexpected stab trim to due to MCAS - suddenly a complex and confusing combination of faults that could overwhelm a crew (and the lack of information and training just made it worse). Suddenly a no-big-deal MCAS problem is potentially catastrophic.
I did wrote several Failure Mode and Effects Analysis (FMEA) and System Safety Assessment (SSA) documents during my career. The key was to access 'and single failure or likely combinations of failures'. It's getting that second part right that seems to be lacking.

That's what is scary to me about Boeing's miss - a simple properly done FMEA for an AOA sensor erroneous high angle output should have identified the whole scenario that could unfold. What else did they fail to properly analyze and identify?

[tucumseh]

Failure Mode and Effects Analysis (FMEA)

Well said. Some include 'Criticality'.

I don't wish to divert the thread, but this isn't the first time a Boeing aircraft has been certified with poorly implemented safety critical software, followed swiftly by multiple fatalities.

[Bidule]

Originally Posted by tdracer

However, MCAS failed because AOA was bad, which drove multiple related faults such as stick shaker, bad airspeed, and unexpected stab trim to due to MCAS - suddenly a complex and confusing combination of faults that could overwhelm a crew (and the lack of information and training just made it worse). Suddenly a no-big-deal MCAS problem is potentially catastrophic.

Did MCAS fail? I would rather think it worked as designed but on the basis of wrong data/information originated by the AOA.

[Torquelink]

Aviation Daily, 11 April:

LOS ANGELES—As the investigation continues into the causes of the Mar. 10 Ethiopian Airlines Boeing 737 MAX accident, sources close to the probe say flight data recorder (FDR) data firmly supports the supposition that the aircraft’s left angle-of-attack (AOA) sensor vane detached seconds after take-off and that, contrary to statements from the airline, suggests the crew did not follow all the steps for the correct procedure for a runaway stabilizer.

Detailed analysis of the FDR trace data shows that approximately six seconds after liftoff was signaled by the weight-on-wheels switch data, the data indicate the divergence in angle-of-attack (AOA) and the onset of the captain’s stick-shaker, or stall warning. Almost simultaneously, data shows the AOA sensor vane pivoted to an extreme nose-high position.

This, says one source, is a clear indication that the AOA’s external vane was sheared off—most likely by a bird impact. The vane is counter-balanced by a weight located inside the AOA sensor mounting unit, and without aerodynamic forces acting on the vane, the counterweight drops down. The AOA sensor, however, interpreted the position of the alpha vane balance as being at an extreme nose-high angle-of-attack.

With the stick shaker active, the trace indicates the crew pushed forward on the column to counteract what they believed were indications of potential approach to stall. The aircraft, now in level flight, also accelerated rapidly as its power setting remained at 94% N1 thrust used for take-off. This was followed by some manual trim inputs using the thumb switches on the control column.

Seconds after speed advisories were heard, the crew raised the flaps. With the autopilot turned off, flaps up and erroneous AOA data being fed to the flight control computer (FCC), the stage was set for the MAX’s maneuvering characteristics augmentation system (MCAS) to activate. This is indicated by approximately 8-sec of nose-down stabilizer movement, which was followed by the use of manual trim on the control column. However, with the MCAS having moved the stabilizer trim by 2.5 units, the amount of manual nose-up trim applied to counteract the movement was around 0.5 units, or roughly only 20% of the amount required to correctly re-trim the aircraft.

Because of the way the aircraft’s flight control computer P11.1 software worked, the use of manual trim also reset the MCAS timer, and 5 sec. later, its logic having not sensed any correction to an appropriate AOA, the MCAS activated again. The second input was enough to put in the full nose-down trim amount. The crew again manually counteracted with nose-up trim, this time offsetting the full amount of mis-trim applied by the latest MCAS activation.

By then, some 80% of the initial MCAS-applied nose down trim was still in place, leaving the aircraft incorrectly trimmed. The crew then activated the stabilizer trim cutoff switches, a fact the flight data recorder indicates by showing that, despite the MCAS issuing a further command, there was no corresponding stabilizer motion. The aircraft was flying at about 2,000 ft. above ground level, and climbing.

The crew apparently attempted to manually trim the aircraft, using the center-console mounted control trim wheels, but could not. The cut-out switches were then turned back on, and manual trim briefly applied twice in quick succession. This reset the MCAS and resulted in the triggering of a third nose-down trim activation lasting around 6 sec.

The source says the residual forces from the mis-trim would be locked into the control system when the stabilizer cut-off switches were thrown. This would have resulted in column forces of up to around 50 lb. when the system was switched back on.

Although this could have been reduced by manually trimming the aircraft, this did not occur, and the third MCAS activation placed the aircraft in a steep nose-down attitude. This occurred with the aircraft near its peak altitude on the flight—about 6,000 ft. The engines remained at full take-off power throughout the flight, imposing high aerodynamic loads on the elevators as the crew attempted to pull back on the columns.

Vertical acceleration data also indicates momentary negative g during which the AOA sensor on the left side unwinds. This is seen as further validation of the theory that the external part of the alpha vane was detached as the apparent change in angle indication could only be explained by the effect of negative g on the counterbalance weight, forcing it to float up inside the sensor housing. In addition, the captain’s stick shaker also comes off twice in this final phase, further reinforcing the severed vane notion.

The source indicates the crew appeared to be overwhelmed and, in a high workload environment, may not have followed the recommended procedures for re-trimming. Boeing’s stabilizer runaway checklist’s second step directs pilots to “control aircraft pitch attitude manually with control column and main electric trim as needed,” according to one U.S. airline’s manual reviewed by Aviation Week. If the runaway condition persists, the cut-out switches should be toggled, the checklist says.

[oggers]

Boeing obviously needs a clean sheet design for the 180-200 seat market.

Because when you design an entirely new aircraft from the ground up you are less likely to make a mistake than when modifying a proven design?