ATCS SPECIFICATION 100
REVISION 4.0
MAY 1995
CHANGE RECORD SHEET FOR ATCS SPECIFICATION 100
| 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. |
|
|
|||
|
|
|||
|
|
|||
|
|
Page
FOREWORD i
1.0 SCOPE 1-1
2.0 APPLICABLE DOCUMENTS 2-1
3.0 REQUIREMENTS 3-1
3.1 SYSTEM DEFINITION 3-2
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
3.1.6.1 Environment 3-12
3.1.6.2 Packaging 3-12
3.1.6.3 Software 3-12
3.2 SYSTEM OPERATING REQUIREMENTS 3-13
4.0 QUALITY ASSURANCE 4-1
Appendix A - Glossary A-1
Appendix B - Conventions and Assumptions B-1
FOREWORD
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.
ATCS SYSTEM ARCHITECTURE
1.0 SCOPE
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.
2.0 APPLICABLE DOCUMENTS
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
3.0 REQUIREMENTS
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.
| |
3.1 SYSTEM DEFINITION
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.
| CAPABILITY/LEVEL | 30 | ||
| 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 |
O |
O | O |
| 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
3.1.6.1 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.
3.1.6.2 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.
3.1.6.3 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.
3.2 SYSTEM OPERATING REQUIREMENTS
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).
4.0 QUALITY ASSURANCE
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.
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.
XPNDR,
XPONDER - Transponder
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.