![]() |
|
Anti-preselection...... - Printable Version +- IRSE Exam Forum (https://irse.signalpost.org) +-- Forum: MODULES (https://irse.signalpost.org/forumdisplay.php?fid=3) +--- Forum: Module 3 (https://irse.signalpost.org/forumdisplay.php?fid=6) +---- Forum: Principles Queries etc (https://irse.signalpost.org/forumdisplay.php?fid=70) +---- Thread: Anti-preselection...... (/showthread.php?tid=821) Pages:
1
2
|
Anti-preselection...... - onestrangeday - 01-07-2011 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 RE: Anti-preselection...... - PJW - 01-07-2011 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! (01-07-2011, 03:27 PM)onestrangeday Wrote: Hi Signalling Professionals: RE: Anti-preselection...... - onestrangeday - 02-07-2011 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 (01-07-2011, 09:11 PM)PJW Wrote: 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". RE: Anti-preselection...... - PJW - 02-07-2011 The clause in the EFTR is certainly clear to me and it does appear from your description that the 2nd route request was stored, either deliberately or accidentally, by the system as it should not. If I understood your account correctly, there was no incident involving train 1 which held its route until clear of the points. The second route that had been stored then started to set and called those points but then immediately cancelled itself, fundamentally because train 1 had fulfilled the conditions which it was also looking for (I'd need to see a layout to understand this better). Therefore undesirable certainly but not actually directly dangerous; however it does reveal that the interlocking not performing as specified which in itself does raise concerns of course. Also I am a bit "interested" why the route release conditions for route 2 could have ben satisfied by a train on route 1; it is certainly possible that the same crucial track sections involved in each case, but once the release had been effective for route 1 then it should have immediately destroyed the memory of the satisfaction of sequence rather than leaving them (perhaps it was just a short duration timing thing that would not be significant if the primary failure had not occurred) primed to do the same for another occasion / route. So: 1. Your anti preselection clause seems fine in that it should have prevented what you reported happened. 2. I do think that the interlocking functionality does need to be investigated. Would seem that the implementation is defective in some way, possibly due to a site fault but I suspect far more likely to be a design error and yes it could well be "in concept" and thus generic rather than a one off in that particular circuit (assuming that this is route relay interlocking but analogous in the case of computer based interlocking) (02-07-2011, 03:38 AM)onestrangeday Wrote: hi PJW: RE: Anti-preselection...... - onestrangeday - 02-07-2011 Hi PJW: I have included the track layout for better understanding. I agree with you, maybe the risk is not high, but it can be improved and be better designed. (has this ever happened in UK) once again thanks for your explanation (02-07-2011, 07:28 AM)PJW Wrote: The clause in the EFTR is certainly clear to me and it does appear from your description that the 2nd route request was stored, either deliberately or accidentally, by the system as it should not. RE: Anti-preselection...... - PJW - 02-07-2011 I was hoping for a brief sketch, but never a screenshot carefully annotated- wonderfully clear, thanks very much. Never heard of quite that sort of thing happening, but we do certainly have incidents. Actually I can't readily think of a depot with as much signalling- I expect that the new Eurostar depot might have, but I have never been there. The lack of anti-preselection should have been found by testing prior to commissioning (but one must admit that occasionally such things slip through). On the assumption that the 2nd signal would not have cleared (I envisage that whereas the final track might perhaps not be required clear in the aspect all the intermediate ones would be proved), then to NR principles the route shouldn't have been released even with the track sequence. I can see that the passage of the first train would have satisfied the Approach Locking condition, but for TORR to occur not only is another track operation needed in the sequence (actually since this is not a passenger move this isn't mandatory but for your layout they'd be no reason not to implement), but more importantly the "signal stick" has to be proved disengaged, thus proving that the 2nd signal had been off and was replaced by the passage of a train from its berth to the stick track. Hence, to NR eyes, this looks like something else wrong that should have been found in testing. Definitely agree with you; it doesn't look well designed. I think that I might be letting the contractor know that if he wanted any more business from me that he'd better buck his ideas up and resolve the issue. (02-07-2011, 10:03 AM)onestrangeday Wrote: Hi PJW: RE: Anti-preselection...... - onestrangeday - 03-07-2011 Hi PJW: thanks for your clarification. I have understood the subject much better and know what to do next. william (02-07-2011, 09:04 PM)PJW Wrote: I was hoping for a brief sketch, but never a screenshot carefully annotated- wonderfully clear, thanks very much. RE: Anti-preselection...... - Jerry1237 - 04-07-2011 As for the points "failure" alarm, was it actually an OOC alarm? There needs to be care taken during design to avoid cyclic locking or to get locking/trains into Mexican standoff situations. With the ever larger and more complex layouts we are expected to deal with, the chances are these situations are far more likely to occur. PJW, There are now many depots that are fully signalled throughout. Temple Mills is one (which that screen layout isn't). Jerry RE: Anti-preselection...... - onestrangeday - 04-07-2011 hi jerry: sorry for my poor understanding, what is OOC alarm, or do you mean OCC ? (04-07-2011, 08:54 AM)Jerry1237 Wrote: As for the points "failure" alarm, was it actually an OOC alarm? There needs to be care taken during design to avoid cyclic locking or to get locking/trains into Mexican standoff situations. With the ever larger and more complex layouts we are expected to deal with, the chances are these situations are far more likely to occur. RE: Anti-preselection...... - PJW - 04-07-2011 He means "Out Of Correspondence" i.e. if the interlocking request is for the points to move to normal then the alarm is given (after a suitable delay) if the points don't achieve normal or indeed if normal detection is later lost unexpectedly whilst the points are supposed to be staying normal. In your description of the incident it is not immediately obvious what alarm was given- at first reading I thought that the points had moved under the train or indeed the train had trailed through them because they were in the incorrect lie and thus an OOC alarm would have seemed likely, but that is not my understanding of what happened. I believe that the 2nd train never received a proceed aspect and what the signaller observed was the route seemed to set itself but then was cancelled shortly later due to the movement of the 1st train (04-07-2011, 08:47 PM)onestrangeday Wrote: hi jerry: |