The December 2022 issue of IEEE Spectrum is here!

Close bar

Automated to Death

As software pilots more of our vehicles, humans can pay the ultimate price. Robert N. Charette investigates the causes and consequences of the automation paradox

9 min read
Automated to Death
Photo: Win McNamee/Getty Images

The passengers and crew of Malaysia Airlines Flight 124 were just settling into their five-hour flight from Perth to Kuala Lumpur that late on the afternoon of 1 August 2005. Approximately 18 minutes into the flight, as the Boeing 777-200 series aircraft was climbing through 36 000 feet altitude on autopilot, the aircraft—suddenly and without warning—pitched to 18 degrees, nose up, and started to climb rapidly. As the plane passed 39 000 feet, the stall and overspeed warning indicators came on simultaneously—something that’s supposed to be impossible, and a situation the crew is not trained to handle.

At 41 000 feet, the command pilot disconnected the autopilot and lowered the airplane’s nose. The auto throttle then commanded an increase in thrust, and the craft plunged 4000 feet. The pilot countered by manually moving the throttles back to the idle position. The nose pitched up again, and the aircraft climbed 2000 feet before the pilot regained control.

Keep reading...Show less

This article is for IEEE members only. Join IEEE to access our full archive.

Join the world’s largest professional organization devoted to engineering and applied sciences and get access to all of Spectrum’s articles, podcasts, and special reports. Learn more →

If you're already an IEEE member, please sign in to continue reading.

Membership includes:

  • Get unlimited access to IEEE Spectrum content
  • Follow your favorite topics to create a personalized feed of IEEE Spectrum content
  • Save Spectrum articles to read later
  • Network with other technology professionals
  • Establish a professional profile
  • Create a group to share and collaborate on projects
  • Discover IEEE events and activities
  • Join and participate in discussions

Paying Tribute to Computer Science Pioneer Frederick Brooks, Jr.

He helped develop the IBM System/360 and its operating system

3 min read
portrait of an elderly man in a a red tie and blazer with a bookcase in the background
University of North Carolina

Frederick P. Brooks Jr., a prolific computer scientist and longtime professor of computer science, died on 17 November at the age of 91.

While working as a project manager at IBM in the 1960s, the IEEE Life Fellow led the development of the System/360 computer family. It was the first vertically compatible family of mainframe computers. Brooks also developed IBM’s OS/360, the world’s largest software project at the time. He is credited with coining the term computer architecture, which is used to describe how hardware and software are organized to make up a computer system and the operations which guide its function. He wrote The Mythical Man-Month, a book of essays published in 1975 that detailed lessons he learned from challenges he faced while developing the OS/360.

Keep Reading ↓Show less

Learn How Global Configuration Management and IBM CLM Work Together

In this presentation we will build the case for component-based requirements management

2 min read

This is a sponsored article brought to you by 321 Gang.

To fully support Requirements Management (RM) best practices, a tool needs to support traceability, versioning, reuse, and Product Line Engineering (PLE). This is especially true when designing large complex systems or systems that follow standards and regulations. Most modern requirement tools do a decent job of capturing requirements and related metadata. Some tools also support rudimentary mechanisms for baselining and traceability capabilities (“linking” requirements). The earlier versions of IBM DOORS Next supported a rich configurable traceability and even a rudimentary form of reuse. DOORS Next became a complete solution for managing requirements a few years ago when IBM invented and implemented Global Configuration Management (GCM) as part of its Engineering Lifecycle Management (ELM, formerly known as Collaborative Lifecycle Management or simply CLM) suite of integrated tools. On the surface, it seems that GCM just provides versioning capability, but it is so much more than that. GCM arms product/system development organizations with support for advanced requirement reuse, traceability that supports versioning, release management and variant management. It is also possible to manage collections of related Application Lifecycle Management (ALM) and Systems Engineering artifacts in a single configuration.

Keep Reading ↓Show less