Connection to PCS via the Common Interface – The first steps for Infrastructure Managers



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: 


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



2. Common Interface set-up 

2.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 
  3. Send to RNE the LI information, remote LI information - Inbound, remote LI information - Outbound and the message types to be configured 


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


Name: RNE_TIL_Test_LI 


IP address: 

Instance no: 03 

URL of the RNE Test LI for heartbeat connection set-up:



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


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


3. Starting with PCS 

3.1 Relevant PCS documentation 

To do: review PCS documentation. 

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


3.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: All PCS test 4 accounts are accessible with the following test accounts (same password for all 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.  




4. PCS Master Data  

The master data review, update and clean-up are critical to reduce implementation issues related to master data inconsistencies.  

The master data shall be checked in PCS production site under the “Administration” menu  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 and RNE will contact the IM after doing an analysis of the impact. 


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


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



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



4.4 Activity types 

To do: 

  1. Check the existing by default activity types. 
  2. If required, create new activity types.
  3. Take 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. 




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



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


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


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


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



5.3 Private Metadata (optional) 

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


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



Company Type