Lion Air 737 Missing

[ExSp33db1rd]

What is the Boeing 737 Max Maneuvering Characteristics Augmentation System?
Boeing quietly added a new system "to compensate for some unique aircraft handling characteristics."


https://theaircurrent.com/aviation-safe ... cas-jt610/

Long read, enjoy.

[boing]

It seems that this system is single channel only ie. there is no cross comparison of multiple channels to detect whether the system is functioning correctly. Allowing a system to control the aircraft flight path without confirming the signals are valid is insane. Even the VC10 stick pusher system, which this resembles, had two channels that were tested independently before flight. You tested the left system, should be no operation. You tested the right system, should be no operation. You tested both systems together, a valid signal, and the stick pusher tried to push the control wheel through the instrument panel.


.

[Boac]

'Automation'/Software control in aviation is reaching the point where in my opinion we need to call a halt in progression while things are reviewed. All the ideas are great - but. How do you 'control' a self-controlling system?

We appear to have a 'stall prevention' system here relying on the input from one of two sensors (they apparently 'swap' authority sector to sector). There does not seem to be any way to prevent a single rogue input from triggering a control input that makes life difficult for pilots. So, we have 3 sensors, and eliminate the 'rogue'? Problem solved? No, the law of unintended consequences meant that on the Airbus, in an unconsidered situation where two of the three (AoA) sensors were jammed by ice in a 'rogue' position, HAL 'intelligently' voted the one remaining that was reading correctly OUT, the tailplane trimmed accordingly and the aircraft crashed into the Med (off Perpignan).

All this 'automation' is coming about because skills are being lost. It is cheaper to buy a system which, for example, tells the crew EXACTLY where they are on a moving map than to do it 'the old way' of using navaids and a map. Don't get me wrong - I loved it - but retained the 'old skills'. It also enables far more accuracy for ATC and flying approaches. The problem is when something 'fails' in it, the pilots do not have the skill to work out where they are and where they are going - I have seen it with my F/Os in my time. It is also cheaper to build systems which warn the pilot he/she is getting near a stall than to train crews not to and to recognise the 'symptoms'. In Airbus, the designers decided that an A350 could not 'logically' be airborne with an indicated airspeed of less than 60kts - but AF447 was, and immense confusion was generated in the cockpit accordingly as the 'warning' came and went with indicated speed fluctuations. The system has now been changed to indicate at all speeds if airborne. (The next FUBAR will be a failure in the sensors that says I am airborne..? - had that happen in an 'old' 737-400 landing in Athens when it 'thought' we were airborne still (a cable had jammed) and we had stall warnings on the runway, pressurisation going beserk, electrical 'wildies' and many other things, BUT nothing 'took real control' (thank the Lord).

I guess we will carry on 'improving' systems as we are, since statistically the odd loss of a few hundred lives through 'automation' is outweighed by the cost savings and overall day-to-day improvement in safety. We will just have to get used to the 'wild' accidents and the 'tut-tutting' of the old geezers - and there is always, as with all transport systems, a calculation behind the scenes of 'acceptable losses'.

[llondel]

It's a reliability thing - having a voting system with multiple sensors helps, but the more sensors you've got, the more chance that at least one is broken. Anything that controls the aircraft should have two or more inputs and there should always be a cockpit warning when the automation decides to disagree with itself so the pilots can at least have a look at what's happening and take over if they decide they don't trust it.

[Undried Plum]

there should always be a cockpit warning when the automation decides to disagree with itself so the pilots can at least have a look at what's happening and take over if they decide they don't trust it.

Doubly important if HAL decides to disagree with the pilots, I'd say.

[Boac]

Unlike a certain Ray-Ban wearing union chief, this guy says it straight:

Captain John Weaks, president of the Southwest Airlines Pilots Union pulled no punches: “We’re pissed that Boeing didn’t tell the companies and pilots. What we need now is to make sure there is nothing else Boeing has not told the companies or the pilots.”

[Slasher]

You can have situations where 2 out of 3 (e.g. ASIs) can be wrong and the isolated black sheep one that's been auto-kicked out of the paddock is working correctly. This is why real pilots who know WTF they're doing are needed in the cockpit in order to dump the electronic glitzies and actually fly the bloody thing while sorting out HAL's latest mess.

[llondel]

There was the Swedish DC9 some years ago where they had compressor stalls on both engines on climb-out, the captain correctly eased back on the throttles and then the new gizmo that he (nor the airline) knew about, decided to advance them again, to the point where the engines disintegrated and they came down in a field. New features are all very well but not if they do things you're not expecting.

[Undried Plum]

“We’re pissed that Boeing didn’t tell the companies and pilots. What we need now is to make sure there is nothing else Boeing has not told the companies or the pilots.”


That'll take years to come out.

When you've got time, take a look at an interesting series of articles, written over a period of months, after years of research, and published by the local paper in Mr Bill's hometown despite almost irresistible commercial and other pressure from the vested interests in that town.

http://old.seattletimes.com/news/local/737/part01/

http://old.seattletimes.com/news/local/737/part02/

http://old.seattletimes.com/news/local/737/part03/

Three other URLs to follow....

[Undried Plum]

http://old.seattletimes.com/news/local/737/part04/

http://old.seattletimes.com/news/local/737/part05/

http://old.seattletimes.com/news/local/737/response/

[Slasher]

I was on the 737-400 when that rudder hardover sh!t hit the fan. A lot of us nervously held on to the 190kt aileron/rudder crossover min speed esp on approach till the problem was eventually solved.

[llondel]

That's fascinating to see the entire story. It was featured on the Air Crash Investigation series but that left a lot of the detail out, only covering two crashes and the one that 'solved' the mystery.

[ian16th]

We told you all about it, in the manual, say Boeing.

[Boac]

From the WSJ - Investigators to ask Boeing for more information https://www.wsj.com/articles/lion-air-s ... business_f

The odd bit is puzzling in the article (about a 'climb').

[Alisoncc]

Local news report:-

The information from the flight data recorder, contained in a preliminary report prepared by Indonesian crash investigators and scheduled to be released on Wednesday, documents a fatal tug-of-war between man and machine, with the plane's nose forced dangerously downward more than two dozen times during the 11-minute flight.

The pilots managed to pull the nose back up over and over until finally losing control, leaving the plane, Lion Air Flight 610, to plummet into the ocean at 450 mph (724 km/h), killing all 189 people on board.

The data from the so-called black box is consistent with the theory that investigators have been most focused on: that a computerised system Boeing installed on its latest generation of 737 to prevent the plane's nose from getting too high and causing a stall instead forced the nose down because of incorrect information it was receiving from sensors on the fuselage.

We seem to have gone from computised systems flying the aeroplanes to computised systems overriding the pilots and crashing aeroplanes. Progress !!

[Boac]

The essentials should be a system that can clearly and simply be understood by crew and over-ridden when necessary in order to exercise the flying skills (which are disappearing, of course )

I recall many years ago, early AB 320, when an Air India (I think) descended gracefully into the ground short of the runway killing most on board, and it was rumoured that the control software on it went through something like 23 different sets of control algorithms from top of descent to landing. Now try to understand that and know when is doing what! I suspect things have improved?

We still await to discover the reason why the LionAir crew did not/?could not? isolate the trim input.

[Capetonian]

I briefly read two reports this morning, one said that Lionair needs to improve its safety culture,. That's an understatement if ever there was one.

The other said the aircraft was 'not airworthy' .

[Mrs Ex-Ascot]

From the Beeb; https://www.bbc.com/news/world-asia-46121127

I must confess that I have wondered why this aircraft was allowed to continue to fly when serious problems had already been reported.

[ExSp33db1rd]

Warning, long read, pour a beer.

Interesting article ( and I'm glad .... Text edited for greater clarity ...... final comment ! )

By Captain Shem Malmquist

AN FSI COMMENTARYThe following is based only on an analysis and implications of the FAA airworthiness directive (AD) issued in the wake of the accident and is not intended to be speculative on the accident itself. Other factors unknown to me may be involved.

In the wake of the October 29 Indonesian crash of a brand new Boeing 737 MAX 8 that took the lives of 189 passengers, the FAA has issued Emergency Airworthiness Directive (AD) 2018-23-51. The 737 is the most widely flown aircraft in the world, This tragedy opens an important conversation between regulators, operators and pilots. Lion Air, an experienced 737 operator, was the launch carrier last year for the 737 MAX 8 and the MAX 9 in March.

While it will take a long time to analyze the Lion Air 610 accident, the AD points out that current system architecture has created vulnerabilities. Anyone who flies modern jet aircraft, as I do, also knows that in some ways this conversation applies to every plane and every pilot. Attempts to assign blame to anyone at any point in this investigation sidesteps a much more important issue, one that is the essential to the future of ever more automated cockpits.

The FAA says its AD was “prompted by analysis performed by the manufacturer showing that if an erroneously high single angle of attack (AOA) sensor input is received by the flight control system, there is a potential for repeated nose-down trim commands of the horizontal stabilizer[1]. This condition, if not addressed, could cause a flight crew to have difficulty controlling the airplane, and lead to excessive nose-down attitude, significant altitude loss, and possible impact with terrain[2].”

As described in the Seattle Times, “The system called MCAS, for Maneuvering Characteristics Augmentation System, is activated when a sensor on the side of the fuselage indicates a dangerously high angle of attack (AOA), the angle between the air flow and the wing. “If the plane is in an abnormally steep turn that puts high stress on the air frame, or when its speeds fall so low it’s about to stall, MCAS will kick in and swivel the horizontal tail to push the nose of the airplane down in an effort to avert the danger”.[3]

While the Seattle Times article incorrectly implies that the system is based on speed or “high stress on the air frame, ” the system description appears to be essentially correct. Low airspeed or a higher load factor (which can occur in a steep turn or pull up from a dive) are among the possible reasons the angle of attack can approach a stall. Unlike other critical components such as air speed indicators or altimeters which have comparator systems that cross check each other for spurious indications and alert the pilot that there is a mismatch, pilots have no way to quickly determine if they are being misled by a faulty AOA sensor[4].

As with erroneous airspeed or altitude readings, the loss of the sensor itself leads to loss of secondary systems and/or can trigger other warning systems. Even on the most advanced state of the art aircraft there is no direct feedback to the pilots when the AOA sensor itself has failed. Pilots must quickly infer a faulty AOA sensor from other faults or indications.

Underlying this problem is the fact that a computer software system does not “fail” like a mechanical system. It can be incorrectly coded, or it can be incorrectly designed, but the system does not “fail” like a turbine blade that rips apart in flight. Generally, what we see is that the software was coded correctly based on the requirements provided to the people coding the software but the problem lies in the requirements and specifications provided to them.

If a certain scenario was not considered in the requirements it is unlikely to find its way into the final computer coding. The AD describes an emergency scenario where a sensor reads an erroneously high AOA and the software reacts as its designers intended. The software responds to the erroneous indication in a manner similar to the way a human might react. However, all the pilot sees is the final result. How the computer came to take an action is opaque.

This makes it very difficult to crosscheck the computer’s process model (decision making process). As Boeing and the FAA AD explain, the bad AOA sensor leads to several problems. The erroneously high indication of AOA first leads to an autopilot disconnect. The system then works to prevent a stall by adding nose-down trim.

So how does this affect the process model (mental model) for the pilots? It is standard in the Boeing aircraft that the stabilizer trim can be stopped by moving the control column in the opposite direction. Aircraft designers assume that no pilot would intentionally trim the aircraft nose up while also pushing forward on the controls to pitch the aircraft down or vice versa. However, in the case of the B-737 MAX 8 and 9 there are reports that reversing the control column (pulling back) won’t work to stop the stabilizer trim from trimming nose-down in the scenario described in the AD.

Others have discussed the rationale behind this design decision[5], but suffice to say that this would be different than what a pilot would be expecting based on previous experience on other Boeing 737 models. The erroneous AOA could trigger both an erroneous stall warning and a pitch down (due to the MCAS trimming the horizontal stabilizer).

This gets a lot more complicated when you consider how the FAA defines a stall condition for a transport category airplane (adapted from Title 14 CFR 25.201):Full stall condition – any one, or combination, of the following:– A nose-down pitch that cannot be readily arrested, which may be accompanied by an uncommanded rolling motion– Buffeting of a magnitude and severity that is a strong and effective deterrent to further increase in angle of attack– The pitch control reaches the aft stop for 2 sec and no further increase in pitch attitude occurs when the control is held full aft, which can lead to an excessive descent rate– Activation of a stall identification device (e.g., stick pusher)

As can be seen, the condition described in the AD would present at least two of the criteria. First is the “nose-down pitch that cannot be readily arrested” (because the pilots were not previously aware that the system was intentionally doing that due to the erroneous sensor) and second is the “activation of a stall identification device,” in this case, a stick shaker, also due to the same erroneous sensor. The pilot could effectively be misled as to what is actually going on by the software system.

The AD also implies that it is possible that the trim cutout switches (guarded switches that disconnect electrical power from the trim system) may not work, stating:“If relaxing the column causes the trim to move, set stabilizer trim switches to CUTOUT. If runaway continues, hold the stabilizer trim wheel against rotation and trim the airplane manually.” Pilots are often our own worst enemy, with some contending that the situation should have been obvious, the aircraft attitude was nominal and airspeed normal. Such Monday morning quarterbacking suggests hindsight bias.

The pilot placed in the middle of this situation does not have the benefit of knowing the outcome. They see the aircraft pitching down and are getting a stall warning. There has been considerable emphasis on stall recovery in the wake of the Air France 447 accident. In the aftermath of that training, pilots are being trained that a stall in a transport airplane is not always apparent nor do all stalls provide the kind of cues pilots might expect based on previous experience. Simulators are not able to fully replicate a real stall in a transport airplane, hence the training emphasizes respecting the stall warning system.

Of course this creates a new quandary. Consider a crew who incorrectly believes they are in a stall situation analogous to the Air France 447 accident, with the nose attitude at a nominal state but the actual AOA is quite high. They might try to recover by pushing over. In other words, the system is tricking the pilot into believing they might be in a non-existent deep stall. Absent any flight deck indication that the information they are relying on is wrong, it would be difficult to pass judgment on a pilot that is following their training.

Perhaps we need to consider adding a flight display alert that prominently shows an AOA failure with a mismatch AOA alert. This approach would parallel similar alerts for airspeed or altitude indication failures. Accomplishing this would be fairly straight forward. Most transport airplanes have at least two, sometimes three, AOA vanes and sensor systems.

A system such as outlined by Ossmann and Joos (2017) would be one possible solution:An advanced fault detection and diagnosis (FDD) system to monitor the triplex redundant angle of attack measurement of a commercial large transport aircraft has been presented. The FDD system incorporates signal- and model-based fault detection algorithms. Fault isolation is achieved by an individual monitoring of the three angle of attack sensors[6]. An alert would be valuable in any case. This is especially true when we consider what happened with other AOA failure events, such as occurred on the Airbus that led the system protection systems to make extreme maneuvers on Qantas 72. (https://en.wikipedia.org/wiki/Qantas_Flight_72).

Such an alerting system would provide the pilots with the information they need to disconnect flight computers or other actions as appropriate. This should be combined with ensuring pilots understand all of the functionality of the system so they would recognize all a particular sensor failure might impact. Every flight depends on pilots to “fix” problems that designers did not anticipate, be they in aircraft design, procedures or the entire system design.

Give the pilot the information and skills to do that. Give the pilot information that the system has an erroneous input via its sensing system.

How can we prevent future problem like this? A systems approach to analysis would be a good start. Identifying the needs up front prior to writing the requirements for the software has to happen. Implementing System Theoretic Accident Models and Processes (STAMP) would likely be the best solution we have at present. The majority of current risk analysis methods (FTA, Bow-Tie, FMEA, FMECA, PRA,, HFACS, ARP 4761, MIL-STD-882 etc.) are just not up to the task for finding complex system interaction problems as has been described here.

Nor are those methods well suited to identify problems in systems that rely on humans and software. STAMP (see http://psas.scripts.mit.edu/home/) can provide a way forward.

Knowledge can keep you alive. Captain Shem Malmquist is a veteran 777 captain and accident investigator. He is coauthor of Angle of Attack: Air France 447 and The Future of Aviation Safety and teaches an online high altitude flying course with Beyond Risk Management and Flight Safety Information.

Text edited for greater clarity - Rob

[Boac]

A very good comment. I have always bleated since the early days of the AB about the software inputs. To see

A systems approach to analysis would be a good start. Identifying the needs up front prior to writing the requirements for the software has to happen.

saddens and gladdens my heart simultaneously. That it needs to be said is sad, that it has been is good.

The only part I take issue with is

Consider a crew who incorrectly believes they are in a stall situation analogous to the Air France 447 accident, with the nose attitude at a nominal state but the actual AOA is quite high.

which I think paints an incorrect picture of 447 (my emphasis). They WERE most definitely in a deep stall situation, and "the nose attitude at a nominal state but the actual AOA is quite high" is definitely a stalled situation.

One thing is still nagging me - according to Av Herald, eye witness (fishermen) reports describe the crash thus
"... the aircraft was flying unusually low. The aircraft appeared to roll in for a turn when it shook and swooped sharply and impacted the waters of the sea...." yet we are presented with information suggesting a fast and steepening dive into the sea. Maybe they were within an inch of recovery from the high-speed dive when they were 'seen' but just pulled too hard causing a violent stall or overstressed the tail?