To keep the state’s grid running, operators at the Electric Reliability Council of Texas (ERCOT) must supply up to 75,000 megawatts of power to meet demand. But a cascade of events on February 14—rare plummeting temperatures, up to 11 inches of snowfall, thousands of people turning up their thermostats simultaneously, and power plants spontaneously going offline—meant an extended loss of power for millions of people.
Functions often fail at the edge of their range of validity, leading to so-called edge cases: a situation that occurs only at an extreme operating parameter. An edge case can be expected or unexpected. A stereo speaker might distort audio when played at maximum volume, or a website designed to handle 10,000 users might crash when 50,000 people try to log on. Quantitatively different behavior happens at a system’s boundaries, and a failure to plan for these anomalies can have devastating consequences.
“Our all-time peak demand record is about 75,000 megawatts,” says Joshua D. Rhodes, Ph.D., who works in the Webber Energy Group at the University of Texas at Austin. “In order to keep the lights on in Texas, we would have had to push the system up to 76,000 megawatts, further than we’ve ever pushed it before.” Professor Rhodes’s research focuses on the bulk electricity system, and the grid optimization models he builds frequently result in edge cases. “I push the grid to extremes—or what I thought were extremes.”
In the past, that might have meant testing solar or wind extremes on the grid and making sure supply kept up with demand. “We went into winter 2021 having run scenarios where we had high demand and low supply, but all of these showed as fine,” Rhodes says. “That’s because we were using historical weather norms to look into the future.”
Planning for edge cases is formidable, expensive, and sometimes overlooked. At best, unconsidered edge cases fail to address users at the margins; at worst, they cause drastic system failures. A confluence of edge cases brought down the Challenger space shuttle in 1986 (see sidebar).
When two or more edge cases meet, they form a corner case. Corner cases are valuable when debugging a complex system, but they are often harder and more expensive to test because they require maximal configurations in multiple dimensions. What happens when a self-driving car misinterprets a traffic signal because of a lightning flash, and plows through an intersection? These corner cases are improbable, but not outside the realm of possibility, and experts plan for them through equations that test a system’s validity.
Functions are most useful. “Zero is always a good case test, because something might go wrong at zero,” says Tony Mann, director of the Maths Centre at the University of Greenwich in London. Given that a function can’t be divided by zero and zero has no logarithm, this value might cause software to malfunction if it wasn’t specifically planned for. “Or we take the square root of a negative number and see if software would fail, because most systems can’t handle complex or imaginary numbers.”
Zero is used to signify any kind of null input (whether that’s undefined, an empty array, or the number zero), revealing whether a system behaves as expected. Testing 1 and 2 in a function, by contrast, shows how the system operates with “normal” input. Testing “max” (that is, the upper limit of an application) is a way to stress-test an application—even if the max seems implausible. An error can provide valuable information that might change the design of a product or service ahead of any real-life disaster. “Typically, an edge case arises when you build something and, over time, conditions arise that weren’t foreseen; the assumptions you made originally are no longer valid,” Mann explains.
In the case of the Texas power failure, frozen cooling-water systems and fuel-supply issues pushed the grid toward an extreme corner case that saw the power plant fleet unable to supply enough power to meet demand, according to Rhodes. This failure underscored “the need to plan a reliable grid with the constraint (or boundary) on that supply,” he explains. Boundary testing for such scenarios can be expensive, but the costs of forgoing testing might be greater. “I don’t know that the multisystem failure pushed us to the edge,” Rhodes says, “but it certainly brought the edge closer to us.”
Challenger: A Case Study
A mere 73 seconds after liftoff, on January 28, 1986, NASA’s Challenger space shuttle blew apart, killing all seven astronauts aboard. A review commission found a few edge cases that contributed to the spacecraft’s demise, but most notably, exceptionally cold temperatures were to blame.
Challenger’s solid rockets were rated for temperatures of 39 degrees Fahrenheit or higher, but ground temperature at launch was just 24 degrees. That, in turn, caused a seal located on the shuttle’s right solid rocket booster—known as an O-ring—to malfunction at launch, letting out hot, pressurized gas. The gas ruptured a strut connecting the booster to the external fuel tank, destroying both.
—Courtney Linder
🎥 Now Watch This:
Adrienne Bernhard is a Los Angeles-born, New York-based freelance writer and former assistant to the deputy editor at The New Yorker. She has written for the Financial Times, The Wall Street Journal, the BBC, Smithsonian, The Atlantic, the Boston Review, and New Criterion, among others.
