1. TAF-TSI Train Object
25th June 2018, Prague

2. Definitions

3. JSG Handbook – Train Object
The train object first comes into existence at the earliest planning phase when the RU starts to develop plans to run a train. The Lead RU creates the identification for the train at this stage. The Leading RU will then go through a harmonization process with all RUs involved in the particular business case. They will then apply for paths to run the trains. The attributes of the object Train are: - Train route (geography, journey sections / locations, timing, indication of responsible RU and IM) The locations to be defined for the train route shall be at least: ○ origin of the train route ○ border points ○ destination of train route - Train parameters (weight, length ) - Train calendar / start date

4. JSG Handbook – Train Information
This element group is used to facilitate the harmonization between the involved RUs, IMs and to be used for information publication needs. The train information element contains the following information related to the train Schedule for the entire journey which includes all the key locations (Origin, final destination, interchange, handover, points with commercial stops) and their timings and activities…
Consequences
1 document 1
object
2 definitions

5. Aspects

6. Aspects
Why do we have different interpretations for the „same” object?
When we all know that the train is this:
Because we have different aspects, different systems…
Production planner
Commercial department
„n” aspects of a train, but we have only 2 objects
Resource planning
Etc.
„User”
PATH
TRAIN

7. Proposal

8. International/National System International/National System
The TAF-TSI Train CI CI
International/National System
International/National System
Work as you want with the objects according to users’ demand. Respect the process.
Work as you want with the objects according to users’ demand. Respect the process.
Use the defined objects and schema in the messages. Use the same rules as everyone else.
Proposal (details in a moment on an example)
Meeting between RNE & FTE in Zürich on 9th May 2018
Scope: the content of the message
Train: Identifier (variant), origin, borders (interchange & handover points), destination with time, calendar, parameter
Path: Every additional information

9. Example

10. Example Train ID: XXXX – Core element – 2018 –
Variant 1 (running days 1 – 5)
Variant 2 (running days 6 – 7)
Crew start
Crew start
Origin
Origin
C.st.
C.st.
C.st.
C.st.
C.st.
Handover
Handover
C.st., Loco driver, crew change
C.st., Ld., crew ch.
C.st.
C.st., Crew finish
Destination
Destination
C.st., Crew finish
Legend
1st user (border harmonization)
2nd user (commercial department)
3rd user (resource planner)

11. Path Coordination Message
Train information: O/B/D
Path information: everything else
V1 (1-5)
V2 (6-7)
Filter/Convert/My logic/etc.
E.g. System for passenger information

12. PCS EC model

13. 𝑁 𝑇𝑅 𝑣𝑎𝑟𝑖𝑎𝑛𝑡 ≤ 𝑁 𝑃𝑅 𝑃𝐴 𝑣𝑎𝑟𝑖𝑎𝑛𝑡
PCS & TAF Constraints
User defines/PCS stores:
TSI Variant (Train)
Title of variant (for end user)
PCS entity = subpath (SP)
RU – IM pair basis
Operation points
Calendar
Parameters
Link to TSI variant
TSI Path ID, meaning
PR in RU timetable
PA in IM timetable
TR V
TR V2 6- 7
SP 1.1
SP 1.2
SP 2.1
SP 2.2
SP 2.3
SP 2.4
First rule:
Subpath that here represents e.g. PR object cannot belong to more than one train. Even if the timetable (schedule, route, parameter) is the same for both TR variant in the first territory, two SPs, meaning two PRs should be created by the RU. In PCS it won’t be possible to link one SP to more TSI Variant.
Second rule:
If a subpath does not correspond to the O-B-D rule of the already attached subpaths, then this subpath cannot be linked to that TSI variant.
𝑁 𝑇𝑅 𝑣𝑎𝑟𝑖𝑎𝑛𝑡 ≤ 𝑁 𝑃𝑅 𝑃𝐴 𝑣𝑎𝑟𝑖𝑎𝑛𝑡
SP with different origin cannot belong to that TR variant

14. Process, objects, messages

15. Before Path Request

16. Path Elaboration

17. After Offer, After Allocation