Table of contents

1. Introduction
2. Connecting to PCS as an Applicant – Timeline
3. Common Interface Set-up
   • 3.1 Set up the connection to the Test CI 
   • 3.2 Set up the heartbeat connection with RNE
4. Starting with PCS
   • 4.1 Relevant PCS documentation
   • 4.2 PCS test and production site
5. PCS master data
   • 5.1 IM parameters
   • 5.2 Loco types
   • 5.3 Activity types
   • 5.4 Common Mandatory Parameters
   • 5.5 Code lists
6. Message configuration
   • 6.1 Message format Config: schema
   • 6.2 Common/shared Metadata: message configuration
   • 6.3 Private Metadata (optional)
7. Use cases testing

1. Introduction

The aim of this document is to provide a summary of the first steps to be undertaken by applicants in order to connect to PCS via a Common Interface (CI).  

RNE contact persons for TAF TSI topics: 

• Nicolas Jasinski – Capacity Management IT Manager – nicolas.jasinski@rne.eu

2. Connecting to PCS as an Applicant – Timeline 

The tasks listed in this document do not have to be executed in the sequence they are being listed in the following chapters. Some of the activities can be undertaken and completed independently and in parallel. The below timeline is indicative but recommended to ensure the set-up of robust foundations for the implementation of the connection between the applicant and PCS with TAF TSI messages via the Common Interface. 

3. Common Interface Set-up

3.1 Set up the connection to the Test CI  

To do:  

1. Provide to RNE the name, e-mail, address and phone number of the applicant’s representatives to whom access to the Test CI shall be granted, and the applicant’s Test CI connection details.
2. Set up the connection to the Test CI. 

The very first step to connect to PCS is setting up the connection to RNE Test CI. Please find the connection details here. 
 

URL to the TEST CI GUI: https://taftest1.railneteurope.info/LI/dashBoard/getOutboundGraphicalOverview.action 

Please note that Test CI is RNE’s local CI and is used only for testing purposes. All agencies can receive access to the Test CI and have visibility on the activities and configurations in RNE’s CI. Please note there is also a production CI site.

For more information, please refer to the CI user manual (the latest version is available from the CCS Service Desk). 

3.2 Set up the heartbeat connection with RNE 

To do: set up the heartbeat connection with the Test CI. 

The first step to confirm that the communication in both directions is functioning is to establish the Heartbeat. It is also important to mention that the firewall rules need to be adjusted on both sides so that the CIs can see each other. This might require the involvement of the other departments of the companies, so it might take time. One shall not underestimate this issue. 

4. Starting with PCS

4.1 Relevant PCS documentation 

To do: review PCS documentation. 

Please find below the most relevant documentation when starting with PCS: 

• Please find below the most relevant documentation when starting with PCS: 
• TAF-TSI PCS communication guide: https://railnetat.sharepoint.com/sites/cms_pcs/SitePages/PCS-TAF-TAP-TSI-Communication-Guide.aspx
• PCS integration and migration guide: https://railnetat.sharepoint.com/sites/cms_tsicompliantpcsmandatoryinterface/SitePages/PCS-Web-Services-migration-guide.aspx?from=SendByEmail&e=ASzewapr5kGhiCtg0CMyKQ&at=9
• The latest sequence diagram listing the use cases and the corresponding messages: attached to the TAF-TSI PCS communication guide 

4.2 PCS test and production site 

To do:  

1. Login to PCS Test site (PCS Test 4) and become familiar with the tool. 
2. Provide to RNE the list of users to whom the PCS Webservices access rights shall be sent. 

The Test CI is connected to PCS Test 4: https://pcstest4.rne.eu/pcs/#/login. All PCS test 4 accounts are accessible with the following test accounts (same password for all test accounts): https://cms.rne.eu/pcs/pcs-documentation-0/pcs-test-accounts

The list of error codes that will be sent back to the user in case of error when communicating with PCS is only accessible with PCS Webservices access rights.  

5. PCS master data

The master data review is critical to reduce implementation issues related to master data inconsistencies.  

The master data shall be checked in PCS production site under the “Administration” menu https://pcs-online.rne.eu/pcs/#/login  and in the code lists. 

5.1 IM parameters 

To do:  

1. Check the existing IM parameters in PCS per IM.
2. Take required actions to ensure the acceptance of this master data by the applicant’s system. 

Also called “network-specific parameters” in TAF TSI or national parameters, IM parameters are parameters for which the IM requires information when receiving a request from an applicant. Each IM may have its own specificities so if required and requested by the IM to RNE, IM-specific parameters can be set up in PCS.  

The proper check of the parameters is important to ensure alignment between the applicant’s, PCS and the IM’s booking system. 

5.2 Loco types 

To do:  

1. Take the required actions to ensure the acceptance of this master data by the applicant’s system. 

Each loco type is identified with the following structure: 

• Type of loco 
• Country  
• Series number: crucial, because it must be exactly 4 numeric characters long. 
• Serial number (optional in planning and be default set up with 000) 

5.3 Activity types 

To do: 

1. Check the existing activity types in PCS per IM.
2. Take the required actions to ensure the acceptance of this master data by the applicant’s system. 

Please note that IM-specific activity types are marked with an “X” in the “predefined” column.

5.4 Common Mandatory Parameters 

To do:  

1. Check the existing common parameters in PCS per IM.
2. Take the required actions to ensure the acceptance of this master data by the applicant’s system. 

Please note that the mandatory/optional status of the parameters may differ between the IMs. 

5.5 Code lists 

To do:  check the code lists used in PCS (codes are coming from the TAF code lists) 

For example, the following fields shall be checked: 

• Brake types 
• Activity types 
• Location types 
• Route classes 

6. Message configuration

To do:  

1. Get in contact with the PCS team to know which version of the schema shall be used. 
2. Upload the applicable schema in the Test CI. 
3. Configure the inbound/outbound messages. 

For more information about the Metadata configuration in the CI, please refer to the CI user manual 

This configuration shall be completed by the applicant in the applicant’s local CI,

6.1 Message format Config: schema 

The applicable schema shall be imported. This schema is the schema of reference for the communication with PCS via the CI with TAF TSI messages. 

The below picture is an example only. The listed schema name/version may no longer be valid. 

6.2 Common/shared Metadata: message configuration 

The messages to be sent and received by the applicant shall be configured in the Common/Shared Metadata tab. 

The below picture is an example only. The listed schema name/version may no longer be valid. 

6.3 Private Metadata (optional) 

The private metadata configuration is relevant if a mapping with a legacy schema and system of the applicant is required.  

7. Use cases testing

The testing of the use cases shall start once the tasks from sections 2 to 5 are completed. 

To do:  

1. Review the use cases. 
2. Inform RNE about the start of the testing.  
3. Send TAF-TSI messages according to the use cases listed in the PCS TAF-TSI communication guide with the status “implemented” and check their correct reception and structure in the Test CI. 
4. Inform RNE of any issues during the testing. 

The use cases are listed in the PCS TAF-TSI Communication Guide. Each use case follows the same structure: 

• Sent information: sender, message type and general content. 
• Result: expected result if the sent information is successfully received by PCS. 
• Notifications: recipient, message type and general content. 

The use cases list is completed by a sequence diagram representing the message flows. Please find below explanations about the diagram structure. 

Practical example of a use case: accept the final offer as a leading applicant 

A leading applicant that wants to accept the offer received from an IM shall send a Path Confirmation Message to the CI. If PCS receives successfully the message, the leading applicant receives a Receipt Confirmation message.  

Once PCS received the leading applicant’s message, the other applicants involved in the dossier receive a Path Confirmation Message and all involved IMs receive a Path Confirmed Message.  

The below use case is an example only. The listed messages and content may no longer be valid.