UC:TT:ImportCompleteTimetableForVehicleWorkingSchedulingAndVehicleWorkings

Import complete timetable for vehicle working scheduling and vehicle workings

Description

A complete timetable shall be imported, serving as base for vehicle working scheduling. The infrastructure data is already present in the importing system. Timetable data includes

• base data of trains (train numbers, train category, train line, operators, concessionairs, subcontractors etc)
• traffic periods, including weekdays, holidays, seasonal variation etc
• itineraries, arrival and departure times
• platform assignments
• track occupancies
• formations, including coupling and branching of trains

Optionally, vehicle working data may be imported that may serve as a planning base.

Data Flows and Interfaces

Typically, the import is done manually using a file based interface.

Interference with other railML® schemas

• Common
• Infrastructure: the import uses elements from mesoscopic and macroscopic perspective
• Rolling stock

Characterizing Data

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 timetable data do you expect to receive/send (elements)?

The process covers following steps:

1. Determine Validities
2. Import the traffic network data and routing
3. Import rollingstock data
4. Import itineraries
5. Import track occupancies
6. Import train parts
7. Import trains
8. Import vehicle workings
9. Import rosterings

Determine validities

• Precondition:*

The validities may be calendar based or abstract operating days and operating periods:

• Calendar based: It should be possible to define different calendars. These calendars should be identified by a name attribute. The calendar based validity is defined considering a calendar, a start date and a bitmask. The bitmask defines the instants where the validity takes effect in respect to the calendar and the start date.
  • Required: the "calendar day to validity"-mapping is consistent and complete.
• Abstract validities are defined by name in respect to the timetable version
• A period based abstract validity (e.g., a weekly template) is defined by abstract validity and a bitset. The bitset marks when the validity is repeated in the sequence of validities.

• Execution:*
• Calendar based validities are imported with the help of a "calendar day to validity"-mapping.
• Abstract are searched by name within the timetable version. If the validity is not found a new validity is created.
• For period based abstract validities, the application logic defines the import process.

• Postcondition:*
• All validity descriptions have been mapped to validities in the business model.

_The current validity model covers all usecases. We recommend refactoring and introducing different subtypes for every usecase._

Import traffic network and routing data

• Precondition:*
• Stops have a name attribute, and a reference to a validity
• Stations have a name, a timezone attribute and a reference to a validity.
• Tracks have a name and a validity
• Track section have an name

• This should be used for track closures, or when a stops or stations are temporarily not serviced. For further versions of the schema the validity may be extended to a daytime validity. An application of this feature is e.g. night driving prohibition on certain tracks and stops.
• Stations have a name and a timezone
• Track sections may be used to define on which platform section a vehicle is positioned.

On tracks the change of direction are attributed.

• Execution:*
• Stops are searched by their name in the datasource. If the stop does not exist, it is created and the validity of the stop is assigned. If the stop already exists the validity is applied to the stop and attributes are changed.
• Stations are searched by their name in the datasource. If the station does not exist it is created and the validity is assigned to the station. If the station already exists the validity is applied to the station and attributes are changed.
• Tracks are searched by their name in the datasource. If the track does not exist it is created and the validity is assigned to the track. If the station already exists the validity is applied to the track and the change of direction and other attributes are changed.
• Track sections are imported.
• Routes are searched by name in the datasource. If the route does note exist it is created. If the route already exists the attributes are changed.

• Postcondition:*
• Stops have been imported.
• Stations have been imported.
• Tracks have been imported.
• Routes have been imported.

Import rollingstock data

• Precondition:*
• The formation information has following informations:
  • validity reference \[optional\]: to set a formation outdated during a timetable period
  • length
  • weight
  • speed
  • traction
  • seating capacity
  • standing capacity
  • additional services (buffet, wlan, etc.)

• Execution:*
• The formation is searched by name in the datasource.
  • If the formation is found it is modified according to attributes. If the validity is set, it is applied to the formation.
  • Otherwise the formation is created with the specified attributes and the validity is assigned if the attribute was set in the input data.

• Postcondition:*
• Formations have been imported.

Import train

• Execution:*
• Imports [commercial trains|#Import Commercial Train].
• Imports [operational trains|#Import Operational Train].

Import commercial train

• Precondition:*
• The commercial train consists of an unique id, and a validity reference.
• The commercial train references an itinerary, which defines the requirements of the itinerary for the commercial train.
• The commercial train references a formation. The formation may vary on sections of the itinerary. This formation defines the requirements, which must be fulfilled by the operational trains.
• The commercial train may define connection requirements.
  • Connections define connecting constraints to other commercial trains for a certain stop in the itinerary.

• • Connections have following attributes:
    • a reference to a validity
    • a reference to an itinerary stop of the current train
    • a reference to a another commercial train (need not be in the be in railML-source)
    • a reference to a stop (connection point of other train)
    • a minimum connection time point: the time the train waits at least
    • a maximum connection time point: the time the train waits at most
    • a flag if the connection is guaranteed
    • a flag if the connection meets at same platform
    • a connection direction: both, outgoing, incomming

• Execution:*
• The import identifies with the commercial train by id and validity.
• The status (deleted, modified) defines the operation which will be executed during the import.
  • If the train is marked as deleted and the train is found in the datasource, the train will be deleted for the validity, it has been defined (e.g. Train in datasource is defined Mo-Fr, railml-source defined deletion for Mo-Do. So after the import the train should still exist on Fr, but not on Mo-Do). For deletion only the id attribute and validity reference are mandatory.
  • If the train is marked as modified, it may either be created or modified - if found in the datasource. For creation or modification of a train the id attribute, the validity reference, the formation and the commercial train itinerary are mandatory.
• The [commercial itinerary is imported|#Import itineraries] and assigned to the commercial train.
• The formation is assined to the commercial train

• Postcondition:*
  • • commercial trains have been imported or deleted.

Import operational train

• Precondition:*
• An operational train consists of an unique id, and a validity reference.
• An operational train may implement a commercial train or an itinerary section of it.
  • Therefore the operational train has validity disjunct references to a section of the commercial itinerary. The operational train consists of subsequent sections with several trainparts with their positions, thus defining the formation of the train section.
• Application logic may define requirements for the fulfillment relation between operational and commercial formations and itineraries.

• Execution:*
• The import identifies with the operational train by trainId and validity.
• The status (deleted, modified) defines the operation which will be executed during the import:
  • If the train is marked as deleted and the train is found in the datasource, the train will be deleted. But only for the validity defined in the railml-source. (e.g. Train in datasource is defined Mo-Fr, railml-source defined deletion for Mo-Do. So after the import the train should still exist on Fr, but not on Mo-Do.)
  • Otherwise the train is either imported or modified (if it is found in the datasource).
• The [operational train parts are imported|#Import operational train parts] and assigned to the train according to the position in the train part sequence.

• Postcondition:*
• operational trains have been imported or deleted.

Import operational train parts

• Precondition:*
• The import identifies with the train part by id and validity.
• The category references information on traintype and usage
• operational trainpart may be supervalid to the operational train
• operational trainpart must not be subvalid to the operational train

• Execution:*
• The status (deleted, modified) defines the operation which will be executed during the import.
  • If the train part is marked as deleted and the train part is found in the datasource, the train part will be deleted for the intersection of the validity of the existing train part and the validity defined in the RailMl-source.
  • If the train is defined as modified and not found in the datasource. The train part will be created and the validity will be the validity of the newly created object.
  • If the train is defined as modified and found in the datasource, the train part will be modified respecting the validity defined in the RailMl-source.
• The itinerary is imported and assigned to the train part.
• Categories are imported if missing

• Postcondition:*
• operational train parts have been imported

Import itineraries

• Precondition:*

Following attributes are mandatory for itinerary stops:

• Reference to stop
• Reference to track which is used as "station track"
• The itinerary stops must be well ordered
• Arrival and departure time must be specified
• The track section must be specified for position of vehicles in formation
• Type of stop must bespecified:
  • stop
  • pass
• Reference to next track must be specified
• The itinerary data must be valid. There should not be any spacial interruptions or the sequence of times along the path should not be contradictory
• The positions of the operational trains in train part sequence must be consistent to the change of directions in the infrastructure

• Execution:*
• Itinerary stops are imported: So the shunting time, waiting time is set. The platform infromation is referenced to an already imported track and/or track section.
• Itinerary legs are imported: So the runtime is set and the track wich is used is referenced.

• Postcondition:*
• itinerary stops and legs have been imported
• imported itineraries are consistent

Import vehicle workings

• Vehicle workings may be imported if there is a pre-planning that is to be completed.

• Precondition:*
• 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
• Vehicle workings reference a validity
• Vehicle workings must be subvalid to the validity of operational trains

• Execution:*
• Vehicle workings are identified by name and validity
• The status (deleted, modified) defines the operation which will be executed during the import.
  • If the vehicle working is marked as deleted and the vehicle working is found in the datasource, the vehicle working will be deleted for the intersection of the validity of the existing vbehicle working and the validity defined in the RailMl-source.
  • If the vehicle working is defined as modified and not found in the datasource. The vehicle working will be created and the validity will be the validity of the newly created object.
  • If the vehicle working is defined as modified and found in the datasource, the vehicle working will be modified respecting the validity defined in the RailMl-source.
• All parts of the vehicle working are imported
  • operational train parts are assigned to vehicle working parts
    • The vehicle orientation is calculated depending on the position of the vehicle in the trainpart sequence and the change of direction information in the infrastructure data
  • Shunting trips are imported and assigned a vehicle working part
  • Maintenance blocks are imported and assigned a vehicle working part

• Postcondition:*
• Vehicle workings and all it's parts have been imported.

Import rosterings

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

Adopt vehicle working scheduling to timetable changes

Description

The importing system holds timetable and vehicle working data. A change in the timetable shall be imported.

Data Flows and Interfaces

The import may be performed manually via a file based interface, or online via a message (SOAP) based interface.

Interference with other railML® schemas

• Common
• Infrastructure
• Rolling stock

Characterizing Data

How often do the data change (update)?

could be daily

How big are the data fragments to be exchanged (complexity)?

• small (single train run)

Which views are represented by the data (focus)?

any

Which specific timetable data do you expect to receive/send (elements)?

see _Import complete timetable for vehicle working scheduling_

We describe different subtypes of the _adopt to timetable changes_ usecase.

Change train data (commercial or operational) in a given validity

• Precondition:*
• Import data contains commercial train information with valid id and validity.
• System holds data on a train with this id, and the validity of the train covers the validity change request.

• Execution*
• The system splits the train into one with validity of the change request, and one with the remaining validity.
• The changes are applied to the first train, according to the usecase in _Import complete timetable for vehicle working scheduling_.

• Postcondition*
• The train is changed within the validity of the change request, and unchanged outside.

Change validity of a train

• Precondition:*
• Import data contains commercial train information with valid id and validity.
• System holds data on a train with this id

• Execution*
• The validity of the train is changed.