MAY 1995


Revision Date of Release Affected Pages Purpose of Change & Applicable SPRs
4.0 5/95 2-1, 2-2 SPR 180 - added version numbers in "Applicable Documents".
4.0 5/95 3-3 SPR 195 - added "braking" to predictive enforcement.
4.0 5/95 3-7, 3-9 SPR 238 - second paragraph - LSI references modified; SPR 207 - last paragraph - removed references to withdrawn specifications.
4.0 5/95 3-10 SPR 238 - Figure 3-4 changed voltage to +15Vdc, removed SCU from ILC box.
4.0 5/95 3-10 SPR 238 - Figure 3-5 changed voltage to +15Vdc.
4.0 5/95 2-1, 3-13 SPR 208 - removed reference to withdrawn Specification 150 - deleted last paragraph.
4.0 5/95 All SPR 179 - checked for any grammatical/typo errors for consistency in specification format.
3.0 3/93 All Remove control flows and associated descriptions. SPR #67. Revised footer, Sections 1.0 and 2.0, 3.0 - 4.0, Appendix A and Appendix B.






1.0 SCOPE 1-1







3.1.1 Dispatch System 3-5

3.1.2 Communications System 3-7

3.1.3 Locomotive System 3-7

3.1.4 Field Systems 3-9

3.1.5 Work Vehicle System 3-9

3.1.6 System-Wide Considerations 3-12 Environment 3-12 Packaging 3-12 Software 3-12






Appendix A - Glossary A-1


Appendix B - Conventions and Assumptions B-1


Purpose of ATCS Specifications

This specification for Advanced Train Control Systems (ATCS) has been developed through a public, open-forum process involving contracted systems engineers, railroad industry professionals, and suppliers. The purpose of this and other ATCS specifications is to define the performance and interface requirements for ATCS hardware and software. ATCS specifications are designed to document the stated requirements of railroad operational and technical professionals concerning ATCS hardware and software. These specifications are designed to facilitate compatibility and standardization without limiting the internal design approaches of individual suppliers.

Publication of this specification does not commit any railroad to purchase any hardware or software described herein, require any railroad to use this specification for the purchase of hardware or software generally described, nor constitute endorsement of any supplier's product designed or built according to this specification. Decisions to purchase any product developed in accordance with this specification are matters of discretion and judgment on the part of individual railroads and individual suppliers.



This document sets forth the system architecture for the Advanced Train Control Systems. This specification identifies the hardware and software components of ATCS, their functions and the nature of the interfaces between them. Companion specifications describe the architecture of the ATCS communications system, locomotive system, track forces system, field system and the computer-aided dispatch system. These five system architecture specifications identify the specific hardware and software requirements that apply to the respective systems and define the integration requirements for each. System logic specifications exist for the locomotive, track forces, field and dispatch systems. These specifications describe the logic and data flow within and among the various systems. This document also defines a glossary, and conventions and assumptions. The glossary, and conventions and assumptions are considered commentary and are not part of the standard.

Equipment suppliers should note that this and related ATCS documents encourage them to produce high-performance, low maintenance, high-reliability equipment. They are free to accomplish these objectives and satisfy the requirements of this specification by means of design techniques and technology which they consider to be cost effective and appropriate. Compliance with these specifications does not imply automatic compliance with existing regulatory and safety requirements. Suppliers providing and railroads purchasing hardware and software for ATCS must ensure independently their compliance with the appropriate regulations.





The following documents are a part of this specification to the extent that they are referenced herein. In the event of a conflict between the documents referenced herein and the requirements of this specification, the contents of this specification shall take precedence.

ATCS Specification 110, Version 4.0, Environmental Requirements

ATCS Specification 130, Version 4.0, Recommended Practices for Software Quality Assurance

ATCS Specification 140, Version 4.0, Recommended Practices for Safety and Systems Assurance

ATCS Specification 153, Version 4.0, System Logic - OBC

ATCS Specification 154, Version 4.0, System Logic - CDC

ATCS Specification 155, Version 4.0, System Logic - WIU

ATCS Specification 156, Version 4.0, System Logic - TFT

ATCS Specification 160, Version 4.0, Configuration Management Plan

ATCS Specification 200, Version 4.0, Communications System Architecture

ATCS Specification 210, Version 4.0, Mobile Communications Package

ATCS Specification 220, Version 4.0, Front End Processor

ATCS Specification 225, Version 4.0, Cluster Controller

ATCS Specification 230, Version 4.0, Base Communications Package

ATCS Specification 250, Version 4.0, Message Formats

ATCS Specification 300, Version 4.0, Locomotive System Architecture

ATCS Specification 310, Version 4.0, Locomotive Computer

ATCS Specification 311, Version 4.0, Predictive Enforcement Braking

ATCS Specification 320, Version 4.0, Locomotive Displays & Controls

ATCS Specification 335, Version 4.0, Transponder/Interrogator

ATCS Specification 400, Version 4.0, Dispatch System Architecture

ATCS Specification 500, Version 4.0, Field Systems Architecture

ATCS Specification 530, Version 4.0, Wayside Interface Unit

ATCS Specification 600, Version 4.0, Work Vehicle System Architecture

ATCS Specification 610, Version 4.0, Track Forces Terminal

ATCS Specification 620, Version 4.0, Work Vehicle Display and Control Unit



The basic principle behind ATCS is to provide a cost efficient, safe, modular, train control system with an open architecture. The primary goals of the system are to provide for:

compatibility of systems across railroads. This helps to ensure seamless operation. For example, locomotives from one railroad will be able to communicate, via data radio, with dispatch centers from other roads when operating on their track. Certain baselines, such as standard communications protocols and message formats, have been developed to ensure this goal is met.
the ability for each railroad to selectively implement the capabilities and features it needs. Full-fledged ATCS implementation on an entire railroad is not always appropriate or feasible. ATCS has been designed to allow for selective implementation on various parts of a railroad.
a modular growth path from less capable implementations to more capable implementations. This eliminates the need for an "all-at-once" approach that would be difficult and expensive to achieve. In fact, railroads can implement ATCS at a rate that makes sense from both the service and fiscal points of view.
the ability to implement a system with components from different suppliers. This relieves the railroads of the need to purchase potentially expensive and complex converters that are often needed to interconnect and interface various vendor components. As a result, user costs should be reduced by providing for expanded sources of supply.

The approach that has been taken to achieve these goals is to develop performance and interface specifications (also called form-fit-function or F3 specifications) for ATCS components that stress:

functions to be performed;
performance levels to be achieved;
interfaces (electrical and data);
box sizes, shapes and mounting (i.e., mechanical interfaces);
environmental constraints; and
design standards (hardware and software).

ATCS specifications do not dictate internal design and construction of system components; they do, however, explicitly define functionality and interfaces without limiting supplier design creativity. The critical aspect of the specifications is the interfaces, which must be strictly adhered to in order to ensure an open, extensible system.

ATCS specifications represent the minimum requirements necessary to achieve component interoperability. There are, however, aspects of system operation which do not impinge on component interoperability, and must therefore be specified by the procuring railroad. Items that must be specified by the procuring railroad include:

procedures for dispatcher position changes;
the specifics of interfaces to corporate data systems (e.g., form and format of data queries and responses);
any special add-on devices or computer programs that adapt ATCS to individual railroad operating practices;
detailed implementation of software functions; and
restrictions on or requirements for other implementation issues such as operating system selection, fail-over techniques, transaction scheduling, and algorithm design.


The primary ATCS functions are:

management of track occupancies through centralized route and block interlocking logic;
issuance of movement authorities via the data link to equipped trains and work vehicles, and via voice radio to unequipped trains and work vehicles;
tracking of equipped train location and track occupancies via the data link, and unequipped train location and track occupancies via voice reports and manual entry;
speed enforcement for equipped trains;
enforcement of limits of authority for equipped trains;
pacing for fuel economy for equipped trains;
monitoring and control of wayside systems;
reporting of equipped train diagnostics and operating parameters; and
general exchange of instructions and messages.

These functions are implemented in a common system architecture with system configurations determined by individual railroads.

Figure 3-1 shows the ATCS architecture, which is comprised of five major systems. Four of these systems are the information processing systems that reside at the central dispatch office (the Central Dispatch Computer), on-board locomotives (the On-Board Computer), on-board work vehicles (the Track Forces Terminal) and in the field (the Wayside Interface Unit). These systems collect, process, and distribute data with minimal input from dispatchers, enginemen, and foremen. The fifth system and the ATCS keystone, is the modern data communications system, which ties the various information processing systems together and significantly reduces the need for voice communications.

The function of the dispatch system is to manage the movement of trains throughout the rail network with the objective of guaranteeing safe operations without incurring train delays. The function of the locomotive system is to provide automatic location tracking and reporting, predictive enforcement braking, and automated transmission of movement authorities and switch monitoring and control information via the data communications system. The primary function of the work vehicle system is to provide the capability for a track maintenance foreman to communicate with the central dispatch system and other vehicles via the data communications system. The ATCS field system is designed to provide remote monitoring and control of wayside devices.

ATCS has been designed for modular expansion, which allows for varying levels of operational sophistication. Three basic levels of operation have been identified, although many hybrid configurations are expected in actual installations. The three basic levels and their capabilities are shown in Table 3-1.

Centralized Route/Block Interlocking R R  
Voice Delivery of Mas/Operating Instructions R R* R*
Data Delivery of Mas/Operating Instructions   R R
Voice Reporting of Train Location R R* R*
Manual Reporting of Train Location/Auto. Delivery   R R*
Automatic Reporting and Delivery of Train Location     R
Speed Enforcement     R
Movement Authority Limit Enforcement     R
Mon./Ctl. Field Dev. by Code Lines from Central O O O
Mon./Ctl. Field Dev. by Datalink from Central


Mon./Ctl. Field Devices from Loco. Cab   O* O*
Automatic Reporting of ATCS Device Health   R R
Automatic Locomotive Health Reporting   O O
R = Required capability for this level

R* = Required capability to support fall back to lower operating levels

O = Optional capability

O* = Optional capability for field and central/required on locomotives

Level 30 operation assumes that trains are equipped with an enforcement system, a datalink system, an on-board computer, a location system, and a display. Field devices may or may not be ATCS equipped and/or controlled. The dispatcher has a computer (CDC) which can communicate via the datalink to the on-board ATCS equipment and ATCS equipped field devices.

Level 20 operation is similar to Level 30 operation except that the train has no enforcement capability, no location system and less sophisticated on-board processing capability.

Level 10 operation is similar to Level 20 and 30 operation except that the train has no on-board ATCS equipment, or the ATCS equipment on the train is disabled or turned off. Note that in Level 10 no capability exists for the train to contact equipped field devices directly. Also note that field devices are able to function unaware of the equipped level of the train.

In Level 10 operation, the dispatcher delivers Track Condition Notices (TCNs) and Track Work Protection (TWP) to the engineman or foreman via the voice radio. Where railroads have mechanisms in place to deliver written TCNs and TWPs, a confirmation that the items are on hand should be substituted for voice delivery. It is important, however, that the CDC receive verification that the crew has these items in hand.

ATCS can be viewed in a broader perspective than simply a 'new and improved' train control system. In its most general form, ATCS is a large distributed information processing system which can provide additional benefits to the railroads by performing applications besides train control. These applications include work order reporting, locomotive health monitoring, codeline replacement, and track force data communication.

Work order reporting can be streamlined by using the data communications system to provide timely exchange of information on pickups and setouts between the central dispatch system and locomotives. Work orders can be sent to the locomotive as part of a data download at the beginning of a trip, and can be updated while the locomotive is en route. Timely reporting of completed work can ensure that traffic management systems provide up-to-date information for customer queries.

Locomotive health monitoring systems, which aid in the evaluation of locomotive performance and failure diagnosis, can also make use of the data communications system. On-board sensors can be used to continuously monitor critical mechanical and electrical parameters; data on those parameters can either be "massaged" on-board or transmitted in "raw" form to a central maintenance facility via the data communications system. Remote monitoring at the central facility might be used to optimize fueling procedures, detect incipient failures, diagnose transient or intermittent failures, or provide the basis of a reliability centered maintenance program (as contrasted with a fixed inspection schedule).

The ATCS data communications system can also be used for code line replacement. Code messages generated by existing code systems could be translated into ATCS messages and sent to Wayside Interface Units, where they would be re-translated into the original code message for interfacing to existing signal systems.

Voice communications between the dispatcher and track foreman can be significantly reduced by using the data communications system to transmit work requests and to report work completed. Retrieval of pertinent track data or other information might be made transparent to the dispatcher by using the data communications system.

The applications mentioned above do not require the train control application to be implemented; however, there is considerable benefit in having a standardized infrastructure of communications, message formats, and processing capability upon which to overlay these and the many other applications that will undoubtedly be developed in the future.

3.1.1 Dispatch System

The Dispatch System, shown in Figure 3-2, is the central operating and controlling host of the Advanced Train Control Systems. Key elements of the Dispatch System are the dispatching consoles, the Central Management Computer (CMC) and the Central Safety Computer (CSC). The front end processor and the corporate MIS interface are important interfaces between the dispatch system and the railroad. The Dispatch System is specified in ATCS Specifications 154 and 400.

The dispatching consoles form the man-machine interface between the dispatchers and the Dispatch System. As this interface does not directly impact on interoperability, the consoles are not standardized. Dataflows between the man-machine interface and the CMC/CSC are defined as part of ATCS Specifications 154 and 250.

The Central Management Computer assists the dispatcher in performing the general planning and other non-critical functions of train dispatching including handling of non-vital message traffic. This element is only partly standardized. Certain planning and management functions are central to the operation of ATCS; however, many embellishments are possible and these are not standardized.

The Central Safety Computer performs the function of tracking and managing movements and requested movements. This involves detection of potential conflicts, setting routes, monitoring the status of switches and grade crossings, and tracking train progress. This system also performs the tasks necessary to send and receive vital data messages. The safety system is functionally standardized and specified in ATCS Specification 154.

The interface to Corporate MIS is not standardized; it handles the formatting of data so that various corporate data systems, such as crew scheduling, motive power, or billing can share data with the ATCS management system, and so that the Central Safety System can obtain train consist data from Corporate MIS. Optionally, this consist data may be entered into ATCS manually. Dataflow between ATCS and Corporate MIS are defined as part of ATCS Specification 154 and ATCS Specification 250, Appendix L.

3.1.2 Communications System

The ATCS Communications System, which significantly reduces the need for voice communications, is the mechanism by which the diverse elements of ATCS exchange data. The communications system is composed of two major segments; a ground segment and an RF segment. Figure 3-3 depicts the system topology. The ground segment consists of Front End Processors connected to one or more Cluster Controllers; each Cluster Controller controls a number of base stations or wayside devices. The detailed topology and physical method of connection (leased line, fiber optic, microwave, etc.) is a railroad option. The specifications for the network are flexible enough to allow nearly any topology or mode of ground connection to be used. The general architecture of the communications system, including a detailed description of the system protocols, is contained in ATCS Specification 200; specifications for the Front End Processor, Cluster Controller, Base Communications Package (BCP), and Mobile Communications Package (MCP) are contained in ATCS Specifications 220, 225, 230, and 210, respectively.

The Base Communications Packages (BCP) interface the ground segment to the RF segment of the communications system. Mobile Communications Packages (MCP) interface clients to the RF segment of the communications system or (optionally) to the ground system directly. MCP clients include wayside interface units, on-board computers, and track forces terminals. The RF segment operates at 4800 bits per second in the 900 MHZ radio band.

ATCS Specification 250 defines the message formats and data dictionaries necessary to standardize information transfer over the data communications system.

3.1.3 Locomotive System

The function of the locomotive system is to provide automatic location tracking and reporting, predictive enforcement of speed and authority limits, automated transmission of movement authorities, and switch monitor and control information via the data communications system. The locomotive equipment required to provide these level 30 capabilities is shown in Figure 3-4.

The locomotive equipment required to provide the level 20 functions of automated transmission of movement authorities and switch monitor and control is shown in Figure 3-5. Level 10 ATCS does not require on-board locomotive ATCS equipment. The 300 series specifications address ATCS locomotive system requirements. ATCS Specification 153 addresses locomotive on-board computer software requirements for level 30 locomotives, and for level 30 locomotives operating at level 20.

The Association of American Railroads' Task Force on Locomotive Systems Integration (LSI) has the mission to "develop a practical approach to the integration of the new electronic and mechanical components on locomotives" (per Minutes of Locomotive Systems Integration Committee Briefing to Locomotive Suppliers, September 5, 1991, Montreal, Quebec, dated September 11, 1991). An architecture to achieve this mission has evolved in the LSI Specifications which describe multiple configurations of electronic and mechanical components in a locomotive cab. LSI Configuration 1, described in the LSI Architecture Specification, shows

how an ATCS on-board computer (OBC) fits into the LSI architecture. As a variant to LSI Configuration 1, the ATCS OBC can be used as the interface to the brake sensors and penalty brake. In this alternate configuration, defined for retrofitting ATCS into non-LSI locomotives, the ATCS OBC takes the position of the Intelligent Brake Controller as shown in LSI Configuration 1. Reference the LSI Specifications for further detail on the LSI configurations.

3.1.4 Field Systems

The primary function of the ATCS Field System is to provide remote monitoring and control of wayside devices by the dispatching system, locomotives and track forces. An ATCS Field System is comprised of a Wayside Interface Unit (WIU) and an MCP (see Figure 3-6). The WIU provides the interface between wayside devices and the MCP. Up to 30 wayside devices can be connected to the ATCS Communications Systems via a single WIU and MCP. Wayside devices include power- and hand-operated switches, railway crossings at grade, train defect detectors and track integrity indicators. ATCS Specification 155 and the 500 series specifications address ATCS field system requirements.

Existing code line systems can be replaced with the use of the ATCS data communications system and code line protocol converters (see Figure 3-7), which would translate code messages into ATCS messages and vice versa.

3.1.5 Work Vehicle System

The primary function of the work vehicle system is to provide the capability for a track maintenance foreman to communicate with the Central Dispatch System and other vehicles via the data communications system. The system is designed to support various data input and output functions including switch monitoring and control; requesting, securing and releasing authority for track occupancy; requesting and receiving slow orders for designated mileage limits; transmitting slow order requirements to the central dispatch system; transmitting work reports to the central dispatch system; releasing slow orders; and requesting and receiving advisories. The work vehicle equipment required to provide level 20 capabilities is shown in Figure 3-8.

The work vehicle equipment required to provide these level 20 capabilities and the level 30 capabilities of automatic location tracking and reporting is also shown in Figure 3-8. ATCS Specifications 156 and 600 address ATCS Work Vehicle system requirements.

3.1.6 System-Wide Considerations Environment

Advanced Train Control Systems equipment will be subjected to a rather diverse set of environments, depending upon the nature and location of the equipment. ATCS Specification 110 provides a central repository for descriptions of environmental conditions for vehicle interiors (cab and non-cab), vehicle exteriors (body and truck mounted), wayside outdoors, wayside bungalows and instrument cases, wayside control rooms, computer rooms, and road beds. Each ATCS device specification will refer the reader to appropriate sections of ATCS Specification 110. Packaging

One of the goals of ATCS is the development of a set of standardized, modular train control devices. To further this goal, each ATCS component (device) specification contains information on physical (e.g., size, mounting) requirements for that component. Software

The ATCS system is highly dependent upon software. The extreme importance of proper software design to system safety demands that certain assurances be made by the ATCS supplier to the railroad purchaser. ATCS Specification 130 contains a set of standard practices and guidelines for Software Quality Assurance. Some or all of these practices and guidelines will be required by the purchasing railroad; in fact, the roads are encouraged to specify their own quality assurance procedures, as well. Detailed requirements for OBC, CDC, WIU, and TFT software are identified in ATCS Specifications 153, 154, 155, and 156, respectively.


System logic specifications (also known as Control Flow Specifications) contain a detailed functional description of how ATCS controls rail traffic. The control flows shall be construed as part of the specification for each ATCS component. Adherence to these control flows is as important to interoperability as adherence to the communication protocols and transponder specifications.

The Control Flow Specifications for the On-board Computer, Central Dispatch Computer, Wayside Interface Unit, and Track Forces Terminal are contained in ATCS Specifications 153, 154, 155, and 156, respectively. These specifications, which contain detailed functional requirements, are written in machinable code (Ada-syntax Program Design Language).



Recommendations for software quality assurance procedures throughout the ATCS life-cycle are contained in ATCS Specification 130. Recommended practices for safety and systems assurance are contained in Specification 140.


Appendix A - Glossary

This appendix contains a summary of some of the terms, abbreviations and acronyms used in ATCS specifications.

AAR - Association of American Railroads

ACK - Acknowledgement

ADDR - Address

ATCS - Advanced Train Control System

ATSO - ATCS Technical Support Organization

BCP - Base Communications Package

Boundary - The furthest reaches of a single Movement Authority, Track Condition Notice or Track Work Protection

BTIM - Base Time Entity

BU - Basic Unit

BWEMA - Bidirectional Work Equipment Movement Authority

CC - Cluster Controller

CCB - Configuration Control Board

CDC - Central Dispatch Computer

CDR - Critical Design Review

CDU - Control Display Unit (on locomotive)

CDS - Corporate Data System

CFR - Code of Federal Regulations

CHAR - Characteristics

CI - Configuration Item

CM - Configuration Management

CMC - Central Management Computer

CMP - Configuration Management Plan

CMS - Code Management System

COMM - Communications

CP - Control Point

CRC - Cyclic Redundancy Check

CSC - Central Safety Computer

CSDC - Component Specification Drafting Committee

CSHA - Code-Level Software Hazard Analysis

CTC - Centralized Traffic Control

CTL - Controlled, Controllable

DB - Data Base

DCU - Display and Control Unit

DDAT - Dispatch System Database Manager

DDHA - Detailed Design Hazard Analysis

DEMH - Dispatch System Emergency Handler

DEMP - Dispatch System Designated Employee

DHEL - Dispatch System Health/Status Monitor

Display Horizon - See Horizon

DIST - Distance

DLOC - Dispatch System Location Monitor

DMAH - Dispatch System Authority Handler

DMAN, DMNB, C - Dispatcher

DMIS - Dispatch System Management Information System

DMMI - Dispatch System Man Machine Interface

DPAC - Dispatch System Pacing Manager

DPSK - Differential Phase Shift Keying

DTIM - Dispatch System Time Manager

DTRK - Dispatch System Track Condition Notice and Track Work Protection Manager

DWAY - Dispatch System Wayside Manager

ECRW - Non-engineman train crew member

EIA - Electronic Industries Association

EMAN, EMNB, C - Engineman

EMERG - Emergency

EMI - Electromagnetic Interference

ESS - Environmental Stress Screening

ETU - End-of-Train Unit

FCC - Federal Communications Commission

FEA - Fault Effects Analysis

Feasibility - Check performed as part of validation to determine that

Check the requested/indicated function is possible given physical constraints

FEP - Front End Processor

FMAN, FMNB, C - Foreman

FMEA - Failure Mode Effects Analysis

FMECA - Failure Modes, Effects and Criticality Analysis

F3 - Form, Fit, and Function

GALL - All ground network devices

GBCP - Ground Network Base Communications Package

GCC - Ground Cluster Controller

GFEP - Ground Front End Processor

GINT - Ground Network Initialization Entity, provides address tables to mobiles on request

GPS - Global Positioning System

GTIM - Ground Time Entity

HDLC - High-Level Data Link Control

HOL - Higher-Order Language

HW - Hardware

HWY - Highway

ID - Identification, Identifier

INIT - Initialize

IV&V - Independent Verification and Validation

JWA - Joint Work Authority (Bidirectional, multiple trains) also called WRARS, WRAPA

LDAT - Locomotive Database Manager

LEMH - Locomotive Emergency Handler

LHEL - Locomotive Health Monitor

Limits - The furthest reaches of a train's authority determined by concatenating all MAs held by the train

LLOC - Locomotive Location Monitor

LMAH - Locomotive Authority Manager

LMMI - Locomotive Man Machine Interface

LOC - Location

LOCO - Locomotive

LOI - Location of Interest

LPAC - Locomotive Pacing Manager

LRU - Line Replacement Unit

LTRK - Locomotive Track Condition Notice and Track Work Protection Manager

LWAY - Locomotive Wayside Device Manager

MA - Movement Authority

MCP - Mobile Communications Package

MDSP - All Displays onboard a locomotive

MDT - Mean Down Time

MIS - Management Information System

MMI - Man Machine Interface

MON - Monitor

MP - Milepost

MPH - Miles per hour

MSG - Message

MTBF - Mean Time Between Failures

NACK - Negative Acknowledgement

NX - Entry Exit (referring to a control point)

OBC,03,02 - Locomotive Onboard Computer (03 and 02 also indicate level 30 and level 20 operating capability, respectively)

OPER, OP - Operating, Operate

OS - Operating System

PA - Proceed Authority (Unidirectional, single train)

PAUX - Locomotive Auxiliary Terminal

PAXG - Locomotive Axle Generator

PDR - Preliminary Design Review

PDSP - Locomotive Display Terminal

PDTR - Locomotive Data Recorder

PEID - Locomotive Engineman ID

PETU - Locomotive End-of-train unit

PHA - Preliminary Hazard Analysis

PHL - Preliminary Hazard List

PINT - Locomotive Interrogator

Plausibility - Check performed as part of validation to determine that Check the requested/indicated function is reasonable

PMCP - Locomotive Mobile Communications Package

PPTR - Locomotive onboard printer

PRA - Proceed Restricted Authority (Unidirectional, for following train or other circumstances where restricted speed is desired). Also called PRARS

PRAPA - Proceed Restricted Authority/Protect Against

PRARS - Proceed Restricted Authority/Restricted Speed

PRAT - Production Reliability Acceptance Test Program

PSEN - Locomotive Sensor Control Unit

PSL - Project Support Library

PSLS - Locomotive Secondary Location System

PU/SO - Pick Up/Set Out

QA - Quality Assurance

Rogue - A train occupying ATCS-controlled track without holding an MA authorizing it to do so

RCVD - Received

REQ - Request

RF - Radio Frequency

RFP - Request for Proposal

RN - Revision Notice

RPT - Report

RQT - Reliability Qualification Test Program

RR - Railroad

RTC - Rail Traffic Control

RTS - Railway to specify

RU - Reader Unit

Safety Check - Check performed as part of validation to determine that the requested/indicated function will not cause loss of life or property damage

SBD - Safe Braking Distance, the distance within which a train can be brought to a stop (reliably) with a full service brake application

SBD1 - Safe Braking Distance plus 1 minute at current speed

SBD2 - Safe Braking Distance plus 2 minutes at current speed

SCA - Sneak Circuit Analysis

SCCSC - Safety-Critical Computer Software Components

SETF - Systems Engineering Task Force

SPR - System Problem Report

SRHA - Software Requirements Hazard Analysis

SSAPP - Safety and Systems Assurance Program Plan

SSPP - System Safety Program Plan

TBD - To Be Determined

TCN - Track Condition Notice

TDAT - Track Forces Terminal System Database Manager

TDD - Train Defect Detector (includes hotbox detectors, high/wide detectors, etc.)

TDHA - Top-Level Design Hazard Analysis

TEMH - TFT Emergency Handler

TF - Track Force, sometimes specifically Track Foreman

TFT - Track Forces Terminal

THEL - TFT Health Monitor

TLOC - TFT Location Manager

TMAH - TFT Authority Manager

TMMI - TFT Man Machine Interface

TOP - Track Occupancy Permit (Bidirectional, exclusive of trains, multiple work vehicles)

TRR - Track Forces Terminal TWP/TCN Manager

TRX - Transaction

TTRK - TFT Track Condition Notice and Track Work Protection Manager

TWAY - TFT Wayside Device Manager

TWP - Track Work Protection (controlled by track crew foreman)

UWEMA - Unidirectional Work Equipment Movement Authority

Validate - Perform a series of checks to determine whether it is appropriate to perform an indicated or requested function. May include plausibility, safety, and/or feasibility checks.

VS - Versus

WA - Work Authority (Bidirectional, exclusive)

WCTL - WIU Controllable Device Manager

WEMA - Work equipment movement authority, unidirectional or bidirectional exclusive authority granted to work equipment to move at speed along the train.

WEMH - WIU Emergency Handler

WFPA - Wait for Proceed Authority

WHEL - WIU Health Monitor

WHWY - WIU Highway Device Manager

WIND - Wayside Indicator

WIU - Wayside Interface Unit (ATCS component to interface to field device)

WMMI - WIU Man Machine Interface

WNCD - WIU Non-Controllable Device Manager

WO - Work Order

Working Train - A length assigned to the train by the CDC for the

Length purpose of determining the location of the rear of the train. This length is greater than the current best estimate of train length by a factor that reflects the confidence in the estimate (lower confidence means larger safety factor).

WRAPA - Work Restricted Authority/Protect Against

WRARS - Work Restricted Authority/Restricted Speed

WSIG - WIU Signals Manager

WTDD - Wayside Train Defect Detector (e.g., hotbox detector) Manager

WTLD - Wayside Train Length Measuring Device

WWHC - Wayside Wheel Counter

WXNG - Wayside Highway Crossing Device

XID - Exchange identity, a procedure performed between onboard devices to determine vehicle identity, and the physical ports to which various logical entities are connected.

This procedure is defined in Specification 200.


XPONDER - Transponder


Appendix B - Conventions and Assumptions

This appendix contains a summary of some of the conventions and assumptions used in ATCS specifications.

The following assumptions are applicable to all control flows. ATCS Specifications 153-156 contain detailed descriptions of assumptions made in defining system logic.

Continuous track circuits are not necessarily installed. Powered switches and monitored wayside devices do have occupancy detection.

Where an application must respond to a message success or failure indication from the communications protocol stack, the requirement is defined in the Control Flow Specification.

Fixed route data is issued from one crew change point to the next.

Variable route data is loaded prior to reaching dispatcher boundary or on-line if changed en route.

MAs do not have explicit start times or end times associated with them.

The CDC is designed to allow it to be used to issue authorities only within the territory it controls. Furthermore, if more than one dispatcher is using a CDC, a dispatcher is only allowed to issue authorities within the territory he or she controls.

OBC/CDC/WIU/TFT are responsible for determining the proper addressee for messages they originate. The communications system provides transparent delivery.

ATCS does not provide broken rail protection.

Locomotive ID becomes known by the OBC at power up by the XID procedure described in ATCS Specification 200.

WIU and associated devices IDs are known to the WIU at startup by wiring in its harness, ROM, or other manufacturer defined mechanism.

The OBC will notify the engineman whenever enforcement is invoked, and whenever the train reverts to a lower operating level.

If a train reverts to a lower operating level due to a failure, it remains at that lower level for the remainder of its trip. If the train reverts to a lower operating level due to entry into a lower level territory, it may change back to the higher level upon entering higher level territory.

The following assumptions are applicable to the operation of trains over ATCS equipped wayside devices:

"Alerting" is a computer process which provides the functional equivalent of approach locking.

The OBC has wayside device data stored prior to operating over the device.

The device is within movement authority limits (the OBC shall not address any device outside the limits of movement authority).

Each command to set the position of a controllable device that is carried in an ATCS message contains the network address of the

vehicle on whose behalf the position is set, or a "wild card" address indicating multiple vehicles.

A wayside device shall send an emergency message to the vehicle and CDC when it is on alert and it deviates from its last command or becomes defective. A device shall send a non-emergency status message:

To the CDC when it is placed on alert or when its occupancy state changes.

To the CDC when its position changes or a malfunction is detected and it is not on alert.

Periodically to the vehicle while it is on alert.

A device will reject alert request(s) from other than the train/vehicle on whose behalf it was set (except if a "wild card" is used). A device shall be on alert for only one vehicle at a time, except where the device is an interlocking with independent routes, or a noncontrollable device protecting more than one track.

A device will not accept commands except from its master in a session. This implies field device maintainers must obtain a local session before taking a device off-line for maintenance.

A device will not accept an alert request for a route which is occupied. The device will respond to an alert when occupied with an alert request reject.

An OBC always interprets an alert request reject as a "not ok" status indication.

A device that is under local control for maintenance will reject alert requests.

The OBC will provide a mechanism for crew to manually cancel or re-initiate a device alert when stopped.

The data file of field devices in OBC will identify which, if any, along the route are ATCS equipped. If the device is not ATCS equipped, a message will be displayed to the engineman identifying the device, but the OBC will take no further action.

Equipped track forces operate over devices as does a Level 20 or Level 30 train. Unequipped track forces operate over devices as does a Level 10 train.