I'm not seeing much solid information here. First, read the July 1 NTSB report. The NTSB has already determined that it's a track circuit problem. But they're still not sure what failed.
For background, read one of the previous NTSB reports on Metro collisions. The signaling system is classic General Railroad Signal relay-based fixed blocks with audio-frequency track circuits. That's century-old technology, and Metro is still using the original 1970s trackside systems. There are no computers in the basic train protection system.
The NTSB currently suspects problems with an impedance bond between two blocks. (An impedance bond passes traction power but not signal info.) This puzzles me. An impedance bond that fails should not result in a false clear indication. A short between adjacent blocks should result in a train in either block appearing to be present in both. An open should result in a false indication of train presence. Adjacent blocks should use different audio frequencies, so leakage isn't normally a problem. How did this fail?
I wasn't trying to snap at anyone. But there's a difference b/t a section of busy class-1 mainline with a dozen or so trains on it, and a metro line at rush hour with trains spaced every 2 minutes. (2 minutes...wow). We do sometimes tell trains pulling in behind us where exactly we are and what our lenght is, but that info isn't 100% neccisary as that train behind us must be following restricted speed rules.
When you're as vusy as metro, I doubt it would be very safe to have every train announce every time tehy pause for a few seconds until they can occupy the next block. Unless something goes wrong, they shouldn't be sitting there very long.
But that's my opinion. Take it for the electrons it's written with.
The opinions expressed here represent my own and not those of my employer, any other railroad, company, or person.
zugmannYou can't compare a freight operation to a mass transit operation running every 7 minutes. There would be so much talk on the radio that it would be useless. There should be no need to talk every time a train stops. That is why we have signals. Yes signals can fail, but how many precautions can you justifiably take for an extreme event (all the while being able to move people efficiently)? What's next? Hire rear flagmen for the metro? The radio could fail as well. Better send someone out with fusees and torpedos. Even in freight ops we don't announce to the world every time we stop for a signal. That is why we have a signal system. If there's a train stopped ahead, we get a restricting and proceed prepared to stop in half the distance. No radio needed.
aegrotatioRegarding blocks, it sure appears to me that Metro allows more than one train in a block in the course of normal revenue service, and those trains are both computer-controlled and manually-controlled.
I'd bet that blocks are pretty short, some <1000 feet, which gets pretty close to a platform length.
The control center may know where every train is but that has nothing to do with the ATP system - which is the safety system. The control center is not part of the safety system.
-Don (Random stuff, mostly about trains - what else? http://blerfblog.blogspot.com/)
Hi, zugmann, DC Metro's rush-hour timetable states that trains arrive at stations less than 2 minutes apart. I ride the DC Metro and at Metro Center it's well under 2 minutes between trains.
Regarding edblysard's long post, the comment that I have to make about Metro's operations is that the trains can and do "creep up" to the next train. The headways are very short. At stations you can see the following train about a platform's length behind you. The trains stop in tunnels and creep forward 10 yards or so at a time several times. It happens every day.
Regarding blocks, it sure appears to me that Metro allows more than one train in a block in the course of normal revenue service, and those trains are both computer-controlled and manually-controlled.
Heck, before the 1996 accident, the operators weren't even allowed to drive the trains manually because of excessive flat spots. The system was running for 20 years by that time.
There are sensors between the rails every few yards. Every description I have ever read about the DC Metro is that the central control center (in DC) knows where every train is and that's due to these embedded sensors.
Paul_D_North_Jr If any entering block signal is Red, then there could be a train anyplace in that block - at the far end, or just inside the Red signal - unless someone is assuming that the Red is caused only by a train at the far end, and that's an assumption that is not supposed to be made [it's like 'running on Yellows'].
Which is why transit operations usually keep and extra block between trains.
If you run by a stop and there is a train in that block, applying the brakes at that point might be too late.
zugmann There would be so much talk on the radio that it would be useless.
I agree that the "radio" solution wouldn't be good. There would be so much radio traffic, operators would just tune it out - even if it was only done when one train was stopped behind another. This is a very regular occurance on heavy rail transit systems.
If they are tuning all the chatter that doesn't pertain to their train, they're likey to miss something that is directed at them.
oltmannd [snip] - 100 year old technology. Calling this telemetry is like calling the NYC 999 and the Empire State Express a "High Speed Rail trainset".
There's my dose of humor for the day - thanks.
And -
oltmannd I know a good bit about cab signal equipment - at least enought to get myself in trouble!
Now here's a man with integrity. 'A man's got to know his limitations' - nothing wrong with stating that - too many are afraid to admit that they don't 'know-it-all'.
[Me, too - except that I'd get in trouble from how little I know about cab signals.]
- Paul North.
Bucyrus oltmanndBut, since they've already found the "smoking gun" - a track circuit that doesn't register occupancy of trains - no other failure mode needs to be added on to create a plausible explanation for the crash. Don, From the discovery of a track circuit that does not register trains, how likely is it to find a specific fault that caused this? Would the fault generally have to be a failed electrical connection or switch contact? What are some of the specific possibilities that could constitute that fault?
oltmanndBut, since they've already found the "smoking gun" - a track circuit that doesn't register occupancy of trains - no other failure mode needs to be added on to create a plausible explanation for the crash.
Don,
From the discovery of a track circuit that does not register trains, how likely is it to find a specific fault that caused this? Would the fault generally have to be a failed electrical connection or switch contact? What are some of the specific possibilities that could constitute that fault?
Since it's still not working, they ought to be able to determine the cause. They probabilities of specific failure mechanism is way out of my depth. Looking at the "False Clear" database on the FRA website, it appears that more are human caused than equipment failure, though.
edblysard [snips] Maybe what I am pointing at is simply this... If the motorman in the standing train had been required by rule to announce over the radio to all following trains that he was sitting right behind a train at a given point, and that all following trains should come looking, then the odds of this happening would have gone way down. [emphasis added - PDN.] He wasn't required to do that, we instead relied on a system that, up to this point, had functioned just as intended. But a simple radio call, a basic freight railroading safety practice, would have prevented the accident. [snip] You and I both know that most operational practice and safety rules are truly written in blood.
If the motorman in the standing train had been required by rule to announce over the radio to all following trains that he was sitting right behind a train at a given point, and that all following trains should come looking, then the odds of this happening would have gone way down. [emphasis added - PDN.]
He wasn't required to do that, we instead relied on a system that, up to this point, had functioned just as intended.
But a simple radio call, a basic freight railroading safety practice, would have prevented the accident.
[snip] You and I both know that most operational practice and safety rules are truly written in blood.
From the quote above, my understanding is that edblysard isn't proposing that all stops be broadcast - only those stops where a 2nd train comes up and stops behind another one would be required to be radioed to following trains.
So unless this is a common occurrence, there wouldn't be a lot of radio clutter resulting from this.
What I'm not understanding [yet] is how this precaution really promotes safety - other than to verbally alert following trains that there's severe congestion on the line ahead and that they, too, should be prepared to likely have to stop, because now there are at least 2 trains ahead of them that will have to clear out of the way. But this procedure is essentially redundant to a properly operating signal system - the entire length of all of the stopped trains should be causing a red signal at the entrance to any rearward block which is even partially occupied by a train - or even a single car. So the following trains ought to be seeing Yellow/ restricting in advance of the Red anyway. Likewise, even though the 2nd stopped train may be also occupying a part of a block that the 1st stopped train is in - I don't see how that diminishes safety. If any entering block signal is Red, then there could be a train anyplace in that block - at the far end, or just inside the Red signal - unless someone is assuming that the Red is caused only by a train at the far end, and that's an assumption that is not supposed to be made [it's like 'running on Yellows'].
HarveyK400 Of anybody, RMW might have the best feel for whether there is a possibility that a stray clear signal may have leaked from the adjacent track. Given that the system lost the struck train, it seems the same restricting signal that brought it to a stop, not a clear, would also command its follower to reduce speed and stop at roughly the same location.
Of anybody, RMW might have the best feel for whether there is a possibility that a stray clear signal may have leaked from the adjacent track.
Given that the system lost the struck train, it seems the same restricting signal that brought it to a stop, not a clear, would also command its follower to reduce speed and stop at roughly the same location.
I know a good bit about cab signal equipment - at least enought to get myself in trouble!
The struck train was stopped waiting for the train ahead to clear the station. I don't think it crept into the same block as the train in the station, either. In fact, there was likely an empty block between the stopped train and the train in the station - needed because the Automatic Train Protection system (ATP - cab signals with reactive braking) ) is reactive. Operating in manual mode does not override the Automatic Train Protection system. The ATP can be cutout but It is not normal operating procedure to allow this on the road unless there is an equipment failure that keeps the train or train ahead from moving at all and then operation is limited to 15 mph. There has been not mention of any ATP systems cut out in anything I read.
The block that the stopped train stopped in apparently did not register occupancy. To the signal system, this has the same effect as if the train ceased to exist. The following train would get cab signal aspects as if it was following the train in the station. The block with the train in the station would have "no code" behind it to the next block boundary. The following block would have a "stop code" in it. The block with the stopped train would have "approach" in it. The block behind that (with the striking train in it) would have "clear" in it. (Assuming system is built around three aspects plus stop like the PATCO line in Phila/NJ oops. CRS disease. PATCO has 4 aspects plus stop, but they use them for more than just train separation.)
It is extremely unlikely that the "clear" track code leaked from the adjacent rails. More likely, but still way out there in the odds would be that the cab signal receiver bars picked up the code on the adjacent track. The on board cab signal system would have to be so far out of whack for this to occur that it would have encoutered cab signal flips all over the place prior to the crash or the failure of the equipment on the car would have to have occurred at just the right moment.
But, since they've already found the "smoking gun" - a track circuit that doesn't register occupancy of trains - no other failure mode needs to be added on to create a plausible explanation for the crash.
Except that the track circuits and on board cab signal system may have microprocessors in them, no computer failure, in the classical sense, would have been involved here. Metro's computer automation is all about managing the flow of trains on the network within the bounds of the ATP (cab signal with reactive braking) system. Think of this as driving your car at 30 mph and braking gently up to the red light ahead instead of zooming up at 50 mph and braking hard. It smooths the ride and paces the traffic, but it can't make the red light green.
The term "telemetry" has been kicked around. In the ATP system, the only "data" from the wayside to the train is the coded cab signal in the rails that the train picks up inductively. It's a very crude modulated audio frequency signal - 100 year old technology. Calling this telemetry is like calling the NYC 999 and the Empire State Express a "High Speed Rail trainset".
Railwayman,
It was not my intent to present all of this in a "man vs. Machine", or the "us vs. them" Terminator scenario...believe me, I fully embrace the use of computers and the associated systems they require to function.
If computers are leading us to our doom, then we are already doomed, we have relied on them for so many years that I doubt today's form of society could survive without them...look at how we are communicating right now.
My car in fact, couldn't run without the computer it employs...the thing doesn't even have a throttle cable, the only manual functions you can perform without computer aid is opening the door and steering the car, and the computer has a hand in both that now that I think about it.
My point was the complacency that is slowly creeping into our industrial application of computers...we, the end users, tend to forget that the computer can only follow the program it is running, and that program was written by a human(s) who can and often do make mistakes.
My line of thinking was more along the lines of a system failure, not a computer failure...one where a component failed and the "what if this happens" part of the safety program didn't catch it because it was not programmed to catch that one specific failure.
And by "system", I mean the entire operating system, from the operating practices that allowed the train that was struck to creep up behind another train and occupy the same block to the track circuit design that didn't, for what ever reason, alert the computer of the conflict with the following train.
We have become so used to things working, and working in a manner we think of as "right" that we tend to forget this stuff is a machine, and machines and mechanical components do fail.
We also tend to forget that computers can only follow their program, we act as if the computer can "think" for itself, and if no one ever anticipated this one specific scenario, then no one wrote a piece of programming to deal with it.
My thoughts are that the practice of allowing two trains on a commuter line to get that close to each other, and then giving control of one of these trains to a computer is operationally and fundamentally unsafe...the motormen should, in my opinion, have had a way to communicate verbally to each other, and had a degree of control of their respective trains.
Once manual control was given to the standing train, the system should have given some form of signal to all following trains to "go looking", some version of restricted speed, and the capability of the following train(s) to go to manual operation and comply with the restricted signal.
It didn't, it allowed one train to operate differently that all the other trains, and that one train, because of the system design and operation practices, "disappeared".
If you are going to allow one train in an automated system to function manually, you should give a degree of control to all following trains till all the trains in the system are back running on automatic.
From what I have read, the NTSB parked a train in the same spot, and the system did the same thing again, it allowed a following train to proceed, and would have again allowed the following train to strike the standing train.
While a lot of folks seem intent to find a single fault causing this accident, in that they want to blame a computer, or a signal, it is my contention that the "fault" is in both the programming that allows these trains to get that close, and the operation practice of allowing this to occur under both manual and computer control in the first place.
I think it was a system and operational practice failure combined...the "manual" and operational failsafe practices we routinely use in freight railroading were not there, add in the fact that there was a combined manual and computer controlled operation allowed simply presented a situation that no one had anticipated, and no one had written a program into the automated side of the system to stop the trailing train.
Skipping in and out of manual and automatic operations seems to have overwhelmed the operational practice's safety system.
I would bet that once the NTSB finishes its investigation, they will find the computer did exactly what it was programmed to do...it functioned as intended...and I would bet they recommend that the practice of allowing one train in an automated system to go manual and creep up to occupy the same block as an automated train should be prohibited.
Maybe what I am pointing at is simply this...
If the motorman in the standing train had been required by rule to announce over the radio to all following trains that he was sitting right behind a train at a given point, and that all following trains should come looking, then the odds of this happening would have gone way down.
So why was this not part of the operational practice?
Don't simply blame the computer, or a track circuit design, blame too the operational practice that allowed the combined system, as a whole, to fail.
You and I both know that most operational practice and safety rules are truly written in blood.
23 17 46 11
DMUinCTTrain 1 is in the station, train 2 was stopped and holding, it went Manual (assume with permission) to pull up behind train1 on what we would call a limited approach (15 mph or less, a speed that lets you stop in half the distance to any visble obstruction) . When train 2 pulled forward, the computer failed to recognize two trains in one block or read it as one long train. The Stop for train 3 was lifted and it accelerated to appproach speed. Train 3 hits train 2.
Train 1 is in the station, train 2 was stopped and holding, it went Manual (assume with permission) to pull up behind train1 on what we would call a limited approach (15 mph or less, a speed that lets you stop in half the distance to any visble obstruction) . When train 2 pulled forward, the computer failed to recognize two trains in one block or read it as one long train. The Stop for train 3 was lifted and it accelerated to appproach speed. Train 3 hits train 2.
Maybe I missed an update of confirmation, but there is a lot of ongoing conjecture that the struck train had moved into the block occupied the the train at the station. All that was reported is that the operator was waiting for the train in the station to clear. The number of trains in the station block would be immaterial since the circuit was, and would continue to be, shunted. This would not "clear" the preceding block, only continue the restricting (approach) signal command.
narig01 ...I would suspect that cars floor collapsed into the interior. And that would have been the cause of injuries/deaths. From what I've heard of the cars Rohr built for BART(SF Bay Area), most of the train operators believe that in a collision the correct response would be(and I quote) PUSH the emergency stop and thenRUN like hell down the car....
It's been a few days since the pictures were posted. I notice then that, contrary to your "suspicion," the overriding car was pretty much piggy-back atop the bottom car with little collapsing. This was alluded to in my comment regarding the apparent structural integrity despite concerns for the age of the cars.
[QUOTE:sftrains]I am suprised at how much information is already available to the public from the NTSB, they usually wait a while before they announce anything.[/QUOTE]
The DC Metro does attempt a certain level of transparency. They are a little miffed by the NTSB's rush to judgment in other matters and are more than happy to facilitate the release of details either through WMATA itself or the NTSB. WMATA is very interested in forcing the issue of dedicated funding, which they inexpicably do not have. This incident will be the catalyst for dedicated funding they so desperately need.
There is so much more detail coming out every day that I've decided to defer an opinion for now. Sliding blocks is an interesting concept!!
A new finding came out, too. The operator of the "struck" train had earlier gone into manual mode because his train didn't stop for a train in front of HIM. Plus the test train the NTSB ran did not indicate an occupied block, prompting a system-wide inspection of all wayside equipment. There are all kinds of Metro alerts for single-tracking throughout the system this weekend.
The DC Metro's Wayside signals are very simplistic: essentially, the wayside aspects are only Stop, Go, and the equivalent of "Go Carefully." The Metro is totally dependent on in-cab and telemetry. The telemetry appears to be the failure. It's very sad and very bad. The operator of the "struck" train should be commended. The operator of the "striking" train could not do anything to avoid the tragedy. Very sad.
Adding to Don's post.
If this boils down to a lost occupancy and resultant false-clear, there's nothing particularly magical about the cause of the lost occupancy, or designing and implementing a solution. This is plain-old signal engineering. I don't see any reason to fret about the evils of computers leading us to our doom, unless you happen to consider a Saxby & Farmer lever interlocker of 1890 to be a computer (which it sort of was).
I don't know of any floating-block systems in the U.S. in revenue service. The NYC Canarsie Line CBTC system entered revenue service in 2006/2007, but I have seen nothing about floating block being implemented there yet.
RWM
DMUinCTThe talk in this column is of a Block / Signal System. Was this a Block / Signal System? or a Time Spaced / Headway Timing System? (Train speed / Train separation / Passenger waiting time, governs Train position).
Metro is fixed blocks, I believe. Is there any transit operation that uses floating blocks in regular operation? There's been a lot of talk, but I don't thing anyone has implemented.
Fixed blocks are fixed blocks. I believe since the enforcement is reactive, they a have to keep an extra block between trains. It is unlikely that they give trains permission to cut out the ATC very often - certainly not during regular operations without some sort of equipment failure. Creeping up on train ahead ala frt railroading would not be part of regular operations.
This is sounding more and more like a mal-operating track circuit caused a false clear indication.
Try taking off the "index.html" part.
http://www.cnn.com/2009/US/06/26/dc.train.driver/
Let me add some fog to this speculation.
When the DC Metro opened for the 1976 Bi-Centennial, the best mico-computers ran on a 16 bit, 3MHz chip. That orignal control system must be long gone. In the computer world, replacement chips are a problem after 20 years.
Alstrom of France runs the TGV trains at 3 times the speed of the DC Metro, they should know what they are doing.
The talk in this column is of a Block / Signal System. Was this a Block / Signal System? or a Time Spaced / Headway Timing System? (Train speed / Train separation / Passenger waiting time, governs Train position).
In "Automatic Mode", the operator does not control the speed. in DC, Boston, the operator hits a start button and the computer brings the subway train up to the proper speed and stops at the next station.
Want to speculate: PURE SPECULATION
Don U. TCA 73-5735
The "stop and proceed" philosophy in signaling is not new. Most graphic is the "G" signal which indicates that when it is red or most restrictive, train does not have to stop but may proceed under control being able to stop within sight distance knowing that the block ahead may be occupied; this is or was on steep grades and was designed so that there were no problems stalling or restarting on heavy grades and was primarily aimed at freight trains and heavy passenger. Another "stop and proceed" signal was one the DL&W (for one) had at interlockings: four light search light [top red, 2nd yellow, 3rd yellow, bottom green). Red was stop, red over first yellow (diverging route) or yellow was proceed with caution prepared to stop at next signal, red over top yellow over green (divergining route) or top yellow over greet, medium approach, and red over green (diverging route) or green, clear or proceed. There also was a red over the lower yellow which allowed a train into an occupied block at restricted speed prepared to stop short of a proceeding train or other obstruction. I saw this used frequently during rush hours to keep traffic moving through interlockings so as not to block station platforms and also to return to a train when setting out or picking up cars from sidings.
RIDEWITHMEHENRY is the name for our almost monthly day of riding trains and transit in either the NYCity or Philadelphia areas including all commuter lines, Amtrak, subways, light rail and trolleys, bus and ferries when warranted. No fees, just let us know you want to join the ride and pay your fares. Ask to be on our email list or find us on FB as RIDEWITHMEHENRY (all caps) to get descriptions of each outing.
Comments. I've been watching this on news reports all week.
2 Items that I think the Safety Board(NTSB) will look at.
1. The apparent failure of the signal system to detect the train that was standing still & was struck. One of the pieces I saw in the news was that MTBA(Boston) uses similar equipment from Alsthom(?) and they(MBTA) had a severe failure and warned DC Metro of the failure.
BART(SF Bay Area) during it's 1st few years had no end of troubles with the signal system(Automatic Train Control). Much of it was attributed to the use of a very low voltage(6v or 9v I think) and the overnite build up of condensation(and a very lite layer of corrosion) on the rails
2. The collision itself. The lead car of the moving train(from what I could see of the photos & from published descriptions of witnesses) struck the standing train then rode up of over the last car of that train. According to witnesses the car went up then landed on top of the that car.
I would suspect that cars floor collapsed into the interior. And that would have been the cause of injuries/deaths. From what I've heard of the cars Rohr built for BART(SF Bay Area), most of the train operators believe that in a collision the correct response would be(and I quote) PUSH the emergency stop and thenRUN like hell down the car.
This was what a train operator did about 20-30 years ago when his train hit a maintenance truck (after hours,no passengers) that was hi railing down the wrong track. If I recall correctly that truck went some considerable distance into the BART car. The train operator walked away from the accident, the maintenance crew did not.
Not sure what else to add
Rgds IGN
sftrainsOne of the first reports of the incident said that the stationary train was waiting for a preceding train to clear a platform. It is plausible that the operator of this train asked for permission to go into manual mode and "cutout" the ATP on his train in order to slowly approach the platform while the preceding train was still there. This would not affect the following train at all, but could be the reason the stopped train was in manual mode. ...The real concern in this whole disaster is how a vital track circuit was not shunted by a six car train. That is 24 axles that should have created an occupancy. The fact that this circuit was worked on in the last month points to either a problem that was fixed by turning up the transmit power, or a wiring mistake such as caused the Clapham Junction disaster in England. I am suprised at how much information is already available to the public from the NTSB, they usually wait a while before they announce anything.
One of the first reports of the incident said that the stationary train was waiting for a preceding train to clear a platform. It is plausible that the operator of this train asked for permission to go into manual mode and "cutout" the ATP on his train in order to slowly approach the platform while the preceding train was still there. This would not affect the following train at all, but could be the reason the stopped train was in manual mode.
The real concern in this whole disaster is how a vital track circuit was not shunted by a six car train. That is 24 axles that should have created an occupancy. The fact that this circuit was worked on in the last month points to either a problem that was fixed by turning up the transmit power, or a wiring mistake such as caused the Clapham Junction disaster in England.
I am suprised at how much information is already available to the public from the NTSB, they usually wait a while before they announce anything.
You seem to be confusing manual operation of the struck train with either overriding a stop/restrictive or cutting out the cab signal. In this case, my reading of the account was that the operator was manually controlling the train in compliance with the same cab signal system that governs automatic operation. The account given was that the struck train was operated in manual mode with cab signals - although that was not said directly - from the start of the run, not to close up on the train in the station. The train had stopped and was not creeping ahead at restricted speed and overriding the stop signal which can be done with dispatcher consent if necessary. Nor was the struck train operating and moving with the cab signals cut out, which again is allowed under the rules in certain circumstances; but was not the case here. The rules have been explained previously by others; even if not in direct response to the "manual operation" comments.
While the account said the operator of the stopped train was waiting for the preceding train to clear the station, he just as likely was waiting for the cab signal indication to change as for waiting for dispatcher permission to close up and override a stop indication. For what its worth, I see little imperative to defeat safety systems designed to keep trains apart just to save a few seconds.
This type of train control system has worked well with few exceptions for some 30 years. Perhaps WMATA has encountered more exceptions remembered on previous posts than other properties, and may deserve the review that I understand is a normal part of investigations. This technology was developed in response to unacceptable levels of failure in previous systems in the rail transit environment.
Some of you clearly disdain computer and electronic systems; and because it failed in this case, you hint at trashing it out of hand in favor of something else. Just what is your agenda? How many trains have moved safely through the numerous block circuits along their routes since day one? Let the investigation sort out if there was a systemic flaw or whether this was a perfect storm event that can be avoided in the future.
Earlier I wrote of my suspicions with regard to the track circuits. Let me repeat that the system worked for the train that was struck; but not well enough for the following train. A lot of trains passed safely since the circuits were tested previously; so that reduces, but not eliminates, the likelihood of a cause from that source.
I have no information to dispute the ascertion; but 6 seconds seems like an awfully long time for electrically-conrolled air brakes to set up for a subway train. Six seconds would reduce the collision speed by 18 mph.
Carl
Railroader Emeritus (practiced railroading for 46 years--and in 2010 I finally got it right!)
CAACSCOCOM--I don't want to behave improperly, so I just won't behave at all. (SM)
CShaveRRedblysard Reports have it that the motorman in the trailing put her train in emergency...one would assume because she saw the other train...or maybe she just had that hunch...we will never know because she died...but my point is, had the trains been under a different type of control, or a shared control, this might not have happened. But my guess is that Metro, and the motorman running the trailing train, simply assumed that because the computer didn't take action nothing was wrong. Complacency, being so used to the system always working right, will play a large role in this...but the fact she did plug the train while the computer failed to take action confirms that no matter how well thought out and programmed the computer is, there will always be a need for the human interaction and intervention from the cab. And no, her putting the train into emergency did not prevent the accident, but I bet it saved a lot more lives than we will know. Ed, back when you posted this, I admired (yet again!) your knack for saying just the right thing. Of course, I agree with you, as would most railroaders who have to walk the walk. And it appears that we're not alone: http://www.cnn.com/2009/US/06/26/dc.train.driver/index.html
edblysard Reports have it that the motorman in the trailing put her train in emergency...one would assume because she saw the other train...or maybe she just had that hunch...we will never know because she died...but my point is, had the trains been under a different type of control, or a shared control, this might not have happened. But my guess is that Metro, and the motorman running the trailing train, simply assumed that because the computer didn't take action nothing was wrong. Complacency, being so used to the system always working right, will play a large role in this...but the fact she did plug the train while the computer failed to take action confirms that no matter how well thought out and programmed the computer is, there will always be a need for the human interaction and intervention from the cab. And no, her putting the train into emergency did not prevent the accident, but I bet it saved a lot more lives than we will know.
Reports have it that the motorman in the trailing put her train in emergency...one would assume because she saw the other train...or maybe she just had that hunch...we will never know because she died...but my point is, had the trains been under a different type of control, or a shared control, this might not have happened.
But my guess is that Metro, and the motorman running the trailing train, simply assumed that because the computer didn't take action nothing was wrong.
Complacency, being so used to the system always working right, will play a large role in this...but the fact she did plug the train while the computer failed to take action confirms that no matter how well thought out and programmed the computer is, there will always be a need for the human interaction and intervention from the cab.
And no, her putting the train into emergency did not prevent the accident, but I bet it saved a lot more lives than we will know.
http://www.cnn.com/2009/US/06/26/dc.train.driver/index.html
CNN.com The page you requested cannot be found. The page you are looking for might have been removed, had its name changed, or is temporarily unavailable.
Never too old to have a happy childhood!
Our community is FREE to join. To participate you must either login or register for an account.