Federal Railroad Administration 

Report to Congress 

Positive Train Control 

Implementation Status, Issues, and Impacts 

August 2012 
i

Contents 

Executive Summary ........................................................................................................................ 1

1. Introductory Background ........................................................................................................... 3

1.1 System Architectures .......................................................................................................... 4

1.1.1. ACSES .......................................................................................................................... 6

1.1.2. I-ETMS ......................................................................................................................... 8

1.2 Scale of Deployment ......................................................................................................... 12

2. Technical Implementation Issues of Concern .......................................................................... 15

2.1 Communications Spectrum ............................................................................................... 15

2.2 Radios ............................................................................................................................... 19

2.3 Design Specifications ........................................................................................................ 21

2.3.1 Technical Interface Standards ..................................................................................... 21

2.3.2 Contract Specifications ............................................................................................... 22

2.3.3 Interoperability Standards ........................................................................................... 22

2.4 Back Office Servers and Dispatch Systems ...................................................................... 25

2.5 Track Database Verification ............................................................................................. 27

2.6 Installation Engineering .................................................................................................... 29

2.7 Reliability and Availability ............................................................................................... 33

3. Critical Programmatic Issues of Concern ................................................................................. 35

3.1 Budgeting and Contracting ............................................................................................... 35

3.2 Stakeholder Capacity ........................................................................................................ 39

4. Complexity-Safety Risk Prioritized Deployment ..................................................................... 43

5. Legislative Considerations ....................................................................................................... 47

5.1 Consideration 1 ................................................................................................................. 47

5.2 Consideration 2 ................................................................................................................. 48

5.3 Consideration 3 ................................................................................................................. 49

6. Conclusion ................................................................................................................................ 50

 
ii

List of Tables 

Table 1: Intercity Passenger and Commuter Railroad Vehicle Inventory ................................... 13

Table 2: Comparison of Selected Critical PTC Attributes ........................................................... 14

Table 3: Capital Investment of Major Railroads Through 2012 .................................................. 14

Table 4: 220 MHz Radio Requirements ...................................................................................... 21

Table 5: Critical ITC Interoperability Standards ......................................................................... 23

Table 6: Major Railroad Status of PTC Back Office Server and Dispatch Projects .................... 26

Table 7: Status of Track Database Mapping ................................................................................ 28

Table 8: Devices Requiring New Installation or Upgrade ........................................................... 29

Table 9: Switch Modifications Requirements–Non-Signaled Territory ...................................... 32

Table 10: Signal Replacement Projects ........................................................................................ 32

Table 11: Locomotives Equipped with PTC Systems ................................................................. 33

Table 12: How Complexity Affects System Reliability .............................................................. 35

Table 13: Components of the Public Acquisition Cycle .............................................................. 37

Table 14: Integrated WIU Installation ......................................................................................... 40

Table 15: Standalone WIU Installation ........................................................................................ 40

Table 16: PTC Installer Hires ...................................................................................................... 41

Table 17: Order of Installation ..................................................................................................... 47

List of Figures 

Figure 1: Generic PTC Architecture .............................................................................................. 5

Figure 2: ACSES Transponder ...................................................................................................... 7

Figure 3: ACSES Display .............................................................................................................. 8

Figure 4: BNSF Network Operations Dispatch Center.................................................................. 9

Figure 5: Wayside Interface Unit Internal Components .............................................................. 10

Figure 6: Locomotive Control Display (Left) and I-ETMS Display (Right) ............................... 11

Figure 7: I-ETMS Display Graphic Elements ............................................................................. 12

Figure 8: PTC Radio Spectrum .................................................................................................... 17

Figure 9: Meteorcomm PTC Radios ............................................................................................ 19

Figure 10: LIDAR Mapped Rail GIS Data .................................................................................. 29

Figure 11: Control Point with Three Signal Heads ...................................................................... 31

Figure 12: Planning, Program, Budgeting, and Execution Cycle ................................................. 38

Figure 13: Integrated Safety Risk and Complexity Strategy ....................................................... 46
1

Executive Summary 

The Rail Safety Improvement Act of 2008 (RSIA) established a completion date for the 

installation of interoperable Positive Train Control (PTC) systems by December 31, 2015. 

The RSIA also required the Secretary of Transportation to transmit a report to specified 

congressional committees no later than December 31, 2012, on the progress of the railroad 

carriers in implementing such PTC systems. This report satisfies the statutory reporting 

requirement. 

Although the initial PTC Implementation Plans (PTCIP) submitted by the applicable 

railroads to the Federal Railroad Administration (FRA) for approval stated they would 

complete implementation by the 2015 deadline, all of the plans were based on the assumption 

that there would be no technical or programmatic issues in the design, development, 

integration, deployment, and testing of the PTC systems they adopted. However, since FRA 

approved the PTCIPs, both freight and passenger railroads have encountered significant 

technical and programmatic issues that make accomplishment of these plans questionable. 

Given the current state of development and availability of the required hardware and 

software, along with deployment considerations, most railroads will likely not be able to 

complete full RSIA-required implementation of PTC by December 31, 2015. Partial 

deployment of PTC can likely be achieved; however, the extent of which is dependent upon 

successful resolution of known technical and programmatic issues and any new emergent 

issues. 

The technical obstacles that have been identified to date fall into seven different categories: 

 Communications Spectrum Availability 

 Radio Availability 

 Design Specification Availability 

 Back Office Server and Dispatch System Availability

 Track Database Verification

 Installation Engineering

 Reliability and Availability 

The programmatic obstacles fall into two categories: 

 Budgeting and Contracting

 Stakeholder Availability 

To date, railroads have raised and expended more than $1.5 billion of private capital to try 

and resolve these issues. The Federal Government has distributed $50 million through the 

Railroad Safety Technology Grant Program. Solutions to these issues have either not been 

identified or cannot be implemented by the current December 31, 2015, deadline. 
2

Where solutions have not been identified, FRA and the railroads are working together to find 

solutions that support the completion of PTC system installation as soon as possible. Where 

solutions have been identified, all attempts are being made to accelerate their 

implementation. FRA and the railroads are also working to identify any additional issues and 

solutions; however, this effort is hampered by the novel nature of the issues. PTC 

implementation, on the scale required by the RSIA, has never been attempted anywhere in 

the world. 

Recommendations 

Based on the results of this report, FRA believes that the majority of railroads will not be 

able to complete PTC implementation by the 2015 deadline. Partial deployment can likely 

be achieved; however, the extent of which is dependent upon the successful resolution of any 

known and emergent issues. As a result, FRA recommends that if Congress were to consider 

legislation extending the PTC implementation deadline it should consider several factors, 

including the extent to which each railroad has demonstrated due diligence in its efforts to 

successfully implement PTC technologies on its rail system. In the event that Congress were 

to make legislative changes, FRA suggests allowing for provisional certification of PTC 

systems that will allow for the use of installed PTC systems under controlled conditions 

before final system certification is complete. This will allow for the incremental use of PTC 

systems and produce an increase in safety as the systems are systematically rolled out. FRA 

also suggests that any revisions to a railroad’s PTCIP be subject to FRA approval with 

sufficient time for FRA to review and significant FRA oversight. Finally, FRA recommends 

that it be allowed to approve a railroad to use alternative safety technologies on specified line 

segments in lieu of PTC, particularly in areas with lower safety risks, if appropriately and 

properly justified to FRA. 
3

1. Introductory Background 

Section 104 of the Rail Safety Improvement Act of 2008 (RSIA)1 mandated implementation 

of interoperable Positive Train Control (PTC) systems by “each Class I railroad carrier and 

each entity providing regularly scheduled intercity or commuter rail passenger 

transportation” on selected rail lines in risk priority order by December 31, 2015. The statute 

required such implementation on the following lines: 

‘‘(A) its main line over which intercity rail passenger transportation or commuter rail 

passenger transportation, as defined in section 24102, is regularly provided; 

‘‘(B) its main line over which poison- or toxic-by-inhalation hazardous materials, as 

defined in parts 171.8, 173.115, and 173.132 of title 49, Code of Federal Regulations, 

are transported;” 

The functional requirements of a PTC system were also defined in the same statue. 

Specifically, PTC system functionality had to: 

“ prevent train-to-train collisions, over-speed derailments, incursions into 

established work zone limits, and the movement of a train through a switch left in the 

wrong position.’’ 

The RSIA also required each railroad that was statutorily mandated to implement a PTC 

system to develop and submit to FRA for approval a PTC Implementation Plan (PTCIP). 

The PTCIP was required to document the activities and schedule each railroad would take to 

complete installation on a risk-based prioritization by December 31, 2015. The schedules in 

these plans were developed in 2009. Based on the information available at that time, all 

stakeholders agreed that completion by December 31, 2015, though difficult, was feasible. 

All plans, however, assumed that there would be no major schedule issues associated with 

“critical path” activities. 

A critical path2

 is the longest possible continuous path in time between an initial event and a 

terminal event. It represents the total calendar time required for a project; therefore, any time 

delays in activities along the critical path will delay reaching the terminal event by at least 

the same amount. A schedule generated using critical path techniques is sensitive to the 

underlying assumptions, and the accuracy of those assumptions directly impacts the time 

used in defining the critical path. 

Since submission of the original schedules, obstacles have been identified, which will likely 

delay PTC implementation for most carriers past the original December 31, 2015, deadline. 

There was a high degree of risk regarding the assumptions that had been previously 

identified. In December 2010, the U.S. Government Accountability Office (GAO) published 

a report expressing concerns about the ability of the freight and passenger railroads to meet 

 

1

 49 U.S.C. § 20157. 

2

 Fazar, W. “Program Evaluation and Review Technique,” The American Statistician, Vol. 13, No. 2, (April 

1959), p.10. 
4

the RSIA implementation deadline (and concerns about PTC diverting funding from other 

critical needs). The GAO recognized that the industry was embarking on the development 

and installation of unproven technologies.3

 The GAO report stated that it found there was a 

strong potential for delays if certain problematic components of the process were not 

rectified in a timely manner. 

There has been some successful, but limited deployment, of PTC systems. Amtrak has 

deployed the Incremental Train Control System (ITCS) on approximately 60 route miles 

between Chicago and Detroit. Although this system is approved to operate up to 110 mph in 

revenue service, it is not interoperable with any other PTC system. BNSF Railway (BNSF) 

has deployed the Electronic Train Management System (ETMS) on a limited number of pilot 

territories for revenue test and demonstration purposes. ETMS is also not interoperable with 

any other PTC systems. In the United States, the most successful and widely deployed of the 

PTC systems in existence is the Amtrak Advanced Civil Speed Enforcement System 

(ACSES). After starting in 1993, Amtrak has been able to deploy ACSES on their entire 

Northeast Corridor property in revenue service. Even though it is successfully operating at 

speeds up to 150 mph, the system is limited due to its high cost and inability to interoperate 

with other PTC systems, as required by the RSIA. 

The remainder of this report discusses the major PTC implementation obstacles and identifies 

considerations if legislative changes were to be made to the RSIA. 

1.1 System Architectures 

Understanding the issues requires a basic understanding of the PTC system architecture. All 

PTC systems consist of four basic subsystems: Office, Wayside, Onboard, and 

Communications. Each of these subsystems consists of any number of other subsystems. 

These subsystems, in turn, are made up of a number of other subsystems and components, the 

quantity and configuration of which differ based on the actual architectural implementation. 

They also reflect differences in operating practices, not only between freight railroads, but 

also between freight, intercity, and commuter passenger railroads. Commuter railroads have 

a different operating pattern than freight railroad operations, and this difference impacts the 

design, installation, and testing of a commuter-based PTC system. Unlike freight railroads, 

commuter railroads transport large volumes of passengers during hours that require dense, 

high frequency train service, which typically operates in short signal block territories. A 

multitude of design issues related to maintaining short headways with PTC-imposed braking 

logic may limit rush hour capacity. Additionally, the probability of in-service failures of 

PTC equipment installed on rolling stock adds further unknowns to on-time performance for 

a service that is sensitive to delays. Short headways and on-time performance are critical 

marketing issues for commuter railroads to maintain a competitive edge and market share. 

 

3

 GAO, “RAIL SAFETY: Federal Railroad Administration Should Report on Risks to the Successful 

Implementation of Mandated Safety Technology http://www.gao.gov/assets/320/314033.pdf. 
5

Figure 1: Generic PTC Architecture 

Two basic PTC systems have either been adopted, or are being adopted by the majority of 

railroads in North America. Though they are functionally the same, they represent two 

different technical approaches. ACSES relies on the use of track-embedded transponders as 

the primary means of train position determination. I-ETMS relies on the use of GPS as the 

primary means of train position determination. 

Other PTC systems that are already in limited use, or are being considered for use, represent 

variations of ACSES or I-ETMS. 

1. ITCS is in operation on the Amtrak line between Chicago and Detroit, and is being 

considered for use on the Caltrain Line between San Francisco and San Jose. ITCS 

architecture is similar to the I-ETMS architecture. 

2. The European Train Control System (ETCS) is under consideration by the California 

High-Speed Rail Authority for high-speed operations between San Jose and Los 

Angeles. ETCS is similar to the ACSES architecture. 

3. ETMS is an earlier non-interoperable version of the I-ETMS. ETMS will be replaced 

by I-ETMS. 
6

4. Port Authority Trans-Hudson uses Communications Based Train Control (CBTC), 

which is similar to the ACSES model. 

1.1.1. ACSES 

ACSES is a fully operational safety-critical supplement to traditional Automatic Train 

Control (ATC) cab signal systems,4

 and must be used in conjunction with those ATC systems 

to provide the required PTC functionality. The ATC cab signal system continues to ensure 

“Safe Train Separation” and “Signal Speed Enforcement,” as the ACSES system acts as an 

addition to the ATC cab signal system to provide the additional PTC-required functionality. 

The two systems are functionally independent. Only the operating status (cut-in and 

operating or cut-out) and data used for the Positive Train Stop (PTS) enforcement (e.g. the 

ACSES request for an ATC cab signal enforcement of a PTS) is shared between the two 

systems. 

The ACSES system consists of: 

 Passive (fixed) transponders at wayside locations. 

 A ground network communications system consisting of Safety Temporary Speed 

Restriction Server, Wayside Communications Controllers (WCC), Network Servers 

and Encoders, Base Communications Packages (BCP), and a Mobile 

Communications Packages (MCP) onboard the locomotive. 

 ACSES onboard subsystem and onboard transponder reader. 

The ACSES wayside transponders are installed in ACSES territories at the home signal; 

distant signals; and at other signal, block point, or cut section locations to communicate with 

the onboard ACSES subsystem. The transponders provide data to the onboard system, 

allowing it to determine its location and direction along the track. The transponders also 

provide civil (track) speed restriction data for the territory ahead, ensuring that speeds are 

kept safe for the various types of restrictions not caused by train occupancy (bridges, curves, 

etc.). ACSES works on a distance-to-target principle, and the transponder data includes 

targeting distances (distance from the transponder to the data validity point); therefore, 

transponders do not need to be installed at the point at which the system uses the data (i.e. the 

transponders are not installed at the speed change limit, but in approach to it). 

The data radio system (WCC, BCP, and MCP) is used to route interlocking data (route data, 

civil speed limits, etc.) and temporary speed limit data (start of speed restriction, length of 

speed restriction, speed limit, etc.) to the onboard ACSES system. As implemented, it uses 

Advanced Train Control System (ATCS) Specification 2005

 radios. Since ACSES receives 

data from transponders and is paired to ATC cab signal on the NEC, the requirements for 

 

4

 Cab signaling is a railway safety system that communicates real-time route status information to the cab, crew 

compartment or driver’s compartment of a locomotive, railcar or multiple units, where the train driver or engine 

driver can see the information. 

5

 ATCS Specification 200 defines a communications system architecture and radio protocols to facilitate 

compatibility and standardization. 
7

radio communications are not as critical as other communications-based systems, which 

require radio data to be updated frequently (often continuously) onboard. 

Figure 2: ACSES Transponder 

The ACSES onboard computer acts upon the data received from the transponders and uses a 

data radio network to enforce permanent and temporary speed limits. As the train moves 

along the track, it pulls data from the transponders. Each transponder is programmed with its 

site-specific data and installed along the track. With the data received from the transponders, 

the onboard ACSES subsystem generates a speed limit profile and separate brake profile. If 

the train engineer is nearing a point of exceeding the profile, the engineer is given an audible 

warning, and the civil speed limit indication for the upcoming restriction is provided visually 

to the engineer. The engineer must initiate braking within a specified time limit and 

acknowledge the warning, or the onboard ACSES subsystem will initiate a penalty brake 

application. If the brake profile is exceeded, the onboard ACSES subsystem always initiates 

the penalty brake application. 
8

Figure 3: ACSES Display 

1.1.2. I-ETMS 

I-ETMS is a vital overlay system, currently under design, that provides PTC functionality as 

a supplement to the existing method of train operations. It is intended to be implemented 

across a broad spectrum of railroads without modification. Individual railroads can 

customize this system by adopting different variables that reflect individual railroad 

operations. 

I-ETMS consists of: 

 The Office Segment 

 The Wayside Segment 

 The Communication Segment 

 The Locomotive Segment 

The Office Segment comprises one or more back office servers. Back office servers 

interface with other railroad back office systems or applications, the railroad dispatch system, 

and the Locomotive and Communications Segments. The Office Segment serves as a 

conduit for information conveyed to the Locomotive Segment. The Office Segment accepts 

mandatory directives and other information generated by the railroad’s dispatching system 

and other railroad information systems, and provides it to the Locomotive Segment. The 

interface between the Office Segment and the railroad dispatching and information systems 

may be proprietary to a particular railroad. However, the Office Segment normalizes the 
9

operating data provided by a particular railroad’s dispatching and information systems for 

exchange over an interoperable interface with the Locomotive Segment. The Office Segment 

uses commercial off-the-shelf operating systems and relational database management 

systems. 

Figure 4: BNSF Network Operations Dispatch Center 

The Wayside Segment monitors and reports signal indications, switch position, or status of 

other monitored wayside devices directly to the Locomotive Segment and Office Segment 

using one or more radio networks. The Wayside Segment consists of traditional signaling 

equipment to which Wayside Interface Unit (WIU) functionality has been added. Such 

appliances include interlocking controllers, signal controllers, switch circuit controllers, track 

circuits, track/route hazard detectors, or other field devices. Wayside Segment components 

may exist in either signaled or non-signaled territory. 
10

Figure 5: Wayside Interface Unit Internal Components 

The Communications Segment provides the data communications between the Office 

Segment, the Locomotive Segment, and the Wayside Segment. This provides the medium 

for back office communications and peer-to-peer wayside communications. There are two 

primary methods of communication that are composed of wired and wireless networks. 

Wireless networks are made up of narrowband networks (low data throughput and high 

propagation coverage) and broadband networks (high data throughput and low propagation 

coverage). These wireless networks are connected to wired networks at physical access 

points. 

The messaging system is based upon open source software that is customized to meet the 

requirements of I-ETMS. The architecture consists of a back office server with messaging 

clients, such as locomotives and wayside equipment. Wayside, Locomotive, and Office 

applications communicate by addressing messages to one another and handing them off to 

the Communications Segment for delivery. 

The Locomotive Segment provides the interface into the relevant locomotive systems and 

interlocks the locomotive operations in connection with the other three segments to provide 

the safety benefits. The Locomotive Segment accepts movement authorities, temporary 

speed restrictions, mandatory directives, train consist data, and other information from the 

Office Segment. Signal indications and switch position may be received by the Locomotive 

Segment via peer-to-peer communication with the Wayside Segment. The Locomotive 

Segment interfaces with other locomotive devices including an event recorder, train line data 

sensors, horn circuit, brake systems, cab signal system (if equipped), and the Communication 

Segment. 

Multiple train control processing modules, executing identical application software, are used 

to perform all train control functions such as determination of current position, calculation of 

warning and braking distances, management of limits or restrictions conveyed by verbal or 
11

electronic mandatory directive or signal indication, management of off-board 

communications, and communication with the computer display unit (CDU). 

The Locomotive Segment includes diagnostic capabilities to identify and report module-level 

failures. Failure reports are transmitted to the back office when possible, and may be 

forwarded to the railroad’s existing maintenance or monitoring systems to facilitate the 

issuance of repair or trouble tickets for critical faults and to prevent non-critical faults from 

degrading further. In the event of a critical failure, the Locomotive Segment would have to 

be manually cut out to allow locomotive movement until the failure can be repaired. 

Figure 6: Locomotive Control Display (Left) and I-ETMS Display (Right) 
12

Figure 7: I-ETMS Display Graphic Elements

1.2 Scale of Deployment 

In addition to the complexity of the two basic approaches to implement the PTC 

functionality, the scale of the implementation effort further complicates matters. In 2012, 

U.S. Class I6 railroads operated over almost 162,000 miles of track, 60,000 miles of which 

potentially requires the installation of PTC7 under the current laws and regulations. The 

intercity passenger and commuter railroads account for an additional estimated 8,4008 miles 

of track required to be equipped with PTC. 

In addition to the technical and logistical challenges faced by the freight railroads, the 

passenger railroad situation is further complicated because intercity passenger and commuter 

railroads operate in the public sector and are heavily subsidized operations—resulting in a 

severe shortage of capital funds. More than 2 years ago, the initial conservative estimate for 

PTC implementation on intercity passenger and commuter railroads was more than $2 

billion, with more than 4,000 locomotives and passenger cars with control cabs and 8,400 

track miles to be equipped. As intercity passenger and commuter railroads begin installing 

PTC, the total costs of implementation are expected to exceed the initial $2 billion estimate. 

These estimates do not include costs related to the acquisition of the necessary 220 MHz 

 

6

 BNSF Railway, CSX Transportation, Grand Trunk Corporation (Canadian National Railway U.S. subsidiary), 

Kansas City Southern Railway, Norfolk Southern Railway Combined Railroad Subsidiaries, Soo Line 

Corporation (Canadian Pacific Railway U.S. subsidiary), and Union Pacific Railroad. 7

 “Class 1 Railroad and US Freight Railroad Statistics” Association of American Railroads, 2010. This equates 

to roughly 95,700 miles of the U.S. rail network of roughly 140,000 miles. 

8

 2011 FTA National Transit Database at http://www.ntdprogram.gov/ntdprogram/annual.htm. 
13

radio spectrum.9 Also, the intercity passenger and commuter sector represents a small 

percentage of the total rail industry’s needs for PTC hardware and related vendor services, 

placing it at a distinct disadvantage in a market where qualified vendors and equipment are 

limited. 

Table 1: Intercity Passenger and Commuter Railroad Vehicle Inventory10

Total Locomotives Self-Propelled 

Passenger Cars 

No Cab (Active 

Vehicles Only) 

Self-Propelled 

Passenger Cars 

One Cab 

(Active Vehicles 

Only) 

Self-Propelled 

Passenger 

Cars Two 

Cabs (Active 

Vehicles 

Only) 

Locomotive 

Hauled 

Passenger Cars 

No Cab (Active 

Vehicles Only) 

Locomotive 

Hauled Passenger 

Cars One Cab 

(Active Vehicles 

Only) 

4411 651 9 2439 205 2436 907 

The scope of the U.S. deployment can be compared to the European Rail Traffic 

Management System (ERTMS) implementation (Table 1). ERTMS consists of two distinct 

subsystems. The European Train Control System (ETCS), which equates to the Office, 

Onboard, and Wayside subsystems in the U.S. PTC system architectures; and the Global 

System for Mobile Communications Railway (GSM-R), which equates to the 

Communications subsystem of the U.S. I-ETMS architecture. For every critical element 

except one, the U.S. railroads that are required to implement PTC systems have been 

mandated to do more, at their expense (more than $1.5 billion for major freight railroads 

through 2011),11 and in less time than the next largest worldwide PTC system deployment. 

FRA estimates additional unreimbursed industry installation costs to be approximately $5.2 

billion.12

 

9

Testimony of Joseph Giulietti of the South Florida Regional Transportation Authority on behalf of the 

American Public Transportation Association (APTA) at the March 2011 House Transportation and 

Infrastructure Committee hearing regarding implementing PTC on commuter rail. 

10 Aggregate data sourced from APTA, February 2012. 

11 Aggregate data sourced from seven Class I railroads and the Alaska Railroad, January 2012. Aggregate 

information for commuter railroads is not available. 

12 Based on 20-year low cost estimate at 3 percent, Regulatory Impact Analysis, Federal Register Vol. 75, No. 

10, Friday January 10, 2010, page 2,684. 
14

Table 2: Comparison of Selected Critical PTC Attributes 

Attribute ERTMS U.S. Freight PTC U.S. Passenger PTC 

Countries Deployed 33 (World Wide) 1 1 

Miles of Track 37,671 km 

(22971 miles) 

Operational 

~60,000 ~8500 

Equipped vehicles 5700 vehicles (Operational) ~18,00013 ~4400 

RF Spectrum 

Availability 

8MHz 14 available 

 Dedicated by 

National Spectrum 

Manager 

Still TBD 

 Purchase from 

Secondary 

Spectrum Market 

Still TBD 

 Purchase from 

Secondary Spectrum 

Market 

Standards Availability Complete, Available 

 1993 Start 

 Publically 

Funded 

Under Development 

 2009 Start 

 Privately Funded 

Under Development 

 2009 Start 

 Privately Funded 

Cost Per Mile ~£0.79million/ km 

($1.9M/mile) 

~$ 138k /Mile15 ~138k/Mile 

Table 3: Capital Investment of Major Railroads Through 2012 

Railroad PTC investment through 2011 ($) 

ARR 29,000,000 

BNSF 482,481,000 

CN 43,435,000 

CP 37,000,000 

CSX 333,000,000 

KCS 32,500,000 

NS 265,000,000 

UP $335,000,000 

Total $1,557,416,000 

Aside from the technical obstacles to developing PTC systems, it is unlikely any freight 

railroad could meet the December 31, 2015, deadline without significant changes to the 

current geographic scope of PTC system implementation. FRA is working to minimize 

implementation costs and scheduled delays by reducing the nationwide network on which 

PTC is required. FRA has published a final rule that eliminates certain qualifying tests that 

require PTC implementation on some track segments despite changes in poison-by-inhalation 

materials traffic patterns prior to the December 31, 2015, deadline. FRA estimates a 

substantial reduction in the geographic scope of the PTC system mandate as a result of this 

rule change. In addition, FRA has announced it will initiate a rulemaking that could further 

reduce the geographic scope of the PTC system mandate. 

Once the technical issues are resolved, FRA certifies the PTC systems, and PTC equipment is 

installed, then the railroads will deploy their PTC systems. Most railroads will implement 

PTC systems on a subdivision basis. On each PTC system subdivision, a number of 

 

13 Estimate is based on data provided by the AAR for the seven Class I railroads and Alaska Railroad. 14 This is a 4 MHz data uplink and a 4 MHz data downlink. 

15 HNTB, “Positive Train Control: How Does it Work? Is anyone using it now? How much will it cost? And 

what do we know about the regulations due in October?” The HNTB Companies, June 2009. Estimates range 

from a low of $50,000 per mile to $138,000 per mile. 
15

milestones will occur prior to commissioning a PTC system, including the installation of 

WIUs, equipping locomotives, training employees, ensuring the accuracy of the track 

information, and installing and testing of communications infrastructure. Revenue service 

demonstrations will take place on all routes and the PTC system interconnection with every 

potential signal display will have to be tested. Only at that point will a PTC system be ready 

to be fully implemented. 

All aspects of equipment procurement and installation that are applicable to freight railroads 

are equally applicable to intercity passenger and commuter railroads, with additional 

complications. These include varied configurations of different types of equipment such as 

self-propelled cars, push-pull equipment, and locomotives. Intercity passenger and 

commuter fleet inventory also has varied types of propulsion systems and equipment vintage 

(new, old, or rehabilitated), requiring technology and component modifications, and far more 

limited development and testing resources. 

2. Technical Implementation Issues of Concern 

In the design, development, and implementation stages of PTC systems by the freight, 

intercity passenger, and commuter railroads, there are numerous unresolved technical 

obstacles impeding progress in the following areas: 

 Communications Spectrum Availability 

 Radio Availability 

 Design Specification Availability 

 Back Office Server and Dispatch System Availability

 Track Database Verification

 Installation Engineering

 Reliability and Availability 

2.1 Communications Spectrum 

All PTC wayside locations and all PTC-enabled locomotives must be equipped with an 

interoperable wireless communications infrastructure through a combination of 

communications media. More specifically, the railroads will use wide area networks for 

voice and data communications for wayside and field operations (leased and private circuits, 

fiber, and microwave systems). Many railroads will require upgrades to their wide area 

networks to increase capacity, enhance reliability, provide redundancy, and support current 

digital communications protocols (e.g., Internet Protocol). The specific communications 

technology deployed at a particular location will depend on the railroad’s communications 

network. The infrastructure required for each communications path is different, as is the 

availability and maturity of the components of each infrastructure type. 

Railroads were required to create a private radio frequency (RF) network capable of 

transmitting and receiving the data necessary to support an interoperable PTC system 

network. The frequency needed to provide greater coverage and reliability than the cellular 
16

networks in the United States. The RF spectrum must be available to support congestion-free 

and error-free data channels of the PTC system communications. Of particular concern is the 

availability of RF wireless communications spectrum planned for use between 217.6 MHz 

and 222 MHz. The industry adopted 220 MHz as the interoperability communications 

standard. 

Spectrum in this range is necessary for a number of reasons. First, the 220 MHz spectrum 

has excellent propagation characteristics at relatively low transmission powers. This 

supports the use of relatively wide communications tower spacing and relatively low 

transmission power levels. The former provides for significant reductions in communication 

infrastructure deployment costs, while the later minimizes interference not only between 

railroad PTC subsystems communicating on close or adjacent channels, but also with nonrailroad spectrum users. 

PTC 220 LLC (a consortium of Norfolk Southern Railway (NS), CSX Transportation (CSX), 

Union Pacific Railroad (UP), and BNSF) was able to purchase significant amounts of 

spectrum in the required 220–222 MHz spectrum range. PTC 220 has accumulated the 

aggregation of 220 MHz spectrum of up to 350 KHz, or approximately fourteen 25 kHz 

channels in most areas, nationwide. 

Although spectrum demand studies by these four railroads have indicated that this number of 

channels is sufficient to support freight and some passenger RF communications along rail 

lines with low to moderate density rail traffic, it would not support required communications 

along high density traffic lines. In areas where high density rail operations occur, greater 

amounts of 220 MHz spectrum are necessary. Even though the four freight railroads are able 

and have indicated a willingness to provide access to any excess spectrum capacity they may 

have, the fact remains that additional spectrum purchases will be required by intercity 

passenger or commuter railroads operating in areas of high density rail operations. A recent 

APTA survey found that only three out of the more than 20 commuter railroads have been 

able to acquire spectrum necessary for the statutorily required interoperable communications, 

at least one of which is leasing spectrum from the freight railroads. 

With virtually no additional 220–222 MHz spectrum available for acquisition by the intercity 

passenger and commuter railroads, they have had to consider available spectrum adjacent to 

the 220–222 MHz band. Spectrum in the bands known as the Advanced Mobile Telephone 

System (AMTS) and the Interactive Video and Data Services (IVDS) was available. The 

AMTS spectrum consists of A and B blocks within the 217–218 MHz range and the 219–220 

MHz range, each block providing 1 MHz of spectrum. The IVDS spectrum consists of two 

blocks that are equally divided at 500 kHz between 218 MHz and 219 MHz. 

 
17

Figure 8: PTC Radio Spectrum 

Although sufficient spectrum to augment the freight-owned spectrum between 220–222 MHz 

is potentially available, there are two critical issues that impact intercity and commuter 

operators’ ability to purchase the spectrum. The first issue is that portions of the spectrum 

are in use or are encumbered. In some areas, where ATMS spectrum was available for 

purchase, interference from nearby ATMS incumbents operating under the terms of their 

license would adversely impact the usability of the available spectrum for PTC operations. 

In other areas, purchase of available ATMS spectrum would require extensive modification 

to subleases already granted by the incumbent to protect against interference. Finally, in 

other locations, the AMTS spectrum blocks are not on the market. Similar situations exist 

with the IVDS spectrum. These same issues would also be faced by freight railroads 

attempting to procure ATMS or IVDS spectrum to augment their existing 220–220 MHz 

holdings. 

The second issue is that as publicly owned entities, acquisition rules and budgeting cycles are 

such that the ability of intercity passenger and commuter operations to purchase suitable 

ATMS or IVDS spectrum is more cumbersome than the freight railroads. To date, the seven 

Class I railroads have invested approximately $40 million in acquiring and managing 220 

MHz spectrum. The railroads might need to invest more to acquire additional spectrum to 

ensure adequate coverage in certain congested metropolitan areas and have started 

conducting radio frequency propagation studies in Los Angeles and Chicago to determine if 

their holdings are sufficient to support PTC in the heavily trafficked and populated areas. 

This acquisition of new spectrum would be subject to public procurement policies, which are 

generally structured in such a manner so as to require “full and open” competition for major 

procurements. Full and open procurement requires significant amounts of time to prepare the 

bid documents, write the solicitation, evaluate proposals once they have been submitted, and 
18

work through final negotiations to contract award. This process can take anywhere from 6 

months to 1 year. This period can be further extended in the case that a losing bidder protests 

the contract award. Compliance with the mandated public procurement policies may not 

support acquisition of sufficient spectrum in a timely enough manner to support PTC system 

installation, testing, and deployment by the current 2015 deadline. 

In most cases, these spectrum acquisitions were not anticipated; and, therefore, not a 

budgeted acquisition for the intercity passenger and commuter railroads. Shifting current 

funds to address this unanticipated requirement may not be practicable. There may be 

insufficient appropriations available to enter into any new contracts. In other cases, 

reprogramming funds potentially results in deferment, disruption, or elimination of already 

planned capital safety improvement projects or the intercity passenger and commuter service. 

Spectrum acquisition could be planned and submitted in out-year funding streams. 

Commuter railroads are typically funded with fiscal year (FY) Federal appropriations and 

other discretionary grants or funding sources, and PTC spectrum was not a planned 

expenditure prior to FY 2012. For most organizations, FY 2013 would be the earliest year 

they would be able to dedicate Federal, State, and local funds to PTC implementation. In 

some cases, the FY 2014 budget would represent the first opportunity to submit a planned 

spectrum acquisition for approval. In such cases, actual spectrum acquisition, assuming the 

spectrum required is still available on the market, would not occur until FY 2014. Since 

spectrum is required to support subsystem integration, system qualification testing, FRA 

system certification, and deployment, it is doubtful that this budget process can in all cases 

occur before the December 31, 2015, deadline. 

This spectrum shortfall was previously documented in a number of places by a number of 

sources including the Association of American Railroads (AAR),16 the Federal Transit 

Administration (FTA), the Transportation Research Board, and the Transit Development 

Corporation Inc.17 Although the total spectrum requirement for freight, intercity passenger, 

and commuter railroads remains unknown; and the cost of accessing 220 MHz spectrum 

owned by PTC 220 or other 220 MHz spectrum licenses for intercity passenger and 

commuter requirements is also unknown; the railroads have attempted to get spectrum in the 

secondary market with varying degrees of success. In certain geographical regions, the 

Federal Communications Commission (FCC) has not assigned the 220 MHz licenses 

identified by commuter train operators for PTC system operations. In contrast to the 

aforementioned freight and commuter operators, some commuter operators have requested 

that the FCC allocate these licenses at no cost. The FCC has requested information from 

industry to better understand the commuter railroads’ spectrum needs.18

 

16 PTC Implementation: The Railroad Industry Cannot Install PTC on the Entire National Network by the 2015 

Deadline, Association of American Railroads, January 18, 2012. 

17 PTC Radio Spectrum Planning for Passenger Commuter Rail Operators in the United States, TCRP Project J6, Task 79 Report Prepared by Stantec Consulting Services for the American Public Transportation Association 

and the Federal Transit Administration, November 2011. 

18 FCC Public Notice DA 11-38 Wireless Telecommunications Bureau Seeks Comment on Spectrum Needs for 

the Implementation of the Positive Train Control Provisions of the Rail Safety Improvement Act of 2008, WT 

Docket No. 11-79 of 5 May 2011. 
19

2.2 Radios 

In order to use the RF spectrum while supporting interoperability, radios operating with a 

common shared protocol in the 217–222 MHz spectrum range are required. These radios are 

all required to support PTC subsystem integration, system qualification testing, FRA system 

certification, and widespread deployment before the December 31, 2015, deadline. The 

shared protocol, developed by the Interoperable Train Control Committee (ITC)19 of the 

Class I freight railroads, is not available as a commercial off-the-shelf product. The ITC 

charged Meteorcomm Communications to develop a software defined radio (SDR)20 that 

implements the shared protocol. SDR provides greater flexibility in implementing changes 

in communications protocols, as well as greater simplicity in design, since the radio functions 

can be implemented on general purpose, instead of special purpose, processors. SDR also 

reduces deployment risks, making it possible to deploy expensive infrastructure or large 

numbers of mobile devices without locking in the communications standard that will be used. 

This insulates the user from potential changes and market uncertainty. 

Figure 9: Meteorcomm PTC Radios 

It is challenging to design a reliable radio that can operate over long periods of time in the 

railroad operating environment and be economically manufactured. 

 

19 The ITC consists of the UP, CSX, NS, and BNSF. These railroads have developed the PTC architecture and 

standards that ensure interoperability. This architecture and the associated standards functionally define the IETMS system. 

20 An SDR is radio where components that have been typically implemented in hardware are instead 

implemented in software. 
20

The key challenge for radio reception is the detection of weak signals in noise with a small 

probability of missed detection. This requires that the radio receiver detect dissimilar, 

frequency band dependent, primary signals at differing power levels. For radio 

transmissions, the challenge is using modulation schemes that provide best spectrum 

utilization and capacity while avoiding interference to any primary user. The desired 

transmission scheme should be flexible to allow assignments of any band to any user, and 

should be scalable with the number of users and bands. The radio must accomplish this 

while withstanding changing temperatures, vibrations, and humidity in close proximity with 

other electronic systems that can cause interference and electromagnetic capability issues. 

These issues must be addressed not only for one radio, but three radios (office, wayside, and 

onboard) all with different design characteristics. Meteorcomm has completed and 

operationally tested prototypes of all three radios. However, the designs are not expected to 

be ready for production until fall 2012, with production quantities not available until late 

2012 or early 2013. Meteorcomm does not have manufacturing capacity. As a result, 

Meteorcomm must subcontract to third party manufacturers. 

Although the number of radios required by the railroad industry is approximately 60,000 

units for the Class I railroads over a 3-year period,21 when considered in broader commercial 

context, it is a relatively small quantity. The 220 MHz radios being developed by 

Meteorcomm implement the ITC-specified protocol. In comparison, mobile device unit 

sales,22 which use similar technologies but do not require implementation of the ITC 

protocol, exceeded 440 million units globally in the third quarter of 2011 alone. 

Once PTC systems are installed, the railroad demand for radios will decrease significantly, 

further reducing the attractiveness of the rail market. After completing the initial buy, 

railroad demand will be limited to replace radio units for non-repairable failures. Given this 

comparatively limited market, it is likely that the economics of PTC radio production will not 

attract manufacturing firms with large production capability due to the limited potential 

returns on their investment. Those firms that it does attract will have limitations that may 

preclude production of sufficient quantities of PTC radios at a rate that fully supports 

complete PTC system deployment by all railroads by December 31, 2015. As shown by 

Table 4, only a small number of 220 MHz radios have been installed for testing purposes. 

 

21 This is based on one radio each for the estimated 37,000 WIUs and 18,000 locomotives that must be equipped 

by the Class I railroads. 

22 Gartner Press Release of November 15, 2011, http://www.gartner.com/it/page.jsp?id=1848514, last accessed 

January 9, 2012. 
21

Table 4: 220 MHz Radio Requirements 

Railroad ARR BNSF CN CP CSX KCS NS UP Total 

# Base station 220 

MHz radios 

# needed 35 731 182 116 1285 120 600 1050 4119 

# installed 0 4 0 0 0 0 0 0 4 

# of future 

installations 

needed 

35 727 182 116 1285 120 600 1050 4115 

# Wayside location 

220 MHz radios 

# needed 128 5863 1971 1203 6744 1457 5478 13700 36544 

# installed 0 26 0 0 0 0 0 0 26 

# of future 

installations 

needed 

128 5837 1971 1203 6744 1457 5478 13700 36518 

Locomotive 220 MHz 

radios 

# needed 54 2000 1000 1000 3600 520 3411 6532 18117 

# installed 0 2 0 1 0 0 0 0 30 

# of 

locomotives 

remaining to 

be equipped 

54 1998 1000 999 3600 520 3411 6532 18114 

2.3 Design Specifications 

There are three general types of specifications associated with PTC systems: technical 

interface standards, contract specifications, and interoperability standards. The technical 

interface standards establish uniform engineering of technical criteria, methods, processes, 

and practices. The contract specifications describe in detail the scope of work, materials to 

be used, method of installation, and quality of workmanship for work to be placed under 

contract. Interoperability standards make it possible for systems from different 

manufacturers or based on different architectures to operate together seamlessly. 

2.3.1 Technical Interface Standards 

PTC system interoperability makes technical interface standards important. Technical 

interface standards are the explicit rules permitting components and subsystems to be 

assembled in larger systems and work together. They serve as a means for defining what is 

delivered in terms of functionality and performance from a component or a subsystem to 

other parts of the system, and provide a starting point for the processes of integrating the 

entire system. In this sense, technical interface standards serve as a means of simplifying the 

complexity and limiting the divergence between different elements of a system. 

The definition of PTC interoperability encompasses both a technical and an operational 

capability. The technical capability (ability of systems, units, or staff to provide services to 

and accept services from other systems, units, or staff) addresses issues of connectivity 

among systems, data and file exchange, networking, and other communication-related 

scenarios. The operational capability (ability of systems, units, or staff to use the services so 

exchanged to enable them to operate effectively together) addresses the degree to which 
22

value is derived from that technical capability. Identifying technical requirements for 

interoperability is challenging but straightforward; ensuring “effectiveness” of the technical 

solution is more complex because the operational environment in which effectiveness is 

assessed is a moving target. 

2.3.2 Contract Specifications 

The second type of specification describes in detail the scope of work, materials to be used, 

method of installation, and quality of workmanship for work to be placed under contract. In 

turn, a collection of specifications and standards are a part of the contract documents 

contained in the project manual consisting of written descriptions of a technical nature of 

materials, equipment, construction systems, standards, and workmanship. 

Specifications are involved in both public and private projects; however, they are especially 

important when a project is using a public bidding process or when there are detailed 

requirements for the project. They define the project in greater detail than drawings, 

contracts, and agreements alone. Contract specifications play an important role in the 

ultimate success of any project. It is important to consider the goal and intent of the project 

in the specifications. Contract specifications that are clear, well written, and well organized 

can result in greater bid accuracy, reduced complications, quantifiable measures of the 

projects’ success, and clarity of the requirements and desires throughout the project lifecycle. 

The purpose of the bidding process is to select a qualified contractor to do a well-defined job 

to a known schedule for a known cost. To fulfill this goal, the bid documents (of which the 

technical interface specifications are an integral part) must be clear, concise, fair, and, above 

all, unambiguous. To have a reasonable and fair basis for comparison, it is important that all 

bidders are basing their offers on the same set of criteria, and under the same conditions. If 

the specifications or requirements are vague, the contractors may be bidding on widely 

varying grades of equipment, and may be making invalid assumptions about the scope of 

work. This results not only in an unacceptable spread in bids, but makes it more likely that 

the successful bidder will not deliver what is intended or expected. 

2.3.3 Interoperability Standards 

Development of industry interoperability standards is a difficult task and potentially 

expensive,23 requiring specialized knowledge of what is to be standardized, harmonization of 

conflicting vested interests, trust-building, and concessions to create robust, durable, wellaccepted standards. Interoperability is not a binary state. There are different degrees and 

types of interoperability. It is impossible to say “system A is interoperable but system B is 

not.” Someone has to be able to state the level of interoperability that is necessary and what 

systems constitute a particular interoperability domain. Interoperability may also be volatile 

because the requirements of any given system in the domain may change. 

 

23 Interoperability standards, by their nature tend to be more prescriptive since they require specification of 

fixed formats. The cost relationship between prescriptive and performance standards is highlighted in the 

Office of Management Budget Circular A-4 “Regulatory Analysis,” September 17, 2003. 
23

In the case of I-ETMS interoperability, CSX, BNSF, NS, and UP formed and funded the ITC 

to define the standards for interoperability. This required the establishment of seven different 

working groups to define the architectures, interfaces, communication protocols, data 

elements, message formats, management and control mechanisms, and processes and 

procedures. These working groups have identified and created 26 critical standards to 

capture the requirements, most of which are not expected to be finalized until late 2012 

(Table 5). As the ITC completes these documents, they are turned over to the AAR for 

adoption as railroad industry standards. 

The scope, complexity, and difficulty of PTC interoperability exceed what was originally 

anticipated. Consequently, the adoption of these standards as railroad industry recommended 

practices and standards has not occurred. This has impacted the original ITC railroads and 

the industry as a whole. Without firm interoperability standards, preparation of contract 

documents to develop and implement PTC has been delayed. Therefore, the start of the 

acquisition process for many railroads has been delayed. In situations where the standards 

are available, they cannot be considered “final” as no interoperable PTC systems have 

previously been built. Therefore, the standards’ correctness and completeness cannot be 

evaluated. This creates a potential level of risk that could impact the deployment of 

operational PTC systems by the December 31, 2015, deadline. The delays and lack of 

specification stability are significant in the case of commuter and intercity passenger 

railroads because they have not been involved in the drafting of the interoperable PTC 

system standards, and they are reliant upon the availability of this information to enable their 

system procurements and associated deployments. 

Table 5: Critical ITC Interoperability Standards 

# Specification Title Description Specification Type 

Estimated 

Completion 

Date 

1 Locomotive to Back 

office 

ICD 

Message Formats for messages 

flowing between the locomotive and 

back office 

Interface Control 

Document 

Pending 

Publication 

2 Wayside to 

Locomotive 

ICD 

Message formats for messages 

flowing between the wayside and 

locomotive 

Interface Control 

Document 

Pending 

Publication 

3 Track Database File Track data file format for use by the 

PTC system 

Interface Control 

Document 

Pending 

Publication 

4 Locomotive to Energy 

Management ICD 

Message formats for messages 

flowing between the locomotive and 

the energy management system 

Interface Control 

Document 

Estimated 

completion 

date under 

review 

5 Energy Management 

to Back office ICD 

Message formats for messages 

flowing between the back office and 

the energy management system 

Interface Control 

Document 

Estimated 

completion 

date under 

review 

6 Human Machine 

Interface (HMI) 

Specifications 

Onboard display standards Interface Control 

Document 

Pending 

Publication 

 
24

7 Level 0 Requirements Consists of the top level system 

requirements and objectives 

addressing the following areas; 

Statutory and regulatory, Safety, 

Performance and Interoperability 

Requirements 

Specification 

Pending 

Publication 

8 Level 1 requirements System level requirements for the 

onboard application derived from 

the Level 0 requirements 

Requirements 

Specification 

Pending 

Publication 

9 System Reference 

Architecture 

ITC Architecture Summary Architecture Specification Pending 

Publication 

10 Systems Management Specifications for Systems 

Management 

Requirements 

Specification 

Complete 

11 Time and Location 

ICD and 

Specifications 

Requirements specification for ITC 

Time and Location services 

Requirements 

Specification 

Pending 

Publication 

12 Systems Management 

– Level 1 

Requirements 

System level requirements for the 

Systems Management derived from 

Level 0 requirements 

Requirements 

Specification 

Review 

13 EMP Protocol 

Specification 

Edge message protocol: Message 

envelope for ITC Applications 

Protocol Specification Complete 

14 Class C Specification Message transport for ITC 

Applications 

Protocol Specification Complete 

15 Class D Specification Message transport for ITC 

Applications 

Protocol Specification Complete 

16 Communications – 

Level 1 Requirements 

System Level requirements for the 

messaging system derived from the 

Level 0 requirements 

Requirements 

Specification 

Pending 

Publication 

17 PTC Data Model 

Definition Document 

Describes the PTC Intermediate 

Data model 

Database Definition Pending 

Publication 

18 PTC Physical 

Database Model 

Physical Database Model Database Definition Pending 

Publication 

19 PTC Logical Database 

model 

Logical Database Model Database Definition 6/14/2012 

20 S-9101 Locomotive 

Electronic 

Architecture 

Interface from Locomotive OEM 

Control System to the Train 

Management Computer 

Architecture Specification Complete 

21 Wayside Interface 

Unit (WIU) 

Requirements 

System level specifications f or WUIs Requirements 

Specification 

Pending 

Publication 

22 Wayside Level 1 

Requirements 

System level requirements for the 

WIU derived from the Level 0 

requirements 

Requirements 

Specification 

Pending 

Publication 

23 Standalone Wayside 

Messaging Server 

Hardware specification for 

messaging server at the wayside 

Requirements 

Specification 

Complete 

24 Integrated Wayside 

Messaging Server 

Hardware specification for 

messaging server at the wayside 

Requirements 

Specification 

Complete 

25 Locomotive 

Messaging Server 

Specification 

Hardware Specification for 

messaging server on the locomotive 

Requirements 

Specification 

8/1/2012 

26 Master Test Strategy Test strategy for the development of 

common test cases 

Test Plan 6/19/2012 

It is useful to contrast the ITC/AAR efforts to the European Union (EU) ERTMS 

specification development effort. ERTMS began development of their standards in 1993 

with EU Council Directive 96/48/EC99. It was not until April 25, 2000 (7 years later), when 

the first ERTMS specifications were finalized. The ERTMS specifications were 

subsequently revised to include additional functionalities to better meet the needs of the 

railway companies and infrastructure managers. The current specifications are contained in 
25

the SRS 2.3.0d,24 which was adopted by the European Commission in April 2008. This 

version of the specifications is by no means final. It is known to contain errors and “open 

points,” 41 of which have been identified as priority items for inclusion in the Version 3.0 

update. Almost 20 years after the EU Council ordered the development of ERTMS to 

provide interoperable train control, the specifications are still being finalized and improved. 

Additionally, the overwhelming majority of costs associated with this specification effort 

have been borne by the member States of the EU, while the ITCS costs have been covered by 

the ITC member railroads. Not only did ERTMS specification development take a 

significant period of time to complete, ERTMS has required a significant amount of time to 

deploy. It has taken since 200225 to install the approximately 2,300 miles of ERTMS 

deployed to date, which is primarily on a passenger rail network compared to the more 

complex shared freight and passenger network in the United States. 

2.4 Back Office Servers and Dispatch Systems 

The primary function of the PTC back office server and dispatch system is to communicate 

and coordinate crew sign-in and sign-off, bulletins, train orders, track authorities, speed 

restrictions, train information (e.g. consist, location, operating, and health status, etc.), and 

other specialized data to and from the wayside, and each locomotive to help with the safe and 

efficient movement of trains. The dispatch system allows the generation and analysis of this 

data, while the back office server coordinates the exchange of the data between wayside, 

locomotive, and back office servers belonging to other railroads. The back office server 

takes information from the dispatch system, translates it to a common shared interoperable 

message format, and then routes the generated message for delivery to the recipient. It 

provides the mechanism that enables interoperability between different railroads. This is 

accomplished by providing and managing connectivity of those devices connected to it in 

real time. It is the responsibility of the back office server to select the appropriate 

communications for delivery to the intended destination. Without the back office server, 

PTC systems would be unable to communicate with systems owned and operated by other 

railroads. 

The I-ETMS back office server is still under design. Its development requires three different 

sets of standards or specifications to be completed. First are the interoperable interface 

standards between the back office server and the locomotive subsystem, the back office 

server and the wayside subsystem, and the back office server and other back office servers. 

These standards are under development by the ITC, as discussed in Section 0. Second are the 

interoperable interface standards between the back office server and the railroad-specific 

dispatch system. These are also under development by the individual railroads. Once fully 

defined, the railroad owning the dispatch system is required to make the necessary changes to 

the dispatch system to allow it to communicate to the interface presented to it by the back 

office server. Third are the requirements’ specifications that define hardware and software 

that constitute the back office server and provide the requisite functionality. Although the 

performance requirements for the back office server hardware and software have been 

 

24 The version of ERTMS defined by SRS 2.3.0d roughly corresponds to I-ETMS. 

25 Bombardier pioneered the world’s first commercial ERTMS in Switzerland, 2002. 
26

defined by the railroads, the requirements that define the hardware and software 

implementation to provide the functionality are not complete. 

Completion of the interoperable interface standards is necessary before the developer can 

finish the development specifications for the back office server. Without this information, 

the developer cannot complete the detailed design specifications necessary to create the back 

office server hardware and software. Once these specifications are complete, the developer 

has only completed the first of the five steps of the design process—problem definition. Still 

remaining are gathering of pertinent information, generation of potential solutions, analysis 

and selection of solution, and the implementation and test of the solution. 

Gathering pertinent information can reveal facts about the requirements that result in a 

redefinition of the problem or the discovery of mistakes and false starts made by other 

designers. It can also reveal that there are no existing solutions to the identified problems. 

This information supports the synthesis of ideas, tools, and methods that can potentially solve 

the problem. Potential solutions developed in the generation phase must then be analyzed 

against the requirements, and a solution selected. The analysis includes: functional, 

ergonomic, mechanical, electrical, manufacturability and testability, product safety and 

liability, economic, and regulatory compliance. The final phase of the design process is 

implementation, which refers to the testing, construction, and manufacturing of the solution 

to the design problem. This involves determining the methods of implementation, such as 

prototyping and concurrent engineering, and the distinct activities that must occur during 

implementation, such as documenting the design solution, communicating the design to the 

stakeholders, testing, verifying that the implementation operates correctly, and validating that 

the implementation conforms to the original requirements. 

FRA feels that a significant level of effort still remains for the developer and the 

implementing railroads. Most railroads do not have final back office server software 

available. The final version of the back office server software that will be used by a number 

of railroads is not scheduled to be delivered until late 2012. At that time, the railroads will 

need to lab test the software. Therefore, a production version of this critical back office 

server software will likely not be available until the first quarter of 2013, at the earliest. 

Table 6: Major Railroad Status of PTC Back Office Server and Dispatch Projects 

Railroad Date System will be PTC-capable 

ARR November 2012 

BNSF Completed 

CN December 2012 

CP December 2012 

CSX 4th quarter 2013 

KCS December 2012 

NS 2nd quarter 2013 

UP Completed 

Railroad dispatch systems, most of which have been upgraded in the last 10 years, are 

milepost-based and generally require a precision of one-tenth of a mile to operate trains 

safely. The level of precision required for PTC systems requires some dispatch systems to be 
27

rewritten or redesigned to convey movement authority information to PTC systems with 

greater precision, e.g., to the ten-thousandth of a mile. Railroads are working with their 

dispatch system developers to incorporate this precision and other enhancements required for 

PTC systems. Most railroads will not have PTC-capable dispatch systems until the end of 

2012 or the beginning of 2013. 

Commuter railroads present a variety of additional requirements for the back office segment. 

Those who dispatch their own trains must invest in the complete set of upgraded dispatch 

systems and back office servers to communicate PTC command and control information. 

Many commuters operate as tenants on a network of tracks of which at least a portion is 

dispatched by other railroads. In these cases, the commuters involved are not well positioned 

to influence implementation schedules. 

2.5 Track Database Verification 

PTC track databases are used to provide PTC system information about the position and 

nature of critical infrastructure components such as locations of signals, civil speed 

restrictions, switch locations, and clearance points. This information provides the basis for 

the PTC system calculating the warning and enforcement distances necessary in order to 

provide the required system functionality. The accuracy of the information required for a 

PTC system is more precise than what is required to run a safe and efficient railroad in a nonPTC environment. Inaccuracies in identification of the critical infrastructure component 

types and locations can potentially result in catastrophic failures in the operation of the PTC 

system. 

Field assets26 that are critical to PTC systems (of which there are approximately 500,000) 

must be geolocated to a horizontal precision of less than 2.2 meters (approximately 7 feet) 

and a vertical precision of 0.8 meters (approximately 2 feet) to provide the accuracy 

necessary to safely warn or stop a locomotive. Furthermore, it is not just the PTC routes that 

must be mapped. Yards, industry, and other connecting track also must be mapped to 

account for entry onto and exit from PTC track. More than 63,000 miles of right of way will 

be mapped. Therefore, PTC is requiring each railroad to undertake a complete, highly 

precise physical survey of the track and wayside infrastructure in a fashion not seen since the 

1917 Federal Government survey of railroads. 

 

26 The calculation of assets to be mapped includes the following: integer mileposts; signals; crossings; switches; 

interlocking/control point locations; permanent speed restrictions; the beginning and ending limits of track 

detection circuits in non-signaled territory; clearance point locations for every switch location installed on the 

main and siding tracks; and inside switches equipped with switch circuit controllers. 
28

Table 7: Status of Track Database Mapping 

Railroad ARR BNSF CN CP CSX KCS NS UP Total 

# PTC assets to be* mapped 

and extracted for GIS 

consumption 

2800 95925 25630 20378 114731 9641 77000 130000 476105 

# track miles 

required to be 

GIS mapped 

# miles 

mapped to 

date 

600 7237 80 534 20710 1977 16107 19500 66745 

# miles to 

be mapped 0 16724 4300 2202 855 250 0 5900 30231 

 # track miles 

required to be 

data processed 

# miles 

processed 

to date 

0 3410 0 104 2075 153 231 19500 25473 

# miles 

remaining 

to be 

processed 

600 20551 4300 2632 19,490 2074 16107 5900 71,654 

 # track miles 

GIS data to be 

converted to 

PTC subdiv 

files 

# converted 

to date 0 2358 0 104 302 153 231 265 3413 

# 

remaining 

to be 

converted 

600 21603 4300 2632 20753 2074 16107 25135 93204 

After mapping is complete, additional data from multiple railroad systems must be 

incorporated into a PTC data model for use on board the locomotive in a “subdivision file.” 

These data points include all track classes, clearance points, quiet zones, and bit assignments 

for wayside communications. There are more than 200 attributes that must be included. 

Railroads must verify and validate the accuracy of the geographic information system (GIS) 

data and the way the onboard system interprets the data. Every mile must be traversed prior 

to “turning on” a PTC system to make sure the rail network is represented accurately. 

The data acquisition and maintenance cycle represents repeated phases of revision and 

expansion that a GIS database must go through to remain up-to-date. The cycle can be 

broken down into a series of steps as follows: 

 Pre-planning. 

 Extraction of GIS data into a GPS field system. 

 Relocation of features in the field, and verification and update of these features (and 

collection of new features, if required). 

 Return of the updated data to the GIS. 

The length of each data maintenance cycle and the interval between each cycle will depend 

on the requirements of the particular datasets. For example, in relatively static non-safetycritical data, the data may need updating every 6 months to 1 year, while dynamic safetycritical data may require updates daily. All of the data requires explicit verification and 

validation to ensure its correctness and accuracy. Any time a critical PTC system asset is 

subsequently moved for operating or safety reasons, new GPS coordinates must be acquired 

and the data translated into information for PTC purposes. 
29

Figure 10: LIDAR Mapped Rail GIS Data 

2.6 Installation Engineering 

The limited resources available, along with the 2015 deadline have forced the railroads to 

develop and install PTC technology in a less efficient way than would otherwise be the case. 

System design, development, and testing that normally would be undertaken sequentially 

must happen in parallel, which results in more defects in the development process. As a 

result of the limited resources available to the railroads, the substantial resources required for 

planning, designing, and testing PTC components means that fewer resources are available 

for other service and safety technology projects. 

The need to test the PTC back office systems, including the back office servers, and address 

problems identified during the testing process, also impacts the pace of their development. 

Lab testing of the related technologies and systems will generally find some defects, as was 

the case with the initial software release for the back office servers, requiring the railroads to 

wait for a subsequent version of the technology or system that fixes the defects. 

Once the required hardware and software components are available, widespread PTC system 

deployment by the railroads can begin. Deployment requires a number of separate laborintensive activities along the wayside, onboard the locomotives, and in the office. The 

estimated numbers of components affected are listed in Table 8. 

Table 8: Devices Requiring New Installation or Upgrade 

Item Total Number Requiring Upgrade/Installation 

Locomotives 18,000 

Wayside Interface Units 38,000 

Signals Installation/Replacement 12,000 

Signal Modifications 4,900 

Back Office Servers and Dispatch Systems 30 
30

The engineering associated with the installation of a signal system is representative of the 

level of effort required to install components. 

Before any signal system field installations can occur, railroad engineering staff must first 

complete a detailed design for each site. These designs are subsequently provided to the 

railroad construction, signal, and communication crews. To create this design, the 

engineering staff must: 

 Specify exterior wire and cables requirements and installation instructions. 

 Specify bungalow housing site preparation, housing design, and construction 

requirements and provide installation instructions. 

 Specify signal masts site preparation, design, construction requirements, and provide 

installation instructions. 

 Specify track circuit design and installation requirements. 

 Specify signal unit design and installation requirements. 

 Determine and verify vital fail-safe component implementations and interconnection. 

 Specify required controls and indications and provide installation instructions. 

 Specify communication system radios, antennas, and their connections with other 

system components. 

 Specify lightning protection and grounding requirements for all system equipment 

and provide installation requirements. 

 Verify that electrical and electronic design and locations do not create inductive 

interference, determine corrective actions to eliminate inductive interference if 

present, and provide instructions. 

 Specify wiring requirements for internal bungalow equipment and provide installation 

instructions. 

 Specify/design AC power supply system and provide connection/installation 

instructions. 

 Specify/design standby power supply system and provide installation instructions. 

 Specify all installation, integration, and commissioning tests with required records. 

 Specify any instructions and disposition of existing construction or installation debris. 

 Define configuration management requirements. 

 Integrate specific site into subdivision, division, and network implementation plans. 

After the engineering design has been completed it can be released to the installation 

technicians. Once the design has been released, railroad installation technicians must: 
31

 Install and position PTC radio and GPS antennas at wayside locations and base radio 

sites. 

 Perform cable work. 

 Replace or upgrade battery power. 

 Install lightning and surge protection. 

 Replace track circuits where necessary. 

 Replace signals where necessary. 

 Replace bungalows where new ones are required due to PTC equipment size 

constraints. 

 Perform in-service tests as applicable that can include running through every 

available combination of routes to ensure signal indication accuracy. 

 Update configuration management as applicable. 

Figure 11: Control Point with Three Signal Heads 

In order to install PTC systems, the railroads must obtain all the necessary supplies and 

equipment; stage them for use, then carry out the installation instructions. This is 

complicated when all equipment is not available. Staff then must be rescheduled to return to 

the site at a later date when the required material becomes available to complete the 

installation and testing. This design and installation process must be repeated for each of the 

12,000 sites. During the process, current railroad operations are interrupted. 
32

Table 9: Switch Modifications Requirements–Non-Signaled Territory 

Railroad ARR BNSF CN CP CSX KCS NS UP Total 

# non-signaled 

switch 

locations 

needing power 

& WIUs 

# needed 79 1180 232 569 973 153 728 974 4888 

# equipped with 

power to date 4 84 0 11 0 13 39 58 209 

# remaining to be 

equipped with 

power 

75 1096 232 558 973 140 689 897 4660 

# equipped with 

WIUs to date 4 13 0 11 0 0 39 58 125 

#remaining to be 

equipped with 

WIUs 

75 1167 232 558 973 153 689 897 4744 

# non-signaled 

switch 

locations 

needing 

switch 

position 

monitors 

# needed 79 0 232 569 973 153 728 974 3708 

# equipped to date 4 0 0 11 0 0 39 58 112 

# remaining to be 

equipped 75 0 232 558 973 153 689 897 3577 

Table 10: Signal Replacement Projects 

Railroad ARR BNSF CN CP CSX KCS NS UP Total 

# locations of signal 

replacement required 0 3965 116 76 1724 300 1850 4200 12231 

# locations replaced to date 0 532 31 0 160 64 240 200 1227 

# locations remaining to be 

replaced 0 3433 85 76 1564 236 1610 4000 11004 

This “double touch” strategy is not limited to installing signal systems on tracks. Equipping 

locomotives with PTC technology is another example where the “double touch” strategy is 

applied. 

Activities of similar complexity are associated with the other PTC system components. 

Approximately 18,000 locomotives, or 75 percent of the industry’s active road locomotive 

fleet, must be equipped with PTC system technology. Specifically, these locomotives must 

be equipped with: 

 Train Management Computers (TMC) with fully functional PTC system software. 

 Interoperable 220 MHz radios designed specifically for PTC systems. 

 Communications Management Units or Onboard Networks (OBN). 

 Antennae arrays capable of receiving the full range of PTC system data 

transmissions, e.g., via radio, cellular, Wi-Fi, and GPS. 

 An interactive computer display. 
33

Additionally, every TMC must be interfaced with the locomotive’s onboard systems to 

supply the TMC with critical information such as brake pipe pressure, horn status, and speed 

from the axle alternator. 

The wiring, cabling, welding, cutting, and connecting of locomotive components required for 

a PTC system is made complex by the variety of locomotive models. The largest railroads 

have 15 to 20 different models of locomotives on which PTC equipment will need to be 

installed, some of which have been in service for several decades. The age and variety of the 

locomotive fleet contribute significant additional time, complexity, and costs to the effort to 

install PTC equipment on locomotives. A unique PTC design is required for each unique 

locomotive configuration. 

Railroads must take the locomotives out of revenue service to make modifications required 

for the installation of brackets, wiring, and cabling that will support the onboard PTC 

components when they become available. At the same time, the railroads will install any 

components that are available. The railroads will have to re-shop these same locomotives 

(again taking them out of revenue service) to install the remaining onboard PTC components 

once they become available. 

Table 11: Locomotives Equipped with PTC Systems 

Railroad ARR BNSF CN CP CSX KCS NS UP Total 

# to be equipped 54 2000 1,000 1,000 3,600 520 3411 6,532 18,117 

# partially equipped to date 53 376 34 52 808 40 900 360 2623 

# fully equipped 0 0 0 0 0 0 0 0 0 

The development work for PTC system communications will not be finished once radios are 

available for deployment. The 220 MHz data radio network will require significant radio 

frequency planning and coordination to ensure sufficient coverage has been provided without 

interference. It is likely that areas of high PTC system traffic congestion will result in 

complex frequency coordination and necessitate the sharing of railroad communication 

infrastructure. This type of effort has never been undertaken on the scale and timeline 

required to support interoperable PTC systems 

2.7 Reliability and Availability 

In order for an installed PTC system to provide the desired level of safety, as well as to 

minimize any adverse impact on the railroad operations, the PTC system must be reliable and 

available. Reliability represents the probability of components, parts, and subsystems to 

perform their required functions for a desired period of time without failure in specified 

environments with a desired confidence. Reliability, in itself, does not account for any repair 

actions that may take place. It does not reflect how long it will take to get the unit under 

repair back into working condition. 

Availability is defined as the probability that the system is operating properly when it is 

requested for use. In other words, availability is the probability that a system is not failed or 

undergoing a repair action when it needs to be used. Therefore, not only is availability a 
34

function of reliability, but it is also a function of maintainability. Currently, there is no data 

that reflects either the reliability or maintainability of PTC systems to be implemented using 

the I-ETMS architecture. 

The accuracy of the mean down time estimates is usually not resolved until after initial 

operating capability (IOC). If the actual mean down time is excessive, system modifications 

are required to improve it. Because of the current development state of I-ETMS-based PTC 

systems, sufficient deployments to accurately determine the mean down time will not occur 

until 2014 or 2015. Any system modifications to obtain the required mean time between 

failure would require design, implementation, and testing before deployment of the revised 

system components and retrofitting of already deployed system components has occurred. 

This would result in delays in the completion of system deployment until after the December 

31, 2015, deadline. 

Mathematically, reliability is defined by the mean time between failure and in the case of 

safety-critical failures, mean time to hazardous events. Although these two factors are 

conceptually different, the mathematics of both are the same. Even though similar 

mathematical concepts apply to both, the assumption that a more reliable system is safer, and 

vice versa, is not always correct. It is often true that the safer the system, the lesser the 

reliability. 

The system designer evaluates the achievability of the minimum mean time between failure 

and the mean time to hazardous events by analyzing the failure rates or hazardous event rates 

of mature or similar developing technologies. This analysis includes historical trending for 

similar systems and comparing these results to the new technologies. This is problematic 

process in the case of I-ETMS-based systems as there are no closely similar mature 

technologies from which to draw for determining the actual failure rates of the system. 

These factors are usually not resolved until after the IOC. If they are determined to be 

excessive, system modifications are required to improve them. As is the case with the mean 

down time, sufficient deployments to accurately determine the mean time between failure 

and the mean time to hazardous events will not be available until 2014 or 2015. System 

modifications, if required, may delay completion of system deployment until after the 

December 31, 2015, deadline. 

The likelihood of system modifications is high. PTC is a complex and novel technology, 

comprising a number of varied components. Novelty is closely related to the lack of required 

information and knowledge that lead to high uncertainty in the design. The higher the 

uncertainty, the greater the likelihood of changes to the requirements, which in turn can cause 

changes in product components, layouts, interfaces, and architecture. 

The overall complexity of the system also increases the likelihood of system modification. 

As shown in Table 12, if the number of components increases, for any specific individual 

component reliability the system reliability or safety decreases. Higher reliabilities and 

greater levels of safety have to be designed and manufactured into each component of 

complex systems to obtain a specific system reliability or safety. 
35

Table 12: How Complexity Affects System Reliability 

Number of Critical 

Components in 

Series 

Individual Component Reliability 

99.999% 99.99% 99.9% 99% 

Overall System Reliability 

10 99.99% 99.90% 99.00% 90.44% 

100 99.90% 90.01% 90.48% 36.60% 

250 99.75% 97.53% 77.87% 8.11% 

500 99.50% 95.12% 60.64% 0.66% 

1,000 99.01% 90.48% 60.64% <0.1% 

10,000 90.48% 36.79% <0.1% <0.1% 

100,000 36.79% <0.1% <0.1% <0.1% 

3. Critical Programmatic Issues of Concern 

In the process of design, development, and implementation of PTC systems by the freight 

and passenger railroads in the United States, the following are the most prevalent unresolved 

programmatic obstacles impeding progress: 

 Budgeting and Contracting

 Stakeholder Availability 

3.1 Budgeting and Contracting 

With public sector operating budgets in transition and continuing to grow tighter, Federal 

Government entities are increasingly looking to the private sector to provide goods and 

services. Such goods and services are acquired through a public procurement process that 

generally involves the following: 

 The definition of the procurement requirement. 

 An estimated budget. 

 The solicitation of proposals. 

 The final award of a contract based on stated evaluation criteria and performance. 

The government entities seek private sector providers in order to secure better quality goods 

and services at a lower overall cost. However, these objectives cannot generally be met 

unless contracts are awarded on a truly competitive basis under a system that has clear 

guidelines incorporating transparency, efficiency, economy, accountability, and fairness into 

the public procurement system as a whole. Although private entity procurements also seek to 

secure better quality goods and services at a lower overall cost, they are not governed by 

public procurement laws. The objective of public procurement laws are to enable economic 

operators to compete effectively for public contracts. Public procurement law aims at the 

protection of the integrity of the procurement process, the promotion of economic 

decisionmaking by public entities, and the efficiency of public spending. 
36

Private firms place less emphasis on formal competitive bidding, documented procedures, 

and constraining conflicts of interest than governments. Private firms have built-in 

incentives to purchase goods that provide high value for their price, and to hire contractors 

who will accomplish high-quality jobs at competitive prices. The dimensions of 

accountability are related to results, not process, because in the private sector the results are 

quantifiable by reference to their impact on overall company profit. 

In contrast, the public manager must follow prescribed competitive procedures, and the rules 

give a major weight to fairness and equity. Also, public procurement is subject to oversight 

by the legislature and audit (in addition to internal accountability mechanisms). Mistakes or 

malfeasance in public procurement can have vast political repercussions, owing to the focus 

that the media and the public place on the subject. Private firms and nonprofit agencies both 

prefer stable relationships with suppliers and long-term contracts for certainty and easier 

business planning, but several factors (including the fear of collusion with contractors and 

financial rules) prevent public agencies from developing such long-term relationships. 

Finally, public procurement is often used as a tool for public policy goals (e.g., fostering the 

growth of local industry, or benefiting less fortunate disadvantaged groups). 

Public procurements are all similar in that they require: 

 Clear and fair description of what is to be purchased. 

 Publicized opportunity to bid. 

 Fair criteria for selection and decisionmaking. 

 Receipt of bids from responsible suppliers (or contractors). 

 Comparison of bids and determination of the best or most responsive bid, according 

to the predetermined and publicized rules for selection. 

 Contract award. 

Accordingly, the stages in the process of public bidding are: 

 Pre-bid. 

 Public notice and invitation of bids. 

 Bid opening and evaluation. 

 Resolution of complaints. 

 Contract award and conclusion. 

Time must be allowed for potential suppliers to bid, for the purchasing agency to evaluate the 

bids and make the award decision, for the final details of the contract to be negotiated, and 

for the goods and services to be received or the work to begin. The length of time it takes to 

execute public versus private procurements is consequently greater. 
37

Table 13: Components of the Public Acquisition Cycle 

Acquisition plan 

Scope of work 

Data requirements 

Source selection plan 

Acquisition package preparation (including market surveys and obtaining applicable approvals 

and waivers) 

Purchase request (submission and acceptance) 

Justification and approval for other than full and open competition 

Advertising the requirement 

Legal review and approval (as required) 

Issuance of the solicitation 

Evaluation of proposals 

Obtaining audits (as required) 

Pre-award Surveys 

Development of pre-negotiation plan 

Completion of negotiations (Revised Proposal) 

Contract preparation 

Contract review and approval (as required) 

Legal review and approval (as required) 

Contract award 

Notification to unsuccessful offerors 

Debriefings 

Public procurement must also integrate into the public planning, budgeting, and execution 

(PPB&E) process since most public agencies are precluded by law from entering into a 

contract for goods or services without an approved budget and appropriations. The PPB&E 

process is a complex set of activities for most public entities that extends over a 3-year cycle. 

Year 1 consists of program planning, year 2 consists of budget development and approval, 

and year 3 results in budget execution. At any time, an entity has all three activities in 

process. Using the current fiscal year as an example, entities are currently executing their FY 

2012 budget, budgeting the FY 2013, and planning for FY 2014. 

 
38

Figure 12: Planning, Program, Budgeting, and Execution Cycle 

The initial implementation planning for PTC system installation was submitted and approved 

by FRA during FY 2010, and actual budgeting for PTC system installation did not occur until 

FY 2012, with the first year of execution starting in 2013. Although all railroads submitted 

PTCIPs in 2010, not all PTCIP plans for commuter railroads were integrated with PPB&E 

process. As a result, the actual start of system installation for commuter railroads was 

delayed by as much as 3 years exclusive of the award of the PTC acquisition contract (in and 

of itself potentially a 6 to 9 month process after the start of the fiscal year in which funds are 

first available). Some of the slippage can be compensated for by increasing the parallelism 

of the various installation tasks, albeit with increased costs, but not totally recovered under 

the assumption that there would be no additional major technical issues during the 

installation process. Given the complexity of PTC systems, such an assumption is unlikely. 

Also of importance, is the invalidity of a key assumption of the public sector intercity 

passenger and commuter railroads. When the RSIA was passed in 2008, the industry was 

operating under the premise that a new, long-term reauthorization bill would increase Federal 

capital support for commuter rail systems through FTA grants or that additional Federal 

funding would be made available to assist in the implementation of PTC. However, more 

than 3 years later, the majority of FTA grants have been funded through short-term 

extensions of the Safe, Accountable, Flexible, Efficient Transportation Equity Act: A 

Legacy for Users (SAFETEA-LU) (Pub. L. 109-59) and no long-term bill has been enacted. 

This reduces funding certainty and affects the commuter railroads’ ability to implement longterm plans. Additional public funding was fundamental to commuter railroads’ ability to 

achieve the 2015 deadline.27 Coupled with the absence of a long-term funding solution is a 

global recession that continues to impact State and local revenue sources that traditionally 

support the non-Federal share of commuter capital and operating expenses. 

 

27 Testimony of Joseph Giulietti of the South Florida Regional Transportation Authority on behalf of APTA at 

the March 2011 House Transportation and Infrastructure Committee Hearing regarding implementing PTC on 

commuter rail. 
39

Representatives of intercity passenger and commuter railroads have testified before 

Congress28 that the lack of additional public funding and the mandated 2015 completion date 

has placed some intercity passenger and commuter railroads in the situation of choosing 

between performing critical system safety, state of good repair upgrades, such as bridge 

reconstruction or electrical subsystem upgrades, and implementing PTC systems by 2015. 

With a backlog of unfunded good repair projects of approximately $78 billion,29 diversion of 

resources by the intercity passenger and commuter railroads to implement PTC systems is to 

the further detriment of other essential projects. FRA is concerned that such diversion 

decisions could create future large-scale safety or operations problems that present greater 

risks than those that PTC is intended to prevent. 

 

3.2 Stakeholder Capacity 

There are currently 38 freight, intercity passenger, and commuter railroads that are required 

to implement PTC systems. These railroads are all competing for a limited set of resources, 

in terms of both manpower and essential PTC system components. The pool of experienced 

PTC system equipment suppliers is limited. There are only five major suppliers30 who have 

significant prior experience with PTC equipment manufacturers and not all manufacture all 

PTC system equipment. The ability of these manufacturers to provide the required quantities 

of necessary components has yet to be demonstrated. As could be expected with a program 

of this magnitude and complexity, vendor supply chain and quality control issues have arisen 

with respect to both hardware and software. Some equipment suppliers do not have the 

capacity to satisfy overall industry demand in a timely fashion, resulting in delivery delays. 

Given the limitations of vendor production capacities, and the comparatively low intercity 

passenger and commuter railroads needs compared to the freight railroads,31 it is a logical 

assumption that due to their lesser volume, intercity passenger and commuter railroads will 

be last in line for vendor priority. 

Wayside signal systems interface with PTC systems through WIUs installed at each wayside 

signaling location. WIUs translate the signal logic into PTC system information. There are 

currently two types of WIUs under development by railroad signaling suppliers, “integrated” 

and “standalone” configurations. The integrated WIU will be applied to newer, 

microprocessor-based signal systems. Standalone WIUs will be applied to older, nonmicroprocessor-based signal systems (and some older microprocessor-based systems as 

well). Product availability has been a problem as suppliers strive to develop interoperable 

equipment and undertake the safety-critical development and testing required for signaling 

equipment. Furthermore, railroads subject the equipment to extensive lab and field testing. 

Although one supplier has WIUs available, WIUs from other suppliers are not yet ready for 

 

28 Id. 

29 FTA “National State of Good Repair Assessment,” June 2010. 

30 Alstom, Ansaldo, Inversys, General Electric, Wabtec. 

31 The freight railroads estimate PTC system installation on 18,000 locomotives and 60,000 to 70,000 track 

miles. Commuter railroads have in the neighborhood of 4,000 locomotives and passenger cars with control cabs 

and 8,500 track miles which need to be equipped with PTC. Source AAR and APTA. 
40

production in large quantities. The impact of this on the railroads has been telling (Tables 14 

and 15). 

Table 14: Integrated WIU Installation 

Railroad ARR BNSF CN CP CSX KCS NS UP Total 

# integrated WIUs required to 

be deployed 51 6889 1559 423 5029 669 4300 11371 30291 

# integrated WIUs deployed to 

date 0 948 67 23 124 100 126 1778 3166 

# integrated WIUs remaining 

to be deployed 51 5941 1492 400 4905 569 4174 9553 27085 

Table 15: Standalone WIU Installation 

Railroad ARR BNSF CN CP CSX KCS NS UP Total 

# stand-alone WIUs required to 

be deployed 79 1180 462 135 1167 507 1628 2941 8099 

# stand-alone WIUs deployed to 

date 4 13 0 4 0 0 39 58 118 

# stand-alone WIUs remaining 

to be deployed 75 1167 462 131 1167 507 1589 2883 7981 

The PTC system signal projects require a substantial amount of work in a limited period of 

time by the railroads. Historically, railroads are staffed for a fairly stable amount of signal 

work from year to year. The PTC system signal work has increased the workload for railroad 

signal staff, resulting in a significant increase in the number of locations where signal work is 

required. The limited number of qualified signal technicians available to the railroad 

industry constrains the railroad’s ability to complete the design, installation, and testing work 

required for PTC system signal projects. It has also adversely affected projects to increase 

railroad capacity because the same employees are needed to perform both functions. The 

increase in demand for signal technicians combined with the limited number available has 

resulted in a tremendous increase in signal engineering and installation costs. 

Railroad signalmen, the craft most responsible for PTC system installation, have fewer than 

9,500 members nationwide.32 In addition to implementing PTC systems, these persons are 

also working full time to keep currently installed signal and train control systems operational. 

The work is also arduous. PTC system installers are often required to travel 100 percent of 

the time away from home—sometimes, in excess of 300 miles—working either 4 days on 

and 3 days off, or 8 days on and 6 days off. They work outdoors in all types of weather, over 

uneven terrain, and are required to do heavy lifting, climb ladders and poles at heights that 

can exceed 40 feet. All this while working under live rail traffic conditions where both the 

reliability of the existing systems must be maintained at all times, as well as the personal 

safety of all persons involved. 

The industry has already hired more than 2,000 additional signal technicians specifically for 

PTC and is planning to hire hundreds more. It typically takes 18–24 months for an 

 

32 See http://www.unionfacts.com/union/Railroad_Signalmen, accessed January 10, 2012. This does not 

include individuals qualified to perform this work who do not belong to a labor organization. 
41

individual to receive the training and gain the experience necessary to handle the 

complexities of a PTC system. On the Class I railroads alone, approximately 60,000 

engineers and conductors, 6,500 signal employees, and 2,400 dispatchers will have to be 

trained on PTC systems. This number does not include the mechanics, electricians, and 

supervisors who will also require training. 

Table 16: PTC Installer Hires 

Railroad Number of Hires 

ARR 4 

BNSF 820 

CN 31 

CP 25 

CSX 450 

KCS 26 

NS 300 

UP 383 

Total 2039 

The pace of development of the back office servers and PTC-related back office systems is 

also affected by available resources. Railroad-specific back office technology is developed 

by a small number of companies not previously equipped to support the larger demand 

resulting from PTC system implementation. There are also a limited number of technology 

professionals who have intimate knowledge of railroad operations. The limited resources 

available affect the timing of work on design, development, coding, integration, and testing. 

The details and scope of the back office development required for PTC systems differ for 

each railroad because their information technology systems are unique, minimizing the 

ability to apply the work done for one railroad to another railroad’s PTC system. 

The shortage of qualified people also extends to FRA. FRA’s PTC staff consists of 10 PTC 

specialists and 1 supervisor who are responsible for monitoring all PTC system installation 

and test work nationwide and for the technical review and approval of all documentation 

associated with the statutorily required PTC system certification. This documentation 

includes all the development plans, the safety plans, and any requests for relief by the 

railroads from compliance with Federal rail safety regulations. Although FRA can be 

augmented with a small number of PTC system qualified FRA signal specialists and 

engineers, doing so requires diversion of the latter from their current safety assignments. 

FRA test monitors must travel to ensure that the PTC systems operate with the intended 

functionality. FRA is concerned that funding reductions could hinder the agency’s ability to 

support the railroad’s attempt to meet the mandated deadline. 

A railroad’s request for FRA review, approval, and PTC system certification will require an 

estimated 6 to 9 months. The complexity and size of the railroad-specific safety plans to 

support the certification request is immense. The safety plan associated with ETMS for 

example, a simpler predecessor system to the proposed I-ETMS system, contained more than 

6,000 pages of highly technical information. FRA will receive 38 safety plans from the 

railroads with some of equal or larger size. If received simultaneously, FRA staffing will not 
42

be able to process them concurrently. A best case scenario for the review process for a single 

plan would be 6 to 9 months. Although the railroads are working with FRA to precoordinate these document reviews, this remains a new process with a scope not attempted 

previously for all participants—freight railroads, intercity passenger railroads, commuter 

railroads, and FRA. 

FRA approval of the PTC Development Plans (PTCDP), a significantly simpler document, 

took nearly 18 months. The PTC Safety Plans (PTCSP) will be more complex and 

voluminous than the PTCDPs. The FRA review may result in changes in the PTCSPs as a 

result of design, hardware, or software changes in response to issues that would prevent 

certification, making timely approval problematic. The potential result could be delays in 

some certifications and the ability of the affected railroads to use deployed PTC systems. 

Although FRA support of the various railroads often provides a window into a railroad’s 

progress, it by no means presents a complete picture of what is happening with a program or 

project. FRA support is usually requested when there are issues impeding progress. In 

situations where no FRA support is requested, FRA has only anecdotal evidence of progress, 

or lack thereof. 

For regular, detailed, and unfiltered reporting on a railroad’s progress with PTC system 

implementation, it would be necessary to embed a dedicated FRA PTC-qualified inspector 

into each railroad’s development and deployment team on a fulltime basis. With the 

complexity of PTC systems, multiple inspectors may be required. Currently, FRA has 

neither the staffing, nor the funding, to support such a level of effort. To accomplish this 

would require further increasing the number of government specialists dedicated to PTC by a 

factor of four, with an associated increase in travel and salary costs, as well introducing a 

high degree of Federal intrusion on railroad and vendor autonomy. 

FRA could monitor progress by requiring railroads to submit regular periodic reports to FRA, 

with FRA PTC specialists randomly auditing the submitting railroads to evaluate the 

accuracy of what was reported. Even though this would not require as large a force of 

inspectors (and could be done by existing man power), the complexity of the PTC systems, 

the number of railroads involved, the need to support the test efforts for integration and PTC 

system certification as well as conducting audits, and potential reductions in travel funding 

may also make executing this solution problematic on an annual basis. Requiring regular 

reporting from the railroads and their suppliers would also increase the Federal paperwork 

burdens on railroads. Adding new reporting requirements is contrary to the current 

administration goals of reducing Federal regulatory and reporting burdens. This audit 

approach may be untenable. At current funding levels, FRA has sufficient travel funding to 

support travel for each member of the current PTC test monitoring force for approximately 8 

to 10 weeks of travel annually to cover all aspects of PTC system development and 

certification across the United States. 

 
43

4. Complexity-Safety Risk Prioritized Deployment 

A PTC system is a system of systems. The development of these components requires 

hundreds of subject matter experts to create and document component requirements, develop 

the components, and then test them. At every juncture of the process, integration issues must 

be analyzed and potential or actual defects or risks mitigated. That must be done by the 

railroads. Although suppliers undertake the development of PTC system components, it is up 

to the railroad to integrate the components with each other and with the railroad’s existing 

technology systems. From a timing perspective, PTC system components will not be ready 

until the suppliers are finished with their testing and the railroads complete their integration 

testing. Intercity passenger and commuter railroads face the same challenges as freight 

railroads in integration and testing, amplified by the fact that moving people presents an 

immediate potential risk to the riding public. All of these activities must be planned, 

schedules developed, and modified based on experience gained the development, 

implementation, test, and deployment. 

In an abstract view, PTC systems comprise more than 20 subsystems, including the: 

 Back office servers. 

 Train management computer. 

 I-ETMS software. 

 Authentication systems to verify users. 

 Track database of more than 200 characteristics of track and trackside assets. 

 Interface and enhancements to the dispatch system. 

 Security application for message integrity. 

 Interoperable train control messaging system. 

 220 MHz data radio for base station communication. 

 220 MHz data radio for locomotive communication. 

 220 MHz data radio for switch and signal communication. 

 Communication switching network for interoperable back office communication. 

 Computer display units for onboard the locomotive. 

 Locomotive messaging system to route messages off the locomotive. 

 GPS sensors onboard the locomotive. 

 Crash hardened memory module onboard the locomotive. 

 Onboard network devices for communications. 

 Switch position monitors. 

 Integrated and stand-alone WIUs. 
44

Notional schedules have been developed by each of the railroads and their vendors for these 

subsystems, and the technical issues previously identified are impacting all of these in some 

manner. When combined with the lack of previous experience in this endeavor, the 

schedules developed by the railroads and vendors are often unrealistically optimistic. The 

variety of suppliers, the timing of development of the individual components, the 

interpretation of designs and standards, the enhancement of legacy systems, the dependencies 

between modules, and interfaces all add complexity, risk, and time to the implementation of 

PTC systems. 

Although some of these individual components existed in some form prior to the mandate for 

PTC systems, none of the preexisting components were specifically designed to work in 

concert with all other components in this system of systems. Furthermore, many of these 

components are first-generation technologies being conceived, designed, and developed for 

PTC systems. All of these components must function correctly and reliably, or the entire 

PTC system will fail. In the case of the first-generation technologies, the likelihood of 

problems arising is higher than with proven system components. 

Multiple phases of testing must take place before PTC systems are ready to be put through 

the rigors of real operations. Simulators have been developed to create mock operational 

environments for testing. Each system component is connected to other components for 

integration testing. The process is iterative, with components being added to the test until the 

entire system is assembled in the lab environment to verify system functionality. 

At any point during testing, defects in the components or their interface with other 

components can be revealed. When that occurs, research must be conducted to determine the 

cause, the software or hardware must be modified, and new testing must take place. Each 

defect potentially impacts the schedule for implementing a PTC system, depending on the 

functionality and complexity of the issue. Defects found during field testing can be 

problematic and cause significant delays. Defects place all of the previous work done on 

individual components and their integration in jeopardy. 

Scheduled risks associated with implementation of a PTC system in operationally complex 

and highly trafficked areas, such as Chicago and on the NEC, are high.33 These installations, 

which are representative of high-risk installations required to be completed first under the 

RSIA, are potentially more difficult and present a greater risk of problems arising than in 

other areas. Furthermore, deploying a PTC system in such a manner runs counter to 

deployment strategies executed in most unproven technology development programs. In 

these programs, the technology is best introduced in less operationally complex areas first, 

which would have the lowest adverse impact in the event of issues with the technology. 

Currently, approved implementation plans provide for phasing in PTC systems first in 

geographic areas of greater risk, meaning PTC systems will be installed initially in complex 

 

33 Many other commuter railroads, such as Southern California Regional Rail Authority (SCRRA), do not have 

the level of traffic that is experienced in the Chicago metropolitan area or the NEC, and do not present the same 

level of complexity. SCRRA also benefited by diversion of BNSF and UP PTC assets from BNSF and UP own 

deployment efforts to support SCRRA deployment efforts. 
45

regions. However, by not considering non-safety-related issues in the installation planning 

process, using PTC systems first in operationally complex areas would increase the 

likelihood and severity of rail traffic disruptions. 

Besides impacting critical freight transportation, such disruptions can also impact PTC 

systems commissioning schedules in other lower complexity areas. These issues present 

challenges to PTC system implementation and require that all risk associated with PTC 

system implementation be taken into account in order to implement PTC systems in a 

practical manner. In order to implement a PTC system in more complex areas before it has 

been successfully implemented in less complex areas would be counterproductive from a 

safety and operational risk perspective. In order to reduce the potential disruption of the 

Nation’s rail traffic flow when PTC systems are implemented across the country, while 

reducing safety risks as low as reasonable practical during the process, FRA now allows 

railroads to commission PTC systems in a phased manner, not only based on safety risks, but 

based on installation complexity. Commissioning an interoperable PTC system refers to 

putting the completely tested system into full revenue service operation in a terminal area or 

route, with multiple railroads operating in the area and across railroad boundaries. 

Progressive cutovers will be done by location. It is more effective to move from the less 

complex first to the more complex, as the less complex will require less coordination, 

provide experience how to verify interoperability, and ultimately provide more territories 

with interoperations sooner than addressing the more complex dense areas as a higher 

priority. The criteria for determining when it may be appropriate to move on to the next 

phase of commissioning depends on readiness of the technology for operation in a more 

complex environment. 

One of the key operating objectives is to ensure that the commissioning of a PTC system in a 

terminal area where interoperability is required occurs on all railroads in the same timeframe 

so that trains do not have to operate in and out of pockets of PTC. This requires coordination 

of system implementation and of system testing among all railroads involved in a terminal 

area or route where such interoperability is required—the more railroads that are involved, 

the greater the coordination effort that will be required. 

In more complex terminal areas involving more railroads, there will likely be additional 

training addressing aspects of the more complex operation, e.g., crew training on multiple 

territories. As cutovers cannot occur before all operating technicians have received training, 

there will need to be significant coordination to ensure that training is completed by a 

projected cutover date. In addition, coordination will be required to limit the amount of time 

elapsed between training and live use. Additional considerations in the implementation 

planning are the availability of labor resources to deploy the PTC system equipment, labor 

agreement constraints, and risks of delays due to weather. 

This process is consistent with the statutory and regulatory mandates that PTC systems be 

implemented in areas of greater risk before areas of lesser risk. The methodology for 

implementing the phased implementation of safety and operational risk expands on the risk 

evaluation methodology used for safety risk prioritization previously submitted in the 
46

railroads’ PTCIPs. Since railroads have already submitted PTCIPs with specific safety riskbased implementation plans, revised or amended PTCIPs would need to be prepared and 

submitted to FRA for railroads electing to include operational complexity as an evaluation 

criterion. The revised PTCIPs would need to describe the new complexity-based 

implementation and commissioning plan incorporating complexity into the assessment of 

risk. 

Figure 13: Integrated Safety Risk and Complexity Strategy 

Low Complexity

Group

Medium

Complexity

Group

High Complexity

Group

Relative Risk

Order of Installation
47

A graphical representation of an integrated safety risk and complexity implementation 

strategy is illustrated in Figure 13. The X axis represents both the “Complexity for an 

Interoperable Terminal Area or Route” of the line segments on which the PTC system is 

being deployed and the order of installation. The Y axis represents the relative level of 

safety risk for an individual line segment. Each railroad, based on its individual particular 

network, would group their routes into a number of sets based on “Complexity for an 

Interoperable Terminal Area or Route.” In this example, there are 11 rail line segments of 

varying levels of risk relative to each other that are divided into three sets, representing low, 

medium, and high complexity. Within each set, installation order of PTC on a line segment 

is determined by relative levels of safety risk, with PTC system installation being done from 

line segments with highest risk to safety risk lowest risk. For this example, the order of 

installation of line segments is given by Table 17.

Table 17: Order of Installation 

Segment

Installation

Order

Line Segment

Number

1 10

2 1

3 8

4 11

5 2

6 3

7 7

8 5

9 6

10 9

11 4

5. Legislative Considerations 

In view of the issues that have been identified, FRA identified three items for consideration 

in the event the Congress elects to make legislative changes to the RSIA. 

5.1 Consideration 1 

An upper boundary has not been placed on the allowable extensions. In the case of the 

design, development, testing, and deployment of PTC systems, the overarching controlling 

factors are schedule, manning, component availability, and cost. The significant technical 

and programmatic issues encountered by freight and passenger railroads justify an extension 

of the full RSIA-required implementation deadline for PTC systems. An extension in 

allowable schedule time for a task results in decreases in costs of completion and/or the 

manning required. Similarly, a decrease in allowable schedule time, results in increases in 

costs and/or manpower. Increases to manpower in complex software design and 

developments (particularly late in the project) can result in the project taking more, not less, 

time. 
48

FRA recommends that if Congress were to consider legislation allowing FRA to approve the 

extension for completion of PTC system installation on specified line segments, the 

legislation ensures: 

 Full PTC implementation is not feasible by December 31, 2015, due to one or more 

circumstances beyond the control of the entity. 

 The entity has demonstrated due diligence in its efforts to achieve the December 31, 

2015, mandate, and has gained substantial progress in deploying PTC to the extent 

feasible to date. 

 The entity has taken all actions available in order to mitigate identified obstacles to 

successful implementation. 

 The entity’s revised implementation plan, presented as a request for amendment as 

part of its implementation extension application, proposes to accomplish PTC system 

implementation in a risk-based priority manner acceptable to FRA and to implement 

the planned PTC system as soon as feasible. 

 

 Flexibility for FRA to assign new completion dates based on the duration required to 

resolve the obstacles to completion. 

This suggestion is based on the assumption that the societal objective is to establish levels of 

risk that are as low as reasonably possible (ALARP).34 For a risk to be ALARP, it must be 

possible to demonstrate that the cost involved in reducing the risk further would be 

disproportionate to the benefit gained. The ALARP principle arises from the fact that infinite 

time, effort, and money could be spent on the attempt of reducing a risk to zero. It should not 

be understood as a quantitative measure of benefit against detriment. It is rather a best 

common practice of judgment of the balance of risk and benefit. 

5.2 Consideration 2 

Consistent with a PTC system implementation deadline extension, the development and 

implementation of any specific alternative technology in lieu of a PTC system can advance 

the ALARP principle of balancing risks and benefits. In the case of maximizing rail safety, 

the ALARP principle leads to the conclusion that alternative methods of implementing rail 

safety than PTC should be considered and, if appropriate, allowed. 

FRA recommends Congress consider legislation that allows FRA to approve the use of 

alternative risk mitigation technologies in lieu of a PTC system on specified line segments if: 

 The use of the alternative technologies will not result in a decrease in the level of 

safety from that which currently exists. 

 

34 A detailed discussion of ALARP may be found in Health and Safety Executive, “Reducing Risks, Protecting 

People: HSE’s decision-making Process.” Her Majesty’s Stationary Office, Norwich UK, 2001 ISBN 0 7176 

2151 0y. 
49

 The alternative technologies proposed provide an appropriate level of risk mitigation 

with regards to preventing train-to-train collisions, overspeed derailments, protection 

of roadway workers within their authorized work zones, and movement of a train 

through misaligned switches. 

 The alternative risk mitigation technology implementation plan, submitted as part of a 

petition to substitute alternative risk mitigation technologies for a PTC system, 

implements the alternative risk mitigation technologies in order from areas of least 

risk to areas of greater risk. 

 The alternative technologies are installed as soon as feasible. 

Any allowance for the use of alternative technologies should also allow FRA to impose 

appropriate implementation deadlines and extensions to those deadlines. 

5.3 Consideration 3 

The third consideration reflects good engineering practice across a wide range of complex 

systems, and has been well documented35 as a risk mitigation strategy. 

Certification is a formal assertion that FRA has determined that a PTC system meets the 

requirements of 9 U.S.C. § 20157(h) with respect to the requirements of Title 49 Code of 

Federal Regulations (CFR) Part 236. 

(h) CERTIFICATION.—The Secretary shall not permit the installation of any positive 

train control system or component in revenue service unless the Secretary has 

certified that any such system or component has been approved through the approval 

process set forth in part 236 of title 49, Code of Federal Regulations, and complies 

with the requirements of that part. 

In order to obtain certification, railroads must successfully complete the requirements 

enumerated in 49 CFR Part 236, Subpart I. FRA recommends that if Congress were to 

consider legislation that allows FRA to approve provisional approval for the use of any PTC 

system, the legislation ensures only provisional approval to install, and operate with 

conditions, any PTC system pending full certification. This will allow a railroad to apply to 

FRA for provisional (initial) certification during the time it is working towards full 

certification. During this time a railroad may operate a PTC system pending final 

submission, review, and approval of the railroad’s safety plan by FRA. A railroad must 

provide documentation satisfactory to FRA giving factual evidence demonstrating 

satisfactory PTC system safety performance and the railroads operational competency for 

system use. A provisionally certified system has had its application accepted by FRA, and 

the full safety case of the system is under review. 

The purpose of the provisional approval would be to use, evaluate, and further develop data 

supporting the safety of a PTC system. This would allow the railroad a realistic amount of 

 

35 Lawrence Livermore National Labs “Risk Management Techniques and Practice Workshop 

Report=December 2008” LLNL-TR-409240. 
50

time to complete the PTCSP and FRA to fully analyze it. During this evaluation period, the 

railroads and the public have the benefit of the systems, and FRA can review and evaluate all 

aspects of safety related to the system. A provisional approval would be valid unless the 

system ceases to operate in a safe manner determined by FRA. 

6. Conclusion 

Based on the findings gathered as a result of this report, FRA believes that the majority of 

railroads will not be able to complete PTC implementation by the 2015 deadline. Partial 

deployment can likely be achieved; however, the extent of which is dependent upon the 

successful resolution of known issues and any emergent issues. As a result, FRA 

recommends that if Congress were to consider legislation extending the PTC implementation 

deadline it should consider several factors, including the extent to which each railroad has 

demonstrated due diligence in its efforts to successfully implement PTC technologies on its 

rail system. 

 

In the event Congress were to make legislative changes, FRA also recommends allowing for 

the provisional certification of PTC systems under controlled conditions before final system 

certification is complete. This will allow for the incremental use of PTC systems and 

produce an increase in safety as the systems are systematically rolled out. FRA suggests that 

any revisions to a railroad’s PTC implementation plan be subject to FRA approval with 

sufficient time for FRA to review and significant FRA oversight. 

Finally, were Congress to make legislative changes, FRA recommends Congress consider 

allowing FRA to approve a railroad to use alternative safety technologies on specified line 

segments in lieu of PTC, particularly in areas with lower safety risks, if appropriately and 

properly justified to FRA.