1. PCS Technical Board
Vienna, 28th February 2017

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

3. Review of developments until November 2018

4. 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

5. 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

6. 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

7. UpdateDossierRUIMPair

8. 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

9. Indication in the update procedure
Example:
19 September 2018

10. Indication in the trasseelement
Example:
19 September 2018

11. IP Consolidation

12. 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

13. 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

14. PaP Product definition

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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)

26. 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

27. Timeline April 2017 - Definition of technical requirements towards PCS
June Detailed description of process steps
July Technical evaluation of the technical requirements for PCS
November 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

28. 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 )? Could you use the current notification service?
19 September 2018

29. 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?

30. 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

31. Path Alteration

32. 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

33. Envelope Concept

34. 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

35. 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

36. 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

37. CRs & AOB