2008 Q4 CONFIGURATION MANAGEMENT

[hiteshp]

Our study group In Brisbane looked at the 2008 paper Questions 1 - 4 last Tuesday and would appreciate some feedback.

We would also like to ask whether the answer reflects the time available to answer three questions.

Thanks,
Hitesh, Laura & Johnson.

[PJW]

Our study group In Brisbane looked at the 2008 paper Questions 1 - 4 last Tuesday and would appreciate some feedback.

We would also like to ask whether the answer reflects the time available to answer three questions.

Thanks,
Hitesh, Laura & Johnson.

Q4. I suspect you were running out of time by now and thus this is quite sketchy.
I think this is the only answer in which there was a hint of the railway context in which you are answering. It is generally worth including such a statement in the beginning of your answer; I think this is particularly important for those whose practices are different from UK.

Further more detailed feedback to follow

[PJW]

Our study group In Brisbane looked at the 2008 paper Questions 1 - 4 last Tuesday and would appreciate some feedback.

We would also like to ask whether the answer reflects the time available to answer three questions.

Thanks,
Hitesh, Laura & Johnson.

Q4. I suspect you were running out of time by now and thus this is quite sketchy.
I think this is the only answer in which there was a hint of the railway context in which you are answering. It is generally worth including such a statement in the beginning of your answer; I think this is particularly important for those whose practices are different from UK.

Further more detailed feedback to follow

I don't think this is a question that I would have chosen in the exam and certainly it was by far the weakest of your answers. Only half a page, didn't even seem to attempt the middle section (40% of the marks), think you misunderstood the last bit and the initial portion was itself fairly weak.

However well done for deciding to give it a go; I like your style of sitting down as a group to do questions 1-4 of a paper rather than just picking off a favourite type of question

Nevertheless you ought to be able to do rather better at this one and so I suggest that you discuss again and try to get a better answer together- it is by doing that you will learn.

A few hints to think upon:

1. Initial version of location design given to factory for pre-wiring REB; not built exactly as per design because of the size of some equipment wasn't as the designer assumed. How is this change managed?

2. By the time it is shipped to site more detail is available on site cable routes and some initial assumptions are now known not to be true. One of the discoveries is that the A and B datalinks as designed can no longer be routed via diverse routes as they both cross into and out of the REB via the same UTX and another route is not practicable. Hence significant changes in the area are needed to where data link spurs commence / terminate and the order in which the locations in the station area are connected; the locations have mainly been designed, some are currently in manufacture, some are in the site compound, others are placed in position ready to be cabled. To make use of the necessary possession the datalink cables have to be run to a "back of a fag packet" design cobbled together on site at the eleventh hour to suit the actual cable routes avaailable and hence the ends don't match the locations as built which therefore need to be modified. Those locations shipped to site have had Test Copies issued, those yet to be shipped to site have not. How are these changes managed?

3. Also the client has now changed its mind and now requires that the new signalling system interfaces with two existing conventional signals located in a slightly but significantly different position to the oriinally intended new LED signals. Instead of being clear of junctions their overlaps now extend over them and additional track circuits are required so that there are joints at the signal positions. The locs have been built, the interlocking data and control system screen layouts etc. were all designed before this changes was advised, but since the interlocking data was being tested it was possible to incorporate the change into a re-work cycle clearing test logs from the first pass, so it now is incompatible with the location design. The control centre design is being undertaken by another contractor who is waiting for the commercial implication of this change to be contractually agreed before reworking their data. Given that it will soon be necessary to undertake through testing (site integration testing) how is this going to be achieved?

4. Later it becomes clear that certain items of equipment aren't going to be available in the necesary timescales and an alternative solution using differnt equipment is needed. How are these changes managed?

5. Tester writes Test Log to draw attention that there is a client requirement to provide Earth leakage Detection if more than one point number fed from one busbar and that the design is non-compliant. Problem is that no suitable equipment with product approval is available that is compatible with SSI point modules; necessitates reallocation of certin point ends to different TFMs. The data has been tested, the locations function tested locally and are about to be through tested to the interlockking and control system. How is this change managed?

6. Project includes element of novelty in that the computer based interlocking has never interfaced with the particular signallers control system before. During integration testing certain changes to the product software are required; however this emerges after the hardware has been shipped to site and much of the data testing has been undertaken off-site. How is this change managed?

7. An expected derogation to permit the perpetuation of an existing infrastructure deficiency is not achieved and therefore this now needs to be addressed and extends the scope of the project needing changes outside the originally expected area of change. How is this change managed?

8. When undertaking preparatory work at a location, it is discovered that the site maintenance records on site are of a later version than those officially supplied to the project by the National Records Group and have been used for the design. How is this change managed?

9. Chance discussion with a signaller reveals that they have a different understanding of which routes are currently available for use on the existing layout than is officially known to the signalling records. How is this change managed?

10. A series of enabling stagework is being taken every weekend; approved design is programmed to be issued at T-6 weeks and has to be designed on the assumption that the work in the interim period is undertaken as planned. One possession's work is completely lost due to emergency engineering work taking priority, another weekend's work has to be partially de-scoped due to a key member of staff failing to turn up for the shift, another can't be done because of the outstanding modification necessitated by item 4- so what does that do to the design and maintenance records for the later weekend?

11. A design of an electronic cubicle was approved by the client before being committed to manufacture and has been partially brought into use for those areas commissioned as the first stages of the project. When submitted purely to show the remainder brought into use at the final commissioning, a different reviewer rejects the design on behalf of the client and now requires an alteration which affects the whole cubicle. How is this change managed?

12. The client decides that they can save money long term by making use of a new node on their own fibre optic network rather than provide the originally anticipated connection via a public telecomms supplier; however this is located 2km further away than the original site necessitating the extension of the trackside datalinks and therefore a reassessment of the placement of the positions of the intermediate isolating transformers. How are these changes managed?

13. On a rehearsal weekend it is discovered that a decision to use 961 relays rather than perpetuate the use of old non-standard non-safety relays used for indications failed to take account of ohns law and when connected to the line circuit, the voltage falls from 50V to 30V and they do not pick. Contacts of the new relays have been used and have been pre-tested to the remote signalling centre. How is the necessary change managed?

14. A Technical Query asking the client to clarify and resolve discrepencies between the Control Tables (supplied as warranted documents to which the site data has been written) and the Interlocking Requirements Specfication (supplied against which the Principles testers are assessing the achieved functionality) is answered in a way that sometimes requires the data to be comply with the CTs but different from the IRS, sometimes in accordance with the IRS and therefore requirong an amendment to the CTs. How are the necessary change managed?

15. The Signal Control Centre is being provided by another supplier and they were initially responsible for defining the allocation of the bits within the TDM remote control system to all the existing RRI relay rooms whose control is to be transferred to that centre. During the signalling design of one such remote relay room's TDM interface, it is discovered that certain functions are not actually available in that room but are actually present at the next relay room along the line and therefore should be provided in that TDM system instead. The signalling design for that site has already been issued and unfortunately to make matters worse there are no spare bits on the existing input cards. Hence it necessitates the provision of a new DIP card within that field end cubicle- this is depicted in a separate set of diagrams and has already been delivered to site in accordance them and having been issued with a Certificate of Conformity after FAT testing. The control centre contractor's end of the remote control system will not initiate communication with the field end when there is a mis-match between the cards installed on site and the ones it expects, yet a rehearsal of the system must be undertaken in an imminent scheduled possession. How are the necessary changes managed?


16. A part of the area relevant to a particular control system has already been commissioned whilst the remainder of the area is to be transferred to it later. However it was not possible to perform the necessary pre-testing for the entire final area before the first commissioning was scheduled. Therefore "stage data" has to be installed in the real DIS cubicle 1 to operate the real railway. Meanwhile the "final" version of the same cubicle's data must be installed in the actual DIS2 cubicle reconfigured temporarily to be made to think it is DIS1 but obviously disconnected from the actual signalling ring connected to a temporary test ring instead. Similarly an extra temporary DIS cubicle mus be brought to site and also connected to that test ring,configured as if it were DIS2 with its "final" data.
Then after all the testing is complete at the final stage commissioning the real DIS1 will be loaded with its final data and the real DIS2 stop pretending to be another DIS1 but become itself again connected back onto the final connnections and loaded with its final data and the test ring and the extra DIS cubicle can be disconnected and removed from site. Simples!

I could go on and on but perhaps that gives you sufficient food for thought to construct a more complete answer.


[I'd be extremely interested to discover what you think the right answer is although it should be stated that any similarity between the above list of items and any project that I may currently be working on is obviously entirely coincidental, of course!]

[dorothy.pipet]

Another attempt for comments please

[PJW]

Another attempt for comments please

More substantial than previous attempts and ok as far as it went- however I don't think this was far enough.  Hence have taken the time to indicate the areas which I think were weak or missing entirely and attempt to explain the background to the sort of things that should have been incorporated; this is quite a long response but is not per se intended to be a direct answer to the question set but hopefully gets you to realise where you could have answered better.

Thought your choice of the Smartlock interlocking was  an excellent example of a system to explain why configuration management is necessary and can be managed, but unfortunately did not exploit it for all that it was worth.

To me you discussed version control and change management a bit too much; certainly there is some relevance, but I feel the core of the question was to consider how the various elements which comprise the system need to be COMPATIBLE to operate together successfully- though I must admit that such a response might skew the answer overly to module 7, so there is definitely a need to emphasise the SAFETY impact rather than the system just not working. 

That is indeed why the Smartlock system is potentially such a good example:

1. there are a large number of separate software components (just compare the quantity of information included within a release Baseline compared to that of the SSI CISR) that make up a system, let alone the definition of all the interfaces with other Smartlock interlockings, the Control System etc.
   
2. As an interlocking, it is easy to find examples where small mis-matches can lead to very significant accidents so clearly Safety Critical.
   

You are right though not to concentrate exclusively on software. 
Certainly I would have used the example of the Stockley incident some years ago which resulted in the lack of effective locking on points associated with a swinging overlap. 

• The scenario was created by a change in methodology over the years of how cross-boundary data should be written and the desire to implement the new alteration to the current standards, yet leave much of the data untouched and thus to the old standard.  
  
• Either method is acceptable and the “first testing pass” data for the various routes were undertaken compatibly in both interlockings; however in the course of addressing a Test Log a designer decided to correct what they saw as the anomaly of certain data in their interlocking being implemented differently and brought it into compliance with the modern standard, albeit this was contrary to the original intention.
  
• Even more regrettably the implications of this was not recognised; the data within the neighbouring interlocking was not also amended and thus was incompatible. This led to a set of cross-boundary points being called to their other lie, without an availability check having been performed in either of the interlockings.  The consequences could have been extremely severe- points moving under a train on a stretch of 4-line railway of high permissible speed and so a multiple train head-on collision could easily have resulted.
  

This example does illustrate that Change Control is one of the pre-requisites of Configuration Management, but the most relevant thing for answering this question is the issue of compatibility; it did not matter whether interlocking 1 or interlocking 2 which were straddled by the points tested them for availability, but it was crucial that one of them did so and the inconsistent methodologies adopted resulted in the total lack of locking in a specific scenario (yet was otherwise effective and hence the problem was not uncovered by testing undertaken strictly in conformance with Works Testing Handbook). This incident is actually one of several which has occurred with swinging overlaps implemented in SSI style data; it is far too easy for people to get things subtly wrong. One of the mitigations since put into place is the running of computer test scripts to exercise the data as an enhanced “Rogue Point Test”, which I regard as a pragmatic response but a tacit admission that our other processes are insufficient to prevent such a problem arising in the first place!

The first part of the question asked why CM was necessary through the whole life-cycle; your answer seemed quite weak on this- it did little to explain the WHY and definitely the LIFE-CYCLE (note for the system life, not just the duration of project implementation) was very scantily treated.  OK you mentioned design and test but really just focusing on the implementation of a project; you could have discussed: 

• Defining the client’s requirements for what the project is intended to achieve,
  
• Getting the locations built to an initial design (i.e. before it achieved AFC status and therefore perhaps before an IDC held so may be the original version of the TFM allocations might need to get altered once the niceties of the data implications became clear- an incident comes to mind that involved the original plane of a new TFM for additional TPWS changing to use that new TFM to reallocate the ATP bit so as to free up a bit on the signal’s own TFM for the TPWS bit comes to mind)’
  
• Correlation status of the existing wiring, equipment mod state and software versions at any interface
  
• Transferring Inherited SSI data into Smartlock, 
  
• Subsequent alterations to the data of a previously commissioned Smartlock,
  
• Constant refinement of the SSI DIS papers that give the guidance of the data structures to be used,
  
• Implications of interlocking changes upon the data for the technician’s support system,
  
• Compatibility of Smartlock with SSI TFMs of various mod states,
  
• Ensuring that the testing is undertaken on a known compatible system (data testing generally performed off-site and the likelihood is that the version of the hardware / software for the generic product will continually evolve, so that the “target system” supplied for different projects will differ and so the off-site testing rig must be known to be compatible with the one that it is emulating), 
  
• the fact that the version of the data upon which a tester has written a Test Log may not be the current version that the designer is working upon, 
  
• Control of the USB sticks (data issue to offsite and on-site testers- who may at times deliberately be using different versions for Principles testing and for Through testing) and then those to be placed within the commissioned equipment and those given as maintainers’ spares holding (which also needs to have the relevant hardware of correct mod status etc.),
  
• Often a series of stage work versions of data is needed- perhaps built upon each other or individually backstage do from “final data” and that the need to make a change in one of them might actually need to be similarly replicated across a whole set of them,
  
• Obsolescence management when perhaps the software may need to get transferred to new hardware, or the external TFMs eventually get replaced by the new generation of I/O.
  

You needed to get across the message that CM is more than bureaucratic form filling and that it is an essential underlying element for any form of quality management and assurance process. 
The essence is controlling the COMBINATION of things to define exactly the system being considered. 
Lifecycle starts at the first definition and continues until disposal 

• as-planned, 
  
• as-designed, 
  
• as-built, 
  
• as-evolved during support phase.
  

CM has 4 key elements: 

• Identification 
  
• Change Management 
  
• Status Accounting (i.e. which changes have been incorporates, which are approved but not yet incorporated, which are currently potential changes being assessed etc.)
  
• Audit.
  

   
I thought your answer was better regarding HOW managed, but did seem to biased towards document version control rather than checking software versions, check-sums, CISR / baselines.  
In essence any CM plan needs 

• to identify which of all the various input documents and products of the design process actually need to be under configuration control and define as “Configuration Items”,
  
• to control changes to these CI,
  
• to record any changes to these CI,
  
• to assess the impact of any such change on anything else,
  
• to recognise that at any time there may be several extant versions of an element being used by different people for different purposes on a project, or from the version being used on this project compared to others used for different projects elsewhere.
  

I didn’t really understand your 2nd bullet (perhaps the first word is missing and I read the second as “hint” but perhaps it was “Maint”…).

Not sure either about your comment of new TFMs; as I understand it NR have over recent years become increasingly concerned about the current loop from a DLM being kept short and therefore contained within a single location or rack within an REB (I don’t think based on new TFMs, not actually sure that there is any evidence emerged from the decades of previous practice that forms a basis for the decision and I don’t see it as a CM issue; however if you are right that new TFMs are less resilient than older versions then indeed this would certainly be a compatibility and therefore a CM consideration.

Part b 
was tackled reasonably, but I think the fact that there is a version control and formal record of changes as the design evolves towards approval is far more important from a CM perspective than the traceability of the individuals involved.  
Don’t forget also the various production aids, test tools, simulators and suchlike used for the verification and validation. Similarly the training courses and support manuals, the standard spares list and a host of other documentation must be kept in step- not only to ensure that the correct information is supplied to the client upon original commissioning, but also continual reviewed so that it stays appropriate.  This of course does NOT mean always updated to the latest version of the product since this would be incorrect for the specific installation; however when hardware is raised a mod state or indeed replaced by obsolescence then the installed system must continue to be supported. 
Similarly if the system software (as opposed to the site specific data) is upgraded to resolve an issue, then a decision needs to be made whether this change is to be made at the site or whether it is to retain its original version; of course any incompatibility issues must be anticipated.  Over time the particular mix of standards, hardware components and software components at the various installations of what is ostensibly one product will diverge and can become a CM nightmare; this is one driver to bring particular sites into conformance with one of a limited range of possible combinations. In the commercial software world, one sees this in the likes of Microsoft trying to force consumers onto their most recent version of Windows as don’t want to support the legacy versions; the relationship between a railway and its supply chain is somewhat different and products contractually do have to be supported for typically 25-30 years and CM is very important for this- none of your answer appeared to address this.


I think that this “continued support of installed base of similar but different” implementations was really the intention of the last part of the question; the only hint that your answer was attempting to address this was by discussing the changes in the post-construction phase with Test Logs and Mod Sheets.  This phase is important (how many times has some change that was intended to address one issue resulted in creation of a different, and sometime worse, issue?) and hence worth including somewhere, but I don’t think was what this last part was really seeking.


In summary, I think that your answer showed that your experience was as a Control Table and data designer and as a consequence you had interpreted the question too narrowly.  
You made some reasonable points and it was OK as far as it went, but was too limited. I think you didn’t mention the word “baseline” at all; version control is not just being certain to get the latest version of anything but to be able to get the relevant defined version which should be being used at that time by that process and this is often different.  I am sure that you know this (for example the various “drops” of Smartlock interlocking data that are given to Delta Rail as the supplier of control system to which it is to interface- they need to work on a series of known version with the changes between them identified rather than being told about each individual change in real time), but your answer really did not get that across.

I am sure that the examiners would encounter far worse attempts and this answer would therefore look relatively good by comparison; I think it would just about pass, being pulled through by the middle section.  I am sure that you could have done quite a lot better if you had embraced the whole question and hopefully the above can help you see that you could have done so.