DC Metro Crash: Computer or Operator Error, or Both?

Crash That Kills At Least Seven is Puzzling

2 min read
DC Metro Crash: Computer or Operator Error, or Both?

At 1702 yesterday, a Washington Metropolitan Area Transit Authority (Metro) Red Line subway train apparently traveling at a high rate of speed rear-ended a stationary subway train, killing at least seven people and injuring more than 70. The crash, as the Washington Post dramatically put it, was supposed to be "impossible."

The Metro's trains are controlled by what is called the Washington Metrorail Automatic Train Control system. The system is designed to allow for fully automated train operations requiring very little direct involvement from train operators.

Individual trains have onboard computers that control their speed and brakes. A centralized system uses audio frequency track circuits (commonly called trackside relays) to detect the location of the trains and is designed to keep them a safe distance from one another. If trains get too close, the computers are supposed to apply the train's brakes.

As described in this National Transportation Safety Board (NTSBreport:

"Each mainline route is divided into track blocks from one end of the terminal station to the other. Each block is checked for train occupancy by means of audio frequency track circuits. Tuned impedance devices provide block separation. These devices inject coded signals into the track that detect the presence of a train in the block and automatically transmit limiting and regulated speeds to passing trains. There is generally one track circuit per block with impedance bonds located at both ends of each track circuit."

And finally, if the safety system fails, there is a train operator that has the capability to override the system and apply the brakes.

What is puzzling investigators currently is why, even if the computer system failed, didn't the operator of the train that crashed into the stationary one stop, especially since visibility wasn't impaired and the train was traveling on a straight portion of track. A massive brake failure is one possibility, as is driver incapacitation for some reason being another. The  subway train driver perished in the accident.

There has been problems for many years with the Metro's safety system. For example, as stated in today's Washington Post story:

"The agency tore out all 20,000 trackside relays in 1999 after discovering that a small portion designed to last 70 years were failing after 25. They sent erroneous instructions to trains on several occasions. One train was told to travel 45 mph on a stretch of track with a 15-mph speed limit; another was directed to travel at zero mph when it should have been ordered to move at 15 mph."

In June 2005, there almost was another serious Metro crash when the safety system failed. A train operator noticed that he was getting too close to another train and had to manually applied the brakes to avoid a collision. The train operator following him did the same. The failure could not be reproduced, and according to today's story in the Post, it is unclear whether any definite reason for that failure was ever found. Since there was no crash, the NTSB was not called in to investigate.

Being a more than occasional rider of the Metro, I have an abiding interest into what caused the accident. I'll keep you posted as things become clearer. The NTSB should be able to determine the cause, especially if the train was equipped with an event data recorder and it survived the crash.

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
Vertical
A plate of spaghetti made from code
Shira Inbar
DarkBlue1

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
{"imageShortcodeIds":["31996907"]}