UC:TT:TimetableInformation

Timetable Information (TINF) Subschema: Timetable and Rostering   Related subschemas: IS RS  Reported by: HaCon

DRAFT railML® version TBD

For general information on use cases see UC:Use cases

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).

Characterizing Data / Charakterisierung der Daten

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: <operationalPoint>, <platform>, <platformEdge>
• 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 TT data do you expect to receive/send (elements)?

As a bare minimum the commercial view of a train (<commercialTrain> can be reduced to a <commercialTrainVariant> referencing an <itinerary> which via the reference to a <baseItinerary> consists of a sequence of <baseItineraryPoint> elements with commercially relevant stops (<stop> with an <isCommercial> element). For the each stop the following data is shown:

• published times: <times> element with scope='commercial'
• connections: <commercialConnection> element(s)
• stop description: only <stop> elements which contain a <isCommercial> elemente will be relevant including their <activities> and possible additional <activities> specified as <additionalStopInfo> elements

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

• platform
• passenger info texts
• announcements
• etc.

Further Issues

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.

Update: with the release of railML 3.2 a version of railML has been published that includes a timetable subschema and fully supports partial updates and thus also the option to refer to another train that was transmitted earlier by its UUID.

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.

Update: with the release of railML 3.2 a version of railML has been published that allows partial exports. This means that a railML with a train that references a certain platform does no long need to include that platform, but rather can refer to it directly using its UUID that was communicated with an earlier partial export that contained the infrastructure in a matching level of detail.

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.

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.)