I'll confess I still don't understand why it's so hard to keep track of the position of subway cars in real time. I can think of any number of ways to do that more or less trivially.
That’s the source of a lot of error in project estimates, since it is trivial to come up with plans before considering the details.
Phrasing it as a software project: “I don’t understand why it is so hard to find information on the internet. All of the pages are available through HTTP web servers, aren’t they? What’s wrong with just downloading them all?”
I don't follow you. How is keeping track of the position of a small number of subway cars in a limited geographical area anywhere near as abstract a problem as "finding information on the Internet?"
This is a relatively-trivial engineering exercise with any number of safe, efficient solutions. If someone says it will take a billion dollars to solve the problem, that is the person you should demand proof from.
> This is a relatively-trivial engineering exercise with any number of safe, efficient solutions.
Your comments here are another great example of how ironic it is to hear the word "trivial" used to describe solutions. Don't you think it's a little unrealistic that your "relatively-trivial engineering exercise" suggestions are capable of successfully tackling a problem so many parties have thought about? Have you considered that your insight is actually failing to account for a variety of unknown unknowns you might have about the NYC subway system?
Look at it this way: why do you suppose your suggestions haven't been implemented yet? Do you think the vast array of parties with skin in the game haven't thought of them (and are thus incompetent)? Do you think they simply aren't motivated to implement them?
I wouldn't be surprised if your proposals are technically sound (especially for greenfield rail construction). But I would be absolutely shocked if the problem is anywhere near as trivial as you're making it out to be.
Absolutely fair point. But don't you think there's something profoundly wrong somewhere when cities in all kinds of climates and conditions around the world manage to solve their problems. With the pooled knowledge of all those projects, isn't it likely that the NY project could find solutions there? Presumably sourcing knowledge and solutions and adapting them would in hindsight have been cheaper than developing a system from scratch?
The best solution is probably for the MTA to buy a system from Siemens or Thales – they have that worldwide knowledge. But last time I discussed this here, I was told funding restrictions meant the company had to be American. Unfortunately for that, this is an area of European expertise.
If that's the case it could explain the problems.. Of course that's moronic because the US isn't known for smoothly functioning public transit systems.
Have you considered that your insight is actually failing to account for a variety of unknown unknowns you might have about the NYC subway system?
No. Whatever the unknown unknowns are, they're not going to be that hard to work around. Keeping track of a few train cars isn't exactly the Manhattan Project, even if it has to be done underneath Manhattan.
The video suggests that the total budget for the CBTC retrofit was in the vicinity of $1 billion. I hope that I either misinterpreted it, or that the budget includes other improvements, because I doubt it cost that much (in 2018 dollars) to build the initial subway routes in the first place.
Look at it this way: why do you suppose your suggestions haven't been implemented yet? Do you think the vast array of parties with skin in the game haven't thought of them (and are thus incompetent)? Do you think they simply aren't motivated to implement them?
I think the vast array of parties with skin in the game have treated said "skin" as a target for optimization in itself. I'll readily admit they're likely better at that game than I am.
How can you say with any confidence that the unknown unknowns you have won’t be very hard to work around? That’s entirely the point of unknown unknowns - you don’t know what you don’t know.
(Shrug) I know how to figure out where some subway cars are and keep track of them for less than nine figures. I don't expect anyone to take my word for it, and I don't care if they don't; it's just an excuse for some meaningless chest-thumping on HN while waiting for Vivado to do its thing. :-P
If I lived in New York and had to pay for it, I'd probably find the question less interesting and more infuriating.
I would encourage you to submit a problem statement with your proposed method to TCRP research program [0,1]. Unfortunately the 2019 solicitation is closed, but the 2020 solicitation will open early next year. A better vehicle tracking method than the current block-level tracking is something that would be valuable to sub-surface transit system in the USA and if what you propose (or something similar) is feasible, the statement stands a real good chance of getting funded for a research project. And if the project is funded, you can even bid on the research work. I'm active on the TBR ADC040 subcommittee, if you have questions, hit me up (my twitter is on my profile) and I'll see if I can connect you to the right person.
I write this in all seriousness - this isn't a "if you're so smart why don't you do it" post, I'm writing this in acknowledgement that there are a lot of smart people on HN, and if there's a chance to improve US transit, I'm all for it.
I hear you, but unfortunately, I have no insights that any random EE (or advanced hobbyist) with some DSP experience wouldn't immediately bring up as well. It's safe to say that anything I could suggest has already ended up in plenty of proposals.
It would be interesting to understand just why this is considered a $100M-$1B problem, though. I'm curious enough to do some more reading.
No. Whatever the unknown unknowns are, they're not going to be that hard to work around.
Please try some humility, for real. This isn't some guy's backyard train model project. This is a 24/7-running subway in one of the busiest cities in the world. Errors that result in shutdowns can cost tens to hundreds of millions of dollars in economical damage. Accidents can take hundreds to thousands of lives.
This attitude you have is the attitude of every single commenter who asks why Dropbox has "so many employees" when they "could build it in a weekend". It shows a huge amount of disrespect for complexity you aren't aware of; and by extension, things you're not aware of in general. It's the same attitude you find in project managers who don't understand XKCD1425 and "just want it done now it can't be that hard". The attitude of anti-vaxxers who dismiss expert opinions to rely on their gut feelings.
I don't know why it's so expensive, I haven't seen the breakdown, but my default reaction will be to dig further, rather than to dismiss people who have worked on subway systems infinitely more than me and casually throw in a "Nah, it's just keeping track of some train cars, nbd".
If you need to replace physical infrastructure, well, that's where the problem is. MTA has about 6500 subway cars. Replacing all of those would tie up somewhere around 10% of the world's total yearly subway car manufacturing capacity.
Okay, so maybe you only design a module that can be retrofitted onto existing cars--there's only 16 car designs on the MTA according to Wikipedia. You just have to install them on every car, which means figuring out how to slot the install times into the maintenance schedules of cars, and if your schedule slips for delivering the parts to install, well, that's going to push stuff back a few months.
The problem isn't that the algorithm is hard. The problem is that the hardware didn't exist, and retrofitting hardware is a much more expensive endeavor than retrofitting software.
Okay, so maybe you only design a module that can be retrofitted onto existing cars...
The cars have to receive power from someplace. Wherever they are being energized, there is by definition a complete circuit to all cars being powered on that line. Likewise, wherever the cars are, there is going to be a large and reasonably well-defined impedance discontinuity on the power rail. So, as a first attempt, I'd look at some sort of reflectometry scheme. Wind a few turns of wire around the cable that feeds the third rail, inject a pulse train with Gold codes or something similar that lends itself to autocorrelation methods, and listen for echoes.
This requires a grand total of $0 in hardware to be added to the cars. If it's not enough -- e.g., if the points raised in Anechoic's post render it impractical to rely on passive reflections -- then it should be possible to add a small amount of hardware at the cars to act as an active transponder, injecting its own pulse train in response to carrier-current signals from the distribution point.
So now we need to connect two wires at each car, and mount a small box with some duct tape^W^W milspec fasteners. Not exactly rocket surgery.
The cars have to receive power from someplace. Wherever they are being energized, there is by definition a complete circuit to all cars being powered on that line.
Most, but not all of the time. There are dead segments in pretty much any system be it overhead or third rail.
Likewise, wherever the cars are, there is going to be a large and reasonably well-defined impedance discontinuity on the power rail.
Nope. See Bill Wattenburg's demonstration with BART.
Wind a few turns of wire around the cable that feeds the third rail, inject a pulse train with Gold codes or something similar that lends itself to autocorrelation methods, and listen for echoes.
What if you're not using a third rail?
Basically you seem to have solved the problem under ideal circumstances but not accounted for the myriad of failure modes one will encounter in the real world.
Edit: the other part you're missing is that the first C in CBTC is communication. Locating trains has been fairly well solved (inductive loops, axle counters, etc), communication as well is pretty well solved (802.11 in some cases). The secret sauce is in making everything reliable (think about it, the difference between 3 and 5 nines is a ton of pissed off commutere) AND in making sure everything behaves safely and in a predictable manner.
In more traditional automatic train control setups you divide the track into fixed segments (blocks). One train can occupy a block at a time. Depending on the size of the blocks you may have to keep a block or two of separation between trains. CBTC typically implies what's called moving block. Basically the train is the block. So now you've gotta keep track of all the trains, how fast they're going, how fast they're capable of braking, etc, etc. in order to determine safe spacing and speed limits. It's a bit like automated driving. The algorithms are the secret sauce, and bugs can be fatal. SF's Muni famously had some trains go down the wrong track in the wrong direction during first stages of their CBTC deployment.
Most, but not all of the time. There are dead segments in pretty much any system be it overhead or third rail.
In which case you can assume the cars on those segments are pretty much right where you left them, no? I'm assuming the name of the game is to optimize speed and spacing of cars on active segments.
Or do you mean the cars are basically coasting between segments under flywheel or battery power? Seems like dead reckoning is all that's needed to fill in those gaps. Maybe with a basic anticollision radar as a failsafe. :)
Nope. See Bill Wattenburg's demonstration with BART
I'm not familiar with him, and Google isn't helping much. Any good references?
It's a bit like automated driving.
Except there's no steering wheel, no pedestrians or cyclists, no weather or visibility problems, no uncontrolled vehicle traffic, and every bit of infrastructure is under your control at all times.
Hence my use of 'trivial' to describe the problem. Compared to what the folks at Waymo or Cruise have to deal with, the MTA and its contractors have no excuses whatsoever.
Or do you mean the cars are basically coasting between segments under flywheel or battery power? Seems like dead reckoning is all that's needed to fill in those gaps. Maybe with a basic anticollision radar as a failsafe. :)
Assuming that the train hasn't failed, sped up, derailed, or found another reason to go into an emergency stop. You could make all sorts of assumptions but people typically like their train control systems to fail safe.
I'm not familiar with him, and Google isn't helping much. Any good references?
Literally the first thing that comes up for "bill wattenburg bart" sums up the experiment pretty well.
Except there's no steering wheel
True.
no pedestrians or cyclists
On a subway? Jumpers or aggressors. On at-grade systems? Cars, bicyclists, pedestrians, wildlife, you name it you'll see it on the tracks.
no weather or visibility problems
Weather is a huge issue for BART even underground, and I'd assume that goes more for the New York MTA. Weather is less of an issue now for Muni, but some of the equipment used to mitigate the weather routinely damages the train control equipment. If you're expanding your scope to longer distance rail traffic, look up what British Rail called "the wrong kind of snow".
no uncontrolled vehicle traffic
You'd be surprised what a drunk driver is capable of.
and every bit of infrastructure is under your control at all times.
Ideally. New York is an interesting mishmash of territorial pissing though. See also: Penn Station.
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
That’s the source of a lot of error in project estimates, since it is trivial to come up with plans before considering the details.
Phrasing it as a software project: “I don’t understand why it is so hard to find information on the internet. All of the pages are available through HTTP web servers, aren’t they? What’s wrong with just downloading them all?”
I don't follow you. How is keeping track of the position of a small number of subway cars in a limited geographical area anywhere near as abstract a problem as "finding information on the Internet?"
This is a relatively-trivial engineering exercise with any number of safe, efficient solutions. If someone says it will take a billion dollars to solve the problem, that is the person you should demand proof from.
> This is a relatively-trivial engineering exercise with any number of safe, efficient solutions.
Your comments here are another great example of how ironic it is to hear the word "trivial" used to describe solutions. Don't you think it's a little unrealistic that your "relatively-trivial engineering exercise" suggestions are capable of successfully tackling a problem so many parties have thought about? Have you considered that your insight is actually failing to account for a variety of unknown unknowns you might have about the NYC subway system?
Look at it this way: why do you suppose your suggestions haven't been implemented yet? Do you think the vast array of parties with skin in the game haven't thought of them (and are thus incompetent)? Do you think they simply aren't motivated to implement them?
I wouldn't be surprised if your proposals are technically sound (especially for greenfield rail construction). But I would be absolutely shocked if the problem is anywhere near as trivial as you're making it out to be.
Absolutely fair point. But don't you think there's something profoundly wrong somewhere when cities in all kinds of climates and conditions around the world manage to solve their problems. With the pooled knowledge of all those projects, isn't it likely that the NY project could find solutions there? Presumably sourcing knowledge and solutions and adapting them would in hindsight have been cheaper than developing a system from scratch?
CBTC systems are widely used worldwide.
The best solution is probably for the MTA to buy a system from Siemens or Thales – they have that worldwide knowledge. But last time I discussed this here, I was told funding restrictions meant the company had to be American. Unfortunately for that, this is an area of European expertise.
If that's the case it could explain the problems.. Of course that's moronic because the US isn't known for smoothly functioning public transit systems.
Have you considered that your insight is actually failing to account for a variety of unknown unknowns you might have about the NYC subway system?
No. Whatever the unknown unknowns are, they're not going to be that hard to work around. Keeping track of a few train cars isn't exactly the Manhattan Project, even if it has to be done underneath Manhattan.
The video suggests that the total budget for the CBTC retrofit was in the vicinity of $1 billion. I hope that I either misinterpreted it, or that the budget includes other improvements, because I doubt it cost that much (in 2018 dollars) to build the initial subway routes in the first place.
Look at it this way: why do you suppose your suggestions haven't been implemented yet? Do you think the vast array of parties with skin in the game haven't thought of them (and are thus incompetent)? Do you think they simply aren't motivated to implement them?
I think the vast array of parties with skin in the game have treated said "skin" as a target for optimization in itself. I'll readily admit they're likely better at that game than I am.
How can you say with any confidence that the unknown unknowns you have won’t be very hard to work around? That’s entirely the point of unknown unknowns - you don’t know what you don’t know.
(Shrug) I know how to figure out where some subway cars are and keep track of them for less than nine figures. I don't expect anyone to take my word for it, and I don't care if they don't; it's just an excuse for some meaningless chest-thumping on HN while waiting for Vivado to do its thing. :-P
If I lived in New York and had to pay for it, I'd probably find the question less interesting and more infuriating.
I would encourage you to submit a problem statement with your proposed method to TCRP research program [0,1]. Unfortunately the 2019 solicitation is closed, but the 2020 solicitation will open early next year. A better vehicle tracking method than the current block-level tracking is something that would be valuable to sub-surface transit system in the USA and if what you propose (or something similar) is feasible, the statement stands a real good chance of getting funded for a research project. And if the project is funded, you can even bid on the research work. I'm active on the TBR ADC040 subcommittee, if you have questions, hit me up (my twitter is on my profile) and I'll see if I can connect you to the right person.
I write this in all seriousness - this isn't a "if you're so smart why don't you do it" post, I'm writing this in acknowledgement that there are a lot of smart people on HN, and if there's a chance to improve US transit, I'm all for it.
[0] http://www.trb.org/TCRP/AboutTCRP.aspx [1] http://www.trb.org/TCRP/TCRPOverview.aspx
I hear you, but unfortunately, I have no insights that any random EE (or advanced hobbyist) with some DSP experience wouldn't immediately bring up as well. It's safe to say that anything I could suggest has already ended up in plenty of proposals.
It would be interesting to understand just why this is considered a $100M-$1B problem, though. I'm curious enough to do some more reading.
Please try some humility, for real. This isn't some guy's backyard train model project. This is a 24/7-running subway in one of the busiest cities in the world. Errors that result in shutdowns can cost tens to hundreds of millions of dollars in economical damage. Accidents can take hundreds to thousands of lives.
This attitude you have is the attitude of every single commenter who asks why Dropbox has "so many employees" when they "could build it in a weekend". It shows a huge amount of disrespect for complexity you aren't aware of; and by extension, things you're not aware of in general. It's the same attitude you find in project managers who don't understand XKCD1425 and "just want it done now it can't be that hard". The attitude of anti-vaxxers who dismiss expert opinions to rely on their gut feelings.
I don't know why it's so expensive, I haven't seen the breakdown, but my default reaction will be to dig further, rather than to dismiss people who have worked on subway systems infinitely more than me and casually throw in a "Nah, it's just keeping track of some train cars, nbd".
If you need to replace physical infrastructure, well, that's where the problem is. MTA has about 6500 subway cars. Replacing all of those would tie up somewhere around 10% of the world's total yearly subway car manufacturing capacity.
Okay, so maybe you only design a module that can be retrofitted onto existing cars--there's only 16 car designs on the MTA according to Wikipedia. You just have to install them on every car, which means figuring out how to slot the install times into the maintenance schedules of cars, and if your schedule slips for delivering the parts to install, well, that's going to push stuff back a few months.
The problem isn't that the algorithm is hard. The problem is that the hardware didn't exist, and retrofitting hardware is a much more expensive endeavor than retrofitting software.
Okay, so maybe you only design a module that can be retrofitted onto existing cars...
The cars have to receive power from someplace. Wherever they are being energized, there is by definition a complete circuit to all cars being powered on that line. Likewise, wherever the cars are, there is going to be a large and reasonably well-defined impedance discontinuity on the power rail. So, as a first attempt, I'd look at some sort of reflectometry scheme. Wind a few turns of wire around the cable that feeds the third rail, inject a pulse train with Gold codes or something similar that lends itself to autocorrelation methods, and listen for echoes.
This requires a grand total of $0 in hardware to be added to the cars. If it's not enough -- e.g., if the points raised in Anechoic's post render it impractical to rely on passive reflections -- then it should be possible to add a small amount of hardware at the cars to act as an active transponder, injecting its own pulse train in response to carrier-current signals from the distribution point.
So now we need to connect two wires at each car, and mount a small box with some duct tape^W^W milspec fasteners. Not exactly rocket surgery.
Most, but not all of the time. There are dead segments in pretty much any system be it overhead or third rail.
Nope. See Bill Wattenburg's demonstration with BART.
What if you're not using a third rail?
Basically you seem to have solved the problem under ideal circumstances but not accounted for the myriad of failure modes one will encounter in the real world.
Edit: the other part you're missing is that the first C in CBTC is communication. Locating trains has been fairly well solved (inductive loops, axle counters, etc), communication as well is pretty well solved (802.11 in some cases). The secret sauce is in making everything reliable (think about it, the difference between 3 and 5 nines is a ton of pissed off commutere) AND in making sure everything behaves safely and in a predictable manner.
In more traditional automatic train control setups you divide the track into fixed segments (blocks). One train can occupy a block at a time. Depending on the size of the blocks you may have to keep a block or two of separation between trains. CBTC typically implies what's called moving block. Basically the train is the block. So now you've gotta keep track of all the trains, how fast they're going, how fast they're capable of braking, etc, etc. in order to determine safe spacing and speed limits. It's a bit like automated driving. The algorithms are the secret sauce, and bugs can be fatal. SF's Muni famously had some trains go down the wrong track in the wrong direction during first stages of their CBTC deployment.
Most, but not all of the time. There are dead segments in pretty much any system be it overhead or third rail.
In which case you can assume the cars on those segments are pretty much right where you left them, no? I'm assuming the name of the game is to optimize speed and spacing of cars on active segments.
Or do you mean the cars are basically coasting between segments under flywheel or battery power? Seems like dead reckoning is all that's needed to fill in those gaps. Maybe with a basic anticollision radar as a failsafe. :)
Nope. See Bill Wattenburg's demonstration with BART
I'm not familiar with him, and Google isn't helping much. Any good references?
It's a bit like automated driving.
Except there's no steering wheel, no pedestrians or cyclists, no weather or visibility problems, no uncontrolled vehicle traffic, and every bit of infrastructure is under your control at all times.
Hence my use of 'trivial' to describe the problem. Compared to what the folks at Waymo or Cruise have to deal with, the MTA and its contractors have no excuses whatsoever.
Assuming that the train hasn't failed, sped up, derailed, or found another reason to go into an emergency stop. You could make all sorts of assumptions but people typically like their train control systems to fail safe.
Literally the first thing that comes up for "bill wattenburg bart" sums up the experiment pretty well.
True.
On a subway? Jumpers or aggressors. On at-grade systems? Cars, bicyclists, pedestrians, wildlife, you name it you'll see it on the tracks.
Weather is a huge issue for BART even underground, and I'd assume that goes more for the New York MTA. Weather is less of an issue now for Muni, but some of the equipment used to mitigate the weather routinely damages the train control equipment. If you're expanding your scope to longer distance rail traffic, look up what British Rail called "the wrong kind of snow".
You'd be surprised what a drunk driver is capable of.
Ideally. New York is an interesting mishmash of territorial pissing though. See also: Penn Station.
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.