Developing and implementing IT systems for a transport network is a challenging undertaking.
Transport infrastructures are highly fragmented, yet they must serve a travelling public that needs to use the whole.
Migration to a new system cannot easily be confined to a particular segment, and teething problems can cause massive disruption – and rapid disenchantment.
Privatisation of the railways back in 1993 was followed by the carving up of the national bus and London Tube networks into franchises. “Getting the various operators together to agree something that the travelling public takes for granted is a major task,” says David Hytch, principal transport consultant at LogicaCMG.
“And it is of little value if just one operator innovates, because the fallout of an inconsistent service hits all operators.”
Similarly, the all-important return on investment that dictates any commercial investment is constrained in the transport industry by franchise lifecycles.
“If it takes four years before any return can be recouped – and the franchise only lasts seven years – it is hard to argue for any investment to the board of directors,” says Hytch.
“These factors combined mean that technology upgrades and change come only falteringly to the transport networks. Smartcards have been around for 10 years, yet the rail operators are only just getting serious about it.”
Assisting all public sector transport projects is the growth of open standards such as Corba and XML-based web services. Open standards encourage more competitive tendering too, as local authorities no longer overspecify systems, but instead plug them into broader frameworks, according to engineering and development consultancy Mott MacDonald.
“Suppliers used to provide proprietary and discrete systems for the traffic systems control room, fault management and asset management, whereas these now link together,” says John Glen, transport technology director at Mott MacDonald. “Importantly, risk is also reduced.”
Case study: Oyster gets moving
Despite the obstacles created by fragmented transport systems, it is possible to launch new products, as demonstrated by the Oyster Card scheme. The London Tube and bus pre-pay smartcard shows it is possible to have an integrated ticketing system for disparate transport networks.
Working in the scheme’s favour was the fact that there is a sufficiently large travelling population to secure a financial return. The backing by London mayor Ken Livingstone also helped get it off the ground.
The pre-pay Oyster Card is the culmination of a vision for a single smartcard for Tube, bus, rail and tram that would significantly reduce fraud and make travelling easier for passengers.
However, the scheme has faced some problems. The temporary disabling of the card in areas of London affected by a power outage in January is an instance of the kind of unforeseen challenges the Oyster Card scheme has had to address.
Its development has entailed continually adapting to change, including London Transport morphing into Transport for London in 2000 after the contract was signed.
Added to this was the complexity of working out how to migrate from the old system to the new without any downtime. “People do not stop travelling though London and season tickets still have to work,” says Richard Horton, commercial director of fare systems specialist Cubic Transportation Systems.
Nor is transport a particularly stable environment, as there are fare changes twice a year.
The supplier contract for the scheme was signed in 1998 and TranSys, the winning consortium of Fujitsu, Cubic, EDS and WS Atkins, formed a project team.
Earlier work by London Transport in 1993 had offered proof of concept for a smartcard, and valuable lessons were learned about customer interface and passenger traffic through a gated system. Design deliberations took two years before TranSys was happy it had a system that it could begin developing and implementing.
A mixed architecture of centralised and distributed data was designed to fulfil objectives. Customer journey and payment records are drip fed to a central database, where information is safe from attack and can be mined for management reporting.
The central fare and payment reconciliation system comprises 1.5 million lines of object-oriented code and the application server is hosted on two Sun Fire 6800 systems with eight Sparc processors in each.
Scalability was a major consideration, and the system has withstood a greater uptake of the Oyster Card than had originally been anticipated – the 10 million cards in circulation is three times greater than was envisaged for this point in time. An Oracle database with Actuate and Business Object provides further management reporting tools.
A crucial decision was to revise the original plan of a “big bang” introduction in favour of a phased roll-out. Gradual delivery meant that glitches could be ironed out, wrinkle by wrinkle, without a devastating loss of confidence. A lab testing facility was used extensively to simulate journeys, and London Underground staff were guinea pigs in the first phase of the roll-out.
“The system was given a very thorough thrashing before it was let loose on the public,” says Pat Morey, project manager for TranSys.
Although, logically, the billing system should be a simple question of calculating the cost of a journey between A and B at a particular time “you would be amazed at the things that customers do within this journey”, says Morey. These quirks include exiting a gate then going in and out again to retrieve a glove, for example, or to help a child.
There have been a number of firsts, including operating a capping system as an inducement to travel. Providing this facility entailed calculating 1.83 million journey permutations. Each of these can now be processed in 200 milliseconds at the gated system.
Lessons have been learned too. “With such a complex system it is absolutely vital to have a system integrator who is correctly incentivised and that all scenarios are written into the contract,” says Horton.
Case study: Newcastle’s initiative
Changes in legislation can be the impetus for smaller local authorities to invest in systems to achieve better integrated traffic or passenger flows.
Newcastle City Council is using a geographic information system to comply with the Traffic Management Act, and to ensure commuter traffic in and out of Newcastle flows more smoothly and safely.
At Newcastle City Council, a proven connection between vehicle speed and accidents and the introduction of the 2004 Traffic Management Act created a need to manage traffic more stringently. The council commissioned the IT department to produce systems to support the two initiatives.
The immediate response of the department was to reach for a GIS. “It is the ideal way to bring separate data sources together, and by collating information it is possible to start spotting patterns and trends,” says Bill Taylor, ICT technical consultant with Newcastle council.
“The two traffic management initiatives mean we have vast amounts of data to process and the GIS system from ESRI has enabled us to present large volumes of data in an easy to understand way,” he adds.
For the speed management project, 100 Golden River traffic sensors were implemented, and the captured data is sent over the GPRS network to a communications server.
Once converted by Drakewell software, the data is passed to a SQL Server and then onto the GIS. Here it is processed and displayed as interactive city maps and aerial photographs on a giant plasma screen.
Although the team was confident that a GIS provided the right technical capability for the traffic management project, the context presented fresh challenges. A major task – still underway – was simply uploading data into the GIS. The council has to ensure that every yellow line and disabled parking bay in the real world matches the legal world of documentation in order to accurately levy parking fines.
An inventory of the city’s street and road signs and markings will take two years in total. The authority has made life easier for itself by kitting out auditors with Pocket PCs loaded with Arcpad field map software.
It also enabled the handheld devices with a differential global positioning system (DGPS), which provides sub-metre accuracy in pin-pointing locations. This means the army of auditors can key in the online forms on a Pocket PC without being slowed down by inputting grid references.
However, the novelty of DGPS also threw a small technical spanner into the works. “Arcpad was not accustomed to DGPS – it could handle the old version, but not the new”, says Taylor.
Similarly, the mobile GPRS network, used for sending data from the Pocket PCs to the central system, was shaky. As a result of lost connections, the sensors would hold onto the data, creating a log jam. Once the GPRS signal was back, the sensors would send big bursts of data traffic.
Despite data collection glitches, the GIS offers myriad opportunities to share and publish information. Publishing maps and schema on the internet for businesses and residents to consult before planning journeys is a definite intention. And using XML means there is the prospect of integrating GIS with council car park and bus systems as well.
As Taylor concludes, “The technological capability is there. Sharing that information would be a political decision.”
Comment on this article: email@example.com