Connected Transportation System 1.0 Positive Train Control
Available Languages
Table Of Contents
Cisco Connected Transportation System
Positive Train Control Mandate
Positive Train Control Cost Benefits
The Cisco Unified MPLS Transport Design
Cisco Connected Transportation System
The Rail Safety Improvement Act of 2008 (RSIA08) requires implementation of Positive Train Control (PTC) on railroads, which carry passengers or have high-volume freight traffic with toxic or poisonous-by-inhalation hazardous materials. PTC is a communications and signaling system that has been identified by the National Transportation Safety Board (NTSB) as a technology capable of preventing accidents caused by train operator or dispatcher error.
Connected Transportation System (CTS) PTC introduces continuous location based and speed tracking, with more sophisticated onboard wireless technology for enforcing movement authority from a centralized control center, wherever the vehicle may be. PTC will be inherently more reliable, and offer greater real-time functionality than conventional systems, and would prevent accidents such as the 2008 Chatsworth collision where a more advanced control system would have stopped the train automatically and lives saved. PTC solution is expected to reduce the number of accidents due to excessive speed, conflicting train movements, and engineer failure to obey wayside signals.
Additional examples of potential business benefits include:
•
Line capacity enhancement
•
•
•
•
•
•
PTC promises a new level of safety and efficiency for US railroads. To enable railroads within the United States to increase rail safety and meet requirements of Federal mandate, Cisco's Connected Transportation System enables comprehensive end-to-end network architecture for Positive Train Control. Cisco's Validated Design (CVD) provides blue print reference architecture enabling rail system operators to minimize potential design and implementation risk, and reduced time for deployment.
Release Notes
Release 1.0 of the PTC system provides an end-to-end design to support Positive Train Control deployments. Incorporating back office, transport, wayside, and onboard features, the PTC system offers a scalable and resilient ready-to-deploy application for supporting rail safety functions with coverage that includes:
•
•
•
•
Table 1 shows PTC 1.0 platforms and software versions.
Requirements
The following Positive Train Control requirement mandates and cost benefits are defined.
Positive Train Control Mandate
Positive Train Control (PTC) is one of many new safety measures mandated by the United States Federal government when President George W. Bush signed the Rail Safety Improvement Act in October of 2008. PTC is an end-to-end rail safety system that is designed to prevent the following incidents:
•
•
•
•
The system is designed such that PTC will augment the safety measures already taken by the engineer in control of the train, but if warnings to slow down or stop the train are ignored or cannot be performed by the engineer, PTC will automatically apply the brakes to achieve the desired speed or state of the train. All Class I railroads are required to install PTC on tracks that provide passenger transportation or transport poison- or toxic-by-inhalation hazardous materials, by December 31, 2015. Class I railroads include those railroads having annual revenue of $250 million or more.
As of 2012, approximately 60,000 of the 162,000 miles of railroad tracks in the United States are Class I railroads requiring PTC deployment. Approximately 8,400 miles of intercity passenger and commuter railroad tracks in the U.S. also require PTC deployment.
Positive Train Control Cost Benefits
In 2012, the FRA submitted a Report to Congress,1 in which it was stated that the U.S. railroad industry had already invested over $1.5 billion into PTC implementation. It is forecast that railroads will need to additionally invest more than $5 billion their own funds.
The primary benefit of Positive Train Control, and the driver behind the Federal mandate to implement it, is rail safety. Beyond rail safety, the investment in PTC may pay for itself over the long-term through several potential business benefits.
Rail Safety
While PTC will not prevent all rail accidents, it is designed to prevent the majority of human-caused accidents. PTC has been discussed for several years, but it was a major train collision between a Metrolink commuter train and a Union Pacific freight train in September 2008 that prompted the quick passage of the Rail Safety Improvement Act in October of 2008. That collision caused the deaths of 25 people and injury to 135. Damages totaled over $7 million.
An NTSB investigation concluded that the cause of the collision was the failure of the Metrolink commuter train engineer to notice a red signal and to stop the train accordingly.2 Further, the NTSB report stated that a contributing factor to the accident "[...] was the lack of a positive train control system that would have stopped the Metrolink train short of the red signal and thus prevented the collision." The PTC system would have allowed the engineer up to 15 seconds to respond appropriately to the red signal, and stop the train, before the brakes would have been automatically applied by the system.
Business Benefits
The Federal Railroad Association (FRA) funded an analysis of the costs and benefits of deploying a Positive Train Control system.3 The annual benefits upon completion are estimated to be $2.2 billion to $3.8 billion. This is expected to be seen in the following potential business benefits.
•
•
•
•
•
•
•
System Overview
An end-to-end PTC solution is comprised of four main architectural components that include the back office, onboard, wayside, and bi-directional communication transport. Figure 1 shows the high-level architecture of an end-to-end PTC solution.
Figure 1 The High-Level Architecture of an End-to-End PTC Infrastructure
Back Office
The back office houses the Back Office Server (BOS), which stores, processes, and acts on information it receives from the locomotive onboard computer, wayside messaging server, and maintenance personnel. Its database maintains information on trains, tracks, work zones, and speed restrictions. Based on this data, the BOS will issue movement authorities and notifications to the locomotives.
While it is assumed that the BOS will be housed in a Data Center environment, the PTC solution does not have specialized requirement for the Data Center design. Generalized Cisco design best practices and methodologies are covered in the SDU Virtualized Multiservice Data Center system. The VMDC solution provides design and implementation guidance for Enterprises deploying private cloud services and Service Providers building virtual private and public cloud services. The Cisco VMDC reference architecture integrates various Cisco and third-party products that are part of the cloud computing ecosystem.
VMDC 2.3 is an incremental release, leveraging and optimizing the architecture defined in the previous 2.2 release. The VMDC architecture has been optimized to achieve higher tenancy scale at a lower cost and footprint. These optimizations include the following:
•
•
•
•
Onboard
The onboard computer located on the locomotive will receive the motion authorities from the BOS and notify the engineer of changes in the speed limit or other safety concerns. The engineer will use this information, along with information from wayside devices regarding trackside signaling, and take appropriate action. If the engineer does not slow or stop the train within 15 seconds, the onboard computer will automatically apply the brakes. In the event that the onboard system loses connectivity and cannot get this mission-critical information, the train must be stopped prior to entering the next block.
Wayside
The wayside system encompasses the signaling equipment on and around the track. This may include lamps, switches, gates and track circuits, among other things. These devices can connect to a wayside-messaging server through the use of a Wayside Interface Unit (WIU). This allows the messaging server to send information about the trackside equipment to the BOS for processing, and to broadcast the information over a radio interface so that locomotives can receive the information directly and act on it accordingly.
Communication
Communication between the back office, locomotive, and wayside devices relies on a redundant and resilient bi-directional communications network. The PTC solution offers up to four different interface types that can be used for communication, including Ethernet, Wi-Fi, 220 MHz PTC Radio, and 3G/4G Cellular.
The wayside equipment may communicate with the BOS over any one of the four interface types. The onboard equipment will use either the 220 MHz radio or 3G/4G cellular interface, providing mobility. In the case of the locomotive, it must be capable of roaming horizontally from base station to base station. In either case, the device must also be able to roam vertically between communications technologies. For example, 3G cellular may be used as a backup to 220 MHz radio, or a train may switch to Wi-Fi while at the train station or in the yard.
The industry has standardized on 220 MHz radio frequency due to its long range (20 - 30 miles). This distance decreases the number of base stations deployed along the tracks. Because rails are frequently shared across multiple railroad companies, standardizing on a common PTC radio frequency also allows railroads to interoperate with each other.
The transport network, consisting of the access, aggregation, and core networks, will also provide a resilient communications path between the field devices and the BOS. This will include ruggedized Ethernet switching at the edge, and a multipath backhaul with sub-second re-convergence.
Transport Network
The transport network aspects of the Communications layer in the PTC 1.0 system make use of the Unified MPLS Transport designs developed first by the Unified MPLS for Mobile Transport (UMMT) and continued in the Fixed Mobile Convergence (FMC) system efforts. The Cisco FMC System provides reliable, scalable, and high-density packet processing that addresses the transport and service edge aspects of a wide variety of fixed and mobile legacy services, while reducing the operator's total cost of operations (TCO). It handles the complexities of multiple access technologies, including seamless handover and mobility between access networks to meet demands for convergence and product consolidation. The FMC design addresses key functional aspects critical to deploying a robust and highly-available transport network design for the PTC system deployment, including:
•
•
•
•
The Cisco UMMT and FMC systems are Cisco Validated Designs, and have existing design guides which detail all aspects of the system design and methodology for a transport network using Unified MPLS. Those design guides can be found at the following links:
•
•
System Architecture
Cisco Positive Train Control system architecture consists of the following solution components.
The Cisco PTC Solution
To enable railroads within the United States to increase rail safety and meet the requirements of the Federal mandate, Cisco has partnered with Lilee Systems to provide a state-of-the art Positive Train Control solution. Combining the expertise of Lilee Systems and their software-defined PTC radio components with the network and transport expertise of Cisco, railroads of any size or scope can count on a solid and scalable solution.
The PTC radio components supplied by Lilee Systems include the base station, wayside, yard and locomotive radios, as well as the mobility controller. The mobility controller provides central management of all the PTC components and also manages mobility. Base station, yard and wayside radios communicate securely via an IPsec tunnel to the mobility controller. Figure 2 shows a logical PTC radio network layout.
Figure 2 PTC Relies on Redundant and Resilient Backhaul Network with Cellular Backup
The software-defined radios (SDR) provide a high level of flexibility within the PTC network as they can be configured through software to have one or more virtual interfaces. These interfaces can be of the following types:
•
•
•
•
By default, the interfaces shown above have pre-defined order or precedence whereby the available interface with the highest preference (lowest metric) will be used. This can be manually adjusted according to the user needs.
The radios are also equipped with a GPS (Global positioning satellite) receiver for time synchronization and location information. While GPS is the recommended approach to time synchronization, the times may also be synchronized using NTP, or set manually.
All three radio types (locomotive, base station, and wayside) are hardened to operate in the harsh environments of a railroad. As such, they are capable of operating within an ambient temperature range of -40 to 70 degrees Celsius, and an ambient relative humidity of 5 to 100 percent. Industrial connectors are also used to deal with shock and vibration. This means utilizing M12 connectors on the locomotive radios for Ethernet LAN connections rather than standard RJ-45. N-Type connectors are used for 220 MHz radio antenna connections and TNC is used for GPS, 1PPS, and WiFi antenna connections. Figure 3 shows the various connector types.
Figure 3 Various Hardened Connectors Used on Software-Defined Radios
On-board Radio
A train management computer (TMC) is the on-board computer (Figure 4) that will communicate with the back office server. It will use the on-board locomotive radio as its gateway to reach the data center
hosting the BOS. The locomotive radio will typically connect to a base station radio over a 220 MHz radio frequency. The base station will then securely tunnel traffic that it receives from the locomotive radio, back to the mobility controller. In the event that communications to a base station is not available over the radio interface, the locomotive radio may be configured to use the 3G cellular interface as a backup.Figure 4 On Board Radio
When a train enters a train station or train yard, where Wi-Fi communications is available, the locomotive radio can connect to an available Wi-Fi access point, known as a Yard Radio. Connecting to an available Wi-Fi network offloads some traffic from the 220 MHz radio and offers a high-bandwidth connection for management scenarios including train schedule downloads, onboard software maintenance (configurations, upgrades, etc.), or even mission-critical PTC communications if the railroad prefers to use Wi-Fi for this purpose when available.
Base Station Radio
Base station radios (Figure 5) can be placed up to 20 to 30 miles apart from each other along the track. Each one will operate at a unique frequency within the 218-222 MHz range. Through its Ethernet interface, the radio will communicate across the backhaul network securely with the mobility controller hosted in a remote operating center (ROC). In the event that the base station loses its wired connection to the backhaul network, it can be configured to use a 3G cellular connection as a backup.
The base station also has a Wi-Fi interface that can be configured as an access point or a Wi-fi client. This offers a high-speed Wi-Fi connection to maintenance personnel in the immediate area of the base station.
Figure 5 Base Station Radio
Wayside Radio
The wayside radio (Figure 6) is used in wayside (trackside) stations to provide PTC network connectivity to wayside signaling equipment. If fixed wire-line access to the backhaul network is available, the wayside radio may connect to the BOS in the same manner as a base station radio, and use its 3G cellular interface as a backup. If direct connection to the backhaul network is not possible, then the wayside radio may connect to the closest base station over 220 MHz PTC radio for communications. The wayside radio will also broadcast wayside signaling messages so that locomotive radios can receive and act on them directly.
Figure 6 Wayside Radio
Wayside Messaging Server
A wayside messaging server will connect to a wayside radio in order to send PTC messaging about the wayside signaling back to the BOS. Wayside signaling may include lamps, track circuits, grade level gates and track switches, among other things. These wayside devices connect to the wayside messaging server through a wayside interface unit (WIU). The WIU creates a digital message consumed by the messaging server. The messaging server hosts an x86 application engine that processes the messages from the WIU and sends them to the BOS and broadcasts them to the locomotive, both via the wayside radio. If the messaging server loses its connection to the wayside radio, it may be configured to use a 3G cellular interface as a backup to get the messaging to the BOS.
Mobility Controller
The mobility controller (Figure 7) is hosted in a remote operating center (ROC). It provides communication between the trackside network, including locomotive and wayside radios, and the back office server. Communications between the mobility controller and any base station and wayside radios that it communicates with is secured through the use of IPsec tunneling.
Figure 7 Mobility Controller
Remote management, including configuration and monitoring, of the remote devices that are registered with the mobility controller is performed by the mobility controller. This means that while configuration changes to a wayside, locomotive, or base station radio can be performed locally at the device, changes can also be made at the mobility controller and pushed down to the device.
With support for up to 200 base stations per mobility controller, the system offers seamless roaming so the onboard hosts using the radio for network access, appear to be stationary. Horizontal roaming between base stations is less than 50 ms.
Features of the PTC Radios
Primary features of PTC radios include:
User Management
User management is based on RBAC (Role Based Access Control) and allows the administrator to assign each user to an admin or non-admin role. Admins may create management objects, change or delete configurations, perform upgrades, etc. Non-admin users perform configuration backups, manage debug messages, use the ping utility, and other non-intrusive actions.
IP Routing
The PTC devices support static routing only. However, complex routing schemes can be achieved through the use of traffic classifiers, route tables, and priorities (Figure 8).
Figure 8 IP Routing is Accomplished with Classifiers, Route Tables, and Priorities
Traffic classifiers allow the device to classify traffic based on the following:
•
•
•
•
Route tables allow the device to have multiple routing tables. A traffic classifier may reference any available route table, and a route table may be used by multiple traffic classifiers. Each routing table can be configured with the following attributes:
•
•
•
•
Policy routes tie together the traffic classifier and route table. Each policy route has a priority, which is used to assign a preference to the policy route. The lower the priority, the higher the preference. If a route table cannot route a packet for any reason, the decision falls to the next-preferred policy route (Figure 9).
Figure 9 IP Route Decision Process
NAT
NAT (Network Address Translation) can be configured on the Mobility Controller and all of the radio components. SNAT (Source NAT) is used to perform port address translation (PAT) from the private interface to the public interface. DNAT (Destination NAT) is used to perform port address translation (PAT) from the public interface to the private interface.
Network Management
The Mobility Controller supports SNMPv1 and SNMPv2. All SNMP communities are read-only by default, but can be configured as read-write. The SNMP service can be bound to a specific IP address and port on the Mobility Controller.
The Cisco Unified MPLS Transport Design
Another critical consideration providing transport of the remote PTC radio traffic to the back office server and transport mission-critical movement authorities from the back office server to the locomotives. While some railroads may already have a backhaul transport network to some degree, it is assumed that one does not exist.
The Cisco Unified MPLS Transport design utilized in the Cisco FMC system, and the UMMT system before it, will accommodate the backhaul needs of PTC deployments of any size or scale. While the design breaks down the network into access, pre-aggregation, aggregation, and core segments, some segments can be combined depending on the size and scope of the network.
The network design example in Figure 10 represents a smaller network where the core, aggregation, and pre-aggregation networks are combined into a single network domain. The access network is where the base station and wayside radios would access the network via Ethernet.
Figure 10 Unified MPLS Transport Spans Access, Aggregation and Core Network to Connect PTC to Data Center
Figure 10 assumes a flat LDP (Label Distribution Protocol) LSP (Label Switched Path) across the core and aggregation networks. Together, these two networks form one IGP and LDP domain. The MPLS mobile access network is based on MPLS access rings with ASR 901 access routers, and integrated with labeled BGP LSPs. This network can scale up to thousands of access routers and hundreds of pre-aggregation network nodes.
In cases where a larger backhaul transport is needed, the core and aggregation networks can be separated into independent IGP/LDP domains. Inter-domain MPLS connectivity would continue to be based on hierarchical labeled BGP LSPs. A network design such as this would allow for tens of thousands of access nodes and thousands of pre-aggregation nodes.
Several architecture models utilizing Unified MPLS Transport have been tested, validated and documented as part of the FMC and UMMT Cisco Validated Designs. Further, many production deployments of UMMT and FMC mean it is a mature and tested design that railroads can feel comfortable deploying. Table 2 shows the components validated as part of the latest Unified MPLS Transport design: FMC 1.0.
Complete design best practices and methodologies for each of these transport models are detailed in the Cisco UMMT and FMC design guide documents. Links to these documents are contained in the "Transport Network" section.
Remote Ruggedized Switching
At the base station and wayside stations, ruggedized switches that can withstand large ambient temperature ranges (-40C to 75C), and support flexible configurations, are used. The Cisco Industrial Ethernet 2000 and 3000 series switches are layer 2 and layer 3-capable, respectively. They both offer easy deployment, security, and resiliency in a din-rail form factor.
Functional Components
To design a robust, highly available, and manageable system, there are several functional aspects which need to be considered. Among those aspects are:
•
•
•
•
Design best practices and methodologies for each of these areas are detailed in the Cisco UMMT and FMC design guide documents. Links to these documents are contained in the "Transport Network" section.
Conclusion
The Cisco PTC solution provides a full end-to-end solution that will provide the required infrastructure to implement the Federally mandated Positive Train Control across the railroad. The PTC solution is designed to augment safety precautions already undertaken by the locomotive engineer, specifically to prevent human-caused train incidents. In addition, the potential business benefits may provide a compelling Return-on-Investment within a few years of completion.
The software-defined PTC radios offer a fully redundant and resilient solution at the trackside and on the locomotive, and Cisco's remote switching and Unified MPLS Mobile Transport offer redundancy and resiliency throughout the backhaul network. The network can scale to meet the needs of any rail deployment and stand ready to accommodate future growth in capacity and applications.
Authors: Sean Merrow, Jason Dachtler, Ganesh Subramaniam
1 Federal Railroad Administration Report to Congress—Positive Train Control Implementation, Issues, and Impacts, Aug. 20122 Railroad Accident Report NTSB/RAR-10/013 Positive Train Control (PTC): Calculating Benefits and Costs of a New Railroad Control Technology— ZETA-TECH as part of FRA contract DTRF-53-01-D-0021
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)