Darwin:Schedule Element

Schedule messages

Class diagram for the RttiPPTSchedules_v3 schema

Overview

Darwin provides schedule information when a train is activated, or when new schedule, or changes to an existing schedule, are received.

Schedules cover the complete journey of a single train, and are always sent in full. Changes replace any previous version of a schedule that may have been received. Individual schedule locations may also be deleted within Darwin. Locations will not be marked as deleted, other than being absent from a new schedule.

Darwin identifies trains by RID, whereas TRUST identifies trains by a 10-character identity.

Usage

As part of an update, Darwin provides schedules when a new schedule or schedule change becomes known to Darwin, or when the schedule is activated by TRUST.

Schedule changes and new schedules are always transmitted in full. Schedule changes replace previous versions of the schedule.

Detail

A schedule may be received in two ways:

• Via the Push Port inside inside a uR element, along with a TS element, which initialises the predictions held for this schedule. An association may also be included if this train splits, joins or there is a 'next train' association
• Via the Darwin Timetable (A Darwin push port feed filtered for Schedule and Association data types only)

A schedule message comprises of an origin, zero or more intermediate locations (including both caling and passing locations) and a terminating location.

Cancellations

Cancelled locations are also included in the schedule. If the train is cancelled at the origin, or at the destination, then it will still be identified as an origin/destination but there will be an additional point that represents the live origin/destination. It is possible for cancelled locations to appear before the live origin and/or after the live destination. Locations will be listed in order from origin to destination.

There is no guarantee that locations marked as 'cancelled' will be passed by the train. For example, if a train from Staines to London Waterloo is sent via Richmond instead of via Hounslow, the calling points from Hounslow to Barnes Bridge will be cancelled but the train will never pass these locations.

When a service is re-routed to a path which then re-joins the original path (for example, Staines - Waterloo via Richmond when the schedule has it calling at stations via Hounslow and Brentford)), the location at which the service re-joins may have an 'rdelay' attribute. This attribute provides a delay value that is implied by the change to the service's route. Darwin will add this value to the forecast lateness of the service at the previous schedule location when calculating the expected lateness of arrival at this location. A client that is expecting scheduled times to chronologically increase will need to take this value into account, since the scheduled times may jump back when the service joins its original route. Adding the 'rdelay' value to the scheduled times at the location where it is defined, plus later locations, will maintain chronological order.

It is possible that Working and Public times will be provided at locations where the activity codes indicate that they are not valid. For example, if a train is terminated short of its planned destination, it will have one of its calling points modified to have a 'TF' (Train Finishes) activity to reflect the fact it is now the destination. However, the scheduled departure times will still be published to allow clients to show the planned departure has now been cancelled.

Deletions

Darwin supports the deletion of schedules in addtion to cancellations. Deletions differ from cancellations in how the results are presented to the public. Cancellations are intended to be presented on public facing systems to indicate a service which was expected to run (or call at a location) but for some operational reason is no longer expected to run (or call at location). Cancellations happen on a daily basis for a number of differing reasons.

Deletions are resevered for removing invalid or out of date schedule data and, unlike cancellations, schedules marked as deleted must not be shown or displayed on customer facing applications. Much rarer than cancellations, deletions generally occur when either significant corruption of data has led to schedules being published which do not reflect actual train running or when emergency timetables have to be published and Network Rail issue an emergency CIF file to NRE for publication through Darwin. Deleted schedules may be undeleted (republished through the push port minus the deleted attribute) to re-instate them on public displays.

As noted above, the key reason for deletions over cancellations is error control, to ensure only correct schedule information is displayed to customers.

Ordering

When determining the order of locations when cancelled locations imply an overlapping range of scheduled times, Darwin will sequence the locations based in the working arrival, pass or departure times (as applicable), in that order. For example, given a cancelled location 'A' with a scheduled time of arrival (STA) of 10:00:00 and scheduled time of departure (STD) of 10:05:00, and a second location 'B' with a scheduled passing time (STP) of 10:03:30, location 'A' will be ordered before location 'B'.

There is no absolute guarantee that live times are in chronological order, a client must correctly handle the case where a time goes backwards, or just appears to do so because it has crossed a midnight boundary. Darwin uses the following rules to handle these cases:

Time difference	Interpret as
Less than -6 hours	Crossed midnight
Between -6 and 0 hours	Back in time
Between 0 and +18 hours	Normal increasing time
Greater than +18 hours	Back in time and crossed midnight

Non-passenger trains

Darwin does not hold data on freight or engineering trains. It does support Empty Coaching Stock (ECS) movements by passenger train operators.

If the train category is one of 'OL', 'OO', 'OW', 'XC', 'XD', 'XI', 'XR', 'XX' or 'XZ', Darwin will mark the train as a passenger train using the 'isPassengerService' value. All other values will result in the train being interpreted as an ECS train.

Darwin may not hold information on charter trains. However, when a charter service is included, it will be identified by a boolean value to indicate that it is a charter.

Non-rail modes of transport

Darwin also provides bus and ferry information. The type of service will be identified by a 'status' attribute within a schedule.

Example message

<schedule rid="201411200059826" uid="P63461" trainId="2K33" ssd="2014-11-20" toc="LM">
  <sc:OR tpl="DORIDGE" act="TB" ptd="13:09" wtd="13:09" />
  <sc:PP tpl="BNHTX" wtp="13:11" />
  <sc:IP tpl="WDNYMNR" act="T " pta="13:14" ptd="13:14" wta="13:13:30" wtd="13:14" />
  <sc:DT tpl="KDRMNST" act="TF" pta="14:10" wta="14:10" />
</schedule>

Location types

Darwin has seven types of location, each with a number of attributes:

Tag	Description	act	pta	wta	wtp	ptd	wtd
OR	Origin	Y				Y	Y
OPOR	Operational origin						Y
PP	Passing point				Y
IP	Intermediate point (calls for passengers)	Y	Y	Y		Y	Y
OPIP	Operational stop (not applicable to passengers)			Y			Y
DT	Destination	Y	Y	Y
OPDT	Operational destination			Y