TfL wheels out digital bus info upgrade
Countdown II embraces API-hungry developer masses
As winter sets in, commuters in London stand huddled at bus stops, hoping the shelters' electronic signs report an accurate "due" arrival time rather than a crappy guess.
Those lucky enough to have Transport for London's Countdown system of signs installed at their stops can judge by the minutes flickering on the display whether to brave the chill or nip into the warm caff for a coffee.
The problem is, the signs are not at every stop so some passengers are out in the cold figuratively as well as literally. The equipment is also susceptible to vandalism, and the timetable information isn't being pushed to the phone in your pocket.
But TfL plans to change this with the launch of Countdown II, which went live on Monday after three years in the making.
The main features are an SMS service that sends bus information to phones, improved bus stop signs, and a web app (plus mobile-friendly version) that will show when the bus for a given route will arrive at any stop within Central and Greater London plus a few outlying areas. Users simply enter a postcode, street name, bus route number or bus stop code. With 8,500 buses and 19,000 bus stops, the technical challenges for such a system are considerable.
Countdown: 8,500 buses, 19,000 stops, but not everyone is on the map.
Compared to the ill-fated NHS IT project and other government-backed outsourced IT spend-fests, Countdown II appears to be a rare success. The Register spoke to Simon Reed, head of TfL's Technical Services Group, and Anders Rylander, a Network Architect at TfL.
Reed and Rylander said that, in contrast to this, TfL's approach was a gradual layering of clearly targeted investments, with each project building on the previous one, rather than: "Here's a wad of public cash, achieve great things and call me when you're done."
Reed said: "TfL is responsible for providing a transport network for Londoners, and the days of that just being vehicles are long since gone. So there's been a succession of investments in the bus network going back some years. The most relevant to this conversation was since 2003, a project called iBus, which put location technology into every single (TfL) vehicle, so we can better manage the bus network as a result of knowing where the buses actually are."
GPS is not the only fruit
You'd think that GPS would be just the ticket: "In fact GPS is one of the inputs, but it isn't brilliant for London. Canyoning in particular means GPS doesn't fulfill the accuracy tolerance we need."
Several tracking methods are combined: gyroscope, odometer feed, route layout on board and – of course – GPS. The bus then transmits its location every 30 seconds.
iBus, originally developed by Siemens and later Trapeze, went live in 2007 and all buses were fitted with it by 2009, so it's a proven, solid core around which to build the new Countdown system. As with its predecessor, Countdown II has been outsourced, albeit to three companies: Telent, Trapeze and German contractor IVU. Reed was keen to stress, however, that TfL has kept the design knowledge in-house: they have several IT project managers involved, and their own design team that apparently keeps close tabs on the outsourced development.
Swearing at Bugzilla
Over the last few months, the project has been undergoing intensive testing. IVU and Trapeze have written a multitude of unit tests, especially to cover bug fixes, with Telent then testing their fixes. Between them they're using Bugzilla to track issues. According to Rylander: "A few people have been swearing at Bugzilla, but probably more due to the data they were putting in. Now that they're up to speed on it, it works reasonably well for us."
A public API will be made available for Countdown II to encourage data mashing by third-party developers. This could, for example, lead to a stop-by-stop mobile app that directs anyone new to London's East End to, say, the Velodrome and which helps avoid overcrowding on the Underground.
Reed told us: "Data syndication is fairly new within TfL. We've followed a policy of releasing data feeds whenever we can do so. We've already released Barclays cycle data, CCTV images, locations of all our bus stops – they're all there in our developers area."
Under the covers, the Java/Spring-based system communicates with the buses via VDV, a German standard for transport protocols, but obviously this isn't much use for mobile app developers. So the data syndication API will most likely be cloud-based. As to which cloud, Microsoft's Azure appears to be the front-runner, though TfL hasn't yet signed a commercial agreement with any provider.
Data syndication is fairly new within TfL. We've followed a policy of releasing data feeds whenever we can do so – TfL's Simon Reed
Once the API is released, though, developers can go wild. The obvious first task will be to combine the core iBus API for tracking vehicle locations with a smartphone's own location-based function, so travellers can dispense with tedious bus stop searches on a small screen with cold fingers.
Details of the API are vague at this stage but Rylander says they will figure out what's needed, then design, develop, test, document and release "absolutely this year".
Among the details that still need to be settled is how registration will work. The biggest concern is around scalability and performance, with 6.3 million passengers potentially accessing the service all at once. A device could request details of every single bus route in each hit, making the service particularly susceptible to a zombie-phone DDoS attack (or even just a badly written iPhone app).
The infrastructure is "scalable but limited": the team want to be sure that the system will cope, especially during peak travel times and during the Olympic period. The system has "an awful lot of shared clustering of servers" using "an Oracle technology" – Coherence, we suspect.
Such is the interest in the new service that before it has even been launched, screen-scraping apps have been released by some overly keen types using the beta version of the web app that's been live for several months. While cautious about these bootleg apps, Anders did say that it is "really exciting how creative people are being. Screen scraping is not something that we encourage as it's not allowed. But we're keen to open a dialogue with third-party developers".
Last month, a selection of "top coders" from the iPhone and Android apps arena were invited to TfL HQ to voice their preferences.
When it's released, the API will be available on TfL's Data Feed syndication page.
It is certainly not the first system of its type: Sheffield has had a similar service in place for a while, albeit with just 47 routes. It's the difference in scale that makes the two systems almost incomparable. Is Countdown II a sign that complex, demanding, publicly funded IT projects really can succeed? Its performance over the next few months – and particularly during the Olympics – should give us the answer. ®
Because ideas that can be summed up in sentence aren't neccesarily cheap and easy to do?
Typical. You wait for an outsourcing partner for massive scale public IT infrastructure, then three come along at once.
...saying that town 'x' has a similar system to this. So what? The fact is that this is on a *much* bigger scale and massively more difficult to deliver on. As the article points out, it's piss easy to deliver a system out in the country or in a small town. However, to do the same on a huge network with the environment of London is a reasonably impressive feat, and I've not heard of anything on a similar scale and difficulty anywhere else in the world.
I only wish it had come earlier - but at least it's here ahead of the fabled October snow :-) I find it reasonably accurate; if only it could predict the odd customer still paying by cash and delaying the bus for a minute :-)