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!
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!
(01-07-2011, 03:27 PM)onestrangeday Wrote: 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
PJW