Table of Contents MANAGING THE TSR LIFECYCLE... 1 OVERVIEW... 2 LIFECYCLE FOR PLANNED TSRS... 2 TYPICAL WORKFLOW (PLANNED TSRS)... 3 LIFECYCLE FOR UNPLANNED TSRS... 5 TYPICAL WORKFLOW (UNPLANNED TSRS)... 5 BUSINESS RULES... 6 Page 1 of 8
Overview As the end-to-end planning process proceeds, information will be agreed for any TSRs which are required to support worksites and both will be recorded in PPS: at any time, the current state of a TSR and the worksite which requires it is defined by the value of the status parameters for that TSR and worksite. A TSR which is applied in support of engineering work may be applied for a number of different reasons, for example: It may be applied to a track adjacent to that on which the work is taking place, in order to protect the workforce, over the same time period as the work itself. It may be applied to the track on which the work is taking place, but over a time period following completion of the work (while the new trackwork beds in ). In addition, TSRs may be identified on the basis of track condition, independent of any work which has been planned. Whenever you change the information recorded about a TSR in PPS, you should consider whether the change is significant and therefore warrants a change to the status of the TSR at the same time, making any status changes in accordance with the business rules defined below. Unlike possessions and worksites, a change to the status of a TSR does not result in email notifications being sent to interested parties. Train Operators, Contractors and others who may be interested in TSRs which affect them can, however, search for TSRs recorded in PPS (on the basis, for example, of TSR status, their lines of route and date/time). An outline business process for managing TSRs may be found in the NAU business process manual. Lifecycle for planned TSRs The planning lifecycle for a TSR which is required in support of planned work follows the same lifecycle as that for the work itself, and is described in full in Managing the worksite lifecycle and in outline below. This lifecycle is supported by the worksite email notification facility, together with the TSR status indicator, TSR access privileges granted to users and use of the TSR comments noticeboard. Page 2 of 8
The allowable status values for a TSR and the usual status transitions which will occur are shown in the following diagram: Create Contractor, Network Rail more detailed rework required changes made 01 Work In Progress ready for consultation TSR Status 03 Changes Required Network Rail consultation 02 Proposed changes required approved by Network Rail updates 04 Agreed 05 Cancelled complete no longer required End A TSR may be set to cancelled or back to work in progress from any preceding state. Note that a TSR remains in agreed status even after it is no longer in force (just as for possessions and worksites). Typical workflow (Planned TSRs) The following workflow is based upon a standard set of PPS user access rights which have been set up in PPS (as at July 2003) (these rules are subject to change in the light of experience). It is based upon the premise that TSRs, if planned (rather than reactive in response to an inspection of track condition), are planned on the basis of their need to support corresponding worksites. The workflow for worksite and TSR should therefore go hand-in-hand, with the TSR being linked to the worksite and the email notification of the worksite being used as a trigger for users also to inspect linked TSR records in PPS. What follows is therefore an abbreviated version of the workflow described in the managing the worksite lifecycle topic. The maintain tsr and tsr display work in progress privileges must be set for users in exactly the same way as the maintain worksite and worksite display work in progress privileges for those same users, except in the case of NAU users. Page 3 of 8
Note in particular the following implications: Network Rail RDPU and ADPT users will have full maintain tsr and tsr display work in progress privileges. Contractors will have restricted maintain tsr and tsr display work in progress privileges. Only the NAU TSR Manager requires full maintain tsr and tsr display work in progress privileges (other NAU users may have these privileges for support purposes, but would not normally expect to maintain TSR records). 1. A user (usually a Contractor, but could be a planner in the RDPU or ADPT) creates the initial TSR record and sets the status to Work In Progress. 2. While the TSR information is still being created, only those users with tsr display work in progress privilege will be able to view the TSR record in PPS. 3. When the planner has completed the worksite and associated TSR records, he links the TSR and worksite together and changes the status of both worksite and TSR to proposed. The worksite status change causes an email notification to be sent out to interested contractors and Network Rail planners (RDPU and ADPT) on the basis a number of rules which are set up in system tables (see Managing the worksite lifecycle). 4. The recipient uses the email as a prompt to log into PPS and review the proposed worksite and associated TSR. The recipient makes his review comments known by posting them to the worksite and TSR noticeboards, typically to raise objections, register agreement, identify further information or to request a meeting to discuss the proposed work / TSR. 5. After an interval to allow time for recipients to receive worksite notification emails and respond, the Network Rail planner reviews the worksite and TSR noticeboards and may typically: Post comments to the noticeboards (in response to the contractor comments) OR Make changes to the worksite and/or TSR which will resolve comments received and set status of both records to agreed if appropriate OR Set the status of both records to changes required and submit the records. Resolve the issues offline by setting up a meeting with the contractor and/or the Network Rail plan owner if necessary before making any further changes OR Set the status of both records to changes required and submit the records. Make changes to the worksite and TSR which should resolve the issues raised and set the status to proposed (if the planner has sufficient delegated authority to do this without referring the changes back to the plan owner) (this workaround is necessary in order to force a new email notification to be sent out) OR Set the status of both records to cancelled if the worksite cannot be agreed. 6. If the status was changed to agreed at step 5, worksite email notifications will be set out to interested contractors and plan owners (RDPU and ADPT). 7. If the status was changed to changes required at step 5, email notifications will not be set out to any interested parties. 8. If the status was changed to proposed at step 5, worksite email notifications will be set out to interested contractors and Network Rail planners (RDPU and ADPT), and the process steps from step 3 onwards are repeated. Page 4 of 8
9. If the status was changed to cancelled at step 5, worksite email notifications will be set out to interested contractors but not Network Rail planners or plan owners. Lifecycle for unplanned TSRs The planning lifecycle for TSRs which are imposed as a result of track inspections is simpler than that for planned TSRs, but the following rules are common to both planned and unplanned TSRs: 1. The same TSR status values apply 2. The same user access permissions to TSR records in PPS apply 3. When a TSR is proposed or agreed, the information should include the start and finish date/time. Notes: 1. An unplanned TSR will not normally have any associated worksites (until such time as engineering work to remove the TSR is planned reactively). Management of such TSRs will not therefore be supported by email notification and will need to be driven by manual processes, supported by manual inspection of the PPS records. 2. PPS does not currently support the distinction between ESRs (Emergency Speed Restrictions), TSRs and PSRs (Permanent Speed Restrictions) and the transition of a speed restriction between these categories, except to note that a TSR may be marked as having originally started life as an ESR. 3. In order for any speed restriction to appear in statutory publications which are generated from PPS data (e.g. Section A of the Weekly Operating Notice), it needs to be recorded as an agreed TSR in PPS. Typical workflow (Unplanned TSRs) 1. A user (usually a Contractor, but could be a planner in the ADPT) creates the initial TSR record and sets the status to Work In Progress. TSRs entered in this way will normally be promoted to agreed and implemented almost immediately, since they are required in response to an observed track or lineside problem. 2. While the TSR information is still being created, only those users with tsr display work in progress privilege will be able to view the TSR record in PPS. 3. The ADPT reviews new proposed TSRs at least on a weekly basis and calculates the time loss, enters the estimated time loss into the time loss field on the PPS record and checks the p coded field if the time loss is estimated to be within the engineering allowance for this track. If a TSR is accepted, the ADPT sets the status of the TSR to agreed. 4. The NAU TSR Manager reviews a sample of the new/recently agreed TSRs in PPS on a weekly basis for correct completion of p-coded and time loss fields. 5. TOCs are compensated for time delays due to unplanned TSRs according to Schedule 8 of the Track Access Conditions. Compensation is managed by the Regional performance teams on the basis of actual measured time delays recorded in the TRUST system. (Note: There is no automated connection between estimated delays and p-coding as recorded in PPS and the actual delays and p-coding recorded in TRUST). Page 5 of 8
Business rules General 1. Any user who has the ability to maintain TSR records also has the ability to change the status of the TSR, and anyone who creates a TSR at work in progress status should link the TSR and associated worksite in PPS and set the status to proposed once the information about both TSR and associated worksite is sufficiently mature. 2. However, once the worksite and TSR has progressed beyond work in progress status, you should not make any further changes to the status of either record unless you are a Network Rail planner or Plan Owner. 3. Before changing the TSR status from work in progress to proposed, the Contractor or Network Rail Planner should ensure that: they have considered what disruption might be caused to train services (see Managing the worksite lifecycle). at least the following TSR information has been completed: the location and date/time boundaries of the TSR the reason for the TSR the line(s) affected the anticipated speed restrictions for both passenger ands freight trains. 4. When reviewing proposed TSRs and before setting the TSR status to agreed, the Network Rail planner or plan owner (RDPU or ADPT) should: Check the completeness of the information against the above criteria. Check any linked worksites (see Managing the worksite lifecycle). Calculate the time loss due to the TSR and enter it on the TSR record. Check whether the TSR is within the engineering allowance specified in Section 6 of the Rules of the Route, and check the p-coded field if it is (typically 90% of TSRs fall outside the engineering allowance). If there are other TSRS on this section of track, move the p-coding indicator to or from this TSR in order to optimised the use of engineering allowances. Complete the responsible manager field by selecting the most appropriate TRUST responsible manger field, depending upon the classification code for the TSR (there are a number of TSR codes within TRUST, each of which relates to a number of responsible manager codes). Consult with the NAU Access Manager for the relevant route. 5. When considering cancellation of a worksite (from any preceding state), the Network Rail planner or plan owner should check whether the worksite has already been linked to a TSR and, if appropriate, also set the TSR status to cancelled. (Note that cancellation of a TSR is not the same as removing the TSR: a TSR which has taken place but is now no longer required should remain in agreed status but its end date should be changed to reflect the date when it was/will be removed.) Page 6 of 8
6. If you are considering changing the status of a previously agreed worksite, you should also check whether it has been linked to a TSR, and review the effect of any changes which may need to be made to the TSR. 7. If you are considering changing information held about an agreed TSR (for example, to extend the time period or change the freight or passenger speed), you should agree the changes with the NAU Access Manager for the relevant route. 8. You should only change information held about a TSR which is already at agreed or cancelled status if you are an authorised Network Rail plan owner (RDPU or ADPT). TSR Lifecycle Management, pre-engineering conference: 1. The RDPU is responsible for correct details being in P3 for transfer to PPS. (Note: import from P3 to PPS will be delivered later in 2003). 2. The RDPU is responsible for checking that all TSRs associated with planned engineering work are complete in PPS and linked to their respective worksites as part of the process of finalising the Annual Engineering Work Plan. TSR Lifecycle Management, post-engineering conference, pre-rules of the Route V1: 1. The NAU TSR Manager should use the information in PPS to create a draft Annual TSR plan, which defines all planned TSRs for a timetable year. (The most suitable PPS report to support this is probably the RT01 TSR Summary report). The TSR Manager will negotiate this plan with Train Operators in advance of Rules of the Route Version 1, and agree any revised engineering allowances which may need to be published in Section 6 of Rules of the Route for the applicable timetable year in order to support the planned engineering work. TSR Lifecycle Management, post-rules of the Route V1: 1. The NAU is now responsible for all changes to planned TSRs in PPS. After RotR Version 1, any changes to possessions and worksites which are disruptive and require a supporting TSR should be referred to the appropriate NAU Access Manager and the NAU TSR Manager. 2. The NAU TSR Manager will: Check the calculated time loss / p-coded flag input by the RDPU or ADPT. Negotiate possible changes with the planning teams. Check that the TSR does not break the TOC s contracted journey times (engineering allowance). Negotiate major time loss issues with affected TOCs. Publish any required updates to the draft annual TSR Plan. TSR Lifecycle Management, post-handover to ADPT at TT-46: 1. The APM s representative, who may be a contractor at depot level, may propose a new worksite to be added to an existing possession, or a deletion of a worksite from an existing possession. The ADPM is responsible for ensuring that this change does not affect the disruptive nature of the possession, and if it does, should refer the change to the NAU. 2. The NAU TSR Manager will continue to monitor the time loss and negotiate with TOCs as above. 3. Should a new TSR be required, then the requester / contractor or ADPT should enter it into PPS. Page 7 of 8
TSR Lifecycle Management, other: 1. Requests for unplanned TSRs may occur at any time and will follow the unplanned TSR lifecycle defined above. 2. ADPTs should review all TSRs currently in force at least once per 4-week period, and update the to date for any TSRs which are no longer required. 3. At the end of each planning year, the NAU TSR manager should review all outstanding TSRs which have an end date of the end of the planning year, to establish whether they need to be extended into the following planning year, and update the TSR with a new end date if necessary. Page 8 of 8