S Class Messages: Difference between revisions

From Open Rail Data Wiki
m Split out introductory text
m small punctuation fix
 
(2 intermediate revisions by one other user not shown)
Line 39: Line 39:
Messages are sent in JSON format, as follows:
Messages are sent in JSON format, as follows:


* {"SF_MSG":{"time":"1422404915000","area_id":"SI","address":"16","msg_type":"SF","data":"43"}}
<pre>{"SF_MSG":{"time":"1422404915000","area_id":"SI","address":"16","msg_type":"SF","data":"43"}}
* {"SG_MSG":{"time":"1422404915000","area_id":"RW","address":"00","msg_type":"SG","data":"06880306"}}
{"SG_MSG":{"time":"1422404915000","area_id":"RW","address":"00","msg_type":"SG","data":"06880306"}}
* {"SH_MSG":{"time":"1422404915000","area_id":"RW","address":"04","msg_type":"SH","data":"35000000"}}
{"SH_MSG":{"time":"1422404915000","area_id":"RW","address":"04","msg_type":"SH","data":"35000000"}}</pre>


= Message Fields =
= Message Fields =
Line 53: Line 53:
|-
|-
|time
|time
|&bull;
|&#10004;
|&bull;
|&#10004;
|&bull;
|&#10004;
|Message time
|Message time
UNIX timestamp ''in milliseconds'' since the UNIX epoch
UNIX timestamp ''in milliseconds'' since the UNIX epoch
|-
|-
|area_id
|area_id
|&bull;
|&#10004;
|&bull;
|&#10004;
|&bull;
|&#10004;
|Alphanumeric code representing the TD area that the message originates from (see [[List_of_Train_Describers|list of train describers]])
|Alphanumeric code representing the TD area that the message originates from (see [[List_of_Train_Describers|list of train describers]])
|-
|-
|msg_type
|msg_type
|&bull;
|&#10004;
|&bull;
|&#10004;
|&bull;
|&#10004;
|Type of message
|Type of message
Can be SF_MSG, SG_MSG or SH_MSG
Can be SF_MSG, SG_MSG or SH_MSG
|-
|-
|address
|address
|&bull;
|&#10004;
|&bull;
|&#10004;
|&bull;
|&#10004;
|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.
|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
|data
|&bull;
|&#10004;
|&bull;
|&#10004;
|&bull;
|&#10004;
|Signalling data
|Signalling data
|-
|-
Line 94: Line 94:
* SOP Tables - These are the signalling output tables for a TD and show all bytes and bits
* SOP Tables - These are the signalling output tables for a TD and show all bytes and bits


IECC's have ECS's and most other TD's have SOP's.
IECCs have ECSs and most other TDs have SOPs.


For meanings of individual signalling functions, see [[Signalling Nomenclature]].
For meanings of individual signalling functions, see [[Signalling Nomenclature]].

Latest revision as of 00:54, 4 October 2020

S-Class train describer messages provide updates relating to the status of signalling equipment within a train describer area. Not all TD areas provide this information.

Message types

There are three types of S-Class message:

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 departure is due.
  • Level crossings - whether they are lowered or raised
  • Track sections - whether a particular track section (track circuit or axle counter section) 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. You should also note that even though a subset may available it might not be complete. (E.g A TD may send SIG & TRK data but it may only relate to some signals and track sections - not all of the physical ones in a TD area)

Message Format

Messages are sent in JSON format, as follows:

{"SF_MSG":{"time":"1422404915000","area_id":"SI","address":"16","msg_type":"SF","data":"43"}}
{"SG_MSG":{"time":"1422404915000","area_id":"RW","address":"00","msg_type":"SG","data":"06880306"}}
{"SH_MSG":{"time":"1422404915000","area_id":"RW","address":"04","msg_type":"SH","data":"35000000"}}

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 (see list of train describers)
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

Working with S-Class data

In order to use the S-Class data contained in these messages you need to know what each element is. Network Rail have agreed to release a number of technical documents for each TD which will provide the information you require. While this process has begun it will take some time to complete - you should check the list of train describers for any information that may already have been released or user contributions. You may also like to have the challenge of trying to decode it yourself, in which case you should read the section below and the article on Decoding S-Class Data.

  • ECS Specifications - This provides the full external communications specification showing all connections to and from a TD along with the S-Class bit maps required. Where multiple connections are listed data to the NROD platform generally come via the 'SMART' connection.
  • SOP Tables - These are the signalling output tables for a TD and show all bytes and bits

IECCs have ECSs and most other TDs have SOPs.

For meanings of individual signalling functions, see Signalling Nomenclature.

Interpreting S-Class data

S-Class data represents the state of individual signalling elements within a TD area as bits within a set of up to 2,048 bits. 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. For advice on deducing your own mapping table, see Decoding S-Class Data.


Network Rail Open Data Feeds
Data Feeds About the Feeds Account States Durable Subscriptions Example Code ( PHP / C# / Java / Ruby / Node.js) • Advanced UsesFAQ 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)