Automatic Route setting

[Keith]

When I was at BRHQ, I certainly remember frequent references to this new system called ARS going in at Three Bridges. However, wasn't there something called Junction Optimisation (I think there was a third word in the name, such as System or Technique) before that? I've a vague idea that was being considered for somewhere in Scotland, but I don't remember if it ever went in.

Just before posting this, I thought I'd try the old googling, and came up with a paper on JOT by Malcolm Savage, written in 1968/9. This system successfully did the same as ARS at Glasgow Central [full marks to my memory just for once! ] in the late 1970s, except that its output was on a screen for the signalmen to use, rather than actually setting the routes itself. Full story here

[Andy Overton]

Thanks Keith, some interesting material there

[rswSomerset]

The automatic route setting controlled the area between Copyhold and Keymer Junctions, inclusive. However, for it to make good enough regulating decisions, it had to use indications received from much farther afield - ISTR that this extended at least as far North as Purley, and South almost to Brighton. So the counting device Graham's referring to must have been a separate initiative. Regarding the ARS (sic) that forms part of IECC's, I'm dying to find out how it makes its decisions based on the layout, the timetable, and the actual reported train running. Obviously a large subject, so I'm not expecting a full explanation on here, but if anyone knows where I can read it up, I'll be very interested to know!

[Peter Gibbons]

I can confirm that It also covered Keymer Junction, although of course the signaller was still required to operate Keymer CCTV Crossing (on the the branch to Lewes), as required. It did not include eiither the Preston Park area or Balcombe Tunnel Junction. ARS remains out of use and in any case the section of line between Balcombe Tunnel Junction and Copyhold Junction did have some signalling alterations a couple of years ago.

[panelbeater2]

Three Bridges and Wimbledon both have a system called multiple select auto which was invented by a Three Bridges techician who's name I've forgotten, basically when the auto button is pressed the signal goes into auto and stays there but if the auto button is pressed any more an incramental counter advances (up to 9) and when however many trains have gone past the signal that was selected the auto drops out and the route cancels after the last train past.
Graham

The MSA control at Three Bridges described by Graham was actually applied to T70 Up Vic Fast Line approaching Selhurst. The number of "Auto" cycles was selected by a separate surface mounted push button, rather that the Auto button itself. Additionally, it had a digital countdown indicator, to show the number of cycles set/left.
The control was removed when Panel 1A was divided into 1A and 1C

[rower40]

Regarding the ARS (sic) that forms part of IECC's, I'm dying to find out how it makes its decisions based on the layout, the timetable, and the actual reported train running. Obviously a large subject, so I'm not expecting a full explanation on here, but if anyone knows where I can read it up, I'll be very interested to know!

Good luck with that. Various manufacturers of competing products would love to get their hands on such information. I am not at liberty to divulge my 28 years' experience in this field. I've no idea what's been published and is in the public domain. Sorry...

[kbarber]

Regarding the ARS (sic) that forms part of IECC's, I'm dying to find out how it makes its decisions based on the layout, the timetable, and the actual reported train running. Obviously a large subject, so I'm not expecting a full explanation on here, but if anyone knows where I can read it up, I'll be very interested to know!

Good luck with that. Various manufacturers of competing products would love to get their hands on such information. I am not at liberty to divulge my 28 years' experience in this field. I've no idea what's been published and is in the public domain. Sorry...

Out there somewhere (can't for the life of me recall where, sorry) is a site which has a number of Derby Research papers on it, including one given to a (major or national, I think) mathematical society (!) which described the mathematics of regulating trains over a simple double junction; this was the basis for the design of ARS. Of course, translating that into a real-world application would take a fair bit of work (my grey cell seems to think the paper was given in the early or mid 1970s). But it might be an interesting exercise for the mathematically inclined enthusiast.

[AndyB]

From using SimSig simulations, which have a reputation for accuracy, I think it's roughly:
1. Timetable if both running to time (so an early running freight may be held at a converging junction if it is not blocking classes 1-3 or class 9 trains)
2. Whichever train is running to time unless blocking a late running train would create more disruption to trains behind it
3. If both are running late, check the trains behind and otherwise give priority to the higher class

Obviously it can't take account of trains not already showing on the panel, and nor is it likely to check the impact on subsequent workings of the same set.

[JanH]

From using SimSig simulations, which have a reputation for accuracy, I think it's roughly:
2. Whichever train is running to time unless blocking a late running train would create more disruption to trains behind it
3. If both are running late, check the trains behind and otherwise give priority to the higher class

My impression is that I don't think it's actually clever enough to look at trains other than those that are immediately conflicting.
I think I've seen some brief descriptions somewhere (possibly by Geoff himself on some old newsgroups posts or dotted around the Simsig forums or elsewhere, some googling might turn them up) and the basic principle is that it tries to detect conflicts between trains

• a) where the paths are simply crossing each other at a junction, it only looks at that junction
• b) if the paths are converging, it looks along the whole common stretch until the paths either exit the area or diverge again. Also, looking at it that way, case a) is practically a special case of this where the two trains are converging and then immediately diverging again.
• Edit: c) and then there's of course the case where trains are running in opposing directions along a single line, although it's probably somehow possible to formulate this in terms of b) as well

Then,

• if both trains are running to time (or very near to it, I think the default tolerance is two minutes for a simple crossing (case a)), it might vary for the other conflict types or also depending on the specific location), as you say they're sent in booked order
• else it tries to predict the delay to both trains at the end of the common running section (point of divergence) for both scenarios of "Send train A first" and "Send train B first". The delays are probably also weighted by train class (Edit: and maybe also the current delay - also I think all those weighting factors can in principle be configured individually for each junction) and then the option with the lowest total delay is chosen.

There also needs to be some special logic to resolve circular dependencies (Train A gives priority to train B, train B to train C and train C to train A) and probably lots other bits and pieces, but I think that's the basic gist of it.

Edit:
So far, I haven't been able to dig up again that that post I remember, however

Full story here

it seems that paper has now moved and can be found here - also, on page 27, there's a brief description of the basic principles of ARS and it seems to match what I've written above. For further reading, it's also citing J Hurley “The British Rail automatic route setting system”, I.R.S.E. International Conference “Aspect 91”, London, 7-9 October 1991, pp 334-342. If somebody has access to that conference's proceedings I'd be interested in a copy if possible - if not, I might try and see if I can dig up a copy myself via my local university library.

[edwin_m]

If you can get a login to Sparkrail.org, typing "Automatic Route Setting" (with quotes) into the search box brings up a few that may be of interest.

[StevieG]

As IECC Shift Managers at Liverpool Street (the first IECC signal control centre to go 'live' in the UK), we felt John Hurley (of the BR Research Centre, Derby) to be our ARS 'guru', very knowledgeable and clever, on ARS, the TTP (TimeTable Processor), and the .cif files downloaded to the TTP at 12-hourly intervals from TSDB (Train Services DataBase) containing all the TT data that ARS needed from nine hours later (comm'g at 00:00 and 12:00), while being very approachable, appreciative of signalling operators' needs and concerns, and open to discussing ideas of minor modification : We often liaised with him on the commissioning and 'snagging' of ARS & TTP matters associated with the resignallings at Liv.St. & Bethnal Green, and Brentwood - Shenfield - Southend Vic./ Southminster.
I imagine that his presentation in 1991 would've been most detailed and informative.

[JanH]

If you can get a login to Sparkrail.org, typing "Automatic Route Setting" (with quotes) into the search box brings up a few that may be of interest.

It seems that out of those results, all the British Rail Research papers are "visible at the contributor level" only, but thanks anyway.

[rower40]

Coincidence alert. I saw John Hurley on the bridge at Derby station yesterday lunchtime - not to talk to though, we just exchanged a nod to each other.