TD: Difference between revisions

From Open Rail Data Wiki
← Older editNewer edit →
m →‎S-Class: Fix broken link
Added details of TD fields and messages
Line 3: Line 3:
== Overview ==
== Overview ==


The Train Describer feed provides low-level detail about the position of trains and their train reporting number through a network of berths.  Usually, but not always, a berth is associated with a signal - but there are locations (such as terminal platforms at stations) where there may be more than one berth.
The Train Describer feed provides low-level detail about the position of trains and their train reporting number through a network of berths.  Usually, but not always, a berth is associated with a signal - but there are locations (such as terminal platforms at stations) where there may be more than one berth.  From each berth, there are zero or more other berths which a train description may step in to.  A step between berths represents movement of the train from one berth to another.  Some of these steps may be one-way, some may be two-way.


From each berth, there are zero or more other berths which a train description may move, or 'step' in to.  Some of these may be one-way, some may be two-way.
To access the TD data feed, you must select and subscribe to the appropriate geographical topic(s) on the ''My Feeds'' page on the Data Feeds website (see the [[About_the_feeds|about the feeds]] page.


=== Topics ===
== Topics ==


Message are available in geographic feeds, as well as an country-wide feed. The topic names are as follows:
ActiveMQ topics are provided for signalling in specific geographic areas, as well as a topic representing all TD data in the country.


{| class="wikitable"
{| class="wikitable"
Line 64: Line 64:
|}
|}


=== Message types ===
= Message types =


The Train Describer feed has seven message types:
The Train Describer feed has seven message types, split into two classes.


* '''CA''' - Berth Step, where a description moves 'from' a berth, 'to' another berth
== C Class Messages: Berth Movement ==
* '''CB''' - Berth Cancel, where a description is removed from a berth
* '''CC''' - Berth Interpose, where a description is interposed (placed in to) a berth
* '''CT''' - Heartbeat
* '''SF''' - Signalling data update
* '''SG''' - Signalling data refresh
* '''SH''' - Signalling data refresh finished


The CA, CB, CC and CT messages are referred to as C-Class, and the SF, SG and SH messages are referred to as S-Class.
{| class="wikitable"
! Type
! Name
! Details
|-
|CA
|Berth Step
|The CA message is a 'step' message. 
This moves the description from the 'from' berth, in to the 'to' berth, cancelling the description in the 'from' berth and overwriting any description in the 'to' berth.
|-
|CB
|Berth Cancel
|The CB message is a 'cancel' message.
This cancels the description in the 'from' berth.
|-
|CC
|Berth Interpose
|The CC message is an 'interpose' message. 
This inserts the description in to the 'to' berth, overwriting any description in the 'to' berth.
|-
|CT
|Heartbeat
|The CT message is a 'heartbeat' message, periodically sent from a train describer.
|-
|}


=== C-Class ===
=== Message Format ===


Messages are sent in JSON format, as follows:
Messages are sent in JSON format, as follows:
Line 87: Line 105:
* {"CT_MSG":{"time":"1349696911000", "area_id":"SA", "msg_type":"CT", "report_time":"1249"}}
* {"CT_MSG":{"time":"1349696911000", "area_id":"SA", "msg_type":"CT", "report_time":"1249"}}


==== CA message ====
=== Message Fields ===


The CA message is a 'step' message.  This moves the description from the 'from' berth, in to the 'to' berth, cancelling the description in the 'from' berth and overwriting any description in the 'to' berth.
{| class="wikitable"
!Field
!CA
!CB
!CC
!CT
!Details
|-
|time
|•
|•
|•
|•
|Message time
UNIX timestamp ''in milliseconds'' since the UNIX epoch
|-
|area_id
|•
|•
|•
|•
|Alphanumeric code representing the TD area that the message originates from
|-
|msg_type
|•
|•
|•
|•
|Type of message
Can be CA_MSG, CB_MSG, CC_MSG or CT_MSG
|-
|from
|•
|•
|
|
|''From'' berth
|-
|to
|•
|
|•
|
|''To'' berth
|-
|descr
|•
|•
|•
|
|Train description
Four-letter alphanumeric code representing the headcode or description of the train
|-
|report_time
|
|
|
|•
|Reporting time
|-
|}


==== CB message ====
== S Class Messages: Signalling Data ==


The CB message is a 'cancel' message.  This cancels the description in the 'from' berth.
{| class="wikitable"
 
! Type
==== CC message ====
! Name
 
! Details
The CC message is an 'interpose' message.  This inserts the description in to the 'to' berth, overwriting any description in the 'to' berth.
|-
 
|SF
==== CT message ====
|Signalling Update
 
|Updates the signalling data for a specified set of signalling elements
The CT message is a 'heartbeat' message, periodically sent from a train describer.
|-
 
|SG
=== S-Class ===
|Signalling Refresh
 
|Part of a set of SG messages which update the whole set of signalling data for TD area.  Terminated by an SH message.
Messages are sent in JSON format, as follows:
|-
 
|SH
* {"SF_MSG":{"time":"1349696911000", "area_id":"WJ", "msg_type:"SF", "address":"3E", "data":"18", "report_time":"073814"}}
|Signalling Refresh Finished
* {"SG_MSG":{"time":"1349696911000", "area_id":"WJ", "msg_type:"SG", "address":"30", "data":"900000C0", "report_time":"073814"}}
|Last message in a signalling refresh
* {"SH_MSG":{"time":"1349696911000", "area_id":"WJ", "msg_type:"SH", "address":"30", "data":"900000C0", "report_time":"073814"}}
|-
|}


S-Class messages report the status of the following signalling elements:
S-Class messages report the status of the following signalling elements:
Line 122: Line 201:
Not all train describers support S-Class data, and those that do may only support a subset of the available groups of data.  The [[List of Train Describers]] shows S-Class support.
Not all train describers support S-Class data, and those that do may only support a subset of the available groups of data.  The [[List of Train Describers]] shows S-Class support.


==== Interpreting S-Class data ====
=== Message Format ===
 
Messages are sent in JSON format, as follows:


Consider the S-Class data as a set of 2,048 bits, grouped in to bytes numbered from 0x00 to 0xFF.  Each bit relates to a particular signalling element.
* {"SF_MSG":{"time":"1349696911000", "area_id":"WJ", "msg_type:"SF", "address":"3E", "data":"18", "report_time":"073814"}}
* {"SG_MSG":{"time":"1349696911000", "area_id":"WJ", "msg_type:"SG", "address":"30", "data":"900000C0", "report_time":"073814"}}
* {"SH_MSG":{"time":"1349696911000", "area_id":"WJ", "msg_type:"SH", "address":"30", "data":"900000C0", "report_time":"073814"}}


Each time an element changes state, an SF message is sent with the value of the elements in the entire byte.
=== Message Fields ===


Every few hours, the state of all bits is sent as a 'refresh' in a series of SG messages with the value of groups of four bytes.  These messages are terminated with an SH message.
{| class="wikitable"
!Field
!SF
!SG
!SH
!Details
|-
|time
|•
|•
|•
|Message time
UNIX timestamp ''in milliseconds'' since the UNIX epoch
|-
|area_id
|•
|•
|•
|Alphanumeric code representing the TD area that the message originates from
|-
|msg_type
|•
|•
|•
|Type of message
Can be SF_MSG, SG_MSG or SH_MSG
|-
|address
|•
|•
|•
|Address of the signalling data being updated.  For an SF_MSG, this is the individual signalling element.  For an SG_MSG or SH_MSG, this is the starting address for the four bytes supplied in the data field.
|-
|data
|•
|•
|•
|Signalling data
|-
|report_time
|•
|•
|•
|Reporting time
|-
|}
 
=== Interpreting S-Class data ===


To decode the set of addresses and bits in to signalling elements, several other sets of data are required:
S-Class data represents the state of individual signalling elements within a TD area as bits within a set of 2,048 bits (numbered from 0x00 to 0xFF).  The number of bits needed for a TD area depends on the number of signalling elements within that area.  Each time an element changes state, an SF message is sent with the value of the elements in the relevant byte.


* A mapping table containing a list of bits and the signalling elements to which they refer
Every few hours, the state of all bits is sent as a 'refresh' in a series of SG messages with the value of groups of four bytes.  These messages are terminated with an SH message.
* A diagram containing signal numbers, routes available from signals, point numbers and track circuit detail


These translation tables are currently in the process of being gathered.
To decode the set of addresses and bits in to signalling elements, a mapping table containing a list of bits and the signalling elements to which they refer is needed.  To reference this to signals on the track layout, a diagram containing signal numbers, routes available from signals, point numbers and track circuit detail is also needed.

Revision as of 18:48, 28 April 2013

Train Describer (TD) Feed

Overview

The Train Describer feed provides low-level detail about the position of trains and their train reporting number through a network of berths. Usually, but not always, a berth is associated with a signal - but there are locations (such as terminal platforms at stations) where there may be more than one berth. From each berth, there are zero or more other berths which a train description may step in to. A step between berths represents movement of the train from one berth to another. Some of these steps may be one-way, some may be two-way.

To access the TD data feed, you must select and subscribe to the appropriate geographical topic(s) on the My Feeds page on the Data Feeds website (see the about the feeds page.

Topics

ActiveMQ topics are provided for signalling in specific geographic areas, as well as a topic representing all TD data in the country.

Topic Description
TD_ALL_SIG_AREA All signalling areas
TD_SE_SIG_AREA Scotland - East
TD_SW_SIG_AREA Scotland - West
TD_LNE_NE_SIG_AREA London North Eastern - North East
TD_MC_EM_SIG_AREA Midlands & Continental - East Midlands
TD_LNE_GN_SIG_AREA London North Eastern - Great Northern
TD_LNW_LC_SIG_AREA London North Western - Lancashire and Cumbria
TD_LNW_C_SIG_AREA London North Western - Central
TD_WCS_SIG_AREA West Coast - South
TD_ANG_SIG_AREA Anglia
TD_KENT_MCC_SIG_AREA Kent and Midlands & Continental
TD_SUSS_SIG_AREA Sussex
TD_WESS_SIG_AREA Wessex
TD_WTV_SIG_AREA Western - Thames Valley
TD_WWC_SIG_AREA Western - West Country
TD_WWM_SIG_AREA Western Wales and Marches

Message types

The Train Describer feed has seven message types, split into two classes.

C Class Messages: Berth Movement

Type Name Details
CA Berth Step The CA message is a 'step' message.

This moves the description from the 'from' berth, in to the 'to' berth, cancelling the description in the 'from' berth and overwriting any description in the 'to' berth.

CB Berth Cancel The CB message is a 'cancel' message.

This cancels the description in the 'from' berth.

CC Berth Interpose The CC message is an 'interpose' message.

This inserts the description in to the 'to' berth, overwriting any description in the 'to' berth.

CT Heartbeat The CT message is a 'heartbeat' message, periodically sent from a train describer.

Message Format

Messages are sent in JSON format, as follows:

  • {"CA_MSG":{"time":"1349696911000", "area_id":"SK", "msg_type":"CA", "from":"3647", "to":"3649", "descr":"1F42"}}
  • {"CB_MSG":{"time":"1349696911000", "area_id":"G1", "msg_type":"CB", "from":"G669", "descr":"2J01"}}
  • {"CC_MSG":{"time":"1349696911000", "area_id":"G1", "msg_type":"CC", "descr":"2J01", "to":"G669"}}
  • {"CT_MSG":{"time":"1349696911000", "area_id":"SA", "msg_type":"CT", "report_time":"1249"}}

Message Fields

Field CA CB CC CT Details
time • • • • Message time

UNIX timestamp in milliseconds since the UNIX epoch

area_id • • • • Alphanumeric code representing the TD area that the message originates from
msg_type • • • • Type of message

Can be CA_MSG, CB_MSG, CC_MSG or CT_MSG

from • • From berth
to • • To berth
descr • • • Train description

Four-letter alphanumeric code representing the headcode or description of the train

report_time • Reporting time

S Class Messages: Signalling Data

Type Name Details
SF Signalling Update Updates the signalling data for a specified set of signalling elements
SG Signalling Refresh Part of a set of SG messages which update the whole set of signalling data for TD area. Terminated by an SH message.
SH Signalling Refresh Finished Last message in a signalling refresh

S-Class messages report the status of the following signalling elements:

  • Signal aspects - whether the signal is displaying its most restrictive aspect or not
  • Points - whether the points are set normal or reverse
  • Route set - the route set from a signal to another signal or bay platform
  • TRTS buttons - the status of a Train Ready to Start button, used by train dispatch staff to indicate to the signaller that platform duties are complete
  • Level crossings - whether they are lowered or raised
  • Track circuits - whether a particular track circuit is occupied or not

Not all train describers support S-Class data, and those that do may only support a subset of the available groups of data. The List of Train Describers shows S-Class support.

Message Format

Messages are sent in JSON format, as follows:

  • {"SF_MSG":{"time":"1349696911000", "area_id":"WJ", "msg_type:"SF", "address":"3E", "data":"18", "report_time":"073814"}}
  • {"SG_MSG":{"time":"1349696911000", "area_id":"WJ", "msg_type:"SG", "address":"30", "data":"900000C0", "report_time":"073814"}}
  • {"SH_MSG":{"time":"1349696911000", "area_id":"WJ", "msg_type:"SH", "address":"30", "data":"900000C0", "report_time":"073814"}}

Message Fields

Field SF SG SH Details
time • • • Message time

UNIX timestamp in milliseconds since the UNIX epoch

area_id • • • Alphanumeric code representing the TD area that the message originates from
msg_type • • • Type of message

Can be SF_MSG, SG_MSG or SH_MSG

address • • • Address of the signalling data being updated. For an SF_MSG, this is the individual signalling element. For an SG_MSG or SH_MSG, this is the starting address for the four bytes supplied in the data field.
data • • • Signalling data
report_time • • • Reporting time

Interpreting S-Class data

S-Class data represents the state of individual signalling elements within a TD area as bits within a set of 2,048 bits (numbered from 0x00 to 0xFF). The number of bits needed for a TD area depends on the number of signalling elements within that area. Each time an element changes state, an SF message is sent with the value of the elements in the relevant byte.

Every few hours, the state of all bits is sent as a 'refresh' in a series of SG messages with the value of groups of four bytes. These messages are terminated with an SH message.

To decode the set of addresses and bits in to signalling elements, a mapping table containing a list of bits and the signalling elements to which they refer is needed. To reference this to signals on the track layout, a diagram containing signal numbers, routes available from signals, point numbers and track circuit detail is also needed.

Retrieved from "https://wiki.openraildata.com/index.php?title=TD&oldid=461"