RMT dispute with NR over Automatic Route Setting (ARS), but what are details ?

Sunset route said:

Traffic management interfacing via ARS means non rules qualified Train running controllers can signal trains remotely via manipulation of the train running timings (the timetable) which excludes the rules trained signaller from the loop. Without having the ability to take into account all types of level crossings and other point to point communications the signallers have, track workers requiring safe access to the line or even communication with train drivers. It’s an interface that is apparently work in progress on top of ARS existing quirks

Click to expand...

That would make more sense, isn't TM fully operational and intergrated on only a handful of routes?

Nippy said:

OA is signaller, best endeavour,
OB is wrong regulation
OC is signaller
OD is control decision
OH is ARS

Where I am, our managers are good and would prefer we got an OA for doing the 'right thing' over a massive ARS/planning issue delay.

It doesn't matter which pot it comes out, be if ops, planning or maintenance, it's all Network Rail money at the end of the day going to the TOC/FOC

With regard to the OP, I thought it was more Traffic Management the unions weren't happy with........

Click to expand...

Thanks Nippy, I don’t really keep an eye on delay codes.

Sunset route said:

Traffic management interfacing via ARS means non rules qualified Train running controllers can signal trains remotely via manipulation of the train running timings (the timetable) which excludes the rules trained signaller from the loop. Without having the ability to take into account all types of level crossings and other point to point communications the signallers have, track workers requiring safe access to the line or even communication with train drivers. It’s an interface that is apparently work in progress on top of ARS existing quirks

Click to expand...

I don't see you point here. ARS tries to implement the timetable, as amended, but as per previous posts the signaler has multiple ways to limit what ARS can do and should be using these if they are aware of some reason the timetable (with any amendments) can't work as planned. Also if there are safety-related issues such as track workers and crossings then the means of protecting these should allow for routes erroneously being set by people as well as by ARS, such as reminder devices implemented in the interlocking.

edwin_m said:

I don't see you point here. ARS tries to implement the timetable, as amended, but as per previous posts the signaler has multiple ways to limit what ARS can do and should be using these if they are aware of some reason the timetable (with any amendments) can't work as planned. Also if there are safety-related issues such as track workers and crossings then the means of protecting these should allow for routes erroneously being set by people as well as by ARS, such as reminder devices implemented in the interlocking.

Click to expand...

The point is that you have two people located in different buildings or on different floors of the same building signalling trains and to get the benefit of Train Management the ARS has to be left on but the signaller has no idea how the train running controller will alter the planned timetable on the fly so how are you supposed to alter your own plans or plan your workload.

ARS does as it is told so crap in, crap out as edwin_m says earlier

Nippy said:

OA is signaller, best endeavour,
OB is wrong regulation
OC is signaller
OD is control decision
OH is ARS

Where I am, our managers are good and would prefer we got an OA for doing the 'right thing' over a massive ARS/planning issue delay.

It doesn't matter which pot it comes out, be if ops, planning or maintenance, it's all Network Rail money at the end of the day going to the TOC/FOC

With regard to the OP, I thought it was more Traffic Management the unions weren't happy with........

Click to expand...

No. My question is purely about the RMT concerns regarding 'ARS' deployments raised by the 'report' that they are referring to:

Dear Colleague,

Safety Related Incidents and Signaller Workload Increase Caused by Automatic Route Setting (ARS)

A report from our National Operations Council representatives into ongoing concerns with the company’s plans to implement ARS has recently been considered by the National Executive Committee (NEC). At their meeting on the 16th January 2020 the NEC carried the following resolution:

That we note the report from our National Operations Council rep and the difficulties experienced in discussions with the company. We instruct the General Secretary to inform the company that we will pay no further part in any such discussions until our concerns are addressed as listed by our negotiating team in the said report.

Branches, National Operations Councils reps to be advised.

I have written to the company setting out our position in this regard and demanding they provide answers to the following set of questions:

• Who is responsible for regulating trains, the Train Running Controller, Train Running Specialist, ARS or the Signaller?

• Why are Network Rail continuing to roll known ARS generic faults into the new signalling?

• Why are Network Rail allowing ARS to break operational rules?

• Why are Network Rail putting such reliance on a flawed ARS system which has limitations that make it not fit for purpose in busy multiple train and line locations?

• Who is leading, accountable for and going to deliver on the heavily evidenced concerns from the signalling grade?

• How are Network Rail going to provide next working associations to our automated signalling?




I will keep you informed of any further developments. Please make the contents of this Circular available to all appropriate members.

Yours sincerely

Mick Cash
General Secretary

Click to expand...

https://www.rmt.org.uk/about/health...idents-and-signaller-workload-increase270120/

Sunset route said:

The point is that you have two people located in different buildings or on different floors of the same building signalling trains and to get the benefit of Train Management the ARS has to be left on but the signaller has no idea how the train running controller will alter the planned timetable on the fly so how are you supposed to alter your own plans or plan your workload.

Click to expand...

So there is an issue with actions of the Train Running Controller not being communicated in 'real time' to the Signaller which is exacerbated in ARS controlled areas ? Not necessary a failing of ARS but rather an emergent system behaviour which needs to be considered in any future introduction of ARS.

EvoIV said:

This times one million (as a driver speaking)

Click to expand...

But then signaller leaves, signaller retires, signaller on holiday, signaller on other shift, and of course the elephant in the room signaller on strike. ........Like all software ARS programming develops and improves over time, just as a young signaller becomes more adept and familiar over time with the out of profile situations caused by failures. Younger professionals are also more able to adapt and interwork with technology like ARS etc whereas someone with 40 years experience man and boy would find it harder to break with practices learned over a lifetime. This is true in most technical roles, not just those on the railway.

Sunset route said:

The point is that you have two people located in different buildings or on different floors of the same building signalling trains and to get the benefit of Train Management the ARS has to be left on but the signaller has no idea how the train running controller will alter the planned timetable on the fly so how are you supposed to alter your own plans or plan your workload.

Click to expand...

The people on the other floor aren't signaling trains, the signaler is doing that and if correctly using the tools available should prevent any unsafe situation occurring. I agree there is the potential for operational disruption, I'm not familiar with these systems but perhaps the communication of strategies and changes to signalers is what is falling down. When I was involved with ARS there was a facility to run specific trains to a contingency plan and their descriptions showed up in a different colour (separate from either ARS or non-ARS trains). If that still exists perhaps trains re-timed due to traffic management system intervention could use it?

That would be a good idea. We have had instances where the TRC has implemented changes into Traffic management without telling us and then ARS has done things we aren't expecting. Makes it much harder for us to try and manage ARS if things happen that you aren't expecting. I personally like traffic management if used correctly.

I use ARS as a tool. I have the specification for each of the desks I work. There are niggles, but if your familiar with the desks and have good handover procedures you learn which are "problem" trains. If its getting busy or degraded I can turn off all or some of it. I can ask what its doing, why its not doing something!

edwin_m said:

The people on the other floor aren't signaling trains, the signaler is doing that and if correctly using the tools available should prevent any unsafe situation occurring. I agree there is the potential for operational disruption, I'm not familiar with these systems but perhaps the communication of strategies and changes to signalers is what is falling down. When I was involved with ARS there was a facility to run specific trains to a contingency plan and their descriptions showed up in a different colour (separate from either ARS or non-ARS trains). If that still exists perhaps trains re-timed due to traffic management system intervention could use it?

Click to expand...

If I recall correctly, with traditional ARS the timetable is downloaded daily. If we now have a system in which people are dynamically changing the timetable on the fly, at what point do they become signallers?

LowLevel said:

One of our classic regular ARS fails is having a passenger train bound for Nottingham sat at a signal, either East Mids Parkway down slow or Trent South. There is also the exit there from Ratcliffe power station. If an empty coal train appears at the exit signal ARS has a nasty habit of routing the passenger train up the High Level Goods towards Toton as if it is the freight train for no apparent reason.

Click to expand...

An ARS problem may lie in the ARS software and its configuration, as supplied by the ARS contractor, or it may lie in the timetabling information input by NR, or it may be a combination of both. Getting to the route of a problem may involve investigation by both parties. However, one of the big problems with VDU workstations and ARS is actually getting problems fixed. I seem to recall an RAIB report many years ago about a level crossing that had been shown in the wrong place for many years. It was a "known problem", but had never been fixed.

Unfortunately many VDU control systems seem to have a list of "known problems" that go uncorrected for years on end, I suspect because people happily keep working around them. On the last signalling project that I worked on, we were presented with a substantial list of problems with the existing system that NR wanted corrected at the same time as we made our changes.

In theory, it should be a lot easier to make an alteration to a VDU control system than a conventional panel, as "it is only software". In my experience, the reverse is true, many times over. With a VDU control system, the original contractor has to be brought in to do the software changes, usually at considerable expense due to the amount of retesting required, so money has to be found, and it has to be programmed into that contractor's already-busy schedule. I have worked on several signalling schemes where we have been asked if we could "do something in the interlocking" to fix an indication fault or such-like, because NR couldn't afford to get the VDU contractor in to fix it properly.

When an area is being 'ARSed' , do the designers involve local signallers in the decisions?

Back in the day when I was automating manual clerical work in a completely different industry we soon learned that the projects where we asked end users what they needed and built tools to help them with their jobs were more successful than the early ones where we built a system and told them that was what they'd be using from now on.

ComUtoR said:

One of my top 10 Signaller moments.

Sig : Driver we got a points failure ahead of you. What I'm gonna do is send you out via the fast.
Me : No problem Signaller.

Cue getting routed out onto the fast then right back onto the slow at the next signal.

Sig : Sorry about that Driver, the !£)*^^$%"$$£"! ARS took over !!

Click to expand...

I think I can gather exactly where this would be!

As someone from the control side, you can indeed see occasionally whereby the ARS has made a rather bizarre decision. On congested routes it can really cause an issue. Most drivers and signalling come to an understanding after their joint frustration it appears. I agree about the "garbage in, garbage out" comments. A computer system is only as good as the code used to inform it.

Dai Corner said:

When an area is being 'ARSed' , do the designers involve local signallers in the decisions?

Back in the day when I was automating manual clerical work in a completely different industry we soon learned that the projects where we asked end users what they needed and built tools to help them with their jobs were more successful than the early ones where we built a system and told them that was what they'd be using from now on.

Click to expand...

They should be represented in the Operational Requirements Specification (ORS) workshops, the intention of which is to 'glean' info on those routes that are suitable to be included in the ARS sub-areas + any known signalling, train schedules, regulation quirks which currently the Signaller work around etc. This info once captured in the ORS, which usually contains an VDU overview / screen view map has is drawn upon to identify / name / show the various sub-areas + it includes the route table, is then signed off by Ops before its used by the ARS supplier. e.g see TREsa description which mentions NR ARS standard and 'engaging' operators etc.

https://www.railway-technology.com/products/tresa/

Belperpete said:

If I recall correctly, with traditional ARS the timetable is downloaded daily. If we now have a system in which people are dynamically changing the timetable on the fly, at what point do they become signallers?

Click to expand...

No different in principle from someone ringing in and arranging a VSTP, or Control communicating a service change to a signaling centre. The difference, as noted above, is that it seems to be happening without the signalers being aware of it. That's an issue for the traffic management system and/or the processes that manage it.

I don't really think that the timetable being updated on the fly can work well. Plenty of times you see a change appear in TRUST ages after or in the case of a system like TyrellIO hours after...

So would it be particularly bad using the example of the recent failed train outside Manchester Piccadilly when Control attempts to implement Emergency Line Block Operations as they dont know their ARS from their ELBO?

Sorry. Coat is already on...

bengley said:

In my experience ARS is very poor and makes some crazy decisions which just cause delays.

(I should add, this is mainly the case when things aren't running 100% to plan)

Click to expand...

Yes. One only has to watch what happens at Cardiff Queen Street or around Ordsall Lane Jn and Deansgate. When things are broadly running to time, it normally works fine. As soon as things start to run late, ARS usually makes it worse. I've seen up to half a dozen trains at a stand around Deansgate because ARS wanted to route a given train but that train could not move because something was in the way. Eventually the signaller intervenes and starts to untangle the mess.

Bikeman78 said:

Yes. One only has to watch what happens at Cardiff Queen Street or around Ordsall Lane Jn and Deansgate. When things are broadly running to time, it normally works fine. As soon as things start to run late, ARS usually makes it worse. I've seen up to half a dozen trains at a stand around Deansgate because ARS wanted to route a given train but that train could not move because something was in the way. Eventually the signaller intervenes and starts to untangle the mess.

Click to expand...

That does sound to me like a problem with the way that the timetable information has been input, e.g. the relative priorities given to the trains. Unfortunately, if nobody raises a proper fault report about it, it is unlikely that anything will get done about it.

edwin_m said:

No different in principle from someone ringing in and arranging a VSTP, or Control communicating a service change to a signaling centre. The difference, as noted above, is that it seems to be happening without the signalers being aware of it. That's an issue for the traffic management system and/or the processes that manage it.

Click to expand...

What is a "VSTP"?

Belperpete said:

What is a "VSTP"?

Click to expand...

Very Short Term Plan.

Dai Corner said:

When an area is being 'ARSed' , do the designers involve local signallers in the decisions?

Click to expand...

In most cases that I have been involved with, ARS was applied as part of a significant resignalling scheme, so the signallers were all new to the scheme (although probably not new to the area). Although the ARS was often one of the last things to be commissioned, as it usually can't be commissioned until the whole area has been resignalled, design would have to commence in parallel with the rest of the scheme. For example, for good decision making, ARS needs information about approaching trains from beyond the control area, which may require the underlying signalling and train describer systems designed to provide the necessary information. This kind of "architecture" requirement usually comes from the ARS technical experts, who are familiar with how the ARS algorithms work. In every case that I was involved with, there was always a local signalling operations representative as part of the review committee. However, to be honest, until the signallers are familiar with the new control system, the new layout and its operation, and in particular how ARS works, their input is usually limited.

As I explained previously, the ARS relies on both its configuration, which is done by the ARS supplier, and the timetable information which is provided by and routinely updated by NR. For example, ARS can set a route whenever a train approaches, or wait for a set departure time, or wait until a trigger (such as a TRTS plunger being pressed) is received. This is all defined in the timetable data for a particular train. However, the timetablers can't select the latter option if the signalling system and ARS haven't already been pre-configured so that the ARS can see the relevant trigger. Likewise, where there are conflicting routes, ARS can be configured to set on a first-come basis, according to train priority, according to how much delay it would cause if you let the wrong one in first, or can be told that a certain train must go first. The algorithms for deciding which train to route first are quite sophisticated, but rely very heavily on the timetable information input by NR as regards priorities, requirements on train ordering, etc.

Most of the ARS problems that I have ever encountered have almost-always been down to the timetabling information, rather than the underlying way that ARS has been configured. For example, in the cases mentioned by Bikeman78, it sounds as though the timetables have simply been input so that ARS signals the trains in timetable order. As he says, this is all very well when things are running to time, but hopeless when they are not. It is certainly not making the best use of ARS's capabilities. ARS is perfectly capable of making sensible decisions when trains are running late and out of order, but it can only do so if the timetable information allows it do so. Such timetabling problems should be relatively-easily cured - provided that they get reported back to the relevant people. If people just shrug them off as "ARS is not up to the job" then it will never get better.

Belperpete said:

If I recall correctly, with traditional ARS the timetable is downloaded daily. If we now have a system in which people are dynamically changing the timetable on the fly, at what point do they become signallers?

Click to expand...

It's a change to the timetabling data that ARS signals. The controller's are acting as timetablers based on updated information for the day.

As for safety concerns, if Milton Keynes had sent through an STP amended plan for a small section of the day, would the signallers know in advance the ARS would behave differently to yesterday? If not then there's no real difference is there?

hick said:

It's a change to the timetabling data that ARS signals. The controller's are acting as timetablers based on updated information for the day. As for safety concerns, if Milton Keynes had sent through an STP amended plan for a small section of the day, would the signallers know in advance the ARS would behave differently to yesterday? If not then there's no real difference is there?

Click to expand...

I agree that there shouldn't be any safety concerns. Trackworkers should be properly protected by inhibiting the setting of routes or clearing of signals, for example. And ARS can always be disabled.

However, there are other issues. For example, I understand that the signallers can interrogate the ARS to find out relevant information (getting to the limits of my knowledge here....). If they interrogate a particular train, and are satisfied with what they find (e.g. that a freight train is being held to allow a higher priority train through), but then the data is subsequently changed without them knowing, and ARS immediately signals the freight out without waiting its turn, I could well understand them being unhappy. Likewise if pressure were to be put on signallers to keep ARS working (so that the timetablers can do their job and dynamically intervene) when the signaller might prefer to disable ARS, I could well imagine them not being happy.

The signaller is supposed to be able to signal the area correctly if he has to turn ARS off for any reason. The signaller therefore needs to be kept up-to-date with changes to timetables. If timetable changes are made direct into ARS without informing the signaller, then patently the signaller isn't being kept up-to-date, and so may not be able to carry out their job correctly, but could still be left carrying the can for consequent delays.

So I can well understand that signallers may have concerns about these developments. As timetablers get more and more involved in the dynamic routing of trains, the line between timetabler and signaller gets more and more grey. I suspect that they not unreasonably want to set some lines in the sand.

hick said:

It's a change to the timetabling data that ARS signals. The controller's are acting as timetablers based on updated information for the day.

As for safety concerns, if Milton Keynes had sent through an STP amended plan for a small section of the day, would the signallers know in advance the ARS would behave differently to yesterday? If not then there's no real difference is there?

Click to expand...

The problem is we are moving away from a daily timetable upload and that’s it, to a world where someone can change a trains route before its gets to its next timing point we are or soon will be down 10mins or less timetable alterations by TRCs that can or will have an effect on ARS.

'Normal' ARS / S-ARS: the timetable is, we are told uploaded 3 times a day, however this will not take into account VSTP moves, and more than likely no STP's either, unless it's a few days since 'planned'.
the timetables are uploaded, by Train Planning at MK, who paid us a visit last year, where we complained about trains missing, times wrong, regulation awry etc, seems it's the same old workload issue, .
SARS also has trouble identifying trains too, if you have an early morning train, with say a headcode 1H00, maybe at 0600, and comes over from the depot at maybe 0300 or so, IF there is another 1H00 the previous evening, it will associate this train, and clear the route thinking it's late, so it is taken out of ARS, to avoid this, can then be overlooked ! It does help Signallers control a bigger area on an MCS workstation, and can cut down the Siggies workload, it also has the potential to increase it ! Workload is another story with NX v MCS !

Here's a perfect example of why ARS is crap, particularly in central Manchester.

I was working this train from Preston to Manchester Airport: https://www.realtimetrains.co.uk/train/Y75113/2020-02-11/detailed

We left Preston 9 late but due to both the superior performance of the class 397 and the slack in the timetable on the approach to the Castlefield corridor, I presented at Ordsall Lane only 3 late. I got checked down and stopped at Castlefield Jn and was held for two trains from the CLC towards Oxford Road.

1) https://www.realtimetrains.co.uk/train/Y27587/2020-02-11/detailed
2) https://www.realtimetrains.co.uk/train/Y57308/2020-02-11/detailed

Now I could possibly see the case for holding me for the first one (although it failed PPM anyway) especially as it went into the bay at Oxford Road, so wouldn't have delayed me by more than a minute. I then continued to sit there waiting and the second one came past several minutes later. Had I been allowed through either first, or second, instead of third, I would have been bang on time by the Airport and any passengers with connections at Piccadilly would have had a good chance of catching them.

Again, if I'd been let through at least before the second train, I'd have been through Oxford Road and on my way to Piccadilly before he'd even presented at Castlefield Jn but obviously ARS will just regulate based on whichever train should have gone through first.
This is not the correct way to do things on such a congested bit of line - indeed, with the thinned out service at that time of the night, trains being delayed by 10 minutes can't be called 'congestion' so much as it must be put down to bad regulation.

It's also worth mentioning that all this also delayed the previously on time Northern Chat Moss stopper: https://www.realtimetrains.co.uk/train/Y57679/2020-02-11/detailed

(I will add that despite this, we made PPM at the Airport, but that's not really the point)

swills said:

'Normal' ARS / S-ARS: the timetable is, we are told uploaded 3 times a day, however this will not take into account VSTP moves, and more than likely no STP's either, unless it's a few days since 'planned'.
the timetables are uploaded, by Train Planning at MK, who paid us a visit last year, where we complained about trains missing, times wrong, regulation awry etc, seems it's the same old workload issue, .
SARS also has trouble identifying trains too, if you have an early morning train, with say a headcode 1H00, maybe at 0600, and comes over from the depot at maybe 0300 or so, IF there is another 1H00 the previous evening, it will associate this train, and clear the route thinking it's late, so it is taken out of ARS, to avoid this, can then be overlooked ! It does help Signallers control a bigger area on an MCS workstation, and can cut down the Siggies workload, it also has the potential to increase it ! Workload is another story with NX v MCS !

Click to expand...

That seems mad ! Surely there must be loads of times that headcodes are re-utilised, but in interim can't capacity planning make sure that they do not re-utilise head codes within a 24hr period or is that too ambitious / impractical? Who actually decides head codes is it purely NR or do TOCs have a say ?