> Having full-time software experts running the show turned out to be crucial. Previous incarnations of the project didn’t have a technical leader at the MTA—just old-school senior managers who would try to wrangle the contractors by force of will. The new in-house team, by contrast, was qualified to define exactly what they wanted from software providers in terms those providers could understand. They were qualified to evaluate progress. They could sniff out problems early.
I think this is the most important topic in this article. Government projects cost so much and take so long because there is always a disconnect between the institution paying for the work and the institution doing the work. One can’t reliably measure the other’s capabilities and knowledge and so it becomes a murky relationship (one that is also easily exploited by persons on both sides willing to make their paychecks fatter).
As someone who works in the power utility industry - an industry that has slowly moved from monolithic, often publicly-owned monopolies to a competitive market where lots of functions are contracted out to service providers - I feel that a lot of this is symptomatic of that process.
In the 'old days' when we built lots of large infrastructure projects like the New York subway, various energy megaprojects, the interstate highway system, etc. nearly all technical functions were done in-house at the government or quasi-government agency responsible.
Now we have become 'leaner' and pared down many government agencies to project management only (sometimes just business management - projects is contracted out too), but it's not that easy to manage construction of a subway or a 500 kV transmission line if you don't actually have the base of relevant knowledge internally. Suddenly you have 25-year-olds fresh of out of engineering school being christened 'Senior Project Manager' and put in charge of a large, very complex technical project when 40 years ago, they would have been doing basic design and learning their trade as an engineer under the direction of a phalanx of senior engineers. Then we pat ourselves on the back for 'saving' loads of money by reducing headcount in the public sector when actual total cost of ownership has escalated.
The people actually doing the nuts-and-bolts engineering and construction work have no ownership in the project because the second that contractual completion is declared it's off to the next one.
Right now I am working for a power company that refuses to hire its own project or commissioning engineers, instead contracting management, oversight and quality control of its construction projects to a litany of 3rd parties. Unsurprisingly, it means very few if any people in our company have the expertise to understand what's going on when a project is off the rails. The result is endless delays while senior management wrings their hands and brings in yet more consultants to manage the other consultants.
This happens in the Private Sector as well. I work for a manufacturing company with 6+ facilities (two major, third major greenfield in design and 3 minor facilities) We have 3 engineers for the whole company. We mostly just manage the contracted engineering firms. It sucks for me as a "junior" Senior Project Engineer because I rarely get a chance to learn what my contractors are doing, too busy managing them and coordinating. Naturally, in order to be a better PM I need to know their skills at least at a 500' level. Hard to learn to code PLCs when I'm too busy managing 5 PLC programmers on a project for a month or two, then moving onto something else that might not even have a PLC involved.
Early on in my career, a manager of mine told me about his first few years on the job after being hired by Ontario Hydro (at that time the integrated generation and transmission utility for all of Ontario) in the late 1960s. The first two years was pure training and basically an extension of your engineering degree except specifically applied to the typical problems and practices of the power utility.
Of course, in those days a utility job came with a generous pension, a seniority-based career track and an expectation that you would likely retire there, so anything invested in a young employee was just investing in the company itself.
Large engineering employers no longer feel the same social compact with the profession to train young engineers and make experts out of them. Not only do they not set aside time for employees to learn, there often aren't any seniors around for them to learn from because the company hasn't bothered to create a meaningful career track for engineers. It's promotion up to management or stagnation at entry-level pay. With little meaningful prospect of advancement in their technical career and no pension 'golden handcuffs', there's no incentive for employees to stick around. Once they become experienced, they split for the contractor they used to manage, creating a vicious cycle that drains the utility company of talent.
> anything invested in a young employee was just investing in the company itself.
We often discuss the modern lack of perks you listed, but we rarely discuss this consequence.
I recently left a tech company and was surprised when engineering management showed no interest in learning why I had left. It makes sense not to worry about -me-, but why not worry about the workers who haven't left?
I concluded that since places assume you will leave within 3 years (I was at 3.5), they dont really concern themselves with trying to counter that and consider it normal, which becomes a self-prophecy.
> "25-year-olds fresh of out of engineering school being christened 'Senior Project Manager' and put in charge of a large, very complex technical project"
This is so true. I have nothing to say except you are just hitting so many nails on the head.
how is this affecting the quality of the infrastructure that gets built? the TCO for these projects is going up, but is the quality (read: reliability/time between failures) comparable to what you could expect from the older systems?
It's hard to make a statement about average quality without a lot of data, but the total variance in quality is certainly increasing. Owners/companies that have strong engineering processes and standards are still building high quality projects and with the benefit of improved technology, it's much more reliable than circa 1970s stuff.
But there are also a lot of failures caused entirely by project management SNAFUs, poor communication between contractors on a project, inadequate testing, etc. that are completely avoidable and I personally as being largely caused by the diffusion of responsibility that occurs when a company is no longer capable of turning a wrench without hiring a contractor.
This is incorrect. There are plenty of efficient, well run government institutions and projects. There are also plenty of inefficient and badly run (for the consumer) market-based companies.
I don't know. I agree with your statement about market-based companies. But if you could please cite the fabled "well run government institution", it would probably make your statement a lot stronger. I at least have seen quite a bit of DC and I don't think such a government agency exists.
Perhaps not in the US, and perhaps not now. But the first thing that came to mind for me was the Hong Kong MTR, which started as an extremely successful statutory corporation that only later was privatized (and that with dubious results). Same with the Housing Authority in the same territory, which also was well-run until it was privatized and begun to sell off assets to private enterprises that turned the screws on renters.
There's also the more fundamental question of whether a public good like transit should (and can!) be run for profit and at the same time benefit the entire population and economy. It's possible that's only feasible in some cases, not others. (Of course, NY should be able to turn a healthy budget given the population density.. the mismanagement is evident)
I think it's pretty amazing the number of government services most people spend almost zero time thinking about, and yet, benefit from nearly constantly in their day-to-day lives.
I think, in general, this is one of the attributes of a well-run government institution. It just works and it doesn't draw attention to itself unless necessary to fulfill the job.
In my mind, these organizations are so ubiquitous, and so common, that it seems impossible to not identify them. However, the narrative of "government is bad" seems to be so powerfully blinding that I suppose they can be hard to identify for certain people.
The countdown clocks have been be implemented more than 2 years after the OP article came out: "After 11 years, every NYC subway station finally has countdown clocks"
>You want fewer delays? You want realtime countdown clocks? CBTC is the answer
What crap. For nearly 100 years the subway has been just fine, and after 10-15 years of corruption and mismanagement we're expected to believe the only solution is a multi-billion dollar upgrade with technology that didnt even exist the last time the system was functioning properly?
I dont think lack of computer controlled trains is the problem here:
>Signal problems and car equipment failures occur twice as frequently as a decade ago, but hundreds of mechanic positions have been cut because there is not enough money to pay them — even though the average total compensation for subway managers has grown to well over $200,000 a year.
Daily ridership has nearly doubled in the past two decades to 5.7 million, but New York is the only major city in the world with fewer miles of track than it had during World War II. Efforts to add new lines have been hampered by generous agreements with labor unions and private contractors that have inflated construction costs to five times the international average.
New York’s subway now has the worst on-time performance of any major rapid transit system in the world, according to data collected from the 20 biggest. Just 65 percent of weekday trains reach their destinations on time
The subway hasn't been "just fine" for the past 100 years. Up until the '80s disinvestment was the norm, to the point where pieces of elevated track were literally falling on people on the streets below. It takes a long time to correct 50+ years of deferred maintenance, and we're not out of the woods yet.
Fewer miles of track is a legacy of that time period, as subway replacements for demolished elevated lines never came, and then elevated lines had to be demolished because they were a safety hazard.
As far as construction costs go, the problem is actually that the MTA is not involved in construction union negotiations at all, and the firms are more than happy to oblige the unions and pass on the cost to their captive consumer. The barrier to entry for new firms is quite high due to byzantine NYS bidding rules as a result of '20s era reform, and even if you could have a new firm start up they'd be hiring from the same pool of workers; it's not as if specialized construction workers can be hired on visa.
> At the heart of the issue is the obscure way that construction costs are set in New York. Worker wages and labor conditions are determined through negotiations between the unions and the companies, none of whom have any incentive to control costs. The transit authority has made no attempt to intervene to contain the spending.
The main issue is that New Yorkers are extremely cynical and detached from the elections process, particularly on state and local elections which tend to take place on non-presidential years. Ocasio-Cortez and Gounardes showed that it is possible to turn things around if voters are motivated enough, but for the most part they aren't, and party machine politicians on both sides would like to keep it that way.
> is possible to turn things around if voters are motivated enough, but for the most part they aren't, and party machine politicians on both sides would like to keep it that way.
Reminds me of David Foster Wallace...
> “If you are bored and disgusted by politics and don't bother to vote, you are in effect voting for the entrenched Establishments of the two major parties, who please rest assured are not dumb, and who are keenly aware that it is in their interests to keep you disgusted and bored and cynical and to give you every possible reason to stay at home doing one-hitters and watching MTV on primary day. By all means stay home if you want, but don't bullshit yourself that you're not voting. In reality, there is no such thing as not voting: you either vote by voting, or you vote by staying home and tacitly doubling the value of some Diehard's vote.”
> What crap. For nearly 100 years the subway has been just fine, and after 10-15 years of corruption and mismanagement we're expected to believe the only solution is a multi-billion dollar upgrade with technology that didnt even exist the last time the system was functioning properly?
CBTC has been an utter shit show in San Francisco. The transit consultants LOVE it. The riders who get to put up with extremely delicate equipment? Not so much.
> CBTC has been an utter shit show in San Francisco
CBTC is used all day, every day by cities all over the world without issue. I've personally taken hundreds, if not thousands, of trips on train systems with this technology and it works perfectly.
If SF is having problems with CBTC it says a lot more about SF than CBTC.
Interesting video. 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. (For instance, they already have to run power on a third rail, don't they? What's wrong with time-domain reflectometry?)
Seems that using lots of inexpensive redundant sensors would achieve the necessary fault tolerance and avoid frequent maintenance shutdowns. It sounds like they have instead elected to implement a monolithic system with a lot of expensive hardware at both the station and car levels. I guess that's how they (don't) roll in New York.
> 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.
For instance, they already have to run power on a third rail, don't they? What's wrong with time-domain reflectometry
The third-rail is not continuous, not all segments are energized all the time, and a single train can make simultaneous contact with multiple 3rd rail segments. It's probably not impossible to do, but it's also probably not trivial.
The countdown clocks really show the distance to the train, not the time it will take to arrive (it's more correct that it shows estimated time). I.e. it can be stuck at 5 min for 15 minutes. It would make more sense to actually show that distance in addition to the ETA.
The ETA tells the average passenger what they want to know. What good does knowing the distance do you? If the ETA is bad the analysis should be improved. There's little point in encouraging the passenger to try to outsmart that analysis. The designer of the system has much more information to work with.
Sure it would be be nice to supply that information in some open API somewhere though.
Time makes a lot more sense than stops: for example, at Columbus Circle in NYC, a downtown A train that's one stop away is about 3.5 miles out. A downtown 1 train that's one stop away is less than a half mile out. Except if the downtown A train is running local, in which case it's then about a half mile out.
Time, on the other hand, can be meaningfully displayed to a rider no matter what information they already know. (It's also fairly accurate in practice in my experience.)
It's accurate as long as trains are moving. As soon as they are stalled, that time stops reflecting the real one. So showing the distance at least gives a more appropriate info, instead of showing "5 min" for 15 minutes (which is annoying).
Why hasn’t some kid with a couple Raspberry Pies and a laser and sensor guerillaed up how to sense when the train is X distance from some stop and heading this way - with some mailing list of people to text when the train approaches?
I grew up in NYC back when a normal family could live in Manhattan. I always wondered why they didn't suspend service between midnight and 5AM on weekdays for scheduled maintenance. Move half the maintenance people to midnight shift so avoid all the overtime they pay now.
Not mentioned in the article is that the NYC subway system is controlled by Albany, not NYC.
I used to take the F train into the city every day for 2 years back when I lived in NY. That ride is something I miss very much... such peaceful downtime before wifi and all that.
And what decade were you in NYC? Because the F train of the past ten years is constantly overcrowded, delayed nearly every day, and often out of service on the weekends.
We don't need countdown clocks, we need door-to-door commutes at 200kph with no stops or train changes. The Boring Company should be able to drill around and under.
The Subway is like something from a bygone era:
> All track on the New York subway (and on most American rail) is broken into sections, here about 1,000 feet long. An electric current is constantly running in a loop through each section. When a train enters a section, it short-circuits the loop, which allows the system to know that the section is occupied. The signals behind it automatically turn red.
> Fixed-block signaling systems, in use since the late 1800s, keep trains from getting too close to one another. The neat thing about subway signals, as opposed to the ones you find on the road, is that they actually force you to stop. When a signal is red, a footlong metal T called (appropriately) a “train stop” protrudes above the track; each train car has a corresponding “trip cock” on its wheel frame connected to the emergency brakes. If you were to drive by a stop signal the train stop would hit the trip cock and you’d screech to a halt.
Public transport will always be a loss business if you want to serve all areas and not just the rich. Private companies are always going to try to make as much profit as possible, this includes profit over safety if they can get away with it.
What we need is a reorganization of the public transport sector with competent long term planning and the funds to achieve it.
But as long as corruption, incompetence, cronyism and a complete lack of the public willing to pay for it. It won't happen.
Japan's train system is the envy of the world and is privatized. There are at least 10 different companies running public transportation in Tokyo alone. 3 to 5 in Kyoto.
The majority of the NYC subway system was built by private companies, just FYI. The city acquired the privately owned systems in 1940 and unified them into the single system we have today.
The MTA moves 5.5 million people daily, why don't you do the math on door-to-door individual vehicles for all of them? Like, major office buildings can have 10,000 workers in them, and there may be a bunch of such buildings in a complex. Do the math, figure out what sort of station you need to build to let those people arrive at work in the morning in their individual pods.
And the safety devices you describe are what keeps stories like "subways crash, 500 killed" from being commonplace. What exactly happens when a couple of Boring Company vehicles crash in a tube at 200kph? How do you extract them? What happens to them, and what happens to the other 75 vehicles approaching in the tubes behind them at 200kph? Has any thought at all been given to this?
Obviously the scale is huge, but conventional trains have inefficiencies.
Suppose the average rider's trip is 10 stops. At every stop where the rider does not get off, there is inefficiency because they sitting there, taking up a seat on a train that is stopped. You're not only wasting their time, you're also wasting train capacity.
The naive solution is to make the train longer. Which works, but it's costly because you also have to make the platform longer. In a subway system, that's expensive. And the worst part is, you have to do it for every station the train will stop at, even the ones that aren't as busy.
This is, of course, why express trains exist. Eliminate some stops and you reduce all these problems. But the more stops you eliminate, the fewer people can use the express (because it doesn't stop where they're going), so there's an unavoidable compromise.
In the days before automation, this was probably the best that could be done. But now that automation exists, new approaches are possible.
Since you no longer need a driver per train, you now have the option of making trains smaller. And it's also possible to group people together by starting point and destination. So in theory you could make every train an "express train", one with zero stops other than starting point and destination. No seats wasted on making people wait in a non-moving train while others get on/off. So you can eliminate an inefficiency that you never could before.
Of course, every train needs headway for safety reasons. More smaller trains instead of fewer larger trains means that's harder. So it's not without its own, different limitations. Maybe automation has fast enough reaction time (or other tricks) that can cut down on the physical space needed for headway.
Anyway, the point is that much smaller vehicles might actually increase efficiency, and this is what the Boring Company seems to be planning to do.
On a fixed guideway system--that includes vanilla railways and things like monorails--a train that is stopped completely blocks the entire track, and cannot be routed around except via switches. The minimum headway between trains is dominated by switch fouling: how long it will take a train to pass over the switch, and then for the switch to switch to a different track, before the signal can go green again. You'll also want some extra padding on top of that for timetabled trains, to take into account unexpected long station dwells and schedule recovery.
The throughput of most subways is about 26 trains per hour. With good signalling and track management, you can push it to about 36 trains per hour on a branched line; an unbranched line (which simplifies management a lot!) can get up to 45 trains per hour, but those are definitely not typical numbers. Train length doesn't impact these numbers much, definitely not at the scale of variation being discussed.
Express trains require dedicated tracks to be able to bypass parked trains, or insanely good timetable-keeping to not get stuck behind a local train before a bypass. NYC built a lot of its trunks to 4 tracks, which allows it to make local/express trains, but most systems have found it's easier to just build another 2-track trunk a few blocks away than to try to add 4-tracks to the 2-track trunk.
The idea of trying to use tiny cars with much narrower safety margins for headways is the idea behind personal rapid transit, but PRT systems have been shown to have utterly lousy throughputs: pulling 10,000 people/hour on a trunk PRT line would be a significant milestone, whereas the standard 8-car train on a 26TPH subway easily pulls 25,000 people/hour without needing much effort.
26 trains an hour is pushing it hard. The London underground generally runs at about 24 TPH at rush hour on a single line (in each direction)
If you go to a moving block signalling system you can push the system a bit harder, but the problem is that as the trains get more crowded, their braking distance increases (which increases the block size - so fewer TPH). Also, at rush hour the dwell time at each station increases because more people are getting on and off - again impacting the headway.
> The London underground generally runs at about 24 TPH at rush hour on a single line (in each direction)
Not quite. All of the resignalled lines manage more than that. The Central line reaches something between 27 and 30 tph, the Jubilee Line 30 tph (and I think there are still plans to go even higher) and the Victoria Line 36 tph. The Northern Line is a bit special because of its branching, but the single section south of Kennington towards Morden manages 30 tph as well.
And even the Subsurface Lines (which for the largest part are still conventionally signalled, although not for much longer) manage around 27½ tph on the north (Baker Street - Aldgate) and south (Tower Hill - Gloucester Road) sides of the circle.
> the problem is that as the trains get more crowded, their braking distance increases
A properly designed brake system will
a) be designed to achieve the required deceleration even under maximum loading
b) include load compensation, i.e. the braking force for each car is adjusted depending on its loading to achieve the same deceleration
Basically, I see three ways of looking at what Boring Company is trying to do:
1. It is being built by people who don't know what they're doing and don't understand the field, and it isn't going to work. (This seems to be the way you look at it.)
2. They expect to be able to reduce the costs of tunneling so drastically that the lower throughput of PRT won't even be a problem.
3. They plan to use an unprecedented level of automation to advance the state of the art in how PRT can be done. (This is my guess.)
Obviously, nobody really knows which of the above is the case. They haven't shared a lot of detail.
But in support of the idea that it _could_ be #3, there's a reason I think there's room for innovation in PRT. It's so expensive to build any transit system that relatively few attempts have been made at PRT. And some things have changed since many of those tries, mainly advances in automation. So for example, if switching is a bottleneck for headway, maybe there is a way to build a much faster switch but nobody has put the R&D money into it yet.
> The minimum headway between trains is dominated by switch fouling: how long it will take a train to pass over the switch, and then for the switch to switch to a different track, before the signal can go green again.
The absolute minimum spacing between two trains running non-stop one after the other perhaps. Unless you imagine a system where at each station the line splits into two or three separate tracks, for all practical purposes however the actual limiting factor will be stations, as the combination of platform reoccupation time and dwell times will significantly larger than switch fouling time alone.
> Maybe automation [...] can cut down on [...] headway.
Indeed. One can think of a BC tunnel as a narrow rail tunnel containing a single highway lane. An express lane restricted to networked self-driving non-truck vehicles. Headway buys fewer vehicles sharing the damage and acceleration of a lead accident vehicle's decel - because with networking, they needn't ever exceed it. One might literally do full-speed bumper-on-bumper.
It's a really pretty point in design space that the Boring Company is targeting. But the commentary I've seen has pervasively been confused. Which may be for the best - industry disrupting startups are often better off remaining disregarded for as long as feasible.
> Indeed. One can think of a BC tunnel as a narrow rail tunnel containing a single highway lane. An express lane restricted to networked self-driving non-truck vehicles. Headway buys fewer vehicles sharing the damage and acceleration of a lead accident vehicle's decel - because with networking, they needn't ever exceed it. One might literally do full-speed bumper-on-bumper.
How do you do stations? If you have the station on the mainline, your entire train of vehicles has to stop at the station just like, well, a train, so what you have is just a less safe version of a train. If you have turnouts for stations, you have the issue of switch fouling preventing you from bunching vehicles too close together, and high-speed turnouts have to be long to deal with turn radii. But the real killer with turnouts is trying to get a train to merge back onto the trunk at speed--with little-to-no space between cars, a slight mismatch in speed is going to equal a high-speed collision.
> How do you do stations? [...] high-speed turnouts have to be long to deal with turn radii [...] to get a train to merge back onto the trunk at speed
It's a highway. Paying with tunneling to avoid surface real-estate constraints. And needing fewer lanes for similar throughput due to density and speed. With minibuses. That are self driving. And don't have to worry about human drivers. And can be street legal.
So how would you do X? Well, how would you do it now, with a highway and minibuses? What if you could restrict it to networked automated minibuses? What if they were tightly integrated with infrastructure?
So for stations? Now: highway ramp to/from a lot, platform curb, or street. Automated: similar, but with tighter non-human margins. Integrated: so many possibilities... including elevators?
Consider a subway station. A short station. For a single minibus. Minibus and mini platform and elevator. Everyone gets off the minibus, crosses the platform, and gets on the elevator. Platforms are expensive. Why have a platform? Ok, so minibus and elevator. Everyone steps off the minibus, directly into the elevator. But the minibus isn't all that heavy, so why craft an extra human space? Ok, so you could have the minibus get on the elevator. At the "top", of ramp or elevator, in a mall, or lobby, or platform, or garage, or street, the minibus could play elevator cab, or PRT, or kiss-and-ride Lyft, or lot rideshare, or neighborhood minibus trundling off down the street. And continuous elevators for tightly-integrated automated vehicles could have surprising throughput. The artist sketch[1] of a point-to-point Chicago-O'Hare station has them playing PRT.
The Boring Company is planning multipassenger pods, you'll learn more next week. Capacity planning would be more similar to elevators than subway stations. Stations would be in the building basement levels.
Those hardwired safety mechanisms certainly work, but are primarily needed to overcome human error. We're all willing to fly on planes with autopilot, and self-driving vehicles in tunnels will be safer.
Elon is talking about building 30 or more levels in dense cities. A guy who lands rocket boosters for reuse has certainly thought through the details of an underground transportation system.
You can't just appeal to Elon Musk assuming he knows all and has figured this out.
Have you ever travelled beyond the US and seen an international subway system? I haven't travelled much but there are some amazing systems out there. Japan had 130mph bullet trains in 1964, can you believe that? They're maxing out at 375mph with levitating trains now, and they actually exist unlike Elon's ideas. Why do you give ideas more credit then something that already exist and work brilliantly?
Last year Japan Rail issued an apology because one of their trains left a station 20 seconds early [1].
Even in my town of Sydney, with huge suburban sprawl, we have beautiful, quiet, air conditioned, double decker trains that go to most suburbs and cost $1.50 to $4.
The future has already arrived, the US just doesn't have it yet.
New Yorkers don't have to cross an ocean to see good transit. Even closer to New York at just a day's train ride, the third busiest North American transit system is Montreal.
https://en.wikipedia.org/wiki/Montreal_Metro
I was recently there to visit - the metro is beautifully efficient, on-time, clean, and frequent. Trains every 4 minutes during work hours like clockwork. Connected to an extensive underground pedestrian network downtown, and frequent bus service outside of the core (even on Sundays).
And an unlimited weekend pass valid on both the bus and metro was only ~13 USD.
Yes I lived in Japan for a few years and love the transportation system there. The shinkansen is wonderful, but the hyperloop will be substantially faster in door to door time, because hyperloop cars will also transit the local loop system.
Most transportation systems are not designed to optimize door to door time. Even by express train, it's a long trip from Narita airport to Tokyo.
> A guy who lands rocket boosters for reuse has certainly thought through the details of an underground transportation system.
Landing rocket boosters is about a thousand times easier than underground transportation.
Reusable booster tech has existed since the 1960's. It wasn't developed further for two reasons:
a) It's massively wasteful because you have to carry the fuel for the return trip.
b) The boosters need to be refurbished afterwards anyways, which is actually more expensive than building a new rocket. (More ways to screw up and less leeway for economies of scale and standardization.)
As far as I know, Musk hasn't solved these problems and isn't even planning to.
I think this is the most important topic in this article. Government projects cost so much and take so long because there is always a disconnect between the institution paying for the work and the institution doing the work. One can’t reliably measure the other’s capabilities and knowledge and so it becomes a murky relationship (one that is also easily exploited by persons on both sides willing to make their paychecks fatter).