Difference between revisions of "Train Activation"
Jump to navigation
Jump to search
PeterHicks (talk | contribs) m (Link to TSPEED page) |
(Updated train_id, added section on matching to schedule data) |
||
| Line 1: | Line 1: | ||
| − | 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 | + | 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 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 (a 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. | 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. | ||
| − | |||
| − | |||
= Data structure = | = Data structure = | ||
| Line 33: | Line 31: | ||
|- | |- | ||
|train_id | |train_id | ||
| − | |The 10-character unique identity for this train | + | |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 ''nnHHHHsXXX'' where: | ||
| + | |||
| + | * ''nn'' is the first two digits of the origin TIPLOC, and represents the area where the train starts | ||
| + | * ''HHHH'' 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 obfusticated number is given for freight services. This is used by other feeds, e.g. the [[TD | TD feed]], to track trains. | ||
| + | * ''s'' is the speed class of the train (see [[TSPEED | speed classes]].) | ||
| + | * ''XXX'' is three digits of uncertain meaning | ||
|- | |- | ||
|creation_timestamp | |creation_timestamp | ||
| − | |The timestamp | + | |The timestamp (in ''milliseconds'' since the UNIX epoch) 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, 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. | '''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 | ||
| − | |The | + | |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 | |sched_origin_stanox | ||
| − | |STANOX | + | |[[STANOX]] code for the originating location in the schedule |
|- | |- | ||
|schedule_start_date | |schedule_start_date | ||
| Line 55: | Line 59: | ||
|- | |- | ||
|schedule_source | |schedule_source | ||
| − | |Set to 'C' for schedules from CIF/ITPS, or 'V' for schedules from VSTP/TOPS | + | |Set to ''C'' for schedules from CIF/ITPS, or ''V'' for schedules from VSTP/TOPS |
|- | |- | ||
|schedule_type | |schedule_type | ||
| − | |Either C (Cancellation), N (New STP), O (STP Overlay) or P (WTT/LTP) | + | |Either ''C'' (Cancellation), ''N'' (New STP), ''O'' (STP Overlay) or ''P'' (Permanent i.e. as per the WTT/LTP) |
|- | |- | ||
|schedule_wtt_id | |schedule_wtt_id | ||
| − | |The headcode and [[TSPEED]] of the train | + | |The signaling ID (headcode) and [[TSPEED | speed class]] of the train |
|- | |- | ||
|d1266_record_number | |d1266_record_number | ||
| − | |Either '00000' for a CIF/ITPS schedule, or the TOPS unique ID of the schedule | + | |Either ''00000'' for a CIF/ITPS schedule, or the TOPS unique ID of the schedule |
|- | |- | ||
|tp_origin_stanox | |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 | + | |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 it is 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 | |origin_dep_timestamp | ||
| Line 73: | Line 78: | ||
|- | |- | ||
|train_call_type | |train_call_type | ||
| − | |Either 'AUTOMATIC' for auto-called trains, or 'MANUAL' for manual-called trains | + | |Either ''AUTOMATIC'' for auto-called trains, or ''MANUAL'' for manual-called trains |
|- | |- | ||
|train_call_mode | |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 | + | |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 | |toc_id | ||
| Line 87: | Line 92: | ||
|The TOPS train file address, if applicable | |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 seems to be a bug in the ''schedule_type'' field which does not always match the schedules available in the [[SCHEDULE]] feed. | ||
Revision as of 06:00, 20 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 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 (a 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.
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 nnHHHHsXXX where:
|
| 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) |
| 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 it is 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 |
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 seems to be a bug in the schedule_type field which does not always match the schedules available in the SCHEDULE feed.
