ARS - Wrong Route ?

[ComUtoR]

Afternoon, clever and informed peeps. How or why would ARS give a wrong route ?

Cheers in advance

 

[Efini92]

Afternoon, clever and informed peeps. How or why would ARS give a wrong route ?

Cheers in advance

I always just thought it was the signaller blaming ARS

 

[TSG]

As I understand it, the timetable is uploaded to ARS a couple of times a day from a central server. If the timetable planners prepare a timetable that isn't right, ARS will either do what its told or not do anything, depending on the nature of the error. I suppose the other possibility is that ARS believes the 'correct' route to be unavailable and the 'wrong' route is in ARS data as a legitimate alternative (rightly or wrongly).

 

[Annetts key]

Some signalling equipment failures (or points being restricted) can result in ARS making unwise routing if the signaller does not intervene in time.

Most other occurrences are due to errors in the timetable data as explained by TSG above.

The other possibility is that the selected route is not ‘wrong’, but it may be that the driver does not sign that route. Or, there is a problem further along that route that means that some or all trains are unable to use it.

 

[Nippy]

Or control change the wrong thing in Traffic Management

 

[Oxfordblues]

I've noticed a freight train here in Oxford being stopped because the schedule showed a pathing stop which wasn't needed because the other train wasn't running. It took a while for the signaller, who might have been distracted, to set the route and clear the signal.

 

[rower40]

Q- and Y-pathed trains can also be an issue. Two schedules for the same train, but going different ways, both sent to the ARS computer. It can choose the "wrong" one; all looks fine till the train reaches the junction where the schedules' paths diverge.

Two trains in the timetable with the same train description, but several hours apart; BUT if the description is interposed "early" at the train's starting location (possibly because it stables overnight), then ARS chooses the schedule for the night before, rather than the next morning's service.

Another cause can be if a train (E.g. Excursion, or RailHead Treatment Train, or Track Recording Unit) goes through the same junction signal twice, but goes a different way each time. It's not unheard-of for ARS to send the train the same way each time.

Got any specifics of the incident that led to the question? (Time, Date, Place, which train?)

 

[zwk500]

Q- and Y-pathed trains can also be an issue. Two schedules for the same train, but going different ways, both sent to the ARS computer. It can choose the "wrong" one; all looks fine till the train reaches the junction where the schedules' paths diverge.

This certainly happens, and I know of 1 incident where it directly caused a delay. 3 Q paths were in the System, FOC ran the path with a UID 2nd or 3rd in the list, ARS chose the first result that matched the headcode, and looped it when it wasn't meant to.

Another cause can be if a train (E.g. Excursion, or RailHead Treatment Train, or Track Recording Unit) goes through the same junction signal twice, but goes a different way each time. It's not unheard-of for ARS to send the train the same way each time.

Yes this also happens, with some schedules being split because of the issues.

 

[D365]

Please can somebody define ”ARS”.

 

[Flange Squeal]

Please can somebody define ”ARS”.

Automatic Route Setting

 

[JeffH16]

Please can somebody define ”ARS”.

Automatic Rubbish Signalling

 

[Skie]

Please can somebody define ”ARS”.

Automatic Route Setting equipment

 

[Annetts key]

Automatic Rubbish Signalling

I think you got that incorrect, surely it’s Absolute Rubbish System…?

 

[D365]

I think you got that incorrect, surely it’s Absolute Rubbish System…?

Compared to TPWS, that’s very tame!

 

[Annetts key]

Compared to TPWS, that’s very tame!

I was (trying) to keep it polite

 

[tiptoptaff]

ARS can also wrong route if the driver doesn't reg the GSM-R correctly. We had several wrong routings offered at Bristol East Gantry a short while ago because drivers departing BTM were entering the wildcard rather than the correct signal number and ARS(E) didn't like it.

Seems the most common cause of a wrong route from a driver's perspective is (so we're told) when the train has been taken out of ARS at some point and is either being signalled manually or when put back in to ARS, it isn't recognised correctly.

 

[Horizon22]

Surely ARS is only as good as whatever the human signaller / planner / controller has put in in schedules?

 

[Spartacus]

Surely ARS is only as good as whatever the human signaller / planner / controller has put in in schedules?

Even a perfectly good schedule, or at least a perfectly good schedule if it was signalled by a human, can be problematic for ARS with it's many foibles if it runs foul of any of them.

That said, when you know what and where they are you can sometimes make good use of them in a way that a human signaller might mess the schedule up.

 

[Tomnick]

ARS can also wrong route if the driver doesn't reg the GSM-R correctly. We had several wrong routings offered at Bristol East Gantry a short while ago because drivers departing BTM were entering the wildcard rather than the correct signal number and ARS(E) didn't like it.

Seems the most common cause of a wrong route from a driver's perspective is (so we're told) when the train has been taken out of ARS at some point and is either being signalled manually or when put back in to ARS, it isn't recognised correctly.

What you put in when you register the GSM-R has no bearing on what the ARS does. All that happens is that the GSM-R system checks what's in the train describer berth that you're trying to register in, and if it doesn't match, it'll not let you register. It can't change what the train describer's doing though, and that's where ARS gets its info from.

However, if you try to register correctly and the wrong headcode's in the train describer, it'll kick you out and hopefully the error will be identified and put right before ARS can do any damage! Using the wildcard bypasses that check. We had a similar one a couple of weeks ago, where for some reason the signaller had the wrong headcode in the TD (usually it's something like a set swap that's been overlooked).

It's a bit harsh to blame the drivers for incorrectly registering though - that's not where the root cause lies. I assume that it was a successful attempt at shifting the blame and possibly some of the delay minutes?

 

[Trothy]

It's a bit harsh to blame the drivers for incorrectly registering though - that's not where the root cause lies. I assume that it was a successful attempt at shifting the blame and possibly some of the delay minutes?

It's rare but it does sometimes happen, ARS or not. And it's why drivers shouldn't just use a wildcard without checking with the signaller. I've known of several unit swaps that for whatever reason didn't get actioned correctly and a driver has used a wildcard to register his headcode (without checking with the signaller) only to then find himself asked why when he calls at a signal where he's been offered a wrong route, why his GSM-R has a different reporting number to his actual headcode and how he managed to enter that number in the first place.

I'm sure it can be tempting to think "lazy signaller just hasn't changed the headcode from the inward yet" but using a wildcard where it's not authorized already or without speaking to the signaller can lead to a wrong route from time to time.

== Doublepost prevention - post automatically merged: 9 Feb 2023 ==

And more on topic, the biggest reason I've seen for ARS wrong routes tends to be when for one reason or another, the timetable download fails as there often isn't a clear alarm or indication that this has happened.

Obviously 99.99% of the timetables services don't change from day to day but then you'll have a service that is VAR'd for the week, running off the old timetable and the first you know about it is when a driver calls to say he's been offered a wrong route, or worse taken a wrong route.

Aside from that, unit splits that are for one reason or another the "wrong way" around in the ARS system are another favourite as usually the driver can register his headcode correctly in GSM-R.

 

[Tomnick]

It's rare but it does sometimes happen, ARS or not. And it's why drivers shouldn't just use a wildcard without checking with the signaller. I've known of several unit swaps that for whatever reason didn't get actioned correctly and a driver has used a wildcard to register his headcode (without checking with the signaller) only to then find himself asked why when he calls at a signal where he's been offered a wrong route, why his GSM-R has a different reporting number to his actual headcode and how he managed to enter that number in the first place.

I'm sure it can be tempting to think "lazy signaller just hasn't changed the headcode from the inward yet" but using a wildcard where it's not authorized already or without speaking to the signaller can lead to a wrong route from time to time.

Absolutely. I understand how it can happen (when it last happened to me, before I'd even got in the cab let alone tried to set the GSM-R up, I think the signaller was blissfully unaware that there was a set swap planned!), and how the driver attempting to register correctly is a check that should've highlighted the error. It's a big step from there to "the wrong route was offered because the driver didn't register correctly" though!

 

[Annetts key]

It should be noted that most of the TD (train describer) systems don’t care and don’t perform any checks on what codes are used, or if the same code is used multiple times. The only requirement being that any TD code is four characters.

So have a look at this screenshot:



Can you see any thing wrong here?

Spoiler

And yes, there were two different trains, each using the same 1A12 code, as the train forming the service between Taunton and B.T.M. was a five car, but a different train (a nine car) formed the service between B.T.M. and London Paddington.

 

[Benjwri]

I've noticed a freight train here in Oxford being stopped because the schedule showed a pathing stop which wasn't needed because the other train wasn't running. It took a while for the signaller, who might have been distracted, to set the route and clear the signal.

More likely the signaller had to check that allowing it to continue early was okay, the train it's scheduled to stop to allow pass may not be running but letting it go early could mean it gets in front of something it should be behind, then can't allow it to pass if there isn't a good loop, or could get stuck further up if somewhere it needs to pass through/stop at is full.

 

[endofthetunnel]

And to add to that, even if it is the next train in a certain direction and it will be in the right path, it might need to get held at a later junction instead…But the schedule will assume it’s running at line speed by that junction in the route and so the service can lose time accelerating from a stand, and that initial signaller will take the delay!

 

[Class 170101]

It should be noted that most of the TD (train describer) systems don’t care and don’t perform any checks on what codes are used, or if the same code is used multiple times. The only requirement being that any TD code is four characters.

So have a look at this screenshot:

View attachment 128740

I've removed the spolier so I don't spoil it but thats a no no on safety communication grounds.

 

[zwk500]

I've removed the spolier so I don't spoil it but thats a no no on safety communication grounds.

When a set swap is taking place, what would the normal practice be?

 

[plugwash]

I think the transfer the headcode from the old unit to the new unit when both are stopped in the station. I don't know how they mark the platforms that are occupied by a parked unit though.

I remember platform staff at cambridge complaining that the automated displays and announcements were all driven off the headcodes and this was causing them to announce the arrival platform rather than the departure one for a service that was being unit swapped (leading to the displays/announcements saying a London-bound service was going from one of the north-facing bays).

 

[Annetts key]

I remember platform staff at cambridge complaining that the automated displays and announcements were all driven off the headcodes and this was causing them to announce the arrival platform rather than the departure one for a service that was being unit swapped (leading to the displays/announcements saying a London-bound service was going from one of the north-facing bays).

I don’t know about now, as changes may have been made, but the same was true at B.T.M. in the past. The S&T were carrying out some testing of the T.D. and manually moving a test description around (with permission of the signaller). They and the signaller were blissfully unaware that the automated station announcement system was busy announcing that passengers should stand clear as the next train at platform X is not scheduled to stop, or something similar!

I think at least one signaller has also been caught out when a train was being replatformed, again because they were not aware of the affect on the automated station announcement system of moving a description around…

On the subject of bay platforms, when the current customer information system (CIS) was being installed at B.T.M., it was amusing to see it provided for platform 2. For those who don’t know, platform 2 is classed as a siding, and as such, is a non-passenger line…

 

[IanXC]

When a set swap is taking place, what would the normal practice be?

From what I've seen normal practice for swap or couple up would be for the set waiting to go forward to be described as (in this example) *A12 until the inward set was in the platform.