UC:TT:ImportCompleteTimetableForVehicleWorkingSchedulingAndVehicleWorkings: Difference between revisions
Jump to navigation
Jump to search
[unchecked revision] | [unchecked revision] |
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
==Use case / {{Deu|Anwendungsfall}} / {{Fra|Scénario d’utilisation}}:== | |||
Import complete timetable for vehicle working scheduling and vehicle workings; {{Deu|Umlaufbildung Fahrzeuge Jahresfahrplan}} | Import complete timetable for vehicle working scheduling and vehicle workings; {{Deu|Umlaufbildung Fahrzeuge Jahresfahrplan}} | ||
==Description / {{Deu|Beschreibung}} / {{Fra|Description}}== | |||
A complete timetable shall be imported, serving as base for vehicle working scheduling. | 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 / {{Deu|Datenflüsse und Schnittstellen}} / {{Fra|Flux de données et interfaces}}== | |||
Typically, the import is done manually using a file based interface. | Typically, the import is done manually using a file based interface. | ||
==Interference with other railML<sup>®</sup> schemas / {{Deu|Interferenz mit anderen railML<sup>®</sup>-Schemen}} / {{Fra|Interaction avec autres schemas railML<sup>®</sup>}}== | |||
* Common | * Common | ||
Line 30: | Line 29: | ||
==Characterising Data / {{Deu|Charakterisierung der Daten}} / {{Fra|Caractérisation des données}}== | |||
===How often do the data change (update)?=== | |||
* static | * static | ||
===How big are the data fragments to be exchanged (complexity)?=== | |||
* whole data set, or region | * whole data set, or region | ||
===Which views are represented by the data (focus)?=== | |||
* mid term | * 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, 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, 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 | * Concatenation of operating trains to vehicle workings that are served by the same (abstract) vehicle | ||
* Shunting trips within {{ocp}}s (referencing microscopic infrastructure) | * Shunting trips within {{ocp}}s (referencing microscopic infrastructure) | ||
* Non-revenue trains implementing operational needs | * Non-revenue trains implementing operational needs | ||
* Maintenance blocks for abstract vehicles | * Maintenance blocks for abstract vehicles | ||
Rosterings may be imported if there is a pre-planning that is to be completed. | Rosterings may be imported if there is a pre-planning that is to be completed. | ||
Line 262: | Line 97: | ||
* vehicle standbys | * vehicle standbys | ||
* vehicle accounting for maintanance intervals | * 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, ...) |
Revision as of 10:40, 14 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, 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, 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, ...)