Signalling Control System Serial Train Information Interface

Transcription

1 Specification Signalling Control System Serial Train Information Interface Issued Date: 04 April 2014 Important Warning This document is one of a set of standards developed solely and specifically for use on the rail network owned or managed by the NSW Government and its agencies. It is not suitable for any other purpose. You must not use or adapt it or rely upon it in any way unless you are authorised in writing to do so by a relevant NSW Government agency. If this document forms part of a contract with, or is a condition of approval by, a NSW Government agency, use of the document is subject to the terms of the contract or approval. This document may not be current. Current standards are available for download from the Asset Standards Authority website at State of NSW through Transport for NSW

2 Standard Approval Owner: Authorised by: Approved by: P. McGregor, Lead Signals and Control Systems Engineer D. Spiteri, Chief Engineer Rail G. Bradshaw, Principal Manager Network Standards and Services on behalf of the Asset Standards Authority Configuration Control Board Document Control Version Summary of Change 1.0 First issue For queries regarding this document State of NSW through Transport for NSW

3 Preface The Asset Standards Authority (ASA) develops, controls, maintains, and publishes standards and documentation for transport assts for New South Wales, using expertise from the engineering functions of the ASA and industry. ASA publications comprise of the network and asset standards for NSW Rail Assets and include RailCorp engineering standards that were previously managed by RailCorp until July This standard supersedes RailCorp standard SPG 1254 Signalling Control System Serial Train Information Interface Specification,. The changes to previous content include: updates to reflect organisational changes and resulting changes in responsibilities minor amendments and clarification to content conversion of the standard to ASA numbering, format and style State of NSW through Transport for NSW Page 3 of 16

4 Table of contents 1. Introduction Scope Purpose Application Reference documents Terms and definitions Protocol Physical Layer Data link layer Application layer...9 Appendix A CRC-16 sample code...16 State of NSW through Transport for NSW Page 4 of 16

5 1. Introduction Transport for New South Wales (TfNSW) train management system contains different types of control systems, such as ATRICS, Phoenix, SigView and VICOS. In order to provide seamless operation between different systems, information must be exchanged between systems. This information may include train information, signalling equipment status, blocking, etc. The first serial interface was developed between SigView and ATRICS as detailed in ATRIC ATRICS to SigView (TVS) Interface Specification form Train Information Protocol. This provided a means to fringe train information between systems. The serial interface was further extended to become the Train Describer Interface Protocol (TDIP) for communications between Phoenix and ATRICS. TDIP is based on ATRIC with the addition of a Train Recheck, Train Move and Train Rename messages. Also some limitations have been removed. In order to make sure all current and future control systems can communicate with each other using a unified protocol, this standard has been developed based on ISO/IEC :1994(E) and AS/NZS Scope Train and fringing information is distributed between control systems via serial link under some circumstances. This standard specifies three layers of the OSI recommendation X.200 model as detailed in ISO/IEC :1994(E), namely physical, data link and application layers. Other layers do not need to be implemented. 2.1 Purpose The aim of this document is to provide an overview of the framework and provide low level details to implement the minimum requirements to exchange train and fringing information between control systems using serial protocol called TDIP. 2.2 Application TDIP can be used if there is no network connection between control systems. Since this protocol is based on the serial link, it is slow and not future proof. Therefore it is encouraged that all future interfaces should be based on the network based protocols as detailed within the SPG 1251 and SPG When control systems are communicating with each other using TDIP, a number of data elements must be shared between control systems as listed below: track names location names State of NSW through Transport for NSW Page 5 of 16

6 During the design phase of the projects these names should be published and agreed. 3. Reference documents ATRIC ATRICS to SigView (TVS) Interface Specification form Train Information Protocol, Version 1.3, RailCorp SPE Train Describer Interface Protocol Version 1.4 Issue Date 04/03/2012, AnsaldoSTS ISO/IEC :1994(E) ITU-T Recommendation X.200 Data Networks and Open System Communications Open Systems Interconnection Model and Notation AS/NZS 3512 Information technology - Telecommunications and information exchange between systems - High-level data link control procedures - Description of the X.25 LAPB-compatible DTE data link procedures 4. Terms and definitions The following definitions apply in this document: CRC Cyclic redundancy check DLE Data link escape character (0x10) ETX End of text character (0x03) LSB Least significant bit MSB Most significant bit STX Start of text character (0x02) TDIP Train describer interface protocol 5. Protocol 5.1 Physical Layer a) The TDIP is an asynchronous full-duplex serial protocol. b) The TDIP shall operate 8 bit characters, 1 stop bit, and no parity. The link speed is project dependent but it shall be able to handle bits per second. c) The TDIP shall be based on message frames which shall consist of the fields shown in Figure 1. State of NSW through Transport for NSW Page 6 of 16

7 Figure 1 Fields for TDIP message frames d) The first octet of the frame shall be the STX (0x02) octet which shall mark the start of the frame. e) The second octet of the frame shall be the sequence number. The sequence number shall be used to match request to response messages. The sequence number shall be in the range 0x80 to 0xFF inclusive. f) The third octet of the frame shall be the command number. The most significant bit (MSB) shall be 0 if the message is a request. The most significant bit shall be 1 if the message is a response. g) The fourth octet of the frame shall be the version number. The version number shall be in the range 0x20 to 0xFF inclusive. This octet may not be implemented for some of the existing interfaces. It must be decided on a project by project basis. h) The octets between the version number, if existing, and ETX octet shall be the data field and shall vary in size and content depending on the command. i) The length of the data field is unlimited. But it must be decided on a project by project basis. j) The frame shall be terminated by an ETX (0x03) octet. k) STX, ETX and DLE shall be considered to be special octets. If a special octet appears between the STX and the ETX octet then a DLE (0x10) octet shall be inserted before it. When processing a frame the DLE octets shall be removed and the byte after the DLE shall be considered a normal octet. l) Following the ETX octet, the next two octets shall be the CRC. The CRC shall be calculated on all octets inclusive of the STX and ETX and all special octets such as inserted DLE octets. m) The CRC octets shall not be considered special octets and will not be subject to DLE octet insertion. n) The CRC shall use the CRC-16 CCITT polynomial x^16 + x^12 + x^5 + 1 as detailed in Reference 4. The CRC shall transmit the most significant octet first. See Appendix A CRC-16 sample code. State of NSW through Transport for NSW Page 7 of 16

8 5.2 Data link layer a) The TDIP is a connectionless protocol. Either system may initiate communications by sending a request message. b) If a received frame has an invalid CRC then the message shall be ignored. c) Once a request message has been received, it shall be processed and an appropriate response sent back. d) Each request shall have a sequence number that ranges between 0x80 and 0xFF inclusive. e) Any valid sequence number may be used as the initial sequence number. f) The sequence number shall be incremented with each new request message. Once a request message with sequence number 0xFF is sent the next request message shall have a sequence number of 0x80. g) There is no requirement that request messages be received in sequence. It is not an error to receive an out of sequence request message. h) The response to a request message shall have the same sequence number as the request message. i) The command number shall identify the request type and shall range between 0x40 and 0x7F. j) A response to a request message shall have the same command number as the request, however the most significant bit shall be set to 1. k) If the sequence number of a received response message does not correspond to the sequence number of the unacknowledged request message then the response message shall be ignored. l) Once a request message is sent, the sender shall wait a configurable timeout, before retransmitting the same request message. m) The timeout shall be specified in seconds. The timeout shall be a positive integer greater than 0 and less than 10 seconds. The default shall be 1 second. n) A request message shall be retransmitted a maximum of 3 times after which the message shall be discarded and the link considered failed. o) A request message must be acknowledged or the link declared failed before a new request message may be sent. p) A system that has not sent a request message or received a valid response message within the previous 15 seconds shall send a heartbeat request message. q) If the command of a command message is not recognised then a Command not supported error request message shall be sent. State of NSW through Transport for NSW Page 8 of 16

9 5.3 Application layer Next train message The Next Train message is used to notify the other system that a train is approaching the system boundary Command Message a) A 'Next Train' command message shall be sent once a train reaches a nominated point and is committed to cross the system boundary. A train is deemed to be committed to the system boundary once it has a cleared route across the system boundary. Only one train at a time can be committed to a route across the system boundary. b) The format for the 'Next Train' command message shall be organised as per Figure 2. Figure 2 Format for 'Next Train' command message c) The command for the Next Train command message shall be 0x41. d) The data section of the frame shall consist of three subfields. Each sub-field shall contain printable ASCII text characters and be null (0x00) terminated. e) The size of each sub-field shall be variable. As a minimum, a sub-field shall consist of the null terminating character. f) If the size of a sub-field is too large, or there are sub-fields missing then an Illegal Parameter error response message shall be sent. Otherwise a normal response shall be sent. g) The location field shall contain the name of the location. The name of the location shall be agreed between the two systems and is outside the scope of this document. The maximum size of the location field shall be 64 ASCII characters. h) The track field shall contain the name of the track. The name of the track shall be agreed between the two systems and is outside of the scope of this document. The maximum size of the track field shall be 32 ASCII characters. i) The TrainID field shall contain the name of the train. The maximum size of the TrainID field shall be 10 ASCII characters. The TrainID field shall not be null. j) A TrainID of the form ghostnnnnn shall be used to indicate an un-named train Response message a) A 'Next Train' response message shall be sent when a valid Next Train command message is received. State of NSW through Transport for NSW Page 9 of 16

10 b) The format for the Next Train' response message shall be organised as per Figure 3: STX 0x## 0xC1 VER IETX Figure 3 Format for 'Next Train' response message c) The sequence number shall be the same as the command message. d) The command for the Next Train response message shall be 0xC Heartbeat message The Heartbeat message is used to test the operation of the other system during periods of low activity Command message a) A Heartbeat command message shall be sent if no other command or response message has been sent in the previous 15 second period. b) The format for the Heatbeat' command message shall be organised as per Figure 4: Figure 4 Format for 'Health' command message c) The command for the Health command message shall be 0x43. d) The Health octet shall be a value between 0x00 and 0xFF and shall indicate the overall health of the sub-system that is sending the command. e) A value of 0x00 for the Health octet shall indicate that the sending sub-system is healthy. f) A value of 0xFF for the Health octet shall indicate that the sending sub-system is unhealthy. g) It is implementation specific as to what is indicated by sub-system health. It must be decided project by project basis Response message a) A Heartbeat' response message shall be sent when a valid 'Heartbeat command message has been received. b) The format for the Heartbeat' response message shall be organised as per Figure 5: State of NSW through Transport for NSW Page 10 of 16

11 Figure 5 Format for 'Heath' response message c) The sequence number shall be the same as the command message. d) The command for the Heartbeat response message shall be 0xC3. e) The Health octet shall be a value between 0x00 and 0xFF and shall indicate the overall health of the system that is sending the response. f) A value of 0x00 for the Health octet shall indicate that the sending system is healthy. g) A value of 0xFF for the Health octet shall indicate that the sending system is unhealthy. h) It is implementation specific as to what is indicated by sub-system health. It must be decided project by project basis Train move message The 'Train Move' message is used to notify the other system that a train has moved to a different track circuit. Implementation of this message should be based on the project requirements, such as existence of the overlap areas between two Control System areas Command message a) A Train Move message shall be sent when a train occupies a track circuit within the overlap area of the two systems. The Train Move message will only be sent once a train has entered the adjacent system up to the last track circuit in common with both systems. b) The format for the Train Move' command message shall be as per Figure 6: Figure 6 Format for 'Train Move' command message c) The command for the Train Move command message shall be 0x45. d) The data section of the frame shall consist of three subfields. Each sub-field shall contain printable ASCII text characters and be null (0x00) terminated. e) The size of each sub-field shall be variable. As a minimum, a sub-field shall consist of the null terminating character. If the size of a sub-field is too large or too small, or there are subfields missing then an Illegal Parameter error command message shall be sent in response. Otherwise a normal command shall be sent. State of NSW through Transport for NSW Page 11 of 16

12 f) The location field shall contain the name of the location. The name of the location shall be agreed between the two systems. The maximum size of the location field shall be 64 ASCII characters. g) The track field shall contain the name of the track. The name of the track shall be agreed between the two systems. The maximum size of the track field shall be 32 ASCII characters. h) The TrainID field shall contain the name of the train. The maximum size of the TrainID field shall be 10 ASCII characters. The TrainID field shall not be null. A TrainID of the form ghostnnnnn shall be used to indicate an un-named train Response message a) A 'Train Move' response message shall be sent when a valid 'Train Move command message has been received. b) The format for the Train Move' response message shall be organised as per Figure 7: Figure 7 Format for 'Train Move' response message c) The sequence number shall be the same as the command message. d) The command for the Train Move response message shall be 0xC Train rename message The Rename Train message is used to notify the other system that a train has been renamed Command Message a) A 'Rename Train' command message shall be sent when the train describer information for a train has been changed. b) The format for the Rename Train' command message shall be organised as per Figure 8: Figure 8 Format for 'Rename Train' command message c) The command for the Rename Train' command message shall be 0x46. d) The data section of the frame shall consist of four subfields. Each sub-field shall contain printable ASCII text characters and be null (0x00) terminated. State of NSW through Transport for NSW Page 12 of 16

13 e) The size of each sub-field shall be variable. As a minimum, a sub-field shall consist of the null terminating character. If the size of a sub-field is too large or too small, or there are subfields missing then an Illegal Parameter error command message shall be sent in response. Otherwise a normal command shall be sent. f) The location field shall contain the name of the location. The name of the location shall be agreed between the two systems. The maximum size of the location field shall be 64 ASCII characters. g) The track field shall contain the name of the track. The name of the track shall be agreed between the two systems. The maximum size of the track field shall be 32 ASCII characters. h) The Old TrainID field shall contain the previous name of the train. The maximum size of the Old TrainID field shall be 10 ASCII characters. i) The TrainID field shall contain the current name of the train. The maximum size of the TrainID field shall be 10 ASCII characters Response Message a) A 'Train Rename' response message shall be sent when a 'Train Rename' command message has been received correctly. b) The format for the Train Rename response message shall be organised as per Figure 9. Figure 9 Format for 'Train Rename' response message c) The sequence number shall be the same as the command message. d) The command for the Train Rename response message shall be 0xC Train recheck message The Train Recheck message is used to provide a snapshot for the Next Train at each system boundary and trains occupying track circuits within the overlap area of the two systems Command Message a) A 'Train Recheck' command message shall be sent to request the other system provide a snapshot of the next train expected at the system boundaries, as well as trains occupying track circuits in the overlap area of the two systems. b) A Train Recheck command message shall typically be sent when a link becomes healthy to re-establish the current state. A Train Recheck command message may also be sent periodically. State of NSW through Transport for NSW Page 13 of 16

14 c) The format for the Train Recheck command message shall be organised as per Figure 10: Figure 10 Format for 'Train Recheck' command message d) The command for the Train Recheck command message shall be 0x Response Message a) A 'Train Recheck' response message shall be sent when a Train Recheck command message has been received. b) The format for the Train Recheck' response message shall be organised as per Figure 11: Figure 11 Format for 'Train Recheck' response message c) The sequence number shall be the same as the command message. d) The command for the Train Recheck response message shall be 0xC7. e) The data section of the frame shall consist of four subfields repeated for each train in the system. f) The first subfield shall be a single octet corresponding to the original command. This field can be either the Next Train message (0x41) or the Train Move message (0x45). g) The three subsequent sub-fields shall contain printable ASCII text characters and be null (0x00) terminated. h) The size of each sub-field shall be variable. As a minimum, a sub-field shall consist of the null terminating character. If the size of a sub-field is too large or too small, or there are subfields missing then an Illegal Parameter error command message shall be sent in response. Otherwise a normal command shall be sent. i) The location field shall contain the name of the location. The name of the location shall be agreed between the two systems. The maximum size of the location field shall be 64 ASCII characters. j) The track field shall contain the name of the track. The name of the track shall be agreed between the two systems. The maximum size of the track field shall be 32 ASCII characters. State of NSW through Transport for NSW Page 14 of 16

15 k) The TrainID field shall contain the name of the train. The maximum size of the TrainID field shall be 10 ASCII characters. The TrainID field shall not be null. A TrainID of the form ghostnnnnn shall be used to indicate an un-named train. l) A TrainID previously sent in a Next Train message that is no longer committed to the system boundary will not be included in the Train Recheck response. That is, only system boundaries that have a committed train will be included in the Train Recheck response Error message Response message An 'Error' response message shall be sent in response to invalid command messages; either an unsupported command or invalid formatting of the data field. a) The format for the Error response message shall be organised as per Figure 12: Figure 12 Format for 'Error' response message b) The sequence number shall be the same as the command message. c) The command shall be 0xFF. d) The data field shall have a single octet to indicate the error code. e) The error code shall be an integer in the range 0x21 to 0x7F. The following error codes are defined: 0x21 Command not supported indicates that the value in the command byte is not supported by the system 0x22 Illegal Parameter indicates that the data part of the frame is in the wrong format for the given command f) Other error codes may be defined but they will implementation specific. State of NSW through Transport for NSW Page 15 of 16

16 Appendix A CRC-16 sample code The following is a sample C code segment that implements the algorithm as detailed in AS/NZS crc_16 = 0xFFFF; // Preset to 0xFFFF for (i = 0; i < NUMCHAR; i++) { crc_16 ^= DATA[i] << 8; for (j = 0; j < 8; j++) { if (crc_16 & 0x8000) { crc_16 <<= 1; crc_16 ^= 0x1021; // (CCITT) x16 + x12 + x5 + 1 } else { crc_16 <<= 1; } } } crc_16 = ~crc_16; // Take ones complement crc_16 &= 0xFFFF; // Not needed if int type is 16 bits wide State of NSW through Transport for NSW Page 16 of 16