Office of Research and 

Federal Railroad

Administration

U.S. Department

of Transportation Interoperable Communications-Based Signaling Project

Development 

Washington, D.C. 20590 

DOT/FRA/ORD-09/12 June . 2009

 
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. 

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. 

ii
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 (0702-0288), Washington, D.C. 20503 

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

June 30, 2009 

3. REPORT TYPE AND DATES COVERED 

4. TITLE AND SUBTITLE 

Interoperable Communication-Based Signaling Project

6. AUTHOR(S) 

Bill Petit

5. FUNDING NUMBERS 

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

Petit Consulting Railroad Research Foundation 

17 Hawthorne Drive 50 F Street, NW Suite 5200 

Spencerport, NY 14559 Washington, DC 20001

8. PERFORMING ORGANIZATION 

REPORT NUMBERS 

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

U.S. Department of Transportation 

Federal Railroad Administration 

Office of Research and Development 

1200 New Jersey Avenue SE, Mail Stop 20 

West Building, 3rd Floor 

Washington, DC 20590

10. SPONSORING/MONITORING AGENCY 

REPORT NUMBER 

DOT/FRA/ORD-09/12 

11. SUPPLEMENTARY NOTES 

12a. DISTRIBUTION/AVAILABILITY STATEMENT

This document is available through the FRA Internet site at www.fra.dot.gov

12b. DISTRIBUTION CODE 

13. ABSTRACT

Interoperable Communication-Based Signaling (ICBS) refers to an implementation of a train control system based 

on signaling principles whose system architecture and interface are documented as Recommended Practices (from 

the AREMA Manual of Recommended Practices for Communications and Signaling) by the Association of 

Railroad Engineering and Maintenance-of-Way Association (AREMA). This project demonstrated that existing 

suppliers of vital (fail-safe) train control equipment can modify their products to support the system architecture and 

interfaces as specified. ICBS is capable of satisfying the requirements of a positive train control system. 

15. NUMBER OF 

PAGES 

27 

14. SUBJECT TERMS 

Train control, communications-based train control, CBTC, positive train control, PTC, 

railroad safety, ICBS

16. PRICE CODE

17. SECURITY 

CLASSIFICATION 

18. SECURITY CLASSIFICATION 

OF THIS PAGE 

19. SECURITY CLASSIFICATION 

OF ABSTRACT 

20. LIMITATION OF 

ABSTRACT 

UNCLASSIFIED UNCLASSIFIED UNCLASSIFIED SAR 

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

Prescribed by ANSI/NISO Std. 

239.18 

298-102
iv
Contents 

Executive Summary........................................................................................................... vi 

1.0 Introduction............................................................................................................. 1 

1.1 Background...................................................................................................... 1 

1.2 Objectives ........................................................................................................ 1 

1.3 Overall approach.............................................................................................. 2 

1.4 Scope................................................................................................................ 2 

2.0 Project Description.................................................................................................. 2 

2.1 Communication-Based Signaling (CBS) Origin ............................................. 2 

2.2 CBS System Operation.................................................................................... 3 

2.3 CBS Subsystems.............................................................................................. 5 

2.4 AREMA Recommended Practices on Communication-Based Signaling ....... 8 

2.5 CBS Test Environment.................................................................................... 9 

2.6 CBS SYSTEM DEMONSTRATION TESTS AND CONCLUSIONS ........ 12 

3.0 References............................................................................................................. 26 

v
Executive Summary 

This project demonstrates that the major suppliers of signaling equipment for the North 

American railroads can modify their existing safety-critical equipment to support 

operation of a vital interoperable positive train control system based on signaling 

principles developed over many decades. The project is referred to either as 

communication-based signaling (CBS) in the American Railway Engineering and 

Maintenance–of-Way Association (AREMA) Manual of Recommended Practices or 

interoperable communication-based signaling (ICBS). The terms may be used 

interchangeably. 

Project participants included the major suppliers of signal and train control equipment 

within North America. These suppliers have provided a wide variety of signaling 

equipment, including processor-based equipment that has been in revenue service on 

railroads and transit properties for decades. This includes equipment designed and built to 

the vital (or fail-safe) requirements of rail and transit properties. The project was 

sponsored by the Federal Railroad Administration (FRA) Office of Railroad 

Development and coordinated through the Railroad Research Foundation 

(www.railroadresearch.org). Project management was provided by Bill Petit 

(www.billpetit.com) and the test environment and simulators were provided by Critical 

Link (www.criticallink.com). The participating suppliers include Alstom Signaling 

(www.transport.alstom.com), Ansaldo–STS (previously known as Union Switch and 

Signal) (www.ansaldo-sts.com), General Electric Transportation Systems (GETS) 

(www.getransportation.com), and Safetran Systems (www.safetran.com). Financial 

support was provided by FRA for the project management and test environment. Three of 

the suppliers (Ansaldo–STS, GETS, and Safetran) received funding covering 

approximately a third of their actual costs. Alstom entered the project later than the others 

and received no financial support through FRA. 

This project was undertaken to verify that a set of interoperability standards developed 

and maintained through an industry professional organization (AREMA, 

www.arema.org) could be implemented. Many additional aspects exist to implementing a 

complete positive train control system and this project should be seen as part of a 

pathway toward full interoperable train control. 

As part of the project, a test environment modeling four railroad sections, each 

representing a different railroad, was created along with a communications infrastructure 

for transporting messages. A conventional centralized traffic control (cTc) computeraided dispatch (CAD) system was used to control movement through all of the sections. 

Each of the suppliers modified their own existing equipment to support the AREMA 

Recommended Practices and inserted their equipment into the proper location within the 

overall test environment. Onboard equipment from suppliers was used to move trains 

seamlessly across all the territories. Experience gained through the project was tabulated 

and referred to AREMA for inclusion in the next release of Recommended Practices. 

vi
vii

All four of the suppliers demonstrated that their modified wayside equipment operated 

within the system and was interoperable with other equipment. Two of the suppliers 

demonstrated that their carborne equipment operated within the system (including across 

all four suppliers’ waysides) and was interoperable within the overall system.
1.0 Introduction 

1.1 Background 

Various forms of interoperable advanced train control systems have been investigated 

since 1983 (when an industry project on Advanced Train Control Systems (ATCS)) was 

begun. These train control systems are used to enhance the safety of conventional train 

control systems through continuous monitoring of train position and the ability to enforce 

a train to stop before an obstacle or a point where it is desired to control the train. 

Since then, these systems for freight railroads have been generally called positive train 

control (PTC) systems. For clarity’s sake, the Federal Railroad Administration (FRA) has 

defined PTC systems to include the following major characteristics: 

 Prevent train-to-train collisions. 

 Enforce speed restrictions, including civil engineering restrictions (curves, 

bridges, etc.) and temporary slow orders. 

 Provide protection for roadway workers and their equipment operating under 

specific authorities. 

The Railway Safety Improvement Act of 2008 mandated PTC systems for much of the 

nations rail infrastructure and added an additional requirement of monitoring track switch 

position and preventing train movement over an unauthorized route. Code of Federal 

Regulations Title 49 Part 236 (Rules, Standards, and Instructions Governing the 

Installation, Inspection, Maintenance, and Repair of Signal and Train Control Systems, 

Devices and Appliances) is being modified to include a new Subpart I related to positive 

train control systems. 

Various train control methods have been experimented with including non-vital overlays, 

vital overlays, and vital stand-alone systems. (Overlays are used as additions to existing 

train control systems and use those underlying systems as part of their safety 

justification). ICBS can be used as a vital stand-alone system or may also be used as a 

vital overlay system.

1.2 Objectives 

Interoperable communication-based signaling (ICBS) project objectives were to develop a test 

system based on items in the Manual of Recommended Practices (Recommended Practices) 

developed by the American Railway Engineering and Maintenance-of-Way Association 

(AREMA). Multiple suppliers with experience in safety-critical (vital) train control and 

signaling systems would modify their equipment to participate in a demonstration. This 

demonstration would show that the defined system architecture could meet PTC objectives as 

well as demonstrate that multiple suppliers could develop systems according to the 

Recommended Practices that would be interoperable over the full system. 

1
1.3 Overall approach 

The overall approach was to define a simulated railroad operating scenario, where 

various sections of the test scenario would be controlled by different suppliers and 

onboard systems provided by any of the suppliers that could seamlessly operate over the 

entire test layout. Once the test layout was defined and simulators were developed, the 

individual suppliers would replace the simulators with their individual equipment 

modified to support the AREMA-based architecture. With all the simulators replaced, 

demonstrations were held highlighting the architecture and interoperability. 

1.4 Scope 

The scope of the project was to demonstrate that existing equipment from suppliers could 

be modified (as prototypes) showing the architecture and interoperability attributes of the 

AREMA defined system. The form translator (see the communication-based signaling 

(CBS) subsystem description) was not included in this demonstration. 

2.0 Project Description 

2.1 Communication-Based Signaling (CBS) Origin 

The process of defining the CBS system began at the 2005 AREMA Communications 

and Signaling (C&S) technical conference. During the roundtable discussions of railroad 

Chief Signal Engineers, a request was made to define an interoperable radio-based cab 

signal system. This in turn was assigned to AREMA Committee 37 (signal and train 

control systems). To proceed with this task, members of the committee, who have 

existing vital processor-based signaling equipment in revenue service and had expressed 

an interest in communication-based signaling concepts previously, met separately to 

determine if any prospect existed of coming to an agreement on an interoperable system 

based on the systems they currently have in the field or on the drawing board. The 

companies participating (and their current products) were Alstom Signaling (Atlas), 

General Electric Transportation Systems (GETS) Global Signaling (ITCS–Incremental 

Train Control System), Safetran Systems (vTc–virtual traffic control) and Union Switch 

and Signal (US&S) (CAS–Collision Avoidance System). Surprisingly, all of the 

companies quickly agreed that it was in the best interests of the industry to develop 

interoperability standards based on the common system architecture we had arrived at 

independently. 

Of the companies participating in the original meeting, GETS, Safetran and US&S agreed 

to proceed with the development of draft manual parts. These manual parts were 

presented to AREMA Committee 37 and subsequently approved by the committee for 

publication the 2009 AREMA Manual of Recommended Practices for Communications 

and Signaling (published in Fall 2008). This manual is updated annually (and each 

specific manual part must be revised or reaffirmed on a five-year cycle). 

2
2.2 CBS System Operation 

Understanding the system architecture and philosophy used in developing the CBS 

system is beneficial. In principle, a CBS system operates the same as a conventional cab 

signal system except for the following: 

1. Physical blocks (as determined by track circuits in conventional systems) are 

replaced with virtual blocks that are generally equivalent in length to track circuits 

in cTc territory. 

2. Communications via the rails is replaced with a digital data link. 

3. Train location is determined as an on-board function. 

4. An onboard database is used to provide information needed for enforcing civil 

speeds and determining braking profiles based on attributes such as grade. 

In a CBS system, instead of transmitting vital cab signal information through the rails, a 

radio frequency (RF) communications data link is employed for this function. 

Figure 1. CBS diagram. The communications cloud represents whatever RF 

communication system is chosen to route the pre-defined messages between the 

various subsystems 

3
In the communication-based system, the dispatcher sends requests, via the computeraided dispatch (CAD) office system, to the signaling logic processor (SLP) to control 

switches and set routes just as would be done in conventional cTc operation. These 

operations are done using vital signal logic and principles as described elsewhere in the 

AREMA manual. It is important to note that the CAD requests to the SLP are not part of 

the vital system and are only requests to have actions performed. The actual actions are 

not performed until the vital logic with the SLP allows them to take place. Thus, the SLP 

acts on these requests if it is safe to do so, and sends indications to the CAD office 

system when the requests are completed. These control (requests) and indication 

messages between the CAD and SLP are the same as existing control and indication 

messages used for conventional signal systems. 

The SLP sends control commands to the wayside appliance subsystem (WA) (also 

referred to as a wayside interface unit) to position and lock track switches and/or receives 

switch position information. The onboard logic processor (OBLP) reports the trains 

location in terms of the blocks it is occupying. The SLP determines the governing signal 

aspect for the block occupied (and those about to be occupied) for the train based on 

block occupancies, temporary speed restrictions, switch positions, other routes set within 

the territory; and transmits the governing signal information to the OBLP. The OBLP 

determines the governing aspect for the block based on the data received via the data 

communications link, and the civil speed data contained in the onboard database, and 

displays the appropriate signal aspect and/or speed limit to the operator, who in turn 

controls the train appropriately. If the operator does not control the train appropriately, 

the OBLP determines overspeed and what exceeds authority and requests brakes when 

required. When actual wayside signals are present the SLP will provide the OBLP with 

the address of the signal in place of the signal aspect. The OBLP will then request the 

signal status directly from the signal and use the received signal to determine the limiting 

aspect/speed for the upcoming block. 

Because the number of possible signal aspects is not limited by the physical 

characteristics of the track as in conventional systems, defining a larger number of 

available aspects is possible so that additional information can be conveyed to the 

engineman. This allows more flexibility in operation and better system throughput. 

The communication-based system can also allow the office dispatcher to install 

temporary speed limits or roadway worker authorities. These are converted through the 

forms translator to a format usable by the SLP, which then determines the appropriate 

signal aspects or allowable speeds to be sent to the train. 

A more detailed look at the specific functions to be done by each of the subsystems 

follows.

4
2.3 CBS Subsystems

The following subsystems make up the CBS system. Each subsystem is responsible for 

the functions identified within its subsection. 

 CAD System 

The office is the same as the cTc or dispatcher office system currently in use 

providing a central command and control facility for management of traffic and 

work crews within the controlled territory. Specific functions and operations are 

railroad dependent. This allows current dark territory to be dispatched just as if it 

was cTc territory with the obvious safety and efficiency benefits (e.g., following 

moves through a direct traffic control (DTC) or track warrant control (TWC) 

block). 

 Form Translator 

The forms translator converts specific railroad forms data for functions such as 

temporary speed restrictions into commands that can be used by the SLP. 

 Signaling Logic Processor (SLP) 

The SLP is responsible for the implementation of signaling principles. It 

calculates the appropriate signal aspect and/or speed limit for each virtual block, 

based on train position and travel direction; the position and travel direction of 

other trains; the defined authority limits; the position, status and location of 

switches, and any temporary speed restrictions. 

The SLP is responsible for the following functions. 

o Convert incoming messages (via the data communications network) from 

locomotives into appropriate block occupancy information within the SLP. 

o Convert incoming messages (via the data communications network) from 

wayside interface units into appropriate switch position information within 

the SLP. 

o Note: Interim systems may have alternative methods of entering switch 

position (e.g., dispatcher input based on voice radio from locomotive). 

o Execute signal logic equations to determine governing signal aspects for 

all blocks within the territory. 

o Convert signal aspect information into serial messages for transmission to 

appropriate locomotives for display. 

5
o Note: signal aspects are vitally associated with specific blocks. Because 

the locomotive also vitally knows which block it is occupying, it is not a 

vital function to send the proper aspect to the proper locomotive. 

o Respond to non-vital controls and provide non-vital indications to CAD 

system. 

o Verifying locomotive contains the latest version of all critical databases. 

o Interface to forms translator 

 Note: The SLP may be constructed from a group of local or remote 

processor units, each responsible for a geographic section of 

railroad. Each processor unit within the SLP will be responsible for 

data exchanges with its geographic neighbors. 

 Wayside Appliances (WA) 

The wayside appliances include signals, switches, track circuits, highway crossing 

controllers, defect detectors, and the equipment necessary to allow the appliances 

to interface to the communications links. The WA may include a wayside 

interface unit (WIU), which contains both the necessary control equipment and 

the necessary interface equipment for linking traditional signaling appliances to 

the communication-based system. The WA is responsible for the control of 

switches and determining the status of switches, track circuits, and actual signals 

 On Board Logic Processor (OBLP) 

The onboard logic processor is responsible for determining the train’s current 

location, current speed, train integrity (if installed as a part of the system), 

direction of travel, and the train’s allowed speed as defined by the civil speed 

limit contained in the onboard database, the aspect or speed limit received from 

the SLP or from local devices as instructed by the SLP. The OBLP also 

determines train overspeed, warns the operator, and provides enforcement. 

The OBLP is responsible for the following functions. 

o Maintain a topographical representation (infrastructure database) of all 

blocks in the territory, using the virtual blocks as the fundamental track 

elements. 

o Using information from a location determination system (LDS), identify 

which specific block is currently occupied by train by the block address 

(also referred to as block ID). 

o LDS may be GPS based, transponder based or other. (Note: if based on 

transponders or other wayside equipment not supported by foreign roads, 

the locomotive may be required to operate as “unequipped” on the foreign 

roads.) 

6
o Transmit Block Occupancy information to SLP. 

o Determine signal aspect and/or speed limit information received from SLP 

(after verifying that the aspect received is for the occupied block). 

o Determine the maximum allowed civil speed for the block being occupied 

by the lead end of the train and any civil speed restrictions (‘look back’) 

for any block occupied by the train. 

o Display the correct signal aspect and/or speed limit based on the civil 

restrictions and the signal aspect/speed information received from the 

SLP. 

o Provide overspeed protection, via request of brake application, of most 

restrictive speed limit. 

o Provide overrun protection for exceeding allowable signal aspect authority 

via request of brake application. 

o Provide self-testing function with an indication that self-testing has been 

successfully accomplished. 

 Communication Links 

The CBS system may use any physical communications infrastructure that is 

suitable. Message protocol and structure are as defined in Manual Part 23.4. The 

physical communication links are not vital. Vitality is maintained within the data 

messages. 

For CBS, a decision was made to continue the use of ATCS addressing and 

protocols. The ATCS addressing perfectly fits the desired operation along with 

capitalizing on the existing ATCS addresses widely used in the industry today. 

The ATCS datagram was chosen as it supports the performance and safety needs 

of the system. The use of ATCS addressing and datagrams does not mandate the 

use of ATCS frequencies and radios. The datagrams can easily be sent as a 

payload through any type of system (e.g., IP-based systems) that supports the 

needed system performance. 

 Infrastructure Database 

The database defines the railroad infrastructure including track circuits (actual or 

virtual), signal locations (actual or virtual), and switch locations. The database 

defines the linkages between the track circuits, signals and switches. It defines 

grades, civil speed limits, signal aspects, defect detector locations, highway 

crossing locations, etc. The database defines everything the CBS system needs to 

know about the fixed infrastructure. 

7
2.4 AREMA Recommended Practices on Communication-Based Signaling 

After substantial work, the first set of manual parts was approved by the full membership 

of AREMA Committee 37 and published in the 2009 AREMA C&S Manual. The 

following is an overview of the manual parts. 

23.2.1 Recommended Functional Requirements of a CBS System

This section defines the functional requirements for a Communication-Based Signaling 

(CBS) system, including safety-critical train protection functions and train operation 

functions. Systems may vary widely in complexity and not all functions are required for 

all systems. 

23.2.2 Recommended RAMS, Environmental and Other Requirements for Signaling 

Systems Using CBS Architecture.

This manual part defines the recommended reliability, availability, maintainability, 

safety, environmental, electromagnetic compatibility, and quality assurance requirements 

for the CBS system. 

23.3.1 Recommended Design Guidelines for a CBS System

This manual part defines the system architecture and the interfaces for a system design 

based on conventional signaling principles as needed to meet the functional requirements 

specified in Section 23.2.1 

23.4.1 Recommended Communications Protocols for a CBS system 

This manual part defines the recommended system communication protocols without 

going into specific radio or network systems. Use of ATCS protocols and addressing is 

recommended to meet the safety and performance requirements, as well as to leverage the 

large amount of existing addressing schemes currently in use and the ATCS protocol 

expertise. These addresses and protocols can be used over any type of communication 

systems, not necessarily an ATCS radio system. Given the rate of change in 

communication technology, this approach allows use of any desired communication 

framework, while maintaining the interoperability and safety requirements. 

23.4.2 Recommended Communications Messages for a CBS System

This manual part defines the recommended system messages (i.e. what information are 

you communicating between users) used between subsystems of the CBS system. 

Detailed message contents are included within the manual part. 

23.5.1 Recommended Onboard Database Guidelines for a CBS system 

8
This manual part defines the structure and content of the onboard database to facilitate 

interoperability. It includes the naming structure for each track section, switch, signal, etc 

based upon ATCS addressing techniques, as well as the necessary links to define how the 

various components are linked together. 

2.5 CBS Test Environment 

In late 2007, FRA (www.fra.dot.gov) provided a grant to demonstrate the operation of an 

ICBS system as defined by AREMA. This includes demonstrating the ability of multiple 

suppliers to achieve and demonstrate interoperability by following the Recommended 

Practices. 

The FRA grant covered a laboratory demonstration of the system with each of the 

participating suppliers providing interoperable equipment based on the AREMA Manual 

Parts. The four major signal suppliers in North America GETS 

(www.getransportation.com), Safetran Systems Corporation (www.safetran.com), 

Ansaldo-STS (www.switch.com), and Alstom (www.alstomsignalingsolutions.com) 

agreed to participate in the project. Critical Link (www.criticallink.com) was chosen to 

provide the test environment, including simulators, physical interfaces, and integration 

support. 

To accomplish the testing, a territory had to be defined that would allow each of the 

participating suppliers to have a section to control, an interface to adjacent sections, an 

interface to a control office, and onboard systems capable of traversing all four sections. 

In addition, a communications router was developed that was capable of routing 

information throughout all four sections and all the vehicles based on the defined 

addresses. The approach taken was to develop a set of simulators for each of the 

subsystems that performed the basic functionality as well as supporting the defined 

interfaces. The simulators and router were based on PCs with the ICBS defined messages 

encapsulated and sent via an IP network. After the simulators were developed, each of the 

participating suppliers then used the simulators at their own facilities as a way of testing 

their systems before incorporating them into the final demonstration. 

As each of the suppliers completed various subsystems, they were substituted into the 

demonstration system at the Critical Link facility in Syracuse, NY. Thus, at the 

completion of the project, no simulators were running as they had all been replaced by 

actual suppliers’ equipment. 

The territory to be simulated consisted of four contiguous segments and each with double 

track. Figure 2 is an example of the territory to be controlled by each participant. 

Splitting the territory into blocks and governing signals was arbitrary. Each application of 

CBS will allow blocks and signals to be defined as needed to achieve the needed 

operational performance of that section of railroad. Each of the participating suppliers 

had a similar territory to control and the overall territory had four of these sections 

9
operating contiguously (i.e., a vehicle supplied by a single supplier can move seamlessly 

across all four sections). 

Figure 2. Example Territory for ICBS Simulation 

Table 1 is a partial example of the database that is used to represent the territory. The 

database format and contents are specified in the AREMA Recommended Practices. 

Starting from the left you can see the specific identity of the block currently being 

occupied by the head of the train. This is used as the entry point into the database. For 

example the block labeled 1–10 in Figure 2 (on the left side of the diagram) identifies 

Track 1, Block Number 00010. This correlates to the Block ID 100010 in row 13 of 

Table 1. (The lead portion of the address for all the blocks consists of the RRR.LLL 

ATCS address, which specifically identifies the railroad number and line number being 

operated). Because all of the territory being discussed is on the same RRR.LLL section, 

that portion of the address is not included in what is shown. Methods of transitioning 

between RRR.LLL segments are included in the manual parts. By knowing what block is 

currently occupied, you can also determine the grade, curvature, civil speed limit (a code 

based on train type) as well as which blocks will be occupied as you progress along the 

track. 

10
Row 

Number

Track 

Section 

(Block 

ID)

Track 

Subsection

Subsection 

Type

Ck 

Address Status St Lat St Lon

End 

Lat

End 

Lon St MP

End 

MP

Block 

Length 

(feet) Grade Curve

Curve 

Length

Civil 

spd

Track 

Section & 

Subsection 

UP

T

Sec

Sub

12 199900 00 99 0 0 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 99999 0 0 0 0 10001000 00013 100010 00 17 0 0 43.0500 76.0000 43.0500 76.0259 0.0000 1.1364 6000 0 0 0 060 10002001 19914 100020 01 03 001.03.01 0011(N) 43.0500 76.0259 43.0500 76.0272 1.1364 1.1932 300 0 0 0 060 10002002 10015 100020 01 03 001.03.01 1100(R) 43.0500 76.0259 43.0500 76.0272 1.1364 1.1932 300 0 0 0 030 10002002 10016 100020 02 03 001.03.01 0011(N) 43.0500 76.0272 43.0500 76.0274 1.1932 1.2027 50 0 0 0 060 10003000 10017 100020 02 03 001.03.01 1100(R) 43.0500 76.0272 43.0500 76.0274 1.1932 1.2027 50 0 0 0 030 10003000 10018 100020 03 03 001.03.01 0011(N) 43.0500 76.0259 43.0500 76.0272 1.1364 1.1932 300 0 0 0 030 10002002 30019 100020 03 03 001.03.01 1100(R) 43.0500 76.0259 43.0500 76.0272 1.1364 1.1932 300 0 0 0 030 10002002 30020 100030 00 01 0 0 43.0500 76.0274 43.0500 76.0533 1.2027 2.3390 6000 0 0 0 060 10004000 10021 100040 00 01 0 0 43.0500 76.0533 43.0500 76.0791 2.3390 3.4754 6000 0 0 0 060 10005001 10022 100050 01 02 001.03.02 0011(N) 43.0500 76.0791 43.0500 76.0793 3.4754 3.4848 50 0 0 0 060 10005002 10023 100050 01 02 001.03.02 1100(R) 43.0500 76.0791 43.0500 76.0793 3.4754 3.4848 50 0 0 0 030 10005003 10024 100050 02 02 001.03.02 0011(N) 43.0500 76.0793 43.0500 76.0800 3.4848 3.5133 150 0 0 0 060 10006000 10025 100050 02 02 001.03.02 1100(R) 43.0500 76.0793 43.0500 76.0800 3.4848 3.5133 150 0 0 0 060 00000000 100

Table 1. ICBS Simulated Territory Database

11
2.6 CBS SYSTEM DEMONSTRATION TESTS AND CONCLUSIONS 

RRR = 050, LLL = 001

GETS W ayside

RRR = 050, LLL = 002

SSC W ayside

RRR = 620, LLL = 001

US&S W ayside

GETS SLP SSC SLP U S&S SLP

C omms Simulator

C AD Simulator

Vehic le Simulator

Vehic le Simulator

Vehic le Simulator

GETS OBLP

Als tom OBLP

U S&S OBLP

GETS W A SSC W A U S&S W A

Sw itc h Panel

(8 s w itc hes ) Sw itc h Panel

(8 s w itc hes )

Sw itc h Panel

(8 s w itc hes )

W A Simulator f or > 8 inlputs

8 lines 8 lines

8 lines

C ontrols and Indic ations

Interoperable Mes s age

Formats Interoperable Mes s age

Formats

Als tom W A

Sw itc h Panel

(8 s w itc hes )

8 lines

RRR = 620, LLL = 002

Alstom W ayside

Als tom SLP

Representation of Overall Test Layout

Figure 3. Architecture of the simulation environment 

The dispatch office (CAD Simulator in Figure 3) is based on existing US&S control 

office technology, provides simulated office control for routing trains and tracking 

movement. The dispatch office communicates with the SLPs individually over a 

GENISYS communications link. This link transfers the nonvital controls and indications 

discussed previously. GENISYS is a communications protocol widely used in existing 

cTc systems and was chosen primarily due to availability of existing hardware and tools. 

A variety of other protocols currently being used (e.g., ATCS, IP, and Datatrain) could 

have easily been substituted. Each of the suppliers provided the SLPs for their specific 

section. The SLPs communicate through the communications router to the WAs (for 

monitoring and controlling switches), trains within their territory, and adjacent SLPs 

(necessary for trains to know advance information as well as to allow trains to be cleared 

out of territories behind them). 

All communications between the SLPs, OBLPs and WAs were routed through the 

communications router (identified as communications simulator in the above drawing. 

Each of the subsystems within the complete territory has a unique address based on the 

ATCS addressing schemes described in the AREMA Recommended Practices and in 

wide use throughout the rail industry today. Messages from each device were transported 

via an IP protocol to the communications router, which then routed the messages to the 

12 
correct location based on the embedded ATCS destination address in the message. Figure 

4 shows a screen capture of the CBS Communication Router. 

Figure 4. CBS Communication Router 

The upper portion of the screen shows each of the available communication paths. Each 

path can be individually selected and a delay time or error rate can be entered into that 

specific path. This feature will allow any future testing to closely simulate actual RF 

transmission delays (e.g., approximate different data transmission rates) or to simulate 

system response when a certain percentage of each transmission along that specific path 

is corrupted. The middle screen allows the user to select which of the transmission paths 

should be displayed in the lower portion of the screen. With this capability, the user can 

focus on messages among specifically identified subsystems to enhance debugging. The 

bottom portion of the screen shows in real time the messages being sent over the chosen 

links. Selecting any of the messages individually brings up a detailed screen showing the 

actual contents of the message (e.g., ATCS address, CBS message header, actual message 

contents). In addition, all of the data being seen can be recorded to a file for later 

analysis. 

13 
The SLP simulator reads an input file at start-up to set the states for signal and switch 

indications. For example, all the signals might be cleared for a movement in one direction 

on one track and the opposite direction on the other track. Messages are supported for 

links between the SLP, adjacent SLP, WAs and OBLPs. Figure 5shows the SLP 

simulator for the GETS territory. The upper portion of the display shows the status of all 

the switches in the territory. This can also be used to change a switch position causing the 

SLP to generate a switch position command message to be sent to the proper WA. The 

lower portion of the display shows all of the messages being handled by the SLP. 

Figure 5. GETS Signal Logic Processor Simulator 

The WA simulator (Figure 6) receives messages from the SLP causing switches to be 

moved, then sends the message back to the SLP when the actual movement has taken 

place. The upper portion of the display shows the status of the switches and the lower 

portion shows all of the messages passing through this particular WA. By selecting a 

different position for the switch than actually commanded to in the upper portion of the 

display, a switch can be forced to an improper position (or an unknown position) and the 

information sent to the proper SLP. 

14 
Figure 6. Alstom Wayside Appliance Simulator 

The OBLP simulator provides both vehicle movement simulation, and message handling 

capability for OBLP functionality. For the movement simulation, the upper left portion of 

the display is used to define the desired movement, from there, you can select the 

territory, block ID and desired direction where the simulator will initiate movement. You 

can also select the desired acceleration and deceleration rates for the train. When you 

start the simulation, the simulator initiates sending location messages from the specified 

location. At the lower left of the display, you can select the desired speed and choose to 

either accelerate or brake. After setting the desired speed, the accelerate button will cause 

the train to accelerate to and then maintain that speed. The simulator also has the 

capability of enforcing a stop prior to a absolute stop aspect (e.g., a red signal) being 

approached. This capability can be overridden by deselecting the “enable autostop 

function” on the screen. The center section of the display on the left shows the current 

cab signal aspect for the block being occupied, the identity of the block (and subsection 

of the block) being occupied, the current civil speed (as determined from the database), 

the actual speed, and the distance to the end of the block. If you have accelerated to a 

level above the currently allowed speed, the red overspeed indication will flash. 

On the upper right side of the display, you can see the identities of the blocks being 

occupied by the entire train (from front to rear), as well as the status of the signals and 

15 
switches being approached. The lower right portion of the screen shows all the messages 

sent and received by this OBLP. 

Figure 7. Union Switch & Signal OnBoard Logic Processor Simulator 

16 
When fully integrated, the demonstration showed the ability of trains controlled by 

different suppliers OBLP’s (each simulating a different railroad) to seamlessly move 

through the four territory sections, each of which is controlled by equipment from a 

different supplier. The following figures show the equipment supplied by each of the 

suppliers. 

Figure 8. ICBS project equipment located at the Critical Link facility 

In Figure 8, starting from the left in the back are the GETS OBLP rack, the Alstom 

OBLP rack, the Alstom rack with SLP and WA, the GETS rack with SLP and WA, the 

Safetran rack with SLP and WA, and the US&S rack with SLP and WA. In the front of 

Figure 8 are two screens for the CAD system (one showing the complete territory and 

one with a more detail view). Next to those screens are screens for the communications 

router and other simulators if needed. Figure 9 shows a close-up view of the CAD 

screens. 

17 
Figure 9. A close-up of CAD screens 

The GETS UltraCab carborne equipment is also the equipment currently being used in 

revenue service on the incremental train control system (ITCS) system installed on the 

Michigan High Speed Rail Line as well as in revenue service for the ITCS installation in 

China. The CRT screen is used for their vehicle simulation as well as showing aspect 

information. The normal ITCS display is located to the left of the rack. 

18 
Figure 10 The GETS carborne equipment

19 
The Alstom carborne equipment includes the MicroCabmaticTM equipment currently in 

revenue service. This is the same equipment that will be used for equipping the New 

York City area Metro North Railroad vehicles for ACSES and conventional cab 

signaling. 

Figure 11. Alstom OBLP 

The Alstom rack (see Figure 12) contains their SLP and WA. This equipment is based on 

their VPI Vital Processor Interlocking product used widely in revenue service around 

the world. 

20 
Figure 12. Alstom SLP and WA 

 

21 
Figure 13. GETS SLP and WA 

22 
Figure 14. Safetran SLP and WA. 

23 
Figure 15. The Anslaldo-STS (US&S) equipment. Both their SLP and WA are based 

on their MicroLok product line 

With all the suppliers’ equipment in place, the following scenarios were verified as 

working. As a way of demonstrating that the overall architecture and message 

interoperability operated as intended. 

 Control / Monitoring of power switches 

Starting with a request from the control office, a control message was sent via the 

GENISYS link to the appropriate SLP, the SLP verified that conditions permitted 

safely moving a switch and sent the CBS message through the communications 

router to the WA controlling the addressed switch. The WA changed the physical 

output controlling the switch and sent the appropriate CBS message to the SLP 

when the switch had been physically moved (simulated movement). The SLP then 

sent the indication back to the control office so that the control office could show 

the position of the switch in the field. 

 Supplier A OBLP operation on Supplier B territory 

Each of the OBLP suppliers was controlled across all four sections of the test 

setup to demonstrate interoperability with all of the other suppliers. This included 

24 
handoff from one section to another (additional details below). Various switches 

were thrown and signals cleared in front of the train movement so that a variety of 

routes were taken throughout the territory. 

 Upgrade/Downgrade of Cab Signal 

Once in a block, the cab signal for a suppliers locomotive would be upgraded 

(changed to a less restrictive aspect) or downgraded (changed to a more restrictive 

aspect) by having the office request upgrades or downgrades of the signals in 

front of the train. 

 Overspeed / Profile Stop 

Although not part of the interoperability Recommended Practices, the OBLP 

would cause the train to go into a braking mode if the train exceeded the civil 

speed allowed in the database, or cause the train to stop prior to an upcoming red 

signal (positive stop). 

 Clear for following move with a second supplier ‘s OBLP following through the 

territory 

One suppliers’ OBLP was controlled through the territory with a second 

suppliers’ OBLP immediately following the first move (at a safe distance). This 

includes following moves between sidings—a property inherent to signal systems. 

 Two suppliers’ OBLP's proceeding in one direction (following moves) through a 

territory with a third OBLP (simulated to look like a third supplier) traveling in a 

different direction (on a different track or cleared for a route that would not put it 

in conflict with the first moves). 

 Supplier A OBLP leaving Supplier B territory and entering Supplier C territory. 

This includes the ability to obtain signal and switch information from Supplier C 

for the OBLP before entering the territory, as well as conveying information back 

to Supplier B territory allowing the blocks to be cleared after the OBLP has left 

the territory. This also included verification that “traffic” logic was defined, 

which would prevent two trains from being cleared for movements toward each 

other at supplier boundaries. 

 Change in the available onboard information when the switch and signal status is 

changed on the planned route. 

This verified that Supplier A locomotive could see information from changes in 

Supplier C route status (e.g. switch and signal information) prior to entering 

Supplier C territory. 

25 
26 

As expected, we learned new information as the detailed designs of the subsystems and 

messages were implemented by each of the suppliers. Continuous communication among 

the participants keeps everybody aware of corrections or enhancements that are necessary 

for the successful implementation of the project. 

Lessons learned from this demonstration project were used to enhance and expand these 

manual parts, but subject to committee approval. Status reports are provided to AREMA 

Committee 37 as well as other interested parties, such as the AAR Railway Electronics 

Standards Committee (RESC). These lessons learned were used to update the AREMA 

Manual Parts described above and they have been submitted to AREMA Committee 37 

for approval. Most likely, they will be published in the upcoming 2010 Manual of 

Recommended Practices for Communications and Signaling. 

Successful completion of this demonstration showed a high level of cooperation among 

the principal suppliers of signaling systems for North American railroads toward 

implementing an interoperable system that should serve the railroads well for the longterm future. The CBS approach can be viewed either as a complementary enhancement or 

an alternative to overlay systems currently being tested by some North American 

railroads. Overlay systems are safety justified based on the underlying method of 

operation being maintained, if that underlying method be rules-based (e.g., dispatcher 

issued train orders) or signals-based (cTc). Without the ability to change the underlying 

method of operation, operating efficiencies are more difficult to achieve, such as closer 

spacing, increased velocity, or the ability to support following moves between switching 

points. Because CBS is based on well-accepted signaling principles and implementations 

are based on proven safety-critical architectures (many already in revenue service), CBS 

can be used as a stand-alone system allowing replacement or enhancement of the existing 

method of operation. Removing the physical limitations of existing wayside-based cTc 

systems provides for improved performance (e.g., ability to increase traffic density by 

shortening block length or by increasing the number of signal aspects available). 

Additional capabilities through the use of digital radio transmission allows for continuous 

onboard display of signal aspects, which allows them to be updated mid-block as well as 

providing continuous speed enforcement. 

3.0 References 

[1] AREMA Manual of Recommended Practices on Communications and Signaling 

(2009), www.arema.org