(27-07-2012, 03:25 PM)Jerry1237 Wrote: PJW,

I would be interested to hear more to the rationale in your last paragraph that route release can be driven by a SIL2 control system.

TORR isn't dependant upon being in an ARS area. Is the logic for TORR requiring signal off simply that it is checking a train has stepped through a set and valid route which would include passing a signal that isn't in the stop position? In other words, the movement was valid. This stops the route collapsing behind the train where a potential SPAD, or other unexpected event, has occured - belt and braces?

(30-07-2012, 03:53 PM)Jerry1237 Wrote: I had always presumed that TORR was entirely within the interlocking and that ARS et al only made calls to the locking when it has run some internal checks # that the route was free to be set (beyond just normal). It would be interesting to find out more about the RII/RRI interface and TORR functionality lies within control systems.

(# the checks run to avoid stressing the locking due to requesting unsettable routes.)

(01-08-2012, 09:13 AM)Jerry1237 Wrote: To ask a question; would that not be considered as similar to the signallar pulling the button. The real checking for validity to pull the route is still completed within the locking, hence SIL4? I guess it is an interesting question whether TORR needs to be SIL4 whereas we all accept the route setting/release must be. After all, a signaller certainly isn't SIL4!

Comments?

(24-07-2012, 11:10 PM)PJW Wrote: I have recently been asked a question (not for IRSE Exam purposes):
The question is: In the UK Railway Group Standards, referring to TORR, it implies that for TORR to be effective (i.e. to work), the signal in question must have been OFF when the train passed the signal.
i.e. if the operator pulls the button in front of a train which then runs past the signal at red, TORR is not effective. Similarly if the operator sets a route and the signal doesn't clear and the train is called past the signal, then TORR isn't effective.

Can you confirm the rationale for requiring the signal to be off when the train passed the signal?

My response was as given below; I'd be interested to see if others disagree / can add anything more to it:

I don't think you'll find this rationale written down anywhere; the place I would look would be the relevant chapter of SSI data prep in the SSI8xxx series, but not over hopeful.......Hence this is my own take-

Basically the feature is implemented by requiring the signal stick GSR down (or signal stick xs in SSI data).
This "circuit" consists of parallel paths:
a) berth track clear,
b) first tracks clear,
c) signal RGPR (proving signal at red- the "pumping stick" feature originally provided to allow route to be over-set with train still on this track)

Hence if a train passes signal in the normal manner, the circuit loses a, then b just before gaining c so the stick path is broken. It gives directionality and a pretty good proof that train has actually passed the signal whilst it was displaying proceed (as you detected within the wording of the standard).

As per the actual question you asked- the rationale. I don't absolutely know for sure but my assertion is this.
TORR introduced primarily to support Automatic Route Setting (as it is obvious ARS without TORR wouldn't actually give much benefit!)

There are always hazards relating to absolute reliance upon track circuit train detection- there can be "bobs" when a train briefly disappears due to poor train shunt; also there are many things that can cause a track to appear to be occupied when it is really clear.
A signaller is deemed to be vigilant and to have some intelligence and therefore will stop and think just prior to cancelling a route, doing some form of "double check" that
1. there is no train is approaching the signal and therefore a driver to see an aspect reversion, in addition to
2. satisfying themselves that either the route has been used or that it is appropriate to change the priorities at the junction which had been committed but not yet used for a train.
Whilst a route remains set it holds the locking for any points, level crossing, opposing moves and hence is the last line of defence. Prior to TORR, the signalling already had "approach locking"; therefore the need to provide something additional, using at least one different train detection device, to implement what would otherwise be done by signaller's fingers following appropriate data processing by their brain.

TORR was first implemented on Southern Region (certainly Wimbledon for Waterloo in "Yellow Book free wire" but may also have been earlier such as London Bridge as I think it was in Westpac 4 but my memory is hazy on this); on SR one tends not to be able to achieve a drop shunt of 0.5 ohm but have to accept 0.3 ohm because of the number of impedance bonds on ac vane tracks. In that environment the occasional brief track flick isn't really that unusual. particularly as traction fault effects can giving traction current imbalance in the running rails.

It would not be inconceivable that a single fault (power supply interruption, dodgy insulated rail joint between two track circuits) would cause both to become occupied and then become clear again with one of them being slower to pick than the other- hence they would appear to give a sequence looking as if train had passed. There is a "Power Off" relay that ought to inhibit this in circumstances in which the interlocking itself has lost power, but this wouldn't protect in all circumstances of local power interruption and certainly not for a dodgy IRJ. We wouldn't want to cancel and free the A/L of a route in such circumstances.

Another factor is that ARS is always looking to set routes if due to be set- it is a computer looking for "opportunity" and should it ever see all the point availability conditions simultaneously satisfied it will "get in there" and launch its route request. Therefore the risks associated with lack of perfection of the interlocking / train detection are vastly increased- if a track bobbed and freed all the route locking before becoming properly occupied again, a signaller would not likely to be quick enough to request the route in the "time window" (assuming that the track deadlocked one of the relevant points) and also should anyway think "where the #@*% has that other train gone".

ARS on the other hand would just say "great, the conditions I have been monitoring are all now satisfied so I can do what I have been waiting to do and thus avoid unnecessary delay to my train. It only considers on a train by-train basis when it wants to set a route; it has no real comprehension of the big picture, just evaluating priorities to get a string of green aspects ahead of trains.

The mindset is that ARS should take the routine workload off the signaller, but leave them in control. Hence whereas a signaller can key points or set routes themselves and thus constrain ARS to follow their lead and it will work with them, should a signaller cancel any route prior to passage of train, the ARS is designed to switch off its relevant sub-area on the basis that the signaller did so for a reason and if ARS remained active then it would be competing for control and could do something contradictory.

If a signal is replaced to danger when a train is close to it and then the train passes it as it is unable to stop, the situation is clearly abnormal; hence the rationale: leave the signaller fully in control as they are probably aware of the current scenario in a way that cannot be envisaged by the signalling designer generically.

If a route has been set for a train which has not cleared (perhaps waiting for approach release or the lamp proving of a route indicator) and a train passes it invalidly (going too fast, driver anticipating clearance, sees a route indicator but failure of lamp proving keeps signal at red- all are SPADs for which the driver is responsible) then again wouldn't want to change anything and free up locking. There will need to be an investigation and (certainly in the days of RRI without data monitoring kit) hence very undesirable to destroy evidence of the state at the time of the incident- if the route TORRs there may subsequently be doubt it was ever even set.

So in summary the rational seems to go like this:
1. Increased area of control requires workload to be taken from signaller and can't expect them to be so vigilant as when responsible for a small area and few trains simultaneously
2. ARS increases the likelihood of a weakness in interlocking being exploited by a computer without any common sense
3. More reliance has to be placed on integrity of route cancellation / normalisation- do in the interlocking not the control system
4. The GSRs already exist and have plenty of spare contacts; hence including this level of proof costs almost nothing and provides the benefit of a good confidence that the railway is in "normal operating scenario" conditions; hence it is a "no-brainer" to include within the TORR function.

SSI program and data very much followed the RRI implementation wherever it could (some things like route locking , comprehensive Approach Locking are considerably different but there is a reason for this- the default position was to keep as similar as possible, no doubt for ease of acceptance by a conservative industry.

Perhaps over the years we have become slightly more comfortable- often nowadays the TORR is performed in the SIL2 control system when a pre-exsisting RRI is transferred from a panel signalbox to a new large VDU based control centre. We still implement the same logic of requiring the "stick unset" though.

Any more ideas to reinforce / refute ?