Status of Train and Path Cardinality Train-Path Planning/TRID TEG, 07/05/2019 FTE, TrID WG, 08/05/2019 Christian Weber, SNCF Version 0.1 of 04/05/2019

TRAIN Cancelled (not kept) TRAIN Suspended (kept) Status of TRAIN and PATH : Usual Path Request TRAIN Created (not yet Path Request) TRAIN Cancelled (not kept) TRAIN TRAIN Suspended (kept) PathDetailsMessage TypeOfInfo=21 (no alternative available) PathDetailsMessage OnDemandPath=Desact. PathRequestMessage OnDemandPath=Act./Desact. PathDetailsMessage OnDemandPath=Act. Desactivated PATH PathSectionNotificationMessage TypeOfInfo = 50 (activate path) Activated PATH NO PATH AVAILABLE PathSectionNotificationMessage TypeOfInfo = 51 (desactivate path) The TRAIN is created (with a given calendar) and a PATH REQUEST is introduced (for an activated or desactivated path) A PATH is proposed (for the entire or partial calendar) and, at the end of the process, is accepted and booked If no PATH is available (for the entire or partial calendar), and if this statement is accepted by the RU, the TRAIN can be ‘Suspended’ by the RU (it is kept in the RU IT System waiting another opportunity to submit a PATH REQUEST that could happen or not) The RU can also decide to cancel the TRAIN of its RU IT System depending on its analysis The status ‘TRAIN Suspended’ or ‘TRAIN Cancelled’ is an internal RU process, there is no need to inform the IM as no PATH was allocated

Status of TRAIN and PATH : After Path allocation the links can be changed (1/2) First possibility : Use of the UpdateLinkMessage TRAIN Suspended (kept) TRAIN TRAIN Cancelled (not kept) UpdateLinkMessage Operation = B (break the link) Procedure = TNC (train not cancelled by default) or TC (train cancelled) Procedure = PK (path kept by default) or PNK (path not kept) Activate PATH Desactivate PATH PATH Cancelled Initial link PROS : All status of TRAIN (Suspended / Cancelled) and PATH (Kept as Desactivate / Cancelled) are possible by one message The link TRAIN-PATH is broken Applies on the complete or partial calendar and/or on the complete or partial section CONDITION : Case TC+PNK needs either a new code (e.g. TPC for ‘Train and Path Cancelled ’ or a change in the cardinality to allow 2 elements Procedure

Status of TRAIN and PATH : After Path allocation the links can be changed (2/2) Second possibility : Use of the PathSectionNotificationMessage TRAIN Suspended (kept) TRAIN TRAIN Cancelled (not kept) PathSectionNotificationMessage TypeOfInfo = 51 (desactivate path, train suspended, link kept) or 56 (link not kept) PathSectionNotificationMessage TypeOfInfo = 54 (cancel path, train suspended) If needed : UpdateLinkMessage Operation = B (break the link) PathSectionNotificationMessage TypeOfInfo = 55 (desactivate path, cancel train) PathSectionNotificationMessage TypeOfInfo = 53 (cancel path, cancel train) Desactivate PATH Activate PATH PATH Cancelled Initial link TRAIN and PATH are kept with TypeOfInfo = 51 (desactivate path) and the TRAIN is consequently suspended. The link TRAIN-PATH remains implicitly A UpdateLinkMessage is sent to break the link if necessary or create a code 56 (desactivate path, train suspended, link broken) TRAIN Suspended/Kept and PATH Cancelled needs a new code TypeOfInformation = 54 – Link TRAIN-PATH broken TRAIN Cancelled and PATH Desactivate/Kept needs a new code TypeOfInformation = 55 – Link TRAIN-PATH broken TRAIN Cancelled and PATH Cancelled needs a new code TypeOfInformation = 53 – Link TRAIN-PATH broken PROS : All status of TRAIN (Suspended / Cancelled) and PATH (Kept as Desactivate / Cancelled) are possible by one message The link TRAIN-PATH is broken Applies on the complete or partial calendar and/or on the complete or partial section CONDITION : Create new codes 53 to 56 for the element TypeOfInformation UpdateLinkMessage and PathSectionNotificationMessage are equivalent (with codes to create) - The use of both messages brings flexibility

Creation by the RU of TRAIN2 on BC identified with TRID2 Use of both messages brings flexibility : cardinality TRAIN-PATH EXAMPLE A train ABC identified by TRID1 receives a path ABC identified by PAID1. After allocation, the RU decides to use the path PAID1 as follows : TRID1 limited to AB on the first part of path PAID1; New train TRID2 on the second part BC of the path PAID1. What is the process to be followed ? Legend : objects linked TRID1 A B C PAID1 PathSectionNotificationMessage Identifiers = TRID1, PAID1 TypeOfInfo = 55 (desactivate path, train cancelled) AffectedSection = BC TRID1 A B C PAID1 PAID1 Creation by the RU of TRAIN2 on BC identified with TRID2 (TRAIN2 is compliant with the PATH on section BC) TRID2 B C UpdateLinkMessage Identifiers = TRID2, PAID1 Type = E (establish the link) TrainInformation/PlannedJourneyLocation = B, C with relevant data PathInformation/PlannedJourneyLocation = B, C TRID2 B C PAID1 TRID1 TRID2 Result A B C PAID1 PAID1 Just at the end of the path allocation, a TRAIN is linked to 1,n PATH and a PATH to 1 TRAIN During the lifecycle, a PATH can be linked to 1,n TRAINS The cardinality TRAIN-PATH is n,n

Questions Questions on the different change of status of TRAIN and PATH ? Depending on the discussion, introduce two CRs on codes : Add codes 53, 54, 55, 56 for element TypeOfInformation Add code TPC (Train and Path Cancelled) for the element Procedure of UpdateLinkMessage Questions on cardinality ?