PCS TAF-TSI Communication Guide

Content

Versions

Version number

Date

Author

Highlights

0.1

02-07-2020

Máté Bak

Creation of the document

 

Introduction

The aim of this document to provide a guide for Infrastructure Managers (IMs), Allocation Bodies (ABs) and Applicants (RAs) who would like to synchronize their timetables with PCS from the national systems.

There are specific use cases prepared and described for practical, real-life issues dedicated either to IMs/ABs or RAs.

Apart from the messages and their content, we tried to also describe the particularities of PCS and its TAF-TSI implementation, such as the way it handles the identifiers and how a company shall communicate with a central tool.

Working with the national particularities is also essential and PCS is fulfilled with a lot of national specific data. The guide will explain also how to work with these Network-Specific parameters and with the loco types.

The document will be permanently updated with further use cases. Currently, the focus is on the particularities and the traditional (tailor-made) path request procedures for a different kind of process type. However, in the future, the document will be extended with use cases for Path Alteration and Path Modification and it needs to be updated once working with Pre-arranged Paths will be possible via the PCS Shared Metadata.

Further helper materials, such as example messages for the different use cases can be found in this Filedepot folder.

Abbreviations

Abbreviation

Explanation

MS

Message Status. Assigned by the Sender 1 = creation, 2 = modification, 3 = deletion

TOI

Type of information. Enumeration, indicating to which process step or process type in the planning the message belongs

TOR

Type of request. Enumeration for the types of processes. Study (1), Request (2) - used in PCS as Ad-hoc process type, Modification (3), (4) Annual TT New Request, (5) Annual TT Late Path Request, (6) Rolling Planning, (7) Pre-accepted Offer Request

NSP

Network Specific Parameter, also known as NIMP (National IM Parameter)

NIMP

National IM Parameter, also known as NSP (Network Specific Parameter)

PR

Path Request object, prepared by the RA

PA

Path object, prepared by the IM/AB

RA

Responsible Applicant

IM

Infrastructure Manager

AB

Allocation Body

Messages

For the communication with PCS, the usual Planning related messages shall be implemented. However, you will see that most of the time, you can rely on the Path Coordination Message and the rest will be solved by PCS itself. Of course, the messages generated and sent from PCS will be always in line with the specification of TAF-TSI.

  • Path Request Message, because PCS will deliver the path requests to the IMs/ABs with Path Request messages
  • Path Details Message, because PCS will deliver the offer to the RAs with Path Details messages
  • Path Coordination Message, because for updates in PCS, dossier promotions you shall send Path Coordination messages, and PCS will use this for most of the notifications
  • Error Message, because if there is any mistake regarding your update, PCS will send back Error messages with PCS specific error codes inside
  • Path Confirmed Message, because PCS will deliver the information about the acceptance of the Final Offer to IMs with this message
  • Path Details Refused Message, because PCS will deliver the information about the acceptance of the Final Offer to IMs with this message
  • Path Not Available Message, because IMs need an option to delete an existing path in PCS. They can do it with this message
  • Object Info Message, because PCS will deliver the notifications for every timetable related update with Object Info Message. The reason is that all the sub-paths of the dossier can be entered to one Object Info Message and there is no need to send Path Coordination Messages for each and every sub-path separately

Message Status

According to the TAF-TSI XSD each message has a message status and it can be one of the following values:

  • 1 – Creation
  • 2 – Modification
  • 3 – Delete

However, it’s important to note that PCS is a synchronous system, hence, it processes the received messages immediately and there is no chance for either modifying or deleting a formerly sent message. In case of a mistake, we expect another message fixing the issue also with an MS = 1 – creation.

So, the conclusion is that for PCS, only MS = 1 – creation values can be used.

RNE as sender and recipient

PCS behaves as a message broker in the communication of RA-RA, RA-IM, IM-IM. Normally, the sender and the recipient fields of the messages are fulfilled with the company code of either the RA or the IM. However, there is no place for RNE company code, meaning for PCS in this case. Thus, for the future, it's planned to extend the message header with an additional field, called Broker, like it's shown in the picture below.

As the solution is not even close to being implemented, we have applied a simplification for PCS communication. The actors can send their messages directly to PCS, and PCS will forward them, based on the advanced notification service of the system. So, for each message:

  • Sender: RA/IM Company Code
  • Recipient: RNE Company Code

Then, immediately with the update in the PCS dossier:

  • Sender: RNE Company Code
  • Recipient: RA/IM Company Code

As the RA - IM pairs are stored properly in the system, Path Request Messages, Path Details Messages will be delivered always to the proper partner. As the sender won't contain the company code of the applicant, the IM can get the Applicant information from the message content, as for PCS, each location of a path will belong to the same responsible applicant.

Please note also the economical and other type of benefits of this solution, because the mapping and configuration efforts are reduced to a single channel between PCS and the national system, without having a configuration for all possible communication streams (e.g. for each RA active in a country).

In line with the implementation and the above written structure, the use cases below are described in this manner.

Identifiers

PCS is prepared to handle TAF-TSI identifiers and even more, they are mandatory in the dossiers. However, as most of the agencies are not ready yet to work with these identifiers, the system is able to generate them automatically. The logic is simple; when the user wants, it’s possible to include the ID, if not, the system takes care of it. Let’s see the logic in practice for the different identifiers.

Train ID

During the dossier creation and in the Open phase, the dossier creator agency is allowed to select the company whose company code will be part of the Train ID. Then it’s also possible to define the core element. The timetable period is coming automatically from the timetable period of the dossier (also known as Case Reference). The variant is set to 00 by default.

Currently, there are ongoing discussions and projects for the proper definition of the Train Information. With that regard, PCS works now only with PRs and PAs. The user has the chance to link those PRs to different Train variants. When the user creates the PRs in the dossier (called as sub-paths in the Applicant timetable) and their origin/border/destination varies, then the user must link them to different Train ID variants. This logic is in line current description of the JS Handbook.

What happens if a user cannot provide the Train ID?

It might happen that either a company is not so advanced with its TSI implementation that it can generate its own Train ID, or the user is simply a GUI end-user and not even aware of the meaning of the Train ID. In that case, PCS will generate a Train ID. If the creator agency has UIC ID, then it will be added as company code, if not, then PCS will add 3178 as RailNetEurope. For the core element, the dossier ID will be used, and the variants are automatically increased as a sequence if there is a change in the origin/border/destination. Example: TR - 3178 - ******215987 - 00 - 2020, where 215987 is the dossier ID.

Path Request ID & Path ID

There is a slight difference compared to the Train ID. Companies can still define their own PR ID/PA ID, but only if it’s a machine to machine communication, meaning via an interface. PCS has its fields in the schema, called tsi_path_id. This field keeps the PR ID in the Applicant timetable, and the PA ID in the IM timetable.

<t----- id="...">

  <dossier_id>...</dossier_id>

  <train_id>

    <companyCode>...</companyCode>

    <objectType>...</objectType>

    <coreElement>...</coreElement>

    <variant>...</variant>

    <timetableYear>...</timetableYear>

    <startDate>...</startDate>

  </train_id>

  <traffic_period_text>...</traffic_period_text>

  <agency_type_id>...</agency_type_id>

  <title>...</title>

  <validity_period>...</validity_period>

  <tsi_path_id>

    <companyCode>...</companyCode>

    <objectType>...</objectType>

    <coreElement>...</coreElement>

    <variant>...</variant>

    <timetableYear>...</timetableYear>

    <startDate>...</startDate>

  </tsi_path_id>

Identifiers in PCS right after the Path Request

When the leading Applicant submits the path request, PCS creates immediately IM timetable in the dossier and copies there the content of the Applicant timetable. Then, IMs can start working on the offers in Path Elaboration. However, these PCS paths in the IM timetable get also unique PCS IDs. And the tsi_path_id is still mandatory, however, there is no chance of any input from an IM to set this value. Those shall happen at the same time as the path request. Therefore, PCS generates again the tsi_path_id using the same logic as written above, just using the company code of the responsible IM or Allocation Body. The problem starts here. PCS sends PathCoordination message to the involved IM with the path information from the IM timetable and there they get the generated, PCS made TSI PA ID.

There are two options to apply:

  • The IM doesn't care, and stores the received PCS based identifier, just like any other integrated IM does for the regular PCS interface. They continue working with this identifier
  • The IM doesn't like this ID. He has an option to delete the path and create a new one with his own national ID. PCS will store it in the tsi_path_id element

Network Specific Parameters

PCS and TAF TSI have this option common, that apart from the common train parameters each IM has the possibility to define his national IM parameters for covering the national particularities. These parameters can be defined on.

In PCS, the parameters can be defined on dossier level for an RA – IM pair and on the path section level. This can be represented in the TAF-TSI messages as message level and planned journey location level parameters. Please find here an example of the PCS and the TAF-TSI structure.

National IM Parameter in PCS

<processtype_id>H</processtype_id>

<national_im_parameter id="78118">

         <name>D01 - Vertriebskanal</name>

         <value>PCS</value>

</national_im_parameter>

Network Specific Parameter in TAF-TSI

</ns1:PathInformation>

         <ns1:NetworkSpecificParameter>

                 <ns1:Name> D01 - Vertriebskanal </ns1:Name>

                 <ns1:Value> PCS </ns1:Value>

         </ns1:NetworkSpecificParameter>

</ns1:PathCoordinationMessage>

Both are working with a name/value pair. However, in addition to the TAF TSI options, in PCS the IMs can define the required format of the parameter and the application checks their entry format. That is why please always respect the defined format of the parameter, otherwise, PCS will send back an error message.

Please find here a summary of the possible formatting options in PCS:

  • String
    • Min numbers of characters >=1
    • Max number of characters <=256
  • Single choice list: values are defined in the system
  • Multiple choice list: values are defined in the system
  • Number
    • Min number of digits >=1
    • Max number of digits <=12
  • Date
    • dd.mm.yyyy
    • yyyy-mm-dd
  • Time
    • hh:mm:ss
    • hh:mm
  • Datetime
    • dd.mm.yyyy hh:mm:ss
    • dd.mm.yyyy hh:mm

Also, the IMs have the possibility in PCS to set-up parent-child relations among the parameters with an impact on their visibility or mandatory status.

Please note that dossier level parameters can be entered only after the dossier creation when the RA - IM pairs are already available in the system. It means, they cannot be entered in the first step (dossier creation). Agency can update the dossier level parameters with message-level NSPs using an edit sub-path type of Path Coordination. Then add the message-level parameters after the Path Information and the parameters will be updated. Also, please note that an agency can edit the NSPs only for its partner IM. Editing of the dossier level parameters is limited to the Harmonization phase and available only for Applicants. Even IMs can't edit those parameters later in Path Elaboration or Post-processing phase.

Loco types

Since version 2.2.3 loco types are handled with a composite identifier in TAF TSI. In PCS, it’s also possible for the IMs to publish that are allowed to run on their network (it was developed a couple of years before the TAF TSI XSD change). However, there is a slight difference between the two structure. Let’s check first the TAF TSI structure.

  • Type Code 1: it’s always 9
  • Type Code 2: general vehicle type
    • 0 Miscellaneous
    • 1 Electric locomotive
    • 2 Diesel locomotive
    • 3 Electric multiple-unit set (high speed) [power car or trailer]
    • 4 Electric multiple-unit set (except high speed) [power car or trailer]
    • 5 Diesel multiple-unit set [power car or trailer]
    • 6 Specialised trailer,
    • 7 Electric shunting engine
    • 8 Diesel shunting engine
    • 9 Special vehicle
  • Country code
  • Series number

PCS has its own structure, and currently, its mapping tool converts the loco types Type Code 2 field in the TAF-TSI format. The following fields are taken into account:

  • Engine type: diesel, electric, hybrid, steam
  • Top speed
  • Multiple unit: yes/no

From this information, PCS can tell whether a loco is in Type Code 2 “1”, “2”, “3”, “4” or “5”, but not more than that.

Series number is not always kept in 4 digits because not every IM was able to publish their loco types with UIC numbering. If you are planning to use TAF TSI communication, please check first your loco types in PCS.

A PCS development is planned for Autumn 2020 to support the same loco type structure as in TAF (except the length of the Series number due to the same reason)

Use Cases

Please find here all the use cases related either to IMs/ABs or to RAs. Please note that some of them are commonly applicable for each party, e.g. an acceptance indicator change works the same for any agency in a PCS dossier.

Create dossier (Implemented)

Sent information

The dossier is created by the leading Applicant. To do that, it shall send a Path Coordination Message to PCS with the following information.

  • Message header:
    • Sender: company code of the leading Applicant
    • Recipient: 3178 (RNE)
  • TOR: the proper code, depending on the selected process type
  • TOI: 30 – create dossier
  • Planned Transport Identifiers: TR ID. If the applicant likes to have its own PR ID stored in PCS, it can also send the PR ID.

Result

If everything went fine, the dossier is created in PCS. If not, an Error Message is sent back with the root cause. For the codes, please check the chapter with the Error Message.

Path Coordination message can contain Train Information and/or Path Information element. For dossier creation, PCS considers the information from the Train Information element. Based on that, PCS prepares the dossier with the following content:

  • Territories, based on the RA  - IM pairs in the Train Information.
  • Sub-paths, based on the Planned Journey Location information in the Train Information element. Be sure, that each pair has at least two locations in the Train Information. In PCS, the timetables are stored in so-called sub-paths (~PR or PA, depending in which timetable you are checking it)
  • Dossier ID is generated, which will be used further as the CR ID
  • Train ID is stored
  • PR IDs are generated for each sub-paths based on the PCS path IDs in the system

Notifications

The dossier creator agency (leading Applicant) shall be informed that the dossier was successfully created. For that, PCS will send a Path Coordination Message without any Train Information or Path Information. The rest of the message will look almost as the sent message.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of the leading Applicant
  • TOR: the process type automatically resolved by PCS. Please note that it might be different than the sent, if the creator agency didn’t respect the timetabling calendar. After that, each agency shall respect this TOR during the path request process.
  • TOI: 30 – create dossier
  • Planned Transport Identifiers: TR ID, CR ID, PR IDs

The involved agencies (other Applicants) shall be informed that a dossier was created and now it’s in Harmonization. For that, PCS will send an Object Info Message.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of the involved Applicant
  • Identifier: CR ID
  • Path Information Extended: an array of all the created sub-paths in the dossier in the following structure
    • Planned Transport Identifiers: TR ID, CR ID, PR ID
    • Path Information

Change acceptance indicator to green (Implemented)

This is a common use case and shall be applied in the same way by RAs, IMs/ABs. The aim of the use case is to set the acceptance indicators of the agency to green in PCS, which is resolved with the harmonization status in the TAF-TSI.

Sent information

Any involved agency who would like to set the acceptance indicator to green, shall send Path Coordination Message without any Train Information or Path Information having there the following information.

  • Message header:
    • Sender: company code of the involved agency
    • Recipient: 3178 (RNE)
  • TOR: the proper code, depending on the process type
  • TOI: 02 – harmonization accepted
  • Planned Transport Identifiers: TR ID, CR ID

 

Result

If all the mandatory information is fulfilled in the dossier, the acceptance indicators belonging to the involved agency are changed to green. If not, then PCS will send an Error Message.

Notifications

In case of a successful update all affected agencies (including the original sender) shall receive a Path Coordination Message as the following.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of the involved RA or IM/AB depending on the phase
  • TOR: the proper code, depending on the process type
  • TOI: 02 – harmonization accepted
  • Planned Transport Identifiers: TR ID, CR ID

Change acceptance indicator to red

This is a common use case and shall be applied in the same way by RAs, IMs/ABs. The aim of the use case is to set the acceptance indicators of the agency to red in PCS. It works almost the same as setting the green light, but in addition, the sender agency must place a mandatory comment in PCS declaring the reason of the red light.

Sent information

Any involved agency who would like to set the acceptance indicator to red, shall send Path Coordination Message without any Train Information or Path Information having there the following information.

  • Message header:
    • Sender: company code of the involved agency
    • Recipient: 3178 (RNE)
  • TOR: the proper code, depending on the process type
  • TOI: 03 – harmonization rejected
  • Planned Transport Identifiers: TR ID, CR ID
  • Free text field on the message level: reason of the red light

Result

The involved agency set its acceptance indicators to red and the reason is saved in the comment area of the dossier.

Notifications

In case of a successful update all affected agencies (including the original sender) shall receive a Path Coordination Message as the following.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of the involved RA or IM/AB depending on the phase
  • TOR: the proper code, depending on the process type
  • TOI: 03 – harmonization rejected
  • Planned Transport Identifiers: TR ID, CR ID
  • Free text field on the message level: reason of the red light

Automatic downgrade of an acceptance indicator

This is a common use case and shall be applied in the same way by RAs, IMs/ABs. It might happen that you have already set your acceptance indicator to green, but your neighbour makes a change in the dossier having an impact on the border. PCS detects this action and it will automatically downgrade your light from green to yellow. It’s valid for RAs (Harmonization) and IMs/ABs (Path Elaboration, Post-processing) too. PCS checks the following elements on the borders (handover and/or interchange point):

  • Timetable
  • Dwell time
  • Calendar
  • Location

Sent information

There is nothing to send here, because this is an action by PCS.

Result

The acceptance indicator of the affected agency is changed to yellow.

Notifications

The affected agencies shall receive a Path Coordination Message as the following.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of the involved RA or IM/AB depending on the phase
  • TOR: the proper code, depending on the process type
  • TOI: 01 – harmonization in process
  • Planned Transport Identifiers: TR ID, CR ID

General timetable update (Implemented)

This is a common use case and shall be applied in the same way by RAs, IMs/ABs. The aim of the use case is to make any kind of update in the PCS dossier for the timetables. Either changes times, edit the calendar, add new points, delete points, edit train parameters. If a location is not mentioned in the path that was part before, PCS will interpret as a delete. For calendar changes, the agency shall send only a new calendar bitfield with the message. It can be also used for adding new sub-paths (PR/PA) to a dossier. If the ID of the sub-path is not known by PCS, it will interpret as a deletion.

Sent information

Any involved agency who would like to make an update on the timetable in a PCS dossier, shall send a Path Coordination Message with Path Information element having there the following information.

  • Message header:
    • Sender: company code of the involved Applicant
    • Recipient: 3178 (RNE)
  • TOR: the proper code, depending on the process type
  • TOI: 01 – harmonization in process
  • Planned Transport Identifiers: TR ID, CR ID, PR ID
  • Path Information element

Result

If everything went fine, the dossier is updated in PCS. If not, an Error Message is sent back with the root cause.

Notifications

In case of a successful update all affected agencies (including the original sender) shall receive an Object Info Message with the following content.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of the involved agency
  • Identifier: CR ID
  • Path Information Extended: an array of all the sub-paths in the dossier in the following structure
    • Planned Transport Identifiers: TR ID, CR ID, PR ID
    • Path Information

Send path request as leading Applicant (Implemented except the Object Info)

The aim of this use case to promote the dossier from Harmonization to Path Request as a leading Applicant. As PCS stores everything in one dossier, it’s not necessary to send Path Request messages for each and every sub-paths, but the leading Applicant can simply promote the whole dossier, also on behalf of the other involved Applicants. This can happen by an automatic promotion of PCS on a timetable deadline too. In that case, everything works the same way, but there is no need for the sent information by the leading Applicant.

Sent information

The leading Applicant who would like to promote the dossier to Path Request, shall send a Path Coordination Message without Train Information and Path Information to PCS having there the following information.

  • Message header:
    • Sender: company code of the leading Applicant
    • Recipient: 3178 (RNE)
  • TOR: the proper code, depending on the process type
  • TOI: 04 – harmonization completed
  • Planned Transport Identifiers: TR ID, CR ID

Result

If all the mandatory information is fulfilled in the dossier and all the acceptance indicators of the Applicants are set to green, the dossier will be promoted. If not, then PCS will send an Error Message.

Notifications

All involved Applicant shall be informed about the phase promotion; thus, PCS will send one Path Coordination Message to them with the following content.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any involved Applicant
  • TOR: the proper code, depending on the process type
  • TOI: 04 – harmonization completed
  • Planned Transport Identifiers: TR ID, CR ID

Information about the dossier in Path Request phase

On the other side, all IMs/ABs shall be informed about the path requests; thus, PCS will send Path Request Messages for their territory and also one Object Info Message so that they are informed about the content of the whole dossier.

The content of the Path Request Messages

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any involved IM/AB
  • TOR: the proper code, depending on the process type
  • TOI: 04 – harmonization completed
  • Planned Transport Identifiers: TR ID, CR ID, PR ID
  • Related Planned Transport Identifiers: all other PR IDs that are belonging to the dossier
  • Train Information
  • Path Information

The content of the Object Infor Message

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any IM/AB
  • Identifier: CR ID
  • Path Information Extended: an array of all the sub-paths in the dossier in the following structure
    • Planned Transport Identifiers: TR ID, CR ID, PR ID
    • Path Information

Information about the dossier in Path Elaboration phase

Please note that for most of the process types, the Path Request is only a milestone in PCS, that is why, the dossiers are automatically promoted to the next phase, called Path Elaboration. As this step is recorded in the dossier with a separated dossier version and all new dossier versions shall trigger a notification, the IMs/ABs will receive another notification immediately after the Path Request promotion. All IMs/ABs will receive a Path Coordination Message without Train Information and Path Information. As it’s only a “simple” phase promotion, there is no Object Info Message in this case.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any involved IM/AB
  • TOR: the proper code, depending on the process type
  • TOI: 07 – create offer
  • Planned Transport Identifiers: TR ID, CR ID

Delete a sub-path from a dossier

This is a common use case from the business point of view; however, RAs and IMs/ABs shall use different kind of message to perform this action.

Sent information

Any involved Applicant, who would like to delete a sub-path from a dossier, shall send a Path Cancelled Message with the following content.

  • Message header:
    • Sender: company code of the involved Applicant
    • Recipient: 3178 (RNE)
  • TOR: the proper code, depending on the process type
  • TOI: 32 – path cancelled full
  • Planned Transport Identifiers: TR ID, CR ID, PR ID

Any involved IM/AB, who would like to delete a sub-path from a dossier, shall send a Path Not Available Message with the following content.

  • Message header:
    • Sender: company code of the involved IM/AB
    • Recipient: 3178 (RNE)
  • TOR: the proper code, depending on the process type
  • TOI: 32 – path cancelled full
  • Planned Transport Identifiers: TR ID, CR ID, PA ID

Result

The sub-path either with the PR ID from the Applicant timetable or with the PA ID from the IM timetable is successfully deleted.

Notifications

As this update affects the whole dossier content, all affected agencies will receive one Object Info Message from PCS with the following content.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any of the affected agency
  • Identifier: CR ID
  • Path Information Extended: an array of all the sub-paths in the dossier in the following structure
    • Planned Transport Identifiers: TR ID, CR ID, PR ID/PA ID
    • Path Information

Send Offer (draft or final) as leading IM/AB (Implemented except the Object Info)

The aim of this use case is to show, how the leading IM/AB can send an offer. The same approach can be used for Draft Offer or Final Offer. This can happen by an automatic promotion of PCS on a timetable deadline too. In that case, everything works the same way, but there is no need for the sent information by the leading IM.

Sent information

The leading IM who would like to submit an offer for a PCS dossier, shall send a Path Coordination Message without Train Information and Path Information having there the following information.

Result

If all the mandatory information is fulfilled in the dossier and all the acceptance indicators of the IMs/ABs are set to green, the dossier will be promoted. If not, then PCS will send an Error Message.

Notifications

All involved IMs/ABs shall be informed about the phase promotion; thus, PCS will send one Path Coordination Message to them with the following content.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any involved IM/AB
  • TOR: the proper code, depending on the process type
  • TOI: 09 – draft offer, 16 – final offer
  • Planned Transport Identifiers: TR ID, CR ID

On the other side, all Applicants shall be informed about the offers; thus, PCS will send Path Details Messages for their territory and also one Object Info Message so that they are informed about the content of the whole dossier.

The content of the Path Details Messages

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any involved Applicant
  • TOR: the proper code, depending on the process type
  • TOI: 09 – draft offer, 16 – final offer
  • Planned Transport Identifiers: TR ID, CR ID, PA ID
  • Related Planned Transport Identifiers: all other PR IDs & PA IDs that are belonging to the dossier
  • Path Information

The content of the Object Infor Message

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any involved Applicant
  • Identifier: CR ID
  • Path Information Extended: an array of all the sub-paths in the dossier in the following structure
    • Planned Transport Identifiers: TR ID, CR ID, PR ID/PA ID
    • Path Information

Reject dossier as leading IM

The aim of this use case to show, how a leading IM can reject a dossier. It’s possible for them only in Path Request and Path Elaboration phases.

Sent information

The leading IM who would like to reject a dossier in PCS, shall send a Path Coordination Message without Train Information and Path Information having there the following information.

  • Message header:
    • Sender: company code of the leading IM/AB
    • Recipient: 3178 (RNE)
  • TOR: the proper code, depending on the process type
  • TOI: 15 – Preparation of draft offer rejected
  • Planned Transport Identifiers: TR ID, CR ID
  • Free text field on the message level: reason of the rejection

Result

The dossier is rejected by the leading IM and it goes back to Harmonization status. Also, the reason of the rejection is saved to the comment area of the dossier.

Notifications

All agencies shall be informed about the rejection; thus, PCS will send a Path Coordination Message without Train Information and Path Information having there the following information.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any involved agencies
  • TOR: the proper code, depending on the process type
  • TOI: 15 – Preparation of draft offer rejected
  • Planned Transport Identifiers: TR ID, CR ID
  • Free text field on the message level: reason of the rejection

Accept the dossier as a leading Applicant (Implemented)

The aim of this use case to show, how a leading Applicant can accept the dossier and promote it to Active Timetable. Here we have differences among the process types, because for New Path Request and Rolling Planning this acceptance happens in the Final Offer phase, after a Post-processing phase, but for Late Path Request and Ad-hoc Path Request it happens immediately after the offer following the Path Elaboration.

Sent information

The leading Applicant who would like to accept the dossier and move it to Active Timetable, shall send a Path Coordination Message without Train Information and Path Information having there the following content.

  • Message header:
    • Sender: company code of the leading Applicant
    • Recipient: 3178 (RNE)
  • TOR: the proper code, depending on the process type
  • TOI: 17 – final offer accepted
  • Planned Transport Identifiers: TR ID, CR ID

Result

If all the mandatory information is fulfilled in the dossier and all the acceptance indicators of the applicants are set to green, the dossier will be promoted, and it arrives at Active Timetable phase.

Notifications

All involved Applicants shall be informed about the promotion; thus, PCS will send a Path Coordination Message without Train Information and Path Information having there the following content.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any involved Applicant
  • TOR: the proper code, depending on the process type
  • TOI: 17 – final offer accepted
  • Planned Transport Identifiers: TR ID, CR ID

All IMs/ABs shall be informed about the acceptance; thus, PCS will send Path Confirmed Messages to them with the following content.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any involved IM/AB
  • TOI: 17 – final offer accepted
  • Planned Transport Identifiers: TR ID, CR ID, PA ID
  • Related Planned Transport Identifiers: all other PR IDs & PA IDs that are belonging to the dossier

Impact of the dossier in Active Timetable

As the dossier arrived at Active Timetable, it reached its final destination in the path request process. To keep everyone up to date, PCS will send Path Details Messages with the booked paths to all involved Applicants.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any involved Applicant
  • TOR: the proper code, depending on the process type
  • TOI: 22 - booked
  • Planned Transport Identifiers: TR ID, CR ID, PA ID
  • Related Planned Transport Identifiers: all other PR IDs & PA IDs that are belonging to the dossier
  • Path Information

The same shall happen for Pre-accepted offer dossier, when the leading IM sends the Offer, because then, it goes automatically to Active Timetable.

Refuse the Final Offer as a leading Applicant

The aim of this use case is to show, how a leading Applicant can refuse the final offer. There are two options available for them. For Ad-hoc path request, this decision can be made right after the Path Elaboration phase, for the others, it can happen after the Post-processing phase.

  1. Refuse it without revision
  2. Refuse it, asking for revision (it’s available only for Ad-hoc path request)

Sent information

The leading Applicant who would like to refuse the offer, shall send a Path Coordination Message to PCS without Train Information and Path Information having there the following content.

  • Message header:
    • Sender: company code of the leading Applicant
    • Recipient: 3178 (RNE)
  • TOR: the proper code, depending on the process type
  • TOI: 25 – offer/final offer rejected (without revision) or 27 – offer/final offer rejected (revision required)
  • Planned Transport Identifiers: TR ID, CR ID

Result

The result depends on the selected refusal option. If it’s done without revision, the dossier will go to Closed phase, but if it’s with revision (available only for Ad-hoc), it will go back to Path Elaboration.

Notifications

All involved Applicants shall be informed about the rejection; thus, PCS will send a Path Coordination Message without Train Information and Path Information having there the following content.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any involved Applicant
  • TOR: the proper code, depending on the process type
  • TOI: 25 – offer/final offer rejected (without revision) or 27 – offer/final offer rejected (revision required)
  • Planned Transport Identifiers: TR ID, CR ID

All involved IMs/ABs shall be informed about the rejection too; thus, PCS will send Path Details Refused Messages.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any involved IM/AB
  • TOI: 25 – offer/final offer rejected (without revision) or 27 – offer/final offer rejected (revision required)
  • Planned Transport Identifiers: TR ID, CR ID, PA ID
  • Related Planned Transport Identifiers: all other PR IDs & PA IDs that are belonging to the dossier

Close dossier

This is a common use case and shall be applied in the same way by RAs, IMs/ABs. The aim of this use case is to show, how a leading agency can close a dossier. The option is available for leading Applicants in Harmonization, Observations and Active Timetable phases, and it’s available for the leading IM/AB in Path Elaboration, Post-Processing and Active Timetable phases. As for the withdrawal and the red lights, it’s mandatory to place a comment with this action.

Sent information

The leading agency who would like to close the dossier in PCS, shall send a Path Coordination Message without Train Information and Path Information having there the following content.

  • Message header:
    • Sender: company code of leading agency
    • Recipient: 3178 (RNE)
  • TOR: the proper code, depending on the process type
  • TOI: 31 – close dossier
  • Planned Transport Identifiers: TR ID, CR ID

Result

The dossier is closed, and it cannot be re-opened. The only available option is to export it from the system or make a copy and start a new one.

Notifications

All affected agencies shall be informed about the dossier closure; thus, PCS will send a Path Coordination Message without Train Information and Path Information having there the following content.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any involved agency
  • TOR: the proper code, depending on the process type
  • TOI: 31 – close dossier
  • Planned Transport Identifiers: TR ID, CR ID

Make Observation

The aim of this use case to show, how an Applicant can place an Observation in a dossier.

Sent information

The involved Applicant who would like to place an Observation, shall send a Path Coordination Message without Train Information and Path Information having there the following content.

  • Message header:
    • Sender: company code of any involved Applicant
    • Recipient: 3178 (RNE)
  • TOR: the proper code, depending on the process type
  • TOI: 11 – observation in process
  • Planned Transport Identifiers: TR ID, CR ID, PA ID
  • Free text field: the text of the Observation

Result

The Observation is saved in PCS in the comment area.

Notifications

All involved agencies shall be informed that an Observation was made to one of the sub-paths; thus, PCS will send a Path Coordination Message without Train Information and Path Information having there the following content.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any involved agency
  • TOR: the proper code, depending on the process type
  • TOI: 11 – observation in process
  • Planned Transport Identifiers: TR ID, CR ID, PA ID
  • Free text field: the text of the Observation

Release Post-processing as leading Applicant (Implemented)

The aim of this use case is to show, how the leading Applicant can promote the dossier to Post-processing. This can happen by an automatic promotion of PCS on a timetable deadline too. In that case, everything works the same way, but there is no need for the sent information by the leading Applicant.

Sent information

The leading Applicant who would like to promote the dossier to Post-processing, shall send a Path Coordination Message without Train Information and Path Information having there the following content.

  • Message header:
    • Sender: company code of any leading Applicant
    • Recipient: 3178 (RNE)
  • TOR: the proper code, depending on the process type
  • TOI: 12 – observation complete
  • Planned Transport Identifiers: TR ID, CR ID

Result

The dossier is promoted to Post-processing.

Notifications

All involved agencies shall be informed about the dossier promotion; thus, PCS will send a Path Coordination Message without Train Information and Path Information having there the following content.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any involved agency
  • TOR: the proper code, depending on the process type
  • TOI: 12 – observation complete
  • Planned Transport Identifiers: TR ID, CR ID

Withdraw dossier as leading Applicant

The aim of this use case to show, how a leading Applicant can withdraw a dossier. It’s possible for them only in Path Request and Path Elaboration phases.

Sent information

The leading Applicant who would like to withdraw a dossier in PCS, shall send a Path Coordination Message without Train Information and Path Information having there the following information.

  • Message header:
    • Sender: company code of the leading Applicant
    • Recipient: 3178 (RNE)
  • TOR: the proper code, depending on the process type
  • TOI: 29 - withdrawal
  • Planned Transport Identifiers: TR ID, CR ID
  • Free text field on the message level: reason of the withdrawal

Result

The dossier is withdrawn by the leading Applicant and it goes back to Harmonization status. Also, the reason of the withdrawal is saved to the comment area of the dossier.

Notifications

All agencies shall be informed about the withdrawal; thus, PCS will send a Path Coordination Message without Train Information and Path Information having there the following information.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: company code of any involved agencies
  • TOR: the proper code, depending on the process type
  • TOI: 29 - withdrawal
  • Planned Transport Identifiers: TR ID, CR ID
  • Free text field on the message level: reason of the rejection

 

File