Table of contents

1. Introduction
2. Connecting to PCS as an IM – Timeline
3. Common Interface set-up
   • 3.1 Set up the connection between the Test Local Instances
   • 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 test and production site
   • 5.1 IM parameters
   • 5.2 Loco types
   • 5.3 Operation points
   • 5.4 Activity types
   • 5.5 Common Mandatory Parameters
   • 5.6 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 Case Testing

1. Introduction

The aim of this document is to provide a summary of the first steps to be undertaken by an Infrastructure Manager / Allocation Body (IM/AB) 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 IM – 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 IM and PCS with TAF TSI messages via the Common Interface. 

3. Common Interface set-up

3.1 Set up the connection between the Test Local Instances

To do:  

1. Provide to RNE the name, e-mail, address and phone number of the IM representatives to whom access to the Test Local Instance GUI shall be granted 
2. Set up the connection between the Test Local Instances 

Please find below the connection details of the RNE Test Local Instance: 

Name: RNE_TIL_Test_LI 

Hostname: taftest1.railneteurope.info 

IP address: 91.208.217.27 

Instance no: 03 

URL of the RNE Test LI for heartbeat connection set-up: https://taftest1.railneteurope.info/LIMessageProcessing/http/UICCCMessageProcessing/UICCCMessageProcessingHeartBeatWS?wsdl

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

Please note that RNE’s Test LI is used for testing purposes only. All agencies can receive access to the RNE Test LI and have visibility on the activities and configurations in RNE’s Test Local Instance. Please note there is also a Production Common Interface with Production Local Instances.

For more information, please refer to the Common Interface 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 LI. 

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 LIs 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: 

• 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 the 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://railnetat.sharepoint.com/sites/cms_pcs/SitePages/PCS%20Test%20Accounts.aspx

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, update and clean-up are critical to reducing implementation issues related to master data inconsistencies.  

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

The required changes in the master data shall be provided by the IM to RNE (except the ones related to operation points). In the standard process, IMs have a defined timeframe before the opening of the new timetable period in PCS, within which they can update the master data directly in PCS. Outside of this timeframe, IMs can update the master data if not yet used in any dossiers.  If the data is already used in a dossier, the IM shall send the required changes to support.pcs@rne.eu and RNE will contact the IM after doing an analysis of the impact. 

5.1 IM parameters 

To do:  

1. Check the existing IM parameters in PCS (there may be none) 
2. List the parameters that shall be made mandatory, if they are currently optional, or that shall be created (as optional or mandatory), if they do not yet exist in PCS  
3. Provide the list of required changes to RNE. 
4. Take the required actions to ensure the acceptance of this master data by the IM national 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 set-up of the parameters is important to ensure alignment between PCS and the IM booking system. 

5.2 Loco types 

To do:  

1. Check the existing loco types in PCS to ensure compliance with the required PCS structure.  
2. Provide the list of required changes to RNE for locos already used in dossiers. Other locos can be updated directly in the GUI. 
3. Take the required actions to ensure the acceptance of this master data by the IM national system. 

Each loco type must be 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 Operation points 

To do:  

1. Check the correctness of the operation points registered on the IM network  
2. If required, request the required updates in the CRD 

Operation points cannot be edited directly in PCS since this data is retrieved from the primary location registered in the Central Reference File Database (CRD), which is hosted by RNE. Please contact your CRD contact person if you require any updates. 

5.4 Activity types 

To do: 

1. Check the existing by default activity types. 
2. If required, create new activity types.
3. Take the required actions to ensure the acceptance of this master data by the IM national system. 

New activity types are IM-specific only and are only valid on the IM’s network. Please avoid creating duplicates. 

5.5 Common Mandatory Parameters 

To do:  

1. Check the existing by default mandatory parameters in PCS and list the parameters that shall be made mandatory, if currently optional. 
2. Provide the list of required changes to RNE. 
3. Take the required actions to ensure the acceptance of this master data by the IM national system. 

If requested by the IM, optional parameters by default can be made mandatory in PCS only for the concerned IM. For example, if the below-listed agency requires the traction weight information from the applicant, this field can be made mandatory.  

In the future, it is foreseen that IMs will also be able to disable optional parameters for their partners.  

5.6 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 IM in the IM’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 IM 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 IM 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 who 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 receives 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.