Ticket didn't fall out of the machine

[Puffing Devil]

Paper tickets fail when the print fades, i’ve personally had blank tickets dispensed from a TVM due to a print head failure (although the mag stripe was correctly encoded).

What’s needed is a national standard for smart cards/m tickets/e tickets that replicate the benefits of paper tickets, rather than individual operator schemes that are incompatible with each other, and launched in a haphazard manner.

I'll split hairs again and say that a properly issued paper ticket does not fail in the same way an eticket can.

Also to play Devil's Advocate - why do we need eTickets? There is a huge cost associated with implementing such a system and perhaps little benefit. For a much smaller spend we could have ticket machines at every station, which produce not internet connected, hard coded, travel documents.

Two examples to provide food for thought. Many years ago I was working on a new system implementation and worked out the cost of doing a data take-on electronically from the old to new system. This required program design, coding and testing; it was not cheap. It turned out to be cheaper to hire in a bunch of temps for two weeks to key in the records to the new system (with validation). Secondly, there is the urban legend, partly true of the space missions. NASA and then Fisher invested big time in producing a pen to work in space: the Russians took a pencil. Just because it's possible, we don't always need to do it.

 

[rpjs]

I'll split hairs again and say that a properly issued paper ticket does not fail in the same way an eticket can.

Also to play Devil's Advocate - why do we need eTickets? There is a huge cost associated with implementing such a system and perhaps little benefit. For a much smaller spend we could have ticket machines at every station, which produce not internet connected, hard coded, travel documents.

Why can't you do both? On Amtrak in the US in practice you no longer actually need a paper or e-Ticket to board the train, just tell the conductor your name and he/she can look you up on their iPhone. In practice it's faster to show the paper ticket (with bar-code) or e-Ticket but if either won't scan, that's the fall-back.

At stations with access control like New York Penn you do have to show a ticket, paper or phone, to the person at the top of the escalator down to the platform (although when it's a busy train and everyone crowds to the escalator it'd be easy to slip by), but I've got on the train at a rural station and the conductor has been standing by the (one open) door with their iPhone ready with a list of pax boarding at that station and just asked for our names as we boarded.

Now of course, people will say "but Amtrak's not turn-up-and-go is it?" Well yes, but in practice you can buy a "reserved" seat (not actually a specific seat but rather they only sell seats that are actually available to sit on) up to twenty minutes before the train is due at your station, assuming there's capacity, so you get virtually t-u-a-g with a guaranteed seat. If Amtrak can do it, why not the UK?

 

[AngusH]

Ideally the paper ticket is a physical token representing an electronic record. So if you have the paper ticket it works perfectly, if you haven't then the record can be inspected and you can still travel. (edit, and the paper ticket invalidated)

It would also mean that when a paper ticket is sold on departure, the record is immediately inserted into the ticket database and the whole thing works fine.


An unrelated idea might be to force senior rail managers to use exclusively m-tickets for all their staff and famaily travel.

 

[najaB]

A good start would be to replace NRS with an e-ticket database. They manage a single reservation database, why not a single ticket database too?.

As noted above, with a turn-up-and-go railway with onboard ticket sales you need universal data coverage.

 

[yorkie]

Please see Paperless rail tickets across UK by 2019 - Chris Grayling for discussion regarding e-tickets.

There are many threads documenting problems with the current awful implementation of e-tickets, many of which have onerous requirements and are unfit for pupose, e.g. Print at Home Ticket / 'e-ticket' - Refused travel.

 

[rs101]

As noted above, with a turn-up-and-go railway with onboard ticket sales you need universal data coverage.

Given that the emergency services are in the process of switching from a proprietary system to EE's 4G network (due by 2020 but may be delayed a year), which is driving a rollout of longer range 800MHz transmitters with a target of 95% coverage of the UK landmass,I 'd expect your continual worries about coverage may soon be resolved.

If stations provide WiFi (as GA are doing at many of their stations), that would enable many travellers to purchase via apps while at the station, reducing the number of on board sales required considerably.

 

[najaB]

Given that the emergency services are in the process of switching from a proprietary system to EE's 4G network (due by 2020 but may be delayed a year), which is driving a rollout of longer range 800MHz transmitters with a target of 95% coverage of the UK landmass,I 'd expect your continual worries about coverage may soon be resolved.

It's not a concern raised for the sake of it - if a ticket is just a pointer to a database record then that database needs to be accessible anywhere that tickets are sold or examined. It remains to be seen if the railway will get the same priority network access as the emergency services (it's my understanding that the network will drop 'regular' traffic to ensure that there's sufficient bandwidth for ES calls).

 

[Llanigraham]

Given that the emergency services are in the process of switching from a proprietary system to EE's 4G network (due by 2020 but may be delayed a year), which is driving a rollout of longer range 800MHz transmitters with a target of 95% coverage of the UK landmass,I 'd expect your continual worries about coverage may soon be resolved.

Even that date has now slipped, and the target coverage is actually a lot less than that as it is based on coverage of A and B roads only. Plus there has been deep concern from ACPO and other bodies about the ablity of the system to cope with emergency situations, due to the in-built delay in transmission.

The Scottish Ambulance Service are trailling a satellite based system due to the inability of EE's 4g system to cope in their area, and the Welsh Ambulance Service are watching this closely.

As of 4th Quarter 2017 EE are reporting that out of 491 new sites to be built for ESN, 199 are now built or in the build phase; and that of around 21,000 upgrades required for ESN, around 19,000 have been completed. This does not take account the rural masts being built by the Home Office called "EAS extended area service" of which few of the 500 are complete.

 

[Llanigraham]

It's not a concern raised for the sake of it - if a ticket is just a pointer to a database record then that database needs to be accessible anywhere that tickets are sold or examined. It remains to be seen if the railway will get the same priority network access as the emergency services (it's my understanding that the network will drop 'regular' traffic to ensure that there's sufficient bandwidth for ES calls).

Correct.

 

[Bletchleyite]

As noted above, with a turn-up-and-go railway with onboard ticket sales you need universal data coverage.

Depending on how it's done you don't necessarily need that. For example, if you don't allow travel on a simple reference number but require P@H, mobile or a bit of orange card to be printed from the database which would include basic validity information, a batch "when the device gets a signal" process would work no less effectively than the present setup, in some ways more so because a "grip" would include not just the basic information stamped/written in biro but a huge amount of detail such as train, member of staff, location, time etc, and would be able to identify misuse.

Having said that, I would expect blanket coverage of the UK with some kind of mobile data provision within 10 years, easily. Then that problem goes away.

 

[najaB]

Depending on how it's done you don't necessarily need that.

If a guard sells a ticket on board then the database needs updating. That requires either a live connection or batching.

 

[Bletchleyite]

If a guard sells a ticket on board then the database needs updating. That requires either a live connection or batching.

Batching of some kind would probably work for the kinds of line where coverage is that poor. On arrival at the main terminus the machine could download via wifi.

 

[AngusH]

Edit: feeling my comment is offtopic, I've created a new thread instead:

https://www.railforums.co.uk/threads/a-distributed-ledger-as-the-future-of-ticketing.159387/

 

[philthetube]

People don't like change, don't like things they don't trust or things they are not familiar with, you only need to look at all the complaints on here about every new app released by the Toc's to realise that. To use a system you are familiar with is easier than learning, and possibly making expensive mistakes on a new one.

Has anyone actually said that they object to every new app released by a TOC on the grounds that they dislike change?

Are you sure it isn't actually the case that people raise valid concerns about ways in which these apps make the situation demonstrably worse, only for these concerns to be thoughtlessly dismissed as "fear of change" without anyone even listening to what the actual concern was?

In most cases they are probably not worse but different, still capable of selling tickets or whatever they are supposed to do but not liked because of the need to sort out how they work.

 

[rs101]

Batching of some kind would probably work for the kinds of line where coverage is that poor. On arrival at the main terminus the machine could download via wifi.

Works for many of the parcel delivery companies -their systems batch events when out of coverage and transmit automatically when available.

Many TOCs already provide WiFi at their stations - this could be used for uploads.


It's true the EE network will prioritise emergency services traffic, but how likely is that to actually mean non-urgent traffic is completely dropped for any length of time? With batching functionality, is that really a massive problem anyway?

I work on systems providing realtime tracking of hazmat shipments on the North American rail networks - that uses mobile networks for some of the data feeds (live GPS and environmental monitoring of the wagons) and manages to get suitable data connectivity across the entire region, using a small amount of batching.