2015 Q6 WSF of interlocking allegation

[dorothy.pipet]

An attempt for comments please.
This was done timed but with notes available.

[PJW]

An attempt for comments please.
This was done timed but with notes available.

Pre-amble
As soon as I saw this question on the exam paper, I knew that it had been inspired by the Stockley points incident, which actually was at that time the most recent (and could potentially have resulted in the worst accident) such issue to have emerged.  More recently a somewhat similar case has come to light, but instead of emerging very shortly after commissioning only manifested itself after some 20 years of operation. 
To answer the question does not require knowledge of either of the details of either of these occurrences since it is generic and such undesireable situations have always been known to be possible, but certainly if one has experience of some real instance, then it certainly focusses the mind when producing an answer- just one example why it is useful for IRSE exam candidates to keep abreast of the current concerns of the industry to achieve "situational awareness". 
In the case of Stockley, this was the catalyst for escalation across the industry (the Railway Industry Association / IRSE Recommendations in the UK which led to NR increasing the rigour and prominence of Project Stagegates) and indeed shared with the international audience via articles in IRSE News.

Answer
The first part of the question first asked "what documentation would you check?" then "how would you investigate the allegation".
In that context your answer appeared to get of on the wrong foot when it started: "Ask that the points be locked in place"......
I think that it would have been wiser to have responded in the order requested by starting with the documentation; the first bullet point was also rather more detailed than it needed to be for this question, good though it was.
It was sensible to put something "up front", but I think the way I'd have done it would be.

Assumption: Railway has been made safe and some form of temporary working method established by others in the front line and that my investigation is to establish first whether the allegation has substance, secondly whether it was due t interlocking data fault, thirdly (if applicable) how it was that the interlocking was in an unsatisfactory state"
and then get straight into listing the relevant documentation before expanding into the acquisition of other evidence when discussing how you'd undertake the investigation.

As an investigator, you do tend to need to have some background before talking to witnesses, in order to have at the back of your mind some idea of things that are likely to be of interest and have some questions up one's sleeve to ask- to avoid a completely unstructured interview which may take a long time and fail to give information that could have been extracted.  The interviewee often won't know what the interviewer wants to know and in some cases may feel in some way guilty and therefore might try not to say things that they do believe would be of interest or even be deliberately distracting and evasive.  Hence the interviewer needs to have several lines of questioning that seek to confirm / repudiate various potential theories and this itself requires a level of understanding about the technology, processes that should have been followed, project implementation, event timeline in order to have conjectured some possible scenarios.  On the other hand the interviewer does need to get the interviewee to tell what they know and how things seemed to unfold to them from their own perspective at the time that they did / didn't do things without contaminating that evidence by pre-conceived notions.  Whether or not the interviewee has any intention of misleading or being "economical with the truth", human memory is not like replaying a video recording and works by reconstructing a reality from a range of disparate sources and the very form and wording of an interview question will be providing the nucleus around which an answer will be constructed that seem to fit and thus construct a response that the interviewee hope will satisfy the interviewer (regardless of whether they are genuinely trying to give the pure unadulterated truth from their perspective).
Having a certain (too much!) experience of having to do such, it certainly is very difficult to do well.
The truth is that one does not know what documentation might be relevant until after one has spoken to all the witnesses, but one does need a certain amount initially to be able to try to assimilate the context and undertake a "first cut" of what amongst the mountain might be relevant to have some idea who you might wish to talk to and broadly about what; it is only once one has had that conversation that one discovers what further documentation should be scrutinised.  Very often there is a need to re-interview some of the same witnesses later on in te investigation, in order to cast light on the inevitable discrepancies which emerge between various sources of testimony and other evidence.  I think I could probably write a book on this, but in the exam there are 8 minutes to get down some bullets!

Looking at yours:
Whereas there was documentation inferred, it wasn't very evident.  I think that I'd have presented as a list (or perhaps table) listing:
WHAT document
WHY relevant
HOW I'd use to further investigation
Since this first section was about investigating whether the allegation had substance, I think that you had some good content but not convinced re relevance of the 5th one.  I think you probably meant that there may have been other potential causes for the event which the signaller alleged actually happening, but not reflecting upon the integrity of the interlocking itself but created by some other cause.  This is certainly a very valuable point to make; however it wasn't explained like that- indeed had this been made the last on the list and introduced with a statement reflecting that even if the interlocking seemed fine given a level of recheck and retest failing to find anything that the allegation should not be dismissed without having investigated other possibilities, then it would have been transformed.

[respond to parts b & c when  get the chance.......]

[Motty]

An attempt for comments please.
This was done timed but with notes available.

For my tuppence I'd always try and find out if anyone was working in the relay room at the time, in-case it was a 'fat fingers' mistake.  The building entry log is helpful, assuming it's being filled in appropriately.

Similarly was there any project or construction work going on nearby.  Sometimes the people working on the project can be less familiar with the consequences of their accidents.

A

[PJW]

An attempt for comments please.
This was done timed but with notes available.

[respond to parts b & c when  get the chance...]

I have now updated the attachment of your original post to have the version with the scan of all the text on the A3 page.

Part B:

I thought this was good and ought to get the majority of the 7 available marks, although I must admit to wondering whether for the incident on which the question was undoubtedly based I would be confident that it would prevent re-occurrence.  Actually it was the very last item that I do feel is the most likely to capture any repeat occurrence and perhaps you should have made more of it. 
An initial sentence as a lead in to your numbered items emphasising the importance of not cutting corners with the laid down process and enforcing sequential working resisting pressure to make a start on a task before the predecessor is actually complete, would have been useful- it started quite abruptly and it took me a moment to understand where you were heading.

One item that you didn't mention which actually was the thing that prevoked the error in this particular case (but actually is quite typical) is taking particular care on the re-work cycle to incorporate mods and/or respond to Test Logs.  Designer / Checker / Tester almost inevitably working against time and have probably just had to pick -up the task as an interruption to what they would otherwise be doing and hence might be "cold" rather than deeply into the job as they were the first time around.  Particularly if it only seems to be a small alteration "just" to address a particular problem, then the full implications can be overlooked.
Another related factor in the particular incident was that there was a MIX of standards.  The alterations were being done on old data which was not to current standards.  The client wouldn't pay what they perceived to be unnecessary money to bring the existing data up to current standards and yet were equally insistent that the new work should be to new standards.  Either solution for dealing with cross-boundary points worked; the problem was that the combination of one solution in one of the interlockings and the other in its partner had a fatal weakness in a particular situation.  The designers got it right the first time with certain points being treated one way and certain others in the opposite way; however when they needed to revisit the data to address a minor issue, they were disorientated and it seemed illogical that a set of points was done in a way that was non-compliant to modern standards and so thought they were doing the right thing to "upgrade" the data- however it was done in one of the pair of interlockings but not the other, leading to incompatibility.  Hence I would certainly add to your list:
Don't mix-and-match standards!
Try to get strategic engineering decisions made by those of appropriate technical competence rather than those more focussed on finance and project delivery dates.
In reality has the industry learnt its lesson on this- certainly no!. 
I am currently testing data for a place around 35 miles away on the same line and this is c1990s SSI data originally trying to emulate E10k interlocking practices to no documented data standards, has been amended many times since and now we are "simply" "just" converting the train detection to axle counters and whilst we are doing it "just" adding a new signal or two, making provision for the next stage, but of course changing any of the existing data "unnecessarily" is out of scope of the project......

When, due to earlier incidents, the "enhanced rogue point test" came in I believed that it was not practicable; now that we have the enhanced enhanced enhanced rogue point test it certainly isn't.  To have to define it is to me almost an admission of failure; if to have full confidence in the interlocking data we really need to go through every combination of points and routes then the only answer is automated testing to plough through the lot.  Even then it takes ages even if being run on several instances simultaneously and in truth cannot always be completed on finalised data prior to that data being commissioned.  However to me it is the most likely means of preventing a reoccurrence.

As well as attempting to automate some of the testing, then automating some of the checking is another approach.  Computers can be very good at looking for specific conditions that should not exist and proving that they don't, so analyzing the data to see if it is ever possible to get to a "cn" or a "cr" statement without having previously gone through the requisite "cnf" or "crf" test is another approach that can, and probably should be, adopted whilst we continue to utilize the SSI style data.
However swinging overlaps always had issues even n RRI days, particularly when there are multiple sets of facing points that could potentially swing and then bring in a whole different set of trailing point / opposing locking conditions applicable to the specific overlap selected.  However tying to wean the operating department off having such flexibility having become used to it is quite a challenge, but in a holistic safety argument perspective (and this is particularly pertinent to mod 1) then this is something to consider very seriously.

Another item which you could have mentioned was that removing some of the complexity from the SIL4 protection system and implementing within the SIL 2 control system can be beneficial. It wasn't relevant in this particular incident, but certainly there is a definite push to implement Signal Overrun Protection in such a manner.  Perhaps eventually we might feel able to do the same with axle counter reset-restore / aspect restriction functionality (or even considerably simplify as well!)



Part c:

I think the presentation was clear and made good use of the A3 blank.

It was important that it covered a range of technical and procedural options and those that were short term and those long term.

I would have said a bit more about organizing an activity to go look for places which may have such issues lying latent, working out what factors might suggest that the data could be suspect as well as looking at which are the more risky sites due to the likelihood (density of traffic) and consequences (environment, layout design, density and speed of traffic etc.)


I might take issue with some of the detail of what you wrote, but I don't think this particularly relevant from a mod 1 perspective.  However I can't help saying that relating to the specifics, I have to disagree that the locking of points on the points key would be a valid thing to do.  Of course one would think it would be, but the horrible thing about how SSI and SSI-derivative interlockings deal with points is that there is no real equivalent to a relay interlocking lock relay and it is possible to write data that calls points without having checked their availability. 
I have previously met data that stated "if P905 crf then P905 cn"- one simple typo that was virtually invisible in the days of a dot matrix printer as the difference in the dot pattern for "r" and "n" is barely anything.  Particularly in swinging overlap data when there are jumps to @ etc. it all too easy to call points that just haven't been tested at all- therefore if the points are keyed and the dead locking track is occupied, they will move instantly and the only way that one could cause the same havoc in RRI is to shove a live false feed into the coil of a relay in an interlocking that is in traffic.  That is indeed what lies at the heart of the problem; I have the utmost respect for those who developed SSI that was a decade ahead of its time and to think that the industry managed to get stations such as York, Paddington etc. to work on 8 bit processors running at 1 MHz and having just kB of RAM is amazing and inevitably meant some uncomfortable compromises.  The sad thing is that we are fundamentally using the same data structure in a completely different world.  Worse than that we have so much changed our standards  that the "signal special" which originally did so much of the locking "built in" now has to have much data written around it to cope with all the things like TPWS, axle counters that have made what was simple aspect sequence complex........

I would have included an option to do a "quick and dirty" data change to disable elements of the data that might be suspect; in particular I don't think it would be difficult to "comment out" swinging overlap functionality so that the tests would always fail.  This would provide a secure way, albeit restrictive and adding to signaller workload particularly if there was ARS provision (since this would disable the sub-areas when the interlocking failed to respond as it would have expected)- a means perhaps of achieving what you were hoping to do by getting signallers to key the IPS.


In summary I think this was a good answer; the first two parts would have scored very well. Not so sure about part c; it was adequate in that it did give options with advantages and disadvantages, was well presented and had enough content but somehow it was less convincing.  A bit more emphasis on overall safety management and a bit less on interlocking data would have helped.