Definition and modelling of Train and Path in TAF/TAP TSIs

Definition and modelling of Train and Path in TAF/TAP TSIs
Draft Work in progress FTE, TrID WG Christian Weber, SNCF Version 0.3 of 08/12/2018

Agenda Definition of Train and Path Main objects and attributes
Life cycle Train modified in one network only Numbers Data model

Existing definitions : Train, Path (1/3)
Single European Railway Area (directive 2012/34) ‘international freight service’ means a transport service where the train crosses at least one border of a Member State; the train may be joined and/or split and the different sections may have different origins and destinations, provided that all wagons cross at least one border ‘international passenger service’ means a passenger service where the train crosses at least one border of a Member State and where the principal purpose of the service is to carry passengers between stations located in different Member States; the train may be joined and/or split, and the different sections may have different origins and destinations, provided that all carriages cross at least one border ‘urban and suburban services’ means transport services whose principal purpose is to meet the transport needs of an urban centre or conurbation, including a cross- border conurbation, together with transport needs between such a centre or conurbation and surrounding areas ‘regional services’ means transport services whose principal purpose is to meet the transport needs of a region, including a cross-border region ‘train path’ means the infrastructure capacity needed to run a train between two places over a given period

OPE TSI (regulation 2012/757) Train : A train is defined as (a) traction unit(s) with or without coupled railway vehicles with train data available operating between two or more defined points Rolling Stock LOC&PAS TSI (regulation 1302/2014) A ‘train’ is an operational formation consisting of one or more units TAF &TAP TSIs (regulations 1305/2014 & 454/2011) ‘path’ means the infrastructure capacity needed to run a train between two places over a given period (route defined in time and space) ‘path assembly’ : Joining up of individual train paths to extend path in terms of time and space ‘route’ : The geographical way to be taken from a starting point to a point of destination ‘train path’ : Train route defined in time and space ‘train path/slot’ : A definition of a train's route in terms of time and the locations (marker points) at which it will originate and terminate along with details of those locations en-route at which it will either pass or call. The detail might also include any activities that the train will perform en-route for example train crew, locomotive or other consist changes

Draft CUI Uniform Rules (OTIF) ‘international railway traffic’ means traffic which requires the use of an international train path or several successive national train paths situated in at least two States and coordinated by the infrastructure managers concerned The definitions of Train and Path are various The word Service is used according to the client point of view A common definition of Train and Path should be agreed by the different actors This definition should reflect the different understandings

Proposal of definition : Train
According to the context, a ‘train’ could be : ‘production train’ defined as a journey between an origin and a destination with a timetable and a given calendar to be implemented, a ‘production train’ needs a path, a set of vehicles including tractive vehicles (cf. ‘physical train’) and human resources (driver, conductor, etc.) the composition of a ‘production train’ can vary during the journey and can carry one or several ‘commercial train(s)’ ‘commercial train’ defined as a seamless offer of transport for the passengers or freight loads between origin and destination of the ‘commercial train’, including intermediate stops the ‘commercial train’ receives a number used by the client or loader to find information about the journey ‘physical train’ defined as an operational formation consisting of one or more units (cf. definition of ‘train’ in LOC&PAS TSI) defined by the set of European Vehicle Numbers (EVNs) of each vehicle it’s the train running on a track The concept of ‘physical train’ is not very relevant for timetabling concerns

Proposal of definition : Path
‘path’ means the infrastructure capacity needed to run a train between two locations over a given period (route defined in time and space) a ‘path’ is designed by the infrastructure manager (or the allocation body) usually on national level a ‘path’ can be an assembly of other paths to reflect the complete journey of a train, we speak then of ‘full assembled path’ a ‘path’ is designed : on request of a railway undertaking (or an applicant) or directly by the infrastructure manager without request in order to structure the capacity of the network (‘pre-arranged path’)

Example (1/5) Overview IM1 IM2 A B C D E N M Trainset

Example (2/5) Production Train IM1 IM2 Production Train 1 A B C D E N

Example (3/5) Commercial Train IM1 IM2 Commercial Train 1 A B C D E

Example (4/5) Physical Train IM1 IM2 Physical Train 3 Physical Train 5
B C D E N M Physical Train 2 Physical Train 4 The concept of ‘physical train’ is not very relevant for timetabling concerns

Example (5/5) Path IM1 IM2 Path 1 Path 2 A B C D E N M Path 3 Path 4
One path per country

What are the main objects and attributes for planning and operation ?
PLANNED TRAIN NUMBER (PTN) is the "short number" used by RU to identify the train during RU harmonisation (in PCS, field currently named "International Train Number"). PATH is the space-time allocated by IM to RU. Identified by PAID decided by the IM 5 3 6 Köln 1 COMMERCIAL TRAIN NUMBER (CTN) is the number used for passengers information (e.g. on the reservation ticket, display in stations). The CTN is allocated by the RU and used by the RU and the SM (Station Manager) Amsterdam TRAIN is the "move offer" foreseen by RU. Identified by TRID allocated by the RU at the beginning of the path allocation INFRASTRUCTURE TRAIN NUMBER (ITN) is the "short number" used by IM to identify the national path and usually the assembled path according to UIC leaflets 419-1/2 Bruxelles 7 Paris Object Time PATH REQUEST is a request by RU to IM to receive a path to operate the train. Identified by PRID allocated by the RU 2 Attribute CASE REFERENCE is a workflow document used for one path request or a set of path requests gathered for organisational reasons. Identified by CRID allocated by the RU (or the IM for internal purposes) OPERATIONAL TRAIN NUMBER (OTN) is the "short number" used by IM and RU in daily operation (e.g. display in signalling box, communication signalling box/train). Allocated by the IM, it is usually equal to ITN and can be changed in case of event in operation 4 8

Description of the objects
Objects and Identifiers - Overview Four objects are defined currently Train ("owned" by the Railway Applicant [RA]) Path Request ("owned" by the RA) Path ("owned" by the IM) Case Reference cf. Dossier ("owned" by the RA, IM, other actors) These objects are not explicitely defined in the TAP/TAF data model (xsd) but implicitely defined in the messages The data model will be proposed at the end of the presentation TRID, PRID, PAID, CRID have a common structure : Object Type (2A) Company Code (4AN) Core Element (12AN) (free content decided by the Lead RU) Variant (2AN) Yearly Timetable (4N) Date (8N) TR 1187 --PAR_AMS_03 01 2017 Planning (with calendar/regime) : 24 AN Operation (with day of running) : 32 AN

Life cycle Simplified planning cycle Train TRID Path Request PRID
Lead RU with other RUs National RU to National IM 1 1 1/IM 1/IM Train TRID TrainInfo Composition Locations with timing Calendar Wished OTN Path Request PRID PathInfo Composition Locations with timing Calendar Wished OTN To request Lead RU with other RUs National IM to National RU x x n/IM n/IM Train TrainInfo Composition Locations with timing Calendar OTN(s) Path PAID PathInfo Composition Locations with timing Calendar OTN(s) To produce Which TRID ? Is the TRAIN (to request) the same object than the TRAIN (to produce)?

Life cycle Basic example with 2 RUs and 2 IMs (1/4)
Lead RU = RU1 RU1 RU2 Train TRID1 TrainInfo Orig. 08:00 Bord. 10:00 Dest. 12:00 Mo to Su OTN 123 Path Req. PRID1 TrainInfo PathInfo Orig. 08:00 Bord. 10:00 Mo to Su OTN 123 Path Req. PRID2 TrainInfo PathInfo Bord. 10:00 Dest. 12:00 Mo to Su OTN 123 Lead RU = RU1 Train TRID? TrainInfo1 Orig. 08:15 Bord. 10:15 Dest. 12:15 Mo to Th OTN 567 IM1 IM2 Train TRID? TrainInfo2 Orig. 08:15 Bord. 10:15 Bord Dest. 12:30 Fr OTN 567 Train TRID? TrainInfo3 Orig. 08:30 Bord. 10:30 Dest. 12:30 Sa to Su OTN 567 Path PAID1 PathInfo1 Orig. 08:15 Bord. 10:15 Mo to Fr OTN 567 Path PAID2 PathInfo2 Orig. 08:30 Bord. 10:30 Sa to Su OTN 567 Path PAID3 PathInfo3 Bord. 10:15 Dest. 12:15 Mo to Th OTN 567 Path PAID4 PathInfo4 Bord. 10:30 Dest. 12:30 Fr to Su OTN 567 There is 1 TRAIN (to request) There are 3 TRAINS (to produce) How can it be managed ?

Life cycle Basic example with 2 RUs and 2 IMs (2/4) Easy to manage
For the IMs There are 4 PATHS to produce Capacity check on line and in stations Programming of the signalling boxes Traffic management Etc. How to manage ? For the RUs There is 1 TRAIN to request There are 3 TRAINS to produce Rostering (rolling stock, drivers, conductors, etc.) Resources allocation Information for passengers (timetabling, digital tools, ticketing, display in stations and trains, etc.) Information for freight customers Etc.

How to manage 1 TRAIN to request and 3 TRAINS to produce ?
Life cycle Basic example with 2 RUs and 2 IMs (3/4) How to manage 1 TRAIN to request and 3 TRAINS to produce ?   Create new TRIDs and inform via Update Link Message Numerous updates Complex process Difficult IT implementation  TRID kept Object TRAIN TO PRODUCE = TRID (ID only) + relevant PATH objects (PAID + PathInfo) The TRAIN TO PRODUCE remains virtual and is NOT a real object Should be generated dynamically Complex to manage Difficult IT implementation TRID1  PAID1 In IM1 Mo-Fr PAID2 In IM1 Sa-Su PAID3 In IM2 Mo-Th PAID4 In IM2 Fr-So  TRID kept One TRAIN object with several TrainInfo elements (1 request extended to 3 after answer) Each TrainInfo element receives an ID (e.g. 2 AN) -> format 26 AN for objet TRAIN TO PRODUCE Add TrainInfo elements after answer Object Info Message to be sent Different formats Numerous updates Complex process Difficult IT implementation   TRID kept Create a new object (e.g. TRAIN PRODUCTION) used only by the RUs This object is implemented by the RUs Object TRAIN PRODUCTION TPID (24 AN or 32 AN daily) TRID TrainInfo (1 element) Created after allocation by the LeadRU and sent to the other RUs via ObjectInfoMessage Easy to implement Principle of TRID kept Object TP managed only by RUs No Update Link to send 

Life cycle Basic example with 2 RUs and 2 IMs (4/4) Train TRID1
Lead RU = RU1 RU1 RU2 Train TRID1 TrainInfo Orig. 08:00 Bord. 10:00 Dest. 12:00 Mo to Su OTN 123 Path Req. PRID1 PathInfo Orig. 08:00 Bord. 10:00 Mo to Su OTN 123 Path Req. PRID2 PathInfo Bord. 10:00 Dest. 12:00 Mo to Su OTN 123 Lead RU = RU1 IM1 IM2 Train TPID1 TRID1 TrainInfo Orig. 08:15 Bord. 10:15 Dest. 12:15 Mo to Th OTN 567 Train TPID2 TRID1 TrainInfo Orig. 08:15 Bord. 10:15 Bord Dest. 12:30 Fr OTN 567 Train TPID3 TRID1 TrainInfo Orig. 08:30 Bord. 10:30 Dest. 12:30 Sa to Su OTN 567 Path PAID1 PathInfo1 Orig. 08:15 Bord. 10:15 Mo to Fr OTN 567 Path PAID2 PathInfo2 Orig. 08:30 Bord. 10:30 Sa to Su OTN 567 Path PAID3 PathInfo3 Bord. 10:15 Dest. 12:15 Mo to Th OTN 567 Path PAID4 PathInfo4 Bord. 10:30 Dest. 12:30 Fr to Su OTN 567

Life cycle with Train Production object
PROs Easy life for the RUs with a new object TRAIN PRODUCTION used only by RUs The Lead RU creates the object TRAIN PRODUCTION and informs the other RUs via the Object Info Message The object TRAIN PRODUCTION is used inside the RUs and is the basis for RU production (rostering, passengers informatio, etc.) The TRID is unchanged during the complete process No need to update the object TRAIN (to request) even when the answer of the IMs is different of the request of the RUs TRID continues to be used in the messages (RU/IM, IM/IM, RU/RU) No need for the RUs to send the object TRAIN PRODUCTION to the IMs Only the TPID can be sent by the RUs to IMs (as information only) but it is not used by IMs The phase of request and the phase of production are mirrored

Simplified planning cycle Lead RU with other RUs National RU to National IM 1 1 1/IM 1/IM Train Request TRID TrainInfo Composition Locations with timing Calendar Wished OTN Path Request PRID PathInfo Composition Locations with timing Calendar Wished OTN To request Lead RU with other RUs National IM to National RU x x n/IM n/IM Train Production TrainInfo Composition Locations with timing Calendar OTN(s) Path PAID PathInfo Composition Locations with timing Calendar OTN(s) To produce TPIDx TRID The TRAIN PRODUCTION is produced and it keeps the TRID created during the Train Request process

Same characteristics, same Train Production objects (1/2) RU1 RU1 RU1 wants two trains: one for working days one for week-ends Train TRID1 TrainInfo Orig. 08:15 Dest. 12:15 Mo to Fr OTN 1234 Path Req. PRID1 PathInfo Orig. 08:15 Dest. 12:15 Mo to Fr OTN 1234 Train TRID2 TrainInfo Orig. 08:30 Dest. 12:30 Sa to Su OTN 5678 Path Req. PRID2 PathInfo Orig. 08:30 Dest. 12:30 Sa to Su OTN 5678 IM1 RU1 The answer is two trains: one for working days one for week-ends same than the wish Path PAID1 PathInfo Orig. 08:15 Dest. 12:15 Mo to Fr OTN 1234 Train TPID1 TRID1 TrainInfo Orig. 08:15 Dest. 12:15 Mo to Fr OTN 1234 Path PAID2 PathInfo Orig. 08:30 Dest. 12:30 Sa to Su OTN 5678 Train TPID2 TRID2 TrainInfo Orig. 08:30 Dest. 12:30 Sa to Su OTN 5678

Same characteristics, same Train Production objects (2/2) RU1 RU1 RU1 wants one train : the same for all days Train TRID1 TrainInfo Orig. 08:00 Dest. 12:00 Mo to Su OTN 1234 Path Req. PRID1 PathInfo Orig. 08:00 Dest. 12:00 Mo to Su OTN 1234 RU1 IM1 Train TPID1 TRID1 TrainInfo Orig. 08:15 Dest. 12:15 Mo to Fr OTN 1234 Train TPID2 TRID1 TrainInfo Orig. 08:30 Dest. 12:30 Sa to Su OTN 5678 Path PAID1 PathInfo Orig. 08:15 Dest. 12:15 Mo to Fr OTN 1234 Path PAID2 PathInfo Orig. 08:30 Dest. 12:30 Sa to Su OTN 5678 The answer is two trains : one for working days one for week-ends different of the wish In both cases the objects TRAIN PRODUCTION to be produced by the RU are the same even the process to create them is different

This should be simplified
Modification in one network With the current TRID Before the start of the path request period for the annual timatable, IM2 informs that a rerouting will take place from B to C in March with 30 minutes additional time RU1 and RU2 have to create 2 objects TRAIN with 2 TRIDs (in practice : different variants) As consequence : all IDs are different for both periods RU1 sends to IM1 the same Path Request content for both periods but PRIDs are different The Path allocated by IM1 to RU1 is identical for both periods but PAIDs are different Daily except 01/03 to 31/03 Rerouting on network 2 from 01/03 to 31/03 A 08:00 A 08:00 IM1 RU1 IM1 RU1 PRID1 PAID1 PRID3 PAID3 09:00 09:00 TRID1 TPID1 B TRID2 TPID2 B IM2 RU2 IM2 RU2 PRID2 PAID2 PRID4 PAID4 C 10:00 C 10:30 This should be simplified

Rerouting on network 2 from 01/03 to 31/03
Modification in one network What should be the simplest way Simplest way : Path Request 1 and Path 1 have the same ID and same content for both periods Consequences : Train (Request) 1 and Train (Request) 2 should be merged with the same TRID1 The Train (Request) object should contain 2 elements TrainInfo (1 for each period) With the Train Production object, no need to update the content of the object Train (Request) Daily except 01/03 to 31/03 Rerouting on network 2 from 01/03 to 31/03 A 08:00 A 08:00 IM1 RU1 IM1 RU1 PRID1 PAID1 PRID1 PAID1 09:00 09:00 TRID1 TPID1 B TRID1 TPID2 B IM2 RU2 IM2 RU2 PRID2 PAID2 PRID3 PAID3 C 10:00 C 10:30

Modification in one network
Messages and possible data model – RU1 and IM1 PathRequestMessage 1 TRAIN (REQUEST) TRID1 TrainInformation Station A : 08:00 Station B : 09:00 Station C : 10:00 All days except 01-31/03 TrainInformation Station A : 08:00 Station B : 09:00 Station C : 10:30 01-31/03 PATH REQUEST PRID1 PathInformation Station A : 08:00 Station B : 09:00 All days PathDetailsMessage 1 PATH PAID1 Station A : 08:00 Station B : 09:00 All days TRID1 PRID1

Messages and possible data model – RU2 and IM2 PathRequestMessage 2 PathRequestMessage 3 TRAIN (REQUEST) TRID1 TRAIN (REQUEST) TRID1 TrainInformation Station A : 08:00 Station B : 09:00 Station C : 10:00 All days except 01-31/03 TrainInformation Station A : 08:00 Station B : 09:00 Station C : 10:00 All days except 01-31/03 TrainInformation Station A : 08:00 Station B : 09:00 Station C : 10:30 01-31/03 TrainInformation Station A : 08:00 Station B : 09:00 Station C : 10:30 01-31/03 PATH REQUEST PRID2 PATH REQUEST PRID3 PathInformation Station B : 09:00 Station C : 10:00 All days except 01-31/03 PathInformation Station B : 09:00 Station C : 10:30 01-31/03 PathDetailsMessage 2 PathDetailsMessage 3 PATH PAID2 PATH PAID3 Station B : 09:00 Station C : 10:00 All days except 01-31/03 Station B : 09:00 Station C : 10:30 01-31/03 TRID1 TRID1 PRID2 PRID3

Messages and possible data model – Train Production TRAIN PRODUCTION TRAIN PRODUCTION TPID1 TPID2 TRID1 TRID1 PAID1 PAID1 PAID2 PAID3 TrainInformation Station A : 08:00 Station B : 09:00 Station C : 10:00 All days except 01-31/03 TrainInformation Station A : 08:00 Station B : 09:00 Station C : 10:30 01-31/03 Every actor has the right objects to implement : IM1 with PA1 for all days IM2 with PA2 (all days except 01-31/03) and PA3 (01-31/03) RU1 and RU2 with TP1 (all days except 01-31/03) and TP2 (01-31/03) TRID1 is unchanged and permits the links between all objects

Numbers (check alignment with for FTE WG)
PTN (Planned Train Number) "Short number" used by the RUs to identify the train during RU harmonisation between the planners Allocated by the Lead RU, usually by agreement with the other RUs involved in the harmonisation Unicity is required in the scope of RU harmonisation Usually the PTN is the ITN of the full assembled path If several ITNs are used for the full assembled path, the PTN is usually the “main” ITN (longest journey, nb of running days, etc.) The ITN can be changed during the planning process Could be alphanumeric depending on agreements between RUs As one CASE REFERENCE can concern MAIN and SUB, the PTN is an attribute of the CASE REFERENCE grouping MAIN and SUB As one PATH REQUEST can lead to several PATHS, these objects are grouped in the CASE REFERENCE with the PTN as attribute The PTN could also be an attribute of the TrainInformationSection, tbc

Numbers CTN (Commercial Train Number)
"Short number" used for passengers information (e.g. on the reservation ticket, display in stations, etc.) The CTN is allocated by agreement between the involved RUs The CTN is used by the RUs (retail, ticketing, passengers information) and the Station Managers (information in stations) The CTN is linked to a set of vehicles on the same journey with the same origin and destination A "Production Train" can carry one or several CTN(s) Unicity is required in the scope of retail and passengers information Could be alphanumeric depending on agreements between RUs

Numbers ITN (Infrastructure Train Number)
"Short number" used by the IM(s) to identify the national path and/or the full assembled path according ITN is a number compliant with: UIC leaflets 419-1/2 for international trains National train numbering scheme for domestic trains Unicity is required in the scope of (future) operation Allocated by the Coordinator IM (international trains) or the IM (domestic trains) during the planning phase The ITN can change along the journey depending on international or national rules The RUs can request a “preferred ITN” usually by pre-agreement with the IMs Is only numerical due to technical constraints with GSM-R and ETCS

Numbers OTN (Operational Train Number)
"Short number" used by the IMs and RUs in daily operation (e.g. display in signalling box, communication signalling box/train, etc.) OTN is a number compliant with: UIC leaflets 419-1/2 for international trains National train numbering scheme for domestic trains Unicity is required in the scope of operation Equal to the ITN when operation takes place as planned The OTN can change in case of operational events, depending on international or national rules Is only numerical due to technical constraints with GSM-R and ETCS

Meaning of the TRID The TRID is the identifier of a TRAIN REQUEST meant as a ‘wished offer’ which can include a certain level of freedom concerning the locations , timing, calendar, etc. The TRID identifies a TRAIN (to request) with possibly several elements TrainInfo The TrainInfo element of the object TRAIN (to request) is a global overview of the wished offer to travel The precise characteristics (locations, timing, calendar) are defined in the element PathInfo of the Path Request(s) The TRAIN to produce (TRAIN PRODUCTION) is identified by the TPID (TrainProductionID) with a TrainInfo element issued from the relevant PathInfo elements and is used only by the RUs The TRID is always used in the messages between RUs and IMs (RU/IM, RU/RU, IM/IM)

Is the element inside or outside the object ?
Data model (draft) with the 5 objects TR, PA, PR, TP, CR CASE REFERENCE (CRID) Attribute : PTN (also in the TrainInformation element, tbc) TRAIN PRODUCTION PathRequestMessage TrainProduction ID (TPID) [1] (TPID+Day in operation) TRAIN (REQUEST) TrainID (TRID) [1] (TRID+Day in operation) TrainID (TRID) [1] TrainInformation [1-n] Composition Locations with Timing Calendar PTN, CTN ITN* Etc. PathID (PAID) [1-n] (PAID+Day in operation) TrainInformation [1] Composition Locations with Timing Calendar PTN, CTN ITN** (OTN in operation) Etc. PATH REQUEST PathRequestID (PRID) [1] PATH TrainID (TRID) [1] PathID (PAID) [1] (PAID+Day in operation) PathInformation [1] Composition Locations with Timing Calendar PTN ? CTN ? ITN* Etc. PathInformation [1] Composition Locations with Timing Calendar PTN ? CTN ? ITN** Etc. PathDetailsMessage TrainID (TRID) [1] PathRequestID (PRID) [1] * wished/proposed by the RU ** allocated by the IM [x] cardinality (1 or n) Is the element inside or outside the object ?

TO BE CHECKED  Current situation in PCS CRID (Case Reference ID)
PTN (Planned Train Number) TRID (Train ID) if entire journey in Applicant(s) Section PRID (Path Request ID) if national journey in Applicant(s) Section PAID (Path ID) if national journey in IM(s) Section ITN (Infrastructure Train Number) Change of ITN

Questions ?

Definition and modelling of Train and Path in TAF/TAP TSIs

Similar presentations

Presentation on theme: "Definition and modelling of Train and Path in TAF/TAP TSIs"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Definition and modelling of Train and Path in TAF/TAP TSIs

Similar presentations

Presentation on theme: "Definition and modelling of Train and Path in TAF/TAP TSIs"— Presentation transcript:

Similar presentations

About project

Feedback