Vital Positive Train Control (VPTC) 

Dispatch Office

GPS

Wayside 

Interface

Device

(at Switches 

& Signals)

Server

(Central or

Distributed)

Networ

k

Onboard Equipment

Voice & Data Radios

Management

Information

System

High-Resolution Self-Positioning, Displays & Computers On Board 

Govern Train Movements & Speed iaw Limits Received from Off Board

No Track-Based

Positioning

Components

U.S. Department of 

Transportation

Federal Railroad 

Administration

Vital Positive Train Control Research and 

Development—Final Report

Office of Railroad

Policy and Development

Washington, DC 20590

DOT/FRA/ORD-11/14 Final Report

July 2011
NOTICE

This document is disseminated under the sponsorship of the 

Department of Transportation in the interest of information 

exchange. The United States Government assumes no liability for 

its contents or use thereof. Any opinions, findings and 

conclusions, or recommendations expressed in this material do not 

necessarily reflect the views or policies of the United States 

Government, nor does mention of trade names, commercial 

products, or organizations imply endorsement by the United States 

Government. The United States Government assumes no liability 

for the content or use of the material contained in this document.

NOTICE

The United States Government does not endorse products or 

manufacturers. Trade or manufacturers’ names appear herein 

solely because they are considered essential to the objective of this 

report.
i

REPORT DOCUMENTATION PAGE Form Approved

OMB No. 0704-0188

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503.

1. AGENCY USE ONLY (Leave blank) 2. REPORT DATE

July 2011

3. REPORT TYPE AND DATES COVERED

Final Report

4. TITLE AND SUBTITLE

Vital Positive Train Control Research and Development – Final Report

5. FUNDING NUMBERS

FR-RRD-0002-10-01-00

6. AUTHOR(S)

Richard Morgan, Dave Mauger, and Joseph Brosseau

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

Transportation Technology Center, Inc.

55500 DOT Road

Pueblo, CO 81001

8. PERFORMING ORGANIZATION 

REPORT NUMBER

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

U.S. Department of Transportation 

Federal Railroad Administration

Office of Railroad Policy and Development

Washington, DC 20590

10. SPONSORING/MONITORING

AGENCY REPORT NUMBER

DOT/FRA/ORD-11/14

11. SUPPLEMENTARY NOTES

Program Manager: Terry Tse

12a. DISTRIBUTION/AVAILABILITY STATEMENT

This document is available to the public through the FRA Web site at http://www.fra.dot.gov.

12b. DISTRIBUTION CODE

13. ABSTRACT

The Transportation Technology Center, Inc. (TTCI), in cooperation with, the Federal Railroad Administration (FRA), the 

Railroad Research Foundation (RRF), and the Mission Systems and Sensors (MS2) Division of the Lockheed Martin 

Corporation (LMC) conducted research and development (R&D) activities for a safety-critical, communications-based train 

control (CBTC) system. The system R&D was performed under the Vital Positive Train Control (V-PTC) project, and the 

goal of the project was to field test a fully functional vital PTC system that could be used in revenue service operations. 

Jointly, TTCI and LMC accomplished activities related to active field testing of the V-PTC system using the track and related 

facilities at TTC. Test results show significant development success.

14. SUBJECT TERMS 15. NUMBER OF PAGES

77

16. PRICE CODE

17. SECURITY CLASSIFICATION

OF REPORT

Unclassified

18. SECURITY CLASSIFICATION

OF THIS PAGE

Unclassified

19. SECURITY CLASSIFICATION

OF ABSTRACT

Unclassified

20. LIMITATION OF ABSTRACT

NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89)

Prescribed by ANSI Std. 239-18

298-102
ii

METRIC/ENGLISH CONVERSION FACTORS

ENGLISH TO METRIC METRIC TO ENGLISH

LENGTH (APPROXIMATE) LENGTH (APPROXIMATE)

1 inch (in) = 2.5 centimeters (cm) 1 millimeter (mm) = 0.04 inch (in)

1 foot (ft) = 30 centimeters (cm) 1 centimeter (cm) = 0.4 inch (in)

1 yard (yd) = 0.9 meter (m) 1 meter (m) = 3.3 feet (ft)

1 mile (mi) = 1.6 kilometers (km) 1 meter (m) = 1.1 yards (yd)

1 kilometer (km) = 0.6 mile (mi)

AREA (APPROXIMATE) AREA (APPROXIMATE)

1 square inch (sq in, in2) = 6.5 square centimeters (cm2) 1 square centimeter (cm2) = 0.16 square inch (sq in, in2)

1 square foot (sq ft, ft2) = 0.09 square meter (m2) 1 square meter (m2) = 1.2 square yards (sq yd, yd2)

1 square yard (sq yd, yd2) = 0.8 square meter (m2) 1 square kilometer (km2) = 0.4 square mile (sq mi, mi2)

1 square mile (sq mi, mi2) = 2.6 square kilometers (km2) 10,000 square meters (m2) = 1 hectare (ha) = 2.5 acres

1 acre = 0.4 hectare (he) = 4,000 square meters (m2)

MASS - WEIGHT (APPROXIMATE) MASS - WEIGHT (APPROXIMATE)

1 ounce (oz) = 28 grams (gm) 1 gram (gm) = 0.036 ounce (oz)

1 pound (lb) = 0.45 kilogram (kg) 1 kilogram (kg) = 2.2 pounds (lb)

1 short ton = 2,000 pounds 

(lb)

= 0.9 tonne (t) 1 tonne (t) =

=

1,000 kilograms (kg)

1.1 short tons

VOLUME (APPROXIMATE) VOLUME (APPROXIMATE)

1 teaspoon (tsp) = 5 milliliters (ml) 1 milliliter (ml) = 0.03 fluid ounce (fl oz)

1 tablespoon (tbsp) = 15 milliliters (ml) 1 liter (l) = 2.1 pints (pt)

1 fluid ounce (fl oz) = 30 milliliters (ml) 1 liter (l) = 1.06 quarts (qt)

1 cup (c) = 0.24 liter (l) 1 liter (l) = 0.26 gallon (gal)

1 pint (pt) = 0.47 liter (l)

1 quart (qt) = 0.96 liter (l)

1 gallon (gal) = 3.8 liters (l)

1 cubic foot (cu ft, ft3) = 0.03 cubic meter (m3) 1 cubic meter (m3) = 36 cubic feet (cu ft, ft3)

1 cubic yard (cu yd, yd3) = 0.76 cubic meter (m3) 1 cubic meter (m3) = 1.3 cubic yards (cu yd, yd3)

TEMPERATURE (EXACT) TEMPERATURE (EXACT)

[(x-32)(5/9)] °F = y °C [(9/5) y + 32] °C = x °F

QUICK INCH - CENTIMETER LENGTH CONVERSION

0 1 2 3 4 5

Inches

Centimeters 0 1 2 3 4 5 6 7 8 9 10 11 12 13

QUICK FAHRENHEIT - CELSIUS TEMPERATURE CONVERSIO

 -40° -22° -4° 14° 32° 50° 68° 86° 104° 122° 140° 158° 176° 194° 212°

 

°F

 °C -40° -30° -20° -10° 0° 10° 20° 30° 40° 50° 60° 70° 80° 90° 100°

For more exact and or other conversion factors, see NIST Miscellaneous Publication 286, Units of Weights and Measures.

Price $2.50 SD Catalog No. C13 10286 Updated 6/17/98
iii

Contents

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

1 Introduction............................................................................................................................... 4

1.1 Background...................................................................................................................... 4

1.2 Objectives ........................................................................................................................ 5

1.3 Overall Approach............................................................................................................. 5

1.4 Scope................................................................................................................................ 5

1.5 Organization of the report................................................................................................ 6

2 V–PTC System Description................................................................................................... 7

2.1 V–PTC System Architecture............................................................................................ 7

2.2 V–PTC Server.................................................................................................................. 8

2.3 V–PTC Onboard .............................................................................................................. 8

2.4 Communication.............................................................................................................. 12

3 V–PTC System Development.............................................................................................. 13

3.1 Build 1—Train Location Monitoring............................................................................. 13

3.2 Build 2—Server Switch Monitoring.............................................................................. 14

3.3 Build 3—Switch Warnings and Control........................................................................ 14

3.4 Build 4—Onboard Display of Authority ....................................................................... 14

3.5 Builds 5–8—Reactive Enforcement of Speed and Authority Limits............................. 15

4 Enforcement Braking Algorithm Evaluation....................................................................... 17

5 TTC’s PTC Test Bed ........................................................................................................... 22

5.1 PTC Test Bed Overview................................................................................................ 22

5.2 PTC Test Bed Elements................................................................................................. 23

5.3 PTC Test Bed Architecture............................................................................................ 32

5.4 2009 PTC Test Bed Upgrades........................................................................................ 33

5.5 PTC Test Bed Upgrades Documentation....................................................................... 35

6 V–PTC System Testing and Results.................................................................................... 36

6.1 Build 1 Testing—Train Location Monitoring................................................................ 36

6.2 Build 1 Test Results....................................................................................................... 38

6.3 Build 2 Testing – Server Switch Monitoring................................................................. 46

6.4 Build 2 Test Results....................................................................................................... 47

6.5 Build 3 Testing – Switch Warnings and Control........................................................... 49

6.6 Build 3 Test Results....................................................................................................... 50

6.7 Build 4 Testing–Onboard Display of Authority ............................................................ 52

6.8 Builds 5–8 Testing – Reactive Enforcement of Speed and Authority Limits................ 60

6.9 Builds 5–8 Test Results ................................................................................................. 61

7 Summary and Conclusions .................................................................................................. 67

8 References............................................................................................................................ 68

Abbreviations and Acronyms ....................................................................................................... 69
iv

Illustrations

Figure 1. V–PTC System Interaction............................................................................................. 7

Figure 2. V–PTC System Architecture .......................................................................................... 8

Figure 3. Physical Interaction Diagram ......................................................................................... 9

Figure 4. Locomotive State Diagram........................................................................................... 11

Figure 5. V–PTC System Build Cycle Overview........................................................................ 13

Figure 6. Braking Distances for Slow Speed Operations ............................................................ 19

Figure 7. Braking Distances for Sthort Train Operation.............................................................. 20

Figure 8. Braking Distances for Steep Decline Operation........................................................... 20

Figure 9. Track and RF Commications Infrastructure ................................................................. 25

Figure 10. Backhaul and Data Network Overview...................................................................... 26

Figure 11. Radio Laboratory at TTC ........................................................................................... 27

Figure 12. TTCI’s Overall Simulation Process............................................................................ 31

Figure 13. PTC Test Bed Architecture ........................................................................................ 33

Figure 14. Siding Turnout Positions............................................................................................ 34

Figure 15. 602 Bungalow at RTT Siding Turnout....................................................................... 34

Figure 16. Areas of Induced GPS Gaps on RTT ......................................................................... 37

Figure 17. Soap Applied on Top of Rails.................................................................................... 38

Figure 18. Position Location Errors–Full GPS............................................................................ 39

Figure 19. Location Errors—Inhibited GPS ................................................................................ 40

Figure 20. Locomotive Speed Errors—Full GPS ........................................................................ 41

Figure 21. Locomotive Speed Errors—Inhibited GPS ................................................................ 42

Figure 22. Direction and Movement Errors with GPS ................................................................ 43

Figure 23. Slide Testing Results.................................................................................................. 45

Figure 24. Wheel Rate during Slip Testing ................................................................................. 46

Figure 25. TTCI Communications Network................................................................................ 49

Figure 26. Build 3 Testing on Locomotive 2001......................................................................... 50

Figure 27. Graphic of LDU Display on Locomotive 2001.......................................................... 50

Figure 28. Test Setup for Builds 5–8 Testing.............................................................................. 61
v

Tables

Table 1. Build 2 Tests and Results............................................................................................... 48

Table 2. Overview Summary of Build 3 Test Results................................................................. 51

Table 3. Build 3 Tests and Results............................................................................................... 51

Table 4. Summary of Requirements Results................................................................................ 52

Table 5. Summary of Executed Test Steps.................................................................................. 53

Table 6. Detailed Build 4A Test Results ..................................................................................... 54

Table 7. Build 4B Test Case Results ........................................................................................... 57

Table 8. Builds 5–8 Test Case Results......................................................................................... 63
1

Executive Summary

The Transportation Technology Center, Inc. (TTCI), in cooperation with the Federal Railroad 

Administration (FRA), the Railroad Research Foundation (RRF), and the Mission Systems and 

Sensors (MS2) Division of Lockheed Martin Corporation (LMC), conducted research and 

development (R&D) activities for a safety-critical, communications-based train control (CBTC) 

system. 

The new system, functionally a second generation positive train control (PTC) system, is 

designed to use an office-centric architecture based on current and evolving industry PTC 

communications technologies. R&D was performed under the Vital Positive Train Control (V–

PTC) project.

Building on the work of the North American Joint Positive Train Control (NAJPTC) program, 

the V–PTC project was responsible for developing, building, and testing, a revenue-serviceready, V–PTC system at the Transportation Technology Center (TTC) facility, and 

demonstrating the system on a revenue service route. It was envisioned that V–PTC, as a PTC 

system, would provide public benefits by reducing risk to railroad passengers and employees, as 

well as potentially improving the efficiency of the national railroad network.

The scope of this project included Project Office, Systems Engineer, System Development 

Integrator and development test support activities. TTCI, as the Project Office, coordinated with 

LMC, as the System Development Integrator, to manage the project, with input from the V–PTC

technical advisory group and FRA. In its role as Systems Engineer, TTCI provided system 

engineering activities for developing documentation, performing analysis, and completing system 

specifications. LMC as the System Development Integrator developed and provided the necessary 

system hardware and software, and it coordinated with TTCI to install system components at TTC for 

testing. 

Jointly, TTCI and LMC undertook activities, meetings, and conferences related to the development of 

the V–PTC system. These activities included active field testing of the V–PTC system using the 

track and PTC communications and control infrastructure at TTC’s facility. Initially, the project 

was designed to include system testing on a revenue service route of a participating AAR member 

railroad, but as the project unfolded, the member railroad elected to use an alternative interoperable 

PTC system, and the revenue service testing phase was deleted from the project.

The project focused on developing V–PTC locomotive and office PTC segments. These 

segments were then integrated with a commercially available computer aided dispatch (CAD) 

system located at TTC, providing one of the earliest integrated PTC CAD/back office server 

(BOS) combinations in the industry. The locomotive and office segments were also integrated 

with TTC’s wayside segment components, including track infrastructure, wayside signal 

systems, radio frequency (RF) communications network, and a track database for the Railroad 

Test Track (RTT). The V–PTC system was designed to meet the key requirements of a PTC 

system as defined in the Rail Safety Improvement Act of 2008 (RSIA ’08). 

In compliance with V–PTC technical advisory group and FRA guidance, the project was 

implemented using an approach based on providing demonstrated incremental progress during 

the system development cycle. V–PTC functionality development and related testing were 

distributed throughout five groups of demonstrated and deployable capability. 
2

• Build 1 (Train Location Monitoring) was designed to determine the accurate location and 

speed of a train without the aid of track circuits and to report these data to the V–PTC

Server. 

• Build 2 (Server Switch Monitoring) was designed to (1) develop the V–PTC capability to 

monitor and report the alignment of both powered and hand-operated switches, (2) 

monitor and report the status of associated On-Station track circuits, and (3) ensure that 

all of these conditions are reported to the V–PTC Server. 

• Build 3 (Switch Warnings and Control ) was intended to (1) ensure that all of the data in 

the previous builds, including switch point position, are transmitted to the onboard 

display of the locomotive and (2) that the data can be seen and evaluated by the engineer 

(driver) in the cab of the locomotive. 

• Build 4 (Onboard Display of Authority) was intended to (1) verify the capability to 

remotely control alignments of monitored and powered switches by a dispatcher using the 

CAD/BOS interface, (2) transmit the information monitored in Builds 1 and 2 from the 

V–PTC BOS to the CAD system using the interface, and (3) display all authorities 

entered by the dispatcher to the engineer in the cab of the locomotive. 

• Builds 5–8 (Reactive Enforcement of Speed and Authority Limits) encompassed system 

capabilities associated with movement authorities and related functionalities. 

The builds were developed as a coordinated group and then tested in a single on-track test period 

in November and December 2009. After completing development activities for Builds 5–8, the 

project plan was to continue incremental system development until the system had full virtual 

block functionality. However, because of 2010 funding circumstances, the project emphasis 

shifted to developing and demonstrating the LMC implementation of the TTCI-developed PTC 

enforcement braking algorithm (EBA) and to revising the System Requirements Specification

(SRS) for Builds 5–8 to include the remaining functionalities needed to provide V-PTC virtual 

block capabilities. 

As part of the V–PTC project’s focus on addressing PTC related issues, the V–PTC technical 

advisory group asked the TTCI team to examine some of the effects of PTC EBAs on freight 

train operations. During pilot operational use of some other PTC systems, train crews had 

experienced penalty brake enforcements in situations for which they were not warranted. Some 

of the affected operational conditions were examined by running simulations using the Train 

Operations and Energy Simulator (TOES), a validated, widely accepted model for simulating 

freight train performance in detail. The resulting analysis of the effects of PTC EBAs on freight 

train operations showed that a PTC EBA that assumes worst-case braking characteristics (no use 

of independent brake and no use of dynamic brake, which are common assumptions) has the 

potential to have a significant negative impact on freight railroad operations. The analysis also 

showed the potential improvement to operations by including independent and emergency 

braking as part of the PTC enforcement solutions. As a result of this analysis, a separate FRAsponsored project to further investigate methods for improving PTC EBAs was initiated.

To support the periodic developmental system performance evaluations, TTCI upgraded the 

existing track, signals, and communications infrastructure at the TTC in Pueblo, Colorado. 

These upgrades included adding PTC control points (in the form of remotely monitored and

controlled switches), a 4,000-foot siding for meets and passes testing, and 900 megahertz (MHz)

PTC radio communication systems. Also added were a CAD system and a BOS. The design, 

installation, and checkout of these upgrades were phased to correlate with the testing needs of the 
3

incremental development cycle. An additional benefit of the project is that these enhanced test 

bed features are available as needed for testing other PTC systems.

For each of the system builds, testing was performed to compare system performance to the 

related requirements in the SRS. Detailed test reports were produced.1,2,3,4,5 Portions of these 

reports are either summarized or directly extracted and used throughout this report. The results 

show significant development success.
4

1. Introduction

FRA and the railroad industry are very interested in accelerating the development and 

deployment of PTC systems that are in compliance with federal regulatory requirements. The 

National Transportation Safety Board for years placed PTC technology, an advanced train 

control system, as the most wanted technology to enhance safety in the railroad industry. The 

RSIA'08 mandated that PTC be installed on intercity passenger, commuter passenger, and most 

Class 1 freight rail lines by the end of 2015. FRA subsequently codified that with the addition to 

the Code of Federal Regulations (CFR) Subpart I of 49CFR236.

Through years of R&D by the NAJPTC program, substantial progress was made. Several 

railroads adopted significant portions of the technology in developing their PTC systems. 

However, the systems developed by these railroads are overlay systems, and they do not have a 

central safety server that would enable enhanced functionalities, such as moving block

capabilities and protection against propagation of false clears. Moving block technology was 

identified as a possible business benefit of a PTC system that could potentially increase the 

capacity of certain lines over that provided by conventional fixed block systems. Also, 

development of a centralized vital system could benefit the industry by producing a PTC system 

that could replace aging signal systems without the burden of substantial infrastructure 

replacement and continued maintenance of extensive wayside systems. As a replacement to 

provide at least the same safety level as a centralized traffic control (CTC) system, which is a 

vital signal system, a PTC system would need to be of a fail-safe design, with detection 

capabilities of all failure modes and closed-loop designs of all safety-critical components.

TTCI, in cooperation with FRA, RRF, and the MS2 Division of LMC, conducted R&D activities 

for a safety critical, CBTC system. The system, functionally a second-generation vital PTC 

system, is designed to use an office-centric architecture based on current and evolving industry 

PTC communications technologies. The system R&D was performed under the V–PTC project

and the goal of the project was to field test a fully functional vital PTC system that could be used 

in revenue service operations.

1.1 Background

Beginning in 2001, the NAJPTC Program, in a partnership with the Illinois Department of 

Transportation (IDOT), AAR, and FRA, conducted testing between Mazonia and Springfield, 

Illinois, to verify and validate a vital PTC design. IDOT originally planned to leverage this 

technology to allow passenger trains to operate at speeds up to 110 miles per hour (mph) along

this corridor. However, because of the extensive development time required, IDOT decided in 

2006 to install conventional cab signal technologies along the route and withdrew from the 

partnership. Therefore, FRA and RRF elected to continue development of a vital PTC system 

elsewhere. With the concurrence of the participants in NAJPTC (FRA, AAR, IDOT, Union 

Pacific Railroad, and Amtrak), the NAJPTC steering committee was disbanded and a new 

committee comprised of FRA, RRF, and Norfolk Southern, as an operating railroad 

representative, was formed as a technical advisory group for a new follow-on project, the V–PTC

project. LMC, the NAJPTC System Development Integrator, agreed to provide in-kind services, 

worth $2 million or more per year for three years, in order to continue development of a V–PTC

system. LMC further agreed to cooperate with TTCI (as Project Office for the new V–PTC
5

project) on engineering, system development, and field testing of the follow-on V–PTC system. 

Functionally, in the follow-on project, LMC SD2 performed as the System Development 

Integrator and TTCI served as the Project Office, Systems Engineer, and as the field test support 

agency, providing facilities and expertise for field R&D testing activities.

1.2 Objectives

Building on the NAJPTC development work, the objective of the V–PTC project was to continue 

developing, testing, and demonstrating a revenue service-ready V–PTC system at TTC, and then 

to demonstrate the system on a revenue service route. It was envisioned that V–PTC, as a PTC 

system, would provide public benefits through a reduction in risk to railroad passengers and 

railroad employees and would potentially improve the efficiency of the national railroad 

network. 

1.3 Overall Approach

The overall approach was to have TTCI develop the V–PTC Concept of Operations6 and SRS,

7

and to have LMC design, develop, and produce V–PTC system components. The system was 

developed and tested in incremental builds of increasing capabilities. This incremental 

development approach enabled the TTCI/LMC team to periodically evaluate system performance 

to ensure each development phase produced capabilities aligned with the SRS. This approach 

was used to ensure development of a system of continually increasing complexity had a solid, 

well examined foundation on which to build.

To support these periodic developmental system performance evaluations and testing of other 

PTC systems, TTCI upgraded the existing track, signals, and communications infrastructure at 

the TTC in Pueblo, Colorado. These upgrades included adding PTC control points (in the form 

of remotely monitored and controlled switches), a 4,000-foot siding for meets and passes testing, 

and 900 MHz PTC RF communication systems. Also added were a CAD system, a BOS, and 

PTC test instrumentation. The design, installation, and checkout of these upgrades were phased 

to correlate with the testing needs of the incremental development cycle.

1.4 Scope 

The scope of this project included Project Office, Systems Engineer, System Development 

Integrator, and development test support activities. TTCI as the Project Office coordinated with 

LMC as the Systems Development Integrator to manage the project, with input from the V–PTC

technical advisory group and FRA. In its role as Systems Engineer, TTCI provided system 

engineering activities for developing documentation, performing analysis, and completing system 

specifications. LMC as the System Development Integrator developed and provided the necessary 

system hardware and software, and it coordinated with TTCI to install system components at TTC for 

testing. Jointly, TTCI and LMC undertook activities, meetings, and conferences related to the 

development of the V–PTC system. The V–PTC system was actively tested using the track and PTC 

communications and control infrastructure at TTC. Initially, the project was designed to include 

system testing on a revenue service route of a participating AAR member railroad, but as the project 

unfolded, the member railroad elected to use an alternative interoperable PTC system, and the revenue 

service testing phase was deleted from the project.
6

1.5 Organization of the Report

This report is organized in five major sections. Section 1 is the introduction and discusses the 

project’s background, objectives, overall approach, and scope. Section 2 provides a description 

of the V–PTC system, including the system architecture, the V–PTC server, onboard systems, 

and communications. Section 3 describes the V–PTC system development cycles, including 

Build 1 (Train Location Monitoring), Build 2 (Server Switch Monitoring), Build 3 (Switch 

Warnings and Control), Build 4 (Onboard Display of Authority), and Builds 5–8 (Reactive 

Enforcement of Speed and Authority Limits). Section 4 provides information about the TTC’s 

PTC Test Bed, including an overview, a description of test bed elements, a summary of the test 

bed architecture, a review of the upgrades performed in 2009, and a brief description of the 

documentation package for the upgrades. Section 5 presents an overview of testing for each of 

the V–PTC build cycles and a summary of the associated test results.
7

2. V–PTC System Description

This project focused on developing V–PTC locomotive and office PTC segments. These 

segments were then integrated with a commercially available CAD system located at TTC, 

providing one of the earliest integrated PTC CAD/BOS combinations in the industry. The 

locomotive and office segments were also integrated with TTC’s wayside segment components, 

including track infrastructure, wayside signal systems, wayside interface units, RF

communications network, and a track database for the RTT. The system was designed to meet 

the four key requirements of a PTC system, as defined in RSIA ’08:

• Prevent train-to-train collisions

• Prevent over-speed derailments

• Prevent incursions into established work zone limits

• Prevent movement of a train through a switch left in the wrong position

2.1 V–PTC System Architecture

The V–PTC system architecture is described in detail in V–PTC Onboard Train Internal System 

Architecture.

8

 For the reader’s convenience (and with LMC permission), a portion of the report

is presented here. The V–PTC system is required to interface with the locomotive crew, the V–

PTC Dispatch System, and the Wayside Interface Unit (WIU), and is broken up into two major 

subsystems, the V–PTC Server, and the V–PTC Onboard. The V–PTC Server and V–PTC

Onboard are interconnected through the V–PTC Communications System, which is used to 

maintain system status and to share data with each other. Figure 1 shows how the V–PTC

system functions with the other external systems, and Figure 2 shows the internal structure and 

architecture of the V–PTC system.

Figure 1. V–PTC System Interaction
8

Figure 2. V–PTC System Architecture

2.2 V–PTC Server

The V–PTC Server Subsystem consists of the Authority Management Server (AMS) and 

connections to the V–PTC dispatch system and the WIU network. The AMS is responsible for 

determining authority status throughout the V–PTC system territory, authority conflict checking,

and distributing the authorities received from the V–PTC Dispatch System as appropriate; the 

AMS is responsible for stacking and unstacking authorities as required by operating procedures 

on V–PTC track. Additionally, the AMS is responsible for processing speed bulletins as 

delivered by the V–PTC dispatch system, determining switch status via WIU reports, and

maintaining a track database with all monitored and unmonitored switches for notification to the 

V–PTC onboard subsystem. The V–PTC server subsystem also provides interactions with any 

operators and maintainers as required. 

In general, the V–PTC server subsystem is responsible for tracking system configurations, 

determining which system configurations are valid and functioning, processing alerts from the 

V–PTC Onboard and passing the appropriate alerts and notifications to the V–PTC dispatch 

system. In the case of powered switches along proposed locomotive routes, the V–PTC server 

subsystem is responsible for configuring the powered switches such that the locomotive will be 

able to traverse the route with minimal stoppage.

2.3 V–PTC Onboard

The V–PTC Onboard subsystem is responsible for managing a single locomotive and 

communicating with the V–PTC server. In general, the V–PTC Onboard System is responsible 

for ensuring that the locomotive operates in a manner consistent with its authorities (as delivered 

by the V–PTC server), and with the standing railroad rules and regulations governing the local 

area surrounding the railway. 

The V–PTC Onboard System is responsible for periodically checking internal data and physical 

components to ensure no data corruption has occurred within the data stored on it. Additionally, 

the Onboard System is responsible for periodically checking the health of all onboard PTC 

components stopping the train, and reporting to the V–PTC server if any anomalies are detected. 

The V–PTC Onboard System is currently designed to have three major functional units within it:

(1) the Location Determination System (LDS), (2) the Locomotive Display Unit (LDU), and (3) 
9

the Locomotive Control Unit (LCU). These three major units are expected to interact with the 

locomotive, locomotive crew, and the V–PTC server. These three units work together and

ensure that the locomotive operates in accordance with the authorities granted the locomotive by 

the V–PTC dispatch system and V–PTC server, as well as the operating rules of the railway.

A functional breakdown of the V–PTC Onboard System is as follows:

• The LCU is responsible for interacting with the V–PTC server and integrating all of the 

inputs from the LDU, LDS, and V–PTC server to control the locomotive, brake when 

necessary, and respond to situations as appropriate. 

• The LDS is responsible for interfacing with the locomotive sensors and Global 

Positioning System (GPS) systems to determine current locomotive state and position. 

Additionally, it is responsible for mapping the locomotive to track or requesting crew 

assistance (via the LDU) if unable to map to track.

• The LDU is responsible for interacting with the locomotive crew, providing an interface 

for the system to alert the crew of warnings, violations, and subsequent actions taken by 

the onboard system. Additionally, the LDU provides an interface for the crew to 

acknowledge authorities and alerts provided by the dispatching system and V–PTC

server. 

• The V–PTC Onboard System is physically attached to the locomotive that it monitors and 

reports on. The physical onboard system (Figure 3) is comprised of the following:

▬ GPS System

▬ Locomotive Sensor Suite

▬ Brake Interface Unit (BIU)

▬ Onboard Display Unit

▬ Onboard Audio Unit

▬ LCU, LDU, LDS

Figure 3. Physical Interaction Diagram

2.3.1 LCU

The major functionality that the LCU is responsible for performing is as follows:

• Locomotive Health Monitoring and Reporting
10

• Locomotive Location Reporting

• Locomotive Consist Management

• Locomotive Authority Enforcement

• Locomotive Speed Enforcement

• Locomotive Route Enforcement

• Locomotive Data Logging

The LCU is responsible for integrating and maintaining the state of the various components of 

the locomotive, including the other V–PTC onboard subcomponents, as well as the overall state 

of the locomotive. As a part of the overall state of the locomotive, the LCU periodically checks

its internal health and ability to stop the train as necessary. This interaction requires that the 

LCU interface with the BIU and periodically check to ensure that the BIU is functioning 

correctly. Additionally, the LCU is responsible for reporting locomotive location and state to the 

V–PTC Server, which in turn reports the information to the system operator and dispatch system. 

The various states that the LCU can assume are as follows:

• Powered Off

• Powered On

• Offline

• Initialized

• Enabled

• Operational

Each of these states and state transitions are determined by the LCU and communicated to the 

other onboard components and the V–PTC Server. The Powered Off state is the initial PTC state 

for the locomotive, when the LCU has been turned off, and the brakes are subsequently applied 

to the locomotive. When the LCU is turned on, the V–PTC Onboard system moves into the 

Powered-On state. In this state, the Power-On-Self-Test procedure is executed along with Initial 

Program Load. After this, the V–PTC Onboard software is successfully loaded onto the various 

processors and the system transitions into the Initialized state. 

This state has two substates, Departure Test Required and Departure Test Complete. After 

completing Departure test and initializing the train, the V–PTC onboard system transitions from 

the Initialized state into either the Enabled state or Operational state depending on whether the 

locomotive has mapped to controlled track or not. If the locomotive has mapped to controlled 

track, the system is deemed operational, and the V–PTC Onboard system proceeds to enforce the 

train as appropriate. 

The only substate that could occur while the locomotive is in the Operational state is the Out of 

Communications substate. The Out of Communications substate is entered whenever the 

locomotive loses communications with the V–PTC Server. After the locomotive has 

accomplished its route and loses all authorities it has, the V–PTC Onboard system can transition 

back to the Initialized state in the Departure Test Complete substate. Figure 4 illustrates the 

various states that the locomotive will transition through and the nominal flow of the V–PTC

Onboard System. If at any time the LCU system detects a safety-critical fault in the software, it

enters the Offline state, which requires a power cycle and possible maintenance to enable the 

train again.
11

Figure 4. Locomotive State Diagram

The LCU is additionally responsible for ensuring that its datasets (Consist, Authority, Bulletin, 

and Track Database) are internally consistent. Each of these datasets is periodically checked to 

ensure that the data has not changed without the proper authorization. Each dataset is 

safeguarded through the use of Cyclical Redundancy Checks (CRCs), which are also periodically 

checked against the V–PTC Server CRCs to ensure that the onboard data is the same as the data 

the V–PTC Server has stored for the locomotive. 

All of the datasets are used for enforcement purposes to ensure the locomotive follows the 

railway operating procedures and the authorities granted it by the dispatching system. Consist 

data is used to determine the train characteristics, and it is used to determine braking points and 

maximum speed constraints for the whole train. Authority data is used to determine what routes 

the train has permission to traverse and at what points the train is required to stop. Speed data

and bulletin data are used to enforce speed restrictions as set up by the dispatch system. 

Finally, the track database is used to determine track characteristics, including gradient, curves, 

and maximum speed limits at certain locations along the track. Additionally, the track database 

contains switch locations, which are used to determine monitored switch locations as well as 

unmonitored switch locations for the purposes of enforcement and to ensure the train is moving 

correctly over the switch. 

As the LCU controls the interface over the BIU, the LCU is responsible for determining when 

enforcement occurs, whether due to speed violations or authority violations, and reporting this 

information to the V–PTC Server.

The system is required to be fail-safe and ensure correct communications and operations; 

therefore, the eventual architecture will have multiple components performing all LCU 
12

operations in parallel. These multiple components will need to ensure their communications and 

actions taken are in sync to ensure correct operation of the locomotive.

2.3.2 LDS

The LDS system determines the location of the train and serves as the main interface for all the 

train sensors. The LDS is connected to the onboard GPS antenna and uses the GPS system to 

determine initial locomotive location. If the LDS is unable to map to track in multiple track 

territory, it is responsible for requesting crew input to determine which track the train is currently 

occupying. Once the train is mapped to track, the LDS uses inertial navigation to determine 

higher levels of accuracy in location reporting. 

As the main onboard interface with the locomotive sensors, the LDS is responsible for reporting 

to the other components train and locomotive data including location, speed, direction, brake 

pipe pressure, and status of the various components of the train.

2.3.3 LDU

The LDU system is responsible for providing audio and visual interface with the locomotive 

crew members. At the direction of the LCU, it provides various alerts and warnings to the crew 

members to notify them of impending or current actions taken to ensure the train operates in 

accordance to the authorities and speed restrictions given to it. To provide the alerts and 

warnings, the LDU uses the Onboard Display Unit and associated audio devices to notify and 

alert the crew as necessary.

2.4 Communication

Communication between the V–PTC Onboard system and the V–PTC Server is expected to 

occur over one of multiple potential communication media, e.g., satellite link, cell phone data 

packets, radio packets, or wireless Internet. The V–PTC Onboard system and the V–PTC Server 

will determine which of these media to utilize at any given time based on availability and 

priority.

Although the LCU is the only onboard component responsible for communication with the V–

PTC Server, at any one time due to safety and reliability constraints, the LCU may be comprised 

of multiple smaller subcomponents, each able to communicate with the V–PTC Server. To

eliminate competition between the various subcomponents, the LCU ensures that only one 

subcomponent is communicating with the V–PTC Server at any given time. Likewise, a similar 

scheme is utilized to ensure that only one element within the LCU is communicating with the 

LDU at any given time. 
13

3. V–PTC System Development

To comply with V–PTC technical advisory group and FRA guidance, the project was 

implemented using an approach based on providing demonstrated incremental progress during 

the system development cycle. V–PTC functionality development and related testing were

distributed throughout eight phased builds. These builds were organized into five groups of 

demonstrated and deployable capability. Figure 5 shows an overview of the system build cycles. 

3.1 Build 1—Train Location Monitoring

Build 1 was designed to provide the functionality of determining the accurate location and speed 

of a train without the aid of track circuits and report these data to the V–PTC Server. The 

objectives of Build 1 were to:

• Demonstrate Onboard Train-Borne Navigation Performance during field testing at TTC

• Train Location Position Accuracy

• Train Velocity Measurement Accuracy

• Route Determination

• Demonstrate V–PTC Server Build 1 Capabilities

• Log-On Password

• Time Alignment

• Message Logging

• Message Receipt Status

• Software Version Reporting

• Demonstrate that an effective radio link can be established and maintained between trainborne equipment and the V–PTC server at the TTC facility

Train 

Location 

Monitoring

Server 

Switch 

Monitoring

Switch & 

Warnings 

Control

Onboard 

Display of 

Authority

Reactive 

Enforcement of 

Speed & 

Authority Limits

Moving 

Block

Onboard 

Display of 

Bulletins

Vital Positive 

Train Control

Track 

Worker 

Protection

2007 & 2008 2009/2010/2011 Future Development

Figure 5. V-PTC System Build Cycle Overview
14

3.2 Build 2—Server Switch Monitoring

Build 2 was designed to develop the V–PTC capability to monitor and report the alignment of 

both powered and nonpowered (hand-operated) switches, the status of associated on station track 

circuits, and to ensure that all of these conditions are reported to the V–PTC Server.

3.3 Build 3—Switch Warnings and Control

The purpose of Build 3 was to ensure that all of the data in the previous builds, including switch 

point position, is transmitted to the onboard display of the locomotive and that the data can be 

seen and evaluated by the locomotive engineer in the cab of the locomotive. The objectives of 

Build 3 were to:

• Demonstrate switch awareness capability by the V–PTC Server 

• Display correct train location on mapped track 

• Display configuration and location of track features (switches, crossings, mileposts, etc.) 

within the horizon 

• Display train speed and current time onboard the locomotive

• Display results of onboard train-borne power up integrity checks 

• Display status of onboard train-borne health monitoring processing

• Demonstrate V–PTC BOS to wayside or train-borne unit communications over the PTC 

Test Bed’s communications network using MeteorComm MCC-6100 radios

• Respond to a V–PTC technical advisory group request from Build 1 testing to

demonstrate a 40-mile per hour turnout through Switch 301 of the RTT

• Verify that the display of train location and track features is correct

• Perform turnouts using both short-hood forward and long-hood 

forward configurations

3.4 Build 4—Onboard Display of Authority

Generally, Build 4 was intended to (1) verify the capability to remotely control alignments of 

monitored and powered switches by a dispatcher using the CAD/BOS interface, (2) transmit the 

information monitored in Builds 1 and 2 from the V–PTC BOS to the CAD system using the 

interface, and (3) display all authorities entered by the dispatcher to the locomotive engineer in 

the cab of the locomotive. Build 4 capabilities were implemented in two parts, 4A and 4B. The 

specific objectives of Builds 4A and 4B are described below.

3.4.1 Build 4A—Specific Objectives

• The V–PTC Server will receive requests to set nonsignaled control points from the 

dispatching system. The V–PTC Server will command the WIU to set the power

operated switch in the requested position after verifying the request is safe to grant.

• The V–PTC system will align a power operated switch at a nonsignaled control point 

consistent with requests from the dispatching system when none of the following 

conditions apply:

▬ The switch is occupied.

▬ The switch is in local control.

• The V–PTC system will reject a dispatching system request to align a power operated 

switch at a nonsignaled control point when any of the following conditions apply:
15

▬ The switch is occupied.

▬ The control point is in local control.

• The V–PTC system will prevent the operation of a power operated switch at a 

nonsignaled control point when it is occupied by a train.

3.4.2 Build 4B—Specific Objectives

• Monitor powered and hand switches at the dispatch system

• Prevent the operation of a power operated switch at a nonsignaled control point when it is 

occupied by a train (normal, reverse, and unknown switch positions)

• Control powered switches remotely from the dispatch system

▬ Normal operations mode (normal and reverse moves)

▬ Overswitch protection

▬ Local Control Mode (LCM)

▬ Switch change request rejections

• Monitor powered and hand switches at the dispatch system

• Verify train location monitoring at the dispatch system

• Verify correct operations of the V–PTC Server under different test conditions including 

communication outages

• Verify train-borne displays the switch states in the display horizon

3.5 Builds 5–8—Reactive Enforcement of Speed and Authority Limits

Builds 5–8 encompassed system capabilities associated with movement authorities and related 

functionalities. Builds 5–8 were developed as a coordinated group and then tested in a single ontrack test period November and December 2009. The general capabilities developed during 

these builds included the following:

• Verification of train location monitoring at the dispatch system

• Initialization and synchronization of V–PTC Server, RailComm CAD, and Onboard V–

PTC system components

• Awareness and remote control of switches

• Location determination and display on the CAD system 

• Health status monitoring of the V–PTC Server and Onboard systems

• Train activation

• Issuance, delivery, and management of authorities 

▬ Proceed authorities

▬ Cancel and reissue of proceed authorities

▬ GCOR Line 9 conditional authorities

▬ Cancellation of proceed authorities

▬ Route integrity monitoring

 Stops and inspections

 Route locking

▬ Enforcement actions for speed and authority violations

▬ Train termination
16

3.5.1 Builds 9+

After the completion of field testing and movement authority roll-up demonstrations at the end of 

the Builds 5–8 development cycle, LMC had met its project funding obligation to provide a total 

of $6 million over three years. Nonetheless, LMC and the V–PTC technical advisory group

desired to continue V–PTC system development. For continuation efforts, the initial plan was to 

continue the incremental development cycle until the system had moving block functionality, 

which was actually implemented as virtual block instead. However, in response to available 

project funding (for both FRA and LMC), the project emphasis shifted to developing and 

demonstrating the LMC implementation of the TTCI-developed PTC EBA and to revising the 

SRS for Builds 5–8 to include the remaining functionalities needed to provide V–PTC virtual

block capabilities. The principal additional SRS functionalities included:

• Roadway Worker Protection

• Temporary Speed Restrictions

• Advance Grade Crossing Activation

• Virtual Block-based Movement Authorities

These points of emphasis were completed during the fourth quarter of 2010. 
17

4. Enforcement Braking Algorithm Evaluation

As part of the V–PTC project’s focus on addressing PTC related issues, the V–PTC technical 

advisory group asked the TTCI team to examine some of the effects of PTC EBA on freight train 

operations. During pilot operational use of other PTC systems, train crews had experienced

penalty brake enforcements in situations for which they were not warranted. For example, as the 

crew slowed a train while approaching a stop, the train too often received a PTC penalty brake 

enforcement that stopped the train short of the intended stopping position. Several operational 

conditions appeared to have caused these issues, primarily braking operations for which dynamic 

and/or independent braking is typically used:

• Slow speed operations—less than 20 mph, typically less than 15 mph (this issue was 

catalyst for V–PTC EBA efforts)

• Short train operations—trains for which the locomotive weight is dominant

• Steep downgrades—where dynamic brake use is required, but is not accounted for in 

EBA in use at the time

One observation early in the EBA evaluation process was that the use of dynamic braking was 

not accounted for in algorithms used at the time. Normal crew braking procedures are to use 

dynamic braking to slow the train to ~5 mph, then use a combination of automatic and/or

independent braking for speeds below 5 mph, when dynamic braking becomes ineffective. 

However, predictive EBA used at the time were based solely on the use of automatic braking

(i.e., assumed no use of dynamic or locomotive independent brake). Additionally, in order to 

achieve a very high level of safety assurance, the predictive EBAs used at the time also made the 

assumption that the train exhibits worst-case braking system parameters. Consequently, the 

algorithms in use at the time were so conservative that penalty enforcement was initiated earlier 

than necessary and stopped trains significantly short of their target stopping locations.

As part of the EBA evaluation efforts, the operational conditions described above were examined 

by running simulations using TOES, a validated, widely accepted model for simulating freight 

train performance in detail. For each operational condition, simulations were run to compare 

where a train crew would typically begin stopping the train to where a conservative enforcement 

algorithm would initiate a penalty brake application. To model where the enforcement algorithm 

would initiate a penalty application, simulations were run that incorporated worst-case braking 

system parameters, including:

• ABD type control valves

• Long brake cylinder piston stroke

• 8.5 percent net brake ratio

• Loads with 10 percent overweight

To model where a train crew would typically begin stopping the train, simulations were run 

using braking procedures defined in BNSF Railway Company locomotive engineer training 

material. These simulations incorporated “nominal” braking system parameters, including:

• ABDW type control valves

• Nominal brake cylinder piston stroke

• 10 percent net brake ratio
18

• Nominal rated loads

In addition to simulating where a conservative enforcement algorithm would initiate a penalty 

brake application, a number of other potential enforcement strategies were identified and 

simulated. A total of eight simulation cases were run for each operational condition. Seven of 

the eight cases represent the various braking strategies, and a target case represents how a train 

crew would operate the train to a stop. The eight cases are:

• Case 1—Full service brake enforcement to train stop that assumes independent brakes 

are bailed (typical conservative enforcement algorithm assumptions) 

• Case 2—Full service brake enforcement to train stop that precludes bailing of 

independent brakes

• Case 3—Full service brake enforcement to 26 psi brake pipe pressure reduction, 

precluding bailing of independent brakes

• Case 4—Case 1 with emergency brake backup (after penalty is through train)

• Case 5—Case 2 with emergency brake backup (after penalty is through train)

• Case 6—Case 3 with emergency brake backup (after penalty is through train)

• Case 7—Emergency brake enforcement to train stop 

• Target Case—Normal train crew braking procedures (combination of dynamic, 

independent, and automatic brakes used)

Figure 6 shows the results of these simulations for a 100-car loaded general freight train running 

at 10 mph. The figure shows where enforcement would occur for each of the eight cases, in 

order to stop the train at the same location as the target case. It also shows where a 20-second 

and 40-second warning would occur for Case 1. The figure illustrates the observed issue that 

warnings and enforcements occur before a train crew would begin to bring the train to a stop 

using normal operating procedures. The figure also illustrates that use of the independent brake 

and/or use of the emergency brake as a backup for a worst-case train could help reduce the 

negative operational effect of the conservative nature of the EBA.
19

Figure 6. Braking Distances for Slow Speed Operation

Figure 7 shows the results of these simulations for a short train operational scenario. The train 

consist for these simulations included 10 loaded general freight cars, and the simulations ran at 

an operating speed of 40 mph. In this case, the effect of bailing the independent brakes results in 

a much longer stopping distance in case 1 than in the target case. This has a similar effect as the 

slow speed operation of warnings and enforcements occurring before the train crew would 

normally begin stopping the train. Use of the independent brake in these cases has a dramatic 

effect on the stopping distance, and results in the enforcement occurring after the train crew 

would normally begin to stop the train.

Finally, Figure 8 shows the results of these simulations for an operating scenario with a steep 

downgrade. In this case, the 100-car loaded general freight train was operated on a -2 percent

grade at 20 mph. In this case, dynamic brakes were used to control the speed of the train before

enforcement. However, because of the EBA’s assumption that dynamic brakes are not used, the 

train begins to accelerate following the point of enforcement, until the air brakes have time to 

propagate through the train. This assumption results in a dramatically longer stopping distance 

for case 1 than for the target case, which assumes that dynamic brakes will be used to help stop 

the train. Again, it results in warnings and enforcements before the crew would normally begin 

the braking process. As with the previous operational conditions, use of the independent brake 

and emergency brake as a backup has the potential to reduce the negative operational impact.

0

1

2

3

4

5

6

7

8

9

10

-800 -600 -400 -200 0 200 400 600

Distance (Feet)

Speed (mph)

case 1

case 2

case 3

case 4

case 5

case 6

case 7

target case

20 s Warn

40 s Warn
20

Figure 7. Braking Distances for Short Train Operation

Figure 8. Braking Distances for Steep Decline Operation

0

5

10

15

20

25

30

35

40

-4000 -3000 -2000 -1000 0 1000 2000 3000

Distance (Feet)

Speed (mph)

case 1

case 2

case 3

case 4

case 5

case 6

case 7

target case

20 s Warn

40 s Warn

0

5

10

15

20

25

30

-12000 -10000 -8000 -6000 -4000 -2000 0 2000 4000

Distance (Feet)

Speed (mph)

case 1

case 2

case 3

case 4

case 5

case 6

case 7

target case

20 s Warn

40 s Warn
21

The analysis of the effect of PTC EBA on freight train operations demonstrates, through 

simulation test results, that a PTC enforcement algorithm that assumes worst-case braking 

characteristics, no use of independent brake, and no use of dynamic brake has the potential to 

have a significant negative impact on freight railroad operations. The analysis also shows the 

potential improvement by including independent and emergency braking as part of the PTC 

enforcement solution. Additionally, an algorithm that has the ability to adapt to the braking 

characteristics of a specific train to alleviate the conservatism of assuming worst-case braking 

characteristics has the potential to further reduce the negative operational impact. As a result of 

this analysis performed as part of the V–PTC project, a separate project to further investigate 

methods for improving PTC enforcement algorithms was initiated.
22

5. TTC’s PTC Test Bed

As part of the incremental development approach, V–PTC system performance was evaluated at 

the end of each major build cycle. On-track testing was conducted at TTC using the PTC Test 

Bed developed by TTCI with FRA support. The Test Bed was initially developed and 

subsequently upgraded to provide an industry resource for testing PTC-related systems,

equipment, and technologies in an environment free of the requirements associated with revenue 

service test activities. Compliance with requirements associated with testing on revenue service 

routes can present testers with significant challenges. Examples include: 

• Must schedule test activities around revenue service traffic

• Must obey all operating rules or obtain waivers (frequently a lengthy process)

• Difficult to conduct stress testing (i.e., degraded equipment or high capacity 

performance testing)

• Test conditions (and, therefore, test results) are often not repeatable

• Changes to vital equipment require lengthy verification and validation processes before 

retest is possible

Among other uses, the PTC Test Bed provides a facility that can be used for supporting 

development of PTC systems, for conducting performance evaluations of PTC system segments, 

and for performing interoperability and compliance testing. PTC system development could 

include proof of concept demonstrations, system development testing, and simulations and ontrack (field) tests. Performance evaluations would likely involve (1) Locomotive onboard 

equipment, (2) Communications infrastructure components, (3) BOS and CAD/BOS interfaces, 

and (4) WIU (for trackside systems). Interoperability and compliance testing could be for initial 

equipment acceptance and for interchange operations.

Examples of potential PTC Test Bed uses include the following:

• Preliminary field trials and debugging of PTC systems

• Development and testing of improved PTC braking algorithms

• Evaluating impact of communications system performance and loading on PTC 

system performance

• Development and test of PTC positive end of train determination

• Preliminary field testing of an Employee in Charge Portable Remote Terminal

• Demonstrating operation of PTC highway crossing protection systems

• Certification/acceptance testing of PTC systems or components

• Interoperability/interchange testing of multiple PTC systems

The V–PTC project facilitated certain upgrades to the test bed and provided extensive 

opportunities over several years to debug and validate the PTC Test Bed.

5.1 PTC Test Bed Overview

The PTC Test Bed consists of railroad track infrastructure, communication infrastructure, PTC 

equipment, railroad vehicles/rolling stock, laboratories, and specialized software 

(instrumentation and modeling) tools that provide the capabilities to perform consistent and 

realistic test environments for PTC systems and railroad communication systems. The elements 
23

of the PTC Test Bed are building blocks that can be assembled in multiple configurations to 

provide a desired test environment or scenario. The PTC Test Bed at TTC provides an 

independent, dedicated, and controlled test environment that does not interfere with the 

productivity of railroad revenue service operations. It allows PTC testing to be conducted very 

efficiently without interference from revenue trains.

5.2 PTC Test Bed Elements

The PTC Test Bed is composed of numerous elements that can be configured to establish test 

environments needed to conduct evaluation of PTC systems and components. The test bed 

elements fall into three classes:

Fixed Test Bed Elements: These are features of TTC’s test facilities that can be incorporated 

into test environments, but cannot, in general, be altered significantly from their initial state. 

Fixed test bed elements are full-scale equipment and facilities located at TTC and include: 

• RTT

• Transit Test Track (TTT)

• Sidings, turnouts, crossing protection systems, and other railroad infrastructure

• Locomotives and rolling stock

Quasi-Fixed Test Bed Elements: These are features of TTC’s test facilities that are typically 

incorporated into test environments as is, but can be altered if necessary and generally require

more effort to do so than for configurable elements. Quasi-fixed test bed elements are full-scale 

equipment and facilities located at TTC. These elements include:

• RF communication infrastructure

• PTC WIUs

• PTC locomotive equipment

• PTC BOS

• CAD systems

• Signal systems, such as the GE Electrified ElectroCode-4+ system on the RTT

• Backhaul/data network

Configurable Test Bed Elements: These are features or components of the PTC Test Bed that 

can be readily altered, modified, or scaled as needed to create a test environment. Configurable 

test bed elements are modular and in many cases are used to overcome or mitigate limitations of 

fixed or quasi-fixed elements. Configurable test bed elements include:

• Rail Traffic Controller (RTC) Model and Post Processor

• Train Simulator

• WIU Simulators

• Network Traffic Generators

In addition to the fixed and configurable elements, the PTC Test Bed includes test support 

elements. Test support elements are equipment and software tools needed to collect data, 

analyze data, or augment the characteristics of the test environment. These elements include:

• Data collection 

• Track database 
24

• Test Software Environment Controller

• Automated test script generators/Test Designer

• Test Equipment (Spectrum/Network Analyzers, oscilloscopes, RF Noise Generator, and 

RF Channel Simulator)

5.2.1 Fixed Test Bed Elements

Railroad Test Track

The RTT is a 13.5-mile loop with four 50-minute curves and a single 1-degree, 15-minute 

reverse curve. It accommodates maximum speeds of 165 mph. The RTT also has a 4,000-foot 

siding and a crossover to the TTT. 

The RTT has three powered switches with on station circuits located at Switch 302, Switch 305 

(each end of the 4,000 ft siding) and at Switch 602B (crossover to TTT). The RTT is divided 

into 12 signal blocks and is equipped with a GE Electrified ElectriCode 4+ (EEC 4+) signal 

system capable of supporting 9-aspect cab signaling. A 4,000-foot siding and a crossover to the 

TTT to allow for the execution of multitrain meet and pass type operational scenarios. 

Transit Test Track

The TTT is a 9.1-mile oval track, equipped with a third rail power system and is used for vehicle 

performance and specification compliance testing. Vehicle performance investigations at speeds 

up to 80 mph are conducted. The third rail direct current (DC) electrified power system can 

provide transit and commuter vehicles with a variable of 0 to 1,000 volts of DC with a 3,500 

ampere continuous rating. The track includes 3,333 yards of overhead DC contact wire catenary, 

suitable for low-speed operation and evaluation of light rail urban vehicles. The TTT runs 

parallel with the RTT for a significant portion of its overall length, allowing for the ability to 

conduct multitrack PTC scenarios.

Test Bed Communications Infrastructure

The following RF communication infrastructure is in place at TTC:

• 180-foot tower with collocated communication bungalow and power. Antennas for 

160 MHz voice radio, 900 MHz data radio, 450 MHz vehicle tracking system, and 

11 gigahertz microwave T1 are installed. Antennas for communication systems under 

test may be placed on this tower at heights specific to the RF coverage footprint needed. 

• 120-foot tower with collocated communication bungalow and power. Antennas for 

160 MHz voice radio and 900 MHz data radio channels are installed. Antennas for 

communication systems under test may be placed on this tower at heights specific to the 

RF coverage footprint needed.

• Three 802.11 b/g access points with antenna heights ranging from 40 to 100 ft that 

provide on-track sites for wireless data download points.

• CDMA cellular (Verizon) tower and service

Figure 9 shows locations of communication towers and RF infrastructure at TTC.
25

Figure 9. Track and RF Communications Infrastructure

Backhaul infrastructure for the RF communications infrastructure and PTC field networks is 

provided by data networks that are segregated from the TTCI business data network. The

isolated backhaul infrastructure allows for testing of communication equipment that is 

unperturbed by data traffic generated by TTCI’s business applications. Figure 10 provides an 

overview of the network infrastructure in place at TTC to support test of communication and 

train control systems.
26

Figure 10. Backhaul and Data Network Overview

Train Control Infrastructure/PTC Equipment

The PTC Test Bed is currently configured for supporting on-track development testing of the VPTC system. To support testing of this PTC system with an office-centric architecture, the 

current PTC Test Bed configuration includes the following items:

• One CAD system with an interface to a BOS 

• One BOS optimized for the V–PTC system

• Four PTC control points in the form of remotely monitored and controlled 

powered switches

• Three locomotives equipped with PTC locomotive segment equipment 

(from V–PTC)

• Three WIUs comprised of Ansaldo STS MicroLok II object controllers

• Six MeteorComm MCC 6100 software definable radios (SDRs) used for PTC 

communications between WIUs, locomotives, and a base station

• One GPS-based track database for the RTT and other selected track segments

The PTC Test Bed is in the process of being upgraded so that additional PTC testing 

configurations can be supported. When the upgrades are completed (end of first quarter 2011), 

the following features will have been added to the PTC Test Bed:
27

• A Wabtec Train Management and Dispatch (TMDSTM) CAD system 

and V/ETMS®* BOS

• Two locomotives equipped with Wabtec V/ETMS onboard systems 

• Six 12,000-foot (~21⁄4-mile) signal blocks with 4-aspect block signaling 

that is PTC capable

• GE WIUs for signal block and control point ITC-compliant communications

• Twelve MeteorComm MCC 6200 radios communicating at 220 MHz

* Note that when the term “V/ETMS” is used in this document, it refers collectively to the VETMS® PTC system and the ETMS® PTC system, both of which are registered trademarks of 

Wabtec Corporation.

Radio Laboratory Facilities

The radio laboratory at TTC (Figure 11) is equipped to support testing of individual radios or 

networks of radios. It can be operated as an independent facility for testing the performance and 

limitations of railroad data radios within a highly controlled and reproducible environment. The 

TTC radio laboratory features:

• Capability to support testing of radio networks of 50+ radios

• Low noise uninterruptable DC power

• Access to rooftop antennas for combination laboratory/field testing

• Access to GPS 

• Stratum 1 time synchronization

• Noise and interference injection capabilities for evaluation of physical 

layer performance

• Link access protocol performance testing capabilities

• Network infrastructure isolated from TTCI business network

• Remote test monitoring and data acquisition 

Figure 11. Radio Laboratory at TTC
28

5.2.2 Configurable Test Bed Elements

Train Simulator

The Train Simulator software component is used to mimic the operation of either a PTC or non 

PTC-equipped train operating over real or simulated PTC territory. It allows simultaneous 

operation of simulated trains and real trains on the test bed track. It is comprised of a train 

motion simulator, PTC logic implementation, and several data communications interfaces. The 

Train Simulator is used to provide realistic simulated train movements within the test scenario 

and to generate the appropriate PTC messages to accompany that train motion. In addition, the 

Train Simulator can be configured to generate exception conditions, such as undesired 

emergencies, communications equipment failures, logical PTC messaging failures, and the 

failure to the train crew to respond to PTC messages appropriately. The Train Simulator is 

designed to be used to model theoretical as well as realistic PTC usage scenarios over PTCequipped territory, non PTC-equipped territory, or even nonexistent territory to explore the likely 

or possible operational characteristics of the PTC system under test during normal and abnormal 

operating situations.

The Train Simulator communicates with the Environment Controller, the data collection system,

and the simulation definition database. The Environment Controller provides remote 

configuration, control, and monitoring functionality. The data collection system provides the 

ability to log operational parameters for later analysis. The simulation database provides data to 

the Train Simulator, which defines the characteristics of the train being simulated, the territory 

over which that train operates, and the operational rules for operating that train (speed limits, 

authority boundaries, operational movements, etc.).

Both the PTC implementation logic and the data communications interface are implemented in a 

way that allows them to be configured or developed to quickly alter the PTC operation of the 

train simulator. This allows for comparative analysis of several PTC systems using a specific 

data communications infrastructure, or for comparison of various PTC implementations over a 

single data communications infrastructure.

The Train Simulator is intended to replace or supplement the use of PTC equipped trains within 

the PTC Test Bed. There are a number of reasons for this. Primarily, it allows for testing 

scenarios that are deemed to be unsafe using only physical equipment. For instance, it might be 

desirable to test PTC enforcement with a case where multiple trains are operating in close

proximity on the RTT. However, this would be in contravention to the operating and safety rules 

in place at TTC. Therefore, the number of trains that are seen to be operating on the track by the 

PTC implementation could be augmented safely and/or more cost-effectively by using the Train 

Simulator.

In addition, the Train Simulator can be used as part of a test of PTC operation over track that 

either does not exist or is not currently equipped for PTC operation. In this case, the Train 

Simulator provides the ability to conduct “what if” testing in advance of actually installing PTC 

hardware and testing the boundary conditions of a particular PTC implementation safely.

Finally, the Train Simulator provides a low cost alternative for doing comparative analyses of 

either PTC implementations or data communications infrastructures. Due to the modular nature 

of the software, either the PTC logic or the data communications interface can be replaced much 

more easily and cost-effectively. It is possible to test different PTC implementations using the 
29

same data communications equipment over a given territory or different communications 

infrastructures using the same PTC implementation over the same territory. It allows for a form 

of implementation optimization before costly hardware and software is sourced.

Network Traffic Generator

The Network Traffic Generator software component is designed as a tool to generate message

traffic across many different data communications networks. It can be used as either a tool to 

provide simplified network traffic flow for capacity analysis or to generate network “background 

message traffic” during a more detailed testing scenario.

When used to provide capacity analysis, the Network Traffic Generator can be configured to 

send a number of independently controlled message profiles, which may send messages to any 

number of other instances of the Network Traffic Generator over any number of known and 

defined data network interfaces. Messages received from other instances can also be used as 

triggering mechanisms to initiate message transmission (message spawning). In this mode, the 

message transmission and reception times are logged into the data collection system to allow for 

later analysis of metrics such as message latency distributions and message loss rates.

As a background message traffic generation tool, the Network Traffic Generator is used to 

generate message traffic associated with systems outside of the PTC system under test, such as 

signaling and CAD systems or additional PTC nodes that are not physically present. In this 

scenario, the Network Traffic Generator is simply used as a tool to decrease the available data 

message throughput for the network under test. In this case, the message statistics may or may 

not be logged, depending upon their degree of usefulness in statistical analysis.

The message profiles within the Network Traffic Generator allow for the specification of 

message size, number of instances, priority, and distribution of message transmission times. 

Currently, message distributions may be defined as deterministic (e.g., scripted), uniform within 

a given time period, Gaussian, or Poisson. The message distributions may be altered as the test 

progresses. Also, the message distribution types can be expanded as additional needs are 

indentified.

When used in high-level capacity testing, the Network Traffic Generator is designed to replace 

any single component of a PTC System. In this mode, the purpose of the test is to analyze the 

data traffic flow within the system, without the need to implement all the details of the actual 

component. For instance, the Network Traffic Generator can be used to mimic the expected 

network communications traffic for a PTC office server, without the need to implement all the 

logic associated with the office server itself. This allows for quicker high level testing of data 

communications equipment tailored to the specific needs of a particular PTC implementation. 

The expected data message profiles are provided by an external tool, such as TTCI’s RTC postprocessor application, and then translated into a format suitable for the Network Traffic 

Generator. TTCI has implemented a translator for converting RTC post-processor output into 

the necessary input format for the message generators.

In the second intended mode of operation, the Network Traffic Generator is designed to replace 

non PTC communications equipment such as code line replacement devices, CAD system 

interfaces, and other data communications equipment that may reduce the network throughput 

available to the PTC System components under test. In this mode of operation, the Network 
30

Traffic Generator is not strictly a component of the actual test; it is more of a support component 

used to generate a more realistic and accurate test environment.

WIU Simulator

The WIU Simulator mimics the operation of a control point, intermediate signal, or turnout WIU 

within a PTC implementation and also provides the functionality to integrate real and simulated 

trains within the Test Bed. The WIU Simulator includes functionality to interface with physical 

track circuits, train presence detection components, PTC communications logic, and the 

Environment Controller. The WIU simulator has three main modes of operation, which make 

use of a subset of the various components:

• Simulated trains operating within physical PTC territory with physical control 

points installed

• Real and/or simulated trains operating over physical PTC territory without physical 

control points installed 

• Simulated trains operating within theoretical PTC territory

In the first scenario, the WIU simulator interfaces with the physical signaling hardware to show 

track occupancy for the simulated train as necessary. In the second scenario, the WIU simulator 

implements the PTC control logic to determine the correct control point state and monitors the 

physical track to determine whether a physical train exists within its defined track circuit 

boundaries, as well as receiving information regarding the location of simulated trains. In the 

final scenario, the WIU simulator receives information regarding the location of simulated trains 

and determines the state of the control point from that information alone.

The WIU simulator includes an interface to the Environment Controller for remote 

configuration, command, and control. In addition, the WIU simulator receives the location of all 

simulated trains from the Environment Controller.

The WIU Simulator is intended to be used to augment or replace physical WIUs within a PTC 

test scenario for a number of reasons. The following are some examples that demonstrate how 

the WIU may be used:

• High-density control point testing on the RTT. It may be desirable to construct a test 

scenario that includes more control points than the RTT can support without significant 

track work or that TTCI has the physical hardware for. In this case, the WIU simulator 

can be used to increase the number of control points without additional installation time 

or expense. The WIU simulator would use low cost train presence detection to determine 

whether there was a physical train within its boundaries. It would also use PTC control 

and communications logic to communicate with other components of the PTC 

implementation under test.

• Integration of simulated trains into the physical PTC Test Bed. When simulated trains 

are used in conjunction with physical trains and control points, there needs to be some 

way to simulate their presence to the installed control points. In this case, the WIU 

simulator would use computer controlled relays to interface with the existing control 

point circuitry to simulate occupancy for the simulated train.

• Purely simulated PTC territory. In this scenario, there are no physical control points or 

trains present during testing. The WIU simulator would be used in place of all physical 

control points and would need to interface with the other components of the PTC 
31

implementation under test. This allows the Test Bed to be used to simulate PTC 

operations over territory that either does not exist or is not equipped with any PTC 

equipment.

RTC Model and Post-processor

TTCI has developed a unique system for simulating PTC operations in large scale railroad 

operating scenarios, particularly for use in determining communications loading and other 

requirements. Railroad operations are simulated using the nation’s most widely used network 

simulator, RTC. A custom post-processor developed by TTCI accepts RTC output files and 

generates a traffic profile of all messages communicated over data links versus simulation 

periods of up to six weeks. Another TTCI software application imports these traffic profile files 

into the message traffic generators used for stimulating actual radios under test. Figure 12

depicts TTCI’s overall simulation process.

Figure 12. TTCI’s Overall Simulation Process

5.2.3 Test Support Elements

Data Collection 

The data collection and analysis system is used to store and analyze any and all data generated 

within the other PTC software components. The data collection system is implemented as an 

Oracle 9i database located on a dedicated server. Data may be collected either as testing is 

progressing or imported into the data collection after the test is completed using defined import 

routines and file formats. 
32

The data analysis portion of the data collection system has been developed using the 

Microsoft.NET framework and is used to provide statistical analysis of the data collected during 

testing. The data analysis component is extensible and can be enhanced to meet the specific 

requirements of the testing of any particular PTC implementation or scenario.

Simulation Environment Database 

The Simulation Environment Database contains the definition needed for any train and WIU 

simulators used for a particular test. This includes track definition, train and vehicle profiles, 

operating routes and rules, and the location and boundaries of any WIU simulators. The 

Simulation Environment Database is also implemented using Microsoft SQL Server and is 

located on a server connected to the Test Bed control network. 

Test Software Environment Controller

The Test Software Environment Controller application has been developed to provide a central 

point to monitor and control each of the simulator instances used within a given test scenario. It 

is capable of distributing the configuration information to each software instance, coordinating 

the operation of each component and monitoring the status and health of each component.

The Test Software Environment Controller has been developed using the Microsoft .NET 

Framework and the C# language. It includes custom developed display and control components 

for each of the simulators within the Test Bed simulator suite. The number of software 

components that the Environment Controller can control is only limited by the available network 

and computer resources to the application. The Environment Controller application is installed 

on a dedicated computer connected to the Test Bed control network and is available for use both 

locally and remotely, allowing the progress of the test scenario to be monitored from any 

location that is able to connect through the TTCI corporate network.

Automated Test Script Generators/Test Designer

The Test Designer application has been developed to allow for the rapid design and 

configuration of testing scenarios. It has been developed using the Microsoft.NET framework 

and the C# language. The Test Designer includes a graphical user interface with typical 

Windows features such as drag and drop and copy and paste. It has been designed to allow the 

user to build up the configuration of test components without needing to understand the 

underlying test configuration file and database formats. In addition, the Test Designer includes 

the ability to import simulation data from an external application such as the RTC simulation 

model and post-processor. This data is then used as the basis for component configuration. This 

import facility is extensible, which allows for additional import routines to be developed and 

used based on customer or test scenario requirements. The Test Designer outputs scripting 

elements used by either the Environment Controller or the individual software simulation 

components.

5.3 PTC Test Bed Architecture

Figure 13 shows the PTC Test Bed architecture. The fixed and configurable test bed elements 

and the test support elements are connected by various communication networks. Locomotives 

and WIUs use RF communications links while all the configurable elements use local area 

network (LAN) connectivity. For the V–PTC system, the locomotives and WIUs use

MeteorComm MCC6100 radios to send their data reports to the V–PTC BOS via the base station 
33

located in Communications Bungalow #1 in the Facility for Accelerated Service Testing area at 

TTC. In turn, the BOS relays appropriate data to the CAD system over a fiber optic LAN link. 

An interesting characteristic of this architecture is that communication interfaces directly with 

the BOS are via Ethernet. As a result, the BOS responds to data from simulated system 

components (simulated locomotives and WIUs) the same way it responds to “real” system 

components (actual locomotives and WIUs). Consequently, simulators can be used to increase 

the number of apparent units under test and determine a system’s ability to handle higher 

capacity requirements. This approach significantly reduces the costs associated with PTC 

system capacity testing.

Figure 13. PTC Test Bed Architecture

5.4 2009 PTC Test Bed Upgrades

In 2008, it was determined that a siding on the RTT was needed to support V–PTC meet-andpass testing and for other TTC test support purposes. A siding was installed in TTC’s core area 

between Post 85 and Post 100 (see Figure 9). The siding and its associated equipment (powered 

switches, track signal circuits, relays, etc.) were installed in 2009. Figure 14 shows the relative 

positions of the siding turnouts and the locations of dwarf signal lights, which are used as switch 

point indicator lights. .
34

At each end of the siding, a powered switch was installed with its controls located in an adjacent 

bungalow. Also, both hand-operated switches located at the crossover between the RTT to the 

TTT were replaced with powered switches. Four powered switches and two additional manual 

switches are monitored in nearby equipment bungalows by object controllers. In the case of the 

powered switches, the object controllers have the functionality to not only monitor the position 

of the switches, but to also control the switch position when the system is set up in V–PTC

mode. In this mode of operation, the object controllers monitor switch positions, as well as the 

aspect of the switch indicator lights and the state of occupancy of the track (from the fouling 

boundary at one end to the boundary at the other end). 

A pre-existing 8 × 10-foot Sermi aluminum bungalow was used to house the controls and 

electronics necessary for the powered switch and switch position indicator lighting at the north 

end (Post 100) of the RTT siding. At the south end of the siding, a new 10 × 10-foot Sermi 

aluminum bungalow (henceforth referred to as the 602 Bungalow) was installed. Figure 15 is a

picture of the 602 Bungalow. New equipment installed in the bungalow included batteries and 

battery charger, vital relays, on station circuit electronics, lightning arrestors, Ansaldo STS

Microlok II object controllers (used as WIUs), and a MeteorComm MCC 6100 radio.

Figure 15. 602 Bungalow at RTT Siding Turnout

Figure 14. Siding Turnout Positions
35

5.5 PTC Test Bed Upgrades Documentation

A documentation package was created for the PTC Test Bed upgrades to add to TTC’s facility 

documentation records. The documentation package included AutoCAD drawings for 

equipment installation and wiring interconnect diagrams as well as equipment description 

packages. The equipment installation drawings depicted the physical dimensions, location, and 

individual component layout within each of the three equipment bungalows affected by the 

upgrade: (1) the 602 Bungalow, (2) the Post 100 Bungalow, and (3) the Instrumentation Case #

1 Bungalow, which is a small bungalow used for housing track signals equipment. Text-based 

wiring lists developed during the point-to-point interconnection of individual track signal 

components were used to generate physical wiring interconnect drawings for each component. 

Equipment description packages included vendor-provided documentation for each individual 

upgrade component.
36

6. V–PTC System Testing and Results

During development of the V–PTC system, tests were conducted at TTC using the resources of 

the PTC Test Bed. Testing occurred at the end of major build cycles, and the test results were 

reported to the V–PTC technical advisory group. Detailed test reports for each build were 

produced by LMC.1,2,3,4,5 With permission from LMC, portions of each of the following sections 

on test results are either summarized or directly extracted from LMC reports.

6.1 Build 1 Testing—Train Location Monitoring

Testing for Build 1 occurred in March, April, and June of 2008. Since the capabilities developed 

in Build 1 were associated with train location monitoring, the goals of Build 1 testing were (1) to 

perform on-track testing of the LDS as it relates to position accuracy, speed accuracy, and route 

determination per the V–PTC SRS Build 1 performance requirements, and (2) to exercise Build 

1 functional requirements and tests related to train location reporting and data logging. To 

accomplish these goals, LMC published a test plan,

9 which included the following types of 

testing:

• Locomotive position and speed tests on the RTT 

• Direction and movement tests on the RTT 

• Route determination tests (through switches and the Balloon Loop)

• Slide tests (wheel traction loss while braking) on a section of the RTT

• Slip tests (wheel traction loss during acceleration) on a section of the RTT

• GPS multipath tests on the RTT

6.1.1 Position and Speed Testing

Tests for determining position and speed accuracy were conducted at speeds of 10, 40, and 75 

mph and at variable speeds (5–90 mph). Lap directions around the RTT were in clockwise (CW)

and counterclockwise (CCW) directions, and testing included test configurations with high GPS 

visibility and with inhibited system GPS inputs (see Figure 16). There were a total of 16 test 

cases during this portion of testing.
37

Figure 16. Areas of Induced GPS Gaps on RTT

6.1.2 Direction and Movement Testing

Tests for verifying accurate location reports were conducted on a limited section of RTT at 10 

mph. During the tests, the locomotive (1) moved forward 1,000 ft from its initial position, (2) 

stopped, (3) went back 500 ft, (4) stopped, (5) moved forward another 1,000 ft, and finally, (6) 

went back 500 ft again. Then, this cycle of six steps was repeated a number of times. During 

these test cycles, the locomotive engineer performed a combination of normal stops and lurch 

(abrupt) stops. These cycles included some cycles with high GPS visibility and some with 

inhibited system GPS inputs. There were 34 test cases.

6.1.3 Route Determination Testing

Route determination testing was conducted to verify the LDS was accurately determining routes

taken through switches. For this testing, some test runs were accomplished with the locomotive 

moving through RTT switches at 1, 5, 10, and 20 mph, and some runs were conducted on the 

Balloon Loop. For the runs through the switches, movements were in both CW and CCW

directions of travel. These runs evaluated the system’s ability to correctly track movements of

both normal and diverging routes through the switches. Some runs were with high GPS visibility 

and some were with inhibited GPS performance. During the test runs, the V–PTC BOS was 

monitored in real time to verify that proper location reports were being received. There were 

192 test cases.
38

For the test runs around the Balloon Loop, the locomotive traveled around the loop at 20 mph. 

For the two test cases, one traveled CW and the other traveled CCW. 

6.1.4 Slide Testing

Slide testing was conducted to assess LDS location determination performance in the event of

wheel slide while braking. Tests occurred along a 1,000-foot portion of the RTT. Liquid 

detergent was applied to the top of the rails on ~100-foot section of track directly preceding the 

planned stopping point (see Figure 17). The locomotive traveled over the test section at 10 mph, 

and then attempted to stop at or slightly after the end of the 100-foot soaped section. Four test 

cases were performed with both high and inhibited GPS visibility.

Figure 17. Soap Applied on Top of Rails

6.1.5 Slip Testing

Slip testing was intended to assess LDS location determination performance in the event of

wheel slip during acceleration. As with slide testing, test runs occurred on a 1,000-foot portion 

of RTT where liquid soap had been applied to the top of the rails for the first 100 ft of the test 

section. However, in this case, liquid soap was also applied to the locomotive’s wheels just 

before the start of each run. Then, the locomotive accelerated to 10 mph amid wheel slip, 

traversed the test section, and attempted to stop at or slightly after the end of the 1,000-foot

soaped section. Testing included one test with high GPS visibility and one test with inhibited 

system GPS inputs.

6.2 Build 1 Test Results

Detailed Build 1 test results are in LMC’s Build 1 Test Report.1

 An overview summary of the 

results, some of which are extractions from the report, are presented (with permission) in this 

section.
39

6.2.1 Position and Speed Testing

The intent of the position and speed testing was to determine how accurately the LCU places the 

locomotive along the track under various speeds, accelerations and decelerations, and GPS 

visibility conditions. In addition, speed accuracy is assessed using the same data sets. 

Two V–PTC system performance requirements from SRS Section 8.1 are addressed:

• The V–PTC system shall determine the position of the leading end of the V–PTC

controlling locomotive along the track with an accuracy of ≤ 15 ft, at a confidence level 

of 99 percent.

• The V–PTC system shall determine the speed of the train along the track with an 

accuracy of ≤0.5 mph, at a confidence level of 99 percent.

Locomotive Position Location Offset Results - Full GPS Coverage

A total of 16 RTT loop tests were conducted (216 miles), eight traveling CW and eight traveling

CCW. In on-track tests, half of the 16 RTT Loop tests were conducted with continuous GPS 

outages ranging from 1,000 to 8,000 ft in distance. Figure 18 shows a summary of the results.

Figure 18. Position Location Errors - Full GPS

The average offset error is 0.68 ft and the standard deviation is 4.21 ft. The 99 percent value is 

10.8 ft, using over 385 data samples. The requirement is 15 ft at 99 percent. The maximum 

outlier is 14.99 ft. An inspection of the location reports indicated that they were generated 

correctly.

Locomotive Position Location Offset Results - Inhibited GPS Coverage 

Figure 19 shows the results of the same analysis, being performed with GPS RF signal switched 

out of the LCU input between the flags listed above. The average offset error is -0.14 ft, using 

RTT Along Track Position Error Histogram 

with Full GPS

0

5

10

15

20

25

30

35

40

45

-20-18-16-14-12-10-8-6-4-202468101214161820

Along Track Error (ft)

Frequency

Frequency Ave Error: 0.68 ft

Std Dev: 4.21 ft

99% Error: 10.8 ft

Max Outlier:14.99 ft

Sample size: 385
40

over 403 samples, and the 99 percent value is 12.1 ft. The maximum outlier value is 17.1 ft. 

Location reports were generated correctly.

Figure 19. Location Errors – Inhibited GPS

Speed Accuracy Results—Full GPS Coverage

Figure 20 illustrates speed accuracy for the eight RTT runs with GPS enabled. The average error 

is -0.03 mph, and the computed 99 percent value is 0.54 mph. The requirement is 0.5 mph 

(99 percent). The maximum speed error computed is 0.485 mph, indicating that the computed 

99 percent value is too conservative in this case, due to the slightly right skewed distribution of 

errors.

RTT Along Track Position Error Histogram with GPS Gaps

(Gaps at :R12-R17, R20-R21, R41-R47, R56-R64)

0

5

10

15

20

25

30

35

40

45

-20-18-16-14-12-10-8-6-4-2024681012151719

Along Track Error (ft)

Frequency

Frequency Ave Error: -0.14 ft

Std Dev: 4.72 ft

99% Error: 12.1 ft

Max Outlier:17.1 ft

Sample size: 403
41

Figure 20. Locomotive Speed Errors – Full GPS

Speed Accuracy Results—Inhibited GPS Coverage

Figure 21 shows the results of locomotive speed errors with inhibited GPS coverage. GPS 

tracking was disabled continuously and at all times through the speed trap (R12-R17), just over 

5,000 ft in length. The average error in speed is 0.001 mph, and the 99 percent value is 

0.500 mph. This is slightly better than with continuous GPS tracking. The maximum speed 

error noted is 0.487 mph, slightly greater than with GPS tracking enabled (0.485 mph). The 

differences are statistically insignificant.

RTT Along Track Speed Error Histogram 

With GPS Tracking

0

1000

2000

3000

4000

5000

6000

-0.6-0.52-0.45-0.37-0.3-0.22-0.15-0.0700.070.150.220.30.370.450.520.6

mph error

Frequency

Ave Error: -0.03 mph

Std Dev: 0.214 mph

99% Error: 0.54 mph

Max Outlier: 0.485 mph

Sample size: 63,000
42

Figure 21. Loco Speed Errors – Inhibited GPS

6.2.2 Direction and Movement Testing

The intent of the direction and movement tests was to evaluate the ability of the LCU to keep 

track of direction and movement under a long series of direction changes. Direction and 

movement testing was conducted between R12 and R17 on a tangent section of the RTT. This 

testing consisted of moving the locomotive at 10 mph between R12 and R17 in a 1,000-foot 

forward, 500-foot back, 1,000-foot forward repetitive motion until the R17 marker was reached. 

There were 17 separate movements with normal stops and 17 movements with lurch (abrupt) 

stops. Two data sets were generated that spanned R12-R17 travel, one for normal stops and the 

other for lurch stops. The normal stop maneuvers spanned about 1,750 seconds, and the lurch 

stop maneuvers spanned about 1,840 seconds. All stop and start movements were detected 

correctly, as reported in the train location reports.

Direction and Movement with GPS

Figure 22 illustrates the along track offset error for the 34 individual movements (lurch and 

normal stops) combined. The average error is -0.9 ft. There are 84 data points evaluated. The 

maximum error noted was -5.58 ft. The standard deviation is 2.35 ft. The 99 percent value is 

6.04 ft.

RTT Along Track Speed Error Histogram 

Without GPS Tracking

0

2000

4000

6000

8000

10000

12000

-0.6-0.52-0.45-0.37-0.3-0.22-0.15-0.0700.070.150.220.30.370.450.520.6

mph error

Frequency

Ave Error: 0.001 mph

Std Dev: 0.194 mph

99% Error: 0.50 mph

Max Outlier: 0.487 mph

Sample size: 63,000
43

Figure 22. Direction and Movement Errors with GPS

Direction and Movement without GPS

On the basis of the 166 data samples, the average offset error is 1.87 ft, and the standard 

deviation is 6.19 ft. The standard deviation was at first too high to generate meaningful 99

percent statistics from this dataset. Bootstrapping was again used to resample the data 380 times. 

The recomputed standard deviation is also 6.19, and the 99 percent value is 15.9 ft. The 

maximum offset error is 19.42 ft. This sample and the one at 16.9 ft were the only two points 

that exceeded the specification out of the original 166 data samples. Within the data span of 

~1,800 seconds, the percentage of time without GPS tracking is ~85 percent. Train location 

reports were generated correctly in all movements.

6.2.3 Route Determination Testing

The intent of this test was to measure the ability of the LCU to autonomously determine which 

path is taken through the switch, without having knowledge of the switch position from external 

sources. This LCU was field tested in full GPS and complete GPS outage configurations. Six 

switches were included in the route determination tests. They are Switch 304, Switch 303, 

Switch 301, Switch 801, Switch 602B, and Switch 501. Each route determination test consisted

of running through the switch at speeds of 1.5, 5, 10 mph and (except for Switch 303) 20 mph, in 

both directions, in both normal and diverging configurations, for a total of 32 path tests for each 

switch. For No. 20 switches like Switch 602B, the time it took to travel from the facing point 

fouling limit to the normal or diverging clearance points was in the 180-second range. Each test 

was conducted with full GPS visibility and with GPS signals inhibited (RF switch controlled). 

For GPS gap tests, anytime the locomotive was between the facing point fouling limit and 

normal or diverging clearance point, GPS was inhibited via RF switch. A total of 188 separate 

path tests were conducted. 

RTT Along Track Position Error Histogram - Direction 

and Movement with GPS

(17 normal and 17 Lurch Stops)

0

2

4

6

8

10

12

14

16

18

-20-18-16-14-12-10-8-6-4-202468101214161820

Along Track Error ft

Frequency

Frequency Ave Error: -0.9 ft

Std Dev: 2.35 ft

99% Error: 6.04 ft

Max Outlier: 5.58 ft

Sample size: 84
44

In addition to switch path determination testing, a special Balloon Loop test was also performed.

The Balloon Loop was traversed in both the CW and CCW directions at 20 mph and track 

selection was monitored. Switch 303 cannot be taken at 20 mph, so testing was performed at 1.5, 

5, and 10 mph. The test laptop, mounted in the cab and running LDS monitor software, was

watched to ensure that the partition identification changed appropriately when the locomotive 

took a switch in a diverging direction. 

Switch Tests with GPS Tracking Enabled

Results (using the software deployed during the actual testing on the locomotive) indicate that all

switch paths were correctly identified with GPS enabled. 

Switch Tests with GPS Tracking Inhibited

With GPS disabled between the clearance points and fouling limits, a first attempt error was 

noted at Switch 801 diverging at 1.5 mph traveling forward. The second on-track attempt was 

successful. This also occurred at the Switch 602 at 1.5 mph during the diverging move traveling

forward. The second on-track attempt was also successful. Out of 188 tests, two were failures, 

for an initial 98.93 percent success rate.

Balloon Loop Test with GPS Tracking Enabled

For this test, locomotive travel started just north of Switch 301 position with short hood forward, 

traveling CW around the loop until the start point was reached with the rear of the locomotive. 

Then the trip was taken long hood forward, retracing the path CCW. All movements were at 20 

mph. The degree of curvature at the bottom of the loop is 7.6 degrees per 100 ft. Total loop 

length is 8,200 ft.

Balloon Loop Test with GPS Tracking Inhibited on Loop

In this analysis, GPS tracking was inhibited at all times when actually traveling around the loop. 

Note that in the short hood forward direction the error builds up without GPS quite rapidly, until 

GPS is enabled at the Switch 301 to Switch 801 area, peaking at -131 ft. On the return (long 

hood forward) trip, the error buildup was ~0.166 what it was in the short hood forward direction. 

The loop is ~8,200 ft in length along the track centerline. The rate of along track error growth 

without GPS in the short hood forward direction is 0.0159 ft error per ft traveled. In the long 

hood forward direction, the error accumulated at a rate of 0.00268 ft per ft traveled.

6.2.4 Slide Testing on the RTT

The intent of slide testing was to evaluate the location performance of the LCU in the presence 

of sustained wheel slide, because wheel tachometer data is one of the sensor inputs the LCU uses 

for location determination on the rail network. Slide testing was conducted between R12 and 

R13. Water was sprayed on the track just in front of the locomotive as it passed by. The 

locomotive’s automatic sander was disabled. In slide testing, the intent was to measure the LCU

computed offset at the surveyed flags at R12, R12+500, and R13, and compare these values with 

known separations. Figure 23 is a graphic that depicts the results. The data from these tests

indicates the offset errors measured between R12 and R13 are well within the 15 ft requirement.
45

Figure 23. Slide Testing Results

6.2.5 Slip Testing on the RTT

The purpose of slip testing was to evaluate the location performance of the LCU in the presence 

of sustained wheel slip. The data analyzed from the June 2008 testing does not indicate that 

wheel slip was ever developed. Data taken from slip attempts indicate good slip was generated. 

The two flags are 1,000 ft apart, but the tachometer input based distance is 1,119 ft, resulting in a 

119-foot error if tachometer was used without the benefit of GPS tracking. The small and large 

slips can clearly be seen in Figure 24, reaching a peak rate of ~35 ft/s (23 mph) while traversing 

across the slippery section of track during acceleration from a stop. The nominal speed peak 

(without slip) is reached midway through the data set, ~23 mph, consistent with the actual speed 

from the test plan.

Slide Error Analysis on RTT

RTT Travel 

(clockwise)

GPS Conditions - No GPS Satellites Tracked 20 seconds prior to start of motion at R12

R13

R12

1000 ft

Soap Film

Slide 1 Start

Stop

braking

Integrated Tach Pulse Distance = 864 ft

Known Linear distance (survey) = 1001 ft

LDS II Error at R13 = 9 ft

R12

R13

Loco Accelerated to 10 mph from dead

Stop at R12, then brought to stop 13” in past R13

R12500

Requirement is met

 
46

Figure 24. Wheel Rate during Slip Testing

6.3 Build 2 Testing – Server Switch Monitoring

The goal of Build 2 testing was to evaluate how well the V–PTC BOS Switch Monitoring 

functionality complied with the requirements identified in V–PTC SRS, Revision 1. June 2008 

testing included the following specific test events:

• Test 2 Events

▬ Display software version at the system management console

▬ Correct date/time synchronization with coordinated universal time (UTC)

▬ Password control of the system management console

• Test 4 Events

▬ Verify wayside software revision level is compatible

▬ Retry communications after initialization failure (negative communications)

▬ Retry communications after communications outage (lost and regained 

communications)

▬ Software revision level incompatibility aborts wayside device

• Test 5 Events

▬ Subdivision and operational synchronization and status of wayside devices

▬ Time synchronization of V–PTC BOS and wayside devices

• Test 6 Events

▬ Monitoring the power-operated switch states and occupancy

▬ Monitoring of hand-operated switch status

▬ Configurable reporting rate of wayside devices

• Test 7 Event

▬ Logging message communications

Wheel Rate (ft/sec) based on Tach Input 

0

5

10

15

20

25

30

35

40

502448502452502456502460502464502468502472502476502480502484502488502492502496502500502504502508502512502516502520

GPS Time (sec)

Track Speed (ft/sec)
47

To support conducting the Build 2 test events, TTCI implemented two switch simulations, one 

hand-operated and one power operated, in an onsite laboratory at TTC. Two object controllers 

were programmed and configured as planned for testing. One object controller was configured 

as a hand-operated switch and represented Switch 301 on the TTC test track. The Switch 301 

object controller was connected to a switch emulation box that provided switch open and closed 

status. The other object controller was configured as a power-operated switch with an 

overswitch track circuit. 

This configuration represented Switch 602B. This object controller was directly connected to a 

fully functional power-operated switch and switch emulation box that provided overswitch 

occupancy status. Both object controllers were programmed to support initialization and switch 

status messaging to the V–PTC BOS. The hand-operated switch configuration provided both 

Normal and Unknown switch states, while the powered switch configuration provided Normal, 

Unknown, Reverse, Track Circuit Unoccupied, Track Circuit Occupied, Local, and Remote 

Control switch states and status.

6.4 Build 2 Test Results

Detailed descriptions of the Build 2 test results are contained in LMC’s Build 2 Test Report.2

 A 

summary of the report’s content appears below.

All but one test passed during three days of testing. A Problem Report (PR-15) was written to 

address this problem. Table 1 summarizes the results of all testing performed.
48

Table 1. Build 2 Tests and Results

Test 

ID

Test 

Number

System 

Specification

Paragraph

Procedure Name Pass/

Fail

1 Test 2 5.5.1 V–PTC Displays Software Version at the System Management Console P

2 Test 2 5.12 V–PTC Date/Time Synchronization with UTC P

3 Test 2 10.1 V–PTC Password Control of the System Management Console P

4 Test 4 5.1.3.1 Verify Wayside Software Revision Level is Compatible P

5 Test 4 5.1.3.1 Retry Communications for Software Revision After Initialization 

Failure (Negative Communications)

P

12 Test 4 5.1.3.1 Retry Communications for Software Revision After Communications 

Outage (Lost and Regained Communications)

P

13 Test 4 5.1.3.1 Software Revision Level Incompatibility Aborts Wayside Device (Also 

verified—Wayside Software Includes Version Identifier; Wayside 

Software Version Displays at System Management Console; Normal 

Operations for Successful Wayside Software Revision Check

F

6 Test 5 5.1.1.3 Subdivision and Operational Synchronization and Status of Wayside 

Devices

P

7 Test 5 8.2.C Time Synchronization of V–PTC Server and Wayside Devices P

8 Test 6 4.5.1 Monitoring the Power-Operated Switch States and Occupancy P

9 Test 6 4.5.1 Monitoring of Hand-Operated Switch Status P

10 Test 6 4.5.1 Configurable Reporting Rate of Wayside Devices P

11 Test 7 5.6 Logging Communications P

In summary, 12 of 13 tests completely passed during the formal test period. The failure in Test 

ID 5 took place on one section of the test resulting in the V–PTC BOS not initializing the 

wayside device, but at the same time not failing the device as required. All other tests passed 

without any errors. 
49

6.5 Build 3 Testing – Switch Warnings and Control

Build 3 testing occurred in October of 2008. The goals of Build 3 testing were to:

• Perform on-track testing of the V–PTC system’s onboard Train Borne capabilities per the 

V–PTC SRS Build 3 SRS.

• Exercise Build 3 functional requirements and tests related to onboard display of track 

location, switch state, train speed, and date and time; and related to functionality of 

locomotive power-up checks and health monitoring, as well as communications logging.

As a brief summary, Build 3 Test Plan events included the following:

• Onboard display of train location

▬ Display of track configuration within horizon

▬ Display of switch state

▬ Display of train speed

▬ Display of date and time

▬ Configurability of display horizon size

• Locomotive power-up checks

▬ Integrity check

▬ Software version check

• Locomotive health monitoring

• Communications logging

Build 3 testing was conducted on the RTT for all tests that required movement or verification of 

track features displayed on the LDU display. Turnouts onto and return entry to the RTT from the 

Train Dynamics Track, TTT, and the Balloon Loop were also executed. Tests that did not 

require movement were conducted in the yard tracks near the Center Services Building. New 

components for the Build 3 tests included the MCC-6100 radios and the LDU. Figure 25 shows 

the PTC Test Bed communications configuration using components added for Build 3 testing.

Figure 25. TTCI Communications Network

Testing activities were conducted primarily in the cab of Locomotive 2001, either on the RTT or 

in the yard. Figure 26 shows personnel conducting tests in Locomotive 2001.
50

Figure 26. Build 3 Testing on Locomotive 2001

Figure 27 is a graphic depicting the information displayed by the LDU.

Figure 27. Graphic of LDU Display on Locomotive 2001

During testing, a laptop was connected to the onboard LAN to allow for test configuration, test 

support, and test monitoring activities. Additionally, some support activities were accomplished 

from the TTC Operations Building, including saving logs upon completion of a test, creation of 

configuration files needed for the tests, system configuration, and system initialization.

6.6 Build 3 Test Results

Detailed descriptions of the Build 3 test results are contained in LMC’s Build 3 Test Report.2

Table 2 shows a summary of Build 3 test results. Table 3 shows the details of Build 3 test 

results.

Onboard Display 

Current Speed Next Milepost Onboard System Status and Software Versions

Current

Date, Time

Next Switch, its State (if monitored), and Distance Until Approach

Mileposts

Track Configuration within Viewing Horizon

Track Profile

Current 

Location 

of Train
51

Table 2. Overview Summary of Build 3 Test Results

System Test Step Summary Total Steps Percentage

Total Steps Executed – Passed 488 89.5

Total Steps Passed Conditionally 0 0.0

Total Steps Failed 7 1.3

Total Steps Blocked 50 9.2

Total Steps Not Executed 0 0.0

Table 3. Build 3 Tests and Results

Build 3 test results are summarized by test steps performed, test procedures performed, and 

requirements tested. The test step results categories used for the Build 3 tests are defined as 

follows:

• Passed—Step was executed and the expected results were successfully observed

• Passed Conditionally—Step was executed using a workaround or alternative to the stated 

action to successfully observe the expected results

• Failed—Step was executed and the expected results were not observed successfully

System Test Step Totals 0 488 0 7 50 545

LOCO-400: Messaging Logging 10/22/2008 0 9 0 2 11 22 Partial Pass

Test Case 5: Loco Non-Comm Recovery 10/22/2008 0 20 0 0 2 22 Partial Pass

Test Case 3 and 4: S/W Fault Insertion No Build 3 testing – No S/W or Dataset fault insertion with system executing Deferred

Test Case 2: Interface Fault Inserted 10/22/2008 0 16 0 0 5 21 Partial Pass

Test Case 1: Fault Free Environment 10/22/2008 0 25 0 0 0 25 Pass

LOCO-300: On-board Health Monitoring

Test Case 3: Incompatible Version 10/21/2008 0 29 0 1 6 36 Partial Pass

Test Case 2: Interrupt Comms - Version No Build 3 testing - Could not create environment to demonstrate Deferred

Test Case 1: Acceptable Versions 10/21/2008 0 18 0 0 0 18 Pass

LOCO-210: On-board S/W Versions

Test Case 3-3: S/W Fault Insertion 10/21/2008 0 20 0 0 4 24 Partial Pass

Test Case 3-2: S/W Fault Insertion 10/21/2008 0 22 0 0 4 26 Partial Pass

Test Case 3-1: S/W Fault Insertion 10/21/2008 0 17 0 0 4 21 Partial Pass

Test Case 2-1 to 2-5: HW Fault Insertion No Build 3 testing - No H/W failure reporting Deferred

Test Case 1: Fault Free Environment 10/21/2008 0 27 0 0 0 27 Pass

LOCO-200: On-board Power-up Integrity

LOCO-130: AG AI - 40 MPH thru Switch 301 10/21/2008 0 56 0 0 0 56 Pass

LOCO-120: Horizon Size Configuration 10/21/2008 0 101 0 0 0 101 Pass

LOCO-110: On-board Switch Awareness 10/20/2008 0 34 0 1 0 35 Partial Pass

LOCO-100: Track Config & Train Location 10/20/2008 0 94 0 3 14 111 Partial Pass

System Test Procedure Date Executed NE P PC F BL Total Steps Test Status

System Test Step Totals 0 488 0 7 50 545

LOCO-400: Messaging Logging 10/22/2008 0 9 0 2 11 22 Partial Pass

Test Case 5: Loco Non-Comm Recovery 10/22/2008 0 20 0 0 2 22 Partial Pass

Test Case 3 and 4: S/W Fault Insertion No Build 3 testing – No S/W or Dataset fault insertion with system executing Deferred

Test Case 2: Interface Fault Inserted 10/22/2008 0 16 0 0 5 21 Partial Pass

Test Case 1: Fault Free Environment 10/22/2008 0 25 0 0 0 25 Pass

LOCO-300: On-board Health Monitoring

Test Case 3: Incompatible Version 10/21/2008 0 29 0 1 6 36 Partial Pass

Test Case 2: Interrupt Comms - Version No Build 3 testing - Could not create environment to demonstrate Deferred

Test Case 1: Acceptable Versions 10/21/2008 0 18 0 0 0 18 Pass

LOCO-210: On-board S/W Versions

Test Case 3-3: S/W Fault Insertion 10/21/2008 0 20 0 0 4 24 Partial Pass

Test Case 3-2: S/W Fault Insertion 10/21/2008 0 22 0 0 4 26 Partial Pass

Test Case 3-1: S/W Fault Insertion 10/21/2008 0 17 0 0 4 21 Partial Pass

Test Case 2-1 to 2-5: HW Fault Insertion No Build 3 testing - No H/W failure reporting Deferred

Test Case 1: Fault Free Environment 10/21/2008 0 27 0 0 0 27 Pass

LOCO-200: On-board Power-up Integrity

LOCO-130: AG AI - 40 MPH thru Switch 301 10/21/2008 0 56 0 0 0 56 Pass

LOCO-120: Horizon Size Configuration 10/21/2008 0 101 0 0 0 101 Pass

LOCO-110: On-board Switch Awareness 10/20/2008 0 34 0 1 0 35 Partial Pass

LOCO-100: Track Config & Train Location 10/20/2008 0 94 0 3 14 111 Partial Pass

System Test Procedure Date Executed NE P PC F BL Total Steps Test Status
52

• Blocked—The step could not be performed due to either a system problem (PR), a 

functional capability not delivered with the build, test conditions that could not be 

achieved to demonstrate the requirement, or any other conditions that prevented 

execution of the stated actions

• Not Executed—Step was not executed

The pass/fail status of each Build 3 requirement was also analyzed by determining the results of 

each step when a specific requirement was referenced. The status of a requirement was then 

classified into one of the following categories:

• Passed—All steps referencing the requirement passed

• Partial Pass—There was a mixture of passed and either failed or blocked steps 

referencing the requirement

• Failed—All steps referencing the requirement failed

• Blocked—All steps referencing the requirement were blocked

Table 4 is a summary of the requirement totals for each of the above categories.

Table 4. Summary of Requirements Results

Total Requirements

Pass 13

Partial Pass 12

Fail 0

Blocked 11

6.7 Build 4 Testing–Onboard Display of Authority

Build 4 testing occurred in two phases, referred to as Build 4A and Build 4B. Build 4A testing 

occurred in December 2008 and January 2009, and Build 4B testing occurred in April and May

2009.

6.7.1 Build 4A Testing

The goals of Build 4A testing were to:

• Perform on-track testing of the V–PTC system’s ability to command a powered switch 

remotely per the V–PTC SRS, Build 4A performance requirements

• Exercise Build 4A functional requirements and tests related to commanding the switch 

remotely and verifying switch states at the locomotive, the office server, and the object 

controller

• Test commands from the server with the switch in different states: normal, reverse, 

unknown, LCM, and overswitch protection.

An outline summary of the Build 4A Test Plan includes testing of:

• Remote control of switch from office server to demonstrate

▬ Successful control of power-operated switch
53

▬ Object controller’s response to commands from server while in overswitch protection

▬ V–PTC server’s rejection of switch commands

▬ Object controller’s response to commands from server while in local 

control mode

• Communication outages during switch commands

• Communications logging

6.7.2 Build 4A Test Results

Table 5 is an overview summary of the Build 4A test results. 

Table 5. Summary of Executed Test Steps

System Test Step Summary Total Steps Percentage of Total Steps

Total Steps Executed – Passed 1205 98.85

Total Steps Passed Conditionally 0 0.0

Total Steps Failed 3 0.25

Total Steps Blocked 0 0.0

Total Steps Not Executed 11 0.9

Build 4A test results are summarized by test steps performed, test procedures performed, and 

requirements tested. These detailed results of Build 4A testing are recorded in Table 6. The test 

step results categories used across the Build 4A tests are defined as follows:

• Passed—Step was executed and the expected results were successfully observed

• Passed Conditionally—Step was executed using a workaround or alternative to the stated 

action to successfully observe the expected results

• Failed—Step was executed and the expected results were not observed successfully

• Blocked—The step could not be performed due to either a system problem a functional 

capability not delivered with the build, conditions that could not be achieved to 

demonstrate the requirement, or any other conditions that prevented execution of the 

stated actions

• Not Executed—Step was not executed

Note that there are five defined categories of testing:

• Successful control of powered switches

• Overswitch Protection causes Switch Change Command Failures

• V–PTC Server Rejects Switch Change Commands

• LCM causes Switch Change Command Failure

• Communications Outages during Switch Change Commands
54

Table 6. Detailed Build 4A Test Results

System Test Procedure

Date 

Executed P PC NE BL F

Total 

Steps Test Status

SWCNTL-100: Successful 

Control of Powered 

Switches

 Test Case 1 12/18/2008 52 0 0 0 0 52 Pass

 Test Case 2 12/18/2008 49 0 0 0 0 49 Pass

 Test Case 3 12/18/2008 55 0 3 0 1 59 Partial Pass

 Test Case 4 1/23/2009 82 0 0 0 2 84 Partial Pass

SWCNTL-110: Overswitch 

Protection causes Switch 

Change Command Failures

 Test Case 1 1/23/2009 63 0 0 0 0 63 Pass

 Test Case 2 1/23/2009 64 0 0 0 0 64 Pass

 Test Case 3 1/23/2009 67 0 0 0 0 67 Pass

 Test Case 4 1/23/2009 59 0 4 0 0 63 Pass

SWCNTL-120: V–PTC

Server Rejects Switch 

Change Commands

 Test Case 1 1/23/2009 54 0 0 0 0 54 Pass

 Test Case 2 1/23/2009 42 0 0 0 0 42 Pass

 Test Case 3 1/23/2009 54 0 0 0 0 54 Pass

 Test Case 4 1/23/2009 54 0 0 0 0 54 Pass

 Test Case 5 1/23/2009 42 0 0 0 0 42 Pass

 Test Case 6 1/23/2009 54 0 0 0 0 54 Pass

SWCNTL-130: LCM causes 

Switch Change Command 

Failures

 Test Case 1 1/23/2009 67 0 0 0 0 67 Pass

 Test Case 2 1/23/2009 64 0 0 0 0 64 Pass

 Test Case 3 1/23/2009 67 0 0 0 0 67 Pass

 Test Case 4 1/23/2009 66 0 0 0 0 66 Pass

SWCNTL-140: 

Communications Outages 

during Switch Change 

Commands

 Test Case 1 12/18/2008 47 0 0 0 0 47 Pass

 Test Case 2 12/18/2008 56 0 4 0 0 60 Pass

 Test Case 3 12/18/2008 47 0 0 0 0 47 Pass

System Test Step Totals 1205 0 11 0 3
55

6.7.3 Build 4B Testing

The goals of Build 4B testing were to:

• Demonstrate switch control capability by the V–PTC system

• Validate the Build 4 switch control requirements identified in the V–PTC SRS, dated 

October 31, 2008. 

The principal test objectives included evaluating the following V–PTC system 

functionalities:

• Remote control of powered switches from the RailComm CAD system.

• Monitoring of switch positions and state changes from the CAD system including:

▬ Unknown and locked switch positions

▬ Overswitch protection

▬ LCM

• Train location monitoring on the CAD system

• System status updates displayed on the CAD system

The approach to Build 4B testing was to use an integrated CAD/BOS to demonstrate required 

functionalities. A commercially available CAD system from RailComm was interfaced and 

integrated with the V–PTC server by LMC and RailComm. All other system components 

remained the same as had been used for Build 4A test activities. Testing was based on using 

demonstration methods to validate all tested requirements and included the following test 

demonstrations:

• System Synchronization 

▬ V–PTC server/CAD system startup and synchronization

 Starting V–PTC server before CAD

 Starting CAD before V–PTC server

 Communications outages and restarts of each

 Verifying of CAD system software version number

 Error conditions causing interface shutdown and restart 

• Switch Monitoring and Control

▬ Switch monitoring at CAD

 Monitoring of hand-operated switches

 Monitoring of power-operated switches

 Communication outages and restarts of each

▬ Switch control from CAD

 Requesting switch changes from normal to reverse, reverse to normal, 

unknown to reverse and normal, and one position to the same position

 Overswitch protection circuit

 LCM

 Testing timing and lockout conditions

System functionalities associated with location monitoring and system health were tested. 

Location monitoring included CAD system tracking, train initialization and CAD system 

displays, mile post verification on-screen and in messages, and direction of travel on the LDU. 
56

System health included monitoring system health status information sent to CAD system, status 

of object controller communications health, and status of onboard Train Borne communications 

and system health. 

6.7.4 Build 4B Test Results

Detailed descriptions of the Build 4B test results are contained in LMC’s Build 4B Test Report.4

 

The results are summarized in this section of the report.

During the formal test period, 46 out of 50 tests completely passed without errors. This is after 

taking away verification of logging events by the RailComm CAD system. The RailComm 

system has no logging requirements in the V–PTC SRS, and any failures in this area were not 

counted against the overall V–PTC system performance obtained during Build 4B testing. 

Table 7 provides the individual test case results and the statistical data used in developing the 

overall result percentages.

The following is a description of the fields included in Table 7.

• Date executed is the date the test was executed during the formal testing period.

• The column labeled P is the sum of nonrequirement and requirement laden test steps. 

• The column labeled PC stands for passed conditionally. This means the results obtained 

for the test step did not change the overall results of the test case. For example, if the test 

was expecting a TS_DATA state change message as the next message but the wayside 

device had to be reset and after the reset the TS_DATA message was received with the 

expected state then this test step was mark passed conditionally.

• The column labeled NE stands for not executed. This labeled is used for all test steps not 

executed during the test. Reasons include cases in which two outcomes are possible 

depending on the timing of other actions in relationship to external stimulus.

• The column labeled BL stands for blocked. An earlier failure may block the execution of 

later steps. For example, an error causing a message to not be sent will cause a block of 

the acknowledgement message.

• The column labeled F stands for failed. This means the expected result did not happen. 

• The Total Steps column is a sum of test steps in columns P, PC, NE, BL and F for each 

test case. This sum includes both the test case and the post analysis test steps.

The Test Status column is the overall passed/failed test results. A Partial Pass means some 

aspect of the test failed, but the V–PTC system performance was not compromised by the failure. 
57

Table 7. Build 4B Test Case Results

Date 

Executed P PC NE BL F

Total 

Steps

Test 

Status

5/1/2009 31 0 0 0 0 31 Pass

5/1/2009 28 0 0 0 0 28 Pass

5/1/2009 25 0 0 0 1 26

Partial 

Pass

5/1/2009 23 0 0 0 0 23 Pass

5/1/2009 63 0 0 0 0 63 Pass

5/1/2009 58 0 0 0 0 58 Pass

5/1/2009 76 0 0 0 0 76 Pass

5/1/2009 145 0 16 2 4 167

Partial 

Pass

4/30/2009 59 0 0 0 0 59 Pass

4/30/2009 39 0 0 0 0 39 Pass

4/30/2009 84 0 0 0 0 84 Pass

4/30/2009 83 2 0 0 0 85 Pass

5/1/2009 88 0 0 0 0 88 Pass

4/30/2009 76 0 0 0 0 76 Pass

4/30/2009 81 0 0 0 0 81 Pass

5/1/2009 90 0 0 0 0 90 Pass

4/30/2009 65 0 0 0 0 65 Pass

4/30/2009 47 0 0 0 0 47 Pass

5/1/2009 65 0 0 0 0 65 Pass

4/30/2009 65 0 0 0 0 65 Pass

4/30/2009 47 0 0 0 0 47 Pass

5/1/2009 65 0 0 0 0 65 Pass

5/1/2009 74 0 0 0 0 74 Pass

5/1/2009 56 0 0 0 0 56 Pass

5/1/2009 74 0 0 0 0 74 Pass

5/1/2009 74 0 0 0 0 74 Pass

5/1/2009 56 0 0 0 0 56 Pass

5/1/2009 74 0 0 0 0 74 Pass

4/30/2009 71 0 0 0 0 71 Pass

4/30/2009 61 0 0 0 0 61 Pass

5/1/2009 87 0 0 0 0 87 Pass

4/30/2009 84 0 0 0 0 84 Pass

4/30/2009 82 0 0 0 0 82 Pass

5/1/2009 83 0 0 0 0 83 Pass

4/30/2009 70 0 0 0 0 70 Pass

4/30/2009 80 0 0 0 0 80 Pass

4/30/2009 122 0 0 0 0 122 Pass

4/30/2009 122 0 0 0 0 122 Pass

4/30/2009 64 0 0 0 0 64 Pass

SYSSYNC-50: Synchronization between the V-PTC Server and RailComm CAD

SWCNTL-100: Successful Control of Powered Switches

SWCNTL-105: Received Status of Hand-Operated Switch Positions

SWCNTL-110: Over-Switch Protection causes Switch Change Command Failures

SWCNTL-120: V-PTC Server rejects Switch Change Commands

 Test Case 8

 Test Case 1

 Test Case 2

 Test Case 3

SWCNTL-135: Communications Outages while Monitoring Switches

 Test Case 3

 Test Case 4

 Test Case 5

 Test Case 6

 Test Case 7

 Test Case 1

 Test Case 2

 Test Case 6

 Test Case 8

 Test Case 9

 Test Case 10

 Test Case 11

 Test Case 12

SWCNTL-130: Local Control Mode causes Switch Change Command Failures

 Test Case 5

 Test Case 7

 Test Case 5

 Test Case 4

 Test Case 3

 Test Case 2

 Test Case 1

 Test Case 6

 Test Case 3

 Test Case 4

 Test Case 1

 Test Case 2

 Test Case 3

 Test Case 4

 Test Case 1

 Test Case 1

 Test Case 2

System Test Procedure

 Test Case 2

 Test Case 1

 Test Case 2

 Test Case 3

 Test Case 4
58

Test 

ID

Date 

Executed NE P PC F BL

Total 

Steps Test Status

178 12/18/2009 0 19 0 0 0 19 Passed

179 12/18/2009 16 5 0 0 0 21 Partial Test

182 12/1/2009 0 6 0 0 0 6 Passed

184 12/1/2009 0 7 0 0 0 7 Passed

185 12/1/2009 0 8 0 0 0 8 Passed

186 12/1/2009 0 4 0 0 0 4 Passed

187 12/1/2009 0 5 0 0 0 5 Passed

188 12/1/2009 0 18 0 0 0 18 Passed

189 12/1/2009 0 11 0 0 0 11 Passed

190 12/1/2009 0 15 0 0 0 15 Passed

191 12/1/2009 12 11 0 0 1 24 Failed

192 12/1/2009 0 12 1 0 0 13

Passed 

Conditionally 

193 12/1/2009 0 12 1 0 0 13

Passed 

Conditionally

194 12/1/2009 10 2 0 1 0 13 Failed

Totals 941 4625 39 82 49 5736

Test Case 3 (TC-002-3)

Test Case 3 (TC-004-3

Test Case 1 (TC-003-2A)

Test Case 1 (TC-004-1)

Test Case 2 (TC-004-2)

Test Case 1 (TC-001-1A)

Test Case 1

System Test Procedure

Test Case 2

TRNTERM-110 -- CAD Initiated Train Termination Requests

TC-001 -- Onboard Power-On Tests

TC-002 -- Onboard Departure Tests

TC-003 -- Onboard Train Activation Test

TC-004 -- Onboard Train Consist Update Tests

Test Case 3 (TC-001-2)

Test Case 4 (TC-001-3A)

Test Case 5 (TC-001-3B)

Test Case 6 (TC-001-3C)

Test Case 1 (TC-002-1A)

Test Case 2 (TC-002-2)

Date 

Executed P PC NE BL F

Total 

Steps

Test 

Status

4/30/2009 77 0 0 0 0 77 Pass

4/30/2009 73 1 0 0 0 74 Pass

5/1/2009 71 0 0 0 0 71 Pass

5/1/2009 67 0 0 0 0 67 Pass

4/30/2009 64 0 0 0 0 64 Pass

4/30/2009 41 0 0 0 0 41 Pass

5/1/2009 33 0 0 0 0 33 Pass

5/1/2009 48 0 0 0 0 48 Pass

5/1/2009 28 0 0 3 1 32 Fail

5/1/2009 19 0 0 1 1 21 Fail

5/1/2009 114 0 0 0 0 114 Pass

3372 3 16 6 7

LOCMON-150: Location Monitoring and Train Status

HEALTH-160: Error Detection and Health Monitoring

 Test Case 1

 Test Case 2

 Test Case 3

 Test Case 2

 Test Case 3

 Test Case 4

 Test Case 3

SWCNTL-140: Communications Outages during Switch Change Commands

System Test Step Totals

 Test Case 4

 Test Case 2

 Test Case 1

 Test Case 1

System Test Procedure
59

Test 

ID

Date 

Executed NE P PC F BL

Total 

Steps Test Status

178 12/18/2009 0 19 0 0 0 19 Passed

179 12/18/2009 16 5 0 0 0 21 Partial Test

182 12/1/2009 0 6 0 0 0 6 Passed

184 12/1/2009 0 7 0 0 0 7 Passed

185 12/1/2009 0 8 0 0 0 8 Passed

186 12/1/2009 0 4 0 0 0 4 Passed

187 12/1/2009 0 5 0 0 0 5 Passed

188 12/1/2009 0 18 0 0 0 18 Passed

189 12/1/2009 0 11 0 0 0 11 Passed

190 12/1/2009 0 15 0 0 0 15 Passed

191 12/1/2009 12 11 0 0 1 24 Failed

192 12/1/2009 0 12 1 0 0 13

Passed 

Conditionally 

193 12/1/2009 0 12 1 0 0 13

Passed 

Conditionally

194 12/1/2009 10 2 0 1 0 13 Failed

Totals 941 4625 39 82 49 5736

Test Case 3 (TC-002-3)

Test Case 3 (TC-004-3

Test Case 1 (TC-003-2A)

Test Case 1 (TC-004-1)

Test Case 2 (TC-004-2)

Test Case 1 (TC-001-1A)

Test Case 1

System Test Procedure

Test Case 2

TRNTERM-110 -- CAD Initiated Train Termination Requests

TC-001 -- Onboard Power-On Tests

TC-002 -- Onboard Departure Tests

TC-003 -- Onboard Train Activation Test

TC-004 -- Onboard Train Consist Update Tests

Test Case 3 (TC-001-2)

Test Case 4 (TC-001-3A)

Test Case 5 (TC-001-3B)

Test Case 6 (TC-001-3C)

Test Case 1 (TC-002-1A)

Test Case 2 (TC-002-2)
60

6.8 Builds 5–8 Testing – Reactive Enforcement of Speed and Authority Limits

The tests for Builds 5–8 occurred in November/December 2009. Testing goals were to perform 

testing of the Builds 5–8 functionality added in 2009 and to conduct a retest of earlier 

functionality with new server and onboard software. 

The new software included:

• Initialization of V–PTC server and Onboard system

• V–PTC server/CAD initialization and synchronization 

• Switch state awareness and remote switch control 

• Display of train location

• Health status of Wayside and Onboard devices

• Train activation and termination

• Proceed Authority Issuance, Delivery, Rollup, Cancellation

• Following Move Authority Management (GCOR Line 9)

• Route Integrity Monitoring and Stop and Inspect Protection

• Reactive Enforcement and Train Termination

As a summary of the test plan, there were 250 requirements to be verified. A combination of 

laboratory and field testing was used to verify requirements. There were 54 total tests created 

with 215 test cases. The test cases included 45 that were laboratory-only, 63 that were fieldonly, and 107 that were both laboratory and field. There were also three fully operating scenario

demonstrations.

An outline of the test approach appears below:

• Using the agreed to Requirements Verification Conditions and Criteria Matrix, LMC

developed a test plan and test procedures to verify the V–PTC system requirements

• LMC conducted subsystem testing

▬ Used developed subsystem tests to prove message interfaces and basic use case 

functionality

▬ Onboard system used V–PTC server simulator 

▬ V–PTC server used Onboard simulator and RailComm CAD application 

• LMC conducted system integration and test at the Manassas laboratory

▬ Used wayside and CANAC simulators, and radio emulator 

▬ Connected Onboard system, RailComm CAD system and V–PTC server together 

in laboratory environment

▬ Executed preliminary system tests against complete functionality strings

• TTCI/LCM field test team conducted preliminary LDS testing during week of Nov. 14,

2009

▬ Changed out LCU on 2001

▬ Upgraded software on 2001 and 203

▬ Verified LDS navigation of the RTT, TTT, and sidings

• TTCI/LCM field test team started primary on-track testing on Nov. 30, 2009

▬ Installed latest software and completed final integration with the target hardware

▬ Worked through initial bugs and started formal system testing

Figure 28 shows the test setup used during Builds 5–8 testing. 
61

Figure 28. Test Setup for Builds 5–8 Testing

The individual system components that make up the test setup are described below:

1. RailComm’s Dispatch System—used the DOC@TWC dispatching system modified to 

interface directly to the V–PTC Server on the PTC local area network.

2. Lockheed Martin’s V–PTC Server—the central processing application used to vitally 

manage the safe operations of trains on the PTC territory.

3. Ansaldo STS’s object controllers—the WIU provide remote control and status of switch 

points on the PTC territory.

4. LMC’s onboard equipment—the LCU including the LDS and Train Control Component 

software applications, the LDU including the Train User Interface software application 

that displays the managed authority limits providing speed profiles, track line, alerts and 

warnings as the train operates on the controlled territory.

5. MeteorComm’s MCC-6100 radios—provides the RF path for communications to remote 

devices at the waysides or on the trains.

6.9 Builds 5–8 Test Results

Detailed descriptions of the Builds 5–8 test results are contained in LMC’s Builds 5–8 Test 

Report.5

 A summary of the report’s content appears below.

In summary, 115 out of 167 tests passed completely without errors, another 10 tests passed 

conditionally, and 42 tests failed requirement-laden test steps during the formal test period and 

the post test verification. During Builds 5–8 testing, a total of 5,736 test steps were attempted, 

4,625 test steps either executed properly or passed one or more requirements verifying check, 39 

test steps passed conditionally, 82 test steps failed verification of one or more requirements, and 

49 other test steps were blocked by an earlier failure. The remaining 941 test steps were not 

executed because the test was either not completed or the log file for the post test verification 

was not available for evaluation. See Table 8 for more details. 

The following is a description of the fields included in Table 8.
62

• Date executed is the execution date of the test.

• The column labeled NE stands for not executed. This label is used for all test steps not 

executed during testing. Reasons include cases where two outcomes are possible 

depending on the timing of other actions in relationship to external stimulus.

• The column labeled P is the sum of nonrequirement and requirement-laden test steps. 

• The column labeled PC stands for passed conditionally. This means the results obtained 

for the test step did not change the overall results of the test. For example, if the test was 

expecting a TS_DATA state change message as the next message, but the wayside device 

had to be reset. After the reset the TS_DATA message was received with the expected 

state, this test step was mark passed conditionally.

• The column labeled F stands for failed. This means the expected result did not happen. 

• The column labeled BL stands for blocked. An earlier failure may block the execution of 

later steps. For example, an error causing a message to not be sent will cause a block of

the acknowledgement message.

• The Total Steps column is a sum of test steps in columns NE, P, PC, F, and BL for each 

test case. This sum includes both the test case and the postanalysis test steps.

The Test Status column is the overall passed/failed test results. A Passed Conditionally means 

some aspect of the test failed, but the V–PTC system performance was not compromised by the 

failure. 
63

Table 8. Builds 5–8 Test Case Results

Test 

ID

Date 

Executed NE P PC F BL

Total 

Steps Test Status

1 12/6/2009 0 20 0 0 0 20 Passed

2 12/6/2009 0 22 0 0 0 22 Passed

3 12/6/2009 0 18 3 0 0 21

Passed 

Conditionally

4 12/6/2009 0 20 0 0 0 20 Passed

5 12/6/2009 0 20 1 1 0 22 Failed

6 12/6/2009 0 23 0 0 0 23 Passed

7 12/6/2009 0 23 0 0 0 23 Passed

8 12/6/2009 0 23 0 0 0 23 Passed

9 12/6/2009 0 24 0 0 0 24 Passed

10 12/7/2009 0 34 1 2 0 37 Failed

16 12/9/2009 0 9 1 0 0 10 Passed

17 12/9/2009 14 8 0 0 0 22 Passed

18 12/9/2009 17 13 0 0 0 30 Passed

19 12/9/2009 15 12 0 0 0 27 Passed

20 12/10/2009 3 12 0 0 0 15 Passed

21 12/10/2009 0 11 0 0 0 11 Passed

22 12/10/2009 0 11 0 0 0 11 Passed

23 12/10/2009 0 11 0 0 0 11 Passed

24 12/10/2009 0 10 0 0 0 10 Passed

25 12/10/2009 0 10 0 0 0 10 Passed

26 12/10/2009 0 11 0 0 0 11 Passed

27 12/10/2009 0 8 2 3 0 13 Failed

28 12/10/2009 0 10 2 1 0 13 Failed

29 12/10/2009 0 10 2 1 0 13 Failed

30 12/10/2009 0 9 2 1 0 12 Failed

31 12/10/2009 0 10 1 0 0 11 Passed

32 12/10/2009 5 9 1 0 0 15 Passed

33 12/10/2009 5 9 0 1 0 15

Passed 

Conditionally

34 12/10/2009 5 9 0 1 0 15

Passed 

Conditionally

35 12/10/2009 5 9 0 1 0 15

Passed 

Conditionally

36 12/15/2009 2 20 0 0 0 22 Passed

37 12/15/2009 4 31 0 0 0 35 Passed

38 12/15/2009 2 21 1 1 0 25 Failed

39 12/15/2009 2 26 1 1 0 30 Failed

40 12/17/2009 5 25 0 2 0 32 Failed

41 12/17/2009 2 39 0 2 0 43 Failed

42 12/17/2009 12 28 0 2 0 42 Failed

43 12/17/2009 2 33 0 2 0 37 Failed

44 12/17/2009 0 73 0 0 0 73 Passed

45 12/17/2009 9 35 0 1 2 47 Failed

46 12/17/2009 12 0 2 0 1 15 Failed

47 12/17/2009 17 4 4 0 1 26 Failed

48 12/17/2009 2 25 0 0 0 27 Passed

49 12/17/2009 1 17 0 2 7 27 Failed

50 12/17/2009 9 24 0 0 0 33 Passed

51 12/17/2009 2 24 0 0 0 26 Passed

52 12/8/2009 42 26 4 0 0 72 Passed

53 12/8/2009 42 26 0 2 0 70 Failed

54 12/8/2009 42 26 0 2 2 72 Failed

55 12/8/2009 28 18 0 2 0 48 Failed

56 12/8/2009 28 20 0 0 0 48 Passed

57 12/8/2009 24 18 0 2 0 44 Failed

58 12/8/2009 24 18 2 0 0 44

Passed 

Conditionally

59 12/8/2009 2 6 0 1 0 9 Failed

AUTH-0200 -- Authority Management: Into and Out of Controlled Track

AUTH-0300 -- Authority Management: Authority Rejection due to Data Issues

AUTH-0400 -- Authority Management: Authority Rejection due to Invalid Limits

AUTH-0500 -- Authority Management: Authority Rejection due to Functional Checks

Test Case 8

Test Case 4

Test Case 5

Test Case 6

Test Case 7

Test Case 1

Test Case 2

Test Case 3

AUTH-0800 -- Authority Management: Route Integrity, Apply & Release of Restriction(s)

Test Case 3

Test Case 4

Test Case 5

Test Case 6

Test Case 12

Test Case 1

Test Case 2

AUTH-0700 -- Authority Management: Hand-throw Switch Alignment and Protection

Test Case 8

Test Case 9

Test Case 10

Test Case 11

Test Case 2

Test Case 3

Test Case 4

Test Case 7

Test Case 4

Test Case 5

Test Case 1

AUTH-0600 -- Authority Management: Power Switch Alignment and Protection

Test Case 1

Test Case 2

Test Case 3

Test Case 4

Test Case 5

Test Case 6

Test Case 7

Test Case 8

Test Case 2

Test Case 3

Test Case 1

Test Case 1

Test Case 2

Test Case 1

Test Case 3

Test Case 4

Test Case 5

Test Case 6

Test Case 7

Test Case 7

Test Case 8

Test Case 9

Test Case 3

Test Case 4

Test Case 5

Test Case 6

System Test Procedure

Test Case 1

Test Case 2

AUTH-0100 -- Authority Form Functional Test
64

Test 

ID

Date 

Executed NE P PC F BL

Total 

Steps Test Status

60 12/9/2009 12 34 2 2 0 50 Failed

61 12/9/2009 12 67 0 0 0 79 Passed

62 12/9/2009 12 67 0 0 0 79 Passed

63 12/9/2009 12 67 0 0 0 79 Passed

64 12/9/2009 42 63 0 0 0 105 Passed

65 12/9/2009 63 39 0 0 0 102 Passed

66 12/9/2009 63 39 0 0 0 102 Passed

67 12/9/2009 20 14 2 2 0 38 Failed

68 12/9/2009 30 23 0 4 0 57 Failed

69 12/9/2009 30 27 0 0 0 57 Passed

70 12/9/2009 33 40 0 0 0 73 Passed

71 12/9/2009 22 20 0 0 0 42 Passed

72 12/11/2009 0 30 0 0 0 30 Passed

73 12/11/2009 0 31 0 0 0 31 Passed

74 12/11/2009 2 39 0 0 0 41 Passed

75 11/18/2009 0 16 0 0 0 16 Passed

76 11/18/2009 0 18 0 0 0 18 Passed

77 11/18/2009 0 19 0 0 0 19 Passed

78 11/18/2009 0 19 0 0 0 19 Passed

79 11/18/2009 0 22 0 0 0 22 Passed

80 11/18/2009 0 21 0 0 0 21 Passed

81 11/18/2009 0 16 0 0 0 16 Passed

82 11/18/2009 0 16 0 0 0 16 Passed

83 11/18/2009 0 13 0 0 0 13 Passed

84 11/18/2009 0 13 0 0 0 13 Passed

85 11/18/2009 0 18 0 0 0 18 Passed

86 11/21/2009 0 16 0 0 0 16 Passed

87 11/18/2009 0 18 0 0 0 18 Passed

88 11/18/2009 0 18 0 0 0 18 Passed

89 11/18/2009 0 19 0 0 0 19 Passed

90 11/18/2009 0 19 0 0 0 19 Passed

91 11/18/2009 0 22 0 0 0 22 Passed

92 11/18/2009 0 21 0 0 0 21 Passed

93 11/18/2009 0 16 0 0 0 16 Passed

94 11/18/2009 0 16 0 0 0 16 Passed

95 11/21/2009 0 20 0 0 0 20 Passed

96 12/18/2009 0 13 0 0 0 13 Passed

97 12/18/2009 0 18 0 0 0 18 Passed

98 12/18/2009 0 19 0 2 0 21 Failed

99 12/18/2009 0 20 0 0 0 20 Passed

100 12/18/2009 0 16 0 0 0 16 Passed

101 12/18/2009 0 30 0 1 0 31 Failed

103 12/17/2009 2 29 0 0 0 31 Passed

104 12/17/2009 3 18 0 0 0 21 Passed

105 12/17/2009 2 20 0 2 0 24 Failed

106 12/17/2009 2 19 0 0 0 21 Passed

107 12/17/2009 2 19 0 0 0 21 Passed

108 12/17/2009 2 22 0 0 0 24 Passed

110 12/17/2009 3 20 0 0 0 23 Passed

111 12/17/2009 2 23 0 0 0 25 Passed

112 12/17/2009 3 17 0 2 0 22 Failed

113 12/17/2009 3 20 0 0 0 23 Passed

114 12/18/2009 3 19 0 0 0 22 Passed

115 12/18/2009 2 24 0 0 0 26 Passed

116 12/18/2009 3 20 0 1 0 24 Failed

117 12/18/2009 0 42 0 2 0 44 Failed

118 12/18/2009 0 52 0 0 0 52 Passed

120 12/18/2009 26 20 0 2 0 48 Failed

Test Case 6

Test Case 2

Test Case 3

Test Case 4

Test Case 5

Test Case 1

Test Case 2

Test Case 3

Test Case 4

Test Case 5

AUTH-1400 -- Authority Management: Cancel and Re-issue Acceptance from Uncontrolled Track

Test Case 1

Test Case 6

AUTH-1300 -- Authority Management: Automatic Rollup Verification

AUTH-2400 -- Authority Management: Conditional Authority, Following Move

Test Case 18

Test Case 19

Test Case 20

Test Case 21

Test Case 14

Test Case 15

Test Case 16

Test Case 17

Test Case 10

Test Case 11

Test Case 12

Test Case 13

Test Case 6

Test Case 7

Test Case 8

Test Case 9

Test Case 2

Test Case 3

Test Case 4

Test Case 5

Test Case 2

Test Case 3

Test Case 1

AUTH-1200 -- Authority Management: Safety Checking & Rejection, Part 1

Test Case 11

Test Case 12

Test Case 1

AUTH-1100 -- Authority Management: Route Locking

Test Case 7

Test Case 8

Test Case 9

Test Case 10

Test Case 3

Test Case 4

Test Case 5

Test Case 6

Test Case 1

Test Case 2

AUTH-1000 -- Authority Management: Route Integrity, Non-release of Restriction(s)

System Test Procedure

Test Case 2

Test Case 3

Test Case 2

Test Case 4

Test Case 5

Test Case 1

AUTH-1500 -- Authority Management: Cancel and Re-issue Acceptance on Controlled Track

AUTH-1900 -- Authority Management: Cancel Authority Acceptance

Test Case 3

Test Case 1

Test Case 2

Test Case 4
65

Test 

ID

Date 

Executed NE P PC F BL

Total 

Steps Test Status

121 12/6/2009 0 75 0 0 0 75 Passed

122 12/5/2009 0 67 0 0 0 67 Passed

123 12/12/2009 0 44 0 0 0 44 Passed

124 12/10/2009 27 18 0 0 0 45 Passed

125 12/10/2009 0 8 0 0 0 8 Passed

126 12/10/2009 0 37 0 1 0 38 Failed

127 12/12/2009 0 37 0 3 4 44 Failed

128 12/12/2009 0 43 0 0 0 43 Passed

133 12/12/2009 0 37 0 3 2 42 Failed

140 12/5/2009 0 59 0 2 0 61

Passed 

Conditionally

141 12/5/2009 0 59 0 2 0 61

Passed 

Conditionally

142 12/5/2009 3 58 0 4 2 67 Failed

143 12/5/2009 4 61 0 2 0 67

Passed 

Conditionally

144 12/5/2009 0 6 0 3 0 9 Failed

145 22 7 0 0 1 30 Partial Test

146 12/5/2009 3 45 0 0 0 48 Passed

147 12/5/2009 3 60 0 0 0 63 Passed

148 12/9/2009 0 42 0 0 0 42 Passed

149 12/9/2009 6 43 0 1 0 50

Passed 

Conditionally

150 12/9/2009 0 41 0 1 22 64 Failed

151 12/3/2009 4 98 0 0 0 102 Passed

152 12/3/2009 0 93 0 0 0 93 Passed

153 12/3/2009 4 89 0 0 0 93 Passed

154 12/3/2009 0 206 0 0 0 206 Passed

155 12/4/2009 0 33 0 0 0 33 Passed

156 12/4/2009 0 165 0 0 0 165 Passed

157 12/4/2009 4 64 0 0 0 68 Passed

158 12/4/2009 2 33 0 0 0 35 Passed

159 12/4/2009 2 35 0 0 0 37 Passed

160 12/4/2009 4 61 0 0 0 65 Passed

161 12/4/2009 2 34 0 0 0 36 Passed

162 12/1/2009 0 9 0 0 0 9 Passed

163 12/1/2009 0 19 0 2 0 21 Failed

164 12/1/2009 0 9 0 2 0 11 Failed

166 12/1/2009 1 15 0 0 0 16 Passed

167 12/1/2009 0 32 0 0 0 32 Passed

168 12/1/2009 3 3 0 1 4 11 Failed

169 11/20/2009 0 14 0 0 0 14 Passed

170 11/20/2009 0 16 0 0 0 16 Passed

171 11/20/2009 10 13 0 0 0 23 Passed

172 12/1/2009 4 19 0 0 0 23 Passed

173 12/1/2009 0 25 0 0 0 25 Passed

174 12/7/2009 0 58 3 0 0 61 Passed

175 12/8/2009 0 13 0 0 0 13 Passed

SYSSYNC-50 -- Synchronization between the V-PTC Server and RailComm Dispatch System

SYSSYNC-75 -- Synchronization between the V-PTC Server and RailComm Dispatch System

TRNDISP-100 -- Location Determination Initialization

Test Case 1

Test Case 2

CIVSPEED-100 -- Civil Speeds and Restrictions

ENFORCE-100 -- Over-speed Enforcement Violations

ENFORCE-110 -- Authority Limit Violations

System Test Procedure

LOCMON-100 -- Location Determination Initialization Test

Test Case 1

Test Case 2

LOCMON-110 -- Location Determination Initialization Test

Test Case 1

Test Case 2

Test Case 3

SWCNTL-105 -- Hand-throw or Local Switch Alignment Changes

Test Case 4

Test Case 1

Test Case 2

SWCNTL-135 -- Communications Outages while Monitoring Switches

Test Case 1

Test Case 2

Test Case 1

LOCMON-120 -- Location Determination Initialization Test

Test Case 7

Test Case 4

Test Case 3

Test Case 1

Test Case 2

Test Case 5

Test Case 6

Test Case 2

Test Case 3

Test Case 1

SWCNTL-100 -- Successful Control of Powered Switches

Test Case 2

Test Case 4

Test Case 6

Test Case 1

Test Case 2

Test Case 1

Test Case 2

Test Case 3

Test Case 4

Test Case 5

Test Case 1

Test Case 2

Test Case 3

SYSINIT-25 -- Initialization of the V-PTC Server and Onboard System

Test Case 5

Test Case 6

Test Case 7

Test Case 1

Test Case 2

Test Case 3

Test Case 1

Test Case 2
66

During Builds 5–8 testing, a total of 82 test steps failed verification of one or more requirements. 

Because of the incremental nature of the deployment of the V–PTC system, most of the failures 

in this test period were the result of incomplete development on the software portions of the 

system. Overall, it appears that the development of the software is at a point approximately 80 

percent of the way to allow for moving block functionality in the V–PTC system. With 

additional time and funding, it is likely that this functionality could become fully available.

Test 

ID

Date 

Executed NE P PC F BL

Total 

Steps Test Status

178 12/18/2009 0 19 0 0 0 19 Passed

179 12/18/2009 16 5 0 0 0 21 Partial Test

182 12/1/2009 0 6 0 0 0 6 Passed

184 12/1/2009 0 7 0 0 0 7 Passed

185 12/1/2009 0 8 0 0 0 8 Passed

186 12/1/2009 0 4 0 0 0 4 Passed

187 12/1/2009 0 5 0 0 0 5 Passed

188 12/1/2009 0 18 0 0 0 18 Passed

189 12/1/2009 0 11 0 0 0 11 Passed

190 12/1/2009 0 15 0 0 0 15 Passed

191 12/1/2009 12 11 0 0 1 24 Failed

192 12/1/2009 0 12 1 0 0 13

Passed 

Conditionally 

193 12/1/2009 0 12 1 0 0 13

Passed 

Conditionally

194 12/1/2009 10 2 0 1 0 13 Failed

Totals 941 4625 39 82 49 5736

Test Case 3 (TC-002-3)

Test Case 3 (TC-004-3

Test Case 1 (TC-003-2A)

Test Case 1 (TC-004-1)

Test Case 2 (TC-004-2)

Test Case 1 (TC-001-1A)

Test Case 1

System Test Procedure

Test Case 2

TRNTERM-110 -- CAD Initiated Train Termination Requests

TC-001 -- Onboard Power-On Tests

TC-002 -- Onboard Departure Tests

TC-003 -- Onboard Train Activation Test

TC-004 -- Onboard Train Consist Update Tests

Test Case 3 (TC-001-2)

Test Case 4 (TC-001-3A)

Test Case 5 (TC-001-3B)

Test Case 6 (TC-001-3C)

Test Case 1 (TC-002-1A)

Test Case 2 (TC-002-2)
67

7. Summary and Conclusions

TTCI, in cooperation with the FRA, RRF, and LMC, conducted R&D activities for a safety-critical, 

CBTC system. The system, functionally a second-generation PTC system, used an office-centric 

architecture based on current and evolving industry PTC communications technologies. The system 

R&D was performed under the V-PTC project, and the goal of the project was to build and test a 

fully functional vital PTC system that could be used in revenue service operations.

As part of this project, a PTC Test Bed was developed at TTC to support industry PTC development 

activities. The test bed consists of track and communications infrastructure, equipment for each 

major PTC segment, laboratory facilities, and specialized software tools capable of providing 

consistent and realistic test environments for PTC systems. The test bed’s design enables 

multiple configurations, enabling users to mimic a desired test environment or scenario.

The V–PTC system was developed and tested in multiple incremental builds with increasing 

capabilities. This incremental development approach was made practical by using the closed 

track environment of the PTC Test Bed. It enabled the TTCI/LMC team to develop a system 

build, evaluate performance for that build, retest any scenarios that needed retesting, and 

continue on to the next build. This approach was influential in ensuring that development of a 

system of continually increasing complexity had a solid, well examined foundation on which to 

build and that each stage produced capabilities aligned with the SRS.

There were a number of lessons learned. At the highest level, the use of a dedicated test bed for 

this type of testing significantly increases the testing efficiency for developmental systems, 

freeing their testing from the constraints normally associated with revenue service operations. 

Also, the use of an incremental development and testing cycle is an excellent approach for 

developing complex systems. This approach produced a developmental system that showed 

constant progress with solid performing functionalities of increasingly complex capabilities. 

And finally, the results generated by this project show that the current state of PTC-related 

technologies is sufficient for developing and providing equipment for each of the major PTC 

segments, including Wayside, Locomotive, Back Office, and communications infrastructure.

A concluding recommendation is that when the industry’s needs for moving block capabilities 

and/or a PTC office-centric architecture are sufficiently mature and necessary funds are 

available, the V–PTC project should be reactivated using updated SRS requirements that reflect 

current industry requirements. 
68

8. References*

1. Locomotive Control Unit (LCU II) Performance Assessment V–PTC Server Location 

Report Process and Archiving–Final Report–Build 1

2. V–PTC Switch Monitoring Test Report–Build 2

3. V–PTC Switch Awareness Test Report–Build 3

4. V–PTC Switch Control Testing–Final Test Report–Build 4

5. V–PTC Authority Management Testing–Final Test Report–Builds 5-8

6. Concept of Operations for Vital PTC System in Unsignaled Territory

7. V–PTC System Requirements Specification (Revision 06)

8. V–PTC Onboard Train Internal System Architecture Document

9. V–PTC Field Testing at TTCI–Build 1

*[Please contact TTCI at (719) 584-0750 to obtain copies of these reports.]
69

Abbreviations and Acronyms

AAR Association of American Railroads

AMS Authority Management Server

ATCS advanced train control system

BIU brake interface unit

BOS back office server

CAD computer-aided dispatch

CBTC communications-based train control

CFR Code of Federal Regulations

CRC cyclical redundancy checks 

CCW counterclockwise

CW clockwise

DC direct current

EBA enforcement braking algorithm

FRA Federal Railroad Administration

GPS global positioning system

IDOT Illinois Department of Transportation

LAN local area network

LCM local control mode

LCU locomotive control unit

LDS location determination system

LDU locomotive display unit

LMC Lockheed Martin Corporation

MHz megahertz

mph miles per hour

MS2 mission systems and sensors

NAJPTC North American Joint Positive Train Control

PTC positive train control

RF radio frequency

RRF Railroad Research Foundation

RSIA ‘08 Rail Safety Improvement Act of 2008
70

RTC rail traffic controller

RTT railroad test track

SRS system requirements specification

TOES train operations and energy simulator

TTC Transportation Technology Center, the site

TTCI Transportation Technology Center, Inc., the company

TTT Transit Test Track

UTC coordinated universal time

V–PTC vital-positive train control

WIU wayside interface unit