Commuter knew better than apps

[saismee]

You evidently did not read OP's case - or subsequent posts fully - because there were two possible platforms for the service to arrive on. Where something like AI could (still think we're some way away from it) be useful is determining whether Platform 4 is more likely than Platform 5 (it is) and displaying it there.

I certainly read it and all other posts, the layout between Twyford and Maidenhead has seven signals and berths after the points for the other platform; perfect for announcing the alteration. There is no "AI *could*" when AI is inherently unpredictable and random. It's a solved problem, you just need to pass the information to the CIS. It would be trivial to implement if designed nowadays, though I think old software is the biggest hurdle here. I find it absolutely pointless to mention AI in this conversation at all when it isn't relevant and would just increase costs tenfold - it shows that a lot of people have fallen victim to marketing buzzwords.

 

[Steve Harris]

but given the enormous (hidden) costs of AI might it not be quicker, cheaper and easier to train somebody with a Mk I human brain to do the job? It would have other benefits too... Why are we so obsessed with not paying people to do jobs?

That's simple, cost ! When employing a computer you don't pay Income Tax, National Insurance, Pension contributions, sick pay.... need I go on ?

 

[saismee]

That's simple, cost ! When employing a computer you don't pay Income Tax, National Insurance, Pension contributions, sick pay.... need I go on ?

No, instead you lose 14 billion per year. Take a look at OpenAI's revenue

 

[Taunton]

There is no "AI *could*" when AI is inherently unpredictable and random. It's a solved problem, you just need to pass the information to the CIS. It would be trivial to implement if designed nowadays, though I think old software is the biggest hurdle here. I find it absolutely pointless to mention AI in this conversation at all when it isn't relevant and would just increase costs tenfold - it shows that a lot of people have fallen victim to marketing buzzwords.

Quite so. I recall being in London Bridge power box in the 1980s, and being shown the way that messages were passed back and forth to Three Bridges box about running, "computer to computer", and how the controller at the back desk could have announcements made wherever. That was 40 years ago, and in fact the power box was that from the 1976 resignalling so 50 years old. It does so often seem we have actually gone backwards.

 

[Steve Harris]

That's simple, cost ! When employing a computer you don't pay Income Tax, National Insurance, Pension contributions, sick pay.... need I go on ?

But yet :

I find it absolutely pointless to mention AI in this conversation at all when it isn't relevant and would just increase costs tenfold - it shows that a lot of people have fallen victim to marketing buzzwords.

I can't see the argument your trying to make here, as your quoting a figure and then saying AI is irrelevant, which makes your answer pointless does it not !? Plus you haven't quoted a figure for the cost of employing people as per Andrew E's suggestion, so you can't make a comparison.

The broader point i was trying to make was that businesses/organisations prefer automation over employing real people as once you have got over the initial outlay automation is normaly cheaper in the long run. Therefore I doubt if anymore staff will be employed to keep a beady eye on signalmaps. I think we are stuck with what we have (although in limited amount of locations which wouldn't need a lot of money to change which berth the CIS system looks at for a platform change it might be possible to improve things, but generally I think we are stuck were we are).

 

[Ducatist4]

For a period of several weeks the same train at Chesterfield Station was always moved from P1 to P3 despite the boards etc saying P1. I used to tell people to go to P3 to save rushing.

 

[Tom]

I've talked about this on other threads and it would be great to rewrite the systems to be more able to predict platform changes based on route settings or earlier berths that would show the change potentially miles away (take trains leaving Harpenden towards St Albans where you can see if a train will change from platform 3 to 1 a long time in advance).

I'm led to believe that at least one CIS supplier can do exactly this. RTT does it on the Anglia route too.

 

[notverydeep]

You evidently did not read OP's case - or subsequent posts fully - because there were two possible platforms for the service to arrive on. Where something like AI could (still think we're some way away from it) be useful is determining whether Platform 4 is more likely than Platform 5 (it is) and displaying it there.

It doesn't really seem like an AI problem - surely a sub-routine with little bit of site by site logic in the programme would do the job perfectly well? If the train shown in the first line of the Platform 4 list is detected on track x then delete from platform 4 list and insert into platform 5 list, where track x is the first track after the divergence point. The CIS programme is presumably relying on location data feed to generate the list and timings in the first place.

I wonder if when CIS system projects are implemented, no one is tasked with identifying and addressing all the idiosyncrasies that cause them to show misleading information that might lead to passengers missing a train or boarding an incorrect train. I see another example - at Blackfriars northbound Thameslink platform, located shortly after a converging junction. Several times I can see on the Open Train Times map that the route is set for a train from the Elephant & Castle Direction, whereas the screen predicts a train from the London Bridge Direction first, which will persist until the 'wrong' train has almost stopped in the platform, leading to passengers for one route boarding a train to another, or (as I have once) not realised the train is actually my train until it is moving out of the platform! Again, if the information is in the data feed, the logic to account for it in the CIS would not be very challenging to add - but it would require a process in whatever maintenance contract to allow for staff to raise such instances and for the programmer to work on them...

 

[saismee]

But yet :

I can't see the argument your trying to make here, as your quoting a figure and then saying AI is irrelevant, which makes your answer pointless does it not !? Plus you haven't quoted a figure for the cost of employing people as per Andrew E's suggestion, so you can't make a comparison.

The broader point i was trying to make was that businesses/organisations prefer automation over employing real people as once you have got over the initial outlay automation is normaly cheaper in the long run. Therefore I doubt if anymore staff will be employed to keep a beady eye on signalmaps. I think we are stuck with what we have (although in limited amount of locations which wouldn't need a lot of money to change which berth the CIS system looks at for a platform change it might be possible to improve things, but generally I think we are stuck were we are).

If a company is managing to lose 14 billion per year hiring people to update CIS boards manually, I'd be genuinely impressed. I couldn't quote a cost for employing people, but you'd still have to do that to maintain the AI model you are using, otherwise it will fail after any resignalling is done. To add to this, training needs lots of data to look at so the CIS boards would be dead/nonfunctional until trains have been operating for quite some time.

It doesn't really seem like an AI problem - surely a sub-routine with little bit of site by site logic in the programme would do the job perfectly well? If the train shown in the first line of the Platform 4 list is detected on track x then delete from platform 4 list and insert into platform 5 list, where track x is the first track after the divergence point. The CIS programme is presumably relying on location data feed to generate the list and timings in the first place.

I agree, it would certainly require a bit of work updating every station, but it would be far less than the costs of maintaining AI (and the frequent mistakes it would likely make). In order to make the AI consistent enough, it would have to have all the data available, at which point it'd be better to have more rigid conditions. On top of all of this, we should be advocating for improvements, even marginal ones like this. No person should miss their paid-for train by something out of their control, especially if they are a vulnerable person (people with mobility, visual, or hearing impairments could even be put at risk trying to rush, for example).

 

[Tom]

Quite a few large firms claiming to have great AI have attempted to sell stuff into the railway space particularly in the realm of live and performance data and have walked away when they realised quite how weird, unstructured and massively undocumented signalling data actually is.

This isn't a hard problem to solve, I've done it in RTT, others have done it in at least one CIS product. It's laborious to set up due to how the data is, but it's not hard.

 

[43066]

I've talked about this on other threads and it would be great to rewrite the systems to be more able to predict platform changes based on route settings or earlier berths that would show the change potentially miles away (take trains leaving Harpenden towards St Albans where you can see if a train will change from platform 3 to 1 a long time in advance).

There will be some locations where this is possible, but far more where the route will be set at the last signal prior to entry to the platform (Redhill, the example given above, is such a location). So there will still be very short notice if the platform needs to be changed.

This isn't a hard problem to solve, I've done it in RTT, others have done it in at least one CIS product. It's laborious to set up due to how the data is, but it's not hard.

How does AI cope with a signaller making a short notice decision to route a train into a different platform from booked, when the time between the route being set and the train stopping at the platform is less than a minute? You’re still only going to get a minute or so’s notice!

This is the typical situation where this happens: a train sits down in a platform, the box gets a call about a disruptive passenger etc. so the platform is changed at the last moment as the train approaches the entry point - the signaller will either manually set the route for all trains, or will need to override ARS to change the booked platforms, so there’s no way it can really be predicted.

 

[Tom]

How does AI cope with a signaller making a short notice decision to route a train into a different platform from booked, when the time between the route being set and the train stopping at the platform is less than a minute?

I can't talk about how others have implemented it but the way that we implemented it in RTT (on Anglia) is three fold.

Under the hood we have a model where it uses the scheduled platform, a model of what it thinks the platform might be based on current conditions, and then essentially a lightweight twin model of the signalling that's tracking forward progress of the train based on data outputs from it. You can see that in other forms on services that the Track Your Train feature shows on.

We move a platform to 'confirmed' if we're 90% sure a train will use a given platform or we can see that the train is routed into that platform or there is no other viable option. We won't show a likely change if we're not 100% sure as the position of the network may change.

On non-Anglia routes, then we don't have the tracking the signalling as we haven't built the models out to it.

But none of this is AI, we know exactly how it works - we don't need to introduce a pandoras box of messiness because the railway network is constrained, we know the criteria and we can develop around it rather than having something that can hallucinate coming out with a result we simply don't understand.

 

[43066]

I can't talk about how others have implemented it but the way that we implemented it in RTT (on Anglia) is three fold.

Under the hood we have a model where it uses the scheduled platform, a model of what it thinks the platform might be based on current conditions, and then essentially a lightweight twin model of the signalling that's tracking forward progress of the train based on data outputs from it. You can see that in other forms on services that the Track Your Train feature shows on.

We move a platform to 'confirmed' if we're 90% sure a train will use a given platform or we can see that the train is routed into that platform or there is no other viable option. We won't show a likely change if we're not 100% sure as the position of the network may change.

On non-Anglia routes, then we don't have the tracking the signalling as we haven't built the models out to it.

But none of this is AI, we know exactly how it works - we don't need to introduce a pandoras box of messiness because the railway network is constrained, we know the criteria and we can develop around it rather than having something that can hallucinate coming out with a result we simply don't understand.

Ok thanks.

What do you mean by confirming platforms? Presumably you’re still going to display the booked platform on the PIS by default until something changes given that the booked platform will be used 90%+ of the time. So this is no different to what the existing system does.

The decision to change it will often be made at the last moment, and at the last signal before the platform, due to the signaller reacting to something happening on the ground that you can’t predict from the train’s progress so far. So under your system you’re still going to end up with a short notice CIS change in a small minority of cases (just as we have currently), unless I’m missing something?

Your system sounds more like a London terminal style system where the platform isn’t shown at all until the decision is made, but that isn’t going to work at through stations without a large station concourse.

 

[Adam Williams]

I can't talk about how others have implemented it but the way that we implemented it in RTT (on Anglia) is three fold.

Under the hood we have a model where it uses the scheduled platform, a model of what it thinks the platform might be based on current conditions, and then essentially a lightweight twin model of the signalling that's tracking forward progress of the train based on data outputs from it. You can see that in other forms on services that the Track Your Train feature shows on.

We move a platform to 'confirmed' if we're 90% sure a train will use a given platform or we can see that the train is routed into that platform or there is no other viable option. We won't show a likely change if we're not 100% sure as the position of the network may change.

On non-Anglia routes, then we don't have the tracking the signalling as we haven't built the models out to it.

Setting aside the conversation on AI (which 99% of the time is just being thrown into the mix as a marketing gimmick), the fact that we have an independent site doing this on one route proves that the approach is feasible and can work when you put the effort into it. And before someone points out "oh, but that's just one route, you couldn't do that across the network!!", I think most big CIS suppliers in use today have slightly more staff than are currently working on Realtime Trains!

As ever in this industry though, there's a general resistance to innovation and much gnashing of teeth/defence of how things currently work because "zomg it's always worked this way". And it's the passengers that lose out. I don't care if it's a minority of journeys that this happens on; it's really poor - and having been in that position myself and nearly missed the service (and witnessed passengers with mobility problems trying to rush across the station), it's really bloody annoying.

@OscarH hit the nail on the head with this statement:

I know enough about how these things go with the organisations involved that I'm sure they have ended up concluding that it's prohibitively expensive for technical reasons. I'm not convinced I believe that in real terms though

I don't believe it either.

Believe what you want, but if there was an easy and cheap solution, it would have been done.

Sorry, but I really don't think this holds. There's tons of low-hanging fruit just in the FTR space, and general inertia and widespread lack of subject matter understanding in-house (and reliance on very expensive consultancies to deliver .. basically anything or even just to manage projects) has meant that things have generally stagnated and there has not been enough progress made.

 

[renegademaster]

How does AI cope with a signaller making a short notice decision to route a train into a different platform from booked, when the time between the route being set and the train stopping at the platform is less than a minute? You’re still only going to get a minute or so’s notice!

The same way a person monitoring traksy would, by making an educated guess from their past experience.


In reality you could make this less risky but limiting the scope to "has this train passed the last berth it could change platform" , which would be much easier to train.

 

[sh24]

For AI to work well, it needs a REALLY robust, cleansed, purged and reliable data set to learn from. It sounds, from the experienced posters above, that the railway doesn't have this.

 

[43066]

The same way a person monitoring traksy would, by making an educated guess from their past experience.


In reality you could make this less risky but limiting the scope to "has this train passed the last berth it could change platform" , which would be much easier to train.

The “educated guess” is that the booked platform will be used, because that’s what happens >90% of the time. That’s what the system does already. The last berth at which the platform could change will be just outside the platform in most cases.

The idea of not showing the platform until confirmed means no platform displayed at all until the train hits the junction just outside the station? That isn’t going to be feasible at through stations and would surely lead to people rushing for every train!

 

[Haywain]

In reality you could make this less risky but limiting the scope to "has this train passed the last berth it could change platform" , which would be much easier to train.

Is that going to work when the last berth, that determines the platform that will be used, is the one that the platform sits in and will only be occupied 30 seconds before the train arrives?

 

[saismee]

For AI to work well, it needs a REALLY robust, cleansed, purged and reliable data set to learn from. It sounds, from the experienced posters above, that the railway doesn't have this.

And with robust and reliable data, it's then better and easier to just program a consistent PIS system.

Is that going to work when the last berth, that determines the platform that will be used, is the one that the platform sits in and will only be occupied 30 seconds before the train arrives?

In that case, the CIS should be updated when the route is set for the train. There's more information available than just looking where the train is.

 

[43066]

There's more information available than just looking where the train is.

Which information?

It’s often down to a judgement call made by the signaller. Train A has sat down in platform 1 due to a door fault. Train B, also booked into platform 1, reaches the signal outside the station. After a couple of minutes train A still hasn’t moved, or the driver calls to report that the fault is worse than expected, and only at that point the signaller will decide to send train B into platform 2.

 

[bspahh]

Quite a few large firms claiming to have great AI have attempted to sell stuff into the railway space particularly in the realm of live and performance data and have walked away when they realised quite how weird, unstructured and massively undocumented signalling data actually is.

This isn't a hard problem to solve, I've done it in RTT, others have done it in at least one CIS product. It's laborious to set up due to how the data is, but it's not hard.

"Don't waste clean thought on dirty data" is a quote from David Phillips

Cleaning the input data to use in real time for a computer simulation will be hard, and simulations are only useful if you actually do something different. If it flags up an issue which is easy to interpret with common sense, then people will act on it. If its hard to interpret, then its a lot harder to get people to act.

However, you can run simulations on old data and try out different scenarios. You might then learn to spot issues that end up causing a problem.

The fix for that might be advice for the signallers, or changing the timetable or the infrastructure.

XKCD has a useful summary on this:

 

[WAB]

For a period of several weeks the same train at Chesterfield Station was always moved from P1 to P3 despite the boards etc saying P1. I used to tell people to go to P3 to save rushing.

I suspect the change will have been made to the signaller's simplifiers without being reflected in other systems.

 

[renegademaster]

The idea of not showing the platform until confirmed means no platform displayed at all

Where did I say that?
You could have the computer correct once it passed the last possible points and use the booked one until then.

 

[Tom]

What do you mean by confirming platforms? Presumably you’re still going to display the booked platform on the PIS by default until something changes given that the booked platform will be used 90%+ of the time. So this is no different to what the existing system does.

RTT works on the basis of showing the booked platform from the schedule until it can determine otherwise. This is eminently sensible behaviour. But the 'determine otherwise' is where we differ. Ultimately information in perturbed conditions is more critical than in normal conditions. My thoughts on how the industry control this information are well documented - but I've had the phrase said to me "it doesn't matter that we're wrong as long as everyone is wrong" has been said to me in the past by railway management about how they handle incorrect information.

The decision to change it will often be made at the last moment, and at the last signal before the platform, due to the signaller reacting to something happening on the ground that you can’t predict from the train’s progress so far. So under your system you’re still going to end up with a short notice CIS change in a small minority of cases (just as we have currently), unless I’m missing something?

You are correct. The decision to change may be made at the last moment. Most CIS systems however run that off the berth step of the platform so the notice really is essentially whatever the offset time is from step to arrival, in most places that's 30-45 seconds. The way our system works is to look at the signalling state around it, so the moment the route is set to the contrary and signal goes off then we can make the full determination to the contrary. That's normally a reasonable amount more time proportionately depending on where the train is. I do not deny it is still last minute if the train is at a stand outside, but it is more time than the simple berth stepping mechanism.

The fun thing is that for quite a few stations where this occurs the last 'point of no return' berth steps can be upwards of 3-5 miles away. Obviously at places like Welwyn Garden City for instance then it is just outside but i'd say it's more of a 50/50 problem.

I think most big CIS suppliers in use today have slightly more staff than are currently working on Realtime Trains!

For the record there are four of us at RTT. Three of us can write software, only one of us (me) can do the signalling route modelling.

In that case, the CIS should be updated when the route is set for the train. There's more information available than just looking where the train is.

Which is precisely what we do, but with a few more constraints as it's not quite that simple.

However, you can run simulations on old data and try out different scenarios. You might then learn to spot issues that end up causing a problem.

The fix for that might be advice for the signallers, or changing the timetable or the infrastructure.

I've been working on things like this now for the industry for the last 3 years. We're not using AI either, we're still using mathematical models and well defined simulation tools. Coming off the back of it is not always the most obvious answer either - a lot of reduced performance has resulted from brain drain caused by <insert lots of different railway things>.

 

[renegademaster]

No, instead you lose 14 billion per year. Take a look at OpenAI's revenue

This is a ridiculous comment. It's like saying it would cost 14 billion year to post a letter to your gran because Royal Mail cost that a year to run. Running a loss doesn't mean unsuccessful either. New and rapidly expanding companies tend to run a loss for their early period

Is that going to work when the last berth, that determines the platform that will be used, is the one that the platform sits in and will only be occupied 30 seconds before the train arrives?

It will work for the very common cases as described above, you do not have to make perfect the enemy of good

 

[saismee]

Which information?

It’s often down to a judgement call made by the signaller. Train A has sat down in platform 1 due to a door fault. Train B, also booked into platform 1, reaches the signal outside the station. After a couple of minutes train A still hasn’t moved, or the driver calls to report that the fault is worse than expected, and only at that point the signaller will decide to send train B into platform 2.

The route that the train is given. Tom and RTT are already proof that this is possible (to a point better than it currently is).

This is a ridiculous comment. It's like saying it would cost 14 billion year to post a letter to your gran because Royal Mail cost that a year to run. Running a loss doesn't mean unsuccessful either. New and rapidly expanding companies tend to run a loss for their early period

Certainly true, but OpenAI is struggling to find a way to make AI profitable... not exactly promising, especially when it always ends up being a gimmick (or security risk) in any product it is implemented in. I don't see the purpose of investing in a technology that is unproven, unprofitable, and unreliable when an improvement can already be made with existing tools.

 

[renegademaster]

but OpenAI is struggling to find a way to make AI profitable...

That tends to happen when you are research foundation who offers your main product for free.

when it always ends up being a gimmick

You have been using Artificial Intelligence based tools for decades without realizing. Google being the one you probably used the most. LLMs aren't not the only form of AI. Finding a "Berth of last return" for every platform would likely be something suited for more old fashioned "Neural Network" style models , doing it by hand will cost many thousands of man hours which a government that will not open their purse for anything will never pay for. Neither will paying for a few thousand traksy watchers to sit at every station happen.

 

[Horizon22]

In reality you could make this less risky but limiting the scope to "has this train passed the last berth it could change platform" , which would be much easier to train.

Which is pretty much what happens now...

Sorry, but I really don't think this holds. There's tons of low-hanging fruit just in the FTR space, and general inertia and widespread lack of subject matter understanding in-house (and reliance on very expensive consultancies to deliver .. basically anything or even just to manage projects) has meant that things have generally stagnated and there has not been enough progress made.

I won't deny there is very poor in-house knowledge of CIS/PIS systems at most operators and are reliant on getting the suppliers like Worldline / Blackbox / Infotec etc. to explain how to actually use the system, and the lack of integration has made things harder to deliver. But this is not a user-based issue, but would requires a change to the underlying systems of how the CIS works.

Manually changing a platform in CIS takes all of 5 seconds. The main issue is communications so that those making the decisions to change platforms (signallers) are advising those who control the CIS (controllers / station staff).

 

[Adam Williams]

I won't deny there is very poor in-house knowledge of CIS/PIS systems at most operators and are reliant on getting the suppliers like Worldline / Blackbox / Infotec etc. to explain how to actually use the system, and the lack of integration has made things harder to deliver. But this is not a user-based issue, but would requires a change to the underlying systems of how the CIS works.

I have no problem at all with the front-line staff, and completely agree with you here - it's not a user problem at all. Staff do their very best with the tools they're given, which I don't think are always entirely intuitive, as capable as they could be or designed in a "joined up" (considering the needs of both the direct customers (staff) and passengers) way with the functionality that would deliver the best passenger experience.

 

[saismee]

You have been using Artificial Intelligence based tools for decades without realizing.

AI-based tools being unused by the railway somewhat proves that they aren't very helpful, especially for such a simple problem. Nobody has been discussing using them for anything like this until the AI hype and marketing became a thing... maybe because it isn't all that useful in this case? I *can* see AI being used to improve timetabling, and in turn improving CIS, but that doesn't improve the edge-cases that a little thought would help with.

I'm not saying *all* CIS should be upgraded/replaced simultaneously across the UK, but maybe taking a look once customers complain could gradually improve the network over time. This is all getting *very* speculative now though, so I won't be discussing further unless a post is opened in the speculative discussion category.