Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Foul Tracks
#4
(16-01-2017, 01:23 PM)Rob Wrote: I was not sure what a POP group was.

POP group - Predetermined Overrun Protection group
"A group of signals replaced to danger by the signalling system after a SPAD: the grouping is agreed in advance in consultation with operational specialists."
"NR/L2/SIG/30009/E421 describes the extent of the required predetermined protection for each signal"
Ref: NR/L2/SIG/30009/E420 Issue 2, March 2015

I understand it is an automatic reaction to a SPAD as part of overrun management implemented in the control system (i.e. IECC) rather than the interlocking to reduce complexity in the interlocking ('simpler is safer') and to reduce cost (~SIL 2 cheaper than ~SIL 4).

Yes that just about sums it up.  POP Groups is an awful name as at least one of the people who were very involved in writing E420 never tires of saying; they fought valiantly against it but were overwhelmed.

I actually don't think that it makes a huge amount of difference doing in control system or interlocking; ironically it can be easier to amend interlocking data!  However it does mean that it removes it from the  province of Principles Testers (for good or ill) and certainly makes it easier spanning boundaries, particularly as we are now getting ROCs with a right mixture of CBI and RRIs of various different standards.  However the main thing is that the computer does what it does best (continually and tirelessly monitor for pre-defined scenario and quickly and reliably implement the pre-defined emergency response) but leaves the signaller to do what the human does best (use diverse sources of evidence and information to decide the best course of action in the particular circumstances).  
The main problem with the previous approach was the determination to impose pre-defined locking and because there are actually a range of scenarios (slight misjudgement, one wheel just past signal and train stopped, train continuing unchecked, train authorised to pass signal at danger but signaller had forgotten to place a SIS- SPAD Inhibit Short, no SPAD at all but just an unfortunately timed track failure) this was impossible to get right for all the different circumstances.  Compounded by the fact that it was implemented by "upside down route locking" which was invisible to signaller and little bits of it could be left lurking afterwards causing mystery failures of signals to clear).
PJW
Reply


Messages In This Thread
Foul Tracks - by mailmesashi - 12-01-2017, 09:14 AM
RE: Foul Tracks - by PJW - 12-01-2017, 11:30 PM
RE: Foul Tracks - by mailmesashi - 17-01-2017, 09:02 AM
RE: Foul Tracks - by mailmesashi - 01-02-2017, 09:09 AM
RE: Foul Tracks - by Rob - 16-01-2017, 01:23 PM
RE: Foul Tracks - by PJW - 16-01-2017, 07:26 PM
RE: Foul Tracks - by Thed1983 - 29-08-2017, 10:57 PM

Forum Jump:


Users browsing this thread: 1 Guest(s)