Table of contents

1. Introduction
2. Type of timetables
3. Description of the timetables
4. Access Control Rules (ACL)
5. Structure of the timetables
6. Timetable segment views
7. Field descriptions
8. Description of tailor-made and feeder/outflow points

1. Introduction

In PCS generally, each user needs to work on the respective timetable during the phases of the path request based on their roles so Applicants work on the Applicant timetable, IMs/ABs work on the IM timetable and C-OSS managers work on the C-OSS timetable. If the draft offer is sent the IM timetable will be the prominent and the “main” timetable. Applicants will have only reading rights on the IM timetable except in the special phases e.g.: a feasibility study or the path modification process.

2. Type of timetables

A dossier can contain the following timetables:

• Applicant timetable
• IM timetable
• C-OSS timetable
• Feasibility timetable

Each dossier contains at least two timetables: an Applicant and an IM timetable. But if the dossier has a PaP or PaPs added then the RFC acts on behalf of the IM and his/her response will be sent in the C-OSS timetable. For passenger traffic applicants the feasibility timetable stores the IMs’ response.

3. Description of the timetables:

• Applicant timetable: the applicant timetable represents the Applicant’s path request
• IM timetable: the IM timetable represents the Applicant request’s response from the IMs
• C-OSS timetable: the C-OSS timetable represents the response and decision for the Applicant’s path request in pre-booking
• Feasibility timetable: for passenger traffic users represents the IM’s response in the feasibility study process

4. Access Control Rules (ACL)

Basic access control rules (phase-dependent):

• Applicants can only edit the requested timetable for their particular national section
• Similarly, the IMs can only edit the IM timetable for their national section
• C-OSS can only edit the path section that belongs to its PaP or can edit any feeder/outflow path sections
• Feasibility timetable: saved version of the IM timetable (read-only) as a result of the feasibility process

5. Structure of the timetables

The timetables have the same structure and contain common fields but they differ in some fields based on the user roles in the system (Applicant/IM/C-OSS/Feasibility).

Each timetable displays the territories with its operation points with their times. Also in each path section, the owner IM and the activity/location types are shown.

6. Timetable segment views

The dossier’s timetable segment consists of the following views:

• Territories: geographical presentation of the route and timetable divided into Applicant-IM – IM pairs. Timetables are shown in subpaths
• Calendar: it shows the running days and on the top shows the validity period of the entire timetable year. The system allows us to define the running days and offset for the entire timetable or specify specific months/days for a required journey to every path section in all subpaths. Users can select the entire year, a month, a circulation day or individually day by day in the calendar
• Path Variants: it gives a global view of our timetable data and presents the combination of all entered subpaths in the dossier. The route is shown from origin to destination across all territories. It also indicates path variant consistency

7. Field descriptions

The following fields are available for each inserted path section:

• Actual Arrival time: field for requested/offered time in the format “hh:mm”.The user can enter the time in “hhmm” format as well and the system adjusts it. This rule applies to all “Time” fields.
• Actual Departure time: field for requested/offered time in the format “hh:mm”. This is a mandatory field for the reference point.
• Include the earliest/latest times: this is an optional field and the system allows us to define the earliest and the latest times.
• Include public times: this is an optional field and the system allows us to define the public transport service times, to assist passengers with planning a trip.
• Service day for a reference point: it is an optional field and the system allows us to add common descriptions among subpaths that are combined.
• Dwell time: This field is for entering the minimum stop duration at the stop in decimal numbers. For further consistency rules and constraints of this field, please check the referenced documentation
• Offset/Time zone: Manual time offset defined in days assigned by the user to an arrival or departure time in a path section. The system allows defining the time zone value in each path section in hours format.
• Responsible Applicant: the responsible Applicant or unknown agency (this last one for study purposes only)  be default always the creator applicant but possible to change the Applicants corresponding to the neighbouring country.
• Responsible IM: system-generated field according to the selected operation point depending on where is that operation point geographically and by which IM has been registered in the system.
• Path section: select the operation point name by typing the name and PCS will propose the list of available locations registered in the system. 
• Star icon: indicates the reference point of the timetable. Always the first path section is the reference point of each subpath. 
• Gear icon: the indication of the construction starting point. It’s an optional indication that can be set by the Applicants to inform the IMs/ABs about the point, where they should start the construction of the paths. By default set the first path section as the Construction reference point of each sub-path that doesn’t have a Construction reference point assigned.
• Detail: This field could be used for a detailed description of the stop, e.g. platform or track specification.
• Train no.: Field for train number valid for the path from this path section (used as ITN – Infrastructure Train Number)
• Path no.: Field for path number valid for the path from this path section.
• Catalogue path no.: Field for catalogue path number valid for the path from this path section. It’s fulfilled automatically by PCS based on the selected PaP or catalogue path (if this number is published there)

8. Description of tailor-made and feeder/outflow points

Definition from CID for feeder/outflow and tailor-made paths:  In case available PaPs do not cover the entire requested path, the applicant may include a feeder and/or outflow path to the PaP section(s) in the international request addressed to the C-OSS via PCS in a single request.
A feeder/outflow path refers to any path section prior to reaching an Intermediate Point on a corridor (feeder path) or any path section after leaving a corridor at an Intermediate Point (outflow path). Feeder/outflow paths will be constructed on request in the PCS dossiers concerned by following the national path allocation rules. The offer is communicated to the applicant by the C-OSS within the same time frame available for the communication of the requested PaPs. Requesting a tailor-made path between two PaP sections is possible, but because of the difficulty for IMs/ABs to link two PaP sections, a suitable offer might be less likely. 

Graph with possible scenarios for feeder/outflow paths in connection with a request for one or more PaP section(s):