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.”
Oyster Card and Barclaycard to launch e-money scheme
Comment on this article:
computer.weekly@rbi.co.uk