The MTA’s latest projections for the rollout of the fare-payment system that will replace the MetroCard.
Now that the MTA Board committee materials officially recognize that the 7 line extension won’t open until at least the 2nd quarter of 2015 (something we knew last month), we can move onto another project that is oft- and again-delayed: the MetroCard replacement. According to the latest Capital Program Oversight Committee materials, the MTA’s next-gen fare payment system won’t be ready until 2020 if all goes according to plan. Systemwide rollout won’t wrap until 2022 under the current schedule.
I’ve often said that the MTA’s latest technological advances are always five years away. Through the right circumstances, we finally get to enjoy countdown clocks on the A Division trains and BusTime through the city, but it seems that the MTA keeps promising B Division countdown clocks in “3-5 years” and has been for longer than 3-5 years. The MetroCard replacement meanwhile has been five years away from nigh on five years now. And the clock is ticking.
With the current MetroCard technology, now well over 20 years, the MTA faces a sunset date. After or around 2019, the cost of maintain the current MetroCard infrastructure will spike as maintenance contracts expire and parts grow harder to find. Thus, there has been some urgency surrounding the 2019 deadline for the introduction of a new fare payment technology. Various stops and starts, driven, in part, by rapid turnover atop the MTA, have delayed the project, but as Michael DeVitto discussed at my Problem Solvers session last March, the MTA is on track to do, well, something within a few years. Now, however, the timeline is slipping.
According to the latest Board documents, the MTA is gearing up to pass a major milestone in its efforts to find a replacement for the MetroCard that can serve for the next few decades. The new solution has to be integrated and adaptable with a contact-less payment system and a new backend for payment processing. By the end of next month, the MTA expects to wrap the business requirements development contract and will issue an RFP in late winter. The MTA expects to award a contract in mid-2016, and a deployment timeline takes shape from there.
According to the MTA docs, system design will run for 13 months and back-end development for two years. Contactless readers will then be installed in buses and subways over the following 21 months before vending machines are outfitted throughout the system. Much like the MetroCard’s initial rollout, the MTA expects to bring the entire system online within three calendar years at a cost of $450 million. But we know how reliable those cost estimates have been in the past.
These are positive concrete steps, but the problem is that Transit has to keep the current MetroCard system up and running until system-wide rollout is complete. In essence, the agency has to run and maintain two systems — one three decades old and one brand new — at the same time, and since the new system is now scheduled to be online after 2019, the MTA’s costs are going to jump. In fact, an Indepdent Engineering Consultant notes that the budget “may not be adequate” when considering the costs of maintain the MetroCard system in a state of good repair beyond 2019 and through 2023.
So where exactly does this leave us? The MTA is still five years away from a replacement for the MetroCard, and it seems nearly definite that they’ll miss their own 2019 deadline by a considerable margin even if all goes according to plan. This is unfortunately a common theme with technological upgrades and a challenge the MTA faces in convincing politicians it deserves $32 billion to improve the system. They need to deliver something at some point, but five years away is a frustratingly shifting target that seems to remain perennially five years away.
44 comments
Anyone know what PATH is doing with their vending machines?
Missed schedule. Missed budget. Again. What clowns.
One of the real problems if you think about it is scope. You have 6000 plus busses, at least 800 turnstyle arrays, 200 plus commuter rail stations & numerous venders & they all need to be unifed. That’s no excuse for the MTA as they drag there feet as L. A., Chicago & others have the transition.
That’s not very much planned out over a few years of regular maintenance and replacement. Probably a small deviation from work they do or need to do anyway.
AFAIK, there is one vendor (Cubic) who designed and implemented the MetroCard system and commuter RR TVMs. We should wish they had numerous vendors employing open standards. But that’s probably too much to ask.
the Metrocard machines were on Windows NT 4 years ago when i saw a few of them BSOD’d. don’t know if the software works on later versions of windows, but linux is the same way. if they had used linux originally it’s not like you can just upgrade it and everything will continue to work.
at some point you are going to be using proprietary POS software that links to a proprietary payment server and that will be your limiting factor.
You’re confusing open source and open standards. That somebody should be able to re-implement a process without reverse engineering is important. Using this platform or that platform is not.
I’m sure Linux could work fine, but it might not be the most obvious alternative. Linux development targets recent hardware, not crude yet reliable industrial hardware. We’re talking about a job DOS could do well.
is DOS going to support IP v6?
http://www.trumpet.com.au/inde.....river.html
I would guess the FreeDOS people eventually will as well.
Not that I see any compelling reason to support IPv6, unless you think the MTA has need to network more than ~4 billion devices at once?
Mainstream Linux development tends to focus on newer/faster hardware, but Linux has been ported to tons of lower-end and more unusual architectures, and has a healthy presence in the embedded world. For instance, a few years ago I was flying on an airplane, and the seatback entertainment system crashed. It promptly rebooted, but for a few seconds I got to see a very familiar sight: Linux boot messages… ^^;
[I myself have ported Linux to an NEC processor architecture which is basically only used in embedded applications (I think their main market is car control electronics)…]
I still do not understand why the MTA is trying to reinvent the wheel again. Contactless payments has been in use in Boston for at least 7-8 years, DC also has a system that works well enough, the one on PATH seems to work OK. I am sure there are other smaller systems in the US that also have this thing figured out. I am all for competition driving the costs down, but the baseline requirements should be equivalent to Boston’s Charlie card, so that the MTA does not need to invest in the development of new technology, but only in the physical plant. That way if someone can do better on cost than whoever is supplying Charlie in Boston, then great — the MTA and we get to save some money, if not then we can get a system from their supplier that actually works. If the MTA decides to “invent” a new system, I am ready to bet anyone that the timeline that Ben discusses is too optimistic. They will get bogged down in software issues. Every big project these days does experience software related delays, so the best thing is to get someone else’s software which has been mostly debugged and cleaned of issues and proven in the field. The examples of the projects getting in trouble due to software are numerous: Obamacare, F-35 fighter, Citybike and so on.
they will have to run both systems at the same time for half a decade. on buses it means your machine has to accept both forms of payment.
The only reason this is an issue is because Metrocard is held together with sticks and chewing gum at the moment. When Chicago moved from TransitCard to Chicago Card, they supported both simultaneously throughout the life of the Chicago Card, I think. Now that Chicago Card is gone and Chicago is on its second full version of contactless payment, it’s amazing that New York hasn’t even BEGUN.
Yeah Ventra had a bumpy rollout, but they got it working.
Aside from LA’s fleet of buses, Chicago probably is the only comparable system in the US, and they’re on their second generation since their “Metrocard”.
running a project like this for 15-20 years before planning a new one isn’t unheard of. a lot of this stuff was leading edge tech when it was first developed. i’d rather the MTA wait and use more mature technology that we can be sure is easier to upgrade piecemeal in the future
TriMet is facing the same issue in that do you follow ORCA in Seattle a closed loop system or do you follow the CTA & have one that is open sourced. They are going with the latter since they believe that the closed loop is outmoted technology.
The system at PATH does just that. It’s got a reader for swiped Metrocards, and a contact reader for the SmartCard.
PATH installed these a few years back, and it is generally much faster to enter the fare areas, plus it’s faster when refilling the card at the TVMs.
I think that the part where they handle different kinds of payment is not that terribly difficult; they just need entry/exit ‘ways that accept various modules – with different modules for each payment type, obviously including current farecards as a type of module. In pase 1, convert or replace existing entryway hardware with models that have available slots for alternate payment means like cash, credit, contact(less), retinal, DNA or whatever – just some black box with a customer interface input and a standard OK-to-Enter output. As you develop whatever back end the new systems require, you can phase in whatever new payment method(s) you want to accept, or just try out, by plugging appropriate modules into those available slots.
The harder parts involve building out whatever data processing and communication infrastructure you might need to provide essentially instant ratification of very large numbers of nearly simultaneous transactions; probably requiring some seriously big iron computer power and lots of wiring.
Unless an off-the-shelf system comes from a comparably large system like London, the software may have already been scaled up to the edge of its original design limits to reach Boston, DC, LA or Chicago size and be ready to collapse if further expanded. Starting from scratch is not always a terrible idea, if the people involved have the appropriate experience.
Deciding what to do seems to be the hardest part – especially if the slate of possible solutions change faster than than they can be analyzed and otherwise politically processed. That’s one of the benefits of the modular gateways; one can hope that whatever new payment methods evolve, they can be fitted into their own modules and added into the already chosen system as you go forward.
big iron and brawny telecom links from 1993 are what you have in the broadband router under you desk now that also is your wireless access point. It’s so cheap your broadband provider gives it to you or charges a nominal rent on it. the new telecom manager and telecom link they need for the new payment system is going to be extraordinarily powerful compared to what was rolled out for MetroCard and the telecom link is going to extraordinarily wide for 1993.
I’m sure that there will be lots of processing power and lots of bandwidth, etc., etc., etc. in whatever they build; probably more power in a single faregate than all of the missions to the moon put topgether and I think they will need it (and will probably need more than they thought they would when all is said and done). As minuscule as things could be if made by hybrid Swiss watchmaker/Silicon Valley geeks, in the real NY subway, there will probably be a closet or two in each station filled with electronics and wiring to channel the data to the central whatevers over trunk lines they create. As little as one might want to route all this data through the subway I think you would like using the public airways/internet even less.
Sure, computers get smaller outside and bigger inside and everything is better than it was yesterday, but all the extra capability gets used up at least as fast by multimedia outputs and ever more complicated operating systems and generalized programming and whatnot so that by the time big brother decides that your MetroChip is paid up and has not been hacked by terrorists, 3 people might have gone through the turnstile using tokens. No matter how much power and speed you think you have in your system, it will be next to impossible to keep up with people’s expectations. Going with overkill at least gives you a chance; going minimal probably won’t survive the beta testing unless you put the MetroLink into a really good designer earring.
The presentations will be full of promises for the future and other big talk, but when they get right down to doing it, they will be afraid of looking like stupid idiots 5 years down the road by including features that are ‘so yesterday’ not including the ‘today’s new big thing’, so they will design as minimal and feature-free a system as they think they can get away with (and still have trouble getting it to work). The only way someone can get a career boost out of working on this project is to leave just after the contracts are awarded.
The time it takes to process that kind of transaction gets processed by EZPass readers on cars whizzing by at 55 mph. It doesn’t require a whole bunch of multimedia. And the beep is two bytes if that much. The beep your computer makes while it’s booting up, if your computer still does such a quaint thing, is the Ascii character for “bell” whatever that is. all seven bits of it. I’m not in the mood to go look it up.
DC’s Smartrip is 15 years old and is in the process of being replaced. It has many of the same problems that the metrocard faces – mainly obsolete parts and software. DC is currently testing their next system at a limited number of stations, which sounds very similar to what NYC wants to do. It’s not just simply about “contactless payment.” It’s the ability to work with smartphones, credit card chips, etc.
Completely insane. I think NYC is the only major US city left without a contactless system. Chicago, the second largest subway system in the country, is on its second version already and is close to pay-by-phone. SF, Boston, DC, Miami, LA, Atlanta have all had them for years at this point. Even Philly is ahead of NYC on this and I can’t think of a more dysfunctional system. What the hell, MTA?
Go to Toronto. Not a US city but they’re still using TOKENS and scratch-off cards.
We’ve been over this before, but I don’t think tokens are so bad. Still works fine in Philly.
Sloshing them around costs a lot of money versus sloshing electrons around.
SEPTA in Philadelphia is only “ahead” in so far as they’ve planned to skip straight from tokens to contactless. As of now they’re still using tokens and are generally worse than the TTC, MTA, anywhere else in most regards. (E.g. there are no ticket machines at commuter rail stations, so when the ticket windows aren’t open you have to pay the higher on-board cash fare ’cause there’s no other way to pay…)
Not to mention the multi-ride card which has to be punched by hole puncher by a station agent (at least as of two years ago).
Am I misreading the image, or are they going to wait an additional 2 years before actually selling the new card?
figure the first two years it will be for early adopters and only refilled over the internet or via phone as they work the bugs out
Can they go back to the token for a few years?
The part that annoys me the most is that they’re planning all this roll-out without any discussion of what mode of payment they’ll actually use. Are they going to graft a contactless system on the current line-up-like-kindergartners-and-pay-the-driver bus model? Or the early-20th-century-show-all-your-tickets-to-one-of-three-commuter-train-conductors-on-board model? Or do they intend to roll out proof-of-payment across the buses and suburban lines? This seems like a more important question than what vendor they’ll use, when they’ll do it, etc.
Given the outcome of recent contract negotiations, it seems unlikely they are even considering changing any of that.
At least contactless speeds up the bus boarding.
If you have contactless readers on surface transit, you can easily implement proof-of-purchase systems. In San Francisco, you board from any door, tap, and sit down. No need to carry receipts, etc.
I don’t know if proof of purchase works in the subway, but it ought to be implemented on buses. Once you have a contactless system, you’re already there, you just need 1-2 more readers. What an improvement this would make on the buses!
Could, but methinks won’t. They’re too obsessed with making sure everyone pays, even if it costs more than losing a few fares.
Well, I hope I’m wrong.
You’d think the union would get behind this, as it would remove any pretense of the drivers being responsible for enforcing payment, except those who board through the front door. Safety, and all that.
Yes, I’m rather amazed they don’t lobby for it. They seem to love the idea of protective barriers, but getting them entirely out of enforcement duty seems even better.
They seem to be fine with doing it on the SBS busses. Additionally lots of low-height turnstiles have been installed at unstaffed subway entrances to speed passenger flow.
How about they start by just buying the PATH machines and putting them in all the downtown stations?
Too efficient, can’t do it.
What are the chances of NFC implementation so that we can pay with our phones?
Optimistically? As NFC continues to penetrate the market and most recent smartphones (including noted petulant late adopters: Apple, Inc.) already enjoy full NFC functionality, you could with some sanctioned hacking have contactless on your phone that interfaces with the existing systems today.
But this is New York. Realistically? 0%.
I have a wallet that doubles as an iPhone case, and I keep my PATH smartcard inside this wallet so I just need to pass it over the turnstile to enter. Every time I do that, the Apple Pay interface pops up on the phone.
I’m assuming that indicates some sort of technical compatibility, but is it worth it for the PANYNJ to roll something like that out? It wouldn’t make my commute that much easier, and I’d rather see them spend the money on more marble platforms or redundant trains to EWR. :-/
As for the MTA, if we’re talking 5 years, who knows where payment & security technology will be at that point. They may give us NFC with our phones but we’ll be asking for DNA scan payments.
To run ten car trains between Newark and the World Trade center they have to lengthen the platforms at Grove Street and find someplace to store all those extra cars off peak. ( they lengthened the platforms at Exchange Place when it was closed because the World Trade Center station was closed and lengthened Harrison when they rebuilt Harrison. The platforms at Newark are oddly very long already. And it won’t be a problem at Journal Square if they already haven’t done it and nobody noticed or they were ten cars long since they rebuilt Journal Square a long time ago. ) The place to store those cars is out at the airport. Since they have to go out to the airport anyway they might as well do that as revenue moves between Penn Station Newark and the airport. That little tidbit gets lost when people write about PATH to the airport.
Could this be due a dream to run payment verification over their new bus communication package.
It’s absurd that so many systems around the world have contactless payment that works, and has worked for years, that the MTA is looking at five years of development, testing, and installation instead of asking all the vendors who currently have fully functional systems in place around the globe, and asking for bids to do a full implementation NOW.