Train Activation: Difference between revisions
Updated train_id, added section on matching to schedule data |
PeterHicks (talk | contribs) m Flesh out details of Q/Y manual call and non-Q/Y schedules which may be manual call |
||
(20 intermediate revisions by 6 users not shown) | |||
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''. | 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'') some time before the train is due to run. See the [[Train_Call_Window|Train Call Window]] page for the current window sizes. | |||
The TRUST mainframe runs an internal process every 30 seconds throughout the day, causing potentially two lots of automatic train activation messages to be received every minute. | |||
Schedules which is ''Runs as required'', or ''Runs to terminals/yards as required'' (i.e. those with Q, Y or both in the schedule characteristics) are 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''.). Other trains may be required to be called manually depending on other characteristics. | |||
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 = | = Data structure = | ||
<pre> | |||
{ | |||
"header": { | |||
"msg_type": "0001", | |||
"source_dev_id": "", | |||
"user_id": "", | |||
"original_data_source": "TSIA", | |||
"msg_queue_timestamp": "1511528234000", | |||
"source_system_id": "TRUST" | |||
}, | |||
"body": { | |||
"schedule_source": "C", | |||
"train_file_address": null, | |||
"schedule_end_date": "2017-12-08", | |||
"train_id": "775F25MP24", | |||
"tp_origin_timestamp": "2017-11-24", | |||
"creation_timestamp": "1511528234000", | |||
"tp_origin_stanox": "", | |||
"origin_dep_timestamp": "1511535420000", | |||
"train_service_code": "25470001", | |||
"toc_id": "25", | |||
"d1266_record_number": "00000", | |||
"train_call_type": "AUTOMATIC", | |||
"train_uid": "C21373", | |||
"train_call_mode": "NORMAL", | |||
"schedule_type": "O", | |||
"sched_origin_stanox": "77301", | |||
"schedule_wtt_id": "5F25M", | |||
"schedule_start_date": "2016-12-12" | |||
} | |||
} | |||
</pre> | |||
== Header == | == Header == | ||
Line 15: | Line 54: | ||
|- | |- | ||
|source_dev_id | |source_dev_id | ||
|Always blank for an activation message | |||
|- | |||
|user_id | |||
|Always blank for an activation message | |Always blank for an activation message | ||
|- | |- | ||
Line 22: | Line 64: | ||
|original_data_source | |original_data_source | ||
|"TSIA" for an activation message | |"TSIA" for an activation message | ||
|- | |||
|msg_queue_timestamp | |||
| | |||
|} | |} | ||
Line 29: | Line 74: | ||
!Field | !Field | ||
!Description | !Description | ||
|- | |||
|schedule_source | |||
|Set to ''C'' for schedules from CIF/ITPS, or ''V'' for schedules from VSTP/TOPS | |||
|- | |||
|train_file_address | |||
|The TOPS train file address, if applicable | |||
|- | |||
|schedule_end_date | |||
|The end date of the schedule | |||
|- | |- | ||
|train_id | |train_id | ||
|The 10-character | |The 10-character identity for this train. If the schedule is due to run over multiple months, the identifier can be used on the same date every month (12th Feb, 12th March, etc). | ||
This is used in other TRUST messages to identify the 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 | ||
* '' | * ''C'' is the TSPEED value of the train (see [[TSPEED | 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 | |||
|- | |- | ||
|tp_origin_timestamp | |tp_origin_timestamp | ||
Line 46: | Line 99: | ||
'''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. | ||
|- | |- | ||
| | |creation_timestamp | ||
|The | |The timestamp (in ''milliseconds'' since the UNIX epoch) when the train was originally created in TRUST | ||
|- | |- | ||
| | |tp_origin_stanox | ||
|[[STANOX]] code | |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 | |The WTT time of departure from the originating location. A UNIX timestamp in milliseconds since the UNIX epoch, in UTC. | ||
|- | |- | ||
| | |train_service_code | ||
| | |Train service code as per schedule | ||
|- | |- | ||
| | |toc_id | ||
| | |Operating company ID as per [[TOC Codes]] | ||
|- | |- | ||
|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. This will always be ''00000'' for train activation messages, as TRUST generates the train activation message as part of the train call process, then sends the train to TOPS if appropriate, where it is assigned a D1266 record number | ||
|- | |- | ||
|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_uid | |||
|The unique ID of the schedule being activated - either a letter and five numbers, or a space and five numbers for VSTP trains | |||
|- | |- | ||
|train_call_mode | |train_call_mode | ||
| | |Always set to ''NORMAL''. Historically, this could contain ''OVERNIGHT'' if the train is called as part of an overnight batch process to activate peak period trains early, but this no longer happens | ||
|- | |- | ||
| | |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''. | ||
|- | |||
|sched_origin_stanox | |||
|[[STANOX]] code for the originating location in the schedule | |||
|- | |- | ||
| | |schedule_wtt_id | ||
| | |The signalling ID (headcode) and [[TSPEED | speed class]] of the train | ||
|- | |- | ||
| | |schedule_start_date | ||
|The | |The start date of the schedule | ||
|} | |} | ||
Line 97: | Line 144: | ||
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'') | An individual schedule is identified by the unique schedule identifier (''train_uid''), the schedule start date (''schedule_start_date'') and the schedule type (''schedule_type'', or STP Indicator in CIF). | ||
See the [[LTP_and_STP_Processes | LTP and STP Process]] page for more details. | |||
{{Navtable-DataFeeds}} | |||
[[Category:Train Movement Data]] | |||
[[Category:Train Activation Messages]] |
Latest revision as of 15:17, 14 February 2024
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) some time before the train is due to run. See the Train Call Window page for the current window sizes.
The TRUST mainframe runs an internal process every 30 seconds throughout the day, causing potentially two lots of automatic train activation messages to be received every minute.
Schedules which is Runs as required, or Runs to terminals/yards as required (i.e. those with Q, Y or both in the schedule characteristics) are 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.). Other trains may be required to be called manually depending on other characteristics.
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": { "msg_type": "0001", "source_dev_id": "", "user_id": "", "original_data_source": "TSIA", "msg_queue_timestamp": "1511528234000", "source_system_id": "TRUST" }, "body": { "schedule_source": "C", "train_file_address": null, "schedule_end_date": "2017-12-08", "train_id": "775F25MP24", "tp_origin_timestamp": "2017-11-24", "creation_timestamp": "1511528234000", "tp_origin_stanox": "", "origin_dep_timestamp": "1511535420000", "train_service_code": "25470001", "toc_id": "25", "d1266_record_number": "00000", "train_call_type": "AUTOMATIC", "train_uid": "C21373", "train_call_mode": "NORMAL", "schedule_type": "O", "sched_origin_stanox": "77301", "schedule_wtt_id": "5F25M", "schedule_start_date": "2016-12-12" } }
Header
Field | Description |
---|---|
msg_type | '0001' for an activation message |
source_dev_id | Always blank for an activation message |
user_id | Always blank for an activation message |
source_system_id | "TRUST" for an activation message |
original_data_source | "TSIA" for an activation message |
msg_queue_timestamp |
Body
Field | Description |
---|---|
schedule_source | Set to C for schedules from CIF/ITPS, or V for schedules from VSTP/TOPS |
train_file_address | The TOPS train file address, if applicable |
schedule_end_date | The end date of the schedule |
train_id | The 10-character identity for this train. If the schedule is due to run over multiple months, the identifier can be used on the same date every month (12th Feb, 12th March, etc).
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:
|
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. |
creation_timestamp | The timestamp (in milliseconds since the UNIX epoch) when the train was originally created in TRUST |
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_service_code | Train service code as per schedule |
toc_id | Operating company ID as per TOC Codes |
d1266_record_number | Either 00000 for a CIF/ITPS schedule, or the TOPS unique ID of the schedule. This will always be 00000 for train activation messages, as TRUST generates the train activation message as part of the train call process, then sends the train to TOPS if appropriate, where it is assigned a D1266 record number |
train_call_type | Either AUTOMATIC for auto-called trains, or MANUAL for manual-called trains |
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 |
train_call_mode | Always set to NORMAL. Historically, this could contain OVERNIGHT if the train is called as part of an overnight batch process to activate peak period trains early, but this no longer happens |
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. |
sched_origin_stanox | STANOX code for the originating location in the schedule |
schedule_wtt_id | The signalling ID (headcode) and speed class of the train |
schedule_start_date | The start date of the schedule |
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), the schedule start date (schedule_start_date) and the schedule type (schedule_type, or STP Indicator in CIF).
See the LTP and STP Process 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 Uses • FAQ • 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 • TIPLOC Records • 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 (BPLAN) |