To be clear, the scope of my comment is the problem described in the video. I literally know nothing about the details. I didn't understand the problem statement to encompass the incursion of snow, drunk drivers, or cyclists into the subway system, and I don't have any specific ideas on implementing a PTC-like system on a wide-area rail network.
BART has a lot of surface coverage, so yes, I agree that many of those issues can't be hand-waved away in that case. But a municipal subway is, well, a municipal subway. The problem being discussed here is scheduling and tracking, not collision avoidance, obstacle sensing, or any of that other stuff. They are complaining that they can't implement rolling block scheduling because they don't know where their cars are or how fast they're going, and they're saying they need to spend an absurd amount of money to remedy that situation, and that's what I'm objecting to.
The problem I addressed is objectively trivial, whether you agree or not.
When you expand the scope wildly to include a lot of things that have nothing to do with tracking car positions and speeds, it's no longer trivial. But I can only address the content of the video (which I assume you've watched before commenting, as I did.) This entire thread has more to do with moving goalposts than with moving train cars.
BART has a lot of above ground track, but so does the New York MTA. With all of the above snow on the tracks will translate into problems underground.
hey are complaining that they can't implement rolling block scheduling because they don't know where their cars are or how fast they're going, and they're saying they need to spend an absurd amount of money to remedy that situation, and that's what I'm objecting to.
Collision avoidance is an inherent part of scheduling and tracking. The reason they run so much distance between trains in New York (and almost anywhere else) is almost entirely because they're allowing enough distance for the train to stop without hitting the vehicle in front of it. Locating the vehicles with enough precision and accuracy is more than simply sending a signal — although the inductive loops used by Muni work well enough[1] underground until the trains (or, most recently, contractors) themselves destroy the loops. CBTC in by its very definition is more than simply vehicle location.
While I'm mostly in the camp that BART is wildly incompetent, they tried to reinvent an even simpler train control in the 70s and demonstrated quite explicitly what happens when you underestimate the problem at hand. More recently they've spent tens of millions trying to come up with a CBTC (and so has Caltrain) and failed completely. If you know something they don't, talk to a lawyer and file some patents as you could make a mint.
1: For the first decade or so after Muni went to a CBTC[2] setup even something as basic as the transponders were huge pain points and you'd see massive failure rates over time leading to all sorts of problems underground.
2: The big selling point of the CBTC setup Muni chose was that it could be installed with a minimum of disruption AND that it used cheap, off-the-shelf parts. Alcatel/Thales abandoned that design almost immediately after pawning it off on Muni.
Why are they allowing enough distance for the train to stop without hitting the vehicle in front of it? We don't normally do that on interstate highways. If we did do that, capacity would be greatly reduced.
Correct, car drivers do behave in unsafe ways. Humans greatly value freedom of choice, and once given it will almost invariably choose badly and then be sad. We aren't allowed to make the same bad choices on their behalf - users will rebel if you propose that it's OK for a few New York subway trains to crash each day.
This isn't about railways per se. Individuals with freedom of choice on the railway will make bad decisions too. Track workers for example are routinely complicit in the unsafe practices that cause them to die, if we told them "take this dangerous shortcut" we'd be demons, but since they choose for themselves to take the shortcut against instructions we can only wring our hands.
Comments
To be clear, the scope of my comment is the problem described in the video. I literally know nothing about the details. I didn't understand the problem statement to encompass the incursion of snow, drunk drivers, or cyclists into the subway system, and I don't have any specific ideas on implementing a PTC-like system on a wide-area rail network.
BART has a lot of surface coverage, so yes, I agree that many of those issues can't be hand-waved away in that case. But a municipal subway is, well, a municipal subway. The problem being discussed here is scheduling and tracking, not collision avoidance, obstacle sensing, or any of that other stuff. They are complaining that they can't implement rolling block scheduling because they don't know where their cars are or how fast they're going, and they're saying they need to spend an absurd amount of money to remedy that situation, and that's what I'm objecting to.
Perhaps saying "it's trivial to solve" might be the wrong approach then?
The problem I addressed is objectively trivial, whether you agree or not.
When you expand the scope wildly to include a lot of things that have nothing to do with tracking car positions and speeds, it's no longer trivial. But I can only address the content of the video (which I assume you've watched before commenting, as I did.) This entire thread has more to do with moving goalposts than with moving train cars.
BART has a lot of above ground track, but so does the New York MTA. With all of the above snow on the tracks will translate into problems underground.
Collision avoidance is an inherent part of scheduling and tracking. The reason they run so much distance between trains in New York (and almost anywhere else) is almost entirely because they're allowing enough distance for the train to stop without hitting the vehicle in front of it. Locating the vehicles with enough precision and accuracy is more than simply sending a signal — although the inductive loops used by Muni work well enough[1] underground until the trains (or, most recently, contractors) themselves destroy the loops. CBTC in by its very definition is more than simply vehicle location.
While I'm mostly in the camp that BART is wildly incompetent, they tried to reinvent an even simpler train control in the 70s and demonstrated quite explicitly what happens when you underestimate the problem at hand. More recently they've spent tens of millions trying to come up with a CBTC (and so has Caltrain) and failed completely. If you know something they don't, talk to a lawyer and file some patents as you could make a mint.
1: For the first decade or so after Muni went to a CBTC[2] setup even something as basic as the transponders were huge pain points and you'd see massive failure rates over time leading to all sorts of problems underground.
2: The big selling point of the CBTC setup Muni chose was that it could be installed with a minimum of disruption AND that it used cheap, off-the-shelf parts. Alcatel/Thales abandoned that design almost immediately after pawning it off on Muni.
Why are they allowing enough distance for the train to stop without hitting the vehicle in front of it? We don't normally do that on interstate highways. If we did do that, capacity would be greatly reduced.
I think I found the problem. :-)
Correct, car drivers do behave in unsafe ways. Humans greatly value freedom of choice, and once given it will almost invariably choose badly and then be sad. We aren't allowed to make the same bad choices on their behalf - users will rebel if you propose that it's OK for a few New York subway trains to crash each day.
This isn't about railways per se. Individuals with freedom of choice on the railway will make bad decisions too. Track workers for example are routinely complicit in the unsafe practices that cause them to die, if we told them "take this dangerous shortcut" we'd be demons, but since they choose for themselves to take the shortcut against instructions we can only wring our hands.