Anti-preselection......

[onestrangeday]

hi PJW:

thanks for your detailed explanation. one of the reason I ask about this is that there was actually a points failure due to the lack of anti-preselection function included in the interlocking.

The incident happened in depot (signallers have to set route by themselves not through ARS as in the mainline) where the controller set a route (for example Signal 1 to track circuit 1) and along the route there is a point A which has to be in normal position for the designated route. After setting the route and point A was already locked in normal position and train driver received the permission from signaller and started to move to destination track circuit 1.

But for some reason while the train was proceeding to track circuit 1, the signaller pre-set another route (for example signal 2 to track circuit 2) and along the route there is the same point A which has to be in REVERSE position for the route, but since the previous route already taken by signal 1; therefore point A had to be in normal position before being released by sectional locking. Consequently, the route being stored (signal 2 to track circuit 2) and kept the signal 2 at 'red' aspect.

Here comes the rare case.
As the train proceeded to destination track circuit 1 and passed the track circuit A (where point A are), the points were released since the train had proceeded to the next track circuit and cleared the track circuit A. So the points A started to move to the REVERSE position according to the previous stored route (signal 2 to track circuit 2), but at the same time the sequence of occupation of the previous train also fulfilled the condition of automatic route restore for (signal 2 to track circuit 2). So as the points started to move to REVERSE position the route was canceled automatically by the system, therefore the controller received a points failure alarm.

until now, we have informed the depot signaller not to pre-set any route before the previous train arrived its destination track circuit, just to make sure the same thing won't happen again in the future.

So I am not sure whether this could be an outstanding issue that could raised for the extension line project for the contractor to rectify the system accordingly. (I am also not sure whether this is the 'limit' of signalling system, that is not possible to exclude something like this)

I have also tried to find the EFTR (employment functional and technical requirement) document 9 yrs ago, which have stated the function of anti-preselection as following shown:

"
5.2.5 Anti-preselection
Any calls to set routes or move turnouts shall only be effective if such routes or turnouts are available and free to move at the time the call is made. It shall be necessary to remove such calls and re-apply them when the routes or turnouts are available and free to move.
Calls applied to set routes or move turnouts which are not available or free to move shall have no effect whatsoever. "






thanks

You correctly understand one reason why anti-preselection was provided; however I'd tend to the view that it is of rather less importance if it is a computer doing all the route setting rather than signaller. With ARS points are moving and signals clearing all the time without the direct action of the signaller; although they are monitoring the situation and have to remain vigilent to intervene, they need to "get in first".

NR actually uses antipreselection in several different circumstances.

1. A point is not permitted to move subsequently if it were locked at the time the request to move was made. I think this is what you were referring to.

2. Unless all the points are available at the moment of the route request then that is rejected, rather than being stored to be acted upon later.
However with a computer interlocking this could well be a functionality which is there by default: Request received, check conditions, if OK do, else do nothing. Basically it works rather differently than a series circuit which could sit there just waiting for the last condition to become true and might need a particular function to make sure that it is only the request becoming present at the time when all other conditions are already satisfied which is the trigger for action.

3. A route is not permitted to set if a track is occupied for a train making an opposite direction movement (apart from places where this is deliberately disregarded where a train can sensibly come to a stand prior to reversal etc such as at a platform). However note that a route IS permitted to set when a track is occupied for a train in the same direction, although in fact not all NR sites actually permit this (seem to remember that London Bridge is such a site).
Indeed on London Underground, the route cannot set until the tracks are clear so that the aspect can also clear, so whereas on NR it is natural to overset a route for a following train happy in the knowledge that the signal will clear as soon as it is able to (i.e. pre-selection), this is not possible on LU.

Remember railways make different decisions on such issues according to their environment, operating circumstances etc. This may sometimes have originally been based some personal preferences that have then been passed on through history, sometimes as a result of accidents and incidents but hopefully generally determined as a result of sound engineering judgement (which obviously takes into account all the foregoing).

Fundamentally we need to consider what is the risk that antipreselection is intended to mitigate.
For example, one potential problem is that the track circuit locking a point might not be 100% reliable at detecting a vehicle, particularly if the rails are rusty. Hence there could be a "track bob" whilst a train is still traversing the point and if the design of the interlocking permitted a "stored call" just waiting for the points to become unlocked then they would be called in the instant that the track flashes clear momentarily. However if train detection were achieved by axle counter, then that particular risk would not exist; similarly there might be some other mitigation, so in those cases antipreselection may not be necessary.

Not the only risk of course; also need to consider the risk to the technician's fingers if they put them where they shouldn't and fail to isolate the points locally for example.

In your case I expect that the contractor was either
a) given site specific Control Tables by the railway, or
b) perhaps told the generic Signalling Principles that it should utilise to design such CTs.
Therefore project delivery ought to be in accordance with that specification.
Alternatively perhaps it was the other way around with the railway asking the contractor to make their own proposal and then accepting it; again in this case the contractual specification is thereby defined.

If you are asking what policy your railway should in future adopt, then this would require an analysis of the system as a whole, an assessment of the risks (system safety and personnel safety) and if it is determined that antipreselection would be a practicable mitigation, then of course it should be specified.

This could be the basis of quite an interesting module 3 written question!

Hi Signalling Professionals:

Recently, I am reading about the explanation of anti-preselection function for interlocking found in the IRSE textbook (Railway Signalling by O.S Nock). As I read through, I acknowledge that British railway does have this circuit design consideration for the signalling system

However, for the railway system I am now currently working at, do allow route pre-selection function, is that mean this is not a very good design of interlocking ???? I am thinking why do they not include anti-preselection design in the signalling system as how the British design their signalling interlocking.

otherwise,points might move unexpectedly, if the route setting is stored in the computer based interlocking. I hope someone can clarify this for me, if this is not good design for sure, i should ask the contractor to carry out rectification as required for future extension project.



thanks