Retrospective report of the past year PCS-TTR Day 2018, Vienna
Customer satisfaction survey and stats
General Survey Workflow Result Review by GA and PCS Day Survey analysis Survey for the users Survey preparation Presentation to the GA 23 February 2019
General Survey Timeline Apr May Jun Jul Aug Sept Oct Nov Dec Presentation General Assembly TIS Survey Results Preparation and Analysis Results Review General Assembly CIS Survey CIP Survey Reporting Survey PCS Survey 23 February 2019
PCS Survey: Number of participants: 61
Importance of PCS for your business
PCS Usage
Performance, usability, usefulness, support
Performance, usability, usefulness, support (Average results)
Showing the purpose, the story and the future of this action Frozen zone Showing the purpose, the story and the future of this action
Frozen zone is a step in the timetable process when an actor is not allowed to make an update on the dossier. This year, IMs were allowed to update their offer in Observations. „
6% of the dossiers were touched by IMs during Observations
Where was it used? Although it was only 6% of the dossiers, the opportunity was widely used.
It was available only for TT2019 Game over It was available only for TT2019
23 February 2019
GDPR in PCS: New users 23 February 2019
New users in PCS 23 February 2019
OPTIONAL
Dossier closure
Showing the possibilities Open and Harmonization Leading RU can close the dossier 01. Observations* 02. Active Timetable Leading RU or leading IM can close the dossier, after the timetable is started 05. Final Offer* Leading RU can close the dossier and new automatic promotion with all red lights 04. Post-processing* Leading IM or RFC can close the dossier 03. Dossier closure Showing the possibilities
Dwell time
What is dwell time? In PCS General Definition Dwell time is the time spent in the same position, area, stage of a process, etc. Non obligatory field Implemented also in Web services, with its own error code. In PCS the user can include the dwell time to indicate the minimum amount of time needed to stay in one location.
Dwell time should have a standard format defined in minutes and should be taken into account when validating times. Dwell time format
the dwell time (DT) needs to be equal or smaller than 90 minutes In the example, the dwell time (DT) needs to be equal or smaller than 90 minutes DT ≤ Dep – Arr Dwell time formula
Missing arrival or departure times
Other considerations PCS will calculate automatically overnight shifts (offsets) If a time zone change is implemented, PCS will adjust automatically the calculation The system won't check the operation point type In PCS IP error code indicates to the uploader agency if the web-service request contains invalid dwell time. The error code is: 659 INVALID_DWELL_TIME
Hello TSI world! <html> <header><title>This is title</title></header> <body> Hello TSI world! </body> </html>
Instructions for the presentation PCS CI: Common Interface endpoint of PCS (for the TSI communication) PCS IP: Integration Platform endpoint of PCS (for the usual PCS web-service communication) TTM: TAF-TSI Test Manager that simulates pre-defined actions and triggers messages to PCS TIL: Transition and Integration Layer that maps the TSI message content to PCS web-services SOAP UI: the most popular platform for Application Programming Interface functional tests. Substituting your real application
Communication Options TTM PCS CI TIL PCS IP PCS CI TIL PCS IP SOAP RU/IM national tool PCS CI TIL PCS IP PCS IP SOAP RU/IM national tool PCS IP
Messages „…Path Coordination, Path Request, Path Details, Path Not Available, Path Details Confirmed, Path Details Refused, Path Booked, Receipt Confirmation, Error message…” Path Coordination For harmonization purposes. RU-RU or IM-IM communication Receipt confirmation Thank you! I got your message, I could import it in my system and I started to process your request. Path Not Available Something went wrong, the path is no longer available. We will inform you about the possible alternative options And the attributes… Message status, type of information, type of request, code lists, etc.
Scope of the pilot (runs until 2020 Q2) Path request and offer procedure among the RUs and IMs, including also the harmonization of the requests and the offers Path Request process 01 Updating the contracts after the allocation either from the RU or from the IM side. Reviewing the process and message workflow Path modification, alteration, cancellation process 02 Checking all the TSI identifiers, like Train ID, Path Request ID, Path ID and Case Reference ID, if they are suitable for their task Identification 03 Testing FTE’s candidates for the planning and commercial train numbers Train number candidates 04
Presentation