This weekend, I did something I haven’t done in years: I went to camp. This wasn’t my old sleep-away sports camp or the baseball camp I attended for years in the early 1990s. Rather, it was OpenPlans’ Transportation Camp, an unconference that gathered many of the sharpest minds working the transit and transportation space working on the side of the country.
Now, the very idea of an unconference makes people raise an eyebrow. Shouldn’t conferences be structured with set agendas and leaders conducting the pace of things? In a society driven by open-source development and collaboration, a transportation unconference is an ideal format for people to meet and greet each other while bouncing ideas around. I met many readers there and many folks I read elsewhere. While San Francisco gets to enjoy a West Coast gathering next week, I’m already looking forward to next year’s event in New York.
The sessions — which are listed here — were uniformly interesting. I sat in on a Q-and-A with MTA COO Charlie Monheim and US DOT’s Giovanni Carnaroli and Peter Appel. I met the gang from Greater Greater Washington, listened to a presentation on subway signaling and the PA/CIS system and checked out a discussion on matching service with demand. Other sessions — including those on taxi cab applications, road pricing and congestion alleviation — drew raves, but unfortunately, I couldn’t be in more than one room at a time.
Throughout the weekend, the theme was clearly the interaction between technology and infrastructure, and although I missed most of Monheim’s keynote speech due to the MPRE, he hit upon a theme that bears discussion. While the MTA’s data leads itself quite easily to app development, there is an inherent incompatibility between the MTA’s system and technological investments. Last week’s stories on the supposedly obsolete fiber-optics network and the NYPD’s communications problems highlight that gap.
Essentially, this conflict boils down as such: When the MTA purchases rolling stock and upgrades its physical plant, it expects its equipment to last for decades. Subway cars, for instance, have a shelf life of around 40 years before they’re up for replacing, and in the interim, it’s possible that hundreds of newer and better models have hit the rails since then. For better or worse, the same is true for major station renovations, signal upgrades and rail replacement projects.
Meanwhile, when I purchase a new piece of technology, I expect it to last for four years, and I know it will be painfully obsolete by the time those four years are up. My laptop isn’t meant to last 40 years, and the technology behind it improves too quickly for it stay usable much beyond half a decade. For example, the software powering the R160 FIND displays will be obsolete long before the rolling stock is ready to be retired; in fact, the FIND displays have long since passed technological middle age. How then does a transit agency as extensive as the MTA incorporate rapidly-changing technology into a system built for long-term durability?
This conflict is one with which the MTA must grapple on a regular basis. Take, for instance, the BusTime project. As the MTA moves forward with bringing the technology to more than just the B63, those behind the initiative are eying all 800 of Staten Island’s buses, and they hope to retrofit the buses and get the system up and running before the end of 2011. With over 6000 buses operating throughout the city, it’s not a surprise then that it takes a few years to get these wide-reaching technological initiatives up and running.
From Transportation Camp, then, I drew the conclusion that transit agencies face two tasks when it comes to technology. They must make sure that the data these innovations produce gets into the hands of developers who can bring it to the public, and they have make sure that the innovations are compatible with infrastructure that will outlive the technology. What will happen to the countdown clocks in 10 years when they’re due for upgrades? What happens with those FIND displays as they age?
We scorn the MTA’s on-again, off-again attempts to bring technology underground, but ultimately, it’s just not as easy as plug-and-play. As long as the developers have access to data though and the authority is willing to share the real-time information it produces, the public should benefit.
16 comments
The FIND displays have been obsolete since day 1. By that I mean that five years later individual display boards *still* crash and get stuck on some stop, often confusing the dumber customers to the point of outright panic and confusion. Anyone who rides Jamaica Yard’s R160s (E, F, occasionally R) will know what I’m walking about.
The MTA in general is slow/scared with technology. In 1960 they implemented a *fully* automated train signal and control system on the Grand Central Shuttle that worked extremely well until a fire destroyed it and the project shelved. Ten years later BART and WMATA would have their entire fleets running on ATO systems. The R44/R46 P-Wire and Rockwell truck (R46 only) fails scared them away from advanced technology and back to SMEE for the next 20 years. The R62 was basic but was at least light-weight, while the R68/A is a slow whale. Even with the grossly overweight R160, they still struggle with technology. There’s the tensions between transit and technology, but the MTA takes this to a whole different level, sadly.
Combating obsolescence in physical plant is not easy, especially in a large public organization. Failures with experiments and pilots can make it hard to go with something new for a while. It really takes high level sponsors, who are willing to stick their necks out, to push for it, see it through, and make sure it works.
The 20yr rail car rebuilds do help by giving an opportunity to include new technology. Whatever it does (with capital refurbs or new builds) it should be modular and open sourced as much as possible. There is also the issue of scope creep in technology and projects. Where possible, a focus on modularity and growth space, in the initial design, should allow for spiral development to fulfill needs, and add new features as they arise. The JDAM unit is a prefect example. A gps guidance unit with for dumb bombs with extra slots empty for upgrades and updates.
Do the NTT have self steering axle trucks? If not, that should be considered on any new acquisition and rebuilds. They greatly reduce rail and wheel wear, and reduce noise on sharp curves.
“In 1960 they implemented a *fully* automated train signal and control system on the Grand Central Shuttle that worked extremely well until a fire destroyed it and the project shelved. ”
Everyone knows union radicals set the ATo system on fire.
As with the HVAC systems on the NTT cars from the R-142 and up, the MTA needs to make sure the new technological advances are as modular as possible. That way, like the heating/air-conditioning units being lifted out for repair and replacement, the key parts of any computerized system, whether it’s the FIND units or the countdown clocks, can be updated and replaced within their current housings, as opposed to a total redesign that is unable to use any of the current displays or fittings.
The FIND system in itself is not bad. It may be obsolete, but when it works it’s a wonderful system. The issue is the vendor for the software didn’t do a very good job with getting it to be stable. It’s incredibly disappointing to see them still fail 5 years after the R160’s debut.
I don’t know that I would call FIND obsolete (although they do malfunction occasionally). It’s supposed to show route designators, upcoming stops, and occasional PSA’s, which it does. Does the fact that it doesn’t show weather and entertainment updates – like the PATH PA-5’s, make it obsolete?
Those upgrades can be done by an advertising company who would replace the screens and the software that controls them.
Obsolete in my mind means two things
1) The product no longer does what it needs to do
2) Parts are no longer available
My dad uses a Windows xp system that is from 2001. It had windows ME when new, I loaded it up with memory. For basic web surfing and word processing it is just fine. Some would call it obsolete but it does what it needs to do
As for the MTA’s fiber network. As long as they left space for new fibers and upgraded OPTICS they can add new features to it. ATT is using Fibers laid down in the late 1990’s with upgraded OPTICAL proccessors.
Just do be clear: Obsolete doesn’t mean it can’t do what it’s meant to do. The FIND displays can do what they’re meant to do but they can still be obsolete at the same time because the technology is out of date.
Hire a different vendor and replace the software.
This is why you do not use proprietary software or undocumented hardware. If you have the right (open-source) licensing, you can simply hire somoen else to rewrite the software for you so that it works.
Agreed with John-2’s call for modularity. Making the software largely independent of the hardware is part of that modularity and best done by avoiding proprietary software.
Speaking of technology, I’ve just found a two week old article on Railway Gazette saying that Oyster will remain the sole choice for season tickets in London, and the credit card-based system will be used only for pay-as-you-go travel. Can you confirm or deny whether this will be done in New York, too?
I can’t do either. I think it’s too early in the MTA’s planning/RFP process to say for sure. I think their idea is to eliminate any reliance on MetroCard technology, but they’ll still be offering some version of a fare card for those who don’t want to use or don’t have a credit card.
Oh, I’m almost certain that they’ll eliminate the swipecard. What I’m asking is if you could use PayPass for unlimited monthlies, or if they’d follow London and reserve the unlimited monthly for a separate card.
The weather updates would be useful. I suppose obsolete may not be the word I’m looking for in describing FIND. The technology has been here for five years and still malfunctions (quite often on the F train). By now I hoped the bugs would have been worked out. Anybody here know what causes the malfunctions? My first guess is memory or third rail gaps.
The countdown clocks can be 100 times better programed than they currently are by the MTA. They are all made by telecite. Look what the telecite display does in its native home, notice the fonts are the same as for the MTA. The cartoons are amazing for a 1980s LED display technology.
http://www.youtube.com/watch?v.....re=related
For stuff like countdown clocks and displays in the trains, use open-source software which you can edit in-house.
Hardware will become obsolete, but there’s no reason for software to also become obsolete. (Except for safety-critical software, obviously.)