Guidelines for C-OSS concerning PaP and RC Management ... · PDF fileGuidelines for C-OSS...

Guidelines for C-OSS

concerning PaP and RC Management

Version 1.0

RNE Guidelines for Corridor One-Stop Shops (C-OSSs) of

European Rail Freight Corridors (RFCs) for managing

Pre-arranged Paths (PaPs) and Reserve Capacity (RC)

RailNetEurope Oelzeltgasse 3/8 AT-1030 Vienna

Phone: +43 1 907 62 72 00

Fax: +43 1 907 62 72 90 [email protected]

www.rne.eu

mailto:[email protected]

http://www.rne.eu/

Guidelines for C-OSS for PaP and RC Management, Version 1.0

2

VERSION AUTHOR DATE CHANGES

0.1

Jürgen Pfeiffer, DB Netz AG Fahrplan und Kapazitätsmanagement Miloslav Kogler, RNE RFC Senior Manager

2016-09-06

First draft of common Guidelines for C-OSS and PaPs/RC, intended to replace RNE’s individual Guidelines for Corridor-OSS and Guidelines for Pre-arranged Paths

0.2

Jürgen Pfeiffer, DB Netz AG Fahrplan und Kapazitätsmanagement Miloslav Kogler, RNE RFC Senior Manager

2016-09-23

Second draft of common Guidelines for C-OSS and PaPs/RC, incorporating the results of PaP Product Definition and recommendation to streamline the document

0.3

Philipp Koiser, RNE Sales & Timetabling

Manager Miloslav Kogler, RNE RFC Senior Manager

2016-10-05

Third draft of common Guidelines for C-OSS and PaPs/RC, incorporating the amendments to the Process Map/Description agreed in the last PaP Product Workshop, comments received form the working group and alignment with the C-OSS proposal for revision of the current FCA

1.0 Miloslav Kogler, RNE RFC Senior Manager

2016-12-08 Approved by the RNE General Assembly


3

Table of contents 1 Glossary/abbreviations ............................................................................................................ 5

2 Target group and scope of this document ................................................................................ 7

3 Documentation relevant for these Guidelines ........................................................................... 7

4 Requirements .......................................................................................................................... 7

4.1 EU Regulation 913/2010 ................................................................................................... 7

4.2 Framework for capacity allocation (FCA) .......................................................................... 8

4.3 RNE Process Calendar ..................................................................................................... 8

4.4 RNE Guidelines for the Coordination/Publication of Planned Temporary Capacity Restrictions ................................................................................................................................. 8

4.5 RNE Guidelines for Punctuality Monitoring ....................................................................... 9

4.6 RNE Framework for setting up a Freight Corridor Traffic Management System ................ 9

4.7 RNE PCS Process Guidelines .......................................................................................... 9

5 Organisation of the Corridor OSS ............................................................................................ 9

5.1 Set up options for the C-OSS ............................................................................................ 9

5.2 Availability of the C-OSS ................................................................................................. 10

5.3 Customer Confidentiality ................................................................................................. 10

5.4 Tools for the Corridor OSS.............................................................................................. 10

6 Pre-arranged paths (PaPs) and Reserve Capacity (RC) ........................................................ 10

7 Legal status of dedicated capacity ......................................................................................... 11

8 Management of requests for PaPs/RC ................................................................................... 12

8.1 Joint principles for management of PaPs/RC request ..................................................... 12

8.2 Phase 1 - Annual path request ........................................................................................ 13

8.3 Phase 2 - Late path request ............................................................................................ 19

8.4 Phase 3 - Ad hoc path request ........................................................................................ 23

9 PaP Product Definition – Process Maps ................................................................................. 27

9.1 Phase 1 - Annual path request ........................................................................................ 28

9.2 Phase 2 - Late path request ............................................................................................ 32

9.3 Phase 3 - Ad hoc path request ........................................................................................ 35

10 Priority criteria for the allocation of pre-arranged paths ....................................................... 38

10.1 Need for priority determination ........................................................................................ 38

10.2 Consultation in case of conflicts ...................................................................................... 38

10.3 Priority determination by distance and days of operations .............................................. 38

10.4 Additional element for priority determination: Network PaP ............................................. 38

10.4.1 Definition of Network PaP ........................................................................................ 39

10.4.2 Criteria for Network PaP designation ....................................................................... 39

10.4.3 Network PaP designation process ........................................................................... 40

10.4.4 Conflict Management (between X-8 and X-7.5)........................................................ 40

11 Calculating the priority value............................................................................................... 41


4

11.1 Formula for priority calculation if no Network PaP is involved ......................................... 41

11.2 Examples for priority calculation if no Network PaP is involved ....................................... 42

11.2.1 Example 1: Requests for the same PaP sections on a single corridor ...................... 42

11.2.2 Example 2: Requests for the same PaP sections on connected corridors ................ 43

11.3 Formula for priority calculation if Network PaPs are involved .......................................... 44

11.4 Priority determination including Network PaPs ................................................................ 45

11.4.1 Example 3: Conflict is on Network PaP – same number of days .............................. 45

11.4.2 Example 4: Conflict is on Network PaP – different number of days .......................... 46

11.4.3 Example 5: Conflict is on Network PaP – 1st step result is a tie ............................... 47

11.4.4 Example 6: Conflict is on Network PaP – 1st and 2nd step results are a tie ............. 48

11.4.5 Example 7: Conflict is not on Network PaP – same number of days ........................ 49

11.4.6 Example 8: Conflict is not on Network PaP – different number of days .................... 50

11.4.7 Example 9: Conflict is on Network PaP – variant ..................................................... 51

12 Requirements for PCS........................................................................................................ 52


5

1 Glossary/abbreviations

Glossary/abbreviation Definition

AB Allocation Body In this document, only the term Infrastructure Manager (IM) is applied. It refers to IMs and also – if applicable – to Allocation Bodies (ABs).

Ad-hoc path requests Requests submitted by applicants from X-2 till X+12 (covering the running timetable period).

Allocation Means the allocation of railway infrastructure capacity by an Infrastructure Manager or Allocation Body. When the Corridor OSS takes the allocation decision as specified in Article 13(3) of 913/2010, the allocation itself is done by the Corridor OSS on behalf of the concerned IMs, which conclude individual national contracts for the use of infrastructure based on national network access conditions.

Applicant/Applicants Definition in Directive 2012/34: a Railway Undertaking or an International Grouping of Railway Undertakings other persons or legal entities, such as competent authorities under Regulation (EC) No 1370/2007 and shippers, freight forwarders and combined transport operators, With a public-service or commercial interest in procuring infrastructure capacity.

Catalogue path Any kind of published pre-constructed path if it is not a pre-arranged path on a Rail Freight Corridor according to Regulation 913/2010.

Connecting point A point in the network where two or more Corridors share the same infrastructure and it is possible to shift the services applied for from one Corridor to the other.

Corridor OSS (C-OSS) A joint body designated or set up by the RFC organisations for Applicants to request and to receive answers, in a single place and in a single operation, regarding infrastructure capacity for freight trains crossing at least one border along the freight Corridor (EU Regulation No 913/2010, Article 13).

Dedicated capacity Capacity which has to be foreseen by the Corridor Organisations to fulfil the requirements of Regulation 913/2010. It refers to pre-arranged paths and reserve capacity.

Feeder and outflow path Any path/path section prior to reaching an operation point on a RFC (feeder path) or any path/path section after leaving the RFC at an operation point (outflow path). The feeder and/or outflow path may also cross a border section which is not a part of a defined RFC.

Flexible approach When an Applicant requests adjustments to a pre-arranged path, e.g. different station to change drivers or for shunting that is not indicated in the path publication. Also if the Applicant requests feeder and/or outflow paths connected to the pre-arranged path and/or a connecting path between different RFCs, these requests will be handled with a flexible approach.

Handover point Point where the responsibility changes from one IM/AB to another

IM Infrastructure Manager In this document, only the term Infrastructure Manager (IM) is applied. It refers to IMs and also – if applicable – to Allocation Bodies (AB).


6

Interchange point Location where the transfer of responsibility for the wagons, engine(s) and the load of a train goes from one RU to another RU. Regarding a train running, the train is taken over from one RU by the other RU, which owns the path for the next journey section.

Late path request Requests submitted by applicants from X-8 till X-2

MB Management Board

Network PaP “Network PaPs” (in short “NetPaPs”) are PaPs designated to foster the optimal use of infrastructure capacity and address the needs for capacity in specific geographical relations or of market segments with special requirements in train path characteristics. They may be offered on a single RFC or on two or more connected RFCs. Network PaPs consist of contiguous PaP sections linked together and are identified by a special ID or marker in PaP catalogues and IT tools.

Path requests for the annual timetable

Requests submitted by applicants till X-8 (2nd Monday in April) in preparation of the next annual timetable period

PCS Path Coordination System

Pre-arranged path (PaP) A pre-constructed path on a Rail Freight Corridor according to the Regulation 913/2010. A PaP may be offered either on a whole RFC or on sections of the RFC forming an international path request crossing one or more international borders.

Pre-constructed path products

Any Kind of pre-constructed path, i.e. a path constructed in advance of any path request and offered by IMs; applicants can then select a product and submit a path request

Pre-constructed path products are either:

Pre-arranged paths (PaP) on Rail Freight Corridors or

Catalogue paths (CP) for all other purposes

RB Regulatory Body

Reserve capacity (RC) Capacity – e.g. Pre-arranged paths – kept available during the running timetable period for ad-hoc market needs (Article 14(5) Regulation 913/2010)

RFC Rail Freight Corridor. A Corridor organised and set up in accordance with EU Regulation 913/2010

RU Railway Undertaking

TCR Planned Temporary Capacity Restrictions This term covers the earlier used ‘works’, ‘possessions’, ‘works and possessions’ and capacity restrictions. It indicates that the restrictions are planned (no force majeure restrictions) and temporary (no long lasting bottle-necks).

TMS Transport Market Study

X-8 (months) Deadline for requesting paths for the annual timetable (Annex VII (3) Directive 2012/34/EC)

X-11 (months) Deadline for publication of pre-arranged paths Annex VII (4) Directive 2012/34/EU)

For further definitions, please turn to the RNE Network Statement Glossary: http://www.rne.eu/ns_glossary/


7

2 Target group and scope of this document These Guidelines describe the tasks of the Corridor OSS (C-OSS) concerning the management of Pre-arranged Paths (PaPs) and Reserve Capacity (RC), based on Regulation EU 913/2010 and other relevant documents of the Rail Freight Corridors (RFCs) and RNE. Included are the role and functions of the C-OSS in the international timetabling process concerning PaP/RC requests and allocations as agreed by RNE members and the Rail Freight Corridors (RFCs). These Guidelines do not describe the contracting as this is a separate process outside of the C-OSS responsibilities. The document addresses all levels of RNE. It is relevant for all RNE members, RNE working groups and the RNE Joint office. It is also a supporting document for the corridor organisations including the C-OSS. These guidelines are combining the former Guidelines for Corridor-OSS and for Pre-arranged Paths into a common document. At the same time, the results of the PaP Product Definition introducing some adjustments to the RFC-related processes, are an integral part of these guidelines, particularly in Chapters 8 and 9. These adjustments shall be taken into account latest in the Corridor Information Document for the 2019 Timetable. The guidelines have to be reviewed again as soon as the results of the RNE/FTE project “Redesign of the international timetabling process” (TTR) will be available.

3 Documentation relevant for these Guidelines » EU Directive 2012/34 establishing a single European railway area » EU Regulation 913/2010 concerning a European network for competitive freight » Framework for capacity allocation (FCA) on the Rail Freight Corridors » RNE Process Calendar » RNE Guidelines for the Coordination / Publication of Planned Temporary Capacity Restrictions » RNE Guidelines for Punctuality Monitoring » RNE Framework for setting up a Freight Corridor Traffic Management System » RNE PCS Process Guidelines

4 Requirements The activities of the C-OSS are mainly based on requirements laid down in the documents covered in sections 4.1 to 4.7

4.1 EU Regulation 913/2010 In the Regulation 913/2010, the requirements for the Corridor OSS’s role are defined as follows: » Contact point for Applicants to request and receive answers regarding infrastructure capacity for

freight trains crossing at least one border along a Corridor » As a coordination tool provide basic information concerning the allocation of the infrastructure

capacity. It shall display the infrastructure capacity available at the time of request and its characteristics in accordance to pre-defined parameters for trains running in the freight Corridor

» Able to take a decision regarding applications for pre-arranged paths and reserve capacity as specified in Article 13(3)

» Forwarding any request/application for infrastructure capacity which cannot be met by the Corridor OSS to the competent IM(s) and communicating their decision to the Applicant

» Keeping a path request register available to all interested parties.


8

In addition to this, the Corridor OSS shall provide information provided by the RFC MB in the relevant Corridor documentation, in accordance with Article 18. » Information contained in the Network Statements regarding railway lines designated as a Rail

Freight Corridor » A list and characteristics of terminals, in particular information concerning the conditions and

methods of accessing the terminal » Information about procedures for

o Establishment and tasks of the Corridor OSS o Allocation of capacity to freight trains o Authorised Applicants o Procedures regarding traffic management in the Corridor as well as traffic

management in the event of disturbances » Information regarding the Implementation Plan with all connected documents.

4.2 Framework for capacity allocation (FCA) The framework of capacity allocation concerns the allocation of pre-arranged paths as defined in Article 14(3) of Regulation (EU) No 913/2010, and of reserve capacity as defined in Article 14(5) of this Regulation, displayed by the C-OSS for freight trains crossing at least one border on a rail freight corridor. The main tasks for the C-OSS concerning the management of PaPs and RC are laid down in » Chapter II: Principles for the offer of PaPs and RC and » Chapter III: Principles of allocation of PaPs and RC The FCAs are adopted by the Executive Boards of the RFCs and are legally binding documents for the activities of the C-OSSs. In case any differences between FCA(s) and these guidelines are detected, the rules laid down in the FCA(s) have to be respected.

4.3 RNE Process Calendar The RNE Process Calendar is set up for each calendar year, fixing all times and deadlines relevant for the planning process of the next timetable period.

4.4 RNE Guidelines for the Coordination/Publication of Planned Temporary Capacity Restrictions

These Guidelines establish the process for the coordination of planned temporary capacity restrictions in accordance with Article 12 of the Regulation. Restrictions on a Corridor section have an influence on the number of PaPs that it is possible to offer. The limitations can be defined in terms of time, section and quantity. Article 12 of the Regulation requires the publication of the works in one place for each Corridor. This process will affect the Corridor OSS, because the Corridor OSS shall provide information regarding available capacity (Article 13) and information contained in the Network Statements regarding railway lines designated as a Rail Freight Corridor (Article 18).


9

4.5 RNE Guidelines for Punctuality Monitoring The Guidelines are based on the RNE Guidelines for Train Performance Management and describe the process for monitoring the performance of international trains on the RNE and RFC Corridors, and the involvement of RNE Corridor Managers in this process. By establishing the RFCs the RNE Corridors were replaced by the RFCs. Article 19(2) of the Regulation states that the performance shall be monitored. According to Article 19(3) a satisfaction survey of the users shall be organised. The results of the report and the survey shall be published once a year. According to the RNE Guidelines for Train Performance Management and the Guidelines for Punctuality Monitoring, this requires the involvement of the RNE Corridor Managers. If the RFC Management Board (MB) decides to transfer the RNE Corridor Manager’s tasks to the RFC, these tasks could also have an impact on the setup of the Corridor OSS.

4.6 RNE Framework for setting up a Freight Corridor Traffic Management System

These Guidelines are set up in accordance with Articles 16 and 17 of Regulation 913/2010. They lay down the demand for a common approach to traffic management and traffic management in the event of disturbances. Article 13(2) lays down that information referred to in Article 18 shall be provided through the Corridor OSS. This includes the procedures described in Articles 16 and 17. Therefore the Corridor OSS shall also be able to give information regarding procedures for traffic management and traffic management in the event of disturbances.

4.7 RNE PCS Process Guidelines These annual guidelines describe the PCS phases according to the international timetabling calendar and international timetabling processes. The aim is to guide PCS users through the entire timetabling process.

5 Organisation of the Corridor OSS

5.1 Set up options for the C-OSS There are three (3) main possibilities to set up the Corridor OSS: » Its function is that of a coordination tool » As one IM in the Corridor acting on behalf of all IMs in the Corridor » As a joint body set up or designated by the Corridor organisation of each Corridor. Based on this RNE has analysed the possibilities for the set up as an RNE services to their customers. They are listed here without any individual ranking. » Representative OSS, one IM in a Corridor acts on behalf of all IMs in that Corridor supported

by a coordinating IT-tool. » Dedicated OSS, a joint body set up or designated by a Corridor organisation supported by a

coordinating IT-tool. » IT OSS, a coordinating IT-tool standing alone.


10

These Guidelines do not describe each model in itself as this is an organisational decision to be taken by the RFC MB. However, the Guidelines describe a general model for the Corridor OSS as support for their decision.

5.2 Availability of the C-OSS It is mandatory for all Applicants to use PCS when requesting PaPs or RC. This requires a decision of the RFC MB. Other questions can be submitted via e-mail or telephone and will be answered accordingly. The C-OSS should be available to meet all corridor specified processes. Availability is subject to MB decision.

5.3 Customer Confidentiality The Corridor OSS is carrying out its assigned working task on behalf of the Management Board consisting of the IMs cooperating in a RFC. The task shall be carried out in a non-discriminatory way and under customer confidentiality keeping in mind that the applicants are competing in many cases for the same capacity and transports. The functionality of the Corridor OSS is based on trust between all involved stakeholders.

5.4 Tools for the Corridor OSS The main working tools for the Corridor OSS are the RNE IT tools: » Path Coordination System PCS, » Train Information System TIS, » Charging Information System CIS and » Customer Information Platform CIP. In order to enjoy the full benefits of these tools, it is in the interest of all involved stakeholders that their national systems are connected to them. The use of these tools is not only related to day-to-day business, but also to additional functions such as reports. As regards the display of information, a web-based information tool is needed to complete the tool kit for the Corridor OSS.

6 Pre-arranged paths (PaPs) and Reserve Capacity (RC) The basic requirements regarding PaPs and RC are laid down in Article 14 of Regulation 913/2010. But PaPs and RC also pursue a wide range of internal and external oriented aims. Internal aims (IM/corridor oriented)

» Ensure best use of the available capacity, especially on sections with bottlenecks, with help of standardization

» Ensure market-oriented dedication of capacity » Contribute to the efficient construction of harmonized international paths and to the provision of

international path offers » Involvement of terminals at handover points » Ensure more efficient handling of international path requests » Provide reserve capacity for the ad-hoc traffic


11

External aims (customer oriented)

» Display the capacity offered to the freight customers in a transparent way » Ensure fast response times to path requests for ad-hoc traffic » Enable customers to place PaP requests including feeder/outflow paths (e.g. to/from terminals)

in a single step » Provide integrated international path offers

7 Legal status of dedicated capacity The Corridor OSS shall display infrastructure capacity available at the time of request (Article 13 (2) of Regulation 913/2010). During the planning phase of the annual timetable, it is essential that the displayed dedicated capacity is protected in the IMs planning system/tool against major changes (dislocation, shifting, etc.) due to other path requests during the allocation phase performed by the Corridor OSS.

In particular this concerns unilateral changes of border crossing times after publication in the path catalogue at X-11. The published hand-over times have to be guaranteed; they should only be allowed to be modified at a later stage in exceptional cases and with agreement of all IMs concerned.

The Corridor Executive Board shall define the framework for the allocation of the infrastructure capacity on the freight corridor in accordance with Article 39 (1) of Directive 2012/34.

The Corridor Management Board – together with the relevant IMs and ABs – shall promote the coordination of priority rules relating to capacity allocation on the freight corridor. The outcome of this coordination task should be a list of criteria that enables a C-OSS to allocate paths in case of conflicts between requests for the same PaP.


12

8 Management of requests for PaPs/RC This Chapter describes the process concerning management of requests for Pre-arranged paths and for the Reserve capacity as defined within the PaP Product Definition. The process is split in three different, but still to a certain degree interconnected phases: » Phase 1 - Annual path requests; » Phase 2 - Late path request; » Phase 3 - Ad hoc path request. A graphical overview of the whole process in form of a process map displaying the split of the process into individual phases, the interconnection between these phases and a detailed description of each phase is provided in the following Chapter 9 “PaP Product Definition – Process Maps”.

8.1 Joint principles for management of PaPs/RC request The C-OSS shall be involved in all phases of the PaP/RC request and allocation process, starting with the preparation of the PaP/RC offer and ending with evaluating the previous timetable phase.

Based on RFC MB decisions and on the RNE Guidelines for Punctuality Targets, the Corridor OSS could provide the input for evaluating the Corridor’s performance regarding the use of PaPs and their allocation. This may serve as an input for the revision of the PaP offer for the next annual timetable. This can also serve as an input for the report to be published in accordance with Article19 (2) of Regulation 913/2010. Each international PaP should be identified by a unique code, i.e. by a PaP ID. This code should be created at the initiation of the PaP planning. This code should contain information about the rail freight corridor, the travelling direction and, if applicable, about specific sections of the path. It is recommended to ensure that the PaPs requested, offered and allocated can be traced by their ID in national IT systems of the IMs for the complete timetabling period, including the period after allocation. In case of routes being part of more than one RFC (“overlapping corridor sections”) there should be a general agreement by the involved RFCs regarding responsibilities and planning principles for PaP/RC. It has to be ensured that identical timelines and milestones will be applied. The Corridor Management Boards will have to take a decision how to distribute available capacity to cover the needs of the involved RFCs in the overlapping section(s). The possibility of defining Network PaPs should be taken into consideration. Before the publication of RC the situation should be analysed again, on the basis of the available remaining capacity.

Applications for PaPs/RC shall be placed to the Corridor OSS through PCS only. Neither national systems nor any other communication channels to the Corridor OSS will be allowed.

In case of conflicting requests the C-OSS takes the allocation decision for annual path requests according to the priority criteria described in Chapter 10 of these guidelines and the allocation decision for late- and ad hoc path requests according to the rule “first come – first served”. Late path requests will be allocated after the final offer at X-4. Ad-hoc path requests will be allocated as soon as possible by the C-OSS, starting from X-2.

8.2 Phase 1 - Annual path request

Process step / Milestone

Content and responsibility Result Time

PaP preparation The C-OSS in consultation with the IMs define the basic market requirements taking into account the inputs from the market:

- Recommendation on quantities - Recommendation on quality requirements

o Level of border harmonization o Level of required flexibility

IMs have to analyse the available capacity for PaPs as input for the C-OSS taking into account the capacity needs of other types of rail transport. An IM with agreed framework agreements should take the requirements of these agreements into consideration when planning and publishing the PaPs.The RFC MBs finally agree to the recommendations and promote these on IM level.

- Possibility to do corrections (quality and quantity) has to be provided

Principles for PaP Catalogue

X-19 – X-16

PaP catalogue creation The complete PaP catalogue has to be created : - C-OSS coordinate PaP elaboration of the IMs:

o If necessary coordination with other C-OSSs has to be ensured;

o Detail level up to the market requirements; o Bandwidths containing only “reference PaPs” (i.e.

empty PaPs to represent the available amount of PaPs) is possible;

o Complete catalogue has to be harmonized at the border according to the agreed level of border harmonization based on market requirements.

The C-OSS may stay in active communication with the market. The RFC Managing Boards have to agree with the catalogue:

- Possibility to do corrections and additions based on MB feedback has to be provided;

PaP catalogue X-16 – X-11


14

- TCRs have to be taken into consideration to the maximum possible extent (as described in the TCR guidelines). The PaPs cannot be changed until PaP request (Note: Necessary reduction of operation days have to be considered in the offered paths as tailor made paths).

The IMs are providing the PaPs to the C-OSS in the agreed format at X-12. The C-OSS are compiling the files and connect PaPs. The catalogue has to be published via PCS by the C-OSS. The Applicant should be made aware that corrections might occur until the end of January. It is up to each corridor organisation to create any other additional mode of publication and display (e.g. XLS file). This might cover the period from X-11 (PaP publication) until X-8 months (2nd Monday in April; path request deadline), as the allocation of the PaPs starts after the path request deadline.

PaP publication X-11

Corrections of errors The C-OSS in cooperation with IMs inspects the PaP catalogue and performs all corrections detected by any of the involved parties. At this phase the catalogue is read-only for Applicants, who may also provide inputs to the C-OSS for the correction of errors.

Corrected complete PaP catalogue

X-11 – X-10.5

Corrected PaP publication

X-10.5

PaP request phase Leading Applicants create their requests: - Selection of PaP - Selection of running days - Optional adaption of PaPs (including dwell times)

o Applicants have to respect the bandwidths as defined in the PaP catalogue.

Not to be exceeded / to be reached (leads to tailor-made): Bandwidth times, maximum train length / minimum speed

Complete path request X-10.5 – X-8


15

Possible to exceed (to be checked in elaboration phase by the IM): Train load, reference loco, number of stops / maximum stopping time.

- Mandatory definition of reference points - Feeder/Outflow - Selection of cooperating Applicants per section

The PaP request is being harmonized with all involved Applicants

- If requested the C-OSS can support the RUs creating the dossiers to prevent inconsistencies and guide the RUs’ expectations (until X-8.5, maximum 1 week prior to the request deadline) (remark: it should be promoted to have trainings in time before the request)

- The IMs may support the applicants by providing technical check of the requests

All involved RU agree to the terms and conditions* All involved RUs agree to the request* The leading RU submits the request During this phase the C-OSS keeps a register of all requests and updates it accordingly throughout the next phases. *Mandatory action > otherwise no request can be issued

Path request X-8

Pre-booking The requests are being collected by the C-OSS: - If necessary coordination with other C-OSSs has to be

ensured; - A plausibility check is being done: If there are plausibility

flaws the C-OSS may check with the Applicant whether the lacking plausibility can be solved.

Consistent path requests including pre-

booking

X-8 – X-7.5


16

o If it can be solved the request will be corrected by the C-OSS and processed like all other requests

o If it can’t be solved the requests will be rejected - In case of multiple requests within one bandwidth:

o If there are as many requests as paths within the bandwidth, the C-OSS will cover each request by one of those available paths

o If there are more requests than available paths, the C-OSS

in a first step covers the number of requests equal to the number of available paths with a PaP offer. The priority rules for PaP allocation have to be applied.

In a second step offers alternatives or tailor-made solutions for the remaining requests.

o Requests with a higher priority value are being pre-booked*

o Requests with lower priority value will be dealt with an alternative PaP or directly with a tailor made solution.** In case of an alternative PaP:

The Applicant agrees to the alternative PaP: The PaP is being pre-booked*

The Applicant refuses the alternative PaP or does not give an answer in time: The requests will be dealt with as tailor made

- The C-OSS checks if all requests are covered with a consistent answer.

- The C-OSS forwards all requests (PaPs and tailor made requests) to the IMs for path elaboration.

*) Pre-booking is the guarantee to receive capacity within the given parameters. It does not guarantee that requested detailed requirements can be met in the offer.


17

**) The tailor-made solution for PaP requests, that could not have been allocated by the C-OSS are to be treated by the IMs, as request submitted on time.

Requests forwarded to IMs

X-7.5

Path elaboration The IMs create the path offer: - Flexible parts are being created - Tailor made parts are being created - If necessary: Tailor made solutions are being created for

pre-booked PaP sections not available anymore due to external influences, especially TCRs*

- In all cases the borders have to be harmonized. In case, IMs cannot create draft offer due to specific wishes of the applicant not being feasible, IMs can provide individual national solutions for the concerned path sections via the C-OSS. If in this situation no national solution can be provided, the C-OSS has to reject the request. The C-OSS are being informed about the progress, especially about parts of the requests that cannot be fulfilled, about conflicts and about problems in harmonizing the path offers. The IMs can mark areas in which the flexibility will be available even after the final offer (in case the IMs create the actual timetable only shortly before operations) as “Flexible after allocation”. If this flexibility should be applied in cross-border sections an agreement (containing bandwidths and process) by all involved IMs is necessary. The C-OSS involve themselves in the elaboration as observers and should be involved in IMs’ meetings dedicated to harmonized border times. The C-OSS performs all tasks as the leading IM (especially promotion to Draft Offer).

Path offer by IMs X-7.5 – X-5


18

*) If IMs are forced to reconsider PaPs due to TCRs the principle of “guaranteed capacity” is to be kept. Therefore, all requests based on pre-booked PaPs have to receive an offer. The C-OSS has to be informed about reduced operation days of PaPs.

Draft offer X-5

Observations The Applicants can place their observations. The C-OSS provides a checklist and assistance to support the Applicants with their observations. The applicants forward their observations to the IMs for further processing.

Observations to draft offer

X-5 - X-4

Post-processing Based on the observations the IMs have the possibility to correct the offers. The updated offer is being provided to the C-OSS which – after a consistency check – submit the final offer to the Applicants.

Final offer X-4 – X-3.5

Final offer X-3.5

Acceptance The Applicants have to answer* to the final offer within 5 calendar days:

- Acceptance > leads to allocation - Rejection > leads to withdrawal of the request - No answer > The C-OSS is actively trying to get an answer

as mentioned above. In case there is still no answer from the Applicants the C-OSS ends the process (no allocation).

*) If not all Applicants agree to the Final Offer the request will be considered as unanswered.

Allocation X-3.5 – X-3

Allocation X-3

Final construction Depending on the defined flexibility in the “Flexible Allocation” either the Applicant or the IM triggers the final construction. The flexible parts can be changed according to Applicant’s and IM’s requirements.

Final construction As defined in the “Flexible Allocation”

Actual timetable As defined in the “Flexible Allocation”


19

8.3 Phase 2 - Late path request



PaP catalogue creation (for late

requests)

The complete PaP catalogue for late requests can be created*: - The basic catalogue is based on the residual PaPs of the

annual request. The IMs and C-OSS have to agree on the amount of residual capacity available for late requests. Market requirements should generally be already reflected in the PaP offer.

- In case new PaPs are being offered the C-OSS coordinate PaP development

- Bandwidths containing only “reference PaPs” (i.e. empty PaPs to represent the available amount of PaPs) is possible.

The RFC Managing Boards have to agree with the catalogue

- Possibility to do corrections and additions based on MB feedback has to be provided

- A possibility to update the catalogue has to be provided. The catalogue has to be published via PCS.

PaP catalogue for late requests

X-7.5 – X-7

PaP publication for late requests

X-7

PaP request phase Leading Applicants create their requests: - Selection of PaP - Selection of running days - Optional adaption of PaPs (including dwell times)

o Applicants have to respect the bandwidths as defined in the PaP catalogue

- Mandatory definition of reference points - Feeder/Outflow - Selection of cooperating Applicants per section

The PaP request is being harmonized with all involved Applicants

Complete late path request

X-7 – X-3


20

- If requested the C-OSS can support the RUs creating the dossiers to prevent inconsistencies and guide the RUs’ expectations


All involved RU agree to the terms and conditions* All involved RUs agree to the request* The leading RU submits the request *) Mandatory action > otherwise no request can be issued

Late request Any time between X-

7 and X-3

Pre-booking The requests are being received by the C-OSS: - A plausibility check is being done: If there are plausibility



o If it can’t be solved the requests will be rejected - The C-OSS checks if all requests are covered by

consistent answers. - The PaP requests are being pre-booked* - The C-OSS forwards all requests (PaPs and tailor made

requests) to the IMs for path elaboration. *) Pre-booking is the guarantee to receive capacity within the given parameters. It does not guarantee that requested detailed requirements can be met in the offer.


booking

X-7 – X-2


Any time after request (first come

first served) between X-7 and X-2


21

Path elaboration The IMs create the path offer: - Flexible parts are being created - Tailor made parts are being created - In both cases the borders have to be harmonized.

In case, IMs cannot create draft offer due to specific wishes of the applicant not being feasible, IMs can provide individual national solutions for the concerned path sections via the C-OSS. If in this situation no national solution can be provided, the C-OSS has to reject the request. The IMs can mark areas in which the flexibility will be available even after the final offer (in case the IMs create the actual timetable only shortly before operations) as “Flexible after allocation” The C-OSS involve themselves in the elaboration as observers and should be involved in IMs’ meetings dedicated to harmonized border times. The C-OSS performs all tasks as the leading IM (especially promotion to Draft Offer).

Path offer by IMs X-3.5 – X-2

Draft offer Any time after request (first come

first served) between X-3.5 and X-2



X-3.5 – X-1.5

Post-processing Based on the observations the IMs have the possibility to correct the offers. The updated offer is being provided to the C-OSS which – after a consistency check – submit the final offer to the Applicants.

Final offer X-3.5 – X-1


22

Final offer Any time after request (first come

first served) between X-3.5 and X-1

Acceptance The Applicants have to answer to the final offer within 5 calendar days:




Allocation within 5 calendar days after final offer

Allocation 5 days after final offer between





23

8.4 Phase 3 - Ad hoc path request



PaP catalogue creation (for ad hoc requests)

The complete PaP catalogue for ad hoc requests has to be created:

- Baseline are the non pre-booked PaPs in Annual TT as well as in Late Path request

- In case new PaPs are being offered the C-OSS coordinates PaP elaboration

- IMs create PaPs for ad hoc requests under C-OSS

coordination o Detail level up to the market requirements; o Bandwidths containing only “reference PaPs” (i.e.

empty PaPs to represent the available amount of PaPs) is possible;

o Complete catalogue has to be harmonized at the border according to market requirements.

The RFC Managing Boards have to agree with the catalogue:

- Time limit by which the PaPs for ad hoc requests have to be locked in national working timetables of maximum 30 days have to be defined;

- Possibility to do corrections and additions based on MB feedback has to be provided;

- A possibility to update the catalogue has to be provided. The path catalogue has to be published in PCS at x-2 and preferably made available also on RFC’s website and updated regularly. If it is displayed in national systems as well, the competent IM has to ensure consistency with PCS. Any modification of the reserve capacity by IMs have to be consulted and agreed with the relevant C-OSS(s). However, if an

PaP catalogue for ad hoc requests

X-4 - X-2


24

IM discovers that an already published – but not requested – PaP is affected by a restriction in case of force majeure, including urgent and unforeseeable safety-critical work , the relevant paths has to be withdrawn for the appropriate time period. Even in such case, the withdrawal has to be communicated to the relevant C-OSS(s).

PaP publication for ad hoc requests

X-2

PaP request phase Leading RU/Applicants create their requests: - Selection of PaP - Selection of running days - Optional adaption of PaPs (including dwell times)

o Applicants have to respect the bandwidths as defined in the PaP catalogue

- Mandatory definition of reference points - Feeder/Outflow** - Selection of cooperating applicants per section

The PaP request is being harmonized with all involved RUs/Applicants

- If requested the C-OSS can support the RUs creating the dossiers to prevent inconsistencies and guide the RUs’ expectations


All involved RU agree to the terms and conditions* All involved RUs agree to the request* The leading RU submits the request *) Mandatory action > otherwise no request can be issued **) In case of applications including feeder/outflow paths the C-OSS will forward the request to the competent IMs and ensure a

Complete ad hoc path request

X-2 – X+11


25

consistent path construction between the feeder/outflow and the corridor-related path section.

Ad hoc request X-2 – X+11

Pre-booking The requests are being received by the C-OSS: - A plausibility check is being done: If there are plausibility



o If it can’t be solved the requests will be rejected - The C-OSS checks if all requests are covered by consistent

answers. - The PaP requests are being pre-booked* - The C-OSS forwards all requests (PaPs and tailor made

requests) to the IMs for path elaboration. The applicants shall receive a first response to their requests from the C-OSS within five calendar days of receiving the path request. Applicants will be informed about the result of the pre-booking through PCS. *) Pre-booking is the guarantee to receive capacity within the given parameters. It does not guarantee that requested detailed requirements can be met in the offer.


booking

First come, first served


Any time after request (first come first

served)

Path elaboration The IMs create the path offer: - Flexible parts are being created - Tailor made parts are being created - In both cases the borders have to be harmonized

In case, IMs cannot create draft offer due to specific wishes of the applicant not being feasible, IMs can provide individual national solutions for the concerned path sections via the C-OSS. If in this

Path offer by IMs


26

situation no national solution can be provided, the C-OSS has to reject the request The IMs can mark areas in which the flexibility will be available even after the final offer (in case the IMs create the actual timetable only shortly before operations) as “Flexible after allocation” The C-OSS involve themselves in the elaboration as observers and should be involved in IMs’ meetings dedicated to harmonized border times. The C-OSS performs all tasks as the leading IM (especially promotion to Draft Offer).

Draft offer



Post-processing Based on the observations the IMs have the possibility to correct the offers. The updated offer is being provided to the C-OSS which – after a consistency check – submit the final offer to the Applicants. Applicants shall receive the final offer not later than 10 calendar days before train run.

Final offer

Final offer

Acceptance The Applicants have to answer* to the final offer within 5 calendar days:




Allocation

Allocation


27




9 PaP Product Definition – Process Maps

9.1 Phase 1 - Annual path request


29


30


31


32

9.2 Phase 2 - Late path request


33


34


35

9.3 Phase 3 - Ad hoc path request


36


37


38

10 Priority criteria for the allocation of pre-arranged paths

10.1 Need for priority determination In the path request phase of the annual timetabling process it is very likely that several applicants request the same PaP or PaP sections published by the RFCs at X-11. One of the main tasks of the C-OSS is to identify multiple requests for the same PaPs or PaP sections and to solve the conflicts. The aim of the conflict solving process is to allocate the requested PaPs to one applicant and to offer alternative solutions to the other applicants. Alternative solutions may be either an alternative PaP (if available) or a tailor-made path to be constructed and provided by the IMs.

10.2 Consultation in case of conflicts In case of conflicts, conflict solving may be done in the first step by consultation, if the following criteria are met: ■ Only one RFC involved (conflict is on a single RFC) ■ Suitable alternative PaPs are available The C-OSS addresses the applicants and proposes a solution. If the applicants agree to the proposed solution, the coordination process ends. If for whatever reason the coordination process does not lead to an agreement by all parties at X-7.5 the priority rules described in these guidelines will be applied. In case of conflicts which do not meet the criteria listed above, the C-OSS will apply the priority rules and the process described in these guidelines. Experiences of the conflict solving process should be evaluated and taken into consideration for the PaP planning process of following timetable periods. Changing the PaP offer according to the experiences may reduce the number of conflicts in following years.

10.3 Priority determination by distance and days of operations One way for calculating a value for comparison of several requests for the same PaP or PaP sections is based on the total length of all requested PaP sections included in one request (on a single corridor or on connected corridors) multiplied by the number of requested days of operations. This calculation results in a “priority value” for each conflicting request. In case a conflict cannot be solved by consultation, the PaP shall be allocated to the applicant whose request has the highest priority value. The formula for calculating the priority value and examples are provided in chapter 13 (Annex 2) of these guidelines.

10.4 Additional element for priority determination: Network PaP In some corridor sections, capacity may be scarce and the method for priority determination described in section 9.3 could lead to PaP sections remaining unused and thus capacity being wasted. For better matching specific traffic demands (e.g. in specific geographical relations or of market segments with special requirements in train path characteristics) and best use of available capacity


39

– especially for capacity requests involving more than one RFC – the corridors may designate a certain number of the published PaPs as Network PaPs.

10.4.1 Definition of Network PaP Network PaPs (in short NetPaPs) are PaPs designated to foster the optimal use of infrastructure capacity by applying a specific formula for calculating their priority values in case of conflicts provided in chapter 13.3 (Annex 2) of these guidelines. Network PaPs consist of contiguous PaP sections linked together and are identified by a special ID or marker in PaP catalogues and IT tools. They may be offered on a single RFC or on two or more connected RFCs.

10.4.2 Criteria for Network PaP designation Origin and destination of Network PaPs and the number of Network PaPs offered should take into account the following as appropriate:

■ Results of Transport Market Studies;

■ Experiences regarding the scarcity of capacity on the Rail Freight Corridors and IMs/ABs from previous years (e.g. number of requests, number of requests involving more than one RFC);

■ Customer feedback concerning previous years (e.g. received from RAG);

■ Customer expectations and forecast (e.g. received from RAG).

“Standard” PaPs (i.e. PaPs which are no Network PaPs) and Network PaPs are very similar and managed in the same way whenever possible. Differences are summarised in the following table:

Pre-arranged Path (PaP) subject to the Standard priority rule

(Standard PaP)

Pre-arranged Path (PaP) subject to the Network priority rule

(Network PaP)

The PaPs are defined by the IMs/ABs of one corridor and the offer is provided by the C-OSS

The offer may involve more than one corridor. In that case, the Network PaPs are defined by the IMs/ABs of all involved corridors and the offer is provided by the C-OSSs of the relevant corridors.

One or more sections on one corridor Connecting sections on one corridor or on more than one corridor

Relations are mentioned in CID book 4 Relations and share of Network PaPs in relation to normal PaPs are mentioned in CID book 4

Priority calculation when only Standard PaPs are part of the conflict:

(LPAP+LF/O) x YRD = K

Priority calculation when a Network PaP is part of the conflict:

(LNetPAP+LotherPaP +LF/O )x YRD = K


40

10.4.3 Network PaP designation process

■ Network PaPs shall be designated in a transparent and non-discriminatory manner. This is being achieved by complying with the criteria set out under point 9.4.2.

■ RFCs seeing the need for Network PaPs create a list of Network PaP origins and destinations and an indicative share of all PaPs for each timetable period.

■ Arguments for Network PaP designation, RFC sections to be covered by Network PaPs and an indicative share of Network PaPs in regards of all PaPs offered on the RFC shall be published in Book 4 of the CID.

■ Connected RFCs must cooperate in the designation process of Network PaPs. If one of the connected RFCs sees the need for cross-corridor Network PaPs, the involved RFC(s) shall meet the request as far as reasonable and possible. A Network PaP can only be designated if all involved RFCs agree. In case of no agreement, the Executive Boards of the involved RFCs shall be informed and should try to find a common solution.

■ Network PaP construction shall follow the same rules as the ”Standard” PaPs procedures and priorities.

■ Taking comments of the Executive Boards and RBs (if applicable) into consideration, the Network PaPs will be finalised.

■ All PaPs have to be published at X-11.

10.4.4 Conflict Management (between X-8 and X-7.5) If no Network PaP is involved in the conflicting requests, the rule according to chapter 9.3 will be applied. See examples 1 and 2 in chapter 13 (Annex 2). If a Network PaP is involved in the conflict, the applicable priority rule is described in chapter 13.3 (Annex 2). ■ If the conflict is on a Network PaP, priority should be given to the request that maximises length

of the request on this Network PaP, times number of requested operation days. See examples 3 and 4 of chapter 13 (Annex 2).

■ In case of a tie, the total length of all PaP sections requested on all RFCs, times number of requested operation days has to be applied. See example 5 of chapter 13 (Annex 2).

■ If the conflict is not on a Network PaP, priority should be given to the request based on the total

length requested on all RFCs, times the number of requested operation days. See example 6 of chapter 13 (Annex 2).


41

11 Calculating the priority value

11.1 Formula for priority calculation if no Network PaP is involved In a first step the priority value (K) is calculated using only the total requested length of the PaP (LPAP) multiplied by the Number of requested running days (YRD)

K = LPAP

x YRD

LPAP

= Total requested length (in kilometres) of all PaP sections on all involved

RFCs included in one request

YRD

= Number of requested running days for the timetable period; only running

days referring to a date with a published PaP offer for the concerned section will be taken into account.

K = Priority value If the requests cannot be separated in this way, the priority value (K) is calculated using the total requested length of the complete paths (LPAP + LF/O) multiplied by the Number of requested running days (YRD) in order to separate the requests

K = (LPAP

+ LF/O

) x YRD

LPAP

= Total requested length (in kilometres) of PaP sections on all involved RFCs

included in one request

LF/O

= Total requested length of the feeder/outflow path(s); for the sake of

practicality, is assumed to be the distance as the crow flies.

YRD


days referring to a date with a published PaP offer for the concerned section will be taken into account.

K = Priority value If the requests cannot be separated in this way, a random selection is used to separate the requests. This random selection shall be defined in the Corridor Information Document.


42

11.2 Examples for priority calculation if no Network PaP is involved

11.2.1 Example 1: Requests for the same PaP sections on a single corridor

Calculation of priority value: K = LPAP

x YRD

Request 1: K = (200 km + 300 km) x 75 (days) = 500 x 75 = 37,500 Request 2: K = (400 km + 200 km) x 75 (days) = 600 x 75 = 45,000

Result: ■ Request 2 has higher priority value; the PaP could be allocated to this applicant. ■ Request 1 will be offered an alternative (alternative PaP or tailor-made offer).


43

11.2.2 Example 2: Requests for the same PaP sections on connected corridors


x YRD

Request 1: K = (400 km + 200 km) x 99 (days) = 600 x 99 = 59,400 Request 2: K = (500 km + 200 km) x 99 (days) = 700 x 99 = 69,300



44

11.3 Formula for priority calculation if Network PaPs are involved In a first step the priority value (K) is calculated using only the total requested length of the Network PaP (LNetPAP) multiplied by the Number of requested running days (YRD)

K = LNetPAP x YRD

LNetPAP

= Total requested length (in kilometres) of the PaP defined as Network PaP

on either RFC included in one request

YRD


days referring to a date with a published PaP offer for the concerned section will be taken into account

K = Priority value If the requests cannot be separated in this way, the priority value (K) is calculated using the total length of all requested Network PaP sections and other PaP sections (LNetPAP + LOther PAP) multiplied by the Number of requested running days (YRD) in order to separate the requests

K = (LNetPAP + LOther PAP ) x YRD

LNetPAP



LOther PAP

= Total requested length (in kilometres) of the PaP (not defined as Network

PaP) on either RFC included in one request

YRD



K = Priority value If the requests cannot be separated in this way, the priority value (K) is calculated using the total length of the complete paths (LNetPAP + LOther PAP + LF/O) multiplied by the Number of requested running days (YRD) in order to separate the requests

K = (LNetPAP + LOther PAP + LF/O ) x YRD

LNetPAP



LOther PAP

= Total requested length (in kilometres) of the PaP (not defined as Network

PaP) on either RFC included in one request

LF/O

= Total requested length of the feeder/outflow path(s); for the sake of

practicality, is assumed to be the distance as the crow flies

YRD



K = Priority value


45

If the requests cannot be separated in this way, a random selection is used to separate the requests. This random selection shall be defined in the Corridor Information Document.

11.4 Priority determination including Network PaPs

11.4.1 Example 3: Conflict is on Network PaP – same number of days

Calculation of priority value: K = LNetPAP x YRD Request 1: K = 200 km requested on blue NetPaP x 100 (days) = 20,000 Request 2: K = (500 km + 200 km requested on blue NetPaP) x 100 (days) = 70,000



46

11.4.2 Example 4: Conflict is on Network PaP – different number of days




47

11.4.3 Example 5: Conflict is on Network PaP – 1st step result is a tie

1st step calculation of priority value: K = LNetPAP x YRD Request 1: K = 200 km requested on blue NetPaP x 350 (days) = 70,000 Request 2: K = (500 km + 200 km requested on blue NetPaP) x 100 (days) = 70,000

1st step result: ■ Tie - both requests have the same priority value of 70,000

2nd step calculation of priority value: K = (LNetPAP + LOther PAP ) x YRD Request 1: K = (400 + 200 + 100 km total length requested) x 350 (days) = 315,000 Request 2: K = (500 + 200 km total length requested) x 100 (days) = 70,000

2nd step result: ■ Request 1 has higher priority value; the PaP is allocated to this applicant. ■ Request 2 will be offered an alternative (alternative PaP or tailor-made offer) if possible.

Otherwise, request 2 does not receive an offer.


48

11.4.4 Example 6: Conflict is on Network PaP – 1st and 2nd step results are a tie

1st step calculation of priority value: K = LNetPAP x YRD Request 1: K = (500 km + 200 km requested on blue NetPaP) x 100 (days) = 70,000 Request 2: K = (500 km + 200 km requested on blue NetPaP) x 100 (days) = 70,000

1st step result: ■ Tie - both requests have the same priority value of 70,000

2nd step calculation of priority value: K = (LNetPAP + LOther PAP ) x YRD In this example no additional PaPs are requested. The K value is the same as in the 1st step.

2nd step result: ■ Tie - both requests have the same priority value of 70,000

3rd step calculation of priority value: K = (LNetPAP + LOther PAP + LF/O ) x YRD Request 1: K = (500 km + 200 km NetPaP + 150 km Feeder+ 100 km Outflow) x 100 (days) = 95,000 Request 2: K = (500 km + 200 km NetPaP + 100 km Feeder+ 200 km Outflow) x 100 (days) = 100,000

■ Request 2 has higher priority value; the PaP is allocated to this applicant. ■ Request 1 will be offered an alternative (alternative PaP or tailor-made offer) if possible.



49

11.4.5 Example 7: Conflict is not on Network PaP – same number of days


x YRD

Request 1: K = (400 km + 200 km + 300 km) x 150 (days) = 900 x 150 = 135,000 Request 2: K = (500 km + 200 km + 300 km) x 150 (days) = 1,000 x 150 = 150,000

Result: ■ Request 2 has higher priority value; the PaP could be allocated to this applicant. ■ Request 1 will be offered an alternative at least for corridor section C-D (alternative PaP or

tailor-made offer) if possible. Otherwise, request 1 does not receive an offer.


50

11.4.6 Example 8: Conflict is not on Network PaP – different number of days

Although a Network PaP is involved the Net PaP is no part of the conflict.


x YRD

Request 1: K = (400 km + 200 km + 300 km) x 200 (days) = 900 x 200 = 180,000 Request 2: K = (500 km + 200 km + 300 km) x 150 (days) = 1,000 x 150 = 150,000

Result: ■ Request 1 has higher priority value; the PaP is allocated to this applicant. ■ Request 2 will be offered an alternative at least for corridor section C-D (alternative PaP or

tailor-made offer) if possible. Otherwise, request 2 does not receive an offer.


51

11.4.7 Example 9: Conflict is on Network PaP – variant

This variant has no effect on priority determination. The conflict is again on the “Network PaP” section between B and C.


Result: ■ Request 2 has higher priority value; the PaP is allocated to this applicant. ■ Request 1 will be offered an alternative (alternative PaP or tailor-made offer) if possible.



52

12 Requirements for PCS

The C-OSS define the required functionality by PCS necessary to fulfil all defined tasks within the given timeframe (e.g. priority calculation, PaP conflict overview). Detailed functional and technical specifications are being defined in corporation between the C-OSS and RNE with inputs by other concerned stakeholders (IMs, RUs). In case developments have impact on several C-OSS and/or IMs the concerned community has to come to an agreement on how to process these developments. To perform this task RNE has to create a request workflow and the PCS user community has to establish respective boards. Information on any development has to be transparent to all board members. » The goal of all PCS developments concerning C-OSS is to provide the best possible overview

to C-OSS and other users and to provide with all functions required in the most useful manner possible. The Applicants have to be offered a user friendly function to search for PaPs and process their requests.

» PCS must be able to handle the creation, upload, publication, request, pre-allocation and allocation of PaPs in all phases as described in the guidelines. All participating users have to be able to fulfil their tasks (C-OSS, IMs, RUs, Authorised Applicants). These tasks and all communication procedures are defined in respective guidelines.

» PCS needs to prevent the process from being stuck due to non-compliance of Applicants (e.g. unanswered offers). The required processes need to be defined.

» RNE keeps a register of the status of the Applicants. » PCS has to ensure that requests and offers are directed to the correct user (C-OSS, IM, RU,

Applicant). It is the C-OSS’ responsibility to ensure that the data PCS requires to perform this task are correct and no redundancies in the pre-constructed capacity products are being made. Therefore, there can be only one allocation body responsible for a pre-constructed capacity product (IM, AB or C-OSS). In case it is required to have changes of responsibilities respective processes have to be defined and agreed on by the concerned stakeholders.

» The access and editing rights will be defined based on the definitions in the respective guidelines.

» The C-OSS together with the IMs define the technical framework of PaPs (extend of possibilities to edit PaPs in each phase). The C-OSS have to harmonise these requirements with the concerned IMs and with other C-OSS to reduce the variety of approaches to a minimum.

It must be secured that the history of PCS can serve as a part of the register regarding allocation history.

Guidelines for C-OSS concerning PaP and RC Management ... · PDF fileGuidelines for C-OSS...

Documents

Transcript of Guidelines for C-OSS concerning PaP and RC Management ... · PDF fileGuidelines for C-OSS...