Difference between revisions of "Train Activation"

From Open Rail Data Wiki
Jump to navigation Jump to search
m (Updated activation message documentation)
Line 1: Line 1:
 
== Overview ==
 
== Overview ==
  
−
The Train Activation message is used to link a 10-character unique train identity to a schedule.  This unique identity is used in all other message types to refer to the train.
+
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'
  
−
Unique identities are guaranteed unique only within a calendar month, as the final two digits are the day of the month in which the train ran.
+
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.
  
−
=== Linking a schedule to a unique identity ===
+
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'.
  
−
Schedules are uniquely identified by UID, start date and STP indicator.  The activation message has three fields - 'train_uid', 'schedule_start_date' and 'schedule_type'.  To find the schedule that a train is running to, look these up in your timetable database.
+
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.
  
−
=== Auto and Manual Call ===
+
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.
−
 
 
−
Internally, the activation process is known as 'calling', and a train may be called in one of two ways:
 
−
 
 
−
* The majority of schedules are set up as Auto Call.  Activation messages will automatically be sent for them around an hour before the scheduled departure time.
 
−
* Some schedules are set up as Manual Call where a train may operate more than one schedule - usually a freight train which has three timetables available with different destinations, but will only run to one specific one depending on demand on the day.
 
−
 
 
−
There is no difference in handling Auto and Manually called trains.
 
  
 
=== Data structure ===
 
=== Data structure ===
Line 40: Line 33:
  
 
==== Body ====
 
==== Body ====
−
 
  
 
{|
 
{|
 
!Field
 
!Field
 
!Description
 
!Description
−
|-
 
−
|schedule_source
 
−
|Set to 'C' for CIF schedules, or 'V' for VSTP schedules
 
−
|-
 
−
|train_file_address
 
−
|Always blank
 
−
|-
 
−
|schedule_end_date
 
−
|The end date of the schedule as per CIF or VSTP
 
 
|-
 
|-
 
|train_id
 
|train_id
 
|Set to the 10-character unique identity for this train, and will appear in other TRUST message types
 
|Set to the 10-character unique identity for this train, and will appear in other TRUST message types
 +
|-
 +
|creation_timestamp
 +
|The time, 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
 
|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
 
|-
 
|-
−
|creation_timestamp
+
|train_uid
−
|The time in milliseconds of the Activate Message
+
|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.  May not be nil
 +
|-
 +
|sched_start_date
 +
|The start date of the schedule
 
|-
 
|-
−
|tp_origin_stanox
+
|schedule_end_date
−
|STANOX of the originating location, but may be nil
+
|The end date of the schedule
 
|-
 
|-
−
|origin_dep_timestamp
+
|schedule_source
−
|Scheduled departure time
+
|Set to 'C' for schedules from CIF/ITPS, or 'V' for schedules from VSTP/TOPS
 
|-
 
|-
−
|train_service_code
+
|schedule_type
−
|Train service code as per schedule
+
|Either C (Cancellation), N (New STP), O (STP Overlay) or P (LTP)
 
|-
 
|-
−
|toc_id
+
|sched_wtt_id
−
|Operating company ID as per [[TOC_Codes]]
+
|The headcode and TSPEED of the train (either '1', '2', '3', '4', 'C', 'M', 'N' or 'O')
 
|-
 
|-
 
|d1266_record_number
 
|d1266_record_number
−
|'00000' represents a CIF schedule, any other value indicates a VSTP schedule
+
|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
 +
|-
 +
|origin_dep_timestamp
 +
|The estimated WTT time of departure from the originating location
 
|-
 
|-
 
|train_call_type
 
|train_call_type
−
|'AUTOMATIC' for trains which are auto-called, or 'MANUAL' for trains which are manually called (e.g. run-as-required)
+
|Either 'AUTOMATIC' for auto-called trains, or 'MANUAL' for manual-called trains
−
|-
 
−
|train_uid
 
−
|Schedule UID being activated.  Either a letter and five numbers for a CIF schedule, or a space and five numbers for a VSTP schedule where the numbers are the same as the d1266_record_number field
 
 
|-
 
|-
 
|train_call_mode
 
|train_call_mode
−
|Always set to 'NORMAL'
+
|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
 
|-
 
|-
−
|schedule_type
+
|toc_id
−
|One of 'C', 'N', 'O', 'P' as per the STP indicator in the schedule
+
|Operating company ID as per [[TOC_Codes]]
 
|-
 
|-
−
|sched_origin_stanox
+
|train_service_code
−
|STANOX of the originating location.  May not be nil
+
|Train service code as per schedule
 
|-
 
|-
−
|sched_wtt_id
+
|train_file_address
−
|Working Timetable (WTT) identifier - the train reporting number with either '1', '2', '3', '4', 'C', 'M', 'N' or 'O' appended
+
|The TOPS train file address, if applicable
−
|-
 
−
|sched_start_date
 
−
|The start date of the schedule
 
 
|}
 
|}

Revision as of 13:08, 17 January 2013

Overview

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'

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.

Data structure

Header

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

Body

Field Description
train_id Set to the 10-character unique identity for this train, and will appear in other TRUST message types
creation_timestamp The time, 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
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. May not be nil
sched_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 (LTP)
sched_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
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
Retrieved from ‘https://wiki.openraildata.com//index.php?title=Train_Activation&oldid=294’