Back in November, Bruce bashed RapidRide for having neither a published schedule, nor real-time arrival board, nor real support in OneBusAway:
I don’t expect miracles, but I do expect Metro to deliver this service at a level of quality that befits a premium, flagship service. The status quo of no schedule and no OneBusAway on the C & D Lines — more than six weeks after the start of service — is an intolerable embarrassment to the agency and is corroding the RapidRide brand.
All these points are valid, and thankfully Metro has corrected the situation. But that just calls into relief the outrage that Link, a few years older and with an order of magnitude more capital investment, still has nothing but an onsite two minute warning.
Fortunately, a new research project provides some hope that ST will find a solution in the next few years. Last July the Sound Transit Board appropriated funds to a new research & technology program known as “Regional Data Services.” Yesterday I spoke with Michael Berman, the Program Supervisor, who told me the prospects of getting what we’ve been waiting for all this time.
All below the jump.
Phase 1 will cost $9m and run through early 2015. The staff report lists the many research subjects, but here I’ll focus on the real time elements.
The first activity is that Sound Transit is assuming responsibility for One Bus Away. The existing contract with the University of Washington expires on May 15th, and sometime around that date Sound Transit servers will provide the back end for OBA going forward, providing a stable platform for this service.
A second thrust of this project is to improve the quality of data feeding into OBA. There are a number of technical issues . In any case, new algorithms will improve the data set exported to applications like OBA through integrity checks and the like by early next year, and begin a “culture of continuous improvement” by providing feedback to transit agencies about their data streams. It’s not clear that users will immediately notice the change, but over time accuracy should improve.
And light rail? The core problem is that the Supervisory Control And Data Acquisition (SCADA) system that Sound Transit purchased to run the trains is focused on safety and security, not interface to external data customers. Another deliverable in early 2014 should resolve the problems with the SCADA interface to allow OBA to report actual arrival times.
Getting actual next train times in light rail stations is the next step. Although software projects are inherently risky to schedule, Mr. Berman believes that by early 2015 stations should have this capability.
I asked why Link couldn’t inexpensively use GPS in the meantime, just as Metro does. GPS doesn’t work underground, but like a tunnel bus Sound Transit could estimate arrivals while the trains are in tunnels based on its timing while above ground. Mr. Berman said that internally his group had “talked about a stopgap” but were going to see if the SCADA approach worked first. I didn’t think to ask why we were still talking about this almost four years after opening day.
It’s true that lower headways and greater reliability reduce the chances of a really long wait, and therefore the imperative to provide what most frequent rapid transit systems provide. But the times where that falls apart — late-night 15 minute headways, track maintenance, accidents on MLK, tunnel snafus — are the times where this information is most missed.
* In fact, according to Wayne Watanabe (IT Service Delivery Manager for KCDOT), King County Metro has withheld millions of dollars in payments for the Automated Vehicle Location System (AVLS), until Init AG, the Germany-based contractor, solves some of the problems. An Init AG spokesman declined to comment, citing “a contractual obligation relative to the confidentiality of all our projects.” UPDATE: Mr. Watanabe clarifies that “the OBS project is not yet completed and consistent with the terms and conditions of the contract, full payment is only made upon full system acceptance. Metro and its contractor are actively working together to resolve the issues affecting system operation.”
Would the signs be able to double as RTA signs for the nearby transfer buses?
Or in the case of the DSTT, could they scroll through all the other tunnel buses?
Would be nice, but at least for the tunnel, not worth the effort: as soon as U-Link opens, buses are relegated to the surface for good. There would be at most 3 or 4 years of benefit from a potentially costly and time-consuming software effort.
Huh? Reference Please!
According to the latest SIP, train frequency will remain the same in the tunnel when ULink opens. Buses will likely remain until Northgate opens after 2020.
Yeah, I wish people would stop cluelessly repeating this “fact”.
Reference: https://seattletransitblog.wpcomstaging.com/2010/05/27/how-and-when-link-reliability-will-improve/
I did have it wrong, though; it’s implied that U-Link will end bus service in the tunnel. According to the referenced article, there seems to be some kind of joint operating agreement that comes up for renewal and negotiation next year.
Okay, the bus RTA signs at train-only stations are more important, since they give riders an indication of how long they have to hustle over to the bus stop, and rider groups, like those on the 50, have been asking for them.
Still, it would be nice to know when the next 255 is coming, so if it is going to be awhile, the rider can run upstairs and catch the 545. [ot]
Metro and ST studied this issue when the tunnel was converted to dual-use rail and bus. A useful number of buses can use the tunnel until train headways drop to five minutes. That will not happen in 2016. The benefits to riders in terms of speed and reliability, and to Metro in terms of dollars saved compared to trips on the surface are considerable, making it highly unlikely the withdrawal will happen until it is unavoidable.
That’s enough on this dead-horse subject for this discussion.
[ot]
Ending bus service in the DSTT when U-Link opens is the most likely course of action, but it is not a 100% given at this point.
However, it really isn’t worth spending any more $$$ on integrating buses and LR in the DSTT — buses will be relegated to the surface either when U-Link opens, or shortly thereafter.
But having true real time info for Link in the tunnel will be great — just use your paper schedule for the buses.
Could we at least get free wifi in the tunnels? This combined could get those of us with smartphones OBA. Combined with either GPS or their current system would help.
Or even better, a stationary OBA display in the stations themselves(a la 3rd and Pike). That doesn’t sound too tough.
(Ugh. I think you can figure out what I meant to say.)
Wifi or cell reception in the tunnel is expensive–about $2 million at last count. Metro and ST have better things to spend their money on, like service. The cell providers don’t want to pay for it either.
If we all had GSM and interoperability like in Europe, it could be done. But the fact of the matter is you’d need 4 base stations (one for each carrier) in every station. And I still don’t think that would get you service between the stations.
There is little reason it should be this expensive other than a bias towards using contractors rather than county personnel. There is already existing fiber and cable infrastructure, there is existing conduit, there is an existing city IP network. Perhaps if our government bureaucracies were a little more creative and less risk averse, they could save the taxpayers serious money.
They could also approach this problem by inviting the cell carriers to pay for the privilege of providing cell signal in the nearly 2 miles of tunnels we have now and for kitting out the upcoming 3.15 miles of ULink tunnels.
Charles,
Getting the carriers to pay is a great idea in theory, but the problem is that our carriers are not interoperable. So if AT&T gets service, it doesn’t help anyone on Verizon.
There’s also a lot of problems with municipal open wifi networks. Most of these are political, but it’s not an easy thing.
The lack of interoperability is precisely why carriers might be willing to pay for it. If the tunnel has cell phone service for everyone, that doesn’t really help Verizon’s bottom line all that much beyond a few extra text and data charges. On the other hand, if Verizon is the only carrier with service in the tunnels, this now becomes a selling point that induces people to use Verizon over AT&T. I would guess the new customers this would bring would provide plenty of revenue to make paying for the installation worthwhile.
Wrong. The trains and security guards have radios on a repeater and there is only one base (repeater). A Distributed Antenna System (DAS) (leaky coax?) makes it accessible at all stations.
More on the radio system.
I certainly know that engineered solutions and government contracts can strongly inflate the cost of small projects. But we’re talking about adding a few commercial WiFi boxes, a network connection, and some power. Yes, full cell service would be better. But WiFi would be cheap and easy and installed in a day for a thousand bucks or two if someone cared to do it.
I asked KCM engineers about that once. They said WRT WiFi that adding anything to the tunnel for buses is a hard sell because the buses won’t be down there once north link opens, and WRT OBA signs that they think the reliability of real-time arrival predictions inside the tunnel would be poor enough as to render it useless. To me, it seems like it would be perfectly good e.g. n/b at the IDistrict station where vehicles will have just gone out of GPS range. That was, however, the end of the discussion.
I’m curious why getting real time arrival signs for Link is treated as though this is some sort of new ground? How does Link differ from the majority of other systems which use this technology?
I think it’s an issue with the SCADA implementation ST purchased. As with so many government procurement programs, the requirement-writing was not top-notch.
I wouldn’t bash the procurement folks on this one. They generally oversee the process, not developed the specs for it. And it’s quite possible that when the RFP was bid on for this project, it was in the late 90s during the early design, and during the lawsuits when real time displays were only in their infancy. The contractor only has to deliver what was required of them in the contract, and if it was speced this way in the contract…
The TBMs are guided by GPS. Diffential GPS which requires adding a few reference stations but it’s not rocket surgery. Anyway, barring a disaster, knowing when a train left one underground station should give you an arrival time at the next platform with an accuracy of better than the +/- one minute reported.
Maybe the weather guys at KOMO can figure it out. They can tell within a minute when a cloud will be over your head (Accu-weather). A train should give a better return, unless we bought Stealth-LRT ™.
Is that true? I can’t find any information on GPS-equipped TBMs. Differential GPS could help with accuracy and up/down dimensions, but the frequencies that GPS runs on are pretty bad at transmitting through soil and rock. I’ve heard of solutions using longer wave repeaters mounted on the surface that “proxy” the GPS signals from the satellites, maybe that’s what they use.
From watching one of the U-Link tunnel simulation videos, I got the impression that TBM navigation was done using ‘old-fashioned’ surveying techniques updated with laser reflector survey stations and an automagic theodolite attached to the control computer.
It would HAVE to be differential GPS if they wanted any worthwhile accuracy… which they need to be very precise. But that is simple. There is no way GPS penetrates below ground and there is no way to repeat this signal from the surface. That being said, you repeat the gps to where the TBM is… now how do you measure the difference between the gps station above ground and the position of the TBM?
Laser survey is the only way. They could have receivers (prisms) on the TBM which align to these lasers to keep it on track. Or you could know a starting point and have an inertial system that calculates its position based on the start point. You would then update this regularly to correlate with an actual physical survey.
I have no specific knowledge of how this works with TBMs, just guessing based on my experience with positioning/surveying.
Exactly. 2 minutes from Westlake to University St on Link can almost guarantee 8 minutes to International District, plus or minus 30 seconds.
The fact that realtime arrival information is going to take “years” to implement is sad to me. Even if train arrival times could be approximated to be within a 90% accuracy range (very possible with the current technology/implementation), that would be a great solution. I don’t even think OBA has 90% accurate arrival times.
Except for those times when Link gets delayed by a bus wheelchair boarding; bus breakdown, etc.
Better yet, why not use the RFID readers that Metro already installed? Each bus has an RFID tag on the front (passenger side) next to the destination sign.
In the meantime, does ST have a plan to make the 2- or 1-minute train-is-coming announcements accessible to deaf riders? At least some of the crossings have flashing pictures of trains.
Correct me if I’m wrong, but I believe that even the current 2-minute-warning messages are displayed on the signs as well as announced audibly.
You’re right, Adam.
I was in the tunnel last week and the trains weren’t running, but there was no way to discover this from signs or announcements. Basically I waited ages until I asked someone who told me link wasnt running at the moment.
A very poor showing for 2013
If they can’t get the intercom to work as such, why not just buy bullhorns for the station supervisors?
Why aren’t the Westlake mezzanine digital boards turned-off unless needed for an emergency or something? It’s embarrassing they just say “Downtown Seattle Transit Tunnel” in big letters with a small time display below. Or just make the time display fill the whole screen.
To get people into the habit of glancing at them. If they weren’t on it’d be more likely for people to miss them in an abonormal operation situation.
I would think the opposite would be true. Knowing the glowing thing above you is useless, you stop glancing at it. But if all of a sudden there’s a glowing thing above you that wasn’t there before, you notice.
What sort of system controls the message displays as they currently exist? Why does it require such an expensive amount of re-engineering to add any sort of information beyond station name to these signs? I’ve never quite understood why the quality of information is so poor (though quality and quantity of service announcements has been improving slowly).
Last Sunday I was catching the train at SeaTac at 10:30, and there were announcements about the last trains, but it had information for both weekday and Sunday times. Is it too much to ask to have separate announcements for weekday vs. Sudnay/holiday so the announcement doesn’t take so long?
What’s more damning IMO is the obvious lack of service that is illustrated at transit centers served by RR. FWTC has *nine* bays — but only one, bay 8, has a realtime arrival screen. If it were for just the RR bus, that would be one thing — but it also includes the 2-3 other buses — out of at least a dozen or more that serve FWTC — that happen to use the same bay as the RR. Despite the lines that pile up at neighboring bay 7, there is no arrival screen there, nor at any other bay in the whole station. It would actually be useful sometimes to know which bus is coming next among the bays. (This is also a beef I have with OBA — having to flip through multiple “stops” that are really all at the same place.)
I agree with this point about OBA completely – that having to flip through bays is a problem (Renton TC has 10!) – but I’m not certain that OBA is the problem; it may have to do with the actual GTFS feeds, and short of brewing its own solution (idea!), OBA is taking what it’s getting.
They could add one of the OBA signs a la the ones downtown.
There’s a really cheap interim solution that Sound Transit could implement:
Publish the schedule. Post departure times at each station. Just like they do for buses.
For the most part, Link runs close to schedule. More so than buses.
It’s completely irrational that ST doesn’t publish a Link schedule.