Controversy Over Rhee Now to Include Sex, Congress
The Manhattan Project
Report: CCDC Split From UDC Is "Critical To Success"
Increased Urban Walkability For The Win
D.C. United Icon Ben Olsen To Retire
The National Transportation Safety Board has put up a second advisory today on its web site regarding the most recent findings of its investigation of the June 22 Red Line crash. In it, we learn for the first time that the train control system track circuit where the accident occurred -- the same one that investigators initially found to be not functioning properly after testing it during the first couple of days after the crash -- was replaced by WMATA maintenance crews on June 17, five days before the accident. From the advisory:
After a post- accident review of recorded track circuit data, WMATA reported to the NTSB that the track circuit periodically lost its ability to detect trains after June 17th; the NTSB is reviewing documentation on the performance of that track circuit both before and after the June 17th replacement.No conclusions from NTSB on this yet, of course, but given the timeline and the recorded data they mention, it certainly suggests the strong possibility that this was a faulty circuit which failed almost immediately after it was installed.
Also of note from the advisory: On the weekend of July 18, investigators are planning to conduct sight distance tests using trains consisting of similar cars to those involved in the accident. The tests are designed to establish when the struck train would have been visible by the operator of the striking train.
add to stumble upon
add to reddit
tweet this
post to facebook
Interesting. Either that, or I suppose there may have been some fault in its installation that caused it to fail?
Any word at all when it will stop taking me an hour and a half to get from Wheaton to Farragut West for my commute?
Good point, EdHoover.
As for your second inquiry, I'll refer you to the Morning Roundup -- all we know is that trains will be slow indefinitely, until all testing and the investigation are concluded.
Ah the smoking bug can.
What EdHoover said. Did they actually test this thing after replacing it?
What I continue to not understand is why the failsafes are so easily defeated. There should be no reason why a failed sensor would go undetected or ever cause a crash like this.
My damn car tells me when it's own sensors stop working. Every time you turn it on, it tests them all. If something stops reporting data, or reports data that isn't within normal parameters, the "check engine" light goes on.
It seems blindingly obvious that any if any given sensor stops reporting data, or reports unexpected data, it has failed. Does the central computer system not have the basic capacity to notify operators when a sensor hasn't noticed a train in the last, say, 30 minutes?
Beyond that, it's hard to believe the system is so simplistic that even if a sensor or group of sensors has failed, it suddenly forgets where the trains are. So the train happens to stop where there's a sensor "dead area" (no pun intended). Why wouldn't the software be able to raise a HUGE red flag when a train that was noted at the previous group of sensors, failed to arrive at the next one as scheduled? And there's a train cruising into the space where the train ought to be at that point?
You don't even need redundancy for this thing to be 100% safe. You just need a system that has the most basic analysis of the data this is (or, in the case of failed sensors, is NOT) being received by the central system. Clearly that is not the case.
That's been one of my big questions all along. Is our automatic train control (ATC) system that shitty? I posed this to Dr Gridlock on one of his chats but they didn't include it.
I mean, it seems like our ATC can't even do basic metro-y things like, say, stopping at the exact same place on the platform every time. You know, like every other subway system on the planet seems capable of doing. Is ours that old/bad/broken? Is it a matter of funding? Was it installed by idiots? What, precisely, is the issue?
It's really quite appalling. At the heart of this whole thing is SOFTWARE. I don't care how old/crappy/unreliable all the components/relays/sensors are, just having some halfway decent SOFTWARE should compensate for a lot of broken sensors, and certainly let people know when those critical sensors haven't worked in a goddamn week!
Simple answer: yes.
A friend of mine who seemed to have good knowledge of the system told me a few years ago that the entire system was dependent on a single Windows NT4 box. Not sure of the validity or if it's been upgraded since then, but it wouldn't surprise me if it were true.
I find that, frankly, to be surprisingly sophisticated. Given WMATA's track record, I would've wagered a gold tooth (and an incisor at that) that its "system" consisted of an Intellivision and a recycled Frogger cartridge.
Comment of the day! LOL
Comment of the day! LOL
Comment of the day! LOL.
You just know that down at WMATA HQ they're saying, "Damn it! I knew we should have taken out that cartridge and blown on it!"
OK wow, talk about random triple-posting. That last one was supposed to be to @cactus jack's Intellivision comment.
Yikes.
According to the report, and that which is being reported elsewhere, WMATA DID know that the sensor wasn't working. They knew as early as 5 days before that the sensor wasn't working. They just didn't do anything about it.
This is the problem with automatic controls--it lulls humans into a sense of false security and laziness that slows or stops people from taking action when it needs to be taken.
This story just keeps getting more tragic by the minute. I cannot imagine being the conductor's family. Bad enough she watched her own death approaching, but now to find out that WMATA knew they were sending her to her death?!? Reprehensible.
I'll admit that I haven't been following this all that closely, but I'd point out the the controls have worked correctly 99.99% of the time for 30 some years. Obviously something went horrifically wrong in this case but to slag off the entire system as defective or installed by idiots ignores the basic statistical reality of the situation.
From what I understand, system wide, the track sensors and the way the information is transmitted back to the ATC is antiquated and out of date. The actual ATC system (and software) itself is pretty sound! Track sensors were at failt, as the NTSB stated, not the ATC as many think! Unfortunately due to the bad sensors, the train thought everything was ok when in reality... Yes, the operator hit the emergency brakes, but it takes time to stop a 6 car train, it's not going to stop immediately.
It all falls on WMATA employees who are LAZY and incompetent. Management obviously doesn't care what consultants (like the ATSB) have said about the system or the trains. They ignore all the recommendations and just go about business as usual putting band aids on things that should be fixed right in the first place!
(Don't even get me started on this whole Vinyl flooring with cloth seat feature that might be in the new trains. Wouldn't that be just as messy, if not more?)
I am not a regular "commuter" on METRO, but I personally find the ride a lot more smooth when the trains are in ATC. I don't trust many of the operators who are too lazy to follow directions given to them and use the train controls and ATC to it's full potential.
Statement from Metro General Manager John Catoe on the Second Update from the NTSB Investigation into the June 22 Red Line Train Collision
First and foremost, I want to assure our riders that the Metrorail system is as safe as it can be. We have been working with the NTSB to find the root cause of this tragic accident. And riders will continue to experience delays on the Red Line until we find the cause. We apologize for the inconvenience, but this is critical to gaining a full understanding of why this happened and then taking whatever steps are necessary to ensure that this kind of tragedy doesn’t happen again.
Our testing has resulted in our being able to replicate the problem, but not isolate the specific cause. We know the problem is in a track circuit. We could just replace the parts, but we need to understand what caused it. You don’t just change the parts. We must find the cause.
We have conducted computerized analytical tests, which the NTSB has referenced as “track circuit data.” The data establishes a profile of what’s taking place electronically in the rail system. These tests are normally conducted monthly. What we found during a special review of the data after the accident was that the track circuit periodically lost its ability to detect trains. This is not an issue that would have been easily detectable to controllers in our operations control center. What the analytical profile showed was that the track circuit would fail to detect a train only for a few seconds and then it appeared to be working again. This happened after we had replaced an “impedence” or “weezie bond” for the track circuit for where the accident occurred. The device communicates information such as speed and distance between the tracks, trains and operations control center. The device was replaced as part of Metro’s normal track rehabilitation program. We are now running analytical reports on the rail system daily instead of monthly and system wide. We have found no other similar issues with track circuits in the system.
Again, I want to stress that we will do everything we can to find the cause of this accident, and from what we have discovered so far it appears to be a freak occurrence.
###
FAQ's about the accident: http://www.wmata.com/about_metro/news/faqs/preview.cfm?faqID=57