The Impacts of PTC and Evolving Technologies on Railway Communications. Number of Words: 3523

Transcription

1 The Impacts of PTC and Evolving Technologies on Railway Communications Kevin Nichter Lilee Systems Derek Weatherwax CN Number of Words: 3523 Abstract As required by the Code of Federal Regulations (CFR) Title 49 Subtitle B, Chapter 2, Part 236, subpart I, affected Class I, short line, and commuter railroads in the United States are required to design, build, and maintain an interoperable train control system to support Positive Train Control (PTC). Each of these affected roads will deploy a solution that accommodates for their own methods of operation and available technology, while also accommodating for interoperability with other systems. These new interoperable train control networks utilize a 220MHz radio system and Interoperable Train Control Messaging (ITCM) to be deployed as new infrastructure on the railway. However, factors such as the cost associated with the deployment of PTC, the availability and reliability of the current communications system infrastructure, and the desire for a unified network have contributed to the effort to leverage the existing communications networks in some capacity for PTC deployment. This paper examines the potential use of existing communications infrastructure for PTC applications, the potential advantages that may be derived from leveraging the new infrastructure developed for PTC to support other communications traffic for the railway, as well as potential strategies to consider when evaluating these approaches. This paper assumes that the reader has a general understanding of the existing data communications networks utilized by the railroads for applications such as codeline and network management. The reader should also have familiarity with the application of the ITC messaging system and the 220 MHz data radio network to be utilized for PTC. AREMA

2 Introduction Most North American freight and transit railroads have deployed extensive ATCS (Advanced Train Control System) data radio networks to support their train control operations. These radios operate in six channel pairs in the upper 800 MHz and 900 MHz frequencies. Although newer radios are capable of operating with higher throughput, the effective throughput of these radio systems is very limited (<9600 bps) due to constraints in other parts of the train control system and the technology available during the creation of the ATCS standards. These data radios connect wayside signal logic controllers to the ATCS network. Due to limitations in the over-the-air throughput of the ATCS radio network, the link between the ATCS data radio and the signal logic controllers incorporates a protocol designed to run on relatively slow data links (typically, no more than 9600 bps). The components utilized in ATCS data radios have been relatively unchanged since the specification was standardized in the mid-1990s. As the larger railroads completed the bulk of their CTC (Centralized Traffic Control) deployments, the demand for new ATCS data radios began to be driven primarily by the need for the remaining CTC deployments or replacement radios. PTC as a Catalyst In the I-ETMS (Interoperable Electronic Train Management System) version of PTC, the interoperable communications link will be provided by a nationwide federated and licensed 220 MHz TDMA (Time Division Multiple Access) based radio network designed by Meteorcomm, LLC. While some differences exist between the architecture each of the railroads intend to deploy, this radio network will provide the interoperable link between a host railroad and any foreign locomotive that operates on its tracks. In support of this initiative, Meteorcomm partnered with Red Hat Inc. to structure and develop open source messaging software to be used for interoperable PTC operations on the 220 MHz network. Since the interoperable radio network would offer an interoperable communications path at all wayside locations, a 220 MHz radio would be installed in the same physical location as the existing 900 MHz radio previously deployed to support ATCS network connectivity at control points in CTC territory. Although the performance characteristics of the ITC 220 MHz radio largely exceed those of the 900 MHz ATCS data radio, and the ITCM could be enhanced to support other message types besides those specified for PTC, interoperable PTC was not intended to incorporate any additional functionality such as carrying codeline traffic. The concept that such a network could transport CTC messages via the ITCM transport introduces risks that would need to be mitigated accordingly, such as:

3 The impact of additional traffic on the 220 MHz radio network, which would increase the amount of traffic over the air and potentially contribute to additional congestion or even new spectrum needs. The potential for a single point for failure which would result in the railroad losing connectivity to signal devices supporting CTC and PTC operation at a wayside location. The amount of work involved in the creation of new standards at a time when the industry is placing a heavy focus on meeting the requirements set forth in the PTC mandate. Other unknown impacts to overall system reliability. In light of this and in anticipation of potential future benefits which have yet to be articulated or quantified, the industry has put forth some effort into defining a standard for CTC-over-ITCM, which prescribes the message formats and a basic architecture necessary for converting legacy ATCS messages into an EMP format capable of being transported across the ITCM network. This standard also describes the command and control functions for the interface between CTC wayside devices and the office gateway The CTC Over ITCM Standard In April 2013, representatives from the ITC committee and Meteorcomm, LLC created the first draft of a standard messaging interface between CTC wayside and office devices which could utilize the ITCM for transport. This standard utilized several elements of the messaging system defined by the ITC committees for use with PTC (specifically, AAR S-9354 Edge Message Protocol Specification, AAR S Class C Messaging Specification, and AAR S-9356 Class D Messaging Specification). The new messaging format accommodated for the standard ATCS message formats for code line messages primarily control and indication information as well as service and health messages as defined in ATCS Specifications 200, 250, 700, and 157 to be supported for transport by the ITCM network. The existing message payloads can be preserved to allow legacy subsystems to consume and produce the original message formats, while using the ITCM as either a primary or secondary transport. The standard also allowed for the use of IP-based connections between the back office and assets. Since the new message formats developed for PTC support systems management functionality via ISMP (Interoperable Systems Management Protocol), this newly proposed standard would also provide a capability for legacy devices to be supported by the network management systems being deployed for PTC. At the time of this writing, this proposed messaging standard has not been accepted as a standard by the AAR. The protocol stack for CTC over ITCM is as follows: Layer/Format Lower Layers/Formats Protocol IEEE (Ethernet) 10Mbps/100Mbps/1Gbps

4 Layer/Format Protocol Internet Protocol (IP) v4 Transmission Control Protocol (TCP) AAR Class D Upper Layers/Formats AAR Edge Messaging Protocol (EMP) CTC over ITCM Application Message Format Figure 1 CTC Over ITCM Protocol Stack By leveraging the same lower layers and EMP messaging format as those utilized for PTC, a CTC message is intended to be converted to a supported format for transmission across the ITCM. However, the CTC over ITCM standard does not provide a recommended method for integration with the communications subsystem. The following considerations need to be taken into account: 1.) Although accommodations are made for IP transports, there was no intention to define specific physical interfaces such as private radio or cellular modems. 2.) The standard prescribes how native ATCS messages will be handled. However, the support for legacy protocols such as serial-based polled protocols (i.e. Genisys) or other railroad or vendorspecific protocols is not made. The standard assumes that the Field Gateway (FG) devices are used as temporary protocol translators until the wayside signal equipment can support this natively, but the amount of time associated with such a transition is dependent on the ability of a railroad to migrate to the new hardware and solutions in the field as they become available and support from the equipment manufacturers. 3.) There are vendor-specific ATCS messages created to support additional functionality which are not part of the general over-the-air message traffic on ATCS networks (control, indication, recall, and other health status messages). These may need to be supported depending on a specific railroad s implementation of signal and communications devices or the railroad s current methods of managing remote devices. Potential for Use of Alternate Communication Links While other modes of communication are not considered interoperable in the sense that they can provide interoperability between different railroads networks, cellular and other communication technologies are

5 being utilized to provide reliable connectivity between a given railroad s back office and their remote PTC assets. These types of links include: Private cellular 3G / 4G / LTE MPLS (Multiprotocol Label Switching) / leased circuits Satellite Fiber Private RF data links (including microwave) When evaluating the suitability of these communications solutions, the cost, availability, reliability, scalability, and throughput are factored into the decision-making process. Cellular Solutions Cellular connectivity has been utilized for well over a decade in the rail industry to provide reliable connectivity for CTC, as well as other applications such as crossing health and hot box detector monitoring. Improvements to reliability and coverage and increased bandwidth have reduced some of the concerns associated with the reliance on public communications infrastructure. Furthermore, the cellular service providers data plans and enterprise solutions have also evolved to accommodate for large customers with thousands of mobile and fixed assets geographically located across the United States and Canada. As many railroads have adopted the use of cellular networks for primary and secondary connectivity for CTC, the reuse of this existing infrastructure for use in PTC became an option to provide: A potential communications link for wayside locations which do not include a local 220 MHz radio. A potential communications link for locomotives to be utilized for diagnostic access, software maintenance, or in the event that the 220 MHz link is unavailable. A high bandwidth communications link to provide systems management capability, especially useful for large file transfers such as software uploads and train initializations. A primary communications link to provide a railroad with connectivity for testing purposes, especially for situations in which the 220 MHz network has not been deployed but some level of establishing links between the field and back office network is required. MPLS/Leased Circuits An MPLS networking standard is being developed by the AAR ITCIP networking team to interconnect the PTC-dependent railroads in the United States for the exchange of messages between ITCM back office

6 systems. These leased line circuits belong to Sprint and Verizon and are available through two supporting AAR agents which assign IP addresses and GRE (General Routing Encapsulation) tunneling information and act as intermediary agents between the connecting railroads and the two carriers. Due to the scalable, protocol-independent transport layer of MPLS, multiple protocols and existing mediums can be used to support such a network. f Figure 2- Fully Meshed GRE Tunnels In conjunction with the new standards proposed to support CTC over ITCM, and the support for IP paths in the ITC network, the use of cellular, satellite, and private radio links could provide a viable, long-term option for convergence between the network deployed for PTC and the existing networks already in place. An additional advantage to be considered is that this convergence would not increase the amount of traffic over the 220 MHz network or require additional RF spectrum. One caveat is that proper design methodologies must be utilized to ensure that these links can support the reliability and availability requirements necessary for I-ETMS, especially in cases where 220 MHz wayside radios may not be used. The availability of non-rf-based transports at wayside locations such as fiber optics enables railroads the potential to minimize or eliminate the use of wayside 220 MHz radios provided the reliability and latency requirements can be met in an alternate method. This is becoming especially prevalent when reviewing the proposed architectures to be utilized for PTC deployment on transit systems, due to the availability of fiber optic connections at wayside locations. The availability of these fiber optic connections is due in large part to the location of transit organizations within large cities and municipalities where economies of scale make the deployment of fiber optic more feasible.

7 Figure 3 Conceptual Architecture for Fiber-Connected Waysides Using this approach, wayside status messages generated from local WIUs will be transported from wayside locations to the back office, where the messages will be routed to the appropriate base station for transmission to the locomotive using the WSRS (Wayside Status Relay Service) located in the back office. Proof of Concept In order to assess the suitability of the ITCM for transport of CTC messages and provide guidance as to how the migration plan to utilize this standard could be developed, a proof of concept laboratory was built in compliance with the CTC over ITCM specification. The reference architecture for the proof of concept appears below.

8 Table 1 CTC-Over-ITCM Proof of Concept Architecture The laboratory environment utilized simulators to create and control EMP message traffic inserted into the ITCM, along with WMS (Wayside Messaging Server) hardware compliant with the S-9202B specification. Additionally, a SMG (Systems Management Gateway) was also implemented to demonstrate the capabilities of ISMP (Interoperable Systems Management Protocol) when using CTC over ITCM. The reference architecture from the CTC over ITCM specification appears below. Figure 4 Message Flow and Utilization of ISMP for Management of CTC Devices with the ITCM The following findings and observations were made as a result of the proof of concept: 1.) The OG as defined by the specification is not intended to fully replace the functionality provided by an ATCS FEP / CC (Front End Processor / Cluster Controller), commonly referred to as a packet switch in the industry. The differentiator is that an ATCS packet switch provides the ATCS FEPHUB and FEPLCT tasks to support the routing capabilities and voting mechanisms

9 needed for 900 MHz data radio networks. Unless augmented otherwise, an OG and packet switch (or suitable alternative) are both needed to maintain the existing 900 MHz ATCS radio network operation while offering the ITCM as a potential backup path. 2.) This proof of concept implemented a dispatch system simulator that communicated with native EMP messages. Most modern code servers in service on Class I railroads utilize ATCS protocols to communicate with packet switches in the office. In order for a dispatch system to communicate directly with the OG, the dispatch system code servers must also be upgraded to support the existing message sets, or an intermediate application may be implemented to perform protocol converter functions (i.e. ATCS Specification 200 to EMP). An additional option is for the OG to perform the protocol converter duties until such time as the dispatch system may be updated to support EMP-based message formats. It should also be noted here that there are slight variations between the implementation of ATCS between packet switches or FEPs and the dispatch systems utilized by various Class Is. 3.) The ITCM utilizes TNUs (Transport Network Updates) to provide a list of all transports available to a wayside location. These updates allow a wayside location to know the availability of 220 MHz, cellular, or other communications paths and utilize them accordingly. However, traditional ATCS links use a variety of custom-implemented methods of determining when a wayside location should switch between a primary link (for example, a 900 MHz radio) and an alternate path (such as cellular). These methods differ between manufacturers as there is no standard across the industry. Therefore, it may be advantageous to explore a standard to define when an ATCS links should switch to an available ITCM network path. 4.) When the ITCM is utilized for codeline traffic, the tools that have been created for message tracing and general diagnostics of the ITC messaging system could also be applied for codeline. These tools are implemented using ISMP (Interoperable Systems Management Protocol). This helped to reinforce the notion of a truly converged network since similar maintenance tools could be utilized regardless of the traffic type. The diagram below, from the CTC over ITCM specification, shows the message flow between CTC devices, the OG, the FG, and the SMG. 5.) Support for serial-based codeline traffic (such as Genisys protocol) is not described in the CTC over ITCM specification. However, there is a generally accepted practice in the industry to convert Genisys control and indication payload as well as recall messages into an ATCS-format. This method provides a roadmap as to how these legacy serial protocols could also utilized the ITCM network for transport. For this proof of concept, the legacy serial connections were

10 accommodated directly in the WMS but they could also be implemented into the WDC. These serial-based connections would need to be supported until wayside equipment can offer Ethernet / IP connectivity and the railroads have updated the field equipment accordingly. 6.) This proof of concept utilized LTE cellular links as one of the transports available to the ITCM. Although the impact of codeline traffic to the overall throughput was minimal, it was difficult to assess what the impacts of latency or poor cellular coverage would be as the proof of concept was implemented under ideal circumstances. Strategies for Consideration and Recommendations for Further Review 1.) Since the transition to a fully converged network supporting CTC over ITCM would take many years, it would be useful to evaluate if there are other intermediate steps which may be taken which would offer railroads the opportunity to embrace some of the additional benefits while gradually updating wayside equipment. Some possibilities might include field upgrade kits to the WIU or microprocessor-based logic controllers to support IP connectivity, support within the WMS for legacy protocols, or intermediate protocol converters. 2.) Because there are thousands of such connections still in operation today, it may be useful to consider a standard for incorporation of serial-based protocols via an FG that may be internal or external to the Wayside Messaging Server. This capability would need to be coordinated with the support in microprocessor-based logic controllers to support the necessary protocols natively, eliminating the need for an FG. 3.) It may be useful to consider the value to the railroads to utilize an OG that also supports the traditional ATCS FEP capability, thus simplifying the back office architecture. 4.) CTC over ITCM offers the possibility to ultimately standardize the codeline assets on ISMP as the method to support systems management. It may be useful to study the impact of a converged network management system one that supports PTC as well as CTC assets to the railroad operations. 5.) In the event that the industry ultimately desires to migrate codeline messages to the 220 MHz network, it will be ideal to perform an assessment of the impact of the increased message load on the 220 MHz network when supporting codeline traffic. This is particularly of interest in highly dense environments.

11 6.) It may be of interest to promote a standard as to how and under what conditions an ATCSconnected wayside location should switch over to the ITCM path. 7.) Depending on the implementation, CTC over ITCM may have a single point of failure at the WMS or the signal logic device. This means that it is possible that a failure of one piece of hardware may render the wayside location unavailable for PTC or CTC. It would be ideal to perform a risk assessment of the impact of a single point of failure at a wayside location for these devices. List of Acronyms AG ATCS CM CTC EMP FEP / CC FEPHUB FEPLCT FG GRE I-ETMS ITC ITCM MCC MPLS OCG OG PTC Application Gateway Advanced Train Control System Connection Manager Centralized Traffic Control Edge Messaging Protocol Front End Processor / Cluster Controller Front End Process Hub Front End Process Line Controller Task Field Gateway General Routing Encapsulation Interoperable Electronic Train Management System Interoperable Train Control Interoperable Train Control Messaging Meteorcomm Communications Multiprotocol Label Switching. Office Communications Gateway Office Gateway Positive Train Control

12 RB SMG TDMA TNU WIU WMS WSRS Remote Broker Systems Management Gateway Time Division Multiple Access Transport Network Updates Wayside Interface Unit Wayside Messaging Server Wayside Status Relay Service Acknowledgements The authors wish to thank members of AREMA Committee 39 for their feedback on this paper as well as input on the next steps. References 1.) AAR S-9354 Edge Message Protocol Specification 2.) AAR S-9355 Class C Messaging Specification 3.) AAR S-9356 Class D Messaging Specification 4.) AAR S-9202 Wayside Interface Unit Requirements 5.) AAR S-9202B Standalone Wayside Messaging Server Hardware 6.) ATCS Specification 200 (March 1993) - ATCS Protocols 7.) ATCS Specification 250 (March 1993) - ATCS Message Formats 8.) ATCS Specification 700 (March 1993) - CPC Specification 9.) ATCS Specification 157 (March 1993) - CPC Operation 10.) ITCSM 1.4 System Architecture 11.) CTC Over ITCM ICD v1.1 Figures in this Document Figure 1 CTC Over ITCM Protocol Stack... 4 Figure 2- Fully Meshed GRE Tunnels... 6 Figure 3 Conceptual Architecture for Fiber-Connected Waysides... 7 Figure 4 Message Flow and Utilization of ISMP for Management of CTC Devices with the ITCM... 8