The December 2022 issue of IEEE Spectrum is here!

Close bar

DC Metro Crash Caused By Incompatible Equipment?

Looking More Likely As Partial Explanation

1 min read
DC Metro Crash Caused By Incompatible Equipment?

The US National Transportation Safety Board (NTSB) finished its second of three days of hearings in Washington, DC regarding the June 2009 DC Metro crash that killed nine and injured scores more. The testimony yesterday focused on the "maintenance, testing and installation procedures" involving the Metro's signaling system, says this article in the Washington Post.

The Post story says that, "Five days before the accident, Metro crews replaced a key piece of equipment with one from another manufacturer. After the equipment was replaced, the circuitry malfunctioned, and no one at Metro detected the problem."

Worse, the NTSB says that Metro ignored warnings from the original signal equipment manufacturer not to use third-party components during maintenance of the system, since the manufacturer Alstom said that it presents "not only a customer quality issue, but also constitutes a serious and increasing risk to overall signaling system safety."

The former Metro supervisory engineer at the time claims that he was "not familiar" with the warning, even as line engineers and technicians apparently knew and were worried over using non-Alstom replacement parts.

The Post said that, "In interviews with federal investigators, Metro technicians who worked on the portion of track involved in the accident before the crash said the installation of equipment by Union Switch & Signal caused speed and power problems because it did not properly match the existing equipment, much of which they noted was 40 years old."

The transcripts of the maintenance crew's interviews with NTSB investigators can be found here. They make for uncomfortable reading if you are a DC Metro rider (like I am).

The NTSB hearing concludes today. The final NTSB report is expected to be released in June.

The Conversation (0)

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
A plate of spaghetti made from code
Shira Inbar

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less