Boeing 737 Max: Is Automation to Blame?

Article By : Junko Yoshida

Why the catastrophic plane crashes of Indonesia's Lion Air last October and another by Ethiopian Airlines last week should be setting off alarms in the automotive industry.

Should the catastrophic plane crashes of Indonesia’s Lion Air last October and another by Ethiopian Airlines last week set off alarms in the automotive industry?


Automation technologies used in airplanes and autonomous vehicles are neither similar nor easily comparable. If anything, “Aviation autopilot is probably easier than an automotive autopilot,” according to Phil Koopman, professor at Carnegie Mellon University's department of electrical and computer engineering.

For me, the most chilling aspect of the two Boeing 737 Max airliners that crashed within a span of five months is that these tragedies occurred despite presumed scrutiny by the Federal Aviation Administration (FAA) — long considered the world's gold standard for aircraft safety.

These disasters have left the aviation industry, the media and the public asking questions on multiple fronts. So, what happened? Did anyone drop the ball?

What happened with Boeing 737 Max?

First, let’s break down what we think we know about the two Boeing 737 Max crashes.

In the immediate aftermath, blame has been hastily and variously assigned to Boeing’s business decisions, lax regulatory requirements, and modifications in hardware and software designs that might have been an afterthought.

There are no conclusive reports. Investigations on both cases are in their early phases. But more information has been trickling down since the Ethiopian Airlines’ crash on March 10th, prompting experts to ponder several factors that might have contributed to killing of the total of 346.

To wit:

  • Boeing made business decisions under extreme time-to-market pressure — in a race against its archrival Airbus, both airlines pursuing a more energy-efficient engine.
  • The system designs of 737 Max were based on Boeing’s existing bestseller, the 737.
  • Boeing forced introduction of a new piece of software specifically designed for the 737 Max, which affects the maneuvering characteristics augmentation system or MCAS.
  • Software updates on MCAS were delayed.
  • A sensor inside 737 Max, suspected of a role in the crash, had no redundant backup.
  • There was a common desire among vested interests and business incentives of Boeing, regulators and airlines to avoid time-consuming and costly training for airplane pilots flying the 737 Max.
  • New automation always springs a few surprises.

Flightradar 24
(Source: Flightradar 24)
The graph above combines altitude data (feet AMSL), ground speed data (knots), and vertical speed (feet per minute) from ET302 of Ethiopian Airlines Flight 302. The altitude fluctuations were recorded shortly after takeoff.

‘Homestead’ one aircraft type

Among the many potential factors on the list, safety experts now wonder if the crux of the issue lies in Boeing’s decision to "homestead” one aircraft type (its bestseller 737) and “keep making modifications that layer on top of another.”

The decision to revamp the 737 might have started a cascade of impacts on issues that eventually led to the B737 Max crashes.

Boeing originally planned to develop a whole new airplane. But scrambling to keep pace with Airbus (whose latest A320neo features a more economical engine), Boeing decided to modify the 737 by adding larger, more efficient engines.

The 737 is a storied airliner. Originally envisioned in 1964, the 737 series is the highest-selling commercial jetliner in history.

(Source: Boeing)

Given its history and reputation, a re-engined and updated 737 Max seemed like a no brainer, commanding immediate rapport with customers.

But on the engineering side, the 737 Max turned out to be a whole different animal. Boeing engineers had to find a way to fit larger engines into the same narrow-body airliner. Boeing’s team ended up placing new engines further forward on the wing, which resulted in altering the aircraft’s “lift” characteristics.

This new configuration tended, in tests, to push the aircraft’s nose upward, threatening a stall in some circumstances. To compensate, Boeing engineers added new software, called MCAS, which pushes the nose of a climbing aircraft down if it calculates the plane is in danger of stalling.

Now, all eyes are on MCAS.

Some preliminary reports point to an MCAS malfunction, posing the hypothesis that a faulty sensor triggered the MCAS erroneously during the Lion Air takeoff.

Late last week, the New York Times reported on new evidence found at the crash site in Ethiopia, “a piece of equipment known as a jackscrew” that controls the angle of the horizontal stabilizers. The Times speculated that the stabilizers can be triggered by MCAS, thus forcing down the nose of the Ethiopian Airline’s jet, in a similar manner to the Lion Air crash in October.

Was MCAS an afterthought?

Although Boeing insists that the MCAS was installed to make the 737 Max safer, the reality is that MCAS became a necessity because the 737 Max couldn’t operate like its predecessors.

The MCAS emerged as a corrective for the new model’s changed behavior. New lines of code in MCAS were added to the existing flight control system to counter the destabilizing pitch forces from the new engines.

So, is it unreasonable to suspect that the MCAS addition was an afterthought to fix an unanticipated problem that cropped up from the enlargement and repositioning of the 737’s engines?

If so, as any embedded system experts can testify, the addition of the MCAS might have violated the first rule of safety-critical systems designs.

“System safety can’t be an afterthought,” Michael Barr, an embedded software expert, once told us. “It must be designed from the very beginning into a system.” Barr, co-founder and CTO of the Barr Group, led the team of engineers who found the software defects blamed for incidents of sudden unintended acceleration (SUA) in Toyota cars.

Training gap

Safety wasn’t the only reason that prompted Boeing to add the MCAS to B737 Max. Boeing needed to ensure that the new plane handled like previous 737s. The rationale here was to insist that changes made in the B737 Max were so minor that they would not require pilots to be re-trained.

By downplaying design changes, Boeing was reportedly hoping not to alarm the FAA. The company wanted to avoid an FAA order to re-train airline pilots on the system differences between the old and new 737s, using simulators.

After the two recent crashes, public outrage focused on this particular Boeing decision, and on regulatory agencies in the United States and the European Union who agreed that pilots need not be trained or even alerted to the new software, including the new MCAS override controls.

In other words, as far as pilots knew, the MCAS did not exist.

Boeing contended there was no need since, in its view, established emergency procedures would cover any problems regardless of whether caused by the original system or the modification.

Pilots’ view

However, it is not a view shared widely by pilots flying the B737 Max today.

James Fallows of the Atlantic combed through recent reports filed in Aviation Safety Reporting System (ASRS), a program run by NASA. He found several reports — filed by pilots — involving the MCAS.

Pilots complained that even when they did not want the plane to descend, the MCAS lowered the nose. Those pilots hastily disabled or overrode the automated systems, took manual control and survived.

One of the captains who condemned Boeing for the insufficiency of its documentation, wrote in ASRS as follows:

The MCAS function becomes active when the airplane Angle of Attack (AOA) exceeds a threshold based on airspeed and altitude. Stabilizer incremental commands are limited to 2.5 degrees and are provided at a rate of 0.27 degrees per second. The magnitude of the stabilizer input is lower at high Mach number and greater at low Mach numbers. The function is reset once angle of attack falls below the Angle of Attack threshold or if manual stabilizer commands are provided by the flight crew. If the original elevated AOA condition persists, the MCAS function commands another incremental stabilizer nose down command according to current aircraft Mach number at actuation.

This description is not currently in the 737 Flight Manual Part 2, nor the Boeing Flight Crew Operating Manual (FCOM), though it will be added to them soon. This communication highlights that an entire system is not described in our Flight Manual. This system is now the subject of an Airworthiness Directives (AD).

I think it is unconscionable that a manufacturer, the FAA, and the airlines would have pilots flying an airplane without adequately training, or even providing available resources and sufficient documentation to understand the highly complex systems that differentiate this aircraft from prior models. The fact that this airplane requires such jury rigging to fly is a red flag. Now we know the systems employed are error prone–even if the pilots aren’t sure what those systems are, what redundancies are in place, and failure modes.

I am left to wonder: what else don’t I know? The Flight Manual is inadequate and almost criminally insufficient. All airlines that operate the MAX must insist that Boeing incorporate ALL systems in their manuals.

Automation error

Inevitably, Boeing’s MCAS failure has left many outside the aviation industry re-thinking the concept of “automation error.”

Colin Barnden, lead analyst at Semicast Research, for example, laid out three possible scenarios for automation failures in aviation:

  1. Catastrophic failure
  2. Sensor failure leading to pilot error
  3. Sensor and/or software failure leading to automation error

Barnden cited US Airways Flight 1549 as an example of the first scenario, with a double engine failure from bird strike — best known from the film “Sully” and the resulting media coverage. The innate human desire to survive got that plane down in a “forced water landing.”

Many factors saved 155 lives that day, said Barnden, but “the one I note is that Capt. Sullenberger ignored the standard operating procedure for loss of thrust and almost immediately started the auxiliary power unit (APU).”

He explained that this is a small turbine in the tail of the plane. It provided electrical power to keep the “by-wire” systems and flight computers operational long enough to land on the Hudson. “With both main engines inoperable (“rolled-back”), they would have run out of electrical power and crashed. Capt. Sullenberger showed what humans can do that AI cannot — improvise,” Barnden concluded.

Barnden’s example of the second scenario is Air France Flight 447. A scheduled international passenger flight from Rio de Janerio to Paris, it crashed on June 1, 2009. The final report by the French authority, released three years later, concluded that the aircraft crashed after temporary inconsistencies between airspeed measurements caused the autopilot to disconnect. The crew reacted incorrectly and the aircraft suffered an aerodynamic stall. It did not recover.

Quoting a Vanity Fair article entitled “Human Factor”, Barnden said, “The comment most telling for me is where the author stated ‘If the pilots had done nothing, that was all they needed to do.’” Barnden explained: “Essentially the pilot was a computer technician more than an aviator and couldn’t understand the sensor data. A simple GPS readout of ‘speed over the ground’ would have told them they were at stall speed.”

Barnden paraphrased a high-tech truism: “Automation reduces the number of problems but makes the problems you then do face much more complex to solve.” He said, “This is a tragic example.”

In Barden’s analysis, Boeing’s MCAS software is an example of the third.

“There’s little detail of the recent crash yet, but it appears to have involved software intentionally overriding the pilot, supposedly for safety,” he said. “So, probably twice now, a plane has crashed as a result of this specific system. Just look at the regulatory response. All Boeing 737 Max 8 planes have been grounded worldwide. Who knows for how long?”

He concluded: “What we have here is a ‘failure of the intended function,’ going back [to your recent piece on SOTIF — Safety of the Intended Functionality]. Barnden said, “A plane shouldn’t fight the pilot and fly into the ground. This is happening after decades of R&D into aviation automation, cockpit design and human factors research in planes.”

Should cars do what aerospace does?

People casually compare automotive safety with aviation safety, suggesting to carmakers, “Why not take aerospace approaches?”

Unfortunately, this is apples and oranges, explains Carnegie Mellon’s Koopman. Certainly, computer-controlled navigation and tactical maneuvers, redundant hardware and near-perfect software could be applied to cars. But the high-quality design and components common to aeronautic design are prohibiting factors for the automotive industry. Further, the biggest difference lies in people. Highly trained professional operators don’t drive most cars, Koopman noted. “Yearly driver exam with road test? Required simulator time for accident response?”

No such thing will ever be mandated for car drivers.

Considering many factors — including operating hours per year, and cost per vehicle for aviation vs. automotive safety, Koopman concludes: “Aviation autopilot is probably easier than an automotive autopilot.”

Phil Koopman
(Source: Phil Koopman)

Also stacked against AV safety is the lack of standards or industry oversight. Put simply, the automotive and aviation industries exist in two entirely different regulatory environments.

The Federal Aviation Administration (FAA), on one hand, exercises far greater oversight of the verification and validation of designs and their implementation than does the National Highway Traffic Safety Administration (NHTSA).

On the other hand, as a report by National Research Council of the National Academies once concluded, “NHTSA does not set its own design and implementation standards, nor does it demand that manufacturers follow third-party standards to guide design, development, and evaluation processes such as testing of software code.”

If the aviation industry can’t get automation right in terms of machine-to-human interaction — as seen with Boeing’s MCAS — what challenges, probably even tougher, does the AV industry face?

I hope I’m not the only one who cringes while pondering the catastrophic accidents waiting to happen to crunch the autonomous vehicles of tomorrow. Remember, AV safety has no federal agency to regulate it. Each individual company makes its own rules and the public is expected to take the carmakers’ word.

Subscribe to Newsletter

Leave a comment