(04-06-2016, 07:24 AM)PJW Wrote:(31-05-2016, 10:54 AM)dorothy.pipet Wrote: 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.
PJW