• Our new ticketing site is now live! Using either this or the original site (both powered by TrainSplit) helps support the running of the forum with every ticket purchase! Find out more and ask any questions/give us feedback in this thread!

'SG' - Regulation Question

Status
Not open for further replies.

The Puddock

Member
Joined
10 Jan 2023
Messages
482
Location
Frog
Some of our Signallers know the working quite well. Kudos to them and some days they are pretty good at sorting out trains.
I’m sure they have but that knowledge has come to them secondhand or through trial and error. They don’t have access to the systems that would allow them to proactively look at traincrew working before making regulating decisions because that belongs to the TOCs.
 
Sponsor Post - registered members do not see these adverts; click here to register, or click here to log in
R

RailUK Forums

Tomnick

Established Member
Joined
10 Jun 2005
Messages
5,933
You’re right, it happens all too often up and down the network but I feel I should point out for the sake of balance that signallers don’t* have any access to systems showing planned or live traincrew diagrams. Unless someone from the TOC deigns to tell them - usually through the NR Train Running Controller - they have no way of checking whether the crew is booked relief and what they do next. Most will take a note of the common traps after they’ve happened once but that doesn’t help when crew workings are disrupted and no one bothers to tell the box.


*as always on the railway there may be some odd places I’m not aware of where the box can somehow see the crew wrokings but that is very much the exception
Absolutely, and there's no criticism intended on my part in the Hubberts Bridge example above. It's an amusing example (none found it more so than the signallars involved), but does highlight just how disjointed the information flow can be.

The problem on our side is that the process for monitoring the effects of late running on traincrew diagrams seems very far from robust. Sometimes, our traincrew supervisor will notice and either arrange a fresh crew from somewhere to pick up the next bit, or at least tell Control that there'll be a delay. More often than not, though, everyone on our side will be oblivious until the train's actually stood at the platform with no relief, unless the traincrew take it upon themselves to raise the issue (which isn't always possible, especially if it's just the driver who's affected – a recent operational incident happened primarily because the driver was worrying about the impact of a delay on his next working, and trying to let the TCS know via his Guard).
 

ComUtoR

Established Member
Joined
13 Dec 2013
Messages
9,562
Location
UK
Absolutely, and there's no criticism intended

None from me either.

We all understand why it happens and often find it somewhere between incredulous and amusing.

but does highlight just how disjointed the information flow can be.

Not just disjointed. It's incredibly slow and inefficient. If my unit developed a fault, I need to call 3 different departments before any decision gets made. Often is a call to the Sig, who tells me to call control, who tell me to call maintenance, then I call everyone back repeating the same information. The Signallers calls their control, who call out control, and then calls me back.

Same with some regulation / disruption. The back and forth will exacerbate the delay.

We had another one the other day where a Driver was routed via a diversionary but they didn't sign it. In this case the Signaller knows that all of us should do and they know which diagrams don't/can't get diverted. It was just this odd Driver who didn't. The delay and the issue was attributed to a planning error.
 

Surreytraveller

On Moderation
Joined
21 Oct 2009
Messages
3,905
Some of our Signallers know the working quite well. Kudos to them and some days they are pretty good at sorting out trains.

With integrated control centres it should be better. Generally, during disruption it works well as everyone is communicating. It's those everyday moments where train a goes here and train b goes there and then oops.
I think integrated controls has allowed train crew diagrams to become more "efficient", which is fine when a couple of trains are running late, but its impossible for Controllers to check every driver's diagram, let alone tip Signallers off, during times of disruption
 

TheBigD

Established Member
Joined
19 Nov 2008
Messages
2,043
Had the same thing on Friday. Got checked at Stoke Jn for no real reason having been 4 late off Grantham.

Get to Werrington Jn and am brought down to a dead stop because it pulled off for a liner running 7-10 minutes early to come off the Joint line which is booked an hour in the yard at Eastfield to boot. It doesn't get the road inside and promptly sits there on the UDS stopping us from moving forward.

Eventually someone noticed and pulls off for us to go round it on the up fast by which time we get to New England North 10 late.

Just in time to sit there as the down Edinburgh is routed into the platform and eventually pulled off for, but then we wait for the Leeds to be signalled into platform 5 before we finally get the road into platform 4 having watched the Ipswich disappear into the distance as booked for us to follow all the way to Ely.

Further delay then at Ely for various services as that connection to Ipswich is both popular and 2 hourly and to be fair to GA if you have passengers for Bury St Edmunds they'll usually hold it there for you to catch up, which they did.

2 minutes delay at Nottingham becomes 24 minutes at Norwich and if I'd been fussed about my PNB would probably have resulted in the back working being part cancelled at Nottingham too.

All put down as far as I know to overhead wire issues between Newcastle and Edinburgh.

I understand the modern issues with signaller workload with things like line blockages but there is literally no area I work that performs better with workstations and ARS than it did as an NX panel.

It's not just the train regulation that has gone south since transfer to York ROC.

Things like neighbouring signalboxes not being advised of possessions/line blockages that they have granted which go in to another boxes area of control.
SBSIs not being followed which then causes problems on other signalboxes' area of control.
Etc etc...

It's a daily occurrence now but nothing seems to have improved since the transfer.
 
Last edited:

Royal351

Member
Joined
27 Apr 2022
Messages
84
Location
Redhill
Evening and Seasons Greetings,

Just a quickie to the 'Fish watchers, Ivory Tower residents, Lever pullers, and general slipper wearing sofa sitters'... ♥♥ (you know I love ya) ♥♥

If you had two trains sitting at terminal, both late and service affecting. However, one had a TRTS and the other didn't. What would your actions be ? I've spoken about this before and some will regulate and pull the road without a TRTS and some will wait. Would you call the platform/control point to find out why or just wait for the TRTS ? I've also heard that you folks are more and more restricted in your actions. How bad is it or can you still make the hard calls ?

@Llanigraham is there a difference with a local box compared to a ROC ?
@Tomnick I'm interested in your experiences after your conversion to the light side of the force



*TRTS - Train Ready To Start (often a plunger on the station to send a signal that shows a service is 'ready'
*SG - GSMR button to send a message to the controlling Signaller
*GSMR - Global System for Mobile Communications-Railway (technically GSM-R)
*ROC - Rail Operations Center


Cheers in advance :wub:

Tbh for my box, I just get the one that TRTS out of the way, cause A) The station staff there are good and don't TRTS unless they see the driver in the cab and B) it frees up a platform. The regulating policy for us, is Right Time, Right Path. If they're late then unless I get told to send something first either by the Adj Box or Control. Then the one thats been TRTS goes first
 

WAB

Established Member
Joined
27 Jun 2015
Messages
1,299
Location
Anglia
The problem on our side is that the process for monitoring the effects of late running on traincrew diagrams seems very far from robust. Sometimes, our traincrew supervisor will notice and either arrange a fresh crew from somewhere to pick up the next bit, or at least tell Control that there'll be a delay. More often than not, though, everyone on our side will be oblivious until the train's actually stood at the platform with no relief, unless the traincrew take it upon themselves to raise the issue (which isn't always possible, especially if it's just the driver who's affected – a recent operational incident happened primarily because the driver was worrying about the impact of a delay on his next working, and trying to let the TCS know via his Guard).
Is there no system which links train running data to crew rosters, highlighting potential delays to their subsequent trips?
 

Horizon22

Established Member
Associate Staff
Jobs & Careers
Joined
8 Sep 2019
Messages
11,010
Location
London
Is there no system which links train running data to crew rosters, highlighting potential delays to their subsequent trips?

There are some online systems integrated but they’re not as advanced as you might expect in most places.

In many cases a controller has 3 different systems, each of which they need to check separately and/or liaise with other colleagues.
 

CarrotPie

On Moderation
Joined
18 Mar 2021
Messages
1,128
Location
‎
Everywhere I've seen on station platforms is TRTS 2 mins before departure time (or if running late as soon as available). Where it's self TRTS by crew running late, then there will be inevitable delays.
At Waterloo TRTS is done by dispatch staff "at -3.5 mins", though I get her this is unusual.
 

Surreytraveller

On Moderation
Joined
21 Oct 2009
Messages
3,905
How does the structure of a Control function allow diagrams to change?
Because any issues with the diagrams can just be left to Control to deal with. And because Controls deal with the issues, the issues don't surface so don't get sorted out, as there are perceived to be no issues
 
Status
Not open for further replies.

Top