PCS TAF-TSI Communication Guide

Content

Introduction

The aim of this document is to provide a guide for IMs/ABs who would like to synchronize their timetables with PCS from the national systems. It does not cover the whole RU – IM communication, because of the focus on the PCS – IM communication as a special dialect of the TAF-TSI communication.

You can see later that for the PCS communication the following messages shall be integrated:

  • Path Request Message, because PCS will deliver the path requests to the IMs with Path Request messages.
  • Path Details Message, because IMs can send all of their offers to PCS with Path Details message
  • Error Message, because if there is any mistake regarding the 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 rejection of the Final Offer to IMs with this message
  • Path Coordination Message, because IMs can send all of their updates before the offer with Path Coordination message. Also, all notifications from PCS (except RU originated) are sent via Path Coordination message
  • Path Not Available Message, because IMs need an option to delete an existing path in PCS. They can do it with this message

As you can see, the Receipt Confirmation message is not mentioned in the list. For PCS communication it’s not necessary. It’s important to state that PCS is a synchronous system, meaning there is no option for waiting for a message for minutes, hours or sometimes even days. For further details, please check the special use case that deals with the Receipt Confirmation message.

In this first version of the document, the focus is on a tailor-made dossier, but in later versions, we try to predict solutions for RFC related business too (not covered yet in TAF TSI).

Abbreviations

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 3 different basic types of the processes in the planning: Study (1), Request (2), Modification (3). As PCS supports other process types too and the TAF-TSI communication shall be utilized for them as well, the extension of the code list might be necessary. Proposal: 1 Path Study, 2 Ad-Hoc Path Request, 3 Path Modification/Alteration, 4 Ad-Hoc Path Request (pre-accepted), 5 Annual Path Request, 6 Late Path Request, 7 Rolling Planning Path Request. This is not yet discussed with the TEGs. Further on this document will focus on the TOR 3 - Ad-Hoc Path Request.

MS – Message status: Assigned by the Sender 1=creation, 2=modification, 3=deletion

Identifiers in PCS

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.

When the user creates the path requests 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.

What happens, when the user doesn’t provide the Train ID?

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.

Disclaimer: the implementation regarding Train ID is based on the current description of TAF TSI. Please note that it might be changed after the Train Object Modelling project of FTE.

Path Request ID/PA 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.

What happens, when the user doesn’t provide the PR ID/PA ID?

It can happen quite easily. Basically, it is the case for all the GUI users. PCS follows the same logic as for the Train ID, but now not the dossier ID will be inserted to the core element, but the PCS path ID, which is an internal PCS identifier. Company codes are entered with the same logic as for the Train ID, but the variants here are always 00. Example: PA - 3032 - ******488078 - 00 - 2020. We may check it more details in the Path Request paragraph.

For IMs, it’s important to store all the IDs you receive, because you should send them back. Also, please note that as you can see, the system is able to handle your own, national identifiers.

Network-Specific Parameters vs. National IM 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

  • Dossier level: in TAF TSI this would mean message level network-specific parameter
    • Example in PCS XML schema:

<processtype_id>H</processtype_id>

<national_im_parameter id="78118">

<name>D01 - Vertriebskanal</name>

<value>PCS</value>

</national_im_parameter>

  • Example in TAF TSI XML schema:

</ns1:PathInformation>

 <ns1:NetworkSpecificParameter>

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

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

</ns1:NetworkSpecificParameter>

</ns1:PathCoordinationMessage>

 

  • Path section level: in TAF TSI this would mean planned journey location level network-specific parameter

Both are working with a name/value pair. 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.

Possible formats in PCS:

  • String
    • Min numbers of characters >=1
    • Max number of characters <=256
  • Single choice list
  • Multiple choice list
  • 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

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 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 TAF TSI generator and there the locos are stored in this format, but as they are stored originally in PCS, not all the options are supported. The main difference is the Type Code 2 because PCS stores that information in three fields and can generate the code based on their combination:

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

Country code is originated from the IM’s UIC ID that published the loco type.

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.

Example description

It’s easier to demonstrate the different use cases on a live example.

The example shows a PCS dossier (216481) that contains two trains (one core element with two variants). The example itself is a 2RU - 2IM situation with ÖBB (0081) - RCA (2181), VPE (3032) - GYSEV-C (2143) pairs. The leading agencies are in the second pair.

The reason for the two trains is the two different destinations in Hungary (please check the outline below). The trains are split according to weekdays (1-5) and weekends (6-7).

RCA splits its path requests according to the trains. However, GYSEV-C has two path requests for the second train variant, one for Saturdays (6) and one for Sundays (7).

ÖBB prepares one-one paths as an offer to the received path requests. VPE sends two paths for the weekdays; one for the summer period and for the rest. However, the requests for the weekends cannot be met, that is why they send offers only for Saturdays.

The example tries to demonstrate also the actions when a partner finished already the harmonization (set green light in PCS), however, the neighbor changes something at the border. In this case, PCS (the application itself) automatically downgrades the harmonization status of the partner.

Objects

The following objects will be used during the example.

For the demonstration purpose different kind of concepts are used for the identifier generation:

  • RCA prepares the different path requests with the same core element and utilizes the variants to make differentiation
  • GYSEV-C generates always fully random (but unique) core elements for the Path Requests and leaves the variant 00.
  • ÖBB, similar to RCA, prepares the different paths with the same core element and utilizes the variants to make differentiation
  • VPE, similar to GYSEV-C, generates always fully random (but unique) core elements for the paths and leaves the variant 00.

Use case overview

Before jumping into the details, please find here an overview of the use cases that we tried to cover with this example.

Path Request

  1. Get information about Path Requests
  2. Pre-accepted Offer

Path Elaboration and Post-Processing

  1. Timetable updates as work in progress
  2. IM would like to delete a path from PCS
  3. Setting green light in PCS and informing the partner IMs
  4. Sending an update affecting the border
  5. Offer (draft or final) is sent to the Applicants
  6. Setting red light in PCS and informing the partner IMs
  7. Rejecting dossier in PCS
  8. Sending an update that contains calendar days of existing paths
  9. Leading applicant withdraws the dossier
  10. Leading IM closes the dossier

Observations and Acceptance

  1. IM gets back the dossier from Observations
  2. Leading applicant closes the dossier
  3. Applicant’s decision in the Acceptance phase

Active Timetable

  1. Close dossier

Receipt Confirmation and Error message

  1. The necessity of Receipt Confirmation
  2. Error Message from PCS
  3. Error Message to PCS

Path Modification/Path Alteration

Path Request

Applicants have already finished their harmonization and they submitted path requests in PCS. Let’s check what happens in the different process types:

  • New Path Request: dossier arrives at Path Request phase
  • Late Path Request: dossier arrives at Path Elaboration phase
  • Ad-Hoc Path Request (currently supported via TAF-TSI connection): dossier arrives at Path Elaboration phase
  • Ad-Hoc Path Request (pre-accepted): dossier arrives at Path Elaboration phase
  • Rolling Planning Path Request: dossier arrives at Path Elaboration phase

It’s clear that for most of the process types the “Path Request” is only a milestone. The exception is the New Path Request where the leading IM has to release the dossier to Path Elaboration (change request is pending to change this too). To do that the Leading IM can send Path Coordination to PCS with TOI 07 (create offer). In this case, the message has the following elements:

  • Message header:
    • Sender: 3032 (VPE as leading IM)
    • Recipient: 3178 (RNE)
  • TOR: 2 – Request
  • MS: 1 – Creation
  • TOI: 07 – Create offer
  • Identifiers: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020

It’s enough to have one message with one path. It doesn’t matter how many paths are existing, because the IM makes its actions on the dossier or on the dossier Applicant – IM pair.

What happens in PCS?

It’s more important to note what happens in PCS when the leading Applicant sends the dossier to path request. PCS copies the Applicant timetable to an IM timetable block.

In our example there are five path requests (2+3), which are represented with sub-paths in PCS:

  • ÖBB receives PR - 2181 - ********ABCD - 00 - 2020; PR - 2181 - ********ABCD - 01 - 2020
  • VPE receives PR - 2143 - *******X12C3 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PR - 2143 - *******SDF53 - 00 - 2020

As part of the copy of the timetables, PCS creates five sub-paths in the IM timetable. However, as the TAF TSI identifiers are mandatory and there was no IM activity so far in the dossier, it copies the identifiers from the path requests:

  • ÖBB: PA - 2181 - ********ABCD - 00 - 2020; PA - 2181 - ********ABCD - 01 - 2020
  • VPE: PA - 2143 - *******X12C3 - 00 - 2020; PA - 2143 - *******98A01 - 00 - 2020; PA - 2143 - *******SDF53 - 00 - 2020

When an IM doesn’t have an interface connection, the GUI user can start working on these paths immediately. However, if the IM has a connection, the first moment when they start sending their own IDs, PCS will update the identifier in the sub-path according to the national identifier. When an IM sends either Path Coordination message or Path Details message, it contains the PR ID as requested and the PA ID as the answer. This is the basis for PCS to update the sub-paths. In the moment of Path Request, PCS will have the identifiers in the following way:

 

 Applicant TTIM TT
PCS Path ID412002412005
Object typePRPA
TSI Path ID*******X12C3*******X12C3
Variant0000
TTP20202020
Company code21432143

 

When VPE sends a Path Coordination message with the following IDs: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M20205405120- 00 - 2020; PCS will now that the PA - 2143 - *******X12C3 - 00 - 2020 sub-path shall be replaced with the freshly received PA - 3032 – M20205405120- 00 - 2020 path information. This option is valid until the first update, after that, when the IM sends with IDs that are already known by PCS, PCS will update the paths accordingly, because the system knows the ID pairs, e.g.:

PCS path ID 412005 = VPE path PA - 3032 – M20205405120 - 00 - 2020

When an IM sends a new ID for any kind of path request, PCS will create a new sub-path.

Update of IDs Use case

When the Applicant doesn't create its own identifiers, PCS generates the PR and PA IDs based on the PCS Path IDs. In that case, the IM can get the following IDs: PR-******412002-00-2020; PA-******412005-00-2020. If the IM would like to use its own IDs from the national system, it should delete the existing path with ID PA-******412005-00-2020 and send a new path with the national ID. To avoid this workaround, there shall be a new TypeOfInformation in the message, where the IM can indicate that the message is for an existing object, and it would like to update the identifier. Without deleting and creating a new path.

Get information about Path Requests

We already saw what happens in PCS, but how does the IM get information that path requests arrived? In this case, PCS broadcasts Path Request messages to the affected IMs as the following.

To ÖBB two messages will be sent.

  • Message header:
    • Sender: 2181 (RCA)
    • Recipient: 0081 (ÖBB)
    • Broker: 3178 (RNE) with PCS LI number
  • TOR: 2 – Request
  • MS: 1 – Creation
  • TOI: 4 – Harmonization completed
  • Identifiers:
    • First message:  CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2181 - ********ABCD - 00 - 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2181 - ********ABCD - 01 – 2020

To VPE three messages will be sent.

  • Message header:
    • Sender: 2143 (GYSEVC)
    • Recipient: 3032 (VPE)
    • Broker: 3178 (RNE) with PCS LI number
  • TOR: 2 – Request
  • MS: 1 – Creation
  • TOI: 4 – Harmonization completed
  • Identifiers:
    • First message:  CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020
    • Third message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******SDF53 - 00 - 2020

The content of the messages is trivial. They get Train Information and Path Information. It’s up to them, whether they use the Train Information element, but the Path Information shall be imported to their system. Until the Train Information is not defined precisely according to FTE's Train Object Modelling project, in case of PCS, the Train Information will contain the copy of the Path Information element of the particular message.

As said before, all the IDs shall be stored, because they must be used later when the IM provides an answer. Just as a reminder, the IM cannot answer two path requests with one path.

According to the concept of PCS, each party shall be aware of the others' requested/offered content. To serve this need, apart from the above written official Path Request messages, PCS will send to everyone Path Coordination messages with the path requests in the other territories. This is the part of PCS' agency notification. An IM can decide, whether he stores this information or drops it away. An IM can identify that this action is only additional information about the path requests because the TOI is 4 - Harmonization completed and there is no PA ID in the messages. Further notifications about the IMs' update will be sent in similar way (you will see that later), but PA ID will be defined.

To ÖBB three additional Path Coordination messages will be sent:

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: 0081 (ÖBB)
  • TOR: 2 – Request
  • MS: 1 – Creation
  • TOI: 4 – Harmonization completed
  • Identifiers:
    • First message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020
    • Third message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020

To VPE two additional Path Coordination messages will be sent:

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: 3032 (VPE)
  • TOR: 2 – Request
  • MS: 1 – Creation
  • TOI: 4 – Harmonization completed
  • Identifiers:
    • First message:  CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2181 - ********ABCD - 00 - 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2181 - ********ABCD - 01 – 2020

Pre-accepted Offer

Until the further TOR elements are not agreed, this solution is not yet available, or only via Shared Metadata

PCS is able to handle Ad-Hoc path requests with a pre-accepted offer; however, it’s handled with a special process type. Right at the beginning of the dossier creation, the leading Applicant shall select the Ad-Hoc path request process with a pre-accepted offer. Due to the different process type, a different TOR shall be used.

In this case, the IMs get this information with the Path Request messages. For example, ÖBB would get two messages with the following information.

  • Message header:
    • Sender: 2181 (RCA)
    • Recipient: 0081 (ÖBB)
    • Broker: 3178 (RNE) with PCS LI number
  • TOR: TBD, e.g. 4 - Ad-Hoc Path Request (pre-accepted)
  • MS: 1 – Creation
  • TOI: 4 – Harmonization completed
  • Identifiers:
    • First message:  CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2181 - ********ABCD - 00 – 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2181 - ********ABCD - 01 – 2020

Path Elaboration and Post-Processing

The below written use cases are valid basically for Path Elaboration and Post-Processing, but most of them can be used in any phase where the IMs have editing rights, e.g. Feasibility Study Elaboration, Path Modification Elaboration, Path Alteration Conference.

Timetable updates as work in progress

In this step, the IMs are updating their timetable in PCS. In this example, it will be demonstrated with VPE. As presented in the Objects part, VPE has three paths to offer. To do so, VPE shall send three Path Coordination message like the following. Please note that as we wrote previously, even though VPE will send three paths, it doesn’t mean they send one for each path request. They could not make the Sundays, but they send different offers for the weekdays.

Three Path Coordination messages with:

  • Message header:
    • Sender: 3032 (VPE)
    • Recipient: 3178 (RNE)
  • TOR: 2 – Request
  • MS: 1 – Creation
  • TOI: 2 – Harmonization in process
  • Identifiers:
    • First message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M20205405120- 00 - 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M202054092*0- 00 - 2020
    • Third message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020

This mechanism can be used either for creating new paths in PCS or updating an existing one. With this action the IM can create or update the timetable, parameters or calendar of the path. If a location is not mentioned in the path that was part before, PCS will interpret as a delete. For calendar changes the IM shall send only a new calendar bitfield with the message. For each sent Path Coordination message, PCS will send back either RC or Error Message depending on the success of the update.

As part of the notification service, PCS will send (forward) these messages to ÖBB (or all other involved IM of the dossier, if there are more) as Path Coordination messages like the following.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: 0081 (ÖBB)
  • TOR: 2 – Request
  • MS: 1 – Creation
  • TOI: 2 – Harmonization in process
  • Identifiers:
    • First message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M20205405120- 00 - 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M202054092*0- 00 - 2020
    • Third message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020

IM would like to delete a path from PCS

Normally, with PCS web-services this action is quite simple. The IM can use the updateDossierRUIMPair operation and it should not mention the particular paths. PCS will interpret this action as a delete. In TAF TSI, the messages are sent path by path, meaning there is a need for a dedicated message to cancel a path in PCS.

The IM can rely on the Path Not Available message with the following content.

  • Message header:
    • Sender: 3032 (VPE)
    • Recipient: 3178 (RNE)
  • TOR: 2- Request
  • MS: 1 – Creation
  • TOI: 32 - path cancelled full
  • Identifiers: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020

With this action VPE would delete PA - 3032 – M202062114312- 00 – 2020 from the dossier. PCS will send back either RC or Error Message depending on the success of the update.

As part of the notification service, PCS will send (forward) these messages to ÖBB as Path Not Available message as the following.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: 0081 (ÖBB)
  • TOR: 2- Request
  • MS: 1 – Creation
  • TOI: 32 - path cancelled full
  • Identifiers: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020

Setting green light in PCS and informing the partner IM about it

Changing the harmonization status is important in PCS and TAF TSI either. There is a slight difference that in PCS the harmonization status (the so-called acceptance indicators) are set on the pair level and not on the path level. Meaning, it’s enough to send only one of the paths with its identifier. It saves communication on the IM side but also needs an adaptation. Be careful that until you are not done with your paths, don’t send this message to PCS, because it will set your light to green for all included paths of yours.

Setting the green light is one thing, but PCS will inform your partners about this action. That is why they can expect message broadcasting from PCS on behalf of you. Let’s see an example, when VPE would set a green light in the dossier and PCS would inform ÖBB about this action.

VPE shall send one Path Coordination message.

  • Message header:
    • Sender: 3032 (VPE)
    • Broker: 3178 (RNE)
  • TOR: 2 - Request
  • MS: 1 – Creation
  • TOI: 04 – Harmonization completed
  • Identifiers: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020

PCS will send back either RC or Error Message depending on the success of the update.

ÖBB will get three Path Coordination messages.

  • Message header:
    • Sender: 3178 (RNE)
    • Broker: 0081 (ÖBB)
  • TOR: 2 - Request
  • MS: 1 – Creation
  • TOI: 4 – Harmonization completed
  • Identifiers:
    • First message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M20205405120- 00 - 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M202054092*0- 00 - 2020
    • Third message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020

Sending an update affecting the border

How to send an update is covered in one of the previous use cases. We know how to do that; however, it was not yet mentioned, what happens in PCS when an IM sends an update that changes something on the border from the following element:

  • Timetable
  • Dwell time
  • Calendar
  • Location

PCS, the application itself, checks this action, and by design, it downgrades the green light of the affected IM to yellow. It must be communicated via TAF TSI messages too. PCS will send all the paths of the initiator IM to the affected IM. It can check then the impact, and if there is nothing else to do, it can set a green light again as explained in another use case.

Let’s take our example. ÖBB sends an update that changes something at Nickelsdorf grenze, the border location. The sent message looks like as it’s described in the “Timetable updates as work in progress” step.

VPE receives two Path Coordination messages from PCS regarding the ÖBB paths.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: 3032 (VPE)
  • TOR: 2 - Request
  • MS: 1 – Creation
  • TOI: it doesn't really matter. The important is that it affects the border when VPE's lights were already green. E.g. it can be 4 – Harmonization completed.
  • Identifiers:
    • First message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2181 - *********ABCD - 00 - 2020; PA - 0081 – **M-AMA12345- 00 - 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2181 - *********ABCD - 01 - 2020; PA - 0081 –**M-AMA12345- 01 – 2020

Then, VPE receives three further Path Coordination messages from PCS regarding his paths too, because the lights were downgraded to yellow.

  • Message header:
    • Sender: 3178 (RNE)
    • Broker: 3032 (VPE)
  • TOR: 2 - Request
  • MS: 1 – Creation
  • TOI: 2 – Harmonization in process
  • Identifiers:
    • First message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M20205405120- 00 - 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M202054092*0- 00 - 2020
    • Third message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020

As you can see, the notification works pretty much the same as for the “Timetable updates as work in progress” use case, however, it’s important that VPE is aware of the fact, its light was downgraded to yellow. That is why he gets back his paths too with yellow light.

Offer (draft or final) is sent to the Applicants

It’s a privilege of the leading IM to send out Draft Offer and Final Offer. However, as we are using PCS in this example, it’s also possible to rely on PCS’ automatic promotions. Regarding the New Path Request process, when all the IM lights are green, it promotes the dossier to Draft Offer and Final Offer on the deadline according to the RNE timetabling calendar. For Late Path Request and Ad-Hoc Path Request process it checks also the timetabling calendar first (for LPR we have to be after the NPR deadlines) and it promotes the dossiers that are ready, every midnight.

The Applicants will receive the Path Details messages with the proper information. If that’s the case, PCS shall only send the notification to the IMs that Draft Offer or Final Offer was sent out.

Please note that Draft Offer is used only in New Path Request and Rolling Planning processes. For the others, the Final Offer is used only and those are followed by the Acceptance phase.

IMs will get back Path Coordination messages about their paths.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: 3032 (VPE)
  • TOR: 2 – Request
  • MS: 1 – Creation
  • TOI: 09 – draft offer or 16 – final offer

If the leading IM insists to do this action alone, not relying on PCS, it can send also one Path Details message (we talked already about the difference between dossier and paths) with the proper type of information. In our example, VPE should send the following Path Details message.

  • Message header:
    • Sender: 3032 (VPE)
    • Recipient: 2143 (GYSEV-C)
    • Broker: 3178 (RNE) with PCS LI number
  • TOR: 2 – Request
  • MS: 1 – Creation
  • TOI: 09 – draft offer or 16 – final offer
  • Identifier: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020

As it’s a change, affecting the whole the dossier, the same notification will be sent out by PCS to the participating IMs as above, plus PCS will send back either RC or Error Message depending on the success of the update.

Setting red light in PCS and informing the partner IM about it

From the PCS point of view, there is not such a big difference between setting green or setting red light in the system. The procedure is quite similar to the other use case. It’s enough to send one Path Coordination message with the proper information. There is only one additional thing: PCS requires a mandatory comment for the reason of the rejection. This must be pasted to the Path Coordination message, into its free text field on the message level.

If VPE likes to set a red light, the following Path Coordination message should be sent.

  • Message header:
    • Sender: 3032 (VPE)
    • Recipient: 3178 (RNE)
  • TOR: 2 - Request
  • MS: 1 – Creation
  • TOI: 03 – Harmonization rejected
  • Identifiers: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020

PCS will send back either RC or Error Message depending on the success of the update. Again, same as for the green light, ÖBB will be informed about this change by PCS.

ÖBB will get three Path Coordination messages, with the same free text field delivering the reason for rejection.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: 0081 (ÖBB)
  • TOR: 2 - Request
  • MS: 1 – Creation
  • TOI: 03 – Harmonization rejected
  • Identifiers:
    • First message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M20205405120- 00 - 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M202054092*0- 00 – 2020
    • Third message: TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020

Rejecting dossier in PCS

Until the further TOR elements are not agreed, this solution is available only for Ad-Hoc Path Request process, or only via Shared Metadata

Leading IM has the chance to reject a dossier. The procedure is almost the same for all process types, only the TOI is different. In New Path Request process and Rolling Planning Process we have Draft Offer, but in the others, we only have Final Offer. This is the main difference.

In the New Path Request and Rolling Planning process, the leading IM (VPE in our example) shall send one Path Coordination message like the following.

  • Message header:
    • Sender: 3032 (VPE)
    • Recipient: 3178 (RNE)
  • TOR: TBD, e.g. 5 - Annual path request or 7 - Rolling Planning
  • MS: 1 – Creation
  • TOI: 43 – Preparation of draft offer rejected
  • Identifiers: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020[1]

In Late Path Request and Ad-Hoc Path Request process, the leading IM (VPE in our example) shall send one Path Coordination message as the following.

  • Message header:
    • Sender: 3032 (VPE)
    • Recipient: 3178 (RNE)
  • TOR: 2 - Request or TBD. e.g 6 - Late Path request
  • MS: 1 – Creation
  • TOI: 15 – Preparation of final offer rejected
  • Identifiers: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 20201

PCS will send back either RC or Error Message depending on the success of the update.

As part of the PCS notification service, the system shall broadcast this information. Thus, ÖBB will get two Path Coordination messages for its two paths (because the whole dossier was rejected by the leading IM).

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: 0081 (ÖBB)
  • TOR: 2 – Request
  • TOI: 43 – Preparation of draft offer rejected/15 – Preparation of final offer rejected (depending on the process type)
  • Identifiers:
    • First message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2181 - *********ABCD - 00 - 2020; PA - 0081 – **M-AMA12345- 00 – 20201
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2181 - *********ABCD - 01 - 2020; PA - 0081 –**M-AMA12345- 01 – 20201
 

[1] PA can be sent only if it’s known. As it’s a rejection, it could be that it’s rejected immediately, before the IMs sent any of their own PA(s) to PCS.

Sending update that contains calendar days of existing paths

It was already described how to send updates to existing paths. However, there is a special use case, when an IM sends an update that affects the already existing paths in the system that are not in the message. What are we talking about?

Imagine a situation where you have two paths in PCS:

  • First runs on 1-5
  • Second runs on 6-7

Then the IM sends Path Coordination message with a new path for running days 5-6. PCS, as the application itself, is avoiding double booking on the running days. Calendar days are working as a switch by design. Even if the update arrives via an interface, this switch works, and PCS removes the selected days from the other calendars. As previously mentioned, the change in the dossier will result in Path Coordination messages to the participating IMs about the change. Why is it then so special? Because, in this special case, the notification service is sent to the initiator IM too. He will also get the message(s) about the changed path(s). In this special case, he will get two Path Coordination messages with their identifiers and the changed calendars.

Demonstration:

  • VPE sends Path Coordination with a brand new sub-path for 5-6
  • PCS will send back either RC or Error Message depending on the success of the update. Let's assume it was successful
  • ÖBB gets all the VPE paths as part of the notification service
  • EXTRA: VPE gets also all of his paths because PCS did an update on at least one VPE object.

Leading applicant withdraws the dossier

Until the end of Path Elaboration, the leading Applicant has the chance to withdraw the dossier. As always, it has to put there a mandatory reason to explain this action (similar to the rejection).

In our example, GYSEV-C is the leading Applicant. If they decide to withdraw the dossier, every participating IM shall get this information. PCS will send the information to the IMs on behalf of their partner Applicants (sender). Let’s check this from VPE point of view. They will get three Path Request messages.

  • Message header:
    • Sender: 2143 (GYSEV-C)
    • Recipient: 3032 (VPE)
    • Broker: 3178 (RNE)
  • TOR: 2 - Request
  • MS: 2 – Delete
  • TOI: 29 - withdrawal
  • Identifiers:
    • First message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M20205405120- 00 - 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M202054092*0- 00 – 2020
    • Third message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020

The same is happening between RCA and ÖBB, regardless that GYSEV-C is the leading, because the partner of ÖBB is RCA.

Leading IM closes the dossier

If it becomes clear, for any reason, that there is no further need for a dossier, the leading IM has the chance to close it. This option is available for them in Path Elaboration, Post-Processing and also later in Active Timetable.

In our case, VPE is the leading IM. It’s enough for them to send only one Path Coordination message with a mandatory comment in the free text field like the following.

  • Message header:
    • Sender: 3032 (VPE)
    • Recipient: 3178 (RNE)
  • TOR: 2 - Request
  • MS: 1 – Creation
  • TOI: 31 – Close dossier
  • Identifiers: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M20205405120- 00 - 2020

PCS will send back either RC or Error Message depending on the success of the update. As part of the PCS notification service, the system shall broadcast this information. Thus, ÖBB will get two Path Coordination messages for its two paths.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: 0081 (ÖBB)
  • TOR: 2 – Request
  • TOI: 31 – Close dossier
  • Identifiers:
    • First message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2181 - *********ABCD - 00 - 2020; PA - 0081 – **M-AMA12345- 00 - 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2181 - *********ABCD - 01 - 2020; PA - 0081 –**M-AMA12345- 01 - 2020

Observations and Acceptance

IM gets back the dossier from Observations

Observations phase is available only in New Path Request and Rolling Planning processes. In this phase the Applicants have max. 4 weeks to analyse the Draft Offer and provide feedback. Please note that in PCS they can only make comments in a standardized way to the paths they are concerned about.

Then, the dossier is moved to the Post-Processing phase either by the leading Applicant or by PCS’ automatic promotion.

If you check it carefully, it means multiple notifications:

  • When the Applicant makes a comment to a path (optional for them, not sure you get a notification for this)
  • When the dossier reaches Post-Processing, meaning IMs can edit it again

Let’s see what kind of messages would be sent by PCS in these situations.

GYSEV-C made an Observation on a path (as part of the Observations, the Applicant can select in PCS to which path they enter the observation) and VPE gets a Path Request message.

  • Message header:
    • Sender: 2143 (GYSEV-C)
    • Recipient: 3032 (VPE)
    • Broker: 3178 (RNE)
  • TOR: 2 – Request
  • MS: 1 – Creation
  • TOI: 12 – observation - complete
  • Identifiers: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M20205405120- 00 – 2020

The Observation itself is delivered in the free text field of the Path Request message on the message level. It happens only when a path is commented by an Applicant and this message is sent only to the affected IM.

When the dossier arrives at Post-Processing, each participating IM shall get this information. That is why PCS will send out Path Coordination message to all IMs with their paths. Let’s check it from VPE’s point of view. They will get three Path Coordination messages.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: 3032 (VPE)
  • TOR: 2 - Request
  • MS: 1 – Creation
  • TOI: 07 – Create offer
  • Identifiers:
    • First message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M20205405120- 00 - 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M202054092*0- 00 – 2020
    • Third message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020

Leading Applicant closes the dossier

PCS provides the possibility for the leading Applicant in Observations phase to close the dossier. In this case, the dossier will not go back to the IMs in Post-Processing phase.

In our example, GYSEV-C is the leading Applicant. If they decide to close to the dossier, every participating IM shall get this information. PCS will send the information to the IMs on behalf of their partner Applicants (sender). Let’s check this from VPE point of view. They will get three Path Coordination messages.

  • Message header:
    • Sender: 317RNE
    • Recipient: 3032 (VPE)
  • TOR: 2 - Request
  • MS: 1 – Creation
  • TOI: 31 – Close dossier
  • Identifiers:
    • First message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M20205405120- 00 - 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M202054092*0- 00 – 2020
    • Third message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020

Applicants’ decision in Acceptance phase

In Late Path Request and Ad-Hoc path request processes the applicants can make several decisions after the first offer from the IMs:

  • Accept the offer: in PCS, this would move the dossier to Active Timetable
  • Reject the dossier: in PCS, this would move the dossier to Closed
  • Send back to Path Elaboration

IM will get Path Confirmed messages, if the Applicants accepted the Final Offer.

  • Message header:
    • Sender: 2143 (GYSEV-C)
    • Recipient: 3032 (VPE)
    • Broker: 3178 (RNE)
  • MS: 1 – Creation
  • TOI: 17 – final offer accepted
  • Identifiers:
    • First message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M20205405120- 00 - 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M202054092*0- 00 – 2020
    • Third message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020

Please note that compared to the other messages, in Path Confirmed message, the following elements are not required:

  • Type of request
  • Path Information

IM will get Path Details Refused messages, if the Applicants rejected the Final Offer.

  • Message header:
    • Sender: 2143 (GYSEV-C)
    • Recipient: 3032 (VPE)
    • Broker: 3178 (RNE)
  • MS: 1 – Creation
  • TOI: 25 – offer/final offer rejected (without revision)
  • Identifiers:
    • First message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M20205405120- 00 - 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M202054092*0- 00 – 2020
    • Third message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020

Please note that compared to the other messages, in Path Confirmed message, the following elements are not required:

  • Type of request
  • Path Information

IM will get Path Details Refused messages with special TOI, if the Applicants return the dossier to Path Elaboration.

  • Message header:
    • Sender: 2143 (GYSEV-C)
    • Recipient: 3032 (VPE)
    • Broker: 3178 (RNE)
  • MS: 1 – Creation
  • TOI: 27 – offer/final offer rejected (revision required)
  • Identifiers:
    • First message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M20205405120- 00 - 2020
    • Second message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******X12C3 - 00 - 2020; PA - 3032 – M202054092*0- 00 – 2020
    • Third message: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******98A01 - 00 - 2020; PA - 3032 – M202062114312- 00 – 2020

Please note that compared to the other messages, in Path Details Refused message, the following elements are not required:

  • Type of request
  • Path Information

Active Timetable

Close dossier

In Active timetable either the leading Applicant or the leading IM has the chance to close the dossier. The procedure works exactly the same as it is written in the former close dossier use cases.

Receipt Confirmation and Error message

The necessity of Receipt Confirmation

As said before, PCS works as a synchronous system, that is why the Receipt Confirmation message is not required.

By default, when a dossier arrives first at an IM phase, the IM’s acceptance indicators are blue. This is changed to yellow whenever there is an update from the IM.

For the time being, PCS does not require RC, thus please don’t send them when you are communicating with PCS.

Error Message from PCS

The integration of the Error Message is rather important. PCS has its own errors (link) and it would send back to the IMs in the standard Error Message. For example, VPE would try to send an update with an unknown traction mode, PCS would send back the following message.

  • Message header:
    • Sender: 3178 (RNE)
    • Recipient: 3032 (VPE)
  • MS: 1 – Creation
  • TypeOfError: 1 – Functional (except 501, when it’s PCS system error, then it’s 2 – Technical)
  • Severity: 2 – Fatal
  • ErrorCode: 281 – Unknown traction mode
  • FreeTextField:  Error code description, e.g. The request contains traction mode which can’t be resolved in the system.

Error Message to PCS

Same as for the Receipt Confirmation, we don’t support this.

Path Modification

To demonstrate the communication for Path Modification, we will use the same example. The pre-condition for the PM process is that the dossier is in Active Timetable. Similar to the request process, we collected the use cases before the details.

Path Modification Request

  1. Get information about Path Modification Request
  2. Release to Path Modification Elaboration

Path Modification Elaboration

  1. Send no alternative available as an answer
  2. Update path in PCS
  3. Update a path with affecting border section
  4. Sending offer
  5. The applicant withdraws the Path Modification request
  6. Set light in PCS

Path Modification Offer

  1. Get information about the acceptance of the offer

Get information about Path Modification Request

GYSEV-C would like to make a modification on an already allocated path. Thus, it sends a request to modify a path to VPE. The message includes the PA ID that should be modified and a new PR ID.

  • Message header:
    • Sender: 2143 (GYSEVC)
    • Recipient: 3032 (VPE)
    • Broker: 3178 (RNE) with PCS LI number
  • TOR: 3 – Modification
  • MS: 1 – Creation
  • TOI: 4 – Harmonization completed
  • Identifiers: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******RT234 - 00 - 2020; PA - 3032 – M20205405120- 00 - 2020

As before, we consider the Path Information block trivial. However, here we must clarify an issue with the calendar. As in PCS, also in TAF, the Applicant has a chance to make an adjustment to an existing path or replace completely the path. The difference in the Applicants' side that they will get messages for each "live" path.

Release Path Modification Elaboration

If the Path Modification was initiated for a Late Path Request dossier, the leading IM shall release the dossier to Path Modification Elaboration. It can be done in the same way as in the general New Path Request process.

Path Coordination message:

  • Message header:
    • Sender: 3032 (VPE as leading IM)
    • Recipient: 3178 (RNE)
  • TOR: 3 – Modification
  • MS: 1 – Creation
  • TOI: 07 – Create offer
  • Identifiers: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******RT234 - 00 - 2020; PA - 3032 – M20206123512- 00 - 2020

Until the change does not affect any border area, the modification stays bilateral and the other IMs shall not be notified. Please check the separated use case, where an update affects a border section. Then, the usual acceptance indicator downgrade procedure applies.

Send no alternative available as answer

Similar to TAF-TSI, the IM has this option in PCS too. If modification is not feasible, the IM in pair with the initiator Applicant has the right to reject path modification.

Path Not Available message:

  • Message header:
    • Sender: 3032 (VPE)
    • Recipient: 2143 (GYSEV-C)
    • Broker: 3178 (RNE)
  • TOR: 3 – Modification
  • MS: 1 – Creation
  • TOI: 21 - no alternative available
  • Identifiers: CR - 3178 - ******216481 - 00 - 2020; TR - 2143 - *********927 - 00 - 2020; PR - 2143 - *******RT234 - 00 - 2020; PA - 3032 – M20206123512- 00 - 2020

Until the change does not affect any border area, the modification stays bilateral and the other IMs shall not be notified.

Path Alteration

To demonstrate the communication for Path Alteration, we will use the same example. The pre-condition for the PA process is that the dossier is in Active Timetable. Similar to the request process, we collected the use cases before the details.

Path Alteration Conference

  1. Initiate Path Alteration process
  2. Update path in PCS
  3. Update a path with affecting border section
  4. Sending offer
  5. Withdraw Path Alteration
  6. Set light in PCS

Path Alteration Offer

  1. Get information about the acceptance of the offer