UC:TT:ImportCompleteTimetableForVehicleWorkingSchedulingAndVehicleWorkings: Difference between revisions
Jump to navigation
Jump to search
[unchecked revision] | [checked revision] |
No edit summary |
No edit summary |
||
Line 51: | Line 51: | ||
* commercial train data | * commercial train data | ||
** itineraries with optional platform assignments | ** itineraries with optional platform assignments | ||
** commercial formation requirements, commercial coupling and branching | ** commercial formation requirements (may vary per itinerary section), commercial coupling and branching | ||
** planned connection requirements with | ** planned connection requirements with | ||
*** validity, source and target, minimum and maximum connection time, connection guaranteed flag, same platform required flag, connection direction (incoming, outgoing, both) | *** validity, source and target, minimum and maximum connection time, connection guaranteed flag, same platform required flag, connection direction (incoming, outgoing, both) | ||
Line 57: | Line 57: | ||
** references to commercial trains | ** references to commercial trains | ||
** itineraries with optional platform assignments | ** itineraries with optional platform assignments | ||
** formations, including coupling and branching of trains | ** formations (may vary per itinerary section), including coupling and branching of trains | ||
Revision as of 12:30, 15 January 2016
Use case / Anwendungsfall / :
Import complete timetable for vehicle working scheduling and vehicle workings; Umlaufbildung Fahrzeuge Jahresfahrplan
Description / Beschreibung /
A complete timetable shall be imported, serving as base for vehicle working scheduling.
The following usecases are covered:
- import infrastructure for vehicle working scheduling (optional)
- import rolling stock data (optional)
- import timetable for a calendar period
- import timetable for an abstract regular week (template)
- import partial vehicle working data
Data Flows and Interfaces / Datenflüsse und Schnittstellen /
Typically, the import is done manually using a file based interface.
Interference with other railML® schemas / Interferenz mit anderen railML®-Schemen /
- Common
- Infrastructure: the import uses elements from mesoscopic and macroscopic perspective
- Rolling stock
Characterising Data / Charakterisierung der Daten /
How often do the data change (update)?
- static
How big are the data fragments to be exchanged (complexity)?
- whole data set, or region
Which views are represented by the data (focus)?
- mid term
Which specific data do you expect to receive/send (elements)?
Timetable data
- base data of commercial and operational trains (validity, train numbers, train category, train line, operators, concessionairs, subcontractors etc)
- commercial train data
- itineraries with optional platform assignments
- commercial formation requirements (may vary per itinerary section), commercial coupling and branching
- planned connection requirements with
- validity, source and target, minimum and maximum connection time, connection guaranteed flag, same platform required flag, connection direction (incoming, outgoing, both)
- operational train data
- references to commercial trains
- itineraries with optional platform assignments
- formations (may vary per itinerary section), including coupling and branching of trains
Infrastructure data
Stops, stations, tracks, track sections. They should
- refer to a validity, possibly to be extended to daytime validity
- carry infrastructure restrictions
- allow computation of itineraries, including changes of direction
Rolling stock data
Vehicle information should include
- validity reference
- length
- weight
- speed
- traction
- seating capacity (per class)
- standing capacity
- additional services (buffet, wlan, etc.)
vehicle working and rostering data
Vehicle workings may be imported if there is a pre-planning that is to be completed.
- Concatenation of operating trains to vehicle workings that are served by the same (abstract) vehicle
- Shunting trips within Template:Ocps (referencing microscopic infrastructure)
- Non-revenue trains implementing operational needs
- Maintenance blocks for abstract vehicles
Rosterings may be imported if there is a pre-planning that is to be completed.
The following data could be imported:
- Assignment of a rostering plan to a depot
- Concatenation of vehicle workings to multi-day sequences of trains served by the same (abstract) vehicle
- depot runs
- vehicle standbys
- vehicle accounting for maintanance intervals
Open questions
- Identification of operational and commercial trains (if not present in railML data)
- Relationship between operational and commercial trains (itineraries, formations, ...)