Difference between revisions of "Train Activation"

From Open Rail Data Wiki
Jump to navigation Jump to search
m (Correction to 'tp_origin_stanox' notes)
m (Hint about a bug in the schedule_type field.)
Line 67: Line 67:
 
|-
 
|-
 
|schedule_type
 
|schedule_type
|Either ''C'' (Cancellation), ''N'' (New STP), ''O'' (STP Overlay) or ''P'' (Permanent i.e. as per the WTT/LTP)
+
|Either ''C'' (Cancellation), ''N'' (New STP), ''O'' (STP Overlay) or ''P'' (Permanent i.e. as per the WTT/LTP) '''Note:''' There is a bug that causes this field to be populated incorrectly. The value ''O'' should be ''P'' and ''P'' should be ''O''.
 
|-
 
|-
 
|schedule_wtt_id
 
|schedule_wtt_id
Line 102: Line 102:
 
The train activation message is the only message type which directly links a signalling ID to a schedule.  There are ways to infer this relationship using other data, but it is much more difficult.   
 
The train activation message is the only message type which directly links a signalling ID to a schedule.  There are ways to infer this relationship using other data, but it is much more difficult.   
  
An individual schedule is identified by the unique schedule identifier (''train_uid'') and the schedule start date (''schedule_start_date'').  These will identify one or more schedules from the [[SCHEDULE]] data feed.  If there are several schedules that have the same start date, then the one with the lowest STP indicator character is the valid one.  '''Note:''' at present, there seems to be a bug in the ''schedule_type'' field which does not always match the schedules available in the [[SCHEDULE]] feed.
+
An individual schedule is identified by the unique schedule identifier (''train_uid'') and the schedule start date (''schedule_start_date'').  These will identify one or more schedules from the [[SCHEDULE]] data feed.  If there are several schedules that have the same start date, then the one with the lowest STP indicator character is the valid one.  '''Note:''' at present, there is a bug in the ''schedule_type'' field which does not always match the schedules available in the [[SCHEDULE]] feed. Simple workaround is to change a ''O'' value to ''P'' or vice versa.
  
 
See the [[HowSchedulingWorks | how scheduling works]] page for more details.
 
See the [[HowSchedulingWorks | how scheduling works]] page for more details.

Revision as of 20:41, 29 March 2016

An activation message is produced when a train entity is created from a schedule entity by the TRUST system. The train entity refers to a single run of a train on a specific day whereas the schedule entity is potentially valid for several months at a time. Within TRUST, this process is known as Train Call.

Most trains are called automatically (auto-call) before the train is due to run, either 1 or 2 hours depending on the train's class. The TRUST mainframe runs an internal process every 30 seconds throughout the day, causing potentially two lots of train activation messages to be received every minute.

Schedules which is Runs as required, or Runs to terminals/yards as required (flagged with Q or Y in the schedule) are usually called manually - the train operator will submit a message to the TRUST system and this will then cause the schedule to be activated for that day (a process is known as manual call.)

Any train may be manually called some hours in advance if the train is to be cancelled (e.g. a cancellation of a 6pm service which is decided at 8am will result in an auto-call train being manually called and then cancelled).

Data structure

Header

Field Description
msg_type '0001' for an activation message
source_dev_id Always blank for an activation message
source_system_id "TRUST" for an activation message
original_data_source "TSIA" for an activation message

Body

Field Description
train_id The 10-character unique identity for this train

This is used in other TRUST messages to identify the train. The train activation message links the train_id with a particular schedule. train_id is of the format AABBBBCDEE where:

  • AA is the first two digits of the origin STANOX, and represents the area where the train starts
  • BBBB is the signalling ID (headcode) used within the data feeds to represent the train - for passenger trains this is the actual service headcode, but an obfuscated number is given for freight services. This is used by other feeds, e.g. the TD feed, to track trains.
  • C is the TSPEED value of the train (see valid TSPEED values) - note: this does not refer to the actual speed (velocity) of the train
  • D is the Call Code of the train - a letter or number based on the departure time from the origin
  • EE is the day of the month on which the train originated
creation_timestamp The timestamp (in milliseconds since the UNIX epoch) when the train was originally created in TRUST
tp_origin_timestamp The date, in YYYY-MM-DD format, that the train runs. For trains activated before midnight that run after midnight, this date will be tomorrow's date.

Note: there is currently a problem with the tp_origin_timestamp field due to the truncation of the timestamp. This only occurs during daylight savings for trains which start their journey between 0001 and 0200 the next day. To work around this problem, use the date in the origin_dep_timestamp field.

train_uid The unique ID of the schedule being activated - either a letter and five numbers, or a space and five numbers for VSTP trains
sched_origin_stanox STANOX code for the originating location in the schedule
schedule_start_date The start date of the schedule
schedule_end_date The end date of the schedule
schedule_source Set to C for schedules from CIF/ITPS, or V for schedules from VSTP/TOPS
schedule_type Either C (Cancellation), N (New STP), O (STP Overlay) or P (Permanent i.e. as per the WTT/LTP) Note: There is a bug that causes this field to be populated incorrectly. The value O should be P and P should be O.
schedule_wtt_id The signaling ID (headcode) and speed class of the train
d1266_record_number Either 00000 for a CIF/ITPS schedule, or the TOPS unique ID of the schedule
tp_origin_stanox The STANOX code of the origin of the train

If the train is due to start from a location other than the scheduled origin (i.e. it is part-cancelled), this will be the STANOX of the location at which the train starts. Otherwise this field will be empty and you should refer to the 'sched_origin_stanox' field. If this field is populated, it will be typically be in response to a VAR issued through VSTP or SCHEDULE.

origin_dep_timestamp The WTT time of departure from the originating location. A UNIX timestamp in milliseconds since the UNIX epoch, in UTC.
train_call_type Either AUTOMATIC for auto-called trains, or MANUAL for manual-called trains
train_call_mode Set to NORMAL for a train called normally, or OVERNIGHT if the train is called as part of an overnight batch process to activate peak period trains early
toc_id Operating company ID as per TOC Codes
train_service_code Train service code as per schedule
train_file_address The TOPS train file address, if applicable

Linking with Schedule Data

The train activation message is the only message type which directly links a signalling ID to a schedule. There are ways to infer this relationship using other data, but it is much more difficult.

An individual schedule is identified by the unique schedule identifier (train_uid) and the schedule start date (schedule_start_date). These will identify one or more schedules from the SCHEDULE data feed. If there are several schedules that have the same start date, then the one with the lowest STP indicator character is the valid one. Note: at present, there is a bug in the schedule_type field which does not always match the schedules available in the SCHEDULE feed. Simple workaround is to change a O value to P or vice versa.

See the how scheduling works page for more details.


Network Rail Open Data Feeds
Data Feeds About the Feeds Account States Durable Subscriptions Example Code ( PHP / C# / Java / Ruby / Node.js) • Advanced UsesFAQ Release Notes
RTPPM RTPPM Feed
Train Movements Train Movements Feed Train Activation Train Cancellation Train Movement Train Reinstatement Change of Origin Change of Identity Change of Location TSPEED Field Planned Cancellations Cancellation Codes
TD TD Feed C-Class Messages S-Class Messages Train Describers TD Berths
VSTP VSTP Feed
TSR TSR Feed Route Codes
SCHEDULE SCHEDULE Feed Schedule and Location Records Association Records CIF Codes How Scheduling Works Allowances
Reference Data Reference Data Feed TOC Codes CIF Codes Delay Attribution Codes Identifying Locations (STANOX, TIPLOC, NLC and 3-Alpha Codes) STANOX Geographical Areas Train Planning data