C-OSS Pre-Booking, C-OSS Timetable

Description

Purpose

Include the C-OSS capacity handling work in the Dossier processing workflow. Introduce a C-OSS agency type of timetable and allow certain editing possibilities for coordinating C-OSS agencies responsible for path section from PaP in RU-IM pair based dossiers in PCS.

 

Scope

This document describes necessary changes to the PCS Dossier processing workflow as part of the RU/IM harmonization process.

It additionally but as organized in separate phase of development it describes the changes to the timetabling process and authorization changes for the RU, IM and C-OSS roles.

It will impact the workflow module of PCS and possibly the timetable presentation and interface schema.

Process

Data Model/Business Model

Dossier processing Workflow

Pre-booking phase should be recognized by the system for the following

(a)   process types: NPR, LPR, AHPR and AHPR (pre-accepted)

(b)   dossier types: Default, Change, Status quo, Change in current timetable

Pre-booking phase is not supported for partially harmonized dossiers. This is in line with current behavior as dossiers with PaP’s do not supporting partial harmonization either.

The C-OSS users that are involved in a dossier will now have their own processing status indicators or so called traffic lights. Entry of mandatory common train parameters will be checked for C-OSS separately.

Timetable processing

Support agency type C-OSS as timetable owner i.e. C-OSS Timetable

Web services schema

As an on-demand option the IM’s can receive the new processing status of the C-OSS in the agency notification during the Pre-booking phase.

The new C-OSS timetable won’t be included in interface schema. The IM agencies expressed interest in receiving the C-OSS timetable in GetDossierResponse with the purpose of comparing it against the RU request. However, this can be achieved by comparing the IM timetable right after the dossier is promoted to PE when the C-OSS timetable will be copied to the IM timetable.

Functional Requirements

Dossier Processing Workflow

The main implication of the existence of Pre-booking phase is that the coordination C-OSS agencies, involved in a dossier that requests capacity on their corridor, will handle their own traffic light that is independent of the one belonging to the IM that will stay untouched in the duration of the Pre-booking phase.

1)     The system shall recognize Pre-booking phase between PR and PE phases for Dossiers that request PaP capacity.

2)     The system shall place a dossier in Pre-booking phase automatically after milestone PR phase has been reached giving overall dossier read-only access to RU and IM agencies and write access to coordinating C-OSS agencies implicated in the dossier by requested PaP capacity.

3)     Upon entering Pre-booking phase for the first time the system shall reset C-OSS traffic lights to blue (untouched) and with any subsequent re-enter to Pre-booking to yellow (processing).

4)     Once the dossier is in Pre-Booking phase the following requirements apply:

a)     The system shall allow for an involved C-OSS in a Dossier to change the acceptance indicator to green for pairs that he is involved in and are related to Pap Requests in a Reserved Status Category or part of Tailor-made Status.

b)    The system shall prevent the involved C-OSS in a Dossier to change the acceptance indicator to green for pairs that he is involved in and are related to Pap Requests in a status of Invalid or Not Requested category with the exception of Tailor-made status.

c)     The system shall downgrade a green acceptance indicator of a C-OSS that is involved in a pair that is related to Pap Request for which the C-OSS is reverting the reservation by setting the status back to Requested.

d)    The system shall set automatically the acceptance indicator for a C-OSS pair to green as soon as all related Pap Requests are in Reserved Status Category or part of Tailor-made Status.

e)     The system shall allow the C-OSS to downgrade his green acceptance indicator to yellow unconditionally.

5)     Pre-Booking to Path Elaboration promotion

a)     The system shall allow for an involved C-OSS to promote the dossier to PE phase as soon as all C-OSS acceptance indicators are green.

b)    The system shall promote automatically all NPR dossiers to PE phase with involved C-OSS with all green C-OSS acceptance indicators in the morning one day before X-7.5 deadline and in the evening of the X-7.5 deadline. (Note: the function will be developed, but disabled for the time being as C-OSS Managers indicated that they would like to promote dossiers on their own)

c)    The system shall promote automatically all AdHoc and LPR dossiers to PE phase with involved C-OSS with all green C-OSS acceptance indicators nightly.

C-OSS timetable creation and handling

  1. Once the dossier reach Pre-booking phase the system shall:
    1. Create the C-OSS timetable as a copy of the IM timetable
    2. Assign a reference point to the first path section belonging to a RFC corridor for which the C-OSS timetable has requested capacity. (same as in IM timetable in PR phase)
  2. The system shall include the C-OSS timetable in all related reports and PDF exports where the IM timetable is included as representation of the offer.
  3. The system shall allow read only access to involved IM users for the C-OSS timetable from Pre-booking phase onwards.
  4. The system shall allow read only access to involved RU users for the C-OSS timetable from Draft Offer onwards.
  5. The system shall allow all users to select C-OSS timetable paths for comparison against other paths for which the user has at least read privileges.
  6. The system shall generate timetable combinations for the C-OSS timetable paths too.

C-OSS timetable editing in Pre-Booking phase

The intention of introducing C-OSS timetable is to allow certain flexibility to the coordinating C-OSS agencies in handling corridor capacity. Corrections done by the C-OSS users must not in any case impact the requested running days. IM agencies will be able to make easy comparison of their work during Path Elaboration and Post-Processing against the original offer prepared by the C-OSS in the Pre-booking phase. The ability for editing should also facilitate more cases to be eligible for alternative offer with less constraints on alternative PaP selection process. For instance times in F/O/IFO parts of the path that did not fit in with certain alternative PaP will not be a problem anymore.

  1. The system shall allow write access to coordinating C-OSS agency users to the C-OSS main timetable.
  2. The system shall allow a coordinating C-OSS to change the arrival/departure time in non-protected border path section from Flex Pap belonging to their corridor in the C-OSS timetable main path.
  3. The system shall allow a coordinating C-OSS to change common and IM specific train parameters in path sections from Flex Pap belonging to their corridor in the C-OSS timetable main path
  4. The system must prevent a coordinating C-OSS to change the corridor reference point.
  5. The system shall allow a coordinating C-OSS to insert Flex PaP intermediate path sections on behalf of the responsible IM of the PaP and remove additional intermediate path sections entered by the RU.
  6. The system shall propagate changes made by the coordinating C-OSS in combined PaP main path in C-OSS timetable to combined pap auto-generated subsidiary paths that are managed by the system.
  7. The system shall copy the C-OSS timetable to the IM timetable once the dossier reaches Path Elaboration.
  8. The system must never change the calendar of the C-OSS timetable in any of the IM or C-OSS reference points.

Dossier search

1)     The system shall allow access to the dashboard for C-OSS users.

2)     The system shall allow definition of C-OSS user filters and labels.

3)     The system shall support the definition of pre-defined filters based on C-OSS traffic lights.

4)     The system shall apply the ‘My acceptance indicator’ criterion in the Advanced search based on the user’s agency, C-OSS traffic light shall be used for C-OSS users and IM traffic light for IM users.

5)     For IMs the system shall give back result based on only the IM's acceptance indicator and ignore the C-OSS traffic light.

PaP capacity handling

  1. The system shall maintain the requested and reserved capacity based on the C-OSS timetable for dossiers in Pre-booking phase.

Alternative PaP offer

Before the workflow changes proposed in this document the work of the C-OSS in the dossier was done during PE phase and the actual step in the PaP request handling process was only reflected in the path processing status which among other things indicates whether the C-OSS processing part of the PE phase has finished. This now is split in two separated phase by the introduction of Pre-booking phase (see Req. C). Additional workflow branch will be introduced for handling Alternative PaP offer.

  1. The system shall recognize a workflow branch stemming from the Pre-booking phase:
    1. The system shall place the Dossier in Alternative Offer Reserved phase once an alternative PaP is selected and inserted in the Dossier. When C-OSS changes the originally requested PaP (no alternative has been selected), Alternative Offer workflow branch shall be triggered (either manually by the C-OSS or by PCS).
    2. The system shall allow the coordinating C-OSS that is responsible for an inserted Alternative Pap in the C-OSS timetable to promote the dossier to Alternative Offered phase.
    3. The system shall allow the coordinating C-OSS that is responsible for an inserted Alternative Pap in the C-OSS timetable to switch the dossier back to Pre-booking phase from Alternative Offer reserved phase.
    4. The system must remove the Alternative PaP that was inserted in a dossier upon the dossier reaching Pre-booking phase from an Alternative Offer Reserved phase.
    5. The system shall allow for a user from RU agency responsible for path sections of an Alternative PaP in a dossier to set their traffic light to green.
    6. The system shall switch the dossier to Alternative Offer Rejected as soon as RU responsible for path sections of an Alternative PaP in a dossier set their light to red.
    7. The system shall allow the leading RU to switch a dossier from Alternative Offered to Alternative Offer Accepted phase when all lights are green.
  2. The system shall allow Alternative PaP selection, with the following constraints:
    1. pap from the same corridor
    2. different pap id that is not already used in the dossier including the pap being replaced
    3. no new agency is involved that was not involved in the PaP that is being replaced
    4. available capacity on the full stretch that is superset of the requested days in the PaP that is being replaced
    5. inserting the alternative PaP in the dossier does not indicate a need of offset against surrounding F/O/IFO path sections

, with the follow actions being performed before checking insertion constraints and before

Alternative PaP is inserted in the dossier:

  1. The system shall clear F/IFO path section actual arrival/departure times and adjust their offsets accordingly when alternative PaP is selected for Alternative offer that has reference point arrival/departure time earlier than the latest actual arrival/departure time in the respective F/IFO path sections.
  2. The system shall clear O/IFO path section arrival/departure times and adjust their offsets accordingly when alternative PaP is selected for Alternative offer that has latest actual arrival/departure time later than the earliest actual arrival/departure time in the respective O/IFO path sections.

Use cases

The system supports many dossier structures with PaP’s. Following use cases are selected for show casing the changes in this document.

One Corridor

In this use case the dossier structure that consists of two PaP’s from the same corridor is examined. There is only one C-OSS reference point because as a consequence of all PaP’s belonging to the same corridor, there is only one coordinating C-OSS agency involved in the dossier. The feeder and outflow path sections have multiple reference points – one for each responsible IM agency.

C-OSS can edit Flex PaP times

The constraint of this edit is that the times cannot create offset in regards to times in feeder, outflow and intermediate path sections (sandwich or PaP intermediate path sections).

C-OSS can create alternative offer with a PaP with times

  1. later than the feeder path sections, changed second pap times

  1. earlier than the feeder, consequently feeder times will be cleared

  1. later than the sandwich feeder, consequently feeder times will be cleared

  1. later than the outflow, consequently outflow times will be cleared

  1. earlier than the feeder and ends later than the sandwich outflow, feeder and outflow times will be cleared and offset adjusted

The offsets in the feeder after clearing times must be kept as manual offsets because the calendar cannot be changed in this part, only the responsible IM can do that in PE phase. Additional model changes and responsibility during RU timetable will need to be assigned in order for the system to be able to support C-OSS user editing the main path outside of his responsibility. With the current model the entire or partial stretch of the feeder could theoretically belong in territory outside of the corridor responsibility and under the responsibility of an IM agency that is not associated with any of the C-OSS agencies involved in the timetable.

Cross Corridor

The only difference here is that there is more than one coordinating C-OSS involved in the dossier and there is a reference point for each corridor. These reference point are automatically assigned by the system when the IM timetable is created out of the RU timetable. Inherently the calendar is consistent despite of the existence of multiple reference points. The reference points must not change nor the calendar in the feeder and outflow path sections. The calendar of the requested PaP path section must not change.

Open questions

  1. In cross-corridor requests which C-OSS can promote the dossier to PE phase? RNE: both.
  2. In Active Timetable IM timetable catalogue flags are cleared, i.e. no trace is left in the timetable indicating where PaPs were inserted. What should happen with the C-OSS timetable? Should we clear everything there too? RNE: No, keep the flags.
  3. When C-OSS adds an intermediate path section into a block that uses Flex PaP capacity should he be able to select the responsibel IM? Even if PaPs are created till the border they may involve sections from the neighboring IM with changed responsible IM. RNE: no need for that. It will be anyhow a temporary solution as SBPA should solve the border areas, in rest of the cases the responsible IM is always clear.
  4. Should we disable Combined PaP feature in PCS for the next timetable period? RNE: no for the time being.
  5. After complete tailor made there is no reason to give write access anymore to the C-OSS users, because there is no more possibility for them to start alternative offer, insert a PaP or edit anything in the TT: RNE: it's true, however don't mix the timetable with the dossier. Timetable should be read-only for them in such cases, but they still have editing rights on the dossier and acceptance indicator changes, promotion shall be still possible for them.

 

Actor
IM-user
RFC-user
Group concerned
CCB Group
TB Group
PCS Team
Consequences for PCS Interface

Web services schema

As an on-demand option the IM’s can receive the new processing status of the C-OSS in the agency notification during the Pre-booking phase.

The new C-OSS timetable won’t be included in interface schema. The IM agencies expressed interest in receiving the C-OSS timetable in GetDossierResponse with the purpose of comparing it against the RU request. However, this can be achieved by comparing the IM timetable right after the dossier is promoted to PE when the C-OSS timetable will be copied to the IM timetable.

New dossierstatus_id is created for identifying the Pre-booking phase, the new id is "PB".

CR ID
1304
State
In development
Priority
High
Originated from
PaP Product Definition
PCS Team confirmation
Confirmed
User Group Decision
Not yet
Date/Time
29/08/2017 - 07:30