Train Activation: Difference between revisions

From Open Rail Data Wiki
m →‎Body: Corrected some field names
No edit summary
Line 1: Line 1:
== Overview ==
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, and there is no specific business event which triggers the call.  The exception to this is for schedules which are "Runs as required", or "Runs to terminals/yards as required" (flagged with Q or Y in the schedule.)  By default, it is assumed that the train will not run unless the train operator decides that it will;  the train operator will submit a message to the TRUST system and this will then cause the schedule to be activated for that day.  This process is known as 'manual call'.


In IT terms, an activation message is produced when a 'train entity' is created from a 'schedule entity'.  The train entity refers to a single run of a train, starting on one day whereas the schedule entity is potentially valid for several months at a time.  Within TRUST, this process is known as 'Train Call'
Train activations are usually received 1 - 2 hours before the train is due to run, but these trains may be manually called earlier if some details of the train are due to change.
 
For most trains, there is no corresponding business event which triggers an activation, which happens automatically (auto-call) before the train is due to run.
 
The exception to this is for schedules which are "Runs as required", or "Runs to terminals/yards as required" - flagged with Q or Y in the schedule.  By default, it is assumed that the train will not run unless the train operator decides that it will, and submits a message to the TRUST system.  This will then cause the schedule to be activated for that day, and the activation process is known as 'manual call'.
 
Train activations are usually received either one or two hours before the train is due to run, but these trains may be manually called earlier if some details of the train are due to change.


The activation message includes the schedule UID, schedule STP Indicator, and a 10-character ID (unique only within a calendar month) which is seen in all further message for a the train.   
The activation message includes the schedule UID, schedule STP Indicator, and a 10-character ID (unique only within a calendar month) which is seen in all further message for a the train.   


== Data structure ==
= Data structure =


=== Header ===
== Header ==


{| class='wikitable'
{| class='wikitable'
Line 20: Line 14:
|-
|-
|msg_type
|msg_type
|Set to '0001' for an activation message
|'0001' for an activation message
|-
|-
|source_dev_id
|source_dev_id
Line 26: Line 20:
|-
|-
|source_system_id
|source_system_id
|Set to "TRUST" for an activation message
|"TRUST" for an activation message
|-
|-
|original_data_source
|original_data_source
|Set to "TSIA" for an activation message
|"TSIA" for an activation message
|}
|}


=== Body ===
== Body ==


{| class='wikitable'
{| class='wikitable'
Line 39: Line 33:
|-
|-
|train_id
|train_id
|Set to the 10-character unique identity for this train, and will appear in other TRUST message types
|The 10-character unique identity for this train (used in other TRUST message types)
|-
|-
|creation_timestamp
|creation_timestamp
|The time, in milliseconds, when the train was originally created in TRUST
|The timestamp, in milliseconds, when the train was originally created in TRUST
|-
|-
|tp_origin_timestamp
|tp_origin_timestamp
|The date, in YYYY-MM-DD format, the train runs.  For trains activated before midnight that run after midnight, this date will be tomorrow's date - '''see the note below'''
|The date, in YYYY-MM-DD format, 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
|train_uid
Line 92: Line 87:
|The TOPS train file address, if applicable
|The TOPS train file address, if applicable
|}
|}
==== About the tp_origin_timestamp field ====
There is currently a problem with the 'tp_origin_timestamp' field due to the truncation of the timestamp.  This problem only occurs during daylight savings, and only 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.

Revision as of 09:14, 17 May 2013

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, and there is no specific business event which triggers the call. The exception to this is for schedules which are "Runs as required", or "Runs to terminals/yards as required" (flagged with Q or Y in the schedule.) By default, it is assumed that the train will not run unless the train operator decides that it will; the train operator will submit a message to the TRUST system and this will then cause the schedule to be activated for that day. This process is known as 'manual call'.

Train activations are usually received 1 - 2 hours before the train is due to run, but these trains may be manually called earlier if some details of the train are due to change.

The activation message includes the schedule UID, schedule STP Indicator, and a 10-character ID (unique only within a calendar month) which is seen in all further message for a the train.

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 (used in other TRUST message types)
creation_timestamp The timestamp, in milliseconds, when the train was originally created in TRUST
tp_origin_timestamp The date, in YYYY-MM-DD format, 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 UID of the schedule being activated - either a letter and five numbers, or a space and five numbers for VSTP trains
sched_origin_stanox STANOX of 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 (WTT/LTP)
schedule_wtt_id The headcode and TSPEED of the train (either '1', '2', '3', '4', 'C', 'M', 'N' or 'O')
d1266_record_number Either '00000' for a CIF/ITPS schedule, or the TOPS unique ID of the schedule
tp_origin_stanox If the train is due to start from a location other than the origin (i.e. it is part-cancelled), the STANOX of the location at which the train starts, otherwise the STANOX of the scheduled origin location. If this field is populated, it will be typically be in response to a VAR issued through VSTP or SCHEDULE.
origin_dep_timestamp The estimated WTT time of departure from the originating location
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