Commuter knew better than apps

[Steve Harris]

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.

You keep on having this fascination with AI, but have overlooked that automation doesn't = AI. There are probably millions if not billions of automated systems in the world that don't use AI. So the 14 billion figure you keep quoting is totally irrelevant.

AFAIA the current automated CIS system is far cheaper than employing enough staff to keep a beady eye on what the signalling system is doing and updating the customer in a timely manner compared to the poorly implemented automated CIS systems we currently have. Hence the statement I made in post #62 about computers (note "computers" doesn't necessarily mean AI) being cheaper than people. Why else do you think Automatic Route Setting has been developed for signalling systems (because it's cheaper), you just need to use logic to understand why it's cheaper, and post #65 that in some places the automated CIS can be improved.

 

[saismee]

You keep on having this fascination with AI, but have overlooked that automation doesn't = AI. There are probably millions if not billions of automated systems in the world that don't use AI. So the 14 billion figure you keep quoting is totally irrelevant.

AFAIA the current automated CIS system is far cheaper than employing enough staff to keep a beady eye on what the signalling system is doing and updating the customer in a timely manner compared to the poorly implemented automated CIS systems we currently have. Hence the statement I made in post #62 about computers (note "computers" doesn't necessarily mean AI) being cheaper than people. Why else do you think Automatic Route Setting has been developed for signalling systems (because it's cheaper), you just need to use logic to understand why it's cheaper, and post #65 that in some places the automated CIS can be improved.

Did you not read any of my posts? I am explicitly stating that we should be using non-AI automation... I have never said that all automation is AI? My post that you quoted even says AI is a worse idea than replacing the existing system with people manually doing it... the existing system being *automation without AI*.

 

[Steve Harris]

Did you not read any of my posts?

Yes thank you, I did, however I don't think you read mine (see below).

I have never said that all automation is AI?

You said

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

in reply to

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

You might not of said all automation is AI, but you was clearly inferring it as you replied AI to the my "computer". So it's pretty clear to me that you misread my post and thought "computer" = AI, when in fact I was talking about computing! (If i was talking about AI i would of clearly said AI and not computing). In fact I followed up with

"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. "

to try and reaffirm I was talking about computing/automation in general and not specifically AI to clear up any misunderstanding. However, you have mentioned AI numerous times in your posts, yet I've only mentioned it once (in reply to your post) and you think I haven't read your posts! (Some of which IMHO aren't concise and to the point, so it has been hard to understand what you was actually saying, hence the confusion).

It took another post of mine for you to reply and make it clear that we are in agreement that AI is not needed to solve the poor CIS automation issue.
Would I be correct in saying that ?

And automation (generally speaking and excluding AI) is cheaper than employing people to constantly update the CIS with platform changes ? (Which is the point i was originally trying to make). Do we agree on that ?

 

[saismee]

Yes thank you, I did, however I don't think you read mine (see below).

I stand corrected, my bad. I definitely misinterpreted your original post.

 

[Frontera2]

[Deleted]

 

[eoff]

The situation I used to get at Waverley was that a morning North Berwick to Haymarket train would get routed to a terminating platform (not sure if that is the correct term). so while on the train I could see it was now not going to Haymarket, often there was no announcement of this.

 

[35B]

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 work for one of those consultancies, and have lost count of the number of times we’ve had a good idea about how a client could save money &/or earn additional revenues by doing something simple and low cost

The reality is that in large organisations, public or private, there needs to be a critical mass trigger before something will happen. That may be complaints, political pressure, or financial - or it may just be that other stuff is more urgent and gets attention, crowding out other stuff.

The effect, perversely, it can be much easier to do one large project that covers the scope of several small ones, than any of the small ones individually.

 

[Dfatcontroller]

The situation I used to get at Waverley was that a morning North Berwick to Haymarket train would get routed to a terminating platform (not sure if that is the correct term). so while on the train I could see it was now not going to Haymarket, often there was no announcement of this.

Edinburgh Signalling Centre often do this at the last minute and have the understanding from the operator that it is better overall for train running at Waverley.
Usually due to the NBW/HYM service running late, or something else approaching late from the west which blocks the through platform.

For the passengers on the train to know; the following chain of events would need to take place with 60-120 seconds:

1) Signaller would need to inform their Network Rail Train Running Controller (NRTRC).
2) NRTRC tells the ScotRail Train Service Delivery Manager (SRTSDM).
3) SRTSDM needs to find the turn number for the Conductor on the service.
4) SRTSDM calls the Traincrew Supervisor at Waverley to obtain the Conductor's name and phone number.
5) SRTSDM calls the Conductor to let them know.

That's without the SRTSDM also informing the Customer Information Manager so the early termination can be communicated to the passengers.

As you can expect; the service is probably in a bay platform and detrained by the time all this takes place if the decision is last minute.
And assuming all this can happen instantaneously with nothing else going on.

 

[eoff]

Edinburgh Signalling Centre often do this at the last minute and have the understanding from the operator that it is better overall for train running at Waverley.
Usually due to the NBW/HYM service running late, or something else approaching late from the west which blocks the through platform.

For the passengers on the train to know; the following chain of events would need to take place with 60-120 seconds:

1) Signaller would need to inform their Network Rail Train Running Controller (NRTRC).
2) NRTRC tells the ScotRail Train Service Delivery Manager (SRTSDM).
3) SRTSDM needs to find the turn number for the Conductor on the service.
4) SRTSDM calls the Traincrew Supervisor at Waverley to obtain the Conductor's name and phone number.
5) SRTSDM calls the Conductor to let them know.

That's without the SRTSDM also informing the Customer Information Manager so the early termination can be communicated to the passengers.

As you can expect; the service is probably in a bay platform and detrained by the time all this takes place if the decision is last minute.
And assuming all this can happen instantaneously with nothing else going on.

Mmm, how about....

The driver notices he is routed to a non through platfrom, lets the passengers know that the service is terminating.

 

[Surreytraveller]

What you need, is what existed before these automated CIS systems came in. You need staff at key locations, with the local operational knowledge, who communicate with the Signallers, updating the CIS boards manually. Call them Station Supervisors.

 

[LAX54]

Mmm, how about....

The driver notices he is routed to a non through platfrom, lets the passengers know that the service is terminating.

or, if unaware, will stop at the signal, and then call the Signaller on the GSM-R, once at a stand, to advise of a possible 'wrong route'

== Doublepost prevention - post automatically merged: 12 Jan 2025 ==

You keep on having this fascination with AI, but have overlooked that automation doesn't = AI. There are probably millions if not billions of automated systems in the world that don't use AI. So the 14 billion figure you keep quoting is totally irrelevant.

AFAIA the current automated CIS system is far cheaper than employing enough staff to keep a beady eye on what the signalling system is doing and updating the customer in a timely manner compared to the poorly implemented automated CIS systems we currently have. Hence the statement I made in post #62 about computers (note "computers" doesn't necessarily mean AI) being cheaper than people. Why else do you think Automatic Route Setting has been developed for signalling systems (because it's cheaper), you just need to use logic to understand why it's cheaper, and post #65 that in some places the automated CIS can be improved.

I wouldn't hold up ARS or SARS as a good example, its 'OK' whilst everything is booked and on time, (assuming its been programmed correctly!) once it all goes a bit awry with late running, or a small incident, it can be hopeless !

 

[Dfatcontroller]

Mmm, how about....

The driver notices he is routed to a non through platfrom, lets the passengers know that the service is terminating.

Driver doesn't make announcements.

 

[WAB]

Edinburgh Signalling Centre often do this at the last minute and have the understanding from the operator that it is better overall for train running at Waverley.
Usually due to the NBW/HYM service running late, or something else approaching late from the west which blocks the through platform.

For the passengers on the train to know; the following chain of events would need to take place with 60-120 seconds:

1) Signaller would need to inform their Network Rail Train Running Controller (NRTRC).
2) NRTRC tells the ScotRail Train Service Delivery Manager (SRTSDM).
3) SRTSDM needs to find the turn number for the Conductor on the service.
4) SRTSDM calls the Traincrew Supervisor at Waverley to obtain the Conductor's name and phone number.
5) SRTSDM calls the Conductor to let them know.

That's without the SRTSDM also informing the Customer Information Manager so the early termination can be communicated to the passengers.

As you can expect; the service is probably in a bay platform and detrained by the time all this takes place if the decision is last minute.
And assuming all this can happen instantaneously with nothing else going on.

Or, the SRTSDM could use a vaguely modern telephone concentrator with the numbers of all Scotrail guards on it and skip steps 3 and 4. As for the CIM being advised and putting the message out, that's 30 seconds on Tyrell if that.

And of course, the TRCs should really be looking ahead to see if a turn would be beneficial to train running. The sort of delays which would trigger this situation will be known about in advance - just look for something red on TMIS.

 

[Haywain]

Edinburgh Signalling Centre often do this at the last minute and have the understanding from the operator that it is better overall for train running at Waverley.

I find it difficult to believe that signallers are making these sort of decisions independently, placing crew and stock out of position for their next workings.

 

[Dfatcontroller]

Or, the SRTSDM could use a vaguely modern telephone concentrator with the numbers of all Scotrail guards on it and skip steps 3 and 4. As for the CIM being advised and putting the message out, that's 30 seconds on Tyrell if that.

And of course, the TRCs should really be looking ahead to see if a turn would be beneficial to train running. The sort of delays which would trigger this situation will be known about in advance - just look for something red on TMIS.

Once the vaguely modern telephone concentrator is supplied - that could very well be an option! Steps 3 & 4 would still be required - just without the telephone number being relayed!
Agree with your second line too - when do they start doing that?

== Doublepost prevention - post automatically merged: 12 Jan 2025 ==

I find it difficult to believe that signallers are making these sort of decisions independently, placing crew and stock out of position for their next workings.

But they aren't. That move is self contained.
Terminates at Haymarket; reverses at Haymarket West and returns to Waverley empty.

 

[WAB]

I find it difficult to believe that signallers are making these sort of decisions independently, placing crew and stock out of position for their next workings.

Things are slowly changing on the railways - the official chain of command (TOC service controller -> NR TRC -> signaller) is being eroded, especially when it's a blindingly obvious and common decision.

== Doublepost prevention - post automatically merged: 12 Jan 2025 ==

Once the vaguely modern telephone concentrator is supplied - that could very well be an option! Steps 3 & 4 would still be required - just without the telephone number being relayed!
Agree with your second line too - when do they start doing that?

Put in the headcode, see the guard's name, select their name on the concentrator, tell them the info. I've seen this all done in 40 seconds - it's magical to watch.

Perhaps the TRCs just need a bit of 'encouragement'

 

[Dfatcontroller]

Put in the headcode, see the guard's name, select their name on the concentrator, tell them the info. I've seen this all done in 40 seconds - it's magical to watch.

Not in Scotland you haven't!

1) Put in headcode
2) see diagram ID
3) Phone Traincrew Supervisor
4) Obtain name (and phone number - which your concentrator would eradicate)
5) Phone Conductor

 

[Horizon22]

Mmm, how about....

The driver notices he is routed to a non through platfrom, lets the passengers know that the service is terminating.

Sure, but how are those who are in charge of the CIS for both the platform and train running info supposed to update everything?

== Doublepost prevention - post automatically merged: 12 Jan 2025 ==

I find it difficult to believe that signallers are making these sort of decisions independently, placing crew and stock out of position for their next workings.

It can happen, but it is more likely TOC control have made the decision and informed the signaller / train running control of the amendment.

== Doublepost prevention - post automatically merged: 12 Jan 2025 ==

Things are slowly changing on the railways - the official chain of command (TOC service controller -> NR TRC -> signaller) is being eroded, especially when it's a blindingly obvious and common decision.

Not that much. Signallers and TRCs making independent decisions will be terrible for TOCs trying to plan service recovery when the former has limited/no knowledge of crew or stock plans.

 

[IanXC]

As I understand it there are two ways of creating a CIS.

Timetable based - this will take the timetable of the day, and any amendments sent by TOCs and displays this until it has reason to show something else - such as a train arriving in the berth of a different platform than the one it is booked in. This kind of system typically won't pick up on the day diversions and very short notice movements as far as announcing 'fast train approaching' etc, as these trains are not known in the timetable data it has.

Movement based - this looks at the Train Describer feed, whats approaching, and checks for these trains in the timetable/TOC amendment data and announces that, if it doesn't find a match it will announce fast train approaching - on the basis that something is coming and people need to be warned. The only supplier I know of that works this way, also looks at the Train Describer for routes being set and once a train's route reaches a platform, takes that as its platform and will announce a change on this basis.

 

[Steve Harris]

I wouldn't hold up ARS or SARS as a good example, its 'OK' whilst everything is booked and on time, (assuming its been programmed correctly!) once it all goes a bit awry with late running, or a small incident, it can be hopeless !

I was using it as an example that it's been brought in so you can have less signallers (staff). Thereby saving on wages, NI, pension contributions etc etc. As automation is cheaper than employing enough staff to undertake a task. The problem seems to be that most automation on the railway seems to be rather poor. ARS, SARS and the last minute notification of a platform changes being good examples.

== Doublepost prevention - post automatically merged: 12 Jan 2025 ==

What you need, is what existed before these automated CIS systems came in. You need staff at key locations, with the local operational knowledge, who communicate with the Signallers, updating the CIS boards manually. Call them Station Supervisors.

As I said before upthread, that won't happen due to cost. People are more expensive than employing a computer.

 

[Surreytraveller]

As I said before upthread, that won't happen due to cost. People are more expensive than employing a computer.

Not if you're using existing staff

 

[Steve Harris]

Not if you're using existing staff

Very true. But do they actually have the time to take on these extra duties? And will the unions allow staff to do these extra duties without a pay increase?? (If the answers no to the latter it's still extra cost).

 

[Surreytraveller]

Very true. But do they actually have the time to take on these extra duties? And will the unions allow staff to do these extra duties without a pay increase?? (If the answers no to the latter it's still extra cost).

Unions for station staff aren't that powerful. These days station staff aren't that busy, not like pre-privatisation

 

[43066]

Not if you're using existing staff

Which staff specifically do you propose will be able to spend their days monitoring CIS systems, which work fine automatically most of the time anyway?

== Doublepost prevention - post automatically merged: 12 Jan 2025 ==

These days station staff aren't that busy, not like pre-privatisation

Which station staff specifically? They all have other jobs to do!

 

[WAB]

Not in Scotland you haven't!

1) Put in headcode
2) see diagram ID
3) Phone Traincrew Supervisor
4) Obtain name (and phone number - which your concentrator would eradicate)
5) Phone Conductor

It sounds like you lot north of the border need to get with the times! There are a couple of solutions on the market which can get you live crew and traction allocations on timetables, diagrams, carriage working notices, and with traincrew information available with just one click.

 

[Horizon22]

As I understand it there are two ways of creating a CIS.

Timetable based - this will take the timetable of the day, and any amendments sent by TOCs and displays this until it has reason to show something else - such as a train arriving in the berth of a different platform than the one it is booked in. This kind of system typically won't pick up on the day diversions and very short notice movements as far as announcing 'fast train approaching' etc, as these trains are not known in the timetable data it has.

Movement based - this looks at the Train Describer feed, whats approaching, and checks for these trains in the timetable/TOC amendment data and announces that, if it doesn't find a match it will announce fast train approaching - on the basis that something is coming and people need to be warned. The only supplier I know of that works this way, also looks at the Train Describer for routes being set and once a train's route reaches a platform, takes that as its platform and will announce a change on this basis.

Most systems do both in reality. The base timetable is uploaded overnight and can be manually adjusted as required. However if alterations are picked up in the train describers for the relevant berths, then this will automatically update for platforms too.

The gripe appears to be that the latter is not doing this quickly enough automatically when the route provided makes the original timetables platform impossible.

 

[DailyCommuter]

Another last minute platform change for 1P92 at Maidenhead today (the original train that sparked this thread). It only platform altered on CIS and the National Rail app once it was in the platform berth (as shown on OTT). However there are 7 signal berths before that which would have indicated it was impossible to reach the booked platform. The train was routed into Platform 4, but the CIS didn't pickup on that. Surely this doesn't need AI or more staff, just the CIS trigger to be based on a different point and/or to use routing rather than just occupy.

This train has not made the booked platform for 5 days in a row, suggesting maybe a planning issue too.

 

[Dfatcontroller]

It sounds like you lot north of the border need to get with the times! There are a couple of solutions on the market which can get you live crew and traction allocations on timetables, diagrams, carriage working notices, and with traincrew information available with just one click.

I know - I used to use it south of the border!
No-one wants to spend money though!!

 

[Horizon22]

Another last minute platform change for 1P92 at Maidenhead today (the original train that sparked this thread). It only platform altered on CIS and the National Rail app once it was in the platform berth (as shown on OTT). However there are 7 signal berths before that which would have indicated it was impossible to reach the booked platform. The train was routed into Platform 4, but the CIS didn't pickup on that. Surely this doesn't need AI or more staff, just the CIS trigger to be based on a different point and/or to use routing rather than just occupy.

This train has not made the booked platform for 5 days in a row, suggesting maybe a planning issue too.

As has been stated several times, Platform 5 remains an option if running on this line. Just because it cannot go into the booked platform, does not mean any particular alternative platform is certain and then CIS can not display an “or”.

I would suggest raising your concerns with GWR who may be able to investigate further why it is not going into the booked platform and also a response on why the platform is not being amended.

 

[DailyCommuter]

As has been stated several times, Platform 5 remains an option if running on this line. Just because it cannot go into the booked platform, does not mean any particular alternative platform is certain and then CIS can not display an “or”.

Hence my suggestion/query on using routing rather than occupancy, as that would have changed the CIS several mins sooner.

If occupancy has to be used, could you design the system to default to platform 4 for a train booked for the Main but running on the Relief and change again to Platform 5 if it occupies that berth. That's much rarer and passengers would already be on the right island platform. That would give people with mobility issues time to cross over, whereas walking across to the other platform face needs less notice.

It could be designed so that it's generic logic for stations with two pairs of tracks and config data held per station/per platform so that its not unique coding per location.

It wouldn't solve every situation, but at least a percentage would be better than now.