PCS Technical Board Vienna, 28th February 2017

Agenda 09:00 - 09:10 Welcome & Agenda 09:10 - 09:40 Review of the development plan until 2018 November 09:40 - 10:40 PaP Product definition impact analysis (Process and Product) 10:40 - 11:40 TAF-TSI Short Term Path Request Pilot (information, PCS developments, pilot participation, timeline, test cases) 11:40 - 12:15 Interface Map update (Who? When? What? In which phase? Which process? How fast?) - around the table about the current and planned implementations 12:15 - 13:00 Lunch 13:00 - 13:30 Path Alteration (proposal by RNE & SNCF-Reseau) 13:30 - 13:50 Short Term Path Request pilots of RFCs (information from RNE to the members) 13:50 - 14:30 Empty Envelope Concept and Single Border Point Approach status update 14:30 - 16:00 Change requests & Any Other Business 19 September 2018

Review of developments until November 2018

Development plan Minor 2017 Dates: End of development: 25th February Release Candidate: 2nd March Deploy in Production: 3rd April Content: Search for Observations: new column in the result only in Observations and Post-Processing PaP Availability Management Tool (PAMT): search and Excel report Conflict Solving Tool for RFCs UpdateDossierRUIMPair web-service operation adjustment: update based only on the referred pair, the rest stays untouched Trivials: Improved usability when adding a location in a TT (1196) Path number copied to subsidiary (1231) Used terminology in creating and managing PaP (1186) Always show Dossier ID on PCS GUI (1178) Edit calendar (1172) Mandatory Traction details – Default (1152) 19 September 2018

Development plan Major 2017 Dates: End of development: TBD Release Candidate: 2nd November (plan) Deploy in Production: 13th November Content: TAF-TSI Short Term Path Request Pilot (for August): Pre-accepted offer in Ad-Hoc Path Request process Acceptance phase adjustment (Accept/Refuse/Ask for adaptation) Format changes Test environment preparation (maintenance work) IP Consolidation package (Interface): Removal of PCS IP middle layer, connection directly to PCS Core Solving performance issues PaP Product definition 1st step: Pre-Booking phase for RFCs Acceptance indicator adjustments for RFCs (light separation, downgrade to blue) Loco types 19 September 2018

Development plan Minor 2018: Dates End of development: TBD Release Candidate: TBD Deploy in Production: TBD (beginning of April) Content: PaP Product definition 2nd step: C-OSS timetable Alternative offer Major 2018: Deploy in Production: TBD (mid of November) Empty Envelope Concept PaP Product definition 3rd step: New PaP product in place 19 September 2018

UpdateDossierRUIMPair

updateDossierRUIMPair In case when one IM agency is paired with multiple RU agencies there is a need to only send partial update based on the responsible RU agency indicated by the dossierRUIMPair that is sent as element of updateDossierRUIMPairRequest. With this partial update the other blocks of the path that will be absent in the request won’t be modified by PCS IP. This is different from the current behavior that presumes that all path sections that are missing in the request and are under the responsibility of the IM agency that is sending the request, will be deleted. To accommodate this case the following changes to the schema are made: In TrasseElement a new optional element <responsible_ru_agency_id> or <responsible_ru_agency_uic_id> is added, before <agency_id> or <agency_uic_id> element. It is the id of the RU agency responsible for the given path section. This field is not supported in the notification messages, only in getDossier operation. The request type for the getDossier operation, GetDossierRequest, has new optional boolean parameter pathsWithResponsibleRu. When set to true it indicates that <responsible_ru_agency_id> element should be included in all elements of type TrasseElement for the dossier in the response. The request type for the updateDossierRUIMPair operation, UpdateDossierRUIMPairRequest, has new optional boolean parameter updateImPathBasedOnResponsibleRU. By setting it to true you can indicate that the update of IM paths should be based on the responsible RU agency.  This will work only if responsible RU agency is set in all elements from type TrasseElement for the dossier in the request (element <responsible_ru_agency_id> or <responsible_ru_agency_uic_id>) This element is needed to ensure that the sent block (the one that needs to be updated) is resolved correctly on both sides, the client and PCS IP. All path sections that do not have the same responsible RU agency as the one from the RU-IM pair in the request won’t be touched. The intention is that in one of the next major versions the new elements <responsible_ru_agency_id> or <responsible_ru_agency_uic_id> in TrasseElement type will become non optional and additional non optional elements will be added <responsible_im_agency_id> or <responsible_im_agency_uic_id> for the responsible IM agency for each path section. 19 September 2018

Indication in the update procedure Example: 19 September 2018

Indication in the trasseelement Example: 19 September 2018

IP Consolidation

IP Consolidation package National Systems Web-Service Request PCS IP PCS Core Web-Service Request Response/Error Code Notification Service National Systems Web-Service Request PCS Core Response/Error Code Notification Service 19 September 2018

IP Consolidation package As PCS IP tries also to resolve ACL issues as PCS Core, it can happen that the result on the GUI and via IP is different. The aim of the development to remove this additional layer in front of PCS Core and PCS interface partners would send the web-service operations directly to PCS Core. Expected benefits: Decrease of performance issues Decrease of confusing error/response codes, for example: RC 100, when nothing happened in the Core RC 302 on IP, when the action is possible via the GUI Decrease of development time on the interface side Expected consequences: the IP addresses will be changed on RNE side 19 September 2018

PaP Product definition

PaP Product Definition Developments in 3 step Step (Major Release 2017) Pre-Booking phase: New dossierstatus_id Dossier is read-only for IMs/ABs Dedicated acceptance indicators to RFCs: no change for interface partners Special down and upgrades of RFCs in certain process steps (Pre-Booking → Path Elaboration): no change for interface partners Step (Minor Release 2018) C-OSS Timetable: tt_coss part between tt_evu and tt_km with the same structure. C-OSS timetable is edited by the C-OSS Manager. During phase promotion from Pre-Booking to Path Elaboration tt_coss will be copied by PCS to tt_km Alternative Offer: improvement the flexibility for the alternative offer. C-OSS can work in the tt_coss as an RU can work in the tt_evu Step (Major Release 2018) New PaP Product: product is not defined yet 19 September 2018

New PaP Product The complete PaP catalogue has to be created : C-OSS coordinate PaP elaboration of the IMs: If necessary coordination with other C-OSSs has to be ensured; Detail level up to the market requirements; Bandwidths containing only “reference PaPs” (i.e. empty PaPs to represent the available amount of PaPs) is possible; Complete catalogue has to be harmonized at the border according to the agreed level of border harmonization based on market requirements. What is missing for us (TB members, RNE and NCA PCS Team)? Who and when can edit the times on path sections? What are the levels of protection? Who and when can remove path section from the edge of the PaP? What are the levels of protection? Who and when can remove path section from the middle of the PaP? What are the levels of protection? Who and when can add new path section to the PaP? Can IM remove the added new path section (by RU) from the PaP? Definition of bandwidths, slots, conflict resolution rules 19 September 2018

TAF-TSI Short Term PR Pilot Időrend, paraméterek, sémaváltás, folyamatváltás, teszt környezet, teszt partnerek, demo, ábra a megvalósításra

TAF-TSI Short-term Path Request Pilot Use Cases: Path Request 1 RU – 1 IM Path Request 2 RUs – 2 IMs Path Alteration 1 RU – 1 IM Path Alteration 2 RUs – 2 IMs Path Modification 1 RU – 1 IM Path Modification 2 RUs – 2 IMs Path Cancellation 1 RU – 1 RU Path Cancellation 2 RUs – 2 IMs Let’s check the participants Timeline: From August 2017 From May 2018 From October 2018 19 September 2018

Test Environment Solution for the pilot: Test environment: RNE CCS CI Transition/Integration Layer PCS IP* PCS Core* National Systems CI CI TIL PCS IP PCS Core WS WS TSI msg 19 September 2018

Process and schema related changes Pre-accepted offer: new process type for pre-accepted offer (definition of pre-accepted offer see in JSG Handbook) Changes in Acceptance phase: If LRU accepts Draft Offer, dossier moves to Active Timetable If LRU rejects Draft Offer, dossier moves to Harmonization If LRU asks for adaptation, dossier moves to Path Elaboration Schema related changes: see in a document Codelists will be updated PCS and IM specific parameters documentation: see in a document TB decision needed when could be these changes migrated to PCS Production? 19 September 2018

Mapping between PCS and TSI TAF Process: PathRequest (Path Request) TypeOfRequest: Path Request MessageStatus: Creation PathDetails (Offer) PathConfirmed (Acceptance) TypeOfRequest: Path Confirmation PathDetails (Path Booked) TypeOfRequest: Path Details PCS Process: RU → IM Path Request CreateSingleDossier TrainInformation <path>master</path> PathInformation <path>slave</path> GetDossier Store RUIMPair_ID UpdateProgressStatus <progressstatus_id>A</progressstatus_id> <ruimPairId>?</ruimPairId> UpdateDossierStatus <dossierstatus_id>C</dossierstatus_id> <dossierstatus_id>E</dossierstatus_id> 19 September 2018

Mapping between PCS and TSI TAF Process: PathRequest (Path Request) TypeOfRequest: Path Request MessageStatus: Creation PathDetails (Offer) PathConfirmed (Acceptance) TypeOfRequest: Path Confirmation PathDetails (Path Booked) TypeOfRequest: Path Details PCS Process: IM → RU Offer UpdateProgressStatus (~receipt confirmation) <progressstatus_id>P</progressstatus_id> <ruimPairId>?</ruimPairId> UpdateDossierStatus <dossierstatus_id>T</dossierstatus_id> GetDossier Store tt_km <path>slave</path> as Path ID UpdatePath Path ID of the subsidiary UpdateProgressStatus <progressstatus_id>A</progressstatus_id> <dossierstatus_id>A</dossierstatus_id> 19 September 2018

Mapping between PCS and TSI TAF Process: PathRequest (Path Request) TypeOfRequest: Path Request MessageStatus: Creation PathDetails (Offer) PathConfirmed (Acceptance) TypeOfRequest: Path Confirmation PathDetails (Path Booked) TypeOfRequest: Path Details PCS Process: RU → IM Path Confirmation UpdateProgressStatus (~receipt confirmation) <progressstatus_id>P</progressstatus_id> <ruimPairId>?</ruimPairId> UpdateProgressStatus <progressstatus_id>A</progressstatus_id> UpdateDossierStatus <dossierstatus_id>P</dossierstatus_id> 19 September 2018

Mapping between PCS and TSI TAF Process: PathRequest (Path Request) TypeOfRequest: Path Request MessageStatus: Creation PathDetails (Offer) PathConfirmed (Acceptance) TypeOfRequest: Path Confirmation PathDetails (Path Booked) TypeOfRequest: Path Details PCS Process: No PCS action 19 September 2018

RFC Short term PR Pilots Excel tábla, mennyire támogatják ezt IF-n keresztül? Hogy oldjuk meg időlegesen a pre-acceptedet (PCS Support)

Short Term Path Request Problem: Offers are not available from the RFCs on the real short term (e.g. within 5 days) 30 days Reserved Capacity is designed for interim requests Meetings: 9th January, Vienna: Preparation meeting Definition of the variables Announcement of the possible approaches 3rd February, Vienna: Detailed discussion on the possible approaches, pilots Timeline definition Variables: request deadline, role of C-OSS, use of PaPs, number of operation days, scope of products, handling of double requests Approaches: Baltic-Adriatic: use of the regular Ad-Hoc process with the national OSS. C-OSS is not involved in the dossiers, only monitoring based on reports ScanMed and Orient/East-Med: active C-OSS with some kind of PaP products for the time being (PCS’s need for the C-OSS) 19 September 2018

Timeline April 2017 - Definition of technical requirements towards PCS June 2017 - Detailed description of process steps July 2017 - Technical evaluation of the technical requirements for PCS November 2017 - Eventual roll-out in PCS To elaborate on a detailed description of the second pilot a separate workshop will be organised by RNE on 7th April 2017 from 9:00 to 15:00 in Vienna Invitees: C-OSS Managers Timetabling experts 19 September 2018

Pilot on RFC 5 Pilot on Corridor 5 (Baltic – Adriatic) is planned to start in April/May (depending on MB and LM decisions) Members: PKP-PLK SZDC ZSR ÖBB SZ-I RFI Are you ready to support them in the Ad-Hoc process? Common (8 days) deadline for PR. How to handle temporarily the pre-accepted offer? SZDC: IM parameter is in place, if it’s set to „ANO”, RU doesn’t need to accept the offer How to update PCS in this case? Proposal: PCS Support will promote on a defined basis (e.g. weekly) those ad-hoc dossiers via certain borders to Active Timetable that were not rejected How to proceed on the other IMs? Shall we create the same parameter for each? Do you need notification service (e.g. in e-mail)? Could you use the current notification service? 19 September 2018

Interface map abilities and the statuses of the interfaces: Which version is supported? E.g. if it’s not 5.x, then it doesn’t work Which processes are supported? Which train types are supported? Are you able to handle PaPs? Are you able to handle subsidiaries? Are you able to maintain operation points?

Detailed Interface Map What do we know now? A company has or had some time ago a working connection with PCS We don’t know: Is the connection still working? Which version is used? Which way? Both direction or only in one direction Which processes are supported? Is notification service used? If so, which type? Which business are is supported? Passenger or cargo? Are PaPs supported? If so, then both or only fix or flex? Is combined PaP/Tailor-made solution supported? Are subsidiary timetables supported? If so, how do you create them? Erase/create or update methodology? Are you able to do maintenance via your connection? E.g. operation points, traffic periods, etc. What are your plans for supporting the currently not supported functions, business areas, processes? 19 September 2018

Path Alteration

Path Alteration What is the question? Replacement vs. Adjustment Who decides? How could you decide? SNCF-Reseau’s proposal: let PCS make the decision and splitting of the paths Scenarios: Shortening an existing path calendar when the train didn't start yet Shortening an existing path calendar when the train is already running IM would like to split the current 2 calendar pattern (and/or timetable) to 4. e.g. from a half year to a semester aspect. Before the train start on any of the path IM would like to split the current 2 calendar patterns (and/or timetable) to 4. e.g. from a half year to a semester aspect. Train is already running on some of the paths IM would like to merge the current 4 calendar patterns and/or timetable) to 2. e.g. from semester aspect to half year aspect. Train is not running yet IM would like to merge the current 4 calendar patterns and/or timetable) to 2. e.g. from semester aspect to half year aspect. Train is already running on some of the paths 19 September 2018

Envelope Concept

Possible timeframe for 2018 release Updated description Adapt Change Request Updated description Development/Test Prototype ready Workshop Workshop Workshop Final tests Review Review Release Today 21 Feb 17 Oct 2018 Nov 2018 2 May 2017 12 May 2017 13 Oct 2017 16 June 2017 26 June 2017 19 Sept 2017 18/19 May 2017 27-29 June 2017 20/21 Sept 2017 Oct 2017 – Jun 18 19 September 2018

18/19 May workshop Pre-conditions: Updated description of the concept by PCS Team Review of the description by the participants Meeting venue: Skopje at Netcetera office Participants: PCS Team: NCA & RNE External: max. 10 participants Ca. 2 persons from Freight RUs Ca. 2 persons from Passenger RUs Ca. 3 persons from IMs/ABs/RFCs Skills: Speaks English Knows the business logic PCS expert Open for challenges and changes Optional: IT background and TSI knowledge 19 September 2018

Modules of the concept Impact analysis TTR on EEC C-OSS guideline on EEC EEC on other projects Structure description (logic) Dossier creation Dossier editing Create new subpath Edit subpath Remove subpath Calendar editing Carry Forward: From old to new structure Temporary support of both Views Dossier creation steps Outline Timetable combinations Subpaths Calendar Comparison Pre-Arranged Paths Construction and publication (IM, RFC) Use of PaPs in dossiers as RU Handling of PaPs in Pre-booking phase as RFC Handling of PaPs in Path Elaboration as IM Interface Schema changes Additional web-service operations 19 September 2018

CRs & AOB