On Fri, 25 Feb 2005 13:29:34 +0000, Dave Arquati wrote:

Ian Jelf wrote:
I took a trip on a 38 from Piccadilly to Victoria yesterday afternoon.

Unusually, the conductor worked like a Trojan during the trip, checking
fares, calling out stops (with a lot of additional information, too) as
well as warnings. It was a pleasure to see.

My query, though, concerns Oyster.

I paid by Oyster Prepay and at Victoria I left the bus and went straight
into the Underground Station to top up it up. When I did so, I was
astonished to see my journey on the 38 already recorded on my usage. How
does this data get from the conductor's machine to Oyster's "Central
Control" so quickly?

Aha... the conductor's machine doesn't actually hold your information.
The information is stored on the card itself, so when the conductor
marks a bus journey using his machine, that bus journey is stored on the
card. As soon as your card then comes into contact with the central
network (mainly via LU gates, ticket machines or validators) then that
information can be synchronised with the network.

At least that's how I understand it works.

Only partly correct I'm afraid.

The card will store 10 journeys worth of information. Therefore it is
updated each time there is a transaction such as an entry at a gate or
tapping your card on a bus reader. Both the card and reading device
exchange information and validity checks are made. There is a
transaction written to the card and also one generated in the reading /
checking device. As the conductor machine can deduct cash as well as
sell a paper ticket then it MUST record all transactions - how else is
the money accounted for?

The gates are polled regularly by a station computer which then
transmits info to the centre. Similarly when a driver or conductor
finish their shift they will place their module in a depot reader which
then downloads all the transaction info. In the reverse direction new
fares or card hotlists will go in the other direction when they log on
to start a shift.

The garage units will transmit their data to the central system at the
end of the operational day. This info is then sorted alongside all the
trip data for other modes.

Now this is where my knowledge as to what actually exists is a bit rusty
but the initial design of the centre was such that each night each card
record held in the central system would be updated and reconciled once
all the possible linked accountable devices had reported for the
previous day.

As an example all of today's transactions will be processed tonight so
that the central system has up to date records tomorrow. This is why for
capping that they ask you to raise any queries about incomplete trips
and caps the day *after* you travel. I created the basic operational
concept for the new parts of the central system and the last time I was
given a demo of it the supplier showed me the bits that I had specified
working. There's obviously a hell of a lot of detail within the design
that was developed after I left the team. Nice to know I got something
right!

--
Paul C


Admits to working for London Underground!