Vorlage für railML^® 3 use cases im timetable-Schema

Use case / Anwendungsfall / :

An expressive name in English; Ein aussagekräftiger Name in Deutsch;

Description / Beschreibung /

What is the application behind the use case? Which data are required? Who or which tool/application provides these data? Which data are not included (if not obvious)? Define the boundaries of the use case and the relevant data. (max. 200 words, English)

Data Flows and Interfaces / Datenflüsse und Schnittstellen /

Which data flows (from/to the use case application) exist? Which data and process interfaces exist?

References to other data models or outside-world / Referenzen zu anderen Datenmodellen einschl. Nicht-Software-Daten /

Please note here which references to other data models come with that use case. Such references (also described as key expressions) may be one single attribute or a combination of several attributes of the respective <element>. Typical examples are

<designator>s for a national register of stations (<ocp>s),
<line> and/or <track> numbers, names, codes, possibly with UIC numbers,
codes of infrastructure or interlocking elements like signals, switches, signal boxes, level crossings, interlocking routes,
types, classes, codes of <vehicle>s,
names or codes of <categories>,
train numbers, codes or names,
names of circulation plans.

Please do also think about more indirect references to the world outside of software like possibly the names of companies such as infrastructure managers.

You do normally not need to specify references which lead into the already predefined XML world such as dates (of Gregorian calendar), times (of 24 hour clock), or coordinates including heights (of a pre-defined world coordinate system) except if there are special assumptions by the use case.

Please note which references are

mandantory
optional, typical
optional, seldom

for that use case or even, if applicable, which shall be avoided or explicitly not assumed.

Please note which attributes or sets of attributes must be unique within the railML^® file defined by the use case (so in spite of they do not need to be unique by the railML^® schema).

Interference with other railML^® schemas / Interferenz mit anderen railML^®-Schemen /

infrastructure
rolling stock
interlocking
other ..............

Please note which references are

mandantory
optional, typical
optional, seldom

for that use case, from-to which <element>s the references exist (at least, typically) and if there are any references which do not use the default id-ref system of railML^®.

Characterising Data / Charakterisierung der Daten /

This section serves to specify the required data regarding certain aspects.

How often do the data change (update)?

static (not changing)
yearly
regular changes
monthly
weekly
daily
realtime (seconds)

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

tiny (attribute)
very small (element)
small (single train run)
big (line)
huge (region)
whole data set (detailed operational concept network)

Which views are represented by the data (focus)?

Long term planning (eg. for infrastructure dimensioning)
Mid term planning (eg. for yearly timetable disposition)
Short term planning (eg. for trackworks)
Real term planning (eg. for dispatching)
Statistics
Fare collection
Passenger information
...

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

Fill in your application-specific data structure elements, which you are using and want to see modelled in railML 3.
Please describe also structures which should be modeled in another way (so called "refactoring") in railML 3.
Attention: This is the most important part of this questionaire. Please define as detailed as possible, the length isn't limited here.

railML® 3 use cases im Timetable-Schema

Use case / Anwendungsfall / Scénario d’utilisation:

Passenger information at stations/Fahrgastinformation am Bahnhof

Description / Beschreibung / Description

This use case describes the exchange of data between a system for providing passenger information at a railway station and a timetable planning system. The PIS allows for display of the current schedule including information about the current state of operation such as delays, cancelation or additional trains. In order to do so the schedule as published to the passenger for the current day of operation is necessary. The completeness of this timetable information limits the accuracy of the information available to the passenger by means of the PIS. The mandatory data can be limited to the services run on the current operation day, including all stops of a train with the according arrival and departure times. Additional information for can be provided to model blocks of services (can be used to increase accuracy of forecast information), planned interconnection with other services, planned construction sites with impact on the services, etc.

Data Flows and Interfaces / Datenflüsse und Schnittstellen / Flux de données et interfaces

A PIS is a pure railML consumer.

Mandatory information imported from timetable system includes:

<train>
<trainPart>
<category>
<ocp>

Optionally imported information includes:

<track>
<formation>
<annotation>/<annotationRef>
<rostering>
<connection> (in order to provide and manage connection information for internal or external services)
<statistics>

If the topology is not imported from railML it is assumed that it is imported from a different source including an appropriate mapping to the ocp’s imported from railML.

Interference with other railML® schemas / Interferenz mit anderen railML®-Schemen / Interaction avec autres schemas railML®

Mandatory: infrastructure

Optionally: rolling stock

Characterizing Data / Charakterisierung der Daten / Caractérisation des données

This section serves to specify the required data regarding certain aspects.

How often do the data change (update)?

yearly

regular changes

daily

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

Huge - whole data set

Which views are represented by the data (focus)?

Mid term planning (eg. for yearly timetable disposition)

Short term planning (eg. for trackworks)

Passenger information

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

Element	Mandatory	Remarks
Infrastructure/operationControlPoints/ocp	X	Used for referencing with the PIS topology
<timetable>/<timetablePeriods>/<timetablePeriod>	X
<timetable>/<operatingPeriods>/<operatingPeriod>	X
<timetable>/<categories>/<category>
<timetable>/<annotations>/<annotation>
<timetable>/<trainParts>/<trainPart>/formationTT
<timetable>/<trainParts>/<trainPart>/operatingPeriodRef	X
<timetable>/<trainParts>/<trainPart>/ocpsTT	X
<timetable>/<trainParts>/<trainPart>/ocpsTT/times	X
<timetable>/<trainParts>/<trainPart>/ocpsTT/connections
<timetable>/<trainParts>/<trainPart>/ocpsTT/connections/connection
<timetable>/<trainParts>/<trainPart>/ocpsTT/connections/connection/annotationRef
<timetable>/<trainParts>/<trainPart>/ocpsTT/statistics
<timetable>/<trainParts>/<trainPart>/ocpsTT/sectionTT/runTimes
<timetable>/<trainParts>/<trainPart>/ocpsTT/stopDescription
<timetable>/<trainParts>/<trainPart>/ocpsTT/stopDescription/stopTimes
<timetable>/<trainParts>/<trainPart>/ocpsTT/stopDescription/annotationRef
<timetable>/<trainParts>/<trainPart>/annotationRef
<timetable>/trains/train	X
<timetable>/trains/train/trainPartSequence	X
<timetable>/trains/train/trainPartSequence/trainPartRef	X
<timetable>/rosterings/rostering/blockParts/blockPart
<timetable>/rosterings/rostering/blocks/block
<timetable>/rosterings/rostering/blocks/block/blockPartSequence/blockPartRef

Mit Blick auf den Usecase Fahrgastinformation im Fahrzeug sollte <annotation> u. U. erweitert werden, um das Zielsystem der Sonderinformation zu bestimmen. Ausserdem sollte m. E. nach im rostering der Übergangstyp hinterlegt werden. Das hat Einfluss auf die Prognoseberechnung, sowie die berechnung von Via Zieltexten.

Reminder: geocoordinaten am ocp sollten u.U. auch den Kodierungsstandard enthalten (WGS84, CHxxx).

D R A F T - railML^® 3 use case Timetable Information

Status

13.03.15: v0.1 - First draft by Philip Wobst (HaCon)

Next Steps

Review functional requirements with HaCon HAFAS timetable information team (P.Wobst)

Use case / Anwendungsfall / :

Timetable Information; Fahrplanauskunft;

Description / Beschreibung /

Timetable information may include a range of passenger information systems such as a journey planner and print material as well as ticketing and real-time information. This use case will focus on the definition of the minimum requirements for passenger information. The required data includes stations, timetables, service categories. Furhtermore, data regarding links among stops and interchange times can be provided if available. This data would be provided by the long term planning (LTP) or short term planning (STP) timetabling tool. For short term changes/updates the focus lies on the data relevant for passengers information only (commercial view).

Data Flows and Interfaces / Datenflüsse und Schnittstellen /

The data is provided according to the customer specific planning and subsequent publication processes. Usually fixed deadlines and timeframes exist for the typical planning horizons (please see below Which views are represented by the data (focus)?).

Interference with other railML^® schemas / Interferenz mit anderen railML^®-Schemen /

infrastructure: <ocp>
rolling stock: <formation> (?)
interlocking: -

Characterizing Data / Charakterisierung der Daten /

This section serves to specify the required data regarding certain aspects.

How often do the data change (update)?

yearly for LTP planning
regular changes for STP planning
daily for VSTP planning

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

whole data set: provide the full timetable
full time window: provide full timetable for fixed time window (e.g. next 10 days only)
changes for time window: provide only updated elements for a fixed time window (e.g. next 30 days)

Which views are represented by the data (focus)?

LTP: the next yearly timetable - e.g. availability of the next yearly timetable 6 months ahead of time
STP: short term planning changes to the current timetable - e.g. updated timetable information is provided for days +2 to +60

There is no fixed process for the exchange of data with a passenger information system. Whether or not it makes sense to identify and supply updates to a previous export file strongly depends on the capabilities of the systems involved (further discussion needed). Possible export options could be:

Full: a full timetable is provided for a specific time window
Update: only changes to the last export are provided for a specific time window (for the update process all files need to be handled in the correct sequence!)

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

As a bare minimum the commercial view of a <train> can be reduced to one <trainPart> with a sequence of <ocpTT> elements with commercially relevant stops (<stopDescription> with commercial='true'). For the each stop the following data is shown:

published times: <times> element with scope='published'
connections: <connection> element(s) with connType='commercial'
stop description: only <stopDescription> elements with commercial='true' will be relevant including their <stopTimes> element

In addition the following data would be useful for passenger information:

platform
etc.

Handling of connections for partial exports

Depending on the process in the receiving system it might be necessary to provide only a single train with all the relevant connections. However, without the connected trains the current connection element is not valid and the referenced IDs cannot be used to map the connected trains/trainParts.

Referencing platforms in the timetable

Currently the track and platform information shall be provided via the trackRef attribute linking the corrosponding element in the infrastructure. However, this requires quite a detailed infrastructure export. It should be possible to provide the commercial stations and platforms needed for the timetable export only.

Handling of cancellations, partial cancellations, extra trains

Relevant changes to existing trains need to be represented in the export file. A complete list of changes needs to be defined. This will include the following changes:

full cancellation of a train
partial cancellation - i.e. of a trainPart
extra train or trainPart
cancelled stop
extra stop
etc.

Discussion

Minor changes to the <formationTT> are not necessarily relevant and could be ignored (only the category is relevant) or should the formationTT element be optional?

Terms and Expressions

LTP = long term planning: the yearly timetable(s)
STP = short term planning: changes to the current production timetable up to the point that changes can be published to downstream systems (passenger information, train control, train operators, etc.)

Below the this line begins the proposal for a railML^® use case

Use case / Anwendungsfall / :

A timetable for a competition (call for proposals) Ausschreibungsfahrplan;

Description / Beschreibung /

The use case describes a timetable which is transferred

from an authority issuing the invitation to bid
to any potential bidder

with the aim to describe which timetable is asked for in the competition, i. e. the amount of trains, their routes and (regular) operating days and possible any other properties of the trains such as services or minimum seating capacities.

The background behind such a data exchange with railML^® files is, especially at competitions of large production amount, it will be easier for the bidders to reproduce the timetable in their own software systems. This allows a quicker calculation e. g. of the number of vehicles necessary or, at least, the price. Time consuming and potential faulty manual transcription of the timetable shall be avoided. The usage of railML^® for such a data exchange (instead of more special file formats) shall keep this procedure transparent and non-discriminating.

The main intention of the use case is passenger traffic since the number of trains and the extent of the timetables is typically more complex than in freight traffic. But it may also be used for freight traffic.

Data Flows and Interfaces / Datenflüsse und Schnittstellen /

The use case covers a one-direction data exchange only; a possibly offered timetable (from bidder to authority) is not part of this use case.

The use case covers the exchange of the following data in general:

<train> elements with their routes and timings (in associated <trainPart> elements),
<ocp> elements to describe the references from the trains to the infrastructure (stations).

There are several degrees of complexity of which the use case may be used:

with minimum infrastructure (general <ocp>s only) or all necessary infrastructure (<lines>, <track>s, gradients, speeds a. s. o.),
with or without <vehicle>s and <formation>s,
with or without a timetable period,
with or without circulation plans.

The following description refers to the usage of railML^® model 2.2 for this use case since there is no version 3 in use at time of writing.

Infrastructure

From the current experience, it is typical that railML^® files of that use case contain a minimum infrastructure only. The main reason for that may be that normally the authority issuing is not the infrastructure manager. Nevertheless, general infrastructure data are quite published in a competion as a kind of “passing through” issue from the infrastructure manager(s) through the issuing authority. So it may be that they are included in the same railML^® with the timetable. With the advent of national infrastructure registers, it is likely that such registers are referred or extracted in another, say, railML^® file.

Anyway, <ocp>s must be included since without them no railML^® <timetable> file is possible. <lines> and <tracks> are included if necessary to exactly describe the train’s route in complex infrastructure situations (areas of parallel lines). More infrastructure data (gradients, speed a. s. o.) are rather a matter of the previous paragraph.

It shall be assumed that a timetable of this use case is checked by the infrastructure manager(s) in advance and therefore planned in detail.

If more infrastructure is included, its scope is macroscopic.

Timetable period

Typically there is no <timetablePeriod> for timetables of this use case. The timetable is valid not for a certain but a number of years which are not specified in the railML^® file.

The <operatingPeriod>s of the trains have regular weekdays only with no special operating days and no certain date references. The timetables are typically not planned with regard to public holidays or such; the amount of train kilometers a. s. o. is only calculated on a statistic basis (flat number of operating days, statistic year).

However, there may be a <timetablePeriod> defined for one year as a place-holder for all the years. This is common practice if seasonised trains operate, e. g. school trains or summer-only trains.

Theoretically, there may be a very long <timetablePeriod> for all the years the timetable shall be valid. Since this leads to very long bitmasks of <operatingPeriod>s with normally no additional benefit it is not common and not recommended.

<vehicle>s and <formation>s

If the supply of vehicles is component of the competition, often there are neither vehicles nor formations given with the timetable data because this is treated necessary for non-discrimination. However, for practical reasons, normally there is a master vehicle at least for run-time calculation. This is often the slowest acceptable vehicle and may be a theoretical one (a coefficient of power and mass only). It is common to publish this master vehicle with the call for tenders. If the vehicles are allocated there is no reason to exclude them from the timetable.

So, there may or may not be <rollingstock> data in the railML^® file.

Circulation plans

Typically the construction of circulation plans is up to the bidder, so no circulation plans are included. This is likely to be because neither the type (and capacity) of the vehicle(s) nor the location of the depot(s) are known in advance. On the contrary, and even if the vehicles are allocated, circulation plans are expected from the bidders to show their competence.

References to other data models or outside-world / Referenzen zu anderen Datenmodellen einschl. Nicht-Software-Daten /

In any case, <ocp>s refer to one or more national register(s) of stations or other operational places by their <designator> elements. So, it is mandatory to use at least one <designator> with a pre-defined register. For Germany, this is currently register='RL100'.

If <line> elements are included, it must be possible to identify the <line> elements with the lines of the corresponding infrastructure manager. This can be done directly from attributes of the <line> elements or indirectly from attributes of the <track> elements. For Germany, currently the <line>.code attribute has to contain the VzG-Streckennummer, so it must be a 4-digit integer value.

If <track> elements are included, it must be possible to identify the <track> elements with the tracks of the corresponding infrastructure manager. This can be done by a unique attribute of the <track> elements (like code) or by a direction of the track in conjunction with the <line>s. For Germany, if <track> elements are included, also <line> elements have to be included. Each <track> element must be part of (referenced by) exactly one <line> element.

With regard to neutral (non-discriminating) data, the <category> elements do not necessarily need to refer to actual train categories of a certain operator. They can refer to categories of the corresponding infrastructure manager if applicable - or they can be missing or even contain "phantasy" categories. For Germany, since the kind of operator can still be deduced from the DB Netz’s category codes, it is likely to have "neutralised" categories. If <category>s are used, their attribute code has to be unique.

Since the timetable is more a virtual than an actual one, <train> elements are not necessarily to be identified externally. So, train codes nor numbers need not to be given. However, for reasons of practicability, it shall be possible to uniquely identify a train. For Germany, operational trains need to have a unique set of the attributes trainNumber, additionalTrainNumber, and scope (default railML^® rules). Commercial trains need to have a unique trainNumber (additionalTrainNumber and scope do not apply here).

Interference with other railML^® schemas / Interferenz mit anderen railML^®-Schemen /

<infrastructure> (mandatory)
<rollingstock> (optional)

<infrastructure> is referenced

from <ocpTT>.ocpRef to <ocp>.id (mandatory),
from <sectionTT>.lineRef to <line>.id (optional),
from <sectionTT>.<trackRef>.ref to <track>.id (optional)
from <trainPartSequence>.<speedProfileRef>.ref to <speedProfile>.id (optional)

<rollingstock> is referenced

from <formationTT>.formationRef to <formation>.id (optional)
from <rostering>.formationRef to <formation>.id (optional)
from <rostering>.vehicleRef to <vehicle>.id (optional)

Characterising Data / Charakterisierung der Daten /

This section serves to specify the required data regarding certain aspects.

How often do the data change (update)?

static (not changing)
in cases of error-corrections: weekly .. daily in rare cases during a short period (of submission); will probably be handled by a complete data renewal (overriding)

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

infrastructure: medium (region), macroscopic
timetable: medium (region; several up to some hundred trains); operatingPeriod: tiny (one or none)
rolling stock: small (none, one or a few vehicles and formations)

Which views are represented by the data (focus)?

Long term planning (starting typically 1..5 years in future with a duration of typically 3..15 years)

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

Used elements (extract - more is allowed):

Element	Mandatory	Remarks
<infrastructure>.<tracks>.<track>.<trackTopology>.<trackBegin>.<macroscopicNode>.ocpRef <infrastructure>.<tracks>.<track>.<trackTopology>.<trackEnd>.<macroscopicNode>.ocpRef <infrastructure>.<tracks>.<track>.<trackTopology>.<crossSections>.<crossSection>.ocpRef	*1	used to define the conjunction between <track>s and <ocp>s if <track>s are included
<infrastructure>.<trackGroups>.<line>.code	*2	used to identify a line of the Infrastructure Manager(s)
<infrastructure>.<trackGroups>.<line>.infrastructureManagerRef		used to identify the Infrastructure Manager(s) at least if more than one is involved
<infrastructure>.<trackGroups>.<line>.<trackRef>.ref	*2	used to define the conjunction between <line>s and <tracks>s
<infrastructure>.<operationControlPoints>.<ocp>.<designator>.register / .entry	x	used to identify an <ocp> of the Infrastructure Manager(s)
<timetable>.<timetablePeriods>.<timetablePeriod>.startDate / .endDate
<timetable>.<timetablePeriods>.<timetablePeriod>.<holidays>.<holiday>.holidayDate
<timetable>.<operatingPeriods>.<operatingPeriod>	x
<timetable>.<operatingPeriods>.<operatingPeriod>.timetablePeriodRef / .bitMask		must be used if a <timetablePeriod> is included only
<timetable>.<operatingPeriods>.<operatingPeriod>.<operatingDay>.operatingCode	x
<timetable>.<operatingPeriods>.<operatingPeriod>.<operatingDay>.<operatingDayDeviance>.operatingCode / .holidayOffset / .ranking
<timetable>.<operatingPeriods>.<operatingPeriod>.<specialService>.type / .startDate / .endDate		can be used if a <timetablePeriod> is included only
<timetable>.<categories>.<category>.code		used to identify a train type or category of the Infrastructure Manager(s) or a virtual one
<timetable>.<trainParts>.<trainPart>	x
<timetable>.<trainParts>.<trainPart>.<formationTT>.formationRef
<timetable>.<trainParts>.<trainPart>.<formationTT>.<passengerUsage>.<places>.category / .count		may be used to define a minimum necessary seating capacity
<timetable>.<trainParts>.<trainPart>.<formationTT>.<passengerUsage>.<service>.category / .count		may be used to define a minimum acceptable service
<timetable>.<trainParts>.<trainPart>.<operatingPeriodRef>	x
<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.ocpRef	x
<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<times scope='scheduled' …>	x
<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<times scope='scheduled'>.arrival / .departure> / .arrivalDay / .departureDay	(x)	mandatory in context as usual
<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<sectionTT>.lineRef		must be used if <line>s are included
<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<sectionTT>.<trackRef>.ref		must be used if <track>s are included
<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<stopDescription>.commercial / .stopOnRequest
<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<stopDescription>.<stopTimes>.minimalTime	(x)	mandatory in context for ordered traffic stops
<timetable>.<trains>.<train type='operational'>	x	each <trainPart> must be covered by exactly one operational train
<timetable>.<trains>.<train type='commercial'>		used if operational trains are not sufficient to describe the timetable (especially with train coupling and sharing)
<timetable>.<trains>.<train>.trainNumber / .scope / .additionalTrainNumber
<timetable>.<trains>.<train>.<trainPartSequence>	x
<timetable>.<trains>.<train>.<trainPartSequence>.sequence	x
<timetable>.<trains>.<train>.<trainPartSequence>.<trainPartRef>	x
<timetable>.<trains>.<train>.<trainPartSequence>.<trainPartRef>.ref / .position	x

*1 mandatory if <track>s are included
*2 mandatory if <line>s are included

Additional requirements

Each <trainPart> must be covered by exactly one operational train. If commercial trains are given, each <trainPart> must be covered by exactly one commercial train.

If seating capacities or services are defined at <trainPart>s and at <formation>s or <vehicle>s, later defined values override earlier defined values in the meaning of concretising. Formations override vehicles, train parts override formations. In this special use case, the values at <trainPart>s shall be treated as minimum necessary values and the values at <formation>s or <vehicle>s as planned capacity of the master vehicle(s).

If minimum seating capacities differ for certain operating days (at the same train and route section), the corresponding train has to be split in several <trainPart>s with parallel route and disjunctive operating days. Each <trainPart> can refer to a different seating capacity. All these <trainPart>s have to be joined in the corresponding <trainPartSequence>s.

(This procedure also applies to other properties of trains and train parts. Train parts with disjunctive operating days do not have to be mixed with coupled train parts, which apply to train coupling, sharing and "strengthening". See corresponding descriptions for further information.)

Open Issues

Usage of tTimeScope="earliest" / ="latest" instead of or additionally to ="scheduled".
Defining (planned and/or expected) connections between the <train>s involved and also to other (external) <train>s.

Improvements for further versions

1)
To be exactly, the current railML^® does not allow a distinction between values which are minimum necessary and which are planned. There may be a difference between them especially in the use case of timtables for competitions. This applies to

arrival / departure / run times (planned run time with a master formation vs. maximum accepable run time with any other formation)
seating capacities (planned seating capacity with a master formation vs. minimum accepable seating capacity)
connections

and possibly more.

2)
In the current implementation of railml^® 2.x it is not clearly defined how two <trainPart> elements in succeeding <trainPartSequence>s must be chained to model a running through service (group of vehicles). One approach is to chain all <trainPart> elements with the same key (code, name, etc.) in an order whereat the last referenced <ocp> of the current <trainPart> is the same as the first <ocp> of the following <trainPart>. (This order can already be deduced from commercial train elements.) A better modelling for this aspect is, in the author’s opinion, to use the concept of commercial trains in a different way than currently described in Wiki: Each commercial train should model exactly one sequence of <trainPart> elements. Today it may contain several "parallel" sequences of <trainPart> elements at the same time, which makes it impossible to figure out which <trainPart> elements of two succeeding <trainPartSequence>s must be linked together.

3)
The redundancy of repeated arrival and departure times of coupled <trainPart>s shall be avoided e. g. by extracting "itineraries" (refactoring).

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:

Determine Validities
Import the traffic network data and routing
Import rollingstock data
Import itineraries
Import track occupancies
Import train parts
Import trains
Import vehicle workings
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.

User:RailML Orga Governance

Contents

Vorlage für railML^® 3 use cases im timetable-Schema

D R A F T - railML^® 3 use case Timetable Information

Import complete timetable for vehicle working scheduling and vehicle workings =

Description

Data Flows and Interfaces

Interference with other railML® schemas

Characterizing Data

How often do the data change (update)?

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

Which views are represented by the data (focus)?

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

Determine validities

Import traffic network and routing data

Import rollingstock data

Import train

Import commercial train

Import operational train

Import operational train parts

Import itineraries

Import vehicle workings

Import rosterings

Adopt vehicle working scheduling to timetable changes

Description

Data Flows and Interfaces

Interference with other railML® schemas

Characterizing Data

How often do the data change (update)?

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

Which views are represented by the data (focus)?

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

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

Change validity of a train

Navigation menu

User:RailML Orga Governance

Vorlage für railML® 3 use cases im timetable-Schema

D R A F T - railML® 3 use case Timetable Information

Import complete timetable for vehicle working scheduling and vehicle workings =

Description

Data Flows and Interfaces

Interference with other railML® schemas

Characterizing Data

How often do the data change (update)?

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

Which views are represented by the data (focus)?

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

Determine validities

Import traffic network and routing data

Import rollingstock data

Import train

Import commercial train

Import operational train

Import operational train parts

Import itineraries

Import vehicle workings

Import rosterings

Adopt vehicle working scheduling to timetable changes

Description

Data Flows and Interfaces

Interference with other railML® schemas

Characterizing Data

How often do the data change (update)?

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

Which views are represented by the data (focus)?

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

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

Change validity of a train

Navigation menu

Search

Vorlage für railML^® 3 use cases im timetable-Schema

D R A F T - railML^® 3 use case Timetable Information