MSRP K II Manual Standard Of ATCS
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 390
| Download | |
| Open PDF In Browser | View PDF |
3/1/05 Association of American Railroads SAFETY AND OPERATIONS (See copyright statement next page) MANUAL OF STANDARDS AND RECOMMENDED PRACTICES SECTION K-II RAILWAY ELECTRONICS ISSUE OF 2005 Effective March 1, 2005 Compiled under the direction of the Committees responsible for the subjects shown herein. Published by The Association of American Railroads 50 F Street, N.W., Washington, D.C. 20001-1564 © Copyright Association of American Railroads Printed in U.S.A. Copyright © 2005 by the Association of American Railroads (AAR) Safety and Operations 50 F Street, N.W. Washington, D.C. 20001-1564 All rights reserved, including the right to reproduce this book in any form. It is the AAR’s intention that this publication be used to promote the objectives of the AAR and its members for the safe, efficient, and uniform interchange of rail equipment in North America. To this end, only excerpts of a rule or specification may be reproduced by the purchaser for their own use in promoting this objective. No portion of this publication may be displayed or otherwise made available to multiple users through any electronic distribution media including but not limited to a local area network or the Internet. No portion may be sold or used for advertisement or gain by any entity other than the AAR and its authorized distributor(s) without written permission from the AAR. 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics ORDERING INFORMATION Copies of the various sections of this manual can be obtained as follows: ORDERS FOR PUBLICATIONS Publications Department Transportation Technology Center, Inc. P.O. Box 11130 55500 DOT Road Pueblo, CO 81001 Email: pubs@ttci.aar.com Phone: Toll-free 877-999-8824, Direct 719-584-0538 Fax: 719-584-7157 TTCI Web page: www.ttci.aar.com CIRCULAR Subscriptions to Circular Letters of the AAR Safety and Operations’ Technical Services are available in LETTER hardcopy or electronic format (online access via AAR’s Web page at www.aar.org). Circulars are issued SUBSCRIPTIONS at least monthly and include industry letter ballots and results, arbitration decisions, notification of rules and standards revisions, industry early warning and maintenance advisories, and other information related to mechanical rules and standards. Annual subscriptions commence on July 1 and terminate on June 30 of each year. For ordering information, contact the following: Phone: Toll-free 877-999-8824, Direct 719-584-0538 Fax: 719-584-7157 Email: pubs@ttci.aar.com AAR Web page: www.aar.org TTCI Web page: www.ttci.aar.com TECHNICAL QUESTIONS 3/1/05 For technical questions regarding this manual, contact the following: Railway Electronics Task Force Transportation Technology Center, Inc. P.O. Box 11130 55500 DOT Road Pueblo, CO 81001 Email: electronics@ttci.aar.com Phone: 719-584-0795 Fax: 719-585-1895 K-II–i 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics THIS PAGE LEFT BLANK INTENTIONALLY K-II–ii 3/1/05 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics TO THE USER Section K-II—Railway Electronics Part II, Manual of Standards and Recommended Practices, Association of American Railroads (AAR), contains specifications and standards for railway electronics. USER’S GUIDE Section K-II contains four standards at this time. It consists of the following: • Preface: A listing of the subjects covered in the individual volumes making up this manual. This preface is part of each section. • Table of Contents in Alphabetical Sequence: A generalized subject listing that indicates applicable specifications, standards, and recommended practices. • Specifications, Standards, and Recommended Practices: The body of this volume deals specifically with railway electronics. • Revised Page Dates: The latest revision date of each page in Section K-II. RELATED SECTIONS Section K-II—Railway Electronics, should be used in conjunction with the following: • Section K—Railway Electronics, Parts I and III • Section M—Locomotives and Locomotive Interchange Equipment • Section J—Specifications for Quality Assurance, M-1003 RESPONSIBILITY The coverage of Section K-II—Railway Communications, is the responsibility of the AAR Railway Electronics Task Force. FORWARD These specifications for Advanced Train Control Systems (ATCS) have been developed through a public open-forum process involving contracted systems engineers, railroad industry professionals, and suppliers. The purpose of these 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 these specifications does not commit any railroad to purchase any hardware or software described herein, require any railroad to use these specifications for the purchase of hardware or software generally described, or constitute endorsement of any supplier's product designed or built according to these specifications. Decisions to purchase any product developed in accordance with these specifications are matters of discretion and judgment on the part of individual railroads and individual suppliers. 3/1/05 K-II–iii 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics PREFACE The Manual of Standards and Recommended Practices of the Technical Services Division, Association of American Railroads, is issued by authority of the Management Committee of the Division and includes all regularly adopted specifications, standards, and recommended practices of the Association of American Railroads. The manual is composed of the following sections: • Section A, Part I—Table of Contents, Alphabetical and Numerical Index of Sections A through N inclusive • Section A, Part II—Miscellaneous Specifications, Standards (010 Series), and Recommended Practices (010 Series) • Section A, Part III—Vacant • Section B—Couplers and Freight Car Draft Components (100 Series) • Section C—Car Construction—Fundamentals and Details (200 and 2000 Series) • Section C, Part II, Volume 1—Specifications for Design, Fabrication, and Construction of Freight Cars, M-1001 • Section C, Part II, Volume 2—Appendices M-1001 • Section C, Part III—Specifications for Tank Cars, M-1002 • Section D—Trucks and Truck Details (300 and 3000 Series) • Section D, Part II—Code for Designating Design Features for Side Frames and Truck Bolsters (300 and 3000 Series) • Section E—Brakes and Brake Equipment (400 and 4000 Series) • Section E, Part II—Electronically Controlled Brake Systems • Section F—Vacant • Section G—Wheels and Axles (600 Series) • Section G, Part II—Wheel and Axle (Shop) Manual (600 Series) • Section H—Journal Bearings and Lubrication (700 Series) • Section H, Part II—Roller Bearing (Shop) Manual (700 Series) • Section H, Part III—Lubrication (Shop) Manual (700 Series) • Section I—Intermodal Equipment Manual • Section J—Specification for Quality Assurance, M-1003 • Section K—Railway Electronics (5700 Series) • Section K, Part II—Railway Electronics (5800 Series) • Section K, Part III—Railway Electronic (5900 Series) • Section L—Lettering and Marking of Cars (900 Series) • Section M—Locomotives and Locomotive Interchange Equipment • Section N—Multi-Level Manual Specifications are designated with an “M” prefix (e.g., M-900). Standards are prefixed “S” (e.g., S-900). Recommended Practices carry the prefix “RP”( e.g., RP-900). The prefix “S” or “RP” will be followed by a three- or four-digit number. The first digit, 0 through 9, indicates the section in which the standard or recommended practice can be found, as shown in parentheses above. K-II–iv 3/1/05 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics SECTION K-II TABLE OF CONTENTS IN ALPHABETICAL SEQUENCE Subject Standard S-5830 S-5825 S-5800 S-5820 S-5810 Base Communications Package Cluster Controller Communications System Architecture Front End Processor Mobile Communications Package 3/1/05 K-II–v Page K-II–371 K-II–362 K-II–1 K-II–353 K-II–341 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics THIS PAGE LEFT BLANK INTENTIONALLY K-II–vi 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics COMMUNICATIONS SYSTEM ARCHITECTURE Specification S-5800 (Formerly ATCS Specification 200) Adopted: 1987; Revised: 1995, 2002 TABLE OF CONTENTS Paragraph or Appendix 1.0 2.0 3.0 3.1 3.1.1 3.1.2 3.1.3 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.3 3.4 4.0 Appendix A Appendix B Appendix C Appendix D Appendix E Appendix F Appendix G Appendix H Appendix I Appendix J Appendix K Appendix L Appendix M Appendix N Appendix O Appendix P Appendix Q 3/1/05 Topic Page Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–3 Applicable Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–4 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–4 ATCS System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–4 ATCS Data Communications Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–5 ATCS Data Communications System Operational Overview . . . . . . . . . . . . . . . . . . . . . . . . K-II–11 System Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–19 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–19 Physical. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–22 Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–22 Security Commentary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–24 Environmental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–24 Design and Construction (Commentary) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–24 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–25 Quality Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–26 Applications Layer Protocol (Layer 7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–27 Presentation Layer Protocol (Layer 6). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–28 Session Layer Protocol (Layer 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–30 Transport Layer Protocol (Layer 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–36 Network Layer (Datagram) Protocol (Layer 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–48 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–55 Network Layer Virtual Circuit [NV] Protocol (Layer 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–56 Network Layer (Datagram-Radio Network) Protocol (Layer 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–57 Datalink Layer LAPB Protocol (Layer 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–64 Datalink Layer ATCS/HDLC Polled Protocol (Layer 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–65 Datalink Layer HDLC Balanced Protocol (Layer 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–67 Datalink Layer (ATCS Radio Link) Protocol (Layer 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–70 Physical Layer (ATCS Ground Network) (Layer 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–75 Physical Layer (ATCS Radio Network) (Layer 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–76 Physical Layer (ATCS Mobile Network) (Layer 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–77 Protocol State/Flow Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–79 Flow Control Recovery Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–264 K-II–1 ver4.0 3/1/05 Paragraph or Appendix Appendix R Appendix S Appendix T Appendix U Appendix V Appendix W Appendix X Appendix Y Appendix Z Appendix AA Appendix AB Appendix AC ver4.0 AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Topic Page Routing and Vehicle Following Rules and Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–265 Commentary on Emergency Traffic Handling Rules and Procedures . . . . . . . . . . . . . . . . . . . . . . . . K-II–295 ATCS Network Address Assignments—Layer 3 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–296 ATCS Radio Link Address Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–303 XID Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–304 Radio Network Forward Error Correcting Code Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–312 ATCS Standard Protocol Test Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–316 Vital CRC Calculation (Commentary) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–321 Vehicle and Field System Network Layer Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–327 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–332 Change Record Sheet for S-5800 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . K-II–334 Cross-Reference to Paragraphs and Figures in Previous Revision . . . . . . . . . . . . . . . . . . . . . . . . . K-II–336 K-II–2 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics COMMUNICATIONS SYSTEM ARCHITECTURE Specification S-5800 1.0 SCOPE 1.1 This document sets forth the architecture of the data link system for Advanced Train Control Systems. It identifies the hardware and software components for ATCS communications, their functions, and the nature of the interfaces between them. There are companion specifications that describe the architecture of the ATCS locomotive equipment, track forces equipment, wayside equipment, the computer-aided dispatch system, and the overall system architecture. The subsystem specifications identify the specific hardware and software specifications that apply to the respective subsystems and define the integration requirements for each. This document describes the communications flows between any pair of communications nodes—the dispatch system, locomotives, track forces, and wayside equipment—and the system architecture to support those flows. Communications protocol specifications are included in appendices to this specification. 1.2 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 that they consider to be cost-effective and appropriate. Suppliers and railroads purchasing hardware or software in accordance with this specification are responsible for ensuring that equipment and its application satisfy regulatory and safety requirements. 2.0 APPLICABLE DOCUMENTS The following documents are 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 100, Version 4.0, System Architecture Overview • ATCS Specification 110, Version 4.0, Environmental Considerations • AAR Manual of Standards and Recommended Practices, Specification 5810, Version 4.0, Mobile Communications Package • AAR Manual of Standards and Recommended Practices, Specification 5820, Version 4.0, Front End Processor • AAR Manual of Standards and Recommended Practices, Specification 5825, Version 4.0, Cluster Controller • AAR Manual of Standards and Recommended Practices, Specification 5830, Version 4.0, Base Communications Package • ATCS Specification 250, Version 4.0, Message Formats • ATCS Specification 300, Version 4.0, Locomotive Systems • ATCS Specification 400, Version 4.0, Dispatch Systems • ATCS Specification 500, Version 4.0, Field Systems • ATCS Specification 600, Version 4.0, Track Forces Systems • CCITT Recommendation X.25 (1980, 1984) • CCITT V.3 (International Alphabet 5-(IA5)) • CCITT Recommendation Z.100, Z.101, Z.102, Z.103, and Z.104 (1984) • FCC Rules Parts 2, 15 and 90 • FCC General Docket No. 84-1233/Rm-4829 • Government of Canada, Telecommunications Regulatory Service, Radio Standards Specification 119 3/1/05 K-II–3 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 • Government of Canada, Telecommunications Policy Branch, Spectrum Utilization Policy SP 300.4 • Government of Canada, Telecommunications Regulatory Service, Standard Radio System Plan SRSP 501 • IS0 Standards 7498, 3309, 4335, 7809 3.0 REQUIREMENTS 3.1 Definition 3.1.1 ATCS System Architecture 3.1.1.1 The ATCS system architecture is based on an established model of information flow. Fig. 3.1 shows the fundamental model of the ATCS as an information system. The model shown in Fig. 3.1 represents the organizational structure of a railroad as it relates to train control and the flow of information between the various elements of the “control system.” (Note: Fig. 3.1 is intended to show information flow—not the network topology or the path by which information is delivered). 3.1.1.2 The fundamental systems model is based on five levels of information processing: • Continental Level—provides those functions required for inter-railroad operations, primarily consisting of transfer of waybill, consist, and operational (train sheet) information. • Railroad Level—provides those functions required for strategic operation of the railroad; would consist of nonvital management of train operations. • Regional Level—provides functions necessary for operations across dispatch regions, such as handing off traffic from one dispatch center to another. • Dispatch Level—provides the central control functions for train control; functions at this level may be vital or nonvital and will require communication of vital information to and from trains, track forces, and some wayside equipment (such as switches). • Wayside/Mobile Level—provides (a) both vital and non-vital processing of data on locomotives, track units, and wayside devices and (b) communication of vital and nonvital information between trains, track forces, and wayside equipment. ver4.0 K-II–4 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics Fig. 3.1 ATCS system architecture 3.1.2 ATCS Data Communications Architecture The ATCS Data Communications Architecture is driven by the requirements of the users and the information flows as shown in Fig. 3.1. The International Standards Organization's seven-layer Open Systems Interconnect Model of protocol design forms the structure for the architecture. The technology (mobile data radio) used to provide the data path to the vehicles has major implications for the implementation methods selected. 3.1.2.1 ATCS Data System Users 3.1.2.1.1 The users of the Data Communications System have been grouped to facilitate the development of a Data Communications Architecture and of an addressing scheme to uniquely identify each user. These groups are described below, each with an “identifier” number that shall be used as the first digit of the address of all members of that group. • Network Applications (Identifier 0) consist of those applications in the ground network computers (part of the data communications system) that provide value added services to 3/1/05 K-II–5 ver4.0 3/1/05 • • • • • AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 other users and allow the network to be controlled, configured, and queried by other elements of the network or by authorized users. Locomotive Applications (Identifier 1) consist of those applications that are actually on board the locomotive. These include display devices, data recorders, sensor monitors, enforcement logic, databases, and so forth. Host Applications (Identifier 2) consist of those applications that reside in stationary ground computers not part of the communications system. These include dispatch systems and management information systems (MIS) systems (payroll, maintenance, etc.). Wayside Equipment—Wireline Connected (Identifier 3) consist of those applications that reside in wayside (field) systems that have wire, fiberoptic, or microwave connections into the ATCS ground network. These include powered and hand-thrown monitored switches, slide fences, high and wide equipment detectors, broken rail detection systems, etc. Other Mobiles (Identifier 4) consist of those applications that reside in vehicles other than locomotives. These include track repair and inspection vehicles. Wayside Equipment—RF connected (Identifier 5) consist of those applications that reside in wayside (field) systems that are connected to ATCS by radio. These include powered and hand-thrown monitored switches, slide fences, high and wide equipment detectors, broken rail detection systems, etc. 3.1.2.1.2 ATCS network address assignments for users are defined in Appendix T. 3.1.2.2 Major ATCS Data System Components 3.1.2.2.1 The ATCS Data Communications System consists of three major subnetworks. The ground network consists of ground network nodes (front end processors, cluster controllers, and base communications packages—described below) and the telephone circuits, microwave channels, fiberoptic links, and wireline modems that are used to interconnect the nodes. The radio frequency (RF) network consists of the base and mobile radios, and the channels on which they communicate. The user networks consist of the collections of objects and applications within each wayside device, vehicle, or dispatch system. 3.1.2.2.2 The ATCS Data Communication System comprises the following specific hardware: • A front end processor (FEP) is the major entry point from a host computer into the ATCS ground network. It performs message routing and train location functions and may perform protocol conversions. One front end processor would normally be connected to several cluster controllers. FEPs are described in AAR Manual of Standards and Recommended Practices, Specification S-5820 (Formerly ATCS Specification 220). • A cluster controller (CC) is a routing node in the ATCS ground network. It performs similar functions to the front end processor over a smaller geographical area. One cluster controller would normally be connected to several base station controllers. CCs are described in AAR Manual of Standards and Recommended Practices, Specification S-5825 (Formerly ATCS Specification 225). • A Base Communications Package (BCP) is a node in the ATCS ground network which provides the interface to the ATCS Radio Frequency (RF) network. One or more Base Station Radios (on different channel pairs) may be contained in a BCP. BCPs are described in AAR Manual of Standards and Recommended Practices, Specification S-5830 (Formerly ATCS Specification 230). • A mobile communications package (MCP) is a device that may be configured for three different roles in ATCS: (1) as an interface between the RF network and a locomotive computer or display device; (2) as an interface between one RF network and a wayside device interface unit. (3) as an interface between the ATCS ground network and a wayside equipment controller (in this mode, one side of the MCP emulates a BCP on the wireline instead of containing a radio). ver4.0 K-II–6 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics Commentary: MCP manufacturers are free to provide a single device that can be configured for any of the three roles or to build different devices for each role. 3.1.2.3 ATCS Data System Connectivity 3.1.2.3.1 Fig. 3.1 depicts the information flow among ATCS users. Fig. 3.2 depicts the actual connectivity of the various users to the data system. Note that, in general, users communicate through the data system and not directly with each other. Fig. 3.2 ATCS connectivity 3/1/05 K-II–7 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. 3.3 Example ATCS data system topology and major internal connections 3.1.2.3.2 Fig. 3.3 depicts the topology of the data system and shows its major internal connections. This diagram illustrates a number of important points that are outlined below. 3.1.2.3.3 Full/Half Duplex Radio Channel The base station operates in full duplex (transmits and receives at the same time) on the RF network, using separate frequencies for its transmitter and receiver. The locomotive, track force, and wayside devices operate on the complementary pair of channels, but in half duplex mode (transmits and receives alternately). This is illustrated by a locomotive transmitting while the track forces and wayside device are receiving in Fig. 3.3. 3.1.2.3.4 MCP Interface The MCP operates in locomotives, track force vehicles, and RF-connected wayside devices. This provides a standard interface to the data network for a wide variety of user devices. The MCP can also be used in an optional configuration to interface wayside devices directly into the ground network without using the radio channel. All of these configurations are illustrated in Fig. 3.3. 3.1.2.3.5 MIS Interface Management information systems (MIS) may (optionally) interface to the network via dispatch systems or front end processors. 3.1.2.3.6 Combined FEP/CC Cluster controllers and front end processors may be merged into a single unit that has all of the required capabilities of both units (where economics or railway philosophy so dictate). Cluster controllers can be connected to more than one front end processor. More than one dispatch center can be connected to a front end processor, and a dispatch system may be connected to more than one ver4.0 K-II–8 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics front end processor. The procedure that the multi-connected dispatch system would use to determine which front end processor to choose for each outgoing message is installation-defined. Multiple FEPs may be grouped using virtual node numbering described in Appendix R. Commentary: Certain railroad-specific hierarchical network implementations may not be required to support all physical interconnections shown in Fig. 3.3. 3.1.2.3.7 Star-Configured and Multi-Dropped Base Stations Base communications packages may be connected one per line interface to the cluster controller (“star configuration”) or multiple bases per line (“multi-dropped”). 3.1.2.3.8 Territory Outside ATCS Base Station Coverage Fig. 3.4 depicts the connectivity of ATCS components in territory outside ATCS base station coverage. Communications between ATCS MCPs out of coverage is accomplished using the “talk-around” feature. The MCP changes its transmit frequency to match its receive frequency for the duration of the message transmission only. Fig. 3.4 ATCS data system outside data radio base station coverage 3.1.2.3.9 End-of-Train Unit Interface End-of-train units do not use the ATCS Data System directly. Instead, they operate on their own frequencies and are interfaced to the locomotive computer. (See ATCS Specification 310 for details.) 3.1.2.4 Open Systems Interconnect Model 3.1.2.4.1 The International Standards Organization (ISO) has developed a model called the “Open Systems Interconnect (OSI) Reference Model” that addresses the interconnection and com3/1/05 K-II–9 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 munications of diverse user applications irrespective of their internal designs. This model forms the basis upon which the ATCS Data Communications System is structured. 3.1.2.4.2 The model provides for a seven-layered division of functions needed to achieve cooperation among applications. These layers are described in Table 3.1. Table 3.1 ISO Open Systems Interconnect (OSI) reference model Layer Layer Name Function Layer 7 Application Selects appropriate service for the application. (An application is the actual hardware and/or software entity that performs a function in ATCS and requires use of the communications system. Applications are also sometimes called “users”). Layer 6 Presentation Provides data formatting (reformatting) and identification. Layer 5 Session Coordinates the interaction between applications. Layer 4 Transport Provides for end-to-end data integrity and quality of service in communications. Layer 3 Network Switches and routes information. Layer 2 Data Link Transfers units of information across a physical link. Provides media access control, synchronization, framing, and error detection and recovery. Layer 1 Physical Moves bits across a medium. 3.1.2.4.3 Fig. 3.5 shows the relationship between the OSI model and ATCS components. Although the two end users in the figure are the dispatch center and the locomotive computer, the figure is equally applicable to communications between other pairs of users. Protocols for communications between devices will be defined in terms of procedures and data structures used by the entities within the devices at each layer to communicate with peer entities (same layer) in the other device and with adjacent layers in the same device. 3.1.2.4.4 An important concept in the OSI model is that peer-to-peer communications (to the same layer in another device) are established on a logical level through communications with lower layers to the physical level. An application communicates with another application (logically) by passing data down through successive layers until the data is passed by Layer 1 from device to device. When the data reaches the destination device (routing to the proper device is accomplished at Layer 3), it is passed through successive layers to the destination application. In general, overhead is added to the data when it is passed to a lower layer and removed when it is passed to a higher layer. ver4.0 K-II–10 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics Fig. 3.5 ATCS data network by OSI layer 3.1.3 ATCS Data Communications System Operational Overview The following sections provide a high-level perspective on the operation of the Data Communications System. Detailed descriptions of the components of the system are contained in other S-5800 series specifications. Detailed descriptions of the protocols involved are in the appendices to this specification. 3.1.3.1 User Access Interfaces 3.1.3.1.1 Fig. 3.6 depicts the user access interfaces for ATCS. All users require the upper layer protocols (ULP) that implement Layer 4–6 functions, which include formatting data, labeling data, acknowledging data, verifying proper source for commands, etc. Two Layer 3 interfaces are provided to ground users, allowing direct connections to the ATCS ground network from a user device or through public or private X.25 data networks. Layer 2 uses X.25 Link Access Procedure B (LAPB) for ground-based users and High-level Data Link Control (HDLC) balanced procedure for mobile/wayside users. The Layer 1 interfaces are RS422 for the mobile/wayside users and RS232 (optionally RS422) for ground users. 3/1/05 K-II–11 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. 3.6 User access interfaces to ATCS 3.1.3.1.2 The datagram interface is the ATCS basic Layer 3 protocol (used internally at Layer 3). It is based on fully addressed (source and destination) packets of information. It provides eight levels of priority and allows each packet to carry optional facility information in addition to the 128-byte data field. The extended packet size facility may be used to transmit a 256-byte data field (Layer 4 and above) in packets that convey nonvital data. 3.1.3.1.3 The optional nonvital virtual circuit interface (Layer 3 protocol) allows higher layer information to be transported through the public or private network without an “ATCS datagram header.” A protocol adaptor is required in the ATCS data network component to which the public network is attached to add datagram headers to the X.25 packet text fields and enter them into the ATCS network and to perform the reverse process for ATCS-originated traffic. This interface does not support vital traffic. This interface is optional and is provided via gateways in the FEP and/or CC. 3.1.3.2 RF Link Interface The major characteristics of this interface are summarized below. 3.1.3.2.1 Radio Channel Each radio channel is actually a pair of UHF channels. One is used for base-to-mobile/wayside communications on a noncontention basis. The other is used for mobile/wayside-to-base communications on a contention basis. The base is full duplex (simultaneous send and receive). The wayver4.0 K-II–12 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics side/mobiles are half duplex (alternately send and receive). The modulation technique is direct FM (sometimes called baseband FSK) at 4800 bits per second. 3.1.3.2.2 Access Protocol The base shall be able to be configured to access the channel continuously or as required. When the base sends, it indicates the state of its receive channel by inserting “busy bits” into the outbound bit stream. When a mobile has data to send, it first listens to the base's bit stream. If there is no bit stream from the base or if the busy bits indicate “not busy,” then the wayside mobile accesses the channel. If the channel is busy, then the wayside/mobile unit performs a random delay before trying again. The details of the access mechanism are described in Appendix L. 3.1.3.2.3 Data Format 3.1.3.2.3.1 Datagrams to be transmitted on the radio channel are formatted into frames and blocks that provide the following functions: • Error detection • Error correction • Busy bit positioning • Packet length indication • Addressee type indication 3.1.3.2.3.2 A frame may consist of two or more blocks. Whenever a device (MCP or BCP) turns on its transmitter, it first sends a series of 40 alternating 1s and 0s (20 of each) (bit synchronization), and then a 40-bit sequence (frame synchronization) before sending the first frame. Each subsequent frame is preceded by a new frame synchronization sequence (but not a bit synchronization sequence if the transmitter was already on). 3.1.3.2.3.3 Details of the RF protocol are contained in Appendices H, L, N, U, and W. 3.1.3.2.4 Territory Outside of ATCS Base Station Coverage In areas where radio control or condition query of wayside devices is desired but no base station radio coverage exists, wayside devices shall be configured to operate out of coverage. MCP radios in the wayside devices and in trains operating out of coverage are notified that they are out of coverage by their client using message 17.3.1. In the out-of-coverage mode, MCPs operate in simplex two-way alternate mode and transmit on the mobile receive side of channel 1. This is in contrast to communication in a coverage area where the communication is from mobile to base to cluster controller to base to wayside. 3.1.3.3 Ground Network Interfaces There are two internal ground network interfaces—point-to-point and polled. Both are based on HDLC framing. 3.1.3.3.1 Point-to-Point Interface The point-to-point interface is HDLC balanced mode. It is used to link front end processors, combined FEP/CCs, and cluster controllers (implements FEP-FEP, CC-CC, FEP/CC-FEP/CC, FEP/CC-FEP, FEP-CC, CC-BCP, and FEP/CC-BCP interfaces). This protocol is described in detail in Appendix K. 3.1.3.3.2 Polled Interface The polled interface links cluster controllers and combined cluster controller/front end processors to base stations, and optionally, to wayside devices connected to the base station wireline. The polled interface is not a standard version of HDLC but a modified version using HDLC framing with modified rules of procedure that operate without retransmissions between the base and cluster controller in order to maximize throughput. This protocol is described in detail in Appendix J. 3/1/05 K-II–13 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 3.1.3.4 Flow Control Virtually all non-trivial communications networks implement some type of flow control policy aimed at protecting message buffers, a scarce and essential resource in both user and network devices. The ATCS protocol suite provides two types of flow control at Layers 2 and 4 aimed at protecting network and user buffers respectively. Layer 2 flow control allows FEPs, CCs, BCPs, MCPs, and user devices to stop accepting traffic for a short period of time when they have excessive buffer usage (special procedures are defined to ensure they do not remain in this state and halt the network). Layer 4 flow control enables a receiving user to force the sender to delay sending and try again later on end-to-end acknowledged traffic, and to determine at the beginning of a message whether there is sufficient buffer capacity to hold the message. Flow control procedures are described in Appendix Q. 3.1.3.5 Routing and Vehicle Following 3.1.3.5.1 The ATCS data system requires a sophisticated method for routing packets in order to deal with the movement of vehicles from one base station to another. Intelligence is required on board the vehicle to ensure that it tunes its radio to the correct channel at the proper time. This is accomplished by providing a coverage database to the locomotive computer prior to departing the yard. Intelligence is required in the ground network to direct the traffic to the proper base station. 3.1.3.5.2 Each FEP and CC shall maintain a table of mobile locations: • When a packet is received from a mobile, the table will be updated in the servicing cluster controller. If the packet is from a vehicle not in the table, the servicing cluster controller will notify the other cluster controllers and FEPs of the acquisition of a mobile, allowing them to update their tables. • When a packet is received by the FEP from a ground user for a mobile and the mobile is in the table, the packet is forwarded to the servicing cluster controller for delivery. • When a packet is received by the FEP from a ground user for a mobile not in the table, the following events occur: • The packet is discarded and, if the D-bit is set in the packet, a service signal indicating the vehicle is unknown is returned to the ground user. • A request is sent by the node that performs the discard to all other known nodes for a notification if the mobile is in their table. • Depending upon the mode (see Appendix D) of transmission employed, the ground user may resend the packet after a delay. If another node had the vehicle in its table, the network shall attempt to deliver on the subsequent try. 3.1.3.6 Prioritization of Traffic ATCS traffic is divided into eight priority levels. Each priority level can be sent with the data link RF ARQ mechanism enabled or disabled, creating two subpriority levels per priority. These 16 levels are encoded in the Channel Group field of ATCS datagrams. The 16 channel groups determine how datagrams are chosen from a prioritized queue for transmission. 3.1.3.6.1 Prioritized Queue Service Logic There are two types of prioritization—among channel groups and within a channel group. Prioritization within any channel group shall be first-in-first-out. Prioritization among channel groups shall be as described below: • Among channel groups 0–3, a strict priority by channel number shall be employed. All channel group 0 packets shall be serviced before any channel group 1 packet is serviced; all channel group 1 packets are serviced before any channel group 2; and so forth. • When no channel group 3 packets are in queue, packets on channel groups 4–13 shall be serviced. Servicing shall be on a cyclic basis, biased toward lower numbered (higher prior- ver4.0 K-II–14 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics ity) channel groups. A cycle is complete when the opportunity for service has been presented to each of the 10 channel groups. The bias shall be according to the following: Table 3.2 Parameters for determining bias in channel group prioritization Channel Group 4 5 6 7 8 9 10 11 12 13 Opportunities Presented per Cycle 10 9 8 7 6 5 4 3 2 1 Comment: One possible order of selection in a cycle is: 4 5 4 5 6 4 5 6 7 4 5 6 7 8 4 5 6 7 8 9 4 5 6 7 8 9 10 4 5 6 7 8 9 10 11 4 5 6 7 8 9 10 11 12 4 5 6 7 8 9 10 11 12 13 • Packets of channel groups 14 and 15 shall be processed in strict priority order when all lower numbered channel group traffic is completed. 3.1.3.6.2 List of Mandatory Prioritized Queues 3.1.3.6.2.1 The following queues shall be prioritized: • All user-to-network access queues, including dispatch system-to-FEP, and locomotive computer-to-MCP. • All network access point-to-user queues, including FEP-to-dispatch system and MCP-to locomotive computer. • MCP's internal queue of traffic for the radio. • Base communications package queues to cluster controller and the radio. • All queues to ground network point-to-point lines. • All cluster controller send queues to base stations and wayside devices. • Queues of traffic (both directions) between ATCS datagram network and protocol adaptors. 3.1.3.6.2.2 Queues that are internal to a device and not listed above may or may not be prioritized at the discretion of the manufacturer. 3/1/05 K-II–15 ver4.0 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 S-5800 3.1.3.6.3 Allocation of Priorities to Message Each message shall be assigned a priority as it is defined according to Table 3.3: Table 3.3 Message priorities Priority Channel Groups 0 1 2 3 4 5 6 7 0–1 2–3 4–5 6–7 8–9 10–11 12–13 14–15 Uses Emergency Time critical (e.g., time marks, network control) Operational (e.g., location, authorities, switch position) Reserved Normal (e.g., work orders, maintenance conditions) Reserved Long messages (database loads) Low priority (history data) 3.1.3.7 Low Density System (Optional) 3.1.3.7.1 Two alternative configurations exist for low density, single railroad systems (run-through [inter-railroad] trains/locomotives/track forces not supported). The intent of these configurations is to use existing voice communications frequency allocations for data communications. 3.1.3.7.1.1 The first alternative configuration is to implement the baseline system using two VHF voice frequencies per channel instead of two UHF frequencies. This configuration shall be identical to the baseline system in all other respects. 3.1.3.7.1.2 The second alternative configuration, shown in Fig. 3.7, is to use simplex two-way alternate (CSMA). Voice and data may be mixed on the same channel in this configuration depending on traffic levels. Frame structure, forward error correction (including block formats) shall be the same as the baseline system. When appropriate, data may be communicated directly between locomotives (same or different consist), between locomotives and track forces, and between track forces or locomotives and wayside devices. 3.1.3.7.2 As with the baseline system, end-of-train communications are outside the scope of this system. ver4.0 K-II–16 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics Fig. 3.7 Alternative system for low-density territory (simplex) 3/1/05 K-II–17 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 3.1.3.8 Base Transmitter Management (Commentary) The requirements for base station transmitter facilities defined in this Specification S-5800 (Formerly ATCS Specification 200), in Specifications S-5820, S-5825, and S-5830, and in ATCS Specification 250 are intended to support two mechanisms for base transmitter management using standard products. The two techniques are alternating frequencies (see Fig. 3.8) and optimal frequency reuse (see Fig. 3.9). Improper base-transmitter management can lead to poor performance. Performance may be diminished as a result of 1) radio transmission collisions between base stations or 2) loss of busy bits. Radio transmission collisions between base stations, for example, may result in poor reception by mobiles. Additionally, the loss of busy bits, as a result of no base transmission, may cause radio transmission collisions between mobiles. This, in turn, may result in poor reception by bases. BASE A CHANNEL 1 BASE B CHANNEL 2 BASE C CHANNEL 3 BASE D CHANNEL 1 BASE E CHANNEL 2 BASE F CHANNEL 3 BASE G CHANNEL 1 BASE H CHANNEL 2 BASE I CHANNEL 3 Mobiles change channels at these locations Fig. 3.8 Alternating frequencies 3.1.3.8.1 Alternating Frequencies 3.1.3.8.1.1 It is possible to place alternating base stations on different radio channels. At designated geographical positions, the mobile switches channels and hence base stations. This requires no special software in the ground network, and the base stations transmitters can be left on providing busy bit service to mobiles at all times. 3.1.3.8.1.2 Adjacent bases do not interfere because they are on different channels. 3.1.3.8.2 Optimal Reuse 3.1.3.8.2.1 In some areas, base station radio coverage may overlap. Mobiles and field sites in the overlap areas will suffer degraded reception if both bases transmit at the same time. All mobiles will suffer degraded access to the ground network if the base transmitters are left “off ” by default. The solution is to leave the base transmitters “on” by default and for the cluster controller to turn off one base transmitter before sending a message to a device in the overlap area via the other (overlapping) base. Both base transmitters can remain on when communicating outbound to mobiles and field locations that are not in the overlap area. Proprietary algorithms exist for optimizing this process and for determining which mobiles and field devices are in the overlap area based on inbound messages received at each base and on signal strength indications reported by base stations. ver4.0 K-II–18 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics CLEAR (NON-OVERLAP ZONES) BASE A ALL CHANNELS BASE B ALL CHANNELS BASE C ALL CHANNELS REUSE ZONES (OVERLAP AREA) Fig. 3.9 Optimal reuse 3.1.3.8.2.2 Adjacent bases interfere when communicating to mobiles in reuse zones. This interference requires the FEP/CC or CC to command the adjacent base transmitter to shut off during this communication. For example, while sending a packet to a mobile in the reuse zone between bases A and B via base A, the CC must shut down the transmitter in base B. 3.2 System Characteristics 3.2.1 Performance The performance of the data communications system is dependent upon the performance of its major components; the quality of the wireline network and associated modems; the environment, prevailing noise conditions in the RF, in the telephone network, and in the vehicles; and the state of the user devices themselves. This complicates the specification of performance standards for the communications system as a whole. In order to simplify this problem, the following assumptions are made in specifying system performance: • Wireline bit error rate < 1×10–4 • Vehicles/wayside units are within the coverage area of a base station. Coverage shall be defined as a geographical location where the probability of an inbound packet from a stationary vehicle being received correctly on a single try (with error correction) is greater than or equal to 90%. Commentary: For the purpose of defining coverage, a packet is a nonvital ASCII message containing 100 characters of data. It is sent in broadcast mode (no acknowledgments). The packet has the Layer 2, 3, 4, and 6 headers as specified in the appendices to this specification. A possible test to ascertain that a location is in coverage is to send 50 packets from a stationary vehicle to a single ground network address and count the received packets. If 45 or more packets are received, the location is in coverage. • Vehicles/wayside units are on the correct frequency. • All communications components (FEP, CC, BCP, and MCP) are functioning as required by their respective specifications. • Neither user device (source or destination) is in flow control. • Network topology is engineered so as not to create an unusual bottleneck (e.g., too many base stations on a multidrop line). 3/1/05 K-II–19 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 3.2.1.1 Delay 3.2.1.1.1 Delay specifications listed below are of two types: • “99% delay” is defined as follows: If a large sample of traffic is sent, 99% of the messages in the large sample would be delivered within the specified delay. All messages in the large sample are assumed to be sent independently (at random intervals), under the conditions of paragraph 3.2.1 above and the additional conditions stated with each figure. • “Average Delay” is defined as follows: If a large sample of traffic is sent and the delivery times measured, the mean of the delivery times, excluding the longest 1%, is the average delay. Note: This is equivalent to the mean of the delivery times of the traffic delivered within the 99% delay time. 3.2.1.1.2 Emergency Traffic Delay Emergency traffic delays are specified for 99% delay only. In each case, the assumption is made that only one emergency has been declared at a time, and that traffic is sent as described in Appendix S. a. b. c. d. e. Vehicle/wayside to vehicle/wayside (same base station and channel) 4 seconds. Vehicle/wayside to controlling dispatch system (not in flow control) 8 seconds; (in flow control) 15 seconds. Dispatch system to adjacent dispatch system (not in flow control) 5 seconds; (in flow control) 10 seconds. Dispatch system to single vehicle (not in flow control) 5 seconds; (in flow control) 10 seconds. Dispatch system to multiple (up to 10) vehicles (not in flow control) 30 seconds; (in flow control) 60 seconds. 3.2.1.1.3 Normal and Operational Traffic Delay These delays are specified under the conditions that the network is operating at 50–75% inclusive of its nominal capacity, is not in flow control, and that the traffic is sent in Mode 1 as defined in Appendix D. These delays are for either direction of transmission. Normal Operational Average Delay 99% Delay 30 seconds 10 seconds 225 seconds 75 seconds 3.2.1.1.4 Database Traffic Delay These delays are specified under the condition that a single database is being loaded to a train (and no other database is concurrently being loaded via the same ground station), and that no network component from the Dispatch System to the Base Station is loaded beyond 75% of its nominal capacity (not counting the capacity used by the database load itself). The database is assumed to be 50 full-length packets long, and is sent in Mode 2 as defined in Appendix D. These delays are from dispatch to vehicle. Database Delay ver4.0 Average Delay 99% Delay 5 Minutes 10 Minutes K-II–20 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics 3.2.1.2 Throughput The throughput of the data system is engineered on a site-by-site basis. The throughput is a function of the line capacity connecting network nodes, the number of radio channels installed, the type of traffic being sent, and the capacity of the dispatch system, front end processor(s), and cluster controller(s) used. 3.2.1.3 Commentary on Erroneous Messages The data communications system will generate less than 1 false nonvital message per receiver per year and less than 2×10–10 false vital messages per receiver per year. Notes: 1. A false nonvital message is one that has an apparently valid address that makes it deliverable to a user. 2. A false vital message is one that has the elements of Note 1, the vital bit set in the message, and an apparently correct vital or transport layer CRC. 3.2.1.4 Undeliverable Messages Under the conditions of paragraph 3.2.1 and assuming that the source/destination addresses are in the routing tables of the appropriate network nodes, the data system shall deliver at least 99.9% of the traffic with ARQ enabled and at least 75% of the traffic with ARQ disabled. (This assumes all ARQ traffic is tried six times before giving up). 3.2.1.5 Octet Aligned Messages All ATCS messages are integral multiples of 8 bits in length. All packets of all ATCS messages are integral multiples of 8 bits in length. A frame on a particular data link may be other than an integral multiple of 8 bits, however, as a result of HDLC bit stuffing on wire lines and the use of 85-bit blocks on the radio links. 3.2.1.6 Health Reporting 3.2.1.6.1 Health reporting for communications components is done with the following series of messages: Table 3.4 Messages used for health reporting 3/1/05 Message Number Name 4.1.1 4.1.2 4.1.4 4.1.5 4.1.6 4.2.1 4.2.2 4.2.3 4.2.8 4.2.11 4.2.12 4.3.1 QUERY_FOR_SELF_TEST_MSG QUERY_FOR_HEALTH_REPORT_MSG QUERY_HEALTH_LIST_MSG QUERY_SELF_TEST_LIST_MSG DEVICE_RESET_REQUEST_MSG SELF_TEST_RESULTS_MSG HEALTH_REPORT_MSG MALFUNCTION_REPORT_MSG GRACEFUL_SHUTDOWN_NOTICE_MSG PROVIDE_HEALTH_LIST_MSG PROVIDE_SELF_TEST_LIST_MSG SET_HEALTH_REPORTING_RATE_MSG K-II–21 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 3.2.1.6.2 Each MCP with a mobile client reports its health to its THEL or LHEL client. Each MCP with a wayside client reports its health to its WHEL client (first client address provided during XID). Each BCP reports its health to the GHEL address in its parent node (GHEL = 0RRRNN0004). Each GHEL address reports health for itself and its associated BCPs to a configured DHEL address. Procedures for configuring the DHEL address of a node are manufacturer-defined. 3.2.1.6.3 An MCP or BCP conducts a self-test at start-up. After start-up (during operation), receipt of a DEVICE_RESET_REQUEST_MSG (4.1.6) shall cause an MCP or BCP to perform a hardware reset, conduct a self-test, and report the self-test results to its designated health reporting address. Receipt of a QUERY_FOR_SELF_TEST_MSG (4.1.1) shall cause an MCP or BCP to report the results of the most recent self-tests. Self-test results are reported to the designated health reporting address using a SELF_TEST_RESULTS_MSG (4.2.1). After start-up, any failure shall be reported to the designated health reporting address using a MALFUNCTION_REPORT_MSG, and the operational status information reported as part of the self-test results shall be updated. Upon recovery after a failure, a HEALTH_REPORT_MSG (4.2.2) shall be sent to the designated health reporting address. An MCP or BCP shall perform a limited (nondestructive) set of health checks upon receipt of a QUERY_FOR_HEALTH_REPORT_MSG (4.1.2) and report the results in a HEALTH_REPORT_MSG (4.2.2) to its designated health reporting address. Commentary: In MCP and BCP versions prior to revisions 3.0, MCP and BCP health reporting was done periodically based on receipt of a SET_HEALTH_REPORTING_RATE_MSG (4.3.1). Revision 3.0 modified health reporting to have MCPs and BCPs send health reports only when polled by their designated health reporting address. The logic for processing the SET_HEALTH_REPORTING_RATE_MSG and performing periodic health reporting has been left in Appendix P, paragraph 4.0, to provide backward compatibility with previous revisions. 3.2.1.6.4 The GHEL application in each FEP, CC, or FEP/CC conducts a self-test at start-up, requests a self-test from each of its connected BCPs, and reports the results in one or more PROVIDE_SELF_TEST_LIST_MSGs (4.2.12). Upon receipt of a QUERY_FOR_SELF_TEST_LIST_MSG (4.1.5), GHEL provides the last self-test result for itself, communication lines, and each connected BCP. Upon receipt of a QUERY_HEALTH_LIST_MSG (4.1.4), GHEL provides the current health status of itself, communication lines, and each connected BCP using one or more PROVIDE_HEALTH_LIST_MSGs (4.2.11). Upon receipt of a set health reporting rate message, GHEL queries the health of each of its connected BCPs using the QUERY_FOR_HEALTH_REPORT_MSG (4.1.2), waits 30 seconds (to allow responses to arrive) and sends one or more PROVIDE_HEALTH_LIST_MSGs (4.2.11) to report the results; GHEL then sends subsequent lists at the interval specified in the message. GHEL forwards malfunction reports for any failure of its node's hardware or software, communications lines, or its connected BCPs to DHEL (note that BCPs report malfunctions to GHEL). Commentary: The GHEL application resides in each FEP, CC, and FEP/CC. BCPs are not directly attached to FEPs, therefore GHEL applications residing in FEPs (as opposed to CCs or FEP/CCs) do not report the self-test results of BCPs or the health of BCPs. 3.2.2 Physical The physical dimensions, weight, etc., of data communications system components are defined by the appropriate component specification. 3.2.3 Safety 3.2.3.1 Safety in ATCS is a system issue. It is achieved through the interdependence of hardware, software, and the human element. Major factors contributing to system safety that result from the data communications system include the following: • The use of cyclic redundancy checks on all messages whenever they are transmitted on the wireline or RF link (Layer 2). • The use of a second and third redundancy check on vital messages (Layers 4 and 6). ver4.0 K-II–22 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics • The requirement to include source and destination addresses on all messages to reduce the probability of an incorrectly delivered message or any ambiguity about message source. • The requirement for a session establishment prior to certain kinds of data exchanges between users (session established at Layer 5, verified by Layers 5 and 6). • Provisions for expedited handling of emergency traffic by the data system. 3.2.3.2 Major elements of the interaction between the data communications subsystem and other ATCS subsystems that contribute to the overall safety of ATCS include the following: • Convention whereby trains are stopped within a safe area when communications losses prevent verification of safety to proceed. • Voice radio backup to data communications system. • Provisions for data systems to provide monitoring of safety related conditions where none existed before. 3.2.3.3 General Safety Principles 3.2.3.3.1 The following general principles deal with the concepts of safety, vitality, and reliability within the Advanced Train Control System project. These general principles are to be used as guidelines and reference points in the definition, development, documentation, testing, certification, and performance at ATCS components and subsystems. These general principles are intended to be both descriptive and prescriptive. They describe the meaning of safety, vitality, and reliability when used in the context of ATCS. They prescribe the use of the terms safety, vitality, and reliability when used in the context of ATCS. 3.2.3.3.2 The safety, vitality, and reliability requirements of ATCS are best understood when taken together. A central objective of ATCS is to ensure safe train movements and track occupancies that avoid physical conflict, and other operational hazards of similar magnitude. The elements of ATCS involved in the accomplishment of that central objective are vital, since their individual or collective failure can result in life-threatening and property damaging accidents. The reliability with which ATCS accomplishes that central objective must be high enough to sustain efficient railroad operations. 3.2.3.3.3 In ATCS, the following apply: 3.2.3.3.3.1 Vital describes a function in ATCS that could result in a physical conflict, or other operational hazard of similar magnitude if an unsafe failure (including design error) occurs. 3.2.3.3.3.2 The vital elements of atcs are those related to the organization, issuance, safe execution and enforcement of movement authorities. The steps in the movement authority process are to do the following: • Gather sufficient information to ensure safe operation of the systems. • Use logic-based dispatcher decision-making to create movement authorities, which include block, track, and route occupancies, and speeds where applicable, granted to trains, engines, maintenance personnel, and high-rail equipped personnel. The logic shall ensure that no unsafe movement authority can be issued. • Convey and ensure accurate receipt of those movement authorities. • Execute and enforce those movement authorities, including overriding the engineer for train braking, when required. 3.2.3.3.3.3 If a failure of a vital element occurs, no matter what kind of failure, the system shall only fail in safe modes. These predicted safe failure modes shall be selected to eliminate the hazardous consequences of a component or system failure. Equipment design must be such that any single, independent component of software system failure results in a safe condition. Components of software system failures that are not independent, that is, those failures that in turn can cause others, must be considered in combination as a single failure and must not cause unsafe conditions. 3/1/05 K-II–23 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 3.2.3.3.3.4 Reliability is defined as the probability that the system will perform as intended for a specified period of time when used under stated conditions. Reliability is not a substitute for safety design and predicted safe failure modes. The reliability of ATCS vital elements, individual and in sum, must result in a system reliability high enough so as not to impair efficient railroad operations. 3.2.4 Security Commentary A summary of the anticipated threats to the railroads operating under ATCS are shown in Table 3.5. This is not an exhaustive list, but is intended to serve as a starting point for railway communications security planning. 3.2.5 Environmental ATCS communications system components shall comply with environmental requirements as defined by ATCS Specification 110 for the area in which the equipment is installed (e.g., onboard locomotive, office, wayside, etc.). 3.3 Design and Construction (Commentary) 3.3.1 The goal of ATCS is to provide specifications that ensure interoperability, compatibility, safety, reliability, and functionality of components, without specifying all of the details of the internal design of those components. The ATCS specifications focus primarily on form, fit, and function; that is, they specify functions to be performed, allocation of functions between different physical units, performance requirements, and electrical, mechanical, physical, and logical interfaces. They are not intended to be design or manufacturing specifications. The purpose of developing these specifications is to define the common railroad requirements for ATCS systems and to ensure compatibility between components and systems manufactured by different suppliers. This type of specification does not address internal design features or design practices. These specifications will not define internal hardware components (circuit boards) or software modules. The individual railroads will complement the ATCS specifications with their specific implementation requirements, including applicable references to AAR standard practices and FRA regulations. Table 3.5 Security threat summary (page 1 of 2) Threats Examples Jamming/ Low-cost transmitter channel capture captures base station, puts that coverage area out of service Spoofinga/ (simulation of dispatcher/ controller Employeea/ sabotage Interception of proprietary data Incidental EMI ver4.0 Notes Potential Solutions Requires malicious and determined action to be successful for continued period Technical solutions (spread spectrum/power) due to regulation. Simple monitoring of threat— may be able to detect and respond with alarm. Worse case is jammer sends base idle signal. Data message sent to train Implies detailed knowledge Some security provided by session layer of with false Movement and high level of potentially application Authority sophistication on part of layer-verification/authentication. Process can perpetrator be defeated by knowledgeable perpetrator. Employee sends incorrect Only needs application Potentially worst case. Administrative data to train, bad Movement knowledge and is likely to procedures must be applied; no technical Authority, bad track data, have it solution. Can be mitigated by ensuring no etc., alters ROM (train ID) administrative system can send vital or emergency messages. RR “A” intercepts RR “B” RRs express doubt that this Individual RRs can provide proprietary bit proprietary information is a serious problem structures for administrative messages that would be known only to that RR. User in adjacent band (or By definition not a malicious Can detect using same approach as under other emitter) interferes with and determined act jamming. radio K-II–24 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 S-5800 Table 3.5 Security threat summary (page 2 of 2) Threats Network overloading Invalid transponder Examples Someone sends continuous stream of high-priority/ emergency packets and blocks other traffic Improper transponder placed in roadbed Non-ATCS Security Related Threats: Physical disruption of rail or switcha/ Tampering with signal flagsa/ Tampering with cars (coupling/brakes)a/ a/ Notes Could be software error or malicious act Potential Solutions Flow control mechanisms may mitigate this depending on severity. Need to correct software and/or identify perpetrator. Could be track crew error or System shall stop train until problem is malicious and determined resolved. act Voice spoofinga/ Obstructing tracka/ Arsona/ Threat to life 3.3.2 When buying systems built to ATCS specifications, individual railroads will define application or site-specific details. Safety design principles will remain the responsibility of the railroads and the suppliers. 3.3.3 In the area of the protocols contained in the appendices, the descriptions are of functional requirements to be provided at each layer and of specific messages, packets, etc., to be generated under specific conditions. Manufacturers are free to implement these protocols in a layered fashion as described or in a single mass of software in a component (or anything in between). All of the checks and balances to ensure data integrity, format, etc., at each layer must be performed, however, and the resulting functionality must be identical to that described when operated with other ATCS components. 3.4 Documentation 3.4.1 The following minimum documentation shall be provided with each major ATCS data communications system component: • Operating instructions including configuration instructions • Installation guide and instructions • Basic troubleshooting guide • Preventive maintenance guide • Warranty information (if applicable) • Point of contact at manufacturer for problems (including name, address, telephone number). 3.4.2 If the buyer is to perform hardware maintenance, the following additional documentation shall be provided: • Board layouts • Schematics • Test points and expected voltages/waveforms/timing • Detailed troubleshooting guide 3.4.3 If the buyer is to perform software maintenance, the following additional documentation, as a minimum, shall be provided: 3/1/05 K-II–25 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 3.4.3.1 Software Development Plan (SDP)—indicates the resources and methodologies used in the development of the software as follows: • Software engineering organization that supported the development of the software • Hardware (e.g. workstations, test bench), software (e.g., CASE, project management), and facilities, including the applicable versions of all software • Software development methodology that was used (e.g., object oriented, structured analysis) • Formal testing resources, methods, tools, and activities • Quality assurance resources, methods, tools, and activities • Configuration management resources, methods, tools, and activities 3.4.3.2 Software Requirements Specification (SRS)—clearly defines the capability requirements of the software system. 3.4.3.3 Software Product Specification (SPS)—clearly describes the implemented design of the software system and includes the source code listing. 3.4.3.4 Software Test Plan (STP)—clearly describes the resources and techniques used for the qualification test of the software. 3.4.3.5 Software Test Descriptions (STD)—clearly describe the actual procedures that were executed during the performance of the software qualification test. 3.4.3.6 Version Description Document (VDD)—clearly indicates the implemented capabilities of a specific version of the software. 3.4.4 The following documentation, which will clearly indicate methods and resources required for the maintenance of the software, may also be supplied: 3.4.4.1 Computer Resources Integrated Support Document (CRISD)—provides the information needed to plan for the life-cycle support (i.e., maintenance) of the delivered software. This document includes information on the following: • The software to be maintained • The required hardware • The required facilities • The personnel tasked to maintain the software • The procedures to be followed during the maintenance of the software • The process for testing of changes made to the software • The required training on how to maintain the software • A plan for the transition of the software from development to maintenance 3.4.4.2 Firmware Support Manual (FSM)—provides the information necessary to load software or data into firmware components of a system. 3.4.5 If the item is a MCP or BCP, then proof of FCC and/or DOC certification shall be provided. 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 ATCS Specification 140. ver4.0 K-II–26 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX A APPENDIX A APPLICATIONS LAYER PROTOCOL (LAYER 7) 1.0 INTRODUCTION 1.1 The applications layer provides the bridge between the applications program and the ATCS data communications system. This layer provides the mechanism that allows an application to open and close communications sessions, to be informed of the state of those sessions, and to send and receive data on those sessions (sessions are described in detail in Appendix C). 1.2 This layer shall perform the following 12 functions: 1.2.1 Provide the identity of its client application to lower layers as a network address. 1.2.2 Provide the identity of the application(s) with which its client wants to communicate in the form of network address(es). 1.2.3 Identify the format of the data to be sent and accept format identifiers with received data. 1.2.4 Identify the type of session(s) to be opened. 1.2.5 Accept data received on the session and provide data from the application to be sent. 1.2.6 Accept and react to status information about the session(s) it has open (including sent data rejects, session closings, session failures, session additions, and transfers). 1.2.7 Ensure that the application does not attempt to communicate on a session it has not opened. 1.2.8 Notify the presentation layer whether or not each data message to be sent is a special emergency broadcast. This type of message is sent when an application has emergency data to send to a small number (1–3) of other applications. This service will not be requested on a message with a destination broadcast address. 1.2.9 Notify the presentation layer if a normally non-emergency send message is an emergency (priority override). 1.2.10 Accept incoming call indications from the presentation layer and indicate whether the application is able to process the indicated data type (accept or refuse call) from the indicated application. 1.2.11 Request the transfer of sessions controlling slave devices from other masters and accept status information resulting from the request (similar to open request). 1.2.12 Determine whether to accept control of a slave device offered by other applications and offer to transfer control of slaves to other applications when appropriate. 3/1/05 K-II–27 ver4.0 3/1/05 APPENDIX B AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 APPENDIX B PRESENTATION LAYER PROTOCOL (LAYER 6) 1.0 INTRODUCTION 1.1 The presentation layer provides the services necessary to ensure that only data in appropriate formats is provided to applications. It also is responsible for assigning priority and class (mode) of service to send traffic, for flagging data as vital or nonvital, and for ensuring that vital data is not conveyed in a nonvital mode. 1.2 In particular, the presentation layer entity shall perform the following 10 tasks: 1.2.1 For send data, verify that the label provided by the application layer is a valid label and that the length of the data provided is plausible for the label provided; assign a transmission mode, vitality indicator, and a degree of priority based on the label; and, if appropriate, specify a channel type restriction for the data. When an invalid label or data is detected, the send data shall be prevented from reaching lower layers for introduction into the network and the application layer shall be notified. Correspondence between labels and transmission mode, priority, vitality, and session requirements shall be defined in ATCS Specification 250. Note: Presentation layer entity shall accept directives from the application layer entity that the priority of a message is to be upgraded to emergency or special emergency broadcast. 1.2.2 For receive data, verify that the label and version level provided by the session layer are valid, that the length of the data is plausible for the given label and version level, that the data was received on the proper session type (if a session type restriction is in effect for that type of data), and that the data received vital protection in transmission (if required). If the data, label, version level, channel type, or vitality is wrong, notify the originating presentation layer entity of the problem. 1.2.3 Accept notifications of bad labels, incorrect version levels, data, session type, and vitality from other presentation entities. 1.2.3.1 Message Label Number 106.4.8 is used between presentation entities to reject data. The message text contains the following fields: Reason Code Receive Label Receive Data Length — — — 1 byte 2 bytes 2 bytes (integer length in octets) 1.2.3.2 The reason codes are defined as follows: 00 01 02 03 04 05 06 255 — — — — — — — — Undefined Label Wrong Data Size for Label Wrong Session Type for Label Vital Protection Required for Label and Not Present Application Unable to Accept Data Bad Presentation CRC Application Unable to Process Message Version Level Reject Communications Test While Applications Are Running 1.2.3.3 Reject messages are returned with the source and destination reversed from those of the message they reject. ver4.0 K-II–28 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX B 1.2.4 Pass session requests and session status information between application and session layers (including failed send notifications). Recall the sessions currently open for each application so that data from the session layer is passed to proper application. Commentary: Session status information may optionally be stored in a data structure shared by Layers 5 and 6. 1.2.5 Optionally, provide error messages to a log device for rejected send and/or receive messages. 1.2.6 Optionally, provide data reformatting if required by an application. 1.2.7 The Layer 6 entity shall accept incoming call indications from Layer 5 and shall verify that the label and version level are valid and that vitality was specified if required for that label. If these validity checks are met, the Layer 6 entity shall indicate an incoming call to the Layer 7 entity. If the Layer 7 entity accepts the call, the Layer 6 entity shall accept the call from Layer 5. If the Layer 7 entity refuses the call, or if the validity checks fail, the Layer 6 entity shall generate a reject message to the originating Layer 6 entity and shall refuse the call from Layer 5. 1.2.8 The Layer 6 entity shall pass slave transfer offerings indications to Layer 7 and the acceptance/denial indications of slave offerings from Layer 7 back to Layer 5. The Layer 6 entity shall pass slave transfer request indications from Layer 7 to Layer 5 and the appropriate session status for the request from Layer 5 back to Layer 7. 1.2.9 The Layer 6 entity shall add a Presentation CRC to all vital send messages prior to forwarding such messages to Layer 5. The check code to be used is identical to the check code used by the transport layer in terms of polynomial and order of bit transmission. However, it is calculated over the Layer 7 message data not including any header information. The check code is appended to the end of the Layer 7 message data. There is only one Presentation CRC per message (contrasted with Transport CRCs, which are applied one per packet). The order of bit and byte transmission shall be as defined in ATCS Specification 250, section 3.2.1.1 1.2.10 The Layer 6 entity shall check and remove the Presentation CRC from all vital receive messages. If the check code is bad, the message shall be discarded and message number 106.4.8 returned to the originating presentation entity. The receiving Layer 6 entity shall also notify the local health application that a bad CRC was detected (including the source and destination address, message label, message length, and the OSI functional layer where the bad CRC was detected). 1.3 State flow diagrams for the presentation layer are contained in Appendix P to this specification. 3/1/05 K-II–29 ver4.0 3/1/05 APPENDIX C AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 APPENDIX C SESSION LAYER PROTOCOL (LAYER 5) 1.0 INTRODUCTION 1.1 The session layer provides the mechanism that controls the association and disassociation of applications that must cooperate to perform their functions. 1.2 This layer shall provide the following nine functions: 1.2.1 Provide channel opening and closing services to the presentation layer on request. 1.2.2 Generate channel open, close, and transfer requests to distant session entities when required. 1.2.3 Accept and respond to open, close, and transfer requests from distant session entities. Obtain transfer request guidance from the application via Layer 6. 1.2.4 Map received data messages from the transport layer to open sessions to applications, and pass them to the presentation layer (when valid session exists), with the type of session to which they are mapped. 1.2.5 Reject data messages from the transport layer that are addressed to nonexistent or inactive applications. 1.2.6 Reject data messages from the presentation layer when a requirement for a master-slave session is indicated and no master or slave session exists between the indicated applications. 1.2.7 Provide session state and send message status indications to Layer 6. 1.2.8 Accept send message status indications from Layer 4 (failure or success). 1.2.9 Receive incoming call indications from Layer 4. Determine if a session to the indicated application exists. If a session exists, indicate the incoming call to Layer 6. If Layer 6 accepts the call, then the session entity shall accept the call from Layer 4. If no session exists, the session entity shall send a notification to the originating session entity (see below) and shall refuse the call from Layer 4. If Layer 6 refuses the call, then the session layer shall refuse the call from Layer 4. 2.0 SESSION TYPES 2.1 A “session” consists of a Layer 5 entity (either master, slave, or general purpose) and an associated logical connection to an application entity. A session is defined to be “open” when a logical connection is established between it and one or more remote sessions. A session is defined to be “closed” when no logical connection exists between it and any other remote session. A session is defined to be “terminated” when the logical connection to its application entity has been broken. The session entity no longer exists. The following three types of sessions shall be supported (see Fig. C.1): 2.1.1 General Purpose (Mandatory for all ATCS communications system users.) An application may request a general purpose session and send and receive messages from a variety of distant applications, provided that the messages exchanged are not of a type restricted to a master-slave session by Layer 6. A general purpose session is considered to have a logical connection with all other general purpose sessions. 2.1.2 Master Session (Mandatory for all users who control other users.) An application may request to open a master session for the purpose of issuing commands to exactly one slave. The network address of the application making the request, of the slave to which the application is to be connected, and of the controlled device (may be same as slave address) shall all be included in the open request. An ver4.0 K-II–30 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX C application shall be allowed to have any number of master sessions open at one time provided they all connect to different slave addresses. 2.1.3 Slave Session (Mandatory for all users who are controlled by other users). An application may request a slave session for the purpose of accepting commands on behalf of exactly one controlled device. The network address of the application making the request and of the device to be controlled shall be included in the request. The address of a specific master may be included in the request, or the request may allow any master to enter the session. An application shall be allowed to have any number of slave sessions open provided each slave session controls a different device address. A slave may be controlled by more than one master if an existing master so directs the slave session entity. (Note: Some devices may be constructed to preclude the slave from having more than one master, i.e., WIU.) Commentary: The slave and master open requests must contain the three addresses discussed above in order to permit locomotives to control remotely controllable interlockings and yet have each control request be analyzed by the safety logic within the central dispatch. In that situation, the locomotive would have a master-slave relationship with the safety logic application, with the controlled device address being that of a particular interlocking. The safety logic application would have a master slave relationship with the wayside interface unit for the interlocking; again, the controlled device address is that interlocking. In cases where an application is controlling another application directly, the slave address and controlled device address would be identical. Commentary: The slave and master open requests must contain the lower of the version levels of the source and destination entities. In cases where the version level is unknown (e.g., “any master”), the application will specify version level 1 to be used. Upgrading the version level of the session layer signalling after the initial open requests have been received will be negotiated through the use of the BUILT_TO_LEVEL field in the version 3.0 or higher SESSION_DATA_MSG. 2.2 In addition to these basic sessions, the session layer for users who control or are controlled by other users (except for the WIU) shall support multiple-master-slave sessions. 2.2.1 Multiple Master Slave sessions consist of a master-slave session where the master has agreed to allow one or more additional masters to issue commands to the same slave (added masters, contrasted with transferring to a new master). The slave shall accept commands from both masters until one of the masters closes his part of the session or until the slave has terminated the session entirely. An example of the use of this technique is in handing off a train between dispatch systems and allowing the gaining dispatcher to begin issuing authorities (within his territory) to the train before the train reaches his territory. Note: WIUs controlled by central dispatch shall be constructed so as to preclude multiple master sessions. This shall be accomplished by the slave denying (SMD) all open requests from other than the designated master or local control. 3/1/05 K-II–31 ver4.0 3/1/05 APPENDIX C AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 3.0 SESSION LAYER SIGNALLING 3.1 The signals and control messages used by the session layer are defined in Table C.1. The mnemonics indicate the source and sink of each signal by the first two letters as follows: SP PS ST TS MS SM MM — — — — — — — Session to Presentation Signal Presentation to Session Signal Session to Transport Signal Transport to Session Signal Master Session to Slave Session Signal [message] Slave Session to Master Session Signal [message] Master Session to Master Session Signal [message] 3.2 Message label 106.4.7 is used for coordination between session entities. The message contains the following fields: Reason Code: Master Network Address: Slave Network Address: Controlled Device Network Address: Candidate Master Address: a/ — — — — — 1 byte 8 bytes 8 bytes 8 bytes 8 bytesa/ This equates to data element 13 in Table C.2. This is not present in all session control messages. Table C.1 indicates what data elements are required in each session control message by reason code. 4.0 SESSION OPENING PROCEDURES 4.1 General Purpose Session When the application requests a general purpose session, the request shall be propagated through Layer 6 to Layer 5 where the session shall be created. A confirmation shall be relayed through Layer 6 back to the application. 4.2 Master Session A master session shall be initiated by the master application or as a result of an offer from another master or a slave. The session shall be opened only after signals have been received from both the prospective master and the prospective slave indicating concurrence with the session opening. 4.3 Slave Session A slave session shall be initiated by the slave application or as a result of a request from a master. The session shall be opened only after signals have been received from both the master and the slave indicating concurrence with the session opening. Once opened, the master may direct the slave to transfer the session to another master or to add another master to the session. When an open request (or transfer or addition request) is received by the slave from a master other than one of its current masters, the slave shall forward a request transfer message to its existing master and shall await direction to add, transfer to, or deny the session to the requesting master. 5.0 SESSION CLOSING PROCEDURES 5.1 General Purpose Session When the application requests the session to be closed, the request shall be propagated through Layer 6 to Layer 5 where the session shall be terminated, and a confirmation shall be relayed through Layer 6 back to the application. ver4.0 K-II–32 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 S-5800 APPENDIX C 5.2 Master Session The master session may be closed only in the following ways: • If the master application requests an unconditional close, the slave shall be notified and the session terminated. • If the master application refuses an offer of a session, the offeror shall be notified and the session terminated. • If the master application requests a close (conditional on a remaining master [no closeout]) and the slave confirms the close, or if a time-out occurs with no response from the slave. • If the slave requests a close (or confirms a close) of the session and the master session is terminated. • If the slave denies a session the master requested and the master session is terminated. 5.3 Slave Session 5.3.1 The slave session may be closed only in the following ways: • If the slave application requests a close, the master(s) shall be notified and the session terminated. • If the sole remaining master requests a close, the session shall be closed but not terminated, and the slave session shall await a request from a prospective new master. 5.3.2 The closeout timer duration is defined to be 2 minutes. GENERAL PURPOSE SESSION MULTIPLE-MASTER-SLAVE SESSION APPLICATION 1 GENERAL PURPOSE SESSION APPLICATION 1 APPLICATION 2 GENERAL PURPOSE SESSION APPLICATION 3 GENERAL PURPOSE SESSION MASTER-SLAVE SESSION APPLICATION 1 MASTER SESSION SLAVE SESSION APPLICATION 2 APPLICATION N APPLICATION N SLAVE SESSION MASTER SESSION MASTER SESSION SECONDARY-MASTER-MASTER-SLAVE SESSION APPLICATION 1 APPLICATION 2 MASTER SESSION SLAVE SESSION APPLICATION 2 MASTER SESSION APPLICATION 3 SLAVE SESSION MASTER SESSION Fig. C.1 Types of ATCS sessions 3/1/05 K-II–33 ver4.0 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 APPENDIX C S-5800 Table C.1 Session layer signals and control messages Reason Code Name of Signal Signal Mnemonic Required Data Elements Reason Code Name of Signal Signal Mnemonic Required Data Elements 1 Request open MSA 1,2,3,4 N/A Offer session transfer PSI 2 Request close MSB 1,2,3,4 N/A Grant session transfer PSJ 2,3,4,13,16 2,3,4,13 3 Accept open MSC 1,2,3,4 N/A Deny session transfer PSK 2,3,4,13 4 Reject open MSD 1,2,3,4 N/A Offer session add PSL 2,3,4,13,16 5 Direct to add MSE 1,2,3,4,13 N/A Message to send PSM 6,7,8,9,10,11,12,17 6 Direct to transfer MSF 1,2,3,4,13 N/A Receive message accepted (optional) PSN -6,7,8,11 7 Refuse to add MSG 1,2,3,4,13 N/A Reject incoming call PSO 8 Refuse to transfer MSH 1,2,3,4,13 N/A Accept incoming call PSP 6,7,8,11 9 Offer to add MMI 1,2,3,4,13 N/A Confirm GP session open SPA 5 10 Offer to transfer MMJ 1,2,3,4,13 N/A Confirm GP session close SPB 5 11 Accept add MMK 1,2,3,4,13 N/A Confirm slave session open SPC 2,3,4 12 Accept transfer MML 1,2,3,4,13 N/A Confirm slave session close SPD 2,3,4 13 Reject add MMM 1,2,3,4,13 N/A Confirm master session open SPE 2,3,4 14 Reject transfer MMN 1,2,3,4,13 N/A Confirm master session close SPF 2,3,4 15 Request close (no closeout) MSO 1,2,3,4 N/A Deny master session close SPG 2,3,4 16 Request open SMA 1,2,3,4 N/A Session transfer request SPH 2,3,4,13 17 Request close SMB 1,2,3,4 N/A Receive message SPI 6,7,8,10,11,12,14 18 Accept open SMC 1,2,3,4 N/A Send message success SPJ 6,7 19 Reject open SMD 1,2,3,4 (2=rejected master) N/A Send message failure SPK 6,7 20 Reject close SME 1,2,3,4 N/A Incoming call SPL 6,7,8,11,14,16 21 Request transfer SMF 1,2,3,4,13 N/A Deny session open SPM 2,3,4 22 Confirm add SMG 1,2,3,4 (2=added master) N/A Receive session offer SPN 2,3,4,13 23 Confirm transfer SMH 1,2,3,4 (2=new master) N/A Message to send STA 6,7,8,9,10,11,12,17 N/A Request gen purpose open PSA 5 N/A Receive message accepted (optional) STB -- N/A Request gen purpose close PSB 5 N/A Reject incoming call STC 6,7,8,11 N/A Request slave open PSC 2,3,4,16 N/A Accept incoming call STD 6,7,8,11 N/A Request slave close PSD 2,3,4 N/A Send message success TSA 6,7 N/A Request master open PSE 2,3,4,16 N/A Send message failure TSB 6,7 N/A Request sole master open (optional) PSF 2,3,4 N/A Receive message TSC 6,7,8,10,11,12 N/A Request master close PSG 2,3,4 N/A Request master close (no closeout) PSH 2,3,4 N/A Incoming call TSD 6,7,8,11,16 ver4.0 K-II–34 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 S-5800 APPENDIX C Table C.2 Data accompanying session layer signals Number 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Data Element Reason Code Master ID Slave ID Controlled Device ID General Purpose Application ID Message Source Message Destination Vitality Indicator Mode Indicator Priority Indicator Message Label Message Contents Candidate Master ID Session Type (GP, Master, Slave) Session Required Entity/Message Version Indicator Request for Transport Servicea/ a/ The following available transport services can be requested by application. Future versions of this specification may define additional transport layer services. • Suppress Duplicate Elimination • Emergency Override • Emergency Broadcast • Compression • Extended Packet Length • Peer-to-Peer Signalling Upgrade Offer • Request Session Facility 3/1/05 K-II–35 ver4.0 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 APPENDIX D S-5800 APPENDIX D TRANSPORT LAYER PROTOCOL (LAYER 4) 1.0 INTRODUCTION Layer 4 shall provide the following services: • Message segmenting and reassembly • Duplicate elimination (Note: Not all duplicate messages are eliminated by the transport protocols) • Vital message integrity checking (assigns vital CRC at originator and checks it at the receiver) • End-to-end acknowledgment (and negative acknowledgment) • Conversion of the transmission mode and priority assignments from Layer 6 (on send traffic passed through Layer 5) into decisions on what communications parameters to use • Indication of the priority and vitality with which messages were received to higher layers • Message compression and decompression • Provision of session request service using the request session facility provided by Layer 3. 2.0 FIELD DEFINITIONS The following fields in packets are relevant to the transport layer: Commentary: The term packet header is used to mean Octet 1 through the end of the Facility field. The term packet text is used to mean the remainder of the packet. 2.1 Octet 1 Octet 1 of the packet is defined as follows: Most Significant QD 10 Least Significant PPP A where Q D = = PPP A = = the Q-bit (indicates a service signal) and is set to 0 on all originate traffic the D-bit that indicates that a service signal is required from the network back to the originator indicating whether the packet successfully traversed the RF link the priority of the message the ARQ disable bit. When set to 1, the ARQ mechanism is disabled for the packet 2.2 Octets 2–4 Octets 2–4 of the packet are set to 0 on all originate traffic and are ignored on all receive traffic. 2.3 Address Length Indicates length of source address in four most significant bits and length of destination address in four least significant bits. The unit of measure of length is 4-bit BCD digits. This field is Octet 5 of both data packets and datagram service signals. ver4.0 K-II–36 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX D 2.4 Address Indicates the destination and source address, BCD encoded, in 4-bit digits. This field starts at Octet 6 and ends as indicated by the length required to indicate both addresses. Table 2.1 Example of Address field and address length Octet 5 Address Lengths Octet 6 Address Field Octet 7 Address Field Octet 8 Address Field Octet 9 Address Field Octet 10 Address Field Octet 11 Address Field Octet 12 Address Field End Most Significant Nibble Source Length Value = 08 Destination Digit 1 Value = 09 Destination Digit 3 Value = 09 Destination Digit 5 Value = 09 Source Digit 2 Value = 01 Source Digit 4 Value = 03 Source Digit 6 Value = 05 Source Digit 8 Value = 07 Least Significant Nibble Destination Length Value = 05 Destination Digit 2 Value = 09 Destination Digit 4 Value = 09 Source Digit 1 Value = 0A Source Digit 3 Value = 02 Source Digit 5 Value = 04 Source Digit 7 Value = 06 Pad Digit Value = 00 This set of fields indicates a source address of 01234567 and a destination address of 99999. These are not necessarily valid (or even defined) addresses but serve to illustrate the field layouts. 2.5 Facility Length The facility length must be accounted for in order to locate the packet text. The Facility Length field is the octet immediately following the Address field. Layer 4 will set this field to 0 on send traffic, but will accept traffic with a non-zero facility length. The number indicated by the Address Length field is the length of the immediately following Facility Length field in octets. The Facility Length field can be used to carry additional protocol information. The octets beginning after the Facility Length field to the end of a packet are commonly referred to as packet text. (Note: The extended packet size facility may be used to send nonvital packets with a user data (Layer 4–7) field of up to 256 octets.) Note: The “Transport Header” consists of the message number, more bit, part number, end-to-end acknowledgment bit, length field, vital bit, and label field. 2.6 Message Number The transport layer entity shall maintain a modulo 128 counter (initialized to 0) of originated messages for each active message destination (unique ATCS network address). The current value of this counter is placed by the transport entity into the most significant 7 bits of the first octet of the packet text. This number is used by the receiver (message destination) to eliminate duplicates and to associate packets that are part of the same long message. The transport entity shall ensure that message numbers are not reused for the same message destination within a 10-minute time period. The transport entity may enforce this requirement for non-emergency messages by buffering traffic or by sending a fail message indication to the origi- 3/1/05 K-II–37 ver4.0 3/1/05 APPENDIX D AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 nating entity. If the message number is to be reused within 10 minutes for an emergency message (Priority 0), then the facility code SUPPRESS_TRANSPORT_DUPLICATE_ELIMINATION shall be applied to all packets of the message. The modulo 128 counter for a given message destination shall be reset to 0 if there is no traffic to the destination for a 1-hour time period (inactive message destination). Manufacturers may optionally implement dynamic data storage that deletes the counter for the inactive message destination and recreates the counter when needed. 2.7 More Bit This is the low order bit of the first octet of the packet text. The transport entity shall set this bit to 1 on all packets of a multipacket message except the last packet. The bit shall be set to 0 on all single-packet messages and on the last packet of a multipacket message. 2.8 Part Number The transport layer entity shall sequentially number the packets of a message beginning with 1. Each packet of the message shall have the number of its position within the message stored in the most significant seven bits of Octet 2 of the packet text. Commentary: This limits the maximum message size to 127 packets [(127 × 119) = 15113 bytes for vital messages, and (127 × 123) = 15621 bytes for nonvital messages], unless the extended packet size facility is used for nonvital messages. 2.9 End-to-End Acknowledgment Bit The originating transport entity sets this bit in a packet to indicate the need for the receiving transport entity to send back an end-to-end response (acknowledgment, selective non-acknowledgment, reject. or delay directive) upon receipt of the packet. The end-to-end response sent by the receiver is an indication of the status of the whole message at the receiver, not only of the individual packet. Procedures for using this function are further defined in the transport entity receive and send procedures below. This bit is the low order bit of Octet 2 of the packet text. 2.10 Message Length The originating transport entity shall place the number of the highest numbered packet in a message into the most significant 7 bits of Octet 3 of each packet text of a message. The Part Number field and Message Length field together, therefore, convey the information that this is packetof . 2.11 Vital Bit This bit (when set to 1) indicates that the last four octets of the packet contain a Layer 4 redundancy check code covering the packet from the Address Length field to the end of the packet. The vital bit is the least significant bit of Octet 3 of each packet text. 2.12 Label This field contains the data label indicating the type of information carried by the packet. This field is contained in Octets 4 and 5 of the packet text. 2.13 Data This field contains the actual higher layer data to be transmitted. 2.14 Vital CRC This field (when present) is the last four octets of the packet. It is used by the transport entity to detect any corruption of the packet by the data system. It is calculated on the data from the address length octet through the end of the Layer 7 data. The bit order of transmission for the CRC is defined in ATCS Specification 250 section 3.2.1.1. ver4.0 K-II–38 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX D Note: When a message length is such that it does not fill the last packet used to convey the message, the last packet is not padded. The last packet is truncated following the Layer 4 CRC (vital) or following the Layer 7 data (nonvital). 3.0 TRANSPORT LAYER RECEIVER PROCEDURES Upon receiving a packet of a message from Layer 3, the transport layer shall determine if the packet is a datagram or a datagram service signal. Datagram service signals are identified by the qualifier (Q) bit of the received packet being set to a logical 1 (the Q-bit is the most significant bit in the first octet of the packet). 3.1 If the received packet is a service signal, extract the address information (address block in service signal is the same format as in a normal packet), datagram identification (first two bytes following the address block), and the service signal cause (first octet following the datagram identification). The transport layer shall process the service signal as follows: • Extract the message and part numbers from the datagram identification (upper seven bits of the respective octets). • Determine if a message and part matching those extracted is outstanding. • If the message and part number match an outstanding message, verify that the source of the service signal matches the destination of the outstanding message. If not, ignore the service signal, and processing is complete. • Match the cause field with the following table: Code 00010011 00000011 00001011 00001101 00100001 00000101 00001001 00110001 Reason for the Service Signal Local Procedure Error Invalid Facility Request Access Barred Not Obtainable Incompatible Destination Network Congestion Out of Order Delivery Confirmation • If the cause field does not match any code from the table, the error “unexpected service signal” has occurred. Execute exception handler or ignore the service signal. • If the reason is local procedure error, then the network is refusing to deliver the sent packet because of some error (Example: D-bit set in packet and odd channel group specified). The original packet shall not be retried by the transport entity, and a send failure for that message shall be indicated to Layer 5. • If the reason is “invalid facility request,” there is a Facility field in the packet that the network or destination does not understand or allow. The original packet shall not be retried by the transport entity, and a send failure for that message shall be indicated to Layer 5. • If the reason is “access barred,” the network was unable to obtain a path to the specified destination. The transport entity shall retry the original send packet one time after a 15-second delay (this allows the network time to attempt to locate the destination). If the same service signal is received a second time. no further tries shall be attempted, and a send failure shall be indicated to Layer 5. • If the reason is “incompatible destination,” a nonexistent destination was specified (Example: a message was sent to an auxiliary display on a locomotive not equipped with an auxiliary display). The original packet shall not be retried by the transport entity, and a send failure shall be indicated to Layer 5. 3/1/05 K-II–39 ver4.0 3/1/05 APPENDIX D AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 • If the reason is “network congestion,” the network is refusing to accept the traffic for delivery due to excessive ground network loading. The original packet shall not be retried by the transport entity and a send failure shall be indicated to Layer 5. • If the reason is “out of order,” the destination is out of order and the packet cannot be delivered. The original packet shall not be retried by the transport entity and a send failure shall be indicated to Layer 5. • If the reason is “not obtainable,” the network was unable to deliver a packet across the radio link after a maximum number of tries. In normal mode. the packet shall not be retried by the transport entity and a send failure shall be indicated to Layer 5. In all other modes the signal is ignored. • If the reason is “delivery confirmation,” the network is indicating that the packet successfully crossed the RF link. If the transmitted message is in normal mode, then that packet of the message shall be considered delivered. 3.2 If the packet is not a service signal, then determine if it is one of the following: • A duplicate of a completed message. If so, and if the end-to-end acknowledgment bit is set, resend the end-to-end acknowledgment and discard the received packet. The transport entity shall retain source and destination address, message number, and label for at least the last N completed messages for the purpose of duplicate elimination. This table of the last N completed messages must not exceed 128 for mobile devices. In all devices, the table length is manufacturer-defined and must be purged of entries older than 10 minutes. If any packet of a message includes the facility SUPPRESS_TRANSPORT_DUPLICATE_ELIMINATION, that message is not added to the list of completed messages. Furthermore, any packet containing this Facility field is not screened against the existing list of completed messages as a possible duplicate. • A new part of a receive message in progress. If so, reset the timers for that receive message and add the new part to the message parts accumulated. If the packet contains the Request Session Facility Field, format a Session_Data_Msg (106.4.7) and deliver it to Layer 5 (see Appendix E for information on populating fields of the Session_Data_Msg). If this is packet number 1 of the message, then indicate an incoming call to Layer 5 (including source and destination, vitality, message length, label, and version level). If the end-to-end acknowledgment bit is set, wait 0.5 seconds, then send a selective negative acknowledgment (SNAK) or end-to-end acknowledgment packet. If the message is complete and has passed all of the consistency checks, decompress the message (if received with the compression facility present) and pass the message to Layer 5. Note: If the incoming call has not yet been accepted, send SNAKs “and/or” in response to received packets only if packet number 1 has not arrived yet. A SNAK shall also be sent if the short RCVR timer expires and packet number 1 has not arrived even though the call has not been accepted yet. • A part (or all) of a new receive message. If this is packet number 1 of the message, then indicate an incoming call to Layer 5 (including source/destination, vitality, message length, label, and version level). If this is not packet number 1, then defer the incoming call indication until packet number 1 arrives. If Layer 5 indicates the call is not accepted, reject the message. If Layer 5 indicates that the call is accepted, then accept the packet. If the accepted packet has the end-to-end acknowledgment bit set, then send an end-to-end acknowledgment or selective non-acknowledgment (SNAK) as appropriate. If the accepted packet forms a complete message, decompress the message if the compression facility is present and then pass the message to Layer 5. If the packet is part of a longer message (length > 1) and the packet has the A-bit set (no RF ACKs), then start a short transport timer (30 seconds) for the receiver message. If the packet is part of a longer message, then start a transport timer for the receiver message and wait for the remaining parts. • If there is temporarily insufficient buffer space to accept the message, send a transport delay response to the sender and discard the packet. If there will not be sufficient buffer space to store the message, generate a reject. ver4.0 K-II–40 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX D • A duplicate for a part of a receive message in progress. If the end-to-end acknowledgment bit is not set in the packet, discard it. If the end-to-end acknowledgment bit is set, wait 0.5 seconds, send a selective non-acknowledgment (SNAK) or checkpoint if all lower numbered packets have been received, and discard the received packet. • If the received message label is 106.4.5, indicating a transmit abort for a message, then locate the matching receive message in progress (same source, destination, and message number) and discard all receive packets of that message. • If a received packet has label 106.4.1 (end-to-end acknowledgment or checkpoint), 106.4.2 (SNAK), 106.4.3 (receiver abort), 106.4.4 (receiver reject), or 106.4.6 (receiver delay request), the received packet is passed to the part of the transport entity controlling the transmission of messages (Layer 4 transmission procedures for each mode are defined below). • If some packets of a message are received and the short transport timer expires, then send a SNAK or checkpoint as appropriate. • If some packets of a message are received and the transport timer expires twice without receiving any additional new or duplicate packets for that message, generate a receiver abort message to the originator and discard the received packets. • Transport layer consistency checks shall be performed on each nonservice signal received packet. If the message is vital, then the vital CRC is calculated and checked. 3.3 Transport Layer Consistency Checks The receiving transport entity will reject (reject procedure is defined under end-to-end signalling) or discard any message meeting any one of the criteria listed below: • Vital Bit Set in a packet and Extended Packet Size facility in use. Discard the packet and take no action based upon it. • Vital Bit Set in a packet and Vital redundancy check does not check good. Discard the packet and notify the local health application (including the source and destination address, message label, message length, and the OSI functional layer where the bad CRC was detected). • More bit set and part number equal to Message Length field, or more bit not set and part number not equal to message length. Abort the message. (Abort procedure is defined under end-to-end signalling.) • Part Number field greater than Message Length field. Reject the message. • Part Number field or Message Length field set to 0. Reject the message. • Label from two parts of same message not identical. Abort the message. • Vital bit set in one packet of a message and not in another packet of the same message. Abort the message. 3.4 Layer 4 Originator Procedures The Layer 4 entity shall perform the following 11 functions when originating traffic: 3.4.1 Compress the message data if the compression facility has been requested. Data compression shall occur prior to breaking the message into packets. 3.4.2 Determine the number of packets the message will require (123 bytes per packet if nonvital, 119 bytes per packet if vital, unless the extended packet size facility is used for nonvital messages, in which case there are 251 bytes per packet). 3.4.3 Build the address block from the source/destination provided by Layer 5, and insert the address block into each packet (beginning at Octet 5).a/ 3.4.4 Place the Facility Length field and Facility field (if any) into each packet following the address.a/ 3/1/05 K-II–41 ver4.0 3/1/05 APPENDIX D AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 3.4.5 Set the value of each field in the transport header (message number, more bit, part number, end-to-end ACK bit, length, and vital bit). 3.4.6 Place the transport header (including label) into each packet following the Facility or Facility Length field. 3.4.7 Place the data into the packets. 3.4.8 Calculate and insert the vital CRC if required. 3.4.9 Set Octet 1 of the packet to (ODOlPPPA) where D is the delivery confirmation bit, PPP is the priority, and A is the ARQ disable bit.a/ (More information on D and A are included in the mode procedures.) 3.4.10 When the Layer 4 entity is initialized at start-up, it shall cause the facility code SUPPRESS_TRANSPORT_DUPLICATE_ELIMINATION to be applied to all packets of each message transmitted for the first 10 minutes of device operation. Commentary: This ensures that device restarts do not cause all start-up messages to be discarded at the destination as duplicates. 3.4.11 The originate procedure from this point is dependent upon the mode in which the traffic is to be sent. 4.0 TRANSMISSION MODES 4.1 The transport layer interprets the transmission modes assigned by Layer 6 as follows: Table D.1 Interpretation of transmission modes Mode 0—Broadcast 1—Normal 2—Database 3—Assurance 4—Emergency Broadcast 5—Direct Connect a/ ver4.0 Description No acknowledgments or service signals shall be used at Layers 3 or 4. Multiple copies are used to increase the success probability. “RF acknowledgments” are used. Service signals on the status of packets are obtained from the data network. No acknowledgments or service signals are used at Layer 3. Layer 4 end-to-end acknowledgments are used on some packets. Layer 3 acknowledgments are used, service signals are not used, end-to-end acknowledgment at Layer 4 is used. Layer 3 acknowledgments are no used; however, multiple copies are generated by Layer 4. End-to-end acknowledgments are used. No acknowledgements or service signals shall be used at Layers 3 or 4. Commentary: These functions are classically assigned to Layer 3. They have been included in Layer 4 to localize the conversion from mode to parameters into a single layer and to allow the transport layer to calculate the vital CRC over the Address field. Manufacturers are free to provide equivalent functionality with some or all of these functions included in Layer 3. K-II–42 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX D 4.2 Originate Procedures Table D.2 Originate procedures (page 1 of 3) Originate Procedure Layer 4 Mode 0 (Broadcast) Layer 4 Mode 1 (Normal) Description If the originate traffic is in broadcast mode, then each packet shall have the D, A, and end-to-end acknowledgment bits set to 0, 1, and 0, respectively. Three copies of all of the packets shall be passed to Layer 3 (in order) and, once passed, a successful send shall be signaled to Layer 5. Any returned service signals, aborts, rejects, etc., are ignored. No provision for retransmission shall be made by the transport entity. Note: Three copies are sent to achieve a 99% success rate for the packet given an 80% probability of success on each copy. If the originate traffic is in normal mode, then each packet shall have the D, A, and end-to-end acknowledgment bits set to 1, 0, and 0, respectively. The packets shall be passed to Layer 3 in order, and provision made to retransmit any or all of the packets as required. A transport timer shall be started when the packets are passed to Layer 3 and reset as service signals arrive concerning any of the packets. As delivery confirmation service signals arrive, the packets shall be flagged as completed; when all of the packets are completed, then a successful send shall be indicated to Layer 5. If any other service signal arrives for any of the packets, the Layer 4 entity shall respond as described in the receive section above. If a receiver reject or receiver abort is received for any of the packets, an unsuccessful send shall be indicated to Layer 5. If the transport timer expires the first time, the remaining (uncompleted) packets may be again passed to Layer 3 and the timer reset. If the timer expires again, an unsuccessful send is indicated to Layer 5. If a receiver delay request is received, then wait 15 seconds and restart the message from the beginning. Important Note: If the source address identifier (first digit) is (0 or 2) and the destination address identifier is (0 or 2), or if the source and destination addresses are both on the same vehicle, then assurance mode shall be substituted for normal mode by the originating Layer 4 entity. 3/1/05 K-II–43 ver4.0 3/1/05 APPENDIX D AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Table D.2 Originate procedures (page 2 of 3) Originate Procedure Layer 4 Mode 2 (Database) ver4.0 Description This mode was developed to deliver long low-priority messages reliably without undue delay. While these procedures will work for other types of messages, the efficiency is lower. In the database mode the D and A bits shall be set to 0, and 1 respectively. The message shall be logically divided into blocks of 10 packets. The last packet of each block and the last two packets of the message shall have their end-to-end acknowledgment bits set. The Layer 4 entity shall pass the first block to Layer 3 and start the transport timer. Respond to the following events as indicated: • Expiration of the Transport Timer The originator shall resend the last packet of the current block. On the second expiration of the timer (with no response from the destination) the originator shall again send the last packet of the current block. On the third expiration of the timer, an unsuccessful send shall be indicated to Layer 5. • Receipt of a Selective Non-Acknowledgment Packet The missing packets indicated by the SNAK packet shall be resent, and the transport timer reset. If less than five packets were resent, then the next block shall be sent. If five or more packets were resent, then the last packet in the block shall also be resent. • Receipt of a Reject or Abort An unsuccessful send shall be indicated to Layer 5. No more packets of the message shall be sent or resent. • Receipt of an End-to-End Acknowledgement for the Block If the block is the last in the message, then indicate a successful send to Layer 5. Otherwise, reset the transport timer and send the next block if it has not been sent already. • Receipt of a Receiver Delay Request Delay for 15 seconds and start the message over from the beginning. • Receipt of Service Signals Concerning One or More Packets Proceed as described above under the receive section for the given service signal. K-II–44 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX D Table D.2 Originate procedures (page 3 of 3) Originate Procedure Description Layer 4 This mode is similar to normal mode in that the network has primary responsibility Mode 3 for retries. However, the indication to Layer 4 of successful delivery comes from the (Assurance) destination instead of the network (meaning the indication uses more data link resources and takes a longer time to arrive). The D, A, and end-to-end acknowledgment bits shall be set to 0, 0, and 1, respectively. All of the packets in the message shall be passed to Layer 3 and a transport timer started. Respond to any of the following events as indicated: • Expiration of Transport Timer On first expiration, resend all noncompleted packets and reset timer. On second occurrence, signal Layer 5 of an unsuccessful send. • Receipt of a Receiver Reject or Receiver Abort Request Indicate an unsuccessful message to Layer 5. • Receipt of Service Signals Concerning One or More Packets Proceed as described in the receive section for the service signal received. • Receipt of a Receiver Delay Request Wait 15 seconds and resend the message from the beginning. • Receipt of an End-to-End Acknowledgment for One or More Packets Flag those packets completed and, if the entire message is completed, indicate a successful send to Layer 5. • Receipt of SNAK Resend the missing packets. Layer 4 The D, A, and end-to-end acknowledgment bits shall be set to 0, 1, and 1, Mode 4 respectively. The originating transport entity shall make N copies of the packet(s) (Emergency and pass all of the copies to Layer 3 for delivery. For ground-based systems Broadcast) (dispatch, other hosts), N = 10; for mobile/wayside systems, N = 20. (Note: These messages will often be generated in pairs; therefore, the transport entities shall determine whether more than one such message is available from Layer 5 before passing the first message copies to Layer 3. If additional such messages are available, the copies shall be passed to Layer 3 in interleaved fashion (e.g., copy 1 of message 1, copy 1 of message 2, copy 2 of message 1, etc.). No provision shall be made for retransmission of these messages). A successful send shall be signaled to Layer 5 when an end-to-end acknowledgment is received. An unsuccessful send shall be indicated to Layer 5 if 30 seconds elapse without receipt of an end-to-end acknowledgment. Channel group 1 shall be assigned to each packet in each emergency broadcast message. Layer 4 If the originate traffic is in direct mode, then each packet shall have the D, A, and Mode 5 end-to-end acknowledgement bits set to 0, 1, 0, respectively. One copy of each packet (Direct is passed to Layer 3, and once passed, a successful send shall be signalled to Layer Connect) 5. Any returned service signals, aborts, rejects, etc., are ignored. No provision for retransmission shall be made by the transport entity. 3/1/05 K-II–45 ver4.0 3/1/05 APPENDIX D AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 5.0 TRANSPORT LAYER END-TO-END SIGNALLING 5.1 The transport layer shall be capable of generating and processing the following end-to-end signaling indications in accordance with ATCS Specification 250 and the procedures detailed in this appendix and Appendix P, paragraph 7.0: Table D.3 End-to-end signaling indications End-to-End Signalling Indication End-to-End Acknowledgement (Checkpoint) Selective Non-Acknowledgement (SNAK) Receiver Abort Receiver Reject Transmitter Abort Receiver Delay Request Description Message 106.4.1. This signal shall be generated by the receiving transport layer entity to indicate that all packets in a message up to and including the indicated packet number have been received. When the indicated packet number is not the last packet in the message, this signal is referred to as a checkpoint. Message 106.4.2. This signal shall be generated by the receiving transport layer entity to indicate that packets in a message up to and including the indicated packet number have been received, but that selected packets are missing. The part (packet) numbers of the missing packets shall be listed in this signal. If there are more missing parts than can be accommodated in a single signal, then the message shall be aborted and a receiver abort signal shall be sent. A limit of one retransmission per packet at Layer 4 shall apply, except in Mode 2 where a limit of two retransmissions per packet shall apply. The message shall be aborted if this limit is exceeded. Message 106.4.3. This signal shall be generated by the receiving transport layer entity to indicate that the receiver has aborted the message. The message identifying data (message number, source, and destination) shall be saved so that additional packets of the aborted message are also discarded. Note: The message identifying data should be saved only once. It should not be resaved after being saved by a previous abort or reject of the same message. Message 106.4.4. This signal shall be generated by the receiving transport layer entity to indicate that the receiver has rejected the message. The message identifying data (message number, source, and destination) shall be saved so that additional packets of the rejected message are discarded. Message 106.4.5. This signal shall be generated by the originating (transmitting) transport layer entity to indicate that the transmitter has aborted the message. Message label 106.4.6. This signal shall be generated by the receiving transport layer entity to indicate that it is experiencing temporary local buffering problems and to request a delayed retransmission of the message. 5.2 All end-to-end signals shall have the D- and end-to-end acknowledgement bits reset (set to 0), and the channel group (priority and A bit) shall match the message to which the end-to-end signal refers. ver4.0 K-II–46 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX D 6.0 TRANSPORT LAYER TIMER VALUES The transport timers are channel group dependent and shall be as follows: Channel Group (Hex) 0–1 2–3 4–5 6–7 8–9 A–B C–D E–F Transport Timer Limits 30 seconds 40 seconds 60 seconds 80 seconds 90 seconds 100 seconds 120 seconds 150 seconds Commentary: The Layer 4 packetization process is currently defined to use a 128-byte packet text field. An optional extended packet size facility is available that transfers 251 bytes of nonvital user (Layer 7) data per packet. This facility is supported by all ATCS communications devices but may or may not be supported by the receiving user device. If the facility is not to be supported in a user device, the receipt of packets using this facility should result in the generation of an invalid facility datagram service at Layer 4. 7.0 DEFINITION OF THE TRANSPORT LAYER “VITAL” REDUNDANCY CHECK CODE The transport layer check code shall be calculated on the data from the address length octet of the packet through all of the Layer 7 data (including Layer 4–6 data). This code shall be calculated on and included in each packet of a vital message. The polynomial for this code is: 7 9 1+x +x +x 11 +x 15 +x 16 +x 18 +x 19 +x 25 +x 28 +x 30 +x 31 The result of this calculation shall be stored in the last 4 bytes of the packet, most significant byte first. Note that since this is a power 31 code and there are 32 bits in 4 bytes. the highest order bit of the highest order byte is always 0. See Appendix Y for more information. Bit and byte order of transmission shall be as defined in ATCS Specification 250, Section 3.2.1.1. 8.0 ENCODING OF NETWORK ADDRESSES The Network Address field in the packet header (see paragraph 2.0) is encoded in binary coded decimal (BCD). Digit 0 is encoded as A hexadecimal. 3/1/05 K-II–47 ver4.0 3/1/05 APPENDIX E AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 APPENDIX E NETWORK LAYER (DATAGRAM) PROTOCOL (LAYER 3) 1.0 INTRODUCTION This appendix defines the procedures and requirements for user entities at Layer 3 operating in ATCS datagram mode. 2.0 NETWORK ORIGINATOR PROCEDURES The network layer originating entity shall perform the following six functions: 2.1 Sequentially number all originated packets within each channel group, modulo 128 beginning with 0. Set receive sequence number to 1+ last packet number received on same channel group (modulo 128). Insert the number of the originating packet in the seven high order bits of Octet 3; insert the receive sequence number into the seven high order bits of Octet 4. Set the least significant bit of Octet 3 and 4 to zero. 2.2 Detect and discard any packet from Layer 4 that performs as follows: • Has both the D- and A-bit set to 1. (Invalid because it requests delivery confirmation without RF link acknowledgments.) • Fails to have both the source and destination address length > 0. • Is shorter than the length required to hold the indicated address and facility fields. • Fails to have the first octet set to XX10XXXX where X is a don't care bit. • Has the D-bit set and does not have an allowable source-destination pair as defined by the table below: Source Identifier 0 1 2 3 4 5 Allowable Destination Identifiers (when D-bit is set) 1, 3, 4, 5 0, 1, 2, 3, 4, 5 1, 3, 4, 5 0, 1, 2, 3, 4, 5 0, 1, 2, 3, 4, 5 0, 1, 2, 3, 4, 5 A local procedure error service signal shall be generated to Layer 4 in the event of a violation of this check. • Contains a packet text longer than 256 octets. The entity may optionally generate a datagram service signal back to Layer 4 to indicate (cause = local procedure error) these errors (required for invalid use of D-bit). The entity may optionally implement error notification procedures (alarm generation) when these events occur. 2.3 Generate an invalid Facility field service signal to Layer 4 for any Facility field longer than 24 octets. The Facility field may be used to carry additional protocol information. 2.4 Set the channel field to 0. The use of the channel field to convey optional Layer 3 information may be implemented at a later time. 2.5 Pass the valid packets to Layer 2 for transmission. 2.6 While in the NET_CONGESTION state, do the following: 2.6.1 Check the channel group field of each outbound packet to determine whether it is greater than or equal to the CONGESTION_GROUP. ver4.0 K-II–48 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX E 2.6.2 If the channel group is equal to or greater than the congestion group; discard the packet and generate a NETWORK_CONGESTION service signal to the originator. 3.0 NETWORK RECEIVER PROCEDURES The network layer receiving entity shall perform the following four functions: 3.1 Discard a received packet that meets any of the following criteria: • Fails to have a source and destination address length > 1. • Is shorter than the length required to hold the indicated address and facility fields. • Fails to have Octet 1 set to XX10XXXX and Octets 3 and 4 set to XXXXXXX0 where X indicates a don't care bit. • Has a Facility field longer than 24 bytes or a packet text longer than 256 bytes. 3.2 Pass the received packets that were not discarded to the Layer 4 entity servicing the destination address. This implies a routing function if multiple transport entities are serviced by a common network layer entity. 3.3 Upon receipt of a network congestion service signal from Layer 2, do the following: 3.3.1 Set the value of the internal variable CONGESTION_GROUP to the lesser of CONGESTION_GROUP and the channel group from the service signal. 3.3.2 Start a 30-second internal CONGESTION_TIMER (restart if timer is already running). 3.3.3 Pass the service signal to the appropriate Layer 4 entity. 3.3.4 Enter the NET_CONGESTION state. Note: The network congestion service signal pass to Layer 3 is optional for an FEP/CC, but all Layer 3 user stack entities are required to support receipt of the network congestion service signal. 3.4 Upon expiration of the CONGESTION_TIMER, do the following: 3.4.1 Set the value of the internal variable CONGESTION_GROUP to 20. 3.4.2 Exit the NET_CONGESTION state. 4.0 PROCEDURE TO CREATE A SERVICE SIGNAL 4.1 Given a datagram (or original packet) for which a service signal (new packet) is to be generated, the following procedures shall be employed: • If the Q-bit is set in the original packet, do not generate a service signal. (Service signals about service signals shall not be generated.) • Copy Octets 1 and 2 from the original packet to the new packet. Set the Q-bit in the new packet. Reset the D-bit in the new packet. • Copy Octet 3 of the original packet to Octet 4 of the new packet and Octet 4 of the original packet to Octet 3 of the new packet. • Create an address field in the new packet that has the source/destination reversed from the original packet. Note: This requires exchanging address lengths as well as digits. • Copy the first two octets of the text field of the original packet into the two octets immediately following the address field in the new packet (datagram identification). If the original packet has no text or has insufficient text to fill 2 octets, enter 0 bits in the datagram identification field. • Put the cause code for the service signal into the octet immediately following the datagram identification and the diagnostic code, if any, in the octet following the cause. (If no diag3/1/05 K-II–49 ver4.0 3/1/05 APPENDIX E AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 nostic code is to be sent, insert a 0 octet.) If there is no network information, end the new packet after the diagnostic code. • If there is network information to send, then place it (16 octets maximum) after the diagnostic code and then end the new packet. Commentary: The Cause and diagnostic fields were adopted from CCITT\X.25 (1984). The Cause fields used by ATCS are defined on page K-II–39 of this specification. A diagnostic code of 0 (no further information) is always valid. Other diagnostic codes may be used as defined in CCITT Recommendation X.25 (1984), Annex E. 4.2 Facility Fields The architecture is defined to support additional facilities at a later date. Designs should not preclude the later addition of facilities up to a Facility field length of 24 bytes. Additional facilities (if defined) will use the conventions described in CCITT Recommendation X.25 (1984), Section 7.1 (ignoring the packet types called out in the first sentence). 4.2.1 Optional Extended Packet Size Facility The optional extended packet size facility is defined as follows (assuming no other facilities are present): Facility Length Field Octet Facility Field Octet 1 Facility Field Octet 2 Facility Field Octet 3 Maximum Length of User Data (Layers 4-7) = = = = = 03 H 42 H 08 H 08 H 256 octets All ATCS Communications Components operating in the datagram mode shall support these packets. User devices will support or not support these packets at Layers 3–-4 at the manufacturer's option. A user device that receives an extended size packet and is not programmed to handle that packet will generate an invalid Facility field datagram service signal to the packet's originator. 4.2.2 Compression Facility The compression facility is designed to allow traffic to be compressed to conserve bandwidth on the channel. The facility is defined to support multiple compression algorithms (up to 255). The compression algorithms are applied to Layer 7 data only, but shall not be applied to the message version number. The Facility field for compression is defined as follows (assuming no other facilities are present): Facility Length Field Octet Facility Field Octet 1 Facility Field Octet 2 Facility Field Octet 3 Facility Field Octet 4 Facility Field Octet 5 = = = = = 05H 00H 00H 42H ??H Uncompressed Data Length where ?? is an octet defining the compression algorithm used for this message. The uncompressed data length is defined as the minimum number of 256-byte increments necessary to store the uncompressed data. The following are the compression algorithms defined for ATCS: ver4.0 K-II–50 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics Algorithm Number 00H 01H 02–FFH APPENDIX E Algorithm Name No compression Free Software Foundation “gzip” algorithm, version 1.2.4 [TBD] Reserved In the event that a packet is received with an unsupported compression algorithm, the receiver shall reject the packet with an Invalid Facility Field datagram service signal. The service signal shall contain a “Facility Parameter Not Allowed” diagnostic code and a network information field listing available supported compression algorithms as follows: Network Information Field Octet 1 (Format ID) Network Information Field Octets 2->N (Maximum of 13 Octets) = 01H = Available Compression = Algorithm Numbers If there are no compression algorithms supported, then the no compression (00H) algorithm number should not be sent. 4.2.3 Suppress Transport Duplicate Elimination Facility The suppression facility is designed to ensure that when an ATCS component is restarted, its first several messages are not discarded by the receiver. The Facility field for suppression is defined as follows (assuming no other facilities are present): Facility Length Field Octet Facility Field Octet 1 Facility Field Octet 2 Facility Field Octet 3 Facility Field Octet 4 = = = = = 04H 00H 00H 01H 00H 4.2.4 Peer-to-Peer Signalling Upgrade Offer Facility The peer-to-peer signalling upgrade offer facility is designed to allow Layer 4 entities to negotiate end-to-end signalling at other than revision level 1. The offer is considered accepted if a Layer 4 entity that receives an upgrade offer responds with packets containing the same upgrade offer. The Facility field for the peer-to-peer signalling upgrade offer is defined as follows (assuming no other facilities are present): Facility Length Field Octet Facility Field Octet 1 Facility Field Octet 2 Facility Field Octet 3 Facility Field Octet 4 = = = = = 04H 00H 00H 03H ??H where ?? is an octet defining the revision level for which the offer is being made. 4.2.5 Request Session Facility The request session facility is designed to allow a master device to request a session with a slave device while simultaneously sending an application message to the slave device. The application message that accompanies the facility may require the session to be in effect for delivery. The effect of this facility in a receive packet is to cause the transport layer entity to format a session message (MSA—see Appendix C) and deliver it to the session layer ahead of the message conveyed by the receive packet. 3/1/05 K-II–51 ver4.0 3/1/05 APPENDIX E AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 The Facility field for the request session facility is defined as follows (assuming no other facilities are present: Facility Length Field Octet Facility Field Octet 1 Facility Field Octet 2 Facility Field Octet 3 Facility Field Octet 4 Facility Field Octet 5 Facility Field Octet 6 Facility Field Octet 7 Facility Field Octet 8 Facility Field Octet 9 Facility Field Octet 10 Facility Field Octet 11 Facility Field Octet 12 Facility Field Octet 13 = = = = = = = = = = = = = = 00H—marker 00H—marker C0H—variable length field 01H—reason code 0FH—controlled device address length D1D2H—controlled device address D3D4— D5D6— D7D8— D9D10— D11D12— D13D14— D150— Facility field Octet 4 represents the reason code as defined in Appendix C. Only Reason #1 (MSA) is currently supported. The message created by the transport layer is populated with data as follows: Message Version Reason Code Master ID Slave ID Controlled Device ID Set according to version of message in use Octet 4 of Facility field Source address on packet Destination address on packet Included in Facility Parameter field 5.0 ENCODING OF NETWORK ADDRESSES The network address field in the packet header is encoded in binary coded decimal (BCD). Digit 0 is encoded as A hexadecimal. ver4.0 K-II–52 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX E 6.0 INTERNAL STATES At start-up, the Layer 3 entity is not in the NET_CONGESTION CONGESTION_TIMER is not running; and CONGESTION_GROUP is set to 20. state; the Table E.1 ATCS datagram packet format Bits 8 0 1 0 a/ 7 6 General Format ID D 1 5 4 0 X Logical Channel Number Send Packet Sequence Number P(S) Receive Packet Sequence Number P(R) Source Address 0 1 0 1 Destination Address Octet 1 Destination Address Octet 2 Destination Address Octet 3 Destination Address Octet 4 Destination Address Octet 5 Source Address Octet 1 Source Address Octet 2 Source Address Octet 3 Source Address Octet 4 Source Address Octet 5 0 Facility Length Field (normally 0s) Facility Field (normally not present) User Data (128 octets maximuma/ 3 2 Logical Channel Group X X 1 Octets A 1 2 3 4 0 0 Destination Address 0 1 0 5 6 7 8 9 10 11 12 13 14 15 16 17 to N Unless extended packet size facility is used. Note: These packet formats assume address lengths of 10 digits. All ATCS devices shall be capable of decoding packets with address lengths from 0–15 BCD digits. 3/1/05 K-II–53 ver4.0 3/1/05 APPENDIX E AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Table E.2 ATCS datagram service signal packet format Bits 8 1 1 ver4.0 7 6 General Format ID 0 1 5 4 3 2 Logical Channel Group X X 0 X Logical Channel Number Send Packet Sequence Number P(S) Receive Packet Sequence Number P(R) Source Address Length Destination Address Length 0 1 0 1 0 1 Destination Address Octet 1 Destination Address Octet 2 Destination Address Octet 3 Destination Address Octet 4 Destination Address Octet 5 Source Address Octet 1 Source Address Octet 2 Source Address Octet 3 Source Address Octet 4 Source Address Octet 5 Datagram Identification Octet 1 Datagram Identification Octet 2 Cause Field Diagnostic Code Network Information (16 octets maximum) K-II–54 1 Octets A 1 2 3 4 0 0 0 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20–35 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX F APPENDIX F THIS APPENDIX LEFT BLANK INTENTIONALLY 3/1/05 K-II–55 ver4.0 3/1/05 APPENDIX G AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 APPENDIX G NETWORK LAYER VIRTUAL CIRCUIT [NV] PROTOCOL (LAYER 3) 1.0 INTRODUCTION 1.1 This optional protocol allows a user to access ATCS using an X.25 Public Data Network (PDN) in a nonvital or vital mode. A virtual circuit [NV] protocol adaptor is required at both the user site and at the entrance to ATCS. The interface is illustrated below: Fig. G.1 Network Layer Virtual Circuity Protocol Interface 1.2 The user site has the normal Layers 4–7 protocols. However, instead of passing the partially formed packets to Layer 3, the packets are passed to the virtual circuit [NV] protocol adaptor, which sends/receives packets by opening a switched circuit to an ATCS address and placing what would have been the datagram text (user data) into a virtual circuit packet. The adaptor at the other end recalls the address from the incoming call packet from the PDN, builds a datagram, and enters it into the ATCS network. For users with extensive nonvital communications to a single device, a permanent virtual circuit may be used in the same way. 2.0 IMPLEMENTATION RESTRICTIONS 2.1 The virtual circuit [NV] service shall be provided only to ground host or stationary terminal users for communication with wayside devices (Identifiers 3 and 5) and mobile devices (Identifiers 1 and 4). 2.2 All traffic from the virtual circuit [NV] interface shall be mapped to Channel Groups 6 and 8 (8 for normal packets, 6 for interrupt packets). Emergency service shall not be available across this interface. 2.3 Vital redundancy checks shall be invalidated by this interface. Any packet with the vital bit set to 1 in the transport header shall have that bit set to 0 and the last four octets of the packet discarded by the gateway software. 2.4 The PDN must recognize ATCS addresses or the protocol adaptors shall map ATCS addresses to addresses known to the PDN. 2.5 Fast select and other facilities may be supported by the protocol adaptor on the X.25 virtual circuit side of the interface. 2.6 The network addresses on the datagram side of the interface are encoded in binary coded decimal (BCD). Digit 0 is encoded as A hexadecimal. Network address encoding on the virtual circuit side of the interface is defined by the network (PDN) to which the interface is connected. Commentary: This approach to accessing the ATCS Network may be used with other networks besides X.25. ver4.0 K-II–56 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX H APPENDIX H NETWORK LAYER (DATAGRAM-RADIO NETWORK) PROTOCOL (LAYER 3) 1.0 INTRODUCTION 1.1 The Layer 3 radio network protocol is responsible for controlling the transfer of packets across the radio network. This description refers only to the Layer 3 portion of the protocol. 1.2 The Layer 3 entity that exists on behalf of each RF user shall maintain a prioritized output queue through which packets are passed to Layer 2 for transmission. “Sending” a packet for the remainder of this section refers to placing a packet into this output queue for transmission on the radio (mobile/wayside) or to the base station and then the radio (ground). 1.3 Traffic is controlled on the RF link by channel group. Traffic on odd-numbered channel groups is sent across the radio link without acknowledgment, and traffic on even-numbered channel groups is sent across the radio link with acknowledgments. Lower-numbered channel groups imply higher priority traffic. 1.4 Packets refer to ATCS datagram mode packets. For a detailed description of packet header data, see Appendix E. The term ground is used throughout the remainder of this appendix to refer to the front end processor, cluster controller, or combined front end processor/cluster controller implementing the ground network side of the ARQ mechanism for a given base coverage area. 2.0 DEFINITION OF RF USER A Layer 3 entity shall be maintained in the MCP and ground device (cluster controller or FEP/CC) for each RF user. The following defines RF user: • Each unique 12-digit Layer 3 (network) address prefix for wayside devices (Identifier 3 or 5) shall be treated as an independent RF user by the MCP and ground. This means the object number (last 3 digits) of the Layer 3 (network) address is ignored by the protocol described in this appendix. • Each locomotive (Identifier 1) shall be treated as a single RF user. This means the device extension (last 2 digits) of the Layer 3 (network) address of a locomotive is ignored by the protocol described in this appendix. • Each non-locomotive vehicle (Identifier 4 and 6) shall be treated as a single RF user. This means the device extension (last 2 digits) of the Layer 3 (network) address of these vehicles is ignored by the protocol described in this appendix. • Each truck and personal portable terminal (Identifier 6) shall be treated as a single RF user. This means that the device extension (last 2 digits) of the Layer 3 (network) address of these vehicles is ignored by the protocol described in this appendix. 3.0 TRANSFER OF UNACKNOWLEDGED TRAFFIC (ODD-NUMBERED CHANNEL GROUP) 3.1 When a packet with an odd-numbered logical channel group number is passed to Layer 3 for transmission on the RF, it shall be assigned the next sequential send sequence number for that channel group for that RF user and then sent immediately. Each RF user's MCP shall maintain a list of the last three send sequence numbers received from the ground on each odd-channel group for that RF user. Each entry item in the list shall be initialized to 127. The controlling ground network node (FEP/CC or CC) shall maintain a list of the last three send sequence numbers received from each RF user with which it is in contact. 3.2 When an odd-channel group packet is received by an RF user on the RF link between the ground and an RF user, its send sequence is compared with the numbers in the list. If it matches any of the numbers on the list, it is discarded; otherwise it is forwarded to its destination. Traffic received on the RF link between two RF users is forwarded without comparison to the list. The MCP is able to identify RF-user-to-RF-user traffic by a unique RF link Layer 2 address. 3/1/05 K-II–57 ver4.0 3/1/05 APPENDIX H AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 4.0 TRANSFER OF ACKNOWLEDGED TRAFFIC (EVEN-NUMBERED CHANNEL GROUP) There are two types of acknowledged traffic exchanges on the RF network: (1) exchanges between the ground and an RF user (locomotive, ATCS-equipped vehicle, or wayside device); and (2) exchanges between two RF users. When a wayside device is operating on the base channel pairs in “dark” territory (i.e., outside normal ATCS base station coverage), this is considered to be the second type (RF user—RF user). 4.1 Exchanges of Acknowledged Traffic Between the Ground Network and RF Users 4.1.1 A maximum of one unacknowledged packet may be outstanding in each direction on each acknowledged channel group per RF user. Each end shall maintain the following variables for each acknowledged (even-numbered) channel group: • Timer since last transmission on channel group • Originator send sequence number • Next send sequence number (initialize to 0) • Next receive sequence number (initialize to 0) • Try count (initialize to 0) • Retry timer limit • Last received packet acknowledged (initialize to 0) 4.1.2 Additionally, each end shall maintain the following non-channel group specific data: • Timer since last packet received from distant end • Contact timer limit 4.1.3 Upon receiving a packet to send on an acknowledged channel group, the sending Layer 3 entity shall do the following: 4.1.3.1 Determine if there is already a packet outstanding on that channel group. If there is a packet outstanding on the same channel group, hold the packet until it is its turn to send. (If other packets are also being held on the same channel group, queue it behind the others.) 4.1.3.2 When a packet reaches the head of the queue, obtain the send sequence number from the packet and store it as the originator send sequence number. Obtain the next send sequence number for the channel group and set the send sequence number in the packet to that value. Obtain the next receive sequence number for the channel group and set the last receive acknowledged and the receive sequence number field in the packet to this value. Increment (modulo 128) the value for the next send sequence number. Set the try count to 1. Reset the timer-since-last-transmission variable and send the packet. 4.1.3.3 If the timer-since-last-transmission exceeds the retry time limit and the packet has not been acknowledged, set the receive sequence number in the packet to the next receive sequence number value. If the try count exceeds the maximum number of tries (6), then follow the No Communication (Nocom) procedure in paragraph 4.1.3.4; otherwise, reset the timer-since-last-transmission, increment the try count, and resend the packet. 4.1.3.4 No Communication (Nocom) Procedure (for disposing of unacknowledged packets) If the unacknowledged packet has the D-bit set to 0, discard it. If the D-bit is set to 1, generate a datagram service signal to the originator indicating not obtainable and discard the packet. If contact has not been lost, determine if there are additional packets in queue for transmission and, if so, perform the procedure for a packet reaching the head of the holding queue (see paragraph 4.1.3.2 above); if there are no additional packets and the next receive sequence number and the last receive acknowledged number do not match, send an acknowledgment only packet. ver4.0 K-II–58 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX H 4.1.3.5 Loss of Contact Procedure If the timer since last packet received from distant end expires, perform the nocom procedure for all unacknowledged outstanding packets and all packets being held for transmission. Perform the appropriate manufacturer-defined loss of contact notification procedure. Where loss of contact is to be notified from one device to another, use out of order datagram service signals. 4.1.4 Upon receiving a packet from Layer 2 on an even-channel group, the Layer 3 entity shall do the following: 4.1.4.1 Determine if the receive sequence number in the packet matches (is equal to) the next send sequence number variable. If there is a match and a packet is outstanding, that packet becomes acknowledged. The procedure for an acknowledged packet is the same as the nocom procedure above, except that the service signal should reflect delivery confirmation and the try count is set to 0. 4.1.4.2 Obtain the send sequence number from the packet. If the send sequence number matches the next receive number, follow the new packet procedure; if the send sequence number matches the next receive sequence number –2 (modulo 128), discard the packet. If the send sequence number matches the next receive sequence number –1 and there is no packet outstanding (same channel group), then send an acknowledgment only; if the number does not match any of the above, follow the new packet procedure. 4.1.4.3 New Packet Procedure Set the next receive sequence number to the send sequence number of the message +1 modulo 128. Forward the packet to its destination. If no packet is outstanding or in the queue, generate an acknowledgment only packet. Note: Under no circumstances shall a FEP/CC, CC, or FEP generate a service signal to an address with identifier 1, 3, 4, 5, or 6. 4.2 Procedure for Generating an Acknowledgment Only (Ground/RF) 4.2.1 An acknowledgment only packet shall contain no ground address, packet text, send sequence number, channel number, Facility Length field, or packet text (see Table H.1 and Table H.2). The outbound (cluster controller to MCP) acknowledgment only packet shall contain a destination address but no source address. The inbound acknowledgment packets shall contain only a source address but no destination address. These packets shall be identified by a General Format Identifier (high order 4 bits of Octet 1) of 0011. 4.2.2 An acknowledgment only packet shall be transmitted once only upon receipt of a data packet over the RF between ground and an MCP for which there is no corresponding packet (on the same channel group) to send in the opposite direction to carry the acknowledgment. Acknowledgment only packets are always sent on the same channel group as the packet they acknowledge. 4.2.3 An acknowledgment only packet is discarded when its acknowledgment information is used by the receiver's Layer 3 RF Protocol Entity. No acknowledgment shall be generated for an acknowledgment only packet. Commentary: These packets have been altered to deviate in format from standard datagrams to optimize their size for transmission on the RF in the Reed Solomon Block Code chosen for ATCS. 4.3 Procedure for Generating and Responding to Negative Acknowledgement Only 4.3.1 A negative acknowledgement only (NACK) shall contain no ground address, packet text, send sequence number, channel number, or Facility Length field (see Table H.3). There shall be no outbound NACK. The inbound (MCP to cluster controller) NACK shall contain a source address but no destination address. These packets shall be identified by a General Format Identifier (high order 4 bits of Octet 1) of 0000. 3/1/05 K-II–59 ver4.0 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 APPENDIX H S-5800 4.3.2 A negative acknowledgement only packet shall be transmitted once only upon receipt of an outbound data packet by a mobile MCP to an inactive or out-of-order client on the client vehicle. Optionally, wayside MCPs may generate a NACK only for a wayside client, known to be a client of that MCP and known to be inactive or out of order. NACK only packets are always sent on the same channel group as the packet they negatively acknowledge. The NACK only packet's receive sequence number shall be one greater (modulo 128) than the send sequence number in the NACKed packet. The next expected receive sequence number shall not be updated by the MCP as a result of the outbound packet that caused the NACK to be generated. Likewise, the receive sequence number in any outstanding packet shall not be updated as a consequence of having received the outbound packet that caused the NACK only to be generated. Table H.1 Inbound acknowledgement only packet (MCP to CC) GFI X 1 11 X Receive Sequence Number X X X X Source Address Length 0 1 0 0 Digit 1 Digit 3 Digit 5 Digit 7 Digit 9 Channel Group X X 00 X X Destination Address Length 0 0 Digit 2 Digit 4 Digit 6 Digit 8 Digit 10 0 0 0 Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 Octet 7 Octet 8 Table H.2 Outbound acknowledgement only packet (CC to MCP) GFI 00 X 0 11 X Receive Sequence Number X X X X Source Address Length 0 0 0 1 Digit 1 Digit 3 Digit 5 Digit 7 Digit 9 Channel Group X X X X Destination Address Length 0 1 Digit 2 Digit 4 Digit 6 Digit 8 Digit 10 0 0 0 Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 Octet 7 Octet 8 4.3.3 Upon receipt of a NACK only containing a receive sequence number one greater (modulo 128) than the send sequence number of an outstanding packet to the same RF user on the same channel group, the cluster controller shall generate an incompatible destination service signal to the packet’s originator (unless the address identifier of the originator indicates an RF user), discard the outstanding packet, and proceed to the next queued packet on the same channel group for that RF user (if any). ver4.0 K-II–60 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 S-5800 APPENDIX H 4.4 Exchanges of Acknowledged Traffic Between RF Users Outside Base Coverage The exchange of acknowledged traffic between RF users shall be effected as the exchanges between ground and RF users, with the following exceptions: • Upon receiving a packet from another RF user, an acknowledgment only is generated immediately and sent once only to the originator. • Acknowledgment only packets are the only means by which an outstanding packet may be acknowledged. • No checking is done to determine whether a packet is a duplicate. All received packets (except acknowledgment only) are forwarded to their destination. • Receive packets do not cause an update of the MCP's send or receive state variables. • Send packets do update the MCP's send state variable Commentary: The receive state variable (next expected receive) is unreliable when out of coverage because each packet may be going to a different user than the previous, and each receive packet may come from a different user. Thus the only updates to state variables based on RF-to-RF packets received on the radio occur when the received packet is an acknowledgment only. The transmit (RF user–RF user) traffic does update the send state variable, however, because otherwise the MCP would not be able to recognize acknowledgment only packets as pertaining to the proper outstanding packet. Table H.3 Inbound negative acknowledgement only packet (MCP to CC) GFI 00 X 1 00 X Receive Sequence Number X X X X Source Address Length 0 1 0 0 Digit 1 Digit 3 Digit 5 Digit 7 Digit 9 Channel Group X X X X Destination Address Length 0 0 Digit 2 Digit 4 Digit 6 Digit 8 Digit 10 0 0 0 Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 Octet 7 Octet 8 4.5 Procedure for Generating an Acknowledgment Only Between RF Users Outside Base Coverage Acknowledgment only packets between RF users are in the same format as data packets and are recognized by the absence of a packet text. Note: The RF user–RF user ACK only uses GFI 0010 and has a send and receive sequence number, a Channel field, and a Facility Length field. 3/1/05 K-II–61 ver4.0 3/1/05 APPENDIX H AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 4.6 Retry Intervals The retry intervals to be used if an acknowledgment is not received are as follows (actual timer interval should be randomized within the indicated bounds): Channel Group (Hex) Retry Interval 0 2 4 6 8 A C E 4 seconds ± 0.5 seconds 5 seconds ± 0.5 seconds 8 seconds ± 0.5 seconds 10 seconds ± 1.0 seconds 12 seconds ± 1.0 seconds 13 seconds ± 2.0 seconds 16 seconds ± 2.0 seconds 20 seconds ± 2.0 seconds 5.0 RF POLLED MODE The ground network shall indicate to a specific RF user or to all RF users within range of one or more base stations to enter polled mode via a command message (message number 106.4.9). Upon entering polled mode, an RF user shall be inhibited from turning on his radio transmitter until one of the following events occurs: • Sixty seconds elapse from the time of the enter polled mode command and no poll is received. • Sixty seconds elapse from the receipt of a poll and no new poll is received. • A poll is received (this allows the user to turn on his transmitter one time subject to the restrictions stated in the Layer 1 and 2 descriptions in this document). • An RF poll is message number 106.4.11 6.0 BROADCAST OF POLLING COMMANDS The following broadcast addresses are relevant to RF polling commands: Locomotive Number Track Forces Vehicle Number Railroad Number 0000 0000 000 = = = All Locomotives and Track Forces All Track Forces All Railroads 7.0 RESET OF MCP AT CLUSTER CONTROLLER BOUNDARIES 7.1 When a cluster controller or front end processor/cluster controller adds a new mobile MCP, it shall reset the MCP by sending four copies of the MCP reset packet (this packet is a whole message) using channel group 5, receive sequence number 0, and send sequence numbers 0, 3, 6, and 9 (message number 17.3.4) to the MCP (device 01) (see Table R.10). 7.2 The cluster controller shall discard the old client list upon receipt of a new client list. 7.3 When the MCP receives the reset message, it initializes the state machines for all odd channel groups. It ignores all received acknowledgments for a period of 10 seconds. At the end of the 10 seconds, the next send and receive sequence numbers for each even-channel group are set to 0. Outstanding packets are renumbered as 0 (and the next send number for that channel group set to 1). Outstanding packets are resent starting with try number 1. 8.0 ENCODING OF NETWORK ADDRESSES The Network Address field in the packet header is encoded in binary coded decimal (BCD). Digit 0 is encoded as A hexadecimal. ver4.0 K-II–62 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX H 9.0 OUTBOUND QUEUE PURGE (OPTIONAL) The following procedure may optionally be adopted into the ARQ mechanism of a CC or FEP/CC: Upon receiving a negative acknowledgement (an RF NACK) to an outbound packet, a ground network node searches the outbound queue of packets to the same RF user for packets to the identical Layer 3 address. Packets found in this search are deleted from the queue and discarded. Packets thus discarded that have the D-bit set cause the encode to generate a not obtainable service signal to the originator. The search and discard process is a “one-shot” triggered by the NACK (i.e., the search and discard process does not continue beyond the initial search). 10.0 SERVICE SIGNAL COMMENTARY It is the intent of this specification to preclude the Layer 3 entities residing in the FEP/CC, CC, and MCP (that are responsible for the ARQ process) from causing service signals to be generated that transit the radio link. This does not preclude end-user Layer 3 entities from generating such service signals on an end-to-end basis (e.g., Invalid Facility Request). 3/1/05 K-II–63 ver4.0 3/1/05 APPENDIX I AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 APPENDIX I DATALINK LAYER LAPB PROTOCOL (LAYER 2) 1.0 INTRODUCTION The LAPB protocol is defined by CCITT Recommendation X.25 Section 2. Either the single or multilink procedures may be used for ATCS. This protocol is used to connect ground host and terminal users to the ATCS Data Network at FEPs, CCs, or FEP/CCs. The default data rate for these links shall be 9600 bits per second (19200 and 4800 are optional). The normal connection mode shall be for the ATCS data network component to implement the Data Communications Equipment (DCE) side of the Layer 2 interface and for the user device to implement the Data Terminal Equipment (DTE) interface. 2.0 PARAMETERS 2.1 The following LAPB system parameters are defined in CCITT Recommendation X.25 and ISO 7776, Description of the X.25-compatible DTE data link procedures. These parameters shall be programmable in ATCS devices that implement this protocol. Timer T1: Timer T2: Timer T3: Timer T4: Maximum Number of Transmission Attempts N2: The period at the end of which retransmission of a frame may be initiated. The amount of time available at the DCE or DTE before the acknowledging frame must be initiated in order to ensure its receipt prior to Timer T1 running out at the DTE or DCE. The interval of time required for the DCE to justify considering the data link to be in an out-of-service state. The maximum time a DTE will allow without frames being exchanged on the data link. The maximum number of attempts made by the DCE or DTE to complete the successful transmission of a frame. Commentary: The following relationships between timer values are provided in ISO 7776: a T2 < T1 T3 >>> T4 T4 >> T1 2.2 The following values are offered as suggested values for LAPB system parameters for ATCS devices: Timer T1 : Timer T2 : Timer T3 : Timer T4 : Maximum Number of Transmission Attempts N2 : ver4.0 K-II–64 1.5 seconds 0.5 seconds 30 seconds 5 seconds 7 attempts 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 S-5800 APPENDIX J APPENDIX J DATALINK LAYER ATCS/HDLC POLLED PROTOCOL (LAYER 2) 1.0 INTRODUCTION 1.1 The ATCS/HDLC Polled Protocol shall be used between CCs (or FEP/CCs) and the BCP. The CC (or FEP/CC) implements the master side of the protocol, and one or more BCPs may be attached to the line to implement the slave side of the protocol. 1.2 The protocol provides for the master to poll the slave, to pass information to the slave, and to cause the slave to perform a reset or a self-test. It also provides for the slave to pass information to the master, to inform the master that it has completed sending information, to inform the master of the status of its buffers, and to determine if it is in test mode. (When used in this appendix, the terms master and slave bear no relationship to the same terms in Appendix C of this specification.) 2.0 CC AND BCP PROTOCOL 2.1 The following frames may be sent from master to slave: HDLC Mnemonic UI DISC UP RSET ATCS/HDLC Polled Protocol Interpretation Information frame from master to slave; passes to slave device control software or to radio link as indicated by link layer Address field. Commands slave to enter test mode and perform self-test. Self-test results are reported to the GHEL address (0RRRNN0004) using message number 4.2.1 as part of the normal inbound data stream. Polls the slave. The slave shall send all (up to 5) information frames to the master followed by an RR or RNR frame (see definition below). The PH bit shall be set to 1 in this frame. Commands the slave to perform a power-up reset. Master may send this frame addressed to a single slave or to address FFH to reset all slaves on the line. 2.2 The following frames may be sent from slave to master (only after slave receives a poll from the master). HDLC Mnemonic UI DM RD RR RNR ATCS/HDLC Polled Protocol Information Carries information from slave to master. An extra octet shall be added to the end of the information field of this frame that indicates signal strength/quality (see AAR Manual of Standards and Recommended Practices, Specification S-5830 (Formerly ATCS Specification 230), for meanings of values encoded in this extra octet). Indicates the slave is performing a self-test. Indicates that the slave wants the master to request a self-test. May be sent only in lieu of a UI frame. Indicates slave has room to accept at least five frames of traffic from the master in its buffers. If the final bit is not set, it indicates the slave has additional information frames to send to the master. A slave will always end its response to a poll with either an RR or RNR frame to the master. Indicates slave has no room to accept traffic from the master in its buffers. If the final bit is not set, it indicates the slave has additional information frames to send to the master. A slave shall always end its response to a poll with either an RR or RNR frame to the master. 2.3 All frames shall be HDLC frames bounded by flags. All frames received with an invalid CRC shall be discarded. All frames (in either direction) shall contain the slave's identity in the Address field of the HDLC frame. Neither extended addressing nor extended control fields shall be used. 3/1/05 K-II–65 ver4.0 3/1/05 APPENDIX J AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 2.4 When the master polls a slave, the slave shall respond with up to five UI or RD frames followed by an RR or RNR frame. If the master does not receive an RR or RNR frame within 1.5 seconds of sending a poll, the master shall assume the slave is not going to respond and shall continue the poll cycle. 2.5 The master shall recall the number of UI frames sent to the slave since the last RR was received from the slave. The master shall not send more than 5 UI frames to any slave between receipt of RR frames from that slave. The master shall not send any UI frames to the slave between sending a DISC to the slave and receiving an RR from the slave. The master shall poll the slave periodically while it is in test mode. 2.6 The slave's response to a poll in test mode shall be to return a DM frame followed by an RNR frame with the P bit set to 0. The slave shall send all RR and RNR frames with the NR field set to 0. 2.7 The slave shall always base its decision to send RR or RNR at the end of a frame on whether or not it is capable of accepting five additional frames of information from the master. 3.0 P/F BIT DEFINITION The P/F bits are set in each frame type as shown below: UP frame UI frame RR frame RNR frame DM frame DISC frame P bit = 1 P/F bit = 0 If slave has no more UI frames to send to the master F=1; otherwise F=0 If slave has no more UI frames to send to the master F=1; otherwise F=0 F bit = 1 P bit = 0 4.0 ADDRESS ASSIGNMENTS 4.1 The assignment of Layer 2 addresses on ATCS/HDLC polled links shall be as shown below (master has no assigned address): 0 through 254 255 (FFH) Slave Addresses Broadcast 4.2 The broadcast address shall cause any attached BCP to forward traffic to all of its connected radio channels and shall cause any connected wireline MCP to forward traffic to all of its active client ports. 4.3 By prior agreement between both ends of the link, even-numbered addresses 2 through 252 (decimal) may be used as additional slave addresses. Commentary: Care should be exercised when using even-numbered link addresses to avoid conflicts with the ISO-defined HDLC extended addressing feature. ver4.0 K-II–66 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX K APPENDIX K DATALINK LAYER HDLC BALANCED PROTOCOL (LAYER 2) 1.0 INTRODUCTION The High-level Data Link Control (HDLC) balanced class of procedures shall be used between devices on board locomotives and mobile equipment; between devices in a wayside installation; and between cluster controllers (CCs), front end processors (FEPs), and FEP/CCs to communicate at Layer 2. It also may be used between “star” connected base stations and cluster controllers without the Exchange Identification (XID) procedure described below. The description of the HDLC protocol is divided into the following three parts: • Conformance to HDLC Standards • System Specific HDLC Parameters and Procedures • ATCS Implementation-Specific Parameters and Procedures 2.0 CONFORMANCE TO HDLC STANDARDS 2.1 The following International Standards for Data Communications—High-level Data Link Control Procedures define the HDLC protocol: • ISO 3309—Frame Structure • ISO 4335—Elements of Procedures • ISO 7809—Consolidation of Classes of Procedures 2.2 The HDLC class and the options that shall be implemented are defined in ISO 7809 as balanced operation asynchronous balanced mode class (BAC) 1, 2, 4, and 8. Commentary: The basic BAC repertoire provides the following: • A maximum window size of seven information (I) frames outstanding in either direction. • An asynchronous balanced mode (ABM) and an asynchronous disconnected mode (ADM). BAC options 1, 2, 4, and 8 provide the following: • Option 1 permits combined stations to identify themselves with XID frames. • Option 2 specifies reject frames (REJ) for timely reporting of sequence errors. • Option 4 permits unnumbered information (UI) frames that may be transmitted in any mode. UI frames permit one-way transfer of frames if one end of a link is not responding or is unable to respond. • Option 8 sends all I frames as commands to ensure that each frame contains a destination Layer 2 address in the HDLC frame Address field. 3.0 SYSTEM SPECIFIC HDLC PARAMETERS AND PROCEDURES 3.1 Power-Up Upon power-up or a device reset, the initial mode of all devices shall be set to ADM. Either device may take the initiative to establish a link by sending a set asynchronous balanced mode (SABM) command. After sending an SABM command, the sender shall enter ABM by receiving an unnumbered acknowledgement (UA) response or an SABM. If the sender enters ABM by receiving an SABM, the sender shall immediately send a UA response. 3.2 Maximum Information Field Length The information field shall be a maximum of 301 octets long. 3.3 Timer Limits T1 is the time limit within which a sender expects to receive an acknowledgment to an I frame or a required response to a command. T2 is the maximum interval a receiver may wait before generat3/1/05 K-II–67 ver4.0 3/1/05 APPENDIX K AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 ing a required response to a command or an acknowledgement to an I frame. The T1 timer shall be 1.5 seconds. The T2 timer shall be 0.5 seconds. 3.4 Link The link shall be operated as a two-way simultaneous link. 3.5 Error Handling and Link Time-Out If a device in ABM does not receive a valid frame for an interval exceeding 5 seconds, the device shall enter ADM without requiring an acknowledgement from the remote device and shall also notify the higher layers about a communications problem through a manufacturer-defined mechanism. The HDLC logic shall then attempt to recover the link as if the device had just been restarted. When and if the link recovers, the higher layers shall be informed of the recovery through the receipt of a new address list as a result of the XID exchange. The higher layers may also take appropriate actions to recover the link. 4.0 ATCS IMPLEMENTATION-SPECIFIC PARAMETERS AND PROCEDURES 4.1 XID Devices use the XID process to create their address list. A device shall perform the XID process according to Appendix V at device power-up, device reset, or any time the device's address list changes. The XID process shall be performed with each logical interface to the device. A device shall accept XID frames at any time and shall update its list of valid remote link addresses from the XID frame. Frames sent before the XID exchange shall use the broadcast link address (FF hex). Commentary: Appendix V defines the ATCS requirement for dissemination of link addresses using XID frames. The XID process provides information to higher communication protocol layers and allows the locomotive or track forces terminal to recognize and route frames among both optional and standard entities. It permits an adaptable configuration where ports on the MCP and locomotive computer can be used interchangeably. 4.2 ABM States 4.2.1 The two states for a device in ABM are as follows: • Connected—when at least one XID exchange has occurred after a device power-up or reset. • Disconnected—before at least one XID exchange has occurred after a device power-up or reset. 4.2.2 The connected and disconnected states affect the sending of I frames only. Devices in a disconnected state shall not send I frames. Devices in a connected state shall be able to send I frames. There are no states defined for a device in ADM. 4.2.3 Prior to an XID exchange, the completion of an SABM/UA or the receipt of an I frame shall cause the recipient to initiate an immediate XID exchange. I frames received after an SABM/UA exchange but before the XID exchange shall not be acknowledged until after the XID exchange completes. Only when the link is in the connected state (SABM/UA and XID/XID exchanges completed) shall I frames be sent or acknowledged. 4.3 Checkpointing 4.3.1 Only the OBC, TFT, MCP, CC, and FEP/CC shall be responsible for checkpointing. 4.3.2 Checkpointing is described in ISO 4335. Checkpointing shall be performed over a logical interface whenever a device in the connected state has not received a frame over the logical interface for an interval exceeding 2 seconds. A device performs checkpointing by sending an RR or RNR (whichever matches the current condition of the device) command with the poll bit set. The requirement to perform checkpointing does not prohibit a device from sending any frame (including RR or RNR frames with the poll bit set) at any opportunity the HDLC protocol allows. ver4.0 K-II–68 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX K 4.4 Link Initialization 4.4.1 Only the OBC, TFT, MCP, CC, and FEP/CC shall be responsible for link initialization. 4.4.2 Link initialization shall be performed over all the logical interfaces to a device. Link initialization shall be performed only when a device is in ADM or when a device is in ABM in the disconnected state. A device in ADM shall perform link initialization by sending an SABM or XID command or both at an interval of 1.5 seconds. A device in ABM in the disconnected state shall perform link initialization by sending XID commands at an interval of 1.5 seconds. If an XID response is received by a device in ADM, an SABM shall be generated within 2 seconds unless the device has already received an SABM command. Commentary: Devices other then the OBC, MCP, CC, and FEP/CC may take the initiative to establish the link but they are not required to perform the link initialization procedure. 4.5 Signal Strength Information frames (including UI frames) passed from the base station to the cluster controller shall have a signal strength octet appended to the frame contents (immediately preceding the CRC). The encoding of this extra octet is defined in AAR Manual of Standards and Recommended Practices, Specification S-5830 (Formerly ATCS Specification 230). 4.6 Addressing 4.6.1 When there is a point-to-point connection between a cluster controller and a base station, the cluster controller shall use address 01 and the base station address 03. XID procedures shall not be used in this configuration. 4.6.2 When a wayside interface unit is the only device plugged into an MCP, the wayside interface unit shall use address 03. 4.7 Multiple Addresses Devices that contain multiple Layer 2 addresses shall implement a single logical connection. Such a device shall contain only one send sequence number and one next expected receive sequence number for the connection. Command frames (other than I frames, UI frames, and XID frames) may be addressed to any Layer 2 address of the device. Response frames (other than XID frames) may contain any of the device's Layer 2 addresses. I frames and UI frames shall be addressed to specific entities within the device. Addressing for XID frames is covered in Appendix V. Commentary: For onboard devices, the link address in I or UI command frames shall be that of the final destination device on board the vehicle. For example, a command frame destined for the PMCP will have a link address of 01H; a command frame destined for the FEP will have a link address of 23H, which is the ground network address. 4.8 Address Assignments The assignment of link layer addresses for mobile onboard devices is defined in Appendix T of this specification. The assignment of link layer addresses for CCs, FEPs, and FEP/CCs in the ground network is defined in Appendix V of this specification. 3/1/05 K-II–69 ver4.0 3/1/05 APPENDIX L AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 APPENDIX L DATALINK LAYER (ATCS RADIO LINK) PROTOCOL (LAYER 2) 1.0 INTRODUCTION The radio link datalink layer protocol is used between wayside/mobile users and base stations in coverage areas and between wayside and mobile users in dark territory. 2.0 FRAME STRUCTURE 2.1 The frame structure consists of the following (see Fig. L.1): • A frame synchronization sequence • A destination address type indicator • A pad count indicating the number of bits of 0s added to the information field • A length field indicating the number of blocks required to hold the frame • A header CRC field to verify the validity of the destination address type, the pad count, and the length field • An information field that holds either 0 or 1 datagram packet of information • A packet CRC that verifies the validity of the information field • A pad field containing all bits set to 0 2.2 The frame (starting with the destination address type indicator) is segmented into blocks of 60 bits, and each block has a forward error correction encoding algorithm performed on it as described in Appendix W. The encoded blocks are what actually is transmitted on the radio link. For the base station's send, the “busy bits” are set to 1s when the receive channel is busy and to 0s when the receive channel is idle. (Note: The busy bits are set to 1 during block encoding and are reset to 0 immediately prior to transmission when the receive channel is idle so that the state of the busy bits reflects the state of the channel at transmission time, not at block encoding time.) For the MCP case, all busy bits are set to 1s. FRAME SYNCHRONIZATION ADDRESS TYPE INDICATOR (8 BITS) PAD COUNT (8 BITS) LENGTH (IN BLOCKS) (8 BITS) ENCODED WITH FEC HEADER CRC (16 BITS) DATAGRAM PACKET (VARIABLE LENGTH) PACKET crc (16 BITS) PAD FIELD (VARIABLE LENGTH) Fig. L.1 Radio link frame format (before FEC/busy bit encoding) ver4.0 K-II–70 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX L 3.0 CHANNEL ACCESS PROCEDURE—MCP 3.1 If the state of the channel is “no base carrier present” and/or “receiving noise,” then delay 1300 ms and recheck the channel state. If the channel state is still “no base carrier present/receiving noise,” then access the channel; otherwise proceed to paragraph 3.2. 3.2 If the state of the channel is “receiving a sync pattern (bit or frame),” then execute a random delay (10–800ms) and go to paragraph 3.1. 3.3 If the state of the channel is not any of the conditions listed in paragraphs 3.1 or 3.2 (i.e., a base carrier is present and the channel is receiving a sync pattern—indicating the channel is ready to process information), then paragraph 3.4 will be executed. 3.4 If the state of the channel is “receiving data blocks” and the last three busy bits were set to 0, then access the channel. If less than 3 busy bits were received since the last sync pattern, then execute a random 10–50 ms delay and go to paragraph 3.1. If some or all of the last 3 busy bits indicated busy, then execute a random 10–2000 ms delay and go to paragraph 3.1. 4.0 CHANNEL ACCESS PROCEDURE—BASE STATION 4.1 The BCP may be configured to access the channel continuously or as needed. 4.2 When the BCP is configured for as-needed operation, it shall, upon receiving a packet for transmission, turn on the transmitter, send bit sync, send frame sync, and then alternately send frames and frame sync until it has no more traffic to send. 4.3 When the BCP is configured for continuous operation, it shall send bit sync (at start-up) and then alternately send frame sync and frames of data. When the BCP no longer has frames to send, it shall send the idle send frame defined below. If the base is configured for continuous operation and it receives a message label 106.4.12 addressed to the BCP software, it shall turn off its transmitter and leave it off until its next non-idle transmit frame. Upon receiving the next frame, it shall send the frame as described for as-needed operation and then reenter continuous operation. 5.0 BLOCK ENCODING 5.1 The data to be encoded include the following: • The destination address type • The pad count (initially a byte set to 0) • The length field (initially a byte set to 0) • The header CRC • The information field • The packet CRC 5.2 The data is segmented into blocks of 60 bits. Enough 0 bits are added to the data to make the last block exactly 60 bits in length. The pad count is reset (in the first block) to the number of added bits. The length field (in the first block) is reset to the number of blocks, and the packet and frame CRC are calculated. Important note: Calculating the header CRC before setting the pad count and length field will cause the frame to fail at the receiver. 5.3 The segmented blocks are passed to the encoder (encoding is described in Appendix W). The encoder outputs blocks of 80 bits containing the original data and the Forward Error Correction “parity” bits. 3/1/05 K-II–71 ver4.0 3/1/05 APPENDIX L AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 5.4 Busy bits shall be inserted in the encoded 80-bit blocks. Busy bits are initially set to 1 (busy). There are 5 busy bits added per 80-bit block. They are added as follows: Bits 1–15 Busy Bit 1 Bits 16–30 Busy Bit 2 Bits 31–45 Busy Bit 3 Bits 46–60 Busy Bit 4 Bits 61–75 Busy Bit 5 Bits 76–80 5.5 During transmission, the BCP shall reset the busy bits to 0 if the receive (inbound) channel is idle. The MCP shall always send the busy bits set to 1. 5.6 When an MCP or BCP is transmitting on a radio channel, it shall begin its transmission with bit sync, which shall be followed by a frame sync/frame sequence that may be repeated. No bits shall be inserted between the end of a frame and the following frame sync, nor shall bit sync be repeated, nor shall other bits sync be inserted between blocks in a frame. If there are no more data frames or idle frames to send, the transmitter shall be turned off. 6.0 BLOCK DECODING When a receiver receives a block (frame sync is assumed to have been achieved as described below), the busy bits shall be located and extracted (“on the fly”) to update the channel state information. When a complete block has been received (85 bits received, 5 busy bits removed, yielding an 80-bit block), it shall be passed to the block decoder, which performs an error correction algorithm and returns a block of 60 bits. The first 40 bits of the first block in the frame are checked for a valid (zero error syndrome) header CRC. If a valid header CRC is present, additional blocks shall be decoded as specified by the length field. When the specified number of blocks are received and decoded, the received data (header and packet) shall be passed to the frame decoder. 7.0 FRAME DECODING 7.1 The frame decoder receives a packet from the block decoding process described above. The frame decoder checks the packet CRC. If the CRC is bad, the packet is discarded. If the packet CRC is good, the address type is checked against the type of the receiver and kept (passed to Layer 3) or discarded according to the following table: Table L.1 Packet address-receiver correlation Received Address (Hex) 0 1 3 4 5 23 25 27 FF ver4.0 BCP Discard Keep Keep Keep Keep Keep Keep Discard Keep Receiver MCP-LOCO MCP-WIU Discard Discard Keep Discard Discard Keep Discard Discard Discard Keep Discard Discard Keep Keep Keep Keep Keep Keep K-II–72 MCP-TF/PT Discard Keep Discard Keep Discard Discard Keep Keep Keep 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX L 7.2 Other values are undefined and are reserved for future applications (e.g., RF relays). The Layer 2 addresses are defined in Appendix U. 8.0 STATION IDLE SEND FRAME 8.1 When the base station is configured to send continuously but has no packets to send, it shall send frames consisting of the following: Address Type: Pad Count: Length: Header CRC: Information: CRC: Pad Bits: 00 H B8 H 04 H Calculate normally None Calculate normally 23 bytes of all zero bits 8.2 The busy bits shall be set as normally, and frame synchronization shall precede each frame of four blocks. 9.0 MOBILE/WAYSIDE MAXIMUM CHANNEL HOLDING TIME The maximum channel holding time for the mobile/wayside units (non-emergency) shall be 1.0 seconds. Under emergency conditions, it shall be 3.0 seconds. When the maximum holding time has elapsed, the unit shall complete the current frame and then shall release the channel. Once a mobile/wayside unit releases the channel, it shall not attempt to access the channel again for at least 1.5 seconds. A mobile/wayside unit may send any number of frames on the channel (once accessed) subject to the above restrictions. 10.0 SYNCHRONIZATION SEQUENCE 10.1 When any user (base, mobile, or wayside) accesses the channel, it shall first send a sequence of 40 bits consisting of alternating 1s and 0s. It shall then send a frame sync sequence defined as 07092A446F (each character is hex for a 4-bit sequence). Each frame must be preceded by a frame sync sequence. 10.2 A receiver shall synchronize on a frame synchronization sequence containing up to 5 bit errors. 10.3 When a receiver synchronizes on a frame, it shall check for a valid header CRC in the first decoded block. If a valid header CRC is located, the receiver expects additional blocks to complete the frame as specified by the length field. If the header CRC is invalid or if the length field is greater than 41, the receiver again searches for a frame synchronization sequence. After receiving the entire frame (correctly or not), the receiver again searches for a new frame synchronization. Note that a new frame synchronization may immediately follow the last block of the preceding frame. 11.0 CRC DEFINITION 11.1 The 16-bit CRC for the Radio Link Layer 2 protocol (both header and packet CRC) is transmitted most significant bit (first) to least significant bit (last) and is calculated according to the following polynomial: G(x) = x 3/1/05 16 +x 12 K-II–73 5 +x +1 ver4.0 3/1/05 APPENDIX L AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 11.2 The calculation is described in ISO 3309-1979(E) paragraph 3.6. The ATCS FCS differs in the following respects: 11.2.1 The fields on which the header CRC is calculated are the address type indicator, pad count field (the bits between but not including the last bit of the frame synchronization, and the first bit of the header CRC). 11.2.2 The field on which the packet CRC is calculated is the datagram packet (the bits between but not including the last bit of the header CRC and the first bit of the packet CRC). 11.2.3 ATCS frames (prior to RS encoding and after RS decoding) have no fill bits. 12.0 GROUND CONTACT NOTICE When the MCP radio link Layer 2 protocol entity receives a valid frame (good CRCs) from the ground network, it shall send a GROUND-CONTACT-NOTICE signal to its application entity. Commentary: This allows the application entity to detect losing and regaining base station contact. ver4.0 K-II–74 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX M APPENDIX M PHYSICAL LAYER (ATCS GROUND NETWORK) (LAYER 1) 1.0 INTRODUCTION The default physical layer interface for ATCS ground network components shall be EIA RS232-C (optionally, RS422 may be used). The bit rate shall be 9600 bits per second (optionally 19200, or 4800, or 56KB). Synchronous modems shall be used for all interfaces. Modem types are a railroad-specific decision (compatible modems must be used on each wireline). Pinouts, cables, and connectors are not standardized across ATCS, because requirements differ among modem manufacturers. 3/1/05 K-II–75 ver4.0 3/1/05 APPENDIX N AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 APPENDIX N PHYSICAL LAYER (ATCS RADIO NETWORK) (LAYER 1) 1.0 INTRODUCTION 1.1 The ATCS radio network consists of pairs of UHF channels. In the U.S. and Canada, these channels are as follows: Table N.1 UHF channels for the U.S. and Canadian ATCS radio network Channel Number 1 2 3 4 5 6 Base-to-Mobile Frequency 935.8875 MHz 935.9375 MHz 935.9875 MHz 936.8875 MHz 936.9375 MHz 936.9875 MHz Mobile-to-Base Frequency 896.8875 MHz 896.9375 MHz 896.9875 MHz 897.8875 MHz 897.9375 MHz 897.9875 MHz 1.2 Transmission on the channels is baseband FSK. The deviation of the carrier to a higher frequency is interpreted as a logical 0 and to a lower frequency as a logical 1. The bit rate is 4800 bits per second + 100 ppm. Nominal channel separation is 12.5 kHz. 1.3 When communicating out of coverage, Channel 1 shall be used. Commentary: In Canada, for DOC licensing purposes, the out-of-coverage channels are Channels 7–12. These channels should, however, be identified to the MCP as Channels 1–6 in messages sent to the MCP. Also note that when the MCP is operating on Channel 1 out of coverage and an emergency inbound (to ground network) packet in received from the client, the MCP will send the packet on 896.8875 MHz (Channel 1 MCP–BCP frequency). ver4.0 K-II–76 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX O APPENDIX O PHYSICAL LAYER (ATCS MOBILE NETWORK) (LAYER 1) 1.0 INTRODUCTION 1.1 The box-mounted receptacle on a TFT or an OBC for connection to synchronous onboard devices shall be an MS 3112 E-22-55 S connector or railroad-approved equivalent (pin assignments are shown below), which shall mate with an MS 3116 F-22-55 P connector or railroad-approved equivalent. Each 55-pin connector shall service a maximum of four synchronous ports; onboard components shall occupy any one of the four available ports. The electrical interface between a TFT or an OBC and attached onboard components shall be in accordance with the EIA RS-422-A standard. 1.2 The box-mounted receptacle on onboard components for connection to a TFT or an OBC shall be an MS 3112 E-14-15 S connector or railroad-approved equivalent (pin assignments are shown below), which shall mate with an MS 3116 F-14-15 P connector or railroad-approved equivalent. 1.3 The box-mounted receptacle on a WIU for connection to synchronous devices (e.g., an MCP) shall be an MS 3112 E-14-15 S connector or railroad-approved equivalent, which shall mate with an MS 3116 F-14-15 P connector or railroad-approved equivalent. The electrical interface between the WIU and attached devices shall be in accordance with the EIA RS-422-A standards. 1.4 Part numbers to solder-type connectors bear the prefix MS 3112 for the box-mounted receptacle and MS 3116 for the mating connector. Part numbers to crimp-type connectors bear the prefix MS 3122 and MS 3126, respectively. Solder- and crimp-type connectors are equally acceptable. Crimp-type connectors make it easier to replace damaged pins in the field, are reliable, and are widely used in harsh environments. Cable shields shall be grounded to the TFT, OBC, or WIU and not at the opposite ends to avoid ground loops. Cable shields shall not be grounded to MCPs. 1.5 The physical interfaces in the onboard network for ATCS shall be in accordance with RS422A using a MS 3112 E 14-15 S (or railroad-approved equivalent) connector that mates with an MS 3116 F 14-15 S (or railroad-approved equivalent) plug. This applies to ports into the locomotive computer, the track forces terminal (TFT), the MCP, and the wayside interface unit. The shields shall be grounded to the locomotive computer or the TFT and not at the opposite ends to avoid ground loops. Where a device other than the locomotive computer or the TFT connects to the MCP, that other device shall be grounded to the shield. 1.6 The data rate is transmitter determined in the range 2400–19200 bits per second (recommend 19200). The transmitter clock shall be synchronized to the transmit data. The receiver shall expect the receive clock to be synchronized to the received data. The on-to-off transition of the clock signal shall mark the center of the data element (bit). Coding of data is NRZ. 3/1/05 K-II–77 ver4.0 3/1/05 APPENDIX O AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 1.7 Pin assignments for the MS 3112 E-22-55 S box-mounted receptacle are shown in Table O.1. Table O.1 Pin assignments for MS 3112 E-22-55 S box-mounted receptacle Pin A B C D E F G H J K L M N P R S T U V W X Y Z a b c d e ver4.0 Signal Name (Port No.) Send Clock A (1) Send Clock B (1) Send Data A (1) Send Data B (1) Spare Send Clock B (2) Receive Clock B (2) Receive Data B (2) Spare (2) Spare (3) Receive Data B (3) Receive Clock B (3) Send Clock B (3) Spare (3) Send Data B (4) Send Data A (4) Send Clock B (4) Send Clock A (4) Spare (4) Receive Clock A (1) Receive Clock B (1) Receive Data A (1) Receive Data B (1) Send Clock A (2) Receive Clock A (2) Receive Data A (2) Spare (2) Spare (2) Pin f g h i j k m n p q r s t u v w x y z AA BB CC DD EE FF GG HH K-II–78 Signal Name (Port No.) Receive Data A (3) Receive Clock A (3) Send Data B (3) Send Clock A (3) Receive Data B (4) Receive Data A (4) Receive Clock B (4) Receive Clock A (4) Spare (4) Signal Ground (1) Spare (1) Spare (1) Send Data B (2) Signal Ground (2) Spare (2) Signal Ground (3) Send Data A (3) Spare (3) Spare (4) Signal Ground (4) Shield (4) Shield (1) Send Data A (2) Shield (2) Spare (3) Spare (4) Shield (3) 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P APPENDIX P PROTOCOL STATE/FLOW DIAGRAMS 1.0 INTRODUCTION 1.1 This appendix describes seven of the ATCS-layered protocols in a graphical format. These seven were selected because they were developed wholly or in part for ATCS, or were adapted from a proprietary protocol for ATCS use. 1.2 The graphical format was adapted from the CCITT Recommendations Z.101–Z.104. These diagrams do not strictly adhere to the CCITT format. However, the reader familiar with the CCITT format will find these diagrams easy to follow. The diagrams are of three types: • One type shows the environment in which the state machines exist. • One type shows the state transitions for a named state machine. • One type describes the processes that are executed during state transitions. 1.3 These diagrams are not intended to reflect a required design or implementation. Manufacturers are free to design their equipment in any manner that provides a functionally equivalent implementation of the protocols. 1.4 These diagrams contain a number of instances of sending and receiving signals. Several notes about the assumptions made with regard to signals are appropriate: • A signal may be received or discarded only while in a named state. Signals received during state transitions are queued. • A state machine may signal itself or another state machine at the same or adjacent layer. • A handler for “others” may be used to capture and queue signals not handled by a state. • If a signal is received while in a state for which there is no handler (no box to receive the signal) and there is no “others” handler shown below the state, then the signal is lost. • Signals for a state machine are queued in a FIFO manner. 1.5 A list of assumptions applicable to the diagrams for each protocol precedes the diagrams applicable to that protocol. 2.0 PROTOCOL FLOW DIAGRAM LISTING Paragraph K-II–3.0 K-II–4.0 K-II–5.0 K-II–6.0 K-II–7.0 K-II–8.0 K-II–9.0 3/1/05 Topic Busy Bit Channel Access for MCP Layer 3 for MCP Layer 3 for CC Layer 3 User Protocol Layer 4 User Protocol Layer 5 User Protocol Layer 6 User Protocol K-II–79 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.1 Symbols used in Appendix P ver4.0 K-II–80 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Table P.1 Chart index for Appendix P, Paragraph 3.0 Name Page Relationship of MCP busy bit machine to MCP layers 1 and 2 Busy bit machine—MCP Get channel Defined On K-II–87 K-II–88 K-II–89 Called From K-II–88 Table P.2 Chart Index for Appendix P, Paragraph 4.0 (page 1 of 2) Name Page Defined On K-II–90 K-II–91 K-II–92 K-II–93 K-II–94 K-II–95 K-II–96 K-II–97 K-II–98 K-II–99 K-II–100 K-II–101 K-II–102 K-II–103 K-II–104 K-II–105 MCP MCP layer 3/MCP RF protocol Start—MCP Layer 3 MCP add MCP delete MCP enter net MCP leave net MCP inbound MCP outbound MCP handle contact timer MCP init Broadcast match Start—odd MCP Process inbound odd Process outbound odd Initialize odd machine Start—even MCP Process retry Process inbound even Process outbound even Initialize even machine K-II–106 K-II–107 K-II–108 K-II–109 K-II–110 Clear outbound queue K-II–111 Prepare/send outbound even K-II–112 Prevention Handle ACKs MCP reset Even reset K-II–113 K-II–114 K-II–115 K-II–116 3/1/05 K-II–81 Called From K-II–92 K-II–92 K-II–122 K-II–122 K-II–92 K-II–92 K-II–120 K-II–92 K-II–97 K-II–102 K-II–102 K-II–102 K-II–117 K-II–106 K-II–106 K-II–106 K-II–106 K-II–116 K-II–106 K-II–110 K-II–107 K-II–109 K-II–114 K-II–116 K-II–108 K-II–108 K-II–92 K-II–106 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Table P.2 Chart Index for Appendix P, Paragraph 4.0 (page 2 of 2) Name Page Defined On K-II–117 K-II–118 K-II–119 Odd reset MCP reset complete MCP validate outbound Start—MCP application MCP_APP_INIT Process message Process active scan timer Process passive scan timer Process HEALTH TIMER Process Ground Contact Notice Process SET_RADIO_CHANNEL_MSG Process SET_HEALTH_RPTING_RATE_MSG Process NOTIFY_MCP_COMMAND_MSG Process RESET_MCP_MSG Process lost contact reset timer Process outbound sent Process beacon timer Process MCP init request Called From K-II–102 K-II–93 K-II–104 K-II–112 K-II–120 K-II–121 K-II–122 K-II–123 K-II–124 K-II–125 K-II–126 K-II–127 K-II–128 K-II–129 K-II–130 K-II–131 K-II–131 K-II–132 K-II–133 K-II–120 K-II–120 K-II–120 K-II–120 K-II–120 K-II–120 K-II–122 K-II–122 K-II–122 K-II–122 K-II–120 K-II–120 K-II–120 K-II–93 Table P.3 Chart Index for Appendix P, Paragraph 5.0 (page 1 of 3) Name Page Defined On K-II–134 K-II–135 K-II–136 K-II–137 K-II–138 K-II–139 K-II–140 K-II–141 K-II–142 K-II–143 Cluster controller Layer 3 CC-RF protocol CC RF protocol—CC sorter Inbound sort Outbound sort Link pass CC odd state machine Process inbound odd Process outbound odd Initialize odd machine CC even state machine Initialize even machine K-II–144 K-II–145 Process retry Process inbound even K-II–146 K-II–147 ver4.0 K-II–82 Called From K-II–136 K-II–136 K-II–136 K-II–140 K-II–140 K-II–140 K-II–155 K-II–144 K-II–156 K-II–144 K-II–144 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Table P.3 Chart Index for Appendix P, Paragraph 5.0 (page 2 of 3) Name Page Defined On K-II–148 K-II–149 K-II–150 Handle ACKs Process outbound even Process control loss Clear outbound queue Prepare/send outbound even K-II–151 K-II–152 Perform MCP reset Handle NACKs Process odd reset Process even reset MCP reset complete CC validate outbound K-II–153 K-II–154 K-II–155 K-II–156 K-II–157 K-II–158 Add RF user K-II–159 Remove RF user START_GHNO Process outbound packet Process RF inbound Process trunk contact Process purge timer Process direct timer Process denied timer Process search timer Process contact timer Process vehicle contact timer Process vehicle contact Process RF message Process REQUEST_MCP_RESET_MSG Process capabilities Process trunk message Process pull Process push Process push attempt control Process push no control Process search K-II–159 K-II–160 K-II–161 K-II–162 K-II–163 K-II–164 K-II–165 K-II–166 K-II–166 K-II–167 K-II–168 K-II–169 K-II–169 K-II–170 K-II–171 K-II–172 K-II–173 K-II–174 K-II–175 K-II–176 K-II–177 3/1/05 K-II–83 Called From K-II–147 K-II–144 K-II–144 K-II–146 K-II–145 K-II–146 K-II–148 K-II–149 K-II–152 K-II–154 K-II–156 K-II–136 K-II–147 K-II–140 K-II–144 K-II–136 K-II–142 K-II–152 K-II–136 K-II–137 K-II–136 K-II–160 K-II–160 K-II–160 K-II–160 K-II–160 K-II–160 K-II–160 K-II–160 K-II–160 K-II–162 K-II–162 K-II–169 K-II–169 K-II–160 K-II–172 K-II–172 K-II–174 K-II–174 K-II–172 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Table P.3 Chart Index for Appendix P, Paragraph 5.0 (page 3 of 3) Name Page Defined On K-II–178 K-II–179 K-II–180 K-II–181 K-II–182 K-II–183 K-II–184 K-II–185 K-II–186 K-II–187 K-II–188 K-II–189 Process global notice Process contact notice Process denied Process assist Process assist attempt control Process assist no control Process shared assist Process shared attempt control Process shared no control Process CTL list Determine control Late Called From K-II–172 K-II–172 K-II–172 K-II–172 K-II–181 K-II–181 K-II–172 K-II–184 K-II–184 K-II–172 K-II–187 K-II–173 K-II–178 Table P.4 Chart Index for Appendix P, Paragraph 6.0 Name Page Defined On K-II–190 K-II–191 K-II–192 K-II–193 K-II–194 K-II–195 Start—User Layer 3 Initialize user Layer 3 User 3 originate User 3 receive User 3 validate outgoing Process congestion timer Called From K-II–190 K-II–190 K-II–190 K-II–192 K-II–190 Table P.5 Chart Index for Appendix P, Paragraph 7.0 (page 1 of 2) Name Page Defined On K-II–196 K-II–197 K-II–198 K-II–199 K-II–200 K-II–201 K-II–202 K-II–203 K-II–204 K-II–205 K-II–206 Layer 4 (end user) Layer 4 sorter L4 got a packet Process duplicate in complete message Interleaver Sender XMTR L4 initialize transmitter L4 initiate sending Packetize data Initiate broadcast ver4.0 K-II–84 Called From K-II–197 K-II–198 K-II–200 K-II–202 K-II–202 K-II–204 K-II–204 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Table P.5 Chart Index for Appendix P, Paragraph 7.0 (page 2 of 2) Name Page Defined On K-II–207 K-II–208 K-II–209 Initiate normal Initiate data base Initiate assurance Initiate emergency broadcast L4 process transmitter timer Data base timer Normal timer Assurance timer Emergency timer L4 Process service signal L4 process E/E signal L4 process checkpoint L4 process SNAK L4 process delay timer L4 process completion RCVR L4 process XMT abort L4 process RCV packet (page 1 of 2) L4 process RCV packet (page 2 of 2) L4 build MSG L4 process RCVR timer L4 process reject L4 process completion L4 process accept L4 initialize RCVR Consistency L4 accepted and complete K-II–210 K-II–211 K-II–212 K-II–213 K-II–214 K-II–214 K-II–215 K-II–216 K-II–217 K-II–218 K-II–219 K-II–220 K-II–220 K-II–221 K-II–222 K-II–223 K-II–224 K-II–225 K-II–226 K-II–227 K-II–228 K-II–229 K-II–230 K-II–231 Initiate direct L4 process short RCVR timer Assign next message number K-II–232 K-II–233 K-II–234 3/1/05 K-II–85 Called From K-II–204 K-II–204 K-II–204 K-II–207 K-II–204 K-II–202 K-II–211 K-II–211 K-II–211 K-II–211 K-II–202 K-II–202 K-II–216 K-II–216 K-II–202 K-II–202 K-II–220 K-II–220 K-II–231 K-II–220 K-II–220 K-II–220 K-II–220 K-II–220 K-II–220 K-II–231 K-II–223 K-II–228 K-II–204 K-II–220 K-II–197 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Table P.6 Chart Index for Appendix P, Paragraph 8.0 Name Page Defined On K-II–236 K-II–237 K-II–238 K-II–239 K-II–240 K-II–241 K-II–242 Gen_Purpose Session mapper Process receive message Matching MS machine exists Tfinder Master To M_MREQ out To M_SREQ out To M_Open K-II–243 K-II–244 To M_Closeout Slave To S_MREQ out K-II–245 K-II–246 K-II–247 MSA/MREQ out MSB/MREQ out MSC/MREQ out PSC/MREQ out To S_SREQ out K-II–248 K-II–249 K-II–250 K-II–251 K-II–252 MSA/SREQ out MSB/SREQ out MSC/SREQ out To S_Open K-II–253 K-II–254 K-II–254 K-II–255 MSA/Open MSB/Open PSC/SREQ out PSD/SREQ out K-II–256 K-II–257 K-II–258 K-II–259 Called From K-II–237 K-II–238 K-II–237 K-II–241 K-II–243 K-II–241 K-II–242 K-II–243 K-II–245 K-II–244 K-II–246 K-II–252 K-II–247 K-II–247 K-II–247 K-II–247 K-II–246 K-II–247 K-II–255 K-II–252 K-II–252 K-II–252 K-II–247 K-II–252 K-II–255 K-II–255 K-II–252 K-II–252 Table P.7 Chart Index for Appendix P, Paragraph 9.0 Name Page Defined On K-II–260 K-II–261 K-II–262 K-II–263 Presentation layer state machine Process receive message Process incoming call Process message to send ver4.0 K-II–86 Called From K-II–260 K-II–260 K-II–260 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P 3.0 BUSY BIT CHANNEL ACCESS FOR MCP 3.1 MCP Busy Bit Assumptions • Diagram is meant to show channel access rules under busy bit operation. • Busy bit mechanism is the same for emergency and normal traffic, except that channel holding timer is longer for emergency traffic. • Sending a frame includes performing all necessary frame formatting (including FEC blocks). • Base Station busy bit mechanism is not shown. Base Station is assumed to turn on busy bits when carrier is detected. 3.2 Diagrams Fig. P.2 Relationship of MCP busy bit machine to MCP layers 1 and 2 3/1/05 K-II–87 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.3 Busy bit machine—MCP ver4.0 K-II–88 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Note: “Current State” indicates the state of the channel obtained by the receiver. Fig. P.4 Get channel 3/1/05 K-II–89 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 4.0 LAYER 3 FOR MCP 4.1 MCP Layer 3 Assumptions • User is interpreted as defined in ATCS Specification 200, Appendix H. • There is only one set (of 16) state machines (evens and odds) for a vehicle. The number of sets of state machines for a wayside client may vary depending on the communication performance requirements of the field site. This number corresponds to the amount of unique 12-digit prefixes in the wayside addresses contained within the MCP’s active client list. See Appendix T for network address structures. • There is only one set (of 16) state machines (evens and odds) for a vehicle. There are as many sets of machines as there are Layer 3 addresses for a wayside client. • Queues to and from routing and Layer 2 are prioritized queues. • Routing logic is manufacturer defined. • In/out of contact signalling originates from routing block based on notifications from client. • Receive Layer 2 address values are visible to Layer 3. 4.2 Diagrams Fig. P.5 MCP ver4.0 K-II–90 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.6 MCP layer 3/MCP RF protocol 3/1/05 K-II–91 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.7 Start—MCP Layer 3 ver4.0 K-II–92 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.8 MCP add 3/1/05 K-II–93 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.9 MCP delete ver4.0 K-II–94 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.10 MCP enter net 3/1/05 K-II–95 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.11 MCP leave net ver4.0 K-II–96 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.12 MCP inbound 3/1/05 K-II–97 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.13 MCP outbound ver4.0 K-II–98 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.14 MCP handle contact timer 3/1/05 K-II–99 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.15 MCP init ver4.0 K-II–100 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.16 Broadcast match 3/1/05 K-II–101 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.17 Start—odd MCP ver4.0 K-II–102 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.18 Process inbound odd 3/1/05 K-II–103 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.19 Process outbound odd ver4.0 K-II–104 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.20 Initialize odd machine 3/1/05 K-II–105 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.21 Start—even MCP ver4.0 K-II–106 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.22 Process retry 3/1/05 K-II–107 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.23 Process inbound even ver4.0 K-II–108 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.24 Process outbound even 3/1/05 K-II–109 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.25 Initialize even machine ver4.0 K-II–110 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.26 Clear outbound queue 3/1/05 K-II–111 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.27 Prepare/send outbound even ver4.0 K-II–112 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.28 Prevention 3/1/05 K-II–113 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.29 Handle ACKs ver4.0 K-II–114 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.30 MCP reset 3/1/05 K-II–115 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.31 Even reset ver4.0 K-II–116 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.32 Odd reset 3/1/05 K-II–117 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.33 MCP reset complete ver4.0 K-II–118 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.34 MCP validate outbound 3/1/05 K-II–119 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.35 Start—MCP application ver4.0 K-II–120 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.36 MCP_APP_INIT 3/1/05 K-II–121 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.37 Process message ver4.0 K-II–122 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.38 Process active scan timer 3/1/05 K-II–123 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.39 Process passive scan timer ver4.0 K-II–124 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.40 Process HEALTH TIMER 3/1/05 K-II–125 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.41 Process Ground Contact Notice ver4.0 K-II–126 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.42 Process SET_RADIO_CHANNEL_MSG 3/1/05 K-II–127 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.43 Process SET_HEALTH_RPTING_RATE_MSG ver4.0 K-II–128 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.44 Process NOTIFY_MCP_COMMAND_MSG 3/1/05 K-II–129 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.45 Process RESET_MCP_MSG ver4.0 K-II–130 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.46 Process lost contact reset timer Fig. P.47 Process outbound sent 3/1/05 K-II–131 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.48 Process beacon timer ver4.0 K-II–132 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.49 Process MCP init request 3/1/05 K-II–133 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 5.0 LAYER 3 FOR CC 5.1 Cluster Controller Assumptions • “User” in the sort routine is interpreted as defined in Appendix H. • The assumptions stated in Appendix R are in effect. • Internal routing and tracking logic is manufacturer defined. This appendix assumes tracking data will be maintained in a table. The tracking table will be maintained by the handoff application (GHNO) and be queried by the RF protocol and ground network routing (routing) entities. In this appendix, the tracking table is assumed to perform the functionality of the Vehicle Routing table discussed in Appendix R. • Routing passes outbound traffic to GHNO only if the tracking table agrees that this cluster controller has control of that user. Otherwise, routing discards traffic, forwards traffic, and/or generates an appropriate datagram service signal. • Base station queues are prioritized queues. 5.2 Diagrams Fig. P.50 Cluster controller Layer 3 ver4.0 K-II–134 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.51 CC-RF protocol 3/1/05 K-II–135 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.52 CC RF protocol—CC sorter ver4.0 K-II–136 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.53 Inbound sort 3/1/05 K-II–137 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.54 Outbound sort ver4.0 K-II–138 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.55 Link pass 3/1/05 K-II–139 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.56 CC odd state machine ver4.0 K-II–140 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.57 Process inbound odd 3/1/05 K-II–141 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.58 Process outbound odd ver4.0 K-II–142 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.59 Initialize odd machine 3/1/05 K-II–143 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.60 CC even state machine ver4.0 K-II–144 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.61 Initialize even machine 3/1/05 K-II–145 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.62 Process retry ver4.0 K-II–146 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.63 Process inbound even 3/1/05 K-II–147 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.64 Handle ACKs ver4.0 K-II–148 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.65 Process outbound even 3/1/05 K-II–149 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.66 Process control loss ver4.0 K-II–150 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.67 Clear outbound queue 3/1/05 K-II–151 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.68 Prepare/send outbound even ver4.0 K-II–152 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.69 Perform MCP reset 3/1/05 K-II–153 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.70 Handle NACKs ver4.0 K-II–154 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.71 Process odd reset 3/1/05 K-II–155 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.72 Process even reset ver4.0 K-II–156 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.73 MCP reset complete 3/1/05 K-II–157 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.74 CC validate outbound ver4.0 K-II–158 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.75 Add RF user Fig. P.76 Remove RF user 3/1/05 K-II–159 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.77 START_GHNO ver4.0 K-II–160 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.78 Process outbound packet 3/1/05 K-II–161 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.79 Process RF inbound ver4.0 K-II–162 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.80 Process trunk contact 3/1/05 K-II–163 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.81 Process purge timer ver4.0 K-II–164 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.82 Process direct timer 3/1/05 K-II–165 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.83 Process denied timer Fig. P.84 Process search timer ver4.0 K-II–166 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.85 Process contact timer 3/1/05 K-II–167 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.86 Process vehicle contact timer ver4.0 K-II–168 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.87 Process vehicle contact Fig. P.88 Process RF message 3/1/05 K-II–169 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.89 Process REQUEST_MCP_RESET_MSG ver4.0 K-II–170 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.90 Process capabilities 3/1/05 K-II–171 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.91 Process trunk message ver4.0 K-II–172 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.92 Process pull 3/1/05 K-II–173 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.93 Process push ver4.0 K-II–174 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.94 Process push attempt control 3/1/05 K-II–175 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.95 Process push no control ver4.0 K-II–176 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.96 Process search 3/1/05 K-II–177 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.97 Process global notice ver4.0 K-II–178 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.98 Process contact notice 3/1/05 K-II–179 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.99 Process denied ver4.0 K-II–180 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.100 Process assist 3/1/05 K-II–181 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.101 Process assist attempt control ver4.0 K-II–182 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.102 Process assist no control 3/1/05 K-II–183 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.103 Process shared assist ver4.0 K-II–184 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.104 Process shared attempt control 3/1/05 K-II–185 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.105 Process shared no control ver4.0 K-II–186 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.106 Process CTL list 3/1/05 K-II–187 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.107 Determine control ver4.0 K-II–188 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.108 Late 3/1/05 K-II–189 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 6.0 LAYER 3 USER PROTOCOL 6.1 Layer 3 User Protocol Assumptions • Packetizing function is performed at Layer 4 (dividing message into packets). • Packets may have text fields up to 256 bytes and Facility fields up to 24 bytes. • These diagrams do not reflect local (within the user device) routing that may be required if multiple applications are present within the user device. 6.2 Diagrams Fig. P.109 Start—User Layer 3 ver4.0 K-II–190 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.110 Initialize user Layer 3 3/1/05 K-II–191 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.111 User 3 originate ver4.0 K-II–192 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.112 User 3 receive 3/1/05 K-II–193 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.113 User 3 validate outgoing ver4.0 K-II–194 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.114 Process congestion timer 3/1/05 K-II–195 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 7.0 LAYER 4 USER PROTOCOL 7.1 Transport Layer Assumptions • All signals to and from Layer 5 (session) contain the data specified in Appendix C, Table C.2. • A separate Layer 4 state machine is created for each send and receive message. 7.2 Diagrams Fig. P.115 Layer 4 (end user) ver4.0 K-II–196 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.116 Layer 4 sorter 3/1/05 K-II–197 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.117 L4 got a packet ver4.0 K-II–198 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.118 Process duplicate in complete message 3/1/05 K-II–199 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Note: Interleaver is used for special emergency broadcast traffic only. Fig. P.119 Interleaver ver4.0 K-II–200 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.120 Sender 3/1/05 K-II–201 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.121 XMTR ver4.0 K-II–202 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.122 L4 initialize transmitter 3/1/05 K-II–203 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.123 L4 initiate sending ver4.0 K-II–204 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.124 Packetize data 3/1/05 K-II–205 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.125 Initiate broadcast ver4.0 K-II–206 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.126 Initiate normal 3/1/05 K-II–207 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.127 Initiate data base ver4.0 K-II–208 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.128 Initiate assurance 3/1/05 K-II–209 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.129 Initiate emergency broadcast ver4.0 K-II–210 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.130 L4 process transmitter timer 3/1/05 K-II–211 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.131 Data base timer ver4.0 K-II–212 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.132 Normal timer 3/1/05 K-II–213 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.133 Assurance timer Fig. P.134 Emergency timer ver4.0 K-II–214 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.135 L4 Process service signal 3/1/05 K-II–215 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.136 L4 process E/E signal ver4.0 K-II–216 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.137 L4 process checkpoint 3/1/05 K-II–217 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.138 L4 process SNAK ver4.0 K-II–218 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.139 L4 process delay timer 3/1/05 K-II–219 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.140 L4 process completion Fig. P.141 RCVR ver4.0 K-II–220 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.142 L4 process XMT abort 3/1/05 K-II–221 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.143 L4 process RCV packet (page 1 of 2) ver4.0 K-II–222 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.144 L4 process RCV packet (page 2 of 2) 3/1/05 K-II–223 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.145 L4 build MSG ver4.0 K-II–224 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.146 L4 process RCVR timer 3/1/05 K-II–225 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.147 L4 process reject ver4.0 K-II–226 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.148 L4 process completion 3/1/05 K-II–227 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.149 L4 process accept ver4.0 K-II–228 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.150 L4 initialize RCVR 3/1/05 K-II–229 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.151 Consistency ver4.0 K-II–230 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.152 L4 accepted and complete 3/1/05 K-II–231 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.153 Initiate direct ver4.0 K-II–232 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.154 L4 process short RCVR timer 3/1/05 K-II–233 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.155 Assign next message number ver4.0 K-II–234 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P 8.0 LAYER 5 USER PROTOCOL 8.1 Assumptions Applicable to Session Layer State Flow Diagram • When MS, SM, and MM signals are sent, a message is created with the appropriate data, and a Send Message is signaled to Layer 4. • When messages containing MS, SM, and MM signals are received, they are decoded by the session mapper machine, and the appropriate signals are sent to the appropriate master or slave machine. • All signals contain the data elements described in Appendix C, Tables C.1 and C.2, of this specification. Signal mnemonics are those defined in Appendix C, Table C.1 of this specification. 3/1/05 K-II–235 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 8.2 Diagrams Fig. P.156 Gen_Purpose ver4.0 K-II–236 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.157 Session mapper 3/1/05 K-II–237 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.158 Process receive message ver4.0 K-II–238 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.159 Matching MS machine exists 3/1/05 K-II–239 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.160 Tfinder ver4.0 K-II–240 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.161 Master 3/1/05 K-II–241 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.162 To M_MREQ out ver4.0 K-II–242 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.163 To M_SREQ out 3/1/05 K-II–243 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.164 To M_Open ver4.0 K-II–244 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.165 To M_Closeout 3/1/05 K-II–245 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.166 Slave ver4.0 K-II–246 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.167 To S_MREQ out 3/1/05 K-II–247 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.168 MSA/MREQ out ver4.0 K-II–248 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.169 MSB/MREQ out 3/1/05 K-II–249 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.170 MSC/MREQ out ver4.0 K-II–250 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.171 PSC/MREQ out 3/1/05 K-II–251 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.172 To S_SREQ out ver4.0 K-II–252 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.173 MSA/SREQ out 3/1/05 K-II–253 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.174 MSB/SREQ out Fig. P.175 MSC/SREQ out ver4.0 K-II–254 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.176 To S_Open 3/1/05 K-II–255 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.177 MSA/Open ver4.0 K-II–256 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.178 MSB/Open 3/1/05 K-II–257 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.179 PSC/SREQ out ver4.0 K-II–258 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.180 PSD/SREQ out 3/1/05 K-II–259 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 9.0 LAYER 6 USER PROTOCOL 9.1 Layer 6 (Presentation) Protocol Assumptions • The following data for each message type (by label) is available. (This data is specified by ATCS Specification 250). • Vital or nonvital • Master-slave session required (session type restriction) • Minimum/maximum message length • Default priority (can be overridden by application in emergency) • Transmission mode • Any label for which the above items are not known by Layer 6 is considered invalid. • The following signals are transparently passed by the presentation layer (from application to session and vice versa) and are not shown in these diagrams. • All session open and close requests (regardless of channel type) • All signals related to session additions/transfers • All session open and close confirmations and denials • Send message success and failure notifications • Accept and reject call signals. Presentation layer shall notify distant end (originator) of call rejects by application. • Each application makes known to the presentation layer the list of labels it is able to accept/process. This is accomplished via vendor-defined mechanism. • Layer 6 data translations from ATCS to manufacturer defined formats (and vice versa) are not shown in these figures. • Layer 6 has visibility into Layer 5 sufficient to determine what types of sessions currently exist between what applications. 9.2 Diagrams Fig. P.181 Presentation layer state machine ver4.0 K-II–260 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.182 Process receive message 3/1/05 K-II–261 ver4.0 3/1/05 APPENDIX P AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. P.183 Process incoming call ver4.0 K-II–262 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX P Fig. P.184 Process message to send 3/1/05 K-II–263 ver4.0 3/1/05 APPENDIX Q AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 APPENDIX Q FLOW CONTROL RECOVERY PROCEDURES 1.0 INTRODUCTION Commentary: Protocol-related flow control procedures are defined by the protocols used by ATCS at Layers 2 and 4. At Layer 2, the HDLC variants provide mechanisms for devices to signal “not ready” to connected devices when there is a buffer congestion problem. At Layer 4, there is a mechanism for a receiver to request an originator of a message to delay and then resend to alleviate temporary congestion. Because the Layer 2 protocols provide an unequivocal stoppage of traffic on a link, a means must be devised to ensure that several devices do not invoke Layer 2 flow control simultaneously so as to preclude the further processing of traffic by the ground network. Each ATCS node (FEP, CC, FEP/CC, MCP, and BCP) shall implement the following flow control recovery procedures: 1.1 If the node has been in flow control at Layer 2 for 5 seconds, it will begin discarding traffic from its queues. The order of discarding shall be from highest to lowest numbered channel group. Traffic on channel groups 0 and 1 (emergency traffic) shall not be discarded. 1.2 If the procedure in paragraph 1.1 does not cause the node to exit the flow-controlled state within 10 seconds, the node shall declare a major failure and discard all traffic it has buffered (including emergency traffic). 1.3 If the procedure in paragraph 1.2 does not cause the node to exit the flow-controlled state, a second failure shall be declared and the node shall switch to a standby processor (if available) and shall perform whatever procedure is necessary to restore its buffer pool. This may include a power-up reset. ver4.0 K-II–264 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX R APPENDIX R ROUTING AND VEHICLE FOLLOWING RULES AND PROCEDURES 1.0 INTRODUCTION Commentary: Packet routing and vehicle following in a distributed, multivendor, multirailroad environment will require some level of commonality. This commonality is provided by the requirements in this appendix. 1.1 Definitions The following definitions apply to this appendix: Term Routing Node Controlling Node Virtual Node 3/1/05 Definition Any FEP, CC, or FEP/CC. These nodes are required to implement logic to direct traffic among other routing nodes to reach a base station or ground user access point. The FEP, CC, or FEP/CC to which the destination ground user is connected or the FEP/CC or CC to which a base station capable of reaching a mobile/wayside user is connected. A logical node identifier that may be assigned to a physical node within the network. Physical nodes may be assigned one or more virtual nodes. The virtual node represents a specific logical location within the network and thus simplifies the routing tables and the routing logic at all higher level routing nodes. The virtual node may be reassigned to a different physical node as the physical network topology and configuration change to accommodate ATCS application growth within a railroad. This virtual node concept allows network reconfigurations without the necessity to modify field equipment installation parameters. Commentary: ATCS specifications do not distinguish between virtual and physical nodes when using the term “node” and “nodes” except where reference is made to physical items of equipment. The system, in general, will treat all nodes as virtual, independent of their specific assignment to physical nodes within the network. This specification does not prohibit a physical node from containing virtual nodes “owned” by more than one railroad, although agreement between the railroads on necessary routing exchanges is required for this configuration. K-II–265 ver4.0 3/1/05 APPENDIX R AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 1.2 Routing node tables Each routing node shall maintain tables of the following information: Term Nodal routing Local Routing Vehicle Routing Wayside Device Routing Broadcast Routing ver4.0 Definition This table shall contain a list of other routing nodes and potential path(s) to use to get packets to those nodes. This table shall contain a list of stationary users for which the node is the controlling node and how to pass packets to those users. Packets shall be sent to the configured address via its designated FEP or FEP/CC connection and shall not be broadcast to all connected hosts. This table shall contain a list of vehicles and the identity of their controlling node. For the vehicles controlled by the local node, the table contains information on how to get packets to that vehicle (which base to use). This table must be dynamically built at run time. Commentary: This information allows each node to pass packets along to the controlling node for delivery, if the destination node is in the nodal routing table (ground user destinations) or if the vehicle is in the vehicle routing table (vehicle destinations). If the manufacture implements the tracking function in a table, then the vehicle routing table may be combined with the tracking table. In these cases, it is assumed that the vehicle/tracking table will be maintained by the handoff application. The controlling node for wayside device addresses (identifier 3 or 5) shall be determined by a railroad-defined procedure. Procedures defined for the cluster controller handoff application for mobile addresses do not apply to wayside device addresses. The routings for the various classes of broadcast addresses are defined by Table R.1. K-II–266 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX R Table R.1 Layer 3 broadcast routing Destination Address 09 0RRR00DDDD 000000DDDD 1000VVVVDD 10000000DD 1RRR0000DD Fep CC Handling Handling Internal RT clock Internal RT clock and all connected and all connected CCs and BCPs designated FEPs FEP/CC Handling Internal RT clock and all connected BCPs and designated CCs/FEPs If RRR matches, If RRR matches, If RRR matches, to internal to internal to internal application application application DDDD, else DDDD, else DDDD, else discard discard discard Internal Internal Internal application DDDD application DDDD application DDDD Discard Discard Discard All connected All connected All connected CCs and BCPs BCPs, designated designated FEPs CCs/BCPs All connected All connected All connected CCs and BCPs BCPs, designated designated FEPs CCs/BCPs 40000000DD All connected All connected CCs and BCPs designated FEPs 4RRR0000DD All connected All connected CCS and BCPs designated FEPs 4000VVVVDD Discard 3000WWWWWWDDXXX Discard 5000WWWWWWDDXXX 200000DD Forward to 2RRRNNDD Discard Discard Forward to FEP PMCP GWCP Handling Handling Internal RT clock Internal RT clock and all clients and all clients Outbound only Outbound only Outbound only Outbound only Discard Client DD if present, else discard Client DD if present and RRR match, else discard All connected Client DD if BCPs, designated present and client CCs/BCPs is TFT, else discard All connected Client DD if BCPs, designated present and client CCs/BCPs is TFT and RRR match, else discard Discard Discard Discard Discard Forward to 2RRRNNDD Outbound only Discard Discard Discard Discard Discard Discard Discard Outbound only Notes: 1. Where a node converts 000 to RRR or 00 to NN for routing it uses its own RRR or NN number for conversion and does not alter the address field of the packet. 2. Configuration of “designated” node lists is manufacturer defined. 3. If a packet is specified to be forwarded to another RR subnetwork and there is no connection to that subnetwork, it is forwarded to the shared subnetwork. If there is no connection to the shared subnetwork or to the destination railroad, then discard the packet. 4. The same packet shall never be routed back out over the connection from which the packet was received. 3/1/05 K-II–267 ver4.0 3/1/05 APPENDIX R AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 2.0 CLUSTER CONTROLLER TO CLUSTER CONTROLLER HANDOFFS This section defines the mechanism to ensure that when a train passes from the geographical area serviced by one cluster controller to the geographical area serviced by another cluster controller, end-to-end communications continue with minimum disruption. 2.1 Assumptions • The terms “cluster controller” or “CC” as used in this appendix apply equally to FEP/CCs. • The terms “cluster controller” or “CC” when used in this appendix to specify behavior not directly interacting with an MCP or BCP (e.g., sending a global search message) apply to front end processors as well. • A “subnetwork” is defined to be the ground network installed by a single railroad or the shared ground network. • Each “subnetwork” contains a directory service in node 1 of that subnetwork (directory service behavior is defined below). Each CC in the subnetwork has a communications path to the directory service (directly or indirectly through other nodes). • Each cluster controller contains a list of the other cluster controllers with which handoffs are likely to occur, whether part of the same or another subnetwork, and the nodes on this list are considered “adjacent” to the node. • Each cluster controller has a direct or indirect communications path to all adjacent cluster controllers. • There may or may not be a region of overlapping RF coverage between base stations of adjacent cluster controllers. • The “last” base station in each cluster controller's area may or may not be on the same radio channel as the adjacent base of another cluster controller. • The base stations provide calibrated signal strength indications to the cluster controllers according to the table in AAR Manual of Standards and Recommended Practices, Specification S-5830 (Formerly ATCS Specification 230). • Each CC contains a handoff application that manages handoffs among cluster controllers and maintains vehicle tracking information. • CCs do not execute CC handoff procedures in order to execute handoffs between base stations within a single CC's span of control. • A cluster controller initiates an MCP reset whenever the CC enters the IN_CONTROL state (defined below), except when the transition to that state was triggered by receipt of a DEFINE_CAPABILITIES_MSG (message number 17.3.8). • CCs recall the time and signal strength reading from the most recent PULL_CONTROL_MSG that has been sent for any vehicle they are controlling. • Each CC contains a table of the correlation of wayside client addresses to wayside MCP addresses. This allows the CC to reset the entire set of wayside MCP state machines with a single MCP reset message. 2.2 CC Handoff Mechanism 2.2.1 The handoff mechanism resides in three applications: a handoff application in each CC (“GHNO”), a subnetwork (local) directory service in each railroad's subnetwork (“GDIR”), and a shared (global) directory service in the shared subnetwork (“GDIR”). These applications cooperate by exchanging messages over the ground network trunk lines as shown in Fig. R.1. ver4.0 K-II–268 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX R 2.2.2 The messages that are used by the applications are defined below. Messages are defined in ATCS Specification 250. The events represent a series of shortened names that are used elsewhere in this document in defining the behavior of the applications. Table R.2 Messages used by GHNO, GDIR, and global applications 3/1/05 Message Number Message Name Event 17.3.4 17.3.5 17.3.6 106.4.13 106.4.14 106.4.16 106.4.17 106.4.18 106.4.19 106.4.20 106.4.21 106.4.22 106.4.23 106.4.24 106.4.25 RESET_MCP_MSG REQUEST_MCP_RESET_MSG DEFINE_CAPABILITIES_MSG GLOBAL_SEARCH_MSG CONTACT_NOTICE_MSG DENY_CONTROL_MSG PULL_CONTROL_MSG PUSH_CONTROL_MSG REQ_DIRECTORY_ASSIST_MSG DIRECTORY_ASSIST_MSG REQ_SHARED_ASSIST_MSG SHARED_ASSIST_MSG GLOBAL_NOTICE_MSG NO_CONTACT_MSG CC_CTL_LIST_MSG RESET_MCP RCV_RES_RQ RCV_DEF_CP RCV_SEARCH RCV_CONTACT RCV_DENIED RCV_PULL RCV_PUSH RCV_REQ_DIR_ASSIST RCV_ASSIST RCV_REQ_SHR_ASSIST RCV_SHARED RCV_NOTICE RCV_NO_CONTACT RCV_CTL_LIST K-II–269 ver4.0 3/1/05 APPENDIX R AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. R.1 Cluster controller handoff dataflow ver4.0 K-II–270 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX R 2.2.3 In addition to the above events, the events RCV_OUT and RCV_IN are defined to mean the arrival of outbound and inbound packets to/from the vehicle, respectively, at the handoff application. Also, the event RCV_TRUNK_CONTACT is used by routing to signal the handoff application that trunk contact with (to/from) a vehicle in the tracking table has occurred. 2.3 CC Handoff Application 2.3.1 The cluster controller handoff application (GHNO) is responsible for maintaining vehicle tracking information and managing handoffs among cluster controllers. The processing logic for the CC handoff application, including its interface with the directory applications (GDIRs) and RF protocol (ARQ logic), is defined in Appendix P, paragraph 5.0. 2.3.2 Commentary 2.3.2.1 Table R.10 is a state table that provides a high-level description of the handoff application operation in response to certain events. This table is offered as additional explanatory information (commentary), and any discrepancies between the table and Appendix P, paragraph 5.0 shall be governed by Appendix P, paragraph 5.0. 2.3.2.2 The handoff application has seven states. The state of the application defines the relationship of that application to a specific vehicle. The states for the handoff application are as follows: Table R.3 Handoff application states CTL_UNKNOWN The application does not know what CC has control of the vehicle and is not actively attempting to find out. CTL_KNOWN The application knows what node controls the vehicle, but it is not the node on which the application is running. CTL_DENIED The application knows what node controls the vehicle; it is not the node on which the application is running, and the controlling node has sent a DENY_CONTROL_MSG inhibiting the application from sending CONTACT_NOTICE_MSGs. CONTACT_SENT The application has sent a CONTACT_NOTICE_MSG and is awaiting a response before assuming control of the vehicle. IN_CONTROL The application is running on the same node that controls the vehicle. DIR_ASSIST The application has sent a REQ_DIRECTORY_ASSIST_MSG and is awaiting a response. GLOBAL_SEARCH The application has sent out GLOBAL_SEARCH_MSGs and is awaiting a response. 3/1/05 K-II–271 ver4.0 3/1/05 APPENDIX R AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 2.3.2.3 The handoff application uses timers and conditions to aid in controlling behavior. The timer actions are Reset (R), Start (S), and Cancel (C) and are signified by the first letter of the action name. Each timer has a two-letter abbreviation (e.g., PURGE_TIMER is abbreviated PR). Events signifying the expiration of a timer are denoted by the timer's two-letter identifier followed by “_EXP.” The timers used by the handoff application are as follows: Table R.4 Handoff application timers PURGE_TIMER (PR) DIRECT_TIMER (DI) DENIED_TIMER (DN) SEARCH_TIMER (SR) CONTACT_TIMER (CT) VEHICLE_ CONTACT_ TIMER (VT) Used by the handoff application to determine when to purge a vehicle from its table. (Recommended duration is 1 hour.) Used by the handoff application to determine when to give up on receiving a response to a directory assistance request. (Recommended duration is 10 seconds.) Used by the handoff application to determine when it is no longer inhibited from sending contact notices for a given vehicle. (Duration is determined by the message denying control.) Used by the handoff application to determine when to give up on a global search request. (Recommended duration is 30 seconds.) Used by the handoff application to determine when to give up on receiving a response to a contact notice, and to assume control of a vehicle. (Recommended duration is 8 seconds.) Used by the handoff application to reset the VEHICLE_CONTACT_FLAG (VCTF defined below) if the vehicle has not been heard from (RF packet received from) within the last 10 minutes. 2.3.2.4 The condition names are four- or five-letter identifiers. A plus sign in front of a condition name indicates the condition is true; a minus sign in front of a condition name indicates the condition is false. The following conditions are used by the handoff application: Table R.5 Handoff application conditions DBIT TOME KEEP LATE SAME CTLK VCTF SIGA SSI10 ver4.0 Used by the handoff application to signify that the D-bit was set and that the originator identifier was other than 1, 3, 4, or 5 in an outbound packet. This controls whether the application causes an access barred service signal (AB_SVC_SIG) to be generated under some circumstances. Used by the handoff application to signify that a control message (PUSH, PULL, DIRECTORY_ASSIST, or SHARED_ASSIST) indicates control being passed to the receiving node. Used by the handoff application to signify whether it decided to KEEP control of a vehicle even though it received a contact notice for that vehicle from another node. Used by the handoff application to signify that the PULL_CONTROL_MSG or GLOBAL_NOTICE_MSG just received had a later time than the last PULL_CONTROL_MSG sent. If the two times are identical, then LATE means that the message has a higher signal strength reading than the last PULL_CONTROL_MSG sent. If the signal strengths are also identical, LATE means that the node that sent the message had a higher numbered network address than the receiver (digit zero is encoded as a hexadecimal A and is >9). Used by the handoff application to signify that a node originating a message is the same as the node previously identified as being in contact with or in control of a particular vehicle. Used by the handoff application to signify that a controlling node has been identified for a particular vehicle (while in the CONTACT_SENT state). Used by the handoff application to determine if the vehicle has been heard from (RF packet received from) within the last 10 minutes. Used by the handoff application to signify that the signal strength of a received packet is greater than the threshold set by the controlling node in denying control of the vehicle. Used by the handoff application to signify that the vehicle signal strength indicator for a vehicle in the CONTACT_SENT state has increased by at least 10 SSI. K-II–272 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX R 2.3.2.5 The destinations to which the handoff application may send a message are abbreviated as follows: Table R.6 Handoff application destinations AN CN ON LD SD SN Adjacent nodes Controlling node Originating node Local directory service Shared directory service Entire subnetwork (all nodes) Note that if an address is included in two of the destinations to which a message is to be sent, the handoff application will send only one copy of the message. 2.3.2.6 The columns CTL CHG, FWD QUE, and DIS QUE indicate that the application (in conjunction with the RF protocol entity) should (if an asterisk is present) update the controlling node ID, forward the vehicle's queue of outbound traffic to the new controlling node, or discard the vehicle's queue of outbound traffic (sending not obtainable service signals to the originators of packets with the DBIT set). The column labelled RESET MCP indicates that the application should request that the vehicle's MCP be reset. 2.4 Directory Applications 2.4.1 The processing logic for the subnetwork directory service application (local GDIR) and the shared directory service application (global GDIR) are defined in Tables R-3 and R-4 respectively. The directory applications have the following three states in relationship to individual vehicles: Table R.7 Directory application states CTL_UNKNOWN CONTACT_RCVD CTL_KNOWN The application does not know what CC has control of the vehicle and is not actively attempting to find out. The application has not received a definitive indication of the controlling node's identity, but is assuming the node based on a CONTACT_NOTICE_MSG. The application knows the identity of the controlling node for the vehicle. 2.4.2 The directory service applications use a PURGE_TIMER (PR) (Duration is 1 hour) to determine when to purge a vehicle from their tables. The timer actions are Reset (R), Start (S), and Cancel (C) and are signified by the first letter of the action name. The expiration of the timer is denoted by the timer's two letter identifier followed by “_EXP.” 2.4.3 The directory service applications also use two conditions to control behavior. A plus sign in front of a condition name indicates the condition is true, a minus sign in front of a condition name indicates the condition is false: Table R.8 Directory service application conditions SAME HOME 3/1/05 Used by the directory applications to signify that a node originating a message is the same as the node previously identified as being in contact with or in control of a particular vehicle. Used by the directory applications to signify that a vehicle, its controlling node, and any other node involved in a transaction, all belong to the same railroad (subnetwork). K-II–273 ver4.0 3/1/05 APPENDIX R AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 2.4.4 The destinations to which a directory application may send a message are as follows: Table R.9 Directory application destinations CN ON SN CD OD HD SD PA CF OF HF Controlling Node Originating Node Entire Subnetwork (all nodes) Controlling Node's Directory Service Originating Node's Directory Service Vehicle's Home Subnetwork Directory Service Shared Directory Service All nodes necessary to form a path between requesting and controlling node within a subnetwork Flood routing to the controlling node's subnetwork Flood routing of the originator's subnetwork Flood routing of the vehicle's home subnetwork Note that if an address is included in two of the destinations to which a message is to be sent, the application shall send only one copy of the message. ver4.0 K-II–274 3/1/05 3/1/05 APPENDIX R Table R.10 ATCS CC handoff application state table (commentary) S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 K-II–275 ver4.0 3/1/05 S-5800 Table R.10 ATCS CC handoff application state table (commentary) APPENDIX R AAR Manual of Standards and Recommended Practices Railway Electronics ver4.0 K-II–276 3/1/05 3/1/05 APPENDIX R Table R.10 ATCS CC handoff application state table (commentary) S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 K-II–277 ver4.0 3/1/05 S-5800 Table R.10 ATCS CC handoff application state table (commentary) APPENDIX R AAR Manual of Standards and Recommended Practices Railway Electronics ver4.0 K-II–278 3/1/05 3/1/05 APPENDIX R Table R.10 ATCS CC handoff application state table (commentary) S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 K-II–279 ver4.0 3/1/05 S-5800 Table R.10 ATCS CC handoff application state table (commentary) APPENDIX R AAR Manual of Standards and Recommended Practices Railway Electronics ver4.0 K-II–280 3/1/05 3/1/05 APPENDIX R Table R.10 ATCS CC handoff application state table (commentary) S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 K-II–281 ver4.0 3/1/05 S-5800 Table R.10 ATCS CC handoff application state table (commentary) APPENDIX R AAR Manual of Standards and Recommended Practices Railway Electronics ver4.0 K-II–282 3/1/05 3/1/05 APPENDIX R Table R.10 ATCS CC handoff application state table (commentary) S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 K-II–283 ver4.0 3/1/05 S-5800 Table R.10 ATCS CC handoff application state table (commentary) APPENDIX R AAR Manual of Standards and Recommended Practices Railway Electronics ver4.0 K-II–284 3/1/05 3/1/05 APPENDIX R Table R.10 ATCS CC handoff application state table (commentary) S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 K-II–285 ver4.0 3/1/05 S-5800 Table R.10 ATCS CC handoff application state table (commentary) APPENDIX R AAR Manual of Standards and Recommended Practices Railway Electronics ver4.0 K-II–286 3/1/05 3/1/05 APPENDIX R Table R.10 ATCS CC handoff application state table (commentary) S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 K-II–287 ver4.0 3/1/05 S-5800 Table R.10 ATCS CC handoff application state table (commentary) APPENDIX R AAR Manual of Standards and Recommended Practices Railway Electronics ver4.0 K-II–288 3/1/05 3/1/05 APPENDIX R Table R.11 ATCS subnetwork directory service application state table S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 K-II–289 ver4.0 3/1/05 S-5800 Table R.11 ATCS subnetwork directory service application state table APPENDIX R AAR Manual of Standards and Recommended Practices Railway Electronics ver4.0 K-II–290 3/1/05 3/1/05 APPENDIX R Table R.11 ATCS subnetwork directory service application state table S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 K-II–291 ver4.0 3/1/05 S-5800 Table R.11 ATCS subnetwork directory service application state table APPENDIX R AAR Manual of Standards and Recommended Practices Railway Electronics ver4.0 K-II–292 3/1/05 3/1/05 APPENDIX R Table R.11 ATCS subnetwork directory service application state table S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 K-II–293 ver4.0 3/1/05 S-5800 Table R.11 ATCS subnetwork directory service application state table APPENDIX R AAR Manual of Standards and Recommended Practices Railway Electronics ver4.0 K-II–294 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX S APPENDIX S COMMENTARY ON EMERGENCY TRAFFIC HANDLING RULES AND PROCEDURES 1.0 INTRODUCTION Note: All of the requirements in this appendix are addressed elsewhere in this specification. The ATCS Data System shall provide the following features for emergency traffic: • For wayside/mobile declared emergency: Once the channel is accessed by the mobile/wayside unit, the unit alternately sends an emergency broadcast message (Mode 0 as defined in Appendix D) to all locomotives and track forces, and an emergency notification message to the controlling dispatch system. Each message is repeated 20 times. The base station broadcasts one message to the track forces and locomotives and forwards the other message to the dispatch center. • For an emergency declared by a dispatch center, an expedited mechanism exists to send a message to a single vehicle and obtain an end-to-end acknowledgment (Mode 3 as defined in Appendix D). Another mode exists for notifying multiple vehicles and receiving end-to-end acknowledgments from each one (Mode 4 as defined in Appendix D). All locomotives may be notified in broadcast Mode 0 (in Mode 0 as defined in Appendix D) without acknowledgments. • Emergency traffic always goes ahead of all other non-emergency traffic in queues in the ground network. • If a ground network node enters flow control and cannot exit flow control, non-emergency traffic is discarded in an attempt to force an exit that allows emergency traffic processing to continue. Only as a last resort is emergency traffic discarded to facilitate a nodal recovery. • Emergency traffic is identified by the use of channel group 0 or 1. 3/1/05 K-II–295 ver4.0 3/1/05 APPENDIX T AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 APPENDIX T ATCS NETWORK ADDRESS ASSIGNMENTS—LAYER 3 ADDRESSING 1.0 ADDRESS FORMAT The Network Address (Layer 3) field of the packet header shall be packed (2 digits per octet) binary coded decimal (BCD). Digit 0 shall be encoded as A hexadecimal. The first digit of each address shall identify the type of the addressed process according to the definitions given in the following paragraphs. 2.0 ADDRESS IDENTIFIER LIST 0 1 2 3 4 5 6 7 8–9 Network software and services Locomotives Ground host processes (dispatch, maintenance) Wayside devices—wireline connected (switches, signals, base stations) Mobile addresses (work crews, hi-rails) (Important Note: Mobiles other than locomotives shall accept traffic to the locomotive broadcast address). Wayside devices—RF connected Trucks and personal portable terminals Wayside devices—Hierarchically connected Reserved for expansion 3.0 NODE NUMBERING Allocation of network node numbers is not a part of the ATCS specifications. In Appendix R, the description of “Virtual Nodes” contains general guidelines for the issuance of network node numbers. 4.0 NETWORK/HOST ADDRESS STRUCTURE 4.1 Ground Network Nodes and Host Computers shall use address identifiers 0 and 2, respectively. These addresses are 10 digits long and are interpreted as follows: I ! Address Type Identifier Railroad Number Network Node Number Addressed Device Identifier ver4.0 K-II–296 RRR ! ! NN ! ! ! DDDD ! ! ! ! 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX T 4.2 The following groups of network software and service addresses shall be defined as indicated (RRRNN is the node number of a FEP, CC, or FEP/CC): 0RRRNN0000 0RRRNN9999 0RRRNN0001 0RRRNN0002 0RRRNN0003 0RRRNN0004 0RRR010005 0RRRNN0006-0RRRNN0199 0RRRNN0200-0RRRNN0599 0RRRNN0600-0RRRNN0999 0RRRNN1000-0RRRNN1999 0RRRNN2000-0RRRNN2999 0RRRNN3000-0RRRNN9800 0RRRNN9800-0RRRNN9899 0RRRNN9900-0RRRNN9998 NULL Address NULL Address GINT (Address table initialization) GTIM (Address to send Stop Traffic for Time Mark command) GHNO (CC to CC handoff application) GHEL (Health monitor) GDIR (Directory service for subnetwork RRR) Reserved Manufacturer-specific nodal configuration and control Manufacturer-specific value added services Addresses used to implement protocol adaptors Used to identify communications lines. Although communications lines are not addressable, an identifier is needed to represent them in the event of failure. As a result of this technique of assigning identifiers, each end of a trunk line between two nodes has an address. Reserved Manufacturer-specific interactive processes (nodal operator message terminal(s) and monitoring device(s)). Reserved Note: When an MCP receives a packet with a NULL destination address, it should reset its contact timer and then discard the packet. When a CC, FEP, or FEP/CC receives a packet with a NULL address, it should treat the packet normally (i.e., update vehicle location and sequence numbers, generate acknowledgements, etc.) prior to discarding it. 4.3 The following groups of ground host addresses shall be defined as indicated: 2RRRNN0000 and 2RRRNN0002-2RRRNN0999 2RRRNN0001 2RRRNN1000-2RRRNN1999 2RRRNN2000-2RRRNN2999 2RRRNN3000-2RRRNN3999 2RRRNN4000-2RRRNN4999 2RRRNN5000-2RRRNN6999 2RRRNN7000-2RRRNN7999 2RRRNN8000-2RRRNN8999 2RRRNN9000-2RRRNN9999 Reserved System clock (DTIM) Car and motive power management computers/terminals Freight/passenger computers/terminals Maintenance computers/terminals Yard computers/terminals Dispatch computers Other (misc) terminals/computers Dispatch code protocol converters Reserved The 2000 Dispatch System addresses are further defined as shown: 2RRRNN5000-2RRRNN5019 2RRRNN5020-2RRRNN6999 3/1/05 Special functions (RR defined) 132 dispatch positions of 15 addresses each K-II–297 ver4.0 3/1/05 APPENDIX T AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Thus addresses 2RRRNN5020-2RRRNN5034 2RRRNN5035-2RRRNN5049 . . 2RRRNN6985-2RRRNN6999 Dispatch Position 1 Dispatch Position 2 Dispatch Position 132 4.4 Each dispatch position consists of 15 addresses defined as follows: Address # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Entity DMAH DDAT DLOC DEMH DWAY DMMI DHEL DTRK DPAC Railway Defined Railway Defined Railway Defined Railway Defined Reserved Reserved Dispatch Position 1 Example 2RRRNN5020 2RRRNN5021 2RRRNN5022 2RRRNN5023 2RRRNN5024 2RRRNN5025 2RRRNN5026 2RRRNN5027 2RRRNN5028 2RRRNN5029 2RRRNN5030 2RRRNN5031 2RRRNN5032 2RRRNN5033 2RRRNN5034 Dispatch Position 132 Example 2RRRNN6985 2RRRNN6986 2RRRNN6987 2RRRNN6988 2RRRNN6989 2RRRNN6990 2RRRNN6991 2RRRNN6992 2RRRNN6993 2RRRNN6994 2RRRNN6995 2RRRNN6996 2RRRNN6997 2RRRNN6998 2RRRNN6999 5.0 WAYSIDE ADDRESS STRUCTURE 5.1 Wayside devices, wayside MCPs, BCPs, and relays use address identifiers 3 (wire connected to a CC or FEP), 5 (RF connected to a CC or FEP or out of coverage), or 7 (hierarchically connected). 5.2 Types 3 and 5 addresses are 15 digits long and are interpreted as follows: Address Type Identifier Railroad Number WIU/Control Point ID Device Number Object Number I ! RRR ! ! WWWWWW ! ! ! DD ! ! ! ! XXX ! ! ! ! ! 5.3 Within a field site, a separate set of Layer 3 state machines in the MCP shall be allocated for each unique 12-digit address prefix (IRRRWWWWWWDD). Objects with identical device numbers within a site share the same set of Layer 3 state machines. ver4.0 K-II–298 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX T 5.4 The following categorization of wayside device addresses shall be defined as indicated (an identifier of 3 indicates a wireline connected wayside device; an identifier of 5 indicates an RF connected wayside device). Within a WIU number, the device number shall be assigned as follows: 00 01 02 03 04 05 06–31 32–41 42–51 52–61 62–81 82–99 Broadcast MCP or BCP (GWCP/GBCP) WEMH WHEL Event recorder (WREC) Local control box/man machine interface (WMMI) Control points (WCTL) Highway crossings (WHWY) Noncontrollable devices and train defect detectors (WNCD/WTDD) Code line converters (FWPC) Other railroad/manufacturer-defined devices, including AEI Reserved for future assignment Within device numbers, the object number shall be assigned as follows: 000 001 002 003–010 011–199 200–299 300–399 400–449 450–499 500–599 600–699 700–999 Broadcast Device manager Diagnostic port Reserved Track circuits Switches Signals and/or indicators Wheel counters Other sensors Rail break detectors Railroad/manufacturer defined Reserved for future assignment 5.5 For communication to a WIU, other ATCS components shall address messages to the device manager (object number 001) of the corresponding device number (digits 11–12) of the address. For example, an NX setting request for a control point with device number 07 will be addressed to IRRRWWWWWW07001. The object numbers shall be assigned to the individual objects that are contained within a device. Mapping to link layer addresses is railroad/site specific. 5.6 Hierarchically connected wayside devices, wayside MCPs, BCPs, and relays use address identifier 7. These addresses are 14 digits long and are interpreted as follows: Address Type Identifier Railroad Number Routing Region Code Location Code Device Number Object Number 3/1/05 I ! RRR ! ! K-II–299 LLL ! ! ! GGG ! ! ! ! DD ! ! ! ! ! XX ! ! ! ! ! ! ver4.0 3/1/05 APPENDIX T AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 5.7 Within a field site, a separate set of Layer 3 state machines in the MCP shall be allocated for each unique 12-digit address prefix (IRRRLLLGGGDD). Objects with identical device numbers within a site share the same set of Layer 3 state machines. 5.8 The following categorization of hierarchical wayside device addresses shall be defined as indicated. Within a location within a region, the device number shall be assigned as follows: 00 01 02–81 82–99 Broadcast MCP or BCP Other railroad/manufacturer-defined devices Reserved for future assignment Within device numbers, the object number shall be assigned as follows: 00 01 02 03–69 70–99 Broadcast Device manager Diagnostic port Railroad/manufacturer defined Reserved for future assignment 5.9 For communication to a WIU, other ATCS components shall address messages to the device manager (object number 01) of the corresponding device number (digits 11–12) of the address. For example, an NX setting request for a control point with device number 07 will be addressed to 7RRRLLLGGG0701. The object numbers shall be assigned to the individual objects that are contained within a device. Mapping to link layer addresses is railroad/site specific. 6.0 MOBILE ADDRESS STRUCTURE Mobile addresses shall use address identifiers 1 and 4. These addresses are 10 digits long and are interpreted as follows: I ! Address Type Identifier Railroad Number Network Node Number Addressed Device Identifier RRR ! ! VVVV ! ! ! DD ! ! ! ! 7.0 RESERVED ADDRESSES Railroad # 000 All call # 050 Reserved for future use # 340 Shared network # 620 Testing & field evaluation Locomotive #0000 All call Work Crew #0000 All call Network Node # 00 Local node Address 09 Broadcast to all ATCS device clocks. Note: “Wildcard” vehicle address is 10000000DD. ver4.0 K-II–300 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 S-5800 APPENDIX T 7.1 Devices on board locomotives shall also support use of a three-digit address structure when communicating with other devices on board the same locomotive. These addresses shall be interpreted as follows: I ! Address Type Identifier Address Device Identifier DD ! ! 7.2 The Addressed Device Identifier shall be assigned according to the following list. When applied to a Layer 3 (network) address, the values in this list represent decimal values to be packed (two digits per octet) BCD, with 0 encoded as A hexadecimal. When applied to a Layer 2 (link layer) address, the values in this list represent hexadecimal values. Certain values do not apply to Layer 3 addresses as noted. Address 01 03 05 07 09 11 13 15 17 19 21 23 25 27 29 30–40 and even numbers 42–58 41 43 45 47 49 51 53 55 57 59 61 63 65 3/1/05 Device or Entity PMCP (mobile communications package) LHEL/THEL (health monitor) LMAH/TMAH (authority manager) LDAT/TDAT (database manager) LLOC/TLOC (location system) LEMH/TEMH (emergency handler) LWAY/TWAY (wayside device manager) Reserved LPAC (pacing manager) Reserved LTRK/TTRK (track condition handler) Ground network (link layer address only) Emergency broadcast (link layer address only) RF user to RF user (link layer address only) Reserved Nonstandard manufacturer-defined entity PMMI (ATCS display) PARC Alerter/recorder (control) PARS (alerter/recorder store—data to this address is stored) PPTR (printer) PINT (interrogator) PSLS (secondary location system) PAXG (axle generator interface) PSEN (sensor control unit) PEID (engineman ID unit) PAUX (auxiliary terminal) PDSP (ATCS display and LOD) PXID (locomotive identification unit) PETU (end-of-train unit) K-II–301 ver4.0 APPENDIX T AAR Manual of Standards and Recommended Practices Railway Electronics Address S-5800 Device or Entity 67 69 71 73 75 77 79 81 PLOD (locomotive operating display) PAEI (automatic equipment identification unit) PBRK (brake interface module or intelligent brake controller) PCAB (cab signaling unit) PCRP (core/auxiliary processor) PSSC (slow speed control unit) PFLG (flange lubricator) PVRD (voice radio) 83 85 PDEV (device for download/upload to/from locomotive devices) PITC (Intra-train communication devices/devices that communicate to or from a lead locomotive and any units in the consist) PFTM (fuel tank monitor) Reserved PALL (all onboard entities) PALL (link layer address only) 87 89–97 99 FF 7.3 Even-numbered mobile addresses 30–58 (decimal), inclusive, are designated for manufacturer-defined entities. All other even-numbered mobile addresses are reserved. Commentary: Care should be exercised when using even-numbered link addresses to avoid conflicts with the ISO-defined HDLC extended addressing. 8.0 TRUCK AND PERSONAL PORTABLE TERMINAL ADDRESS STRUCTURE 8.1 Trucks and personal portable terminals shall use address identifier 6. These addresses are 14 digits long and are interpreted as follows: I ! Address Type Identifier Railroad Number Truck or Terminal Number Addressed Device Identifier RRR ! ! VVVVVVVV ! ! ! DD ! ! ! ! 8.2 The AAR and the RAC will coordinate the unique assignments of three-digit railroad numbers. The assignment of specific addresses to specific applications within the ranges defined above is an installation and configuration task. The assignment of FEP, CC, and FEP/CC node numbers within a railroad number is railway defined. ver4.0 K-II–302 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX U APPENDIX U ATCS RADIO LINK ADDRESS ASSIGNMENTS 1.0 ADDRESS FORMAT The Address Type field of Layer 2 RF link frames shall employ the following hexadecimal assignments (address type is indicative of destination, not source): 0 1 3 4 5 6 23 25 27 FF 3/1/05 No call Locomotives Not used Non-locomotive vehicles Wayside devices (RF connected) Trucks and personal portable terminals Inbound (to ground network) Emergency broadcast Direct RF–RF user Non-emergency broadcast K-II–303 ver4.0 3/1/05 APPENDIX V AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 APPENDIX V XID PROCESS 1.0 INTRODUCTION TO THE XID PROCESS 1.1 The XID process provides a mechanism for ATCS components at either end of an HDLC balanced data link connection to identify themselves to the component at the opposite end of the link. There are five cases where this is required in ATCS: • Trunk links—between an FEP and CC, between two FEPs, between two CCs, between an FEP/CC and an FEP, or between two FEP/CCs. • WIU—MCP • OBC—MCP • Track forces terminal (TFT)—MCP • Portable terminal (PT)—MCP 1.2 Trunk Links Each end shall identify its railroad number and node number to its partner. The node with the highest node number (RRRNN) shall use link address 03, and the other node shall use link address 01. Note: When node numbers are compared, digit 0 is encoded as A and thus is treated as the highest valued digit. Subject to prior configuration at both ends of the link, trunk lines may omit XID and use a prearranged link level address. 1.3 Vehicles The MCP shall expect to be notified of the vehicle type (locomotive or non-locomotive), the railroad number, and the vehicle number, while the MCP shall identify the link addresses it supports to the client.a/ 1.4 Wayside Interface Unit (WIU) The client shall identify the network addresses of the clients and of the MCP, and the MCP shall respond with its configured network address and the list of link addresses it supports. The client shall include the address of its health monitor (WHEL) as the first of its Layer 3 addresses. Note: The purpose of the MCP always including its network address to its client is to allow the MCP to notify the client (by sending a null address of all zeroes) that it has not been initialized. 1.5 XID Protocol The receipt of a valid XID frame over one of these links always supersedes all previously received XID frames (note that this implies that an XID frame may add or delete clients from an MCP). When an XID exchange on one link causes addition or deletion of entities with which a client may communicate, the XID process shall be initiated on all other links available to that client. 1.6 XID Format The format for the XID frames is shown in Figs. V.1–V.6. 1.7 MCP Uninitilaized When uninitialized, the MCP shall set the number of link addresses it supports to zero and send its XID frame with an MCP network address of all zeroes. 1.8 XID Process—Multiple Ports The XID process between any client with more than one port and its peripherals shall be the same as for the MCP. The client shall perform an XID exchange with all devices attached to it. The OBC shall emulate an initialized MCP to these devices. Note that it is always the MCP address (device a/ ver4.0 The term “client” refers to an OBC, a track forces terminal, or a portable terminal, whichever the MCP in question is currently supporting. K-II–304 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX V 01) that is used to identify the vehicle to onboard devices. The client shall be capable of detecting new physical or logical connections or disconnections of peripheral entities and of performing XID exchanges at any time during its operations. 1.9 MCP to WIU Addressing When the MCP is attached to a WIU, all traffic that the MCP receives on the RF, directed to any of the WIU network addresses, is sent to the WIU using its single link layer address. 1.10 MCP Attached to a Vehicle When the MCP is attached to a vehicle, there is a one-to-one correspondence between the last two BCD digits of the network address of an attached entity and its link layer address. Thus, only the link addresses are exchanged during XID. 1.11 Layer 2 XID Command Frames Any Layer 2 entity that sends XID frames may send an XID command frame in any state (information transfer, disconnected, timer recovery). Any Layer 2 entity that receives a valid XID command frame shall respond with an XID response frame. There is no limit on the number of attempts to pass an XID command frame before receiving a response. XID frames shall not be transmitted at an interval of less than 1.5 seconds. XID command frames shall use link address FFH. XID response frames shall use the lowest numbered link address serviced by the sending device. 1.12 Layer 2 XID Invalid Link Address If a Layer 2 entity receives an XID frame that indicates that the sender had an invalid link address, the Layer 2 entity shall abort the connection to the sender and inhibit connection establishment until a valid XID is received. Link addresses are considered invalid under the following circumstances: • The link address has an even number. • The sender attempts to use a link address (other than a multicast address) belonging to the receiver. • The sender attempts to use a link address (other than a multicast address) belonging to a Layer 2 entity or another (onboard vehicle) active physical connection. 1.13 Locomotive Identification Unit The locomotive identification unit shall be designed to respond with the frame described by Fig. V.6 upon receiving one of the frames described by Figs. V.4 or V.5 or shall periodically send the frame described by Fig. V.6 at an interval in the range of 2–60 seconds (manufacturer defined). In all XID command frames, the P-bit shall be set to zero. In all XID response frames, the F-bit shall be set. Commentary: The locomotive ID unit may be designed without the capability to establish a Layer 2 (or higher layer) connection, beyond the exchange of XID frames. Commentary: Ancillary onboard devices (e.g., data recorders, sensor control units) may subset the ATCS upper layer protocols. In particular, vital message CRC validation and session setup should not be required for messages that the data recorder receives for recording only. Adequate measures must be taken to ensure that these devices cannot affect vital processing (e.g., by reintroducing a canceled authority into the OBC). 1.14 Version Compatibility To maintain compatibility with previous versions of this specification, XID response frames shall have the F-bit set to match the P-bit in the eliciting XID command frame. 3/1/05 K-II–305 ver4.0 3/1/05 APPENDIX V AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 STARTING FLAG LINK ADDRESS (FFH) LINK CONTROL (XID) 0 R1 R2 R3 N1 N2 0 0 0 0 0 0 0 0 LENGTH = 0AH CRC BYTE 1 CRC BYTE 2 ENDING FLAG R1, R2, R3 = railroad number of sender (digits 1, 2, and 3) N1, N2 = node number of sender (digits 1 and 2) Frame is shown one octet per line (ignoring HDLC bit stuffing). Four 0 bytes are included for consistency with network address structure in ATCS Specification 250. Fig. V.1 Trunk XID frame ver4.0 K-II–306 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX V FLAG LINK ADDRESS (FFH) LINK CONTROL (XID) MCP NETWORK ADDRESS 8 OCTETS WIU LINK ADDRESS (03H) NUMBER OF WIU ADDRESSES (1–32) [N] WIU ADDRESS #1 8 OCTETS WIU ADDRESS #2 8 OCTETS * * * WIU ADDRESS N 8 OCTETS CRC BYTE 1 CRC BYTE 2 FLAG Fig. V.2 WIU to MCP XID frame 3/1/05 K-II–307 ver4.0 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 APPENDIX V S-5800 FLAG LINK ADDRESS (FFH) LINK CONTROL (XID) MCP NETWORK ADDRESSa/ 8 OCTETS NUMBER OF MCP ADDRESSES (1–99) [N] MCP ADDRESS 1 MCP ADDRESS 2 MCP ADDRESS 3 * * * MCP ADDRESS N CRC BYTE 1 CRC BYTE 2 FLAG a/ MCP network address in format defined by ATCS Specification 250. Address is all 0s if MCP is not yet initialized. Fig. V.3 MCP to WIU XID frame ver4.0 K-II–308 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 S-5800 APPENDIX V FLAG LINK ADDRESS (FFH) LINK CONTROL (XID) MCP NETWORK ADDRESSa/ 8 OCTETS NUMBER OF LINK ADDRESSES (1–99) [N] OBC [TFT] [PT] LINK ADDRESS 1 OBC [TFT] [PT] LINK ADDRESS 2 OBC [TFT] [PT] LINK ADDRESS 3 * * * OBC [TFT] [PT] LINK ADDRESS N CRC BYTE 1 CRC BYTE 2 FLAG a/ IRRRVVVV01 encoded as defined in ATCS Specification 250 (object #20) Fig. V.4 OBC to MCP XID frame (Track Forces Terminal [TFT] to MCP XID frame; Portable Terminal [PT] to MCP XID frame) 3/1/05 K-II–309 ver4.0 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 APPENDIX V S-5800 FLAG LINK ADDRESS (FFH) LINK CONTROL (XID) MCP NETWORK ADDRESSa/ 8 OCTETS NUMBER OF MCP ADDRESSES (1–99) [N] MCP ADDRESS 1 MCP ADDRESS 2 MCP ADDRESS 3 * * * MCP ADDRESS N CRC BYTE 1 CRC BYTE 2 FLAG a/ MCP network address in format defined by ATCS Specification 250 (object #20) Fig. V.5 MCP to OBC XID frame (MCP to Track Forces Terminal [TFT] XID frame; MCP to Portable Terminal [PT] XID frame) ver4.0 K-II–310 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 S-5800 APPENDIX V FLAG LINK ADDRESS (FFH) LINK CONTROL (XID) MCP NETWORK ADDRESSa/ 8 OCTETS NUMBER OF LINK ADDRESSES (1) LOCO ID UNIT LINK ADDRESSES (63) CRC BYTE 1 CRC BYTE 2 FLAG a/ MCP network address in format defined by ATCS Specification 250 (object #20) Note: On Level 20 trains and on track forces terminals, if the MCP has multiple ports, the ID unit may be connected to a spare MCP port in addition to or in lieu of the smart terminal. Fig. V.6 Locomotive ID unit OBXID frame 3/1/05 K-II–311 ver4.0 3/1/05 APPENDIX W AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 APPENDIX W RADIO NETWORK FORWARD ERROR CORRECTING CODE SPECIFICATION 1.0 INTRODUCTION 1.1 This appendix defines procedures for creating an 80-bit block from 60 bits of user data. 1.2 The decoding algorithm for these blocks is manufacturer specific but must be sufficiently robust to correct two symbol errors per block. 1.3 Specification of an Offset RS (16, 12) Code on 5-Bit Symbols, i.e., Over GF(32) The specification is in five parts. These are as follows: 1. (paragraph 2.0) Specification of how 60 bits of user data are formatted into twelve 5-bit symbols and have four additional symbols appended to give an RS (16, 12) code word. This section assumes that a division polynomial and the field arithmetic have been defined. 2. (paragraph 3.0) Specification of the field arithmetic. 3. (paragraph 4.0) Specification of the division polynomial used in 1). 4. (paragraph 5.0) Specification of an 80-bit offset to add to the code words. 5. (paragraph 6.0) Specification of the primitive polynomial. The individual specifications follow. 2.0 RS(16,12) DEFINITION Data is obtained starting with the least significant bit of the first octet of the frame and proceeding through each octet from least to most significant bit. Subsequent blocks begin with the data bit in the sequence following the last bit encoded by the previous block. The number of bits in the frame always forms an integral number of blocks due to padding inserted into the frame format as shown in Fig. L.1. The data d[0], d[1], d[2],............,d[59] is formed into 12 symbols. We assume that d[0] comes first, d[1] comes second, etc. We label these symbols ds[15], ds[14], ds[13],........, ds[4] where ds[15] = d[ 0], d[ 1], d[ 2], d[ 3], d[ 4] ds[14] = d[ 5], d[ 6], d[ 7], d[ 8], d[ 9] ds[13] = d[10], d[11], d[12], d[13], d[14], . . . ds[ 4] = d[55], d[56], d[57], d[58], d[59] Each of the ds symbols consists of five bits, i.e., the ds are elements of the field with 32 elements, GF(32). Note: d[0] is the low order bit of symbol ds[15]; d[4] is the high order bit of symbol ds[15]. Data is transmitted from symbol ds[15] to ds[4] and then rs[3] to rs[0]. Each symbol is transmitted least to most significant bit. Thus the least significant bit of the first octet becomes the least significant bit of the first symbol. The sixth least significant bit of the first octet becomes the least significant bit of the second symbol ds[14] and so on. ver4.0 K-II–312 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX W We define a polynomial ds(x) by 15 ds ( x ) = ∑ ds [ i ]x i i=4 We complete the description of the code by defining how to generate symbols rs[3], rs[2], rs[1], rs[0] to attach to the ds symbols. This definition is achieved relative to a degree 4 polynomial g(x). Let rem(x) be the remainder polynomial obtained by dividing ds(x) by g(x). Then the rs symbols are defined as the coefficients of the polynomial rem(x). To be specific: ds[15], ds[14], ds[13,........ds[4], rs[3], rs[2], rs[1], rs[0] is a RS (16, 12) code word when 3 rem ( x ) = ∑ rs [ j ]x j j=0 is equal to ds(x) modulo the division polynomial g(x). All the arithmetic in the division is defined over GF(32) (see paragraph 3.0 below). 3.0 FIELD ARITHMETIC DEFINITION The arithmetic over GF(32) will be defined as follows: The addition of two 5-bit symbols will be equal to the exclusive-or of the corresponding bits. The multiplication will be as follows. Firstly, the all-zero symbol will always multiply with another symbol to produce the all-zero symbol. It remains to define the multiplication of two symbols with non-zero entries. This is defined by log and antilog tables. If i and j are the symbols, we define their Galois multiplication as i * j where i * j = antilog [ ( log i + log j )modulo 31 ] That is: the two logs are taken; they are added (using integer arithmetic); if the sum exceeds 30, 31 is subtracted; and the answer addresses an antilog table. It remains to give the log and antilog tables. Writing the 5-bit symbols in hex, the tables are as follows: 3.1 Log Table Addresses 1 to f Addresses 10 to 1f 00 01 12 02 05 13 0b 03 1d 06 1b 14 08 0c 17 04 0a 1e 11 07 16 1c 1a 15 19 09 10 0d 0e 18 0f 3.2 Antilog Table Addresses 0 to f Addresses 10 to 1f 3/1/05 01 02 04 08 10 05 0a 14 0d 1a 11 07 0e 1c 1d 1f 1b 13 03 06 0c 18 15 0f 1e 19 17 0b 16 09 12 00 K-II–313 ver4.0 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 APPENDIX W S-5800 4.0 DIVISION POLYNOMIAL DEFINITION In this section we define the division polynomial, g(x). 4 g( x) = ∑ g [ i ]x i i=0 Then, writing the 5-bit symbols g[i] in hex, the values of g[i], with i increasing from 0 to 3 are as follows: 01 0a 1d 0a 01 5.0 OFFSET PATTERN DEFINITION In this section, we define a pattern of sixteen 5-bit symbols that are added to the RS(16,12) code words. Let ds[15], ds[14], ds[13],......ds[4], rs[3], rs[2], rs[1], rs[0] be the RS code word defined in paragraph 2.0. Then we add (modulo 2 or exclusive OR) a sequence of sixteen 5-bit symbols O[15], O[14], O[13],........O[0] to the code word symbols. Specifically, O[15] is added to ds[15], O[14] is added to ds[14],........and O[0] is added to rs[0]. In hex notation and with increasing index of i, O[i] is equal to: 1c 12 13 0e 1f 06 16 1c 16 1c 16 1c 01 06 1c 0c (Thus, for example, O[0] is equal to 1c.) The final symbols to be transmitted are labeled C[15], C[14], C[13]...,C[4], C[3], C[2], C[1], C[0] where C[15] is equal to the sum of ds [15] and O[15], etc. In terms of transmission, C[15] is sent first, C[14] is sent second, etc. 6.0 PRIMITIVE POLYNOMIAL The GF(32) is constructed from the primitive polynomial: 2 P(x) = 1 + x + x 5 Commentary: The following two examples illustrate the process by which data is encoded. This is for illustrative purposes only and is not part of the specification. Example 1: Assignment of 60 bits from data octets to symbols Octet Format MSB 7 F N V d l t x ver4.0 6 E M U c k s w 5 D L T b j r v 4 C K S a i q u 3 B J R Z h p 2 A I Q Y g o 1 9 H P X f n LSB 0 8 G O W e m Symbol Format MSB LSB 4 3 2 1 0 9 8 7 6 5 E D C B A J I H G F O N M L K T S R Q P Y X W V U d c b a Z I h g f e n m l k I s r q p o x w v y t K-II–314 Symbol Position DS[15] DS[14] DS[13] DS[12] DS[11] DS[10] DS[9] DS[8] DS[7] DS[6] DS[5] DS[4] 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 S-5800 APPENDIX W Example 2. Calculation of RS Symbols (offset sequence not applied) Data Symbols Parity Symbols DS[15] DS[14] DS[13] DS[12] DS[11] DS[10] DS[9] DS[8] DS[7] DS[6] DS[5] DS[4] RS[3] RS[2] RS[1] RS[0] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 02 03 04 05 06 07 08 09 0A 0B 02 05 04 03 0E 17 14 1D 0C 0C 0C 12 0B 01 05 0B 19 00 17 1A 12 12 1B 19 00 04 1F 0B 1B 00 19 17 0F 0D 18 0D 3/1/05 K-II–315 ver4.0 3/1/05 APPENDIX X AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 APPENDIX X ATCS STANDARD PROTOCOL TEST APPLICATION 1.0 INTRODUCTION 1.1 The standard test application shall provide a mechanism whereby a tester can manipulate and test the upper layer protocol entities within an ATCS user device from the application side of the protocols. Manipulation of the protocols from both the line and application sides is necessary to effectively verify protocols' performance and adherence to this specification. The standard protocol test application shall be available with every ATCS user device (CDC, OBC, WIU, intelligent terminal, etc.). 1.2 The standard test protocol application will perform the following functions: • Receive and decode test command messages (21.3.1) from the data system. • Implement tests as defined by the test command messages. • Report the test results to the originator of the test command message using a test result message (21.4.1). • Interface to the upper layer protocols using the application signaling as defined by this specification and as implemented by the manufacturer. 1.3 The test command message (21.3.1) will contain the following data: • Time limit on test. The test application will send test results when this time interval has expired. • Signals that the test application should send to the protocols. These may be tied to a time interval measured from the previous step in the test or based on a “wait for signal” from the protocols. 1.4 The test result message will contain the following: • A list of all signals sent by the standard protocol test application to the protocols and their time of occurrence. • A list of signals received by the standard protocol test application from the protocols and their time of occurrence. 1.5 A typical test would proceed as follows: 1. 2. 3. 4. 5. 6. 7. 8. 9. ver4.0 Tester configures device (according to manufacturer-defined procedure) for test mode. Note: Manufacturer shall provide a reliable mechanism to ensure that the test application is completely disabled during normal operation of the ATCS device. Device loads and starts standard protocol test application. Standard protocol test application opens general purpose session to receive test command message. This session should be set to the devices normal health address (DHEL, LHEL, THEL, or WHEL) as defined in Appendix T. Tester sends test command message to standard protocol test application (contents defined by test plan, format defined by ATCS Specification 250). Standard protocol test application performs test as directed by the test command message. Tester sends packets to the device during the test as defined by the test plan. Standard protocol test application determines test time has expired and ends testing. Standard protocol test application sends results in a test result message to the tester. The tester evaluates the test response packet and the packets sent by the device during the test and determines if the test was successful. K-II–316 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 S-5800 APPENDIX X 1.6 The signalling to be implemented by the standard protocol test application shall be as follows (parentheses contain the presentation layer—session layer signal mnemonics contained in Appendix C, Table C.1): Application to Upper Layer Protocol Signals 1 2 3 4 5 6 7 8 9 10 11 12 13 14 — — — — — — — — — — — — — — Send Message (PSM) Accept Incoming Call (PSP) Reject Incoming Call (PSO) Open General Purpose Session (PSA) Open Master to Slave Session (PSE) Open Slave to Master Session (PSC) Add Master to Session (PSL) Transfer Session to Master (PSJ) Offer Session Transfer to Master (PSI) Deny Session Transfer to Master (PSK) Close General Purpose Session (PSB) Close Master to Slave Session (PSG) Close Slave to Master Session (PSD) Close Master to Slave(no closeout) (PSH) Upper Layer Protocol to Application Signals 21 22 23 26 27 28 29 30 31 32 33 34 35 36 37 38 — — — — — — — — — — — — — — — — Incoming Call (SPL) Confirm General Purpose Session Open (SPA) Confirm General Purpose Session Close (SPB) Confirm Master to Slave Session Open (SPE) Confirm Master to Slave Session Close (SPF) Deny Master to Slave Session Open (SPM) Deny Master to Slave Session Close (SPG) Confirm Slave to Master Session Open (SPC) Confirm Slave to Master Session Close (SPD) Deny Slave to Master Session Open (SPM) Deny Slave to Master Session Close (SPG) Request Transfer of Session to (another) Master (SPH) Offer of Session Transfer From Another Master (SPN) Sent Message Success Indication (SPJ) Sent Message Failure Indication (SPK) Receive Message (SPI) Signal numbers 0, 15–20, and 24–25 are unused. Numbers are assigned to facilitate the identification of signals in messages exchanged between a tester and the standard protocol test application. Signals 5–10, 12–14, and 26–35 are not required in devices that are strictly nonvital (contain no vital elements, functions, or entities). Commentary: The following is a sample design of the logic required for a standard protocol test application to process a Test_Command_Msg and perform a test on the protocol stack of a host device. Refer to Appendix C, Table C.1 for the required data elements to be included in signals transmitted when a test instruction is performed. It is assumed that the standard protocol test application is loaded and running and that a general purpose session has been opened for the devices’ health monitor address (*HEL entity). 3/1/05 K-II–317 ver4.0 3/1/05 APPENDIX X AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. X.1 Sample of standard protocol test application logic (page 1 of 3) ver4.0 K-II–318 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX X Fig. X.2 Sample of standard protocol test application logic (page 2 of 3) 3/1/05 K-II–319 ver4.0 3/1/05 APPENDIX X AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 Fig. X.3 Sample of standard protocol test application logic (page 3 of 3) ver4.0 K-II–320 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX Y APPENDIX Y VITAL CRC CALCULATION (COMMENTARY) 1.0 INTRODUCTION 1.1 This appendix contains two examples of the calculation of “vital” CRCs. The first example displays an explicit calculation of the vital CRC in a spreadsheet format; the second example is a C program, which suppliers are free to use as they see fit. 1.2 Fig. Y.1 shows the 31-bit CRC calculation for a “message” of 2 bytes, hex01 and hex02. The data is arranged as the dividend with the least significant bit of the data representing the most significant bit of the dividend. The data has been shifted left by 31 positions, and 31 zeros are appended. The vital CRC polynomial of Appendix D is used as the divisor. The remainder is the 31-bit CRC sequence; a zero is added to the end of the remainder to fill out the last byte. The sequence of bits that would be sent is shown below the remainder, with the order of transmission being left to right. This is consistent with ATCS Specification 250, Section 3.2.1, which states that messages are sent least significant bit of the first byte first, and most significant bit of last byte last; and that CRCs are sent most significant bit of the most significant byte first, least significant bit of the least significant byte last. 1.3 The following program implements the above calculations in C; an example output for the same “data” as in the explicit example is also shown. Note that the CRC sequence (variable edcval) is a long integer (32 bits), and that the CRC polynomial has been “reversed.” This permits the CRC calculations to be applied to message bytes in sequence without resorting to reversing bit order in each byte, as was done in the first example. It has a side effect that the edcval must be byte reversed, so that the message sent would be: 01 02 25 ed bd 70 1.4 Again, the actual bit order of transmission is such that the first bit sent would be a “1” and the last bit sent would be a “0.” 1.5 When determining whether or not an error has occurred, the received data (including the CRC sequence) is passed through the algorithm. If no error has occurred, the CRC sequence will be all zeros. 3/1/05 K-II–321 ver4.0 3/1/05 S-5800 Fig. Y.1 CRC calculation example APPENDIX Y AAR Manual of Standards and Recommended Practices Railway Electronics ver4.0 K-II–322 3/1/05 3/1/05 S-5800 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics K-II–323 APPENDIX Y ver4.0 3/1/05 APPENDIX Y ver4.0 AAR Manual of Standards and Recommended Practices Railway Electronics K-II–324 S-5800 3/1/05 3/1/05 S-5800 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics K-II–325 APPENDIX Y ver4.0 3/1/05 APPENDIX Y ver4.0 AAR Manual of Standards and Recommended Practices Railway Electronics K-II–326 S-5800 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX Z APPENDIX Z VEHICLE AND FIELD SYSTEM NETWORK LAYER ROUTING 1.0 INTRODUCTION 1.1 In the ATCS operating environment, vehicle and field system devices are required to perform routing functions at the network layer (Layer 3). These devices use the HDLC balanced protocol defined in Appendix K, including the XID process defined in Appendix V, to provide Layer 2 services to Layer 3. These devices also use the ATCS network address assignments defined in Appendix T. 1.2 Definitions The following definitions apply to this appendix: Term Internal Routing External Routing Definition Routing of packets between a device's external port(s) and its user Layer 3 entity. For devices with multiple ports; routing of packets from one external port to another external port. 2.0 MOBILE ONBOARD DEVICES The network layer routing entity contained in mobile onboard devices shall perform the following functions: 2.1 Maintain a routing table containing the ATCS network address and Layer 2 address for internal addressable entities, and the ATCS network address, Layer 2 address, and external port number for external entities to which it may send packets. When the mobile onboard device is configured with multiple external ports, entities that may be accessed via each external port must be identified in the routing table. This information shall be initialized and maintained using information received from Layer 2 during the XID process. Commentary: For devices on board vehicles, there is a one-to-one correspondence between the last two BCD digits of an entity's ATCS network address (Layer 3 address) and its Layer 2 address. Thus, only the Layer 2 addresses are exchanged during the XID process. 2.2 For outgoing packets 2.2.1 Extract the destination ATCS network address from each packet. 2.2.2 If the destination ATCS network address is not a broadcast or multicast address, do the following: 2.2.2.1 Determine if the destination entity is an onboard entity or not. 2.2.2.2 If the destination entity is an onboard entity, then determine the appropriate Layer 2 address and external port using the routing table. Forward the packet to the appropriate Layer 2 queue for the assigned external port. 2.2.2.3 If the destination entity is not an onboard entity, then determine the correct external port for accessing the RF via the MCP. Assign the correct MCP Layer 2 address to the packet and forward the packet to the appropriate Layer 2 queue for the assigned external port. 2.2.3 If the destination ATCS network address is a broadcast or multicast address, do the following: 2.2.3.1 Determine the correct Layer 2 addresses and external ports for each onboard entity implied by the broadcast or multicast address using the routing table. Table Z.1 shows the interpretation of broadcast and multicast addresses for onboard devices. Forward a copy of the packet to each appropriate Layer 2 queue for the identified external ports. 3/1/05 K-II–327 ver4.0 3/1/05 APPENDIX Z AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 2.2.3.2 Determine if the broadcast or multicast address implies any addresses for entities not on board the vehicle. 2.2.3.3 If the broadcast address implies addresses for destination entities that are not onboard entities, then determine the correct external port for accessing the RF via the MCP. Assign the correct MCP Layer 2 address to the packet and forward a copy of the packet to the appropriate Layer 2 queue for the assigned external port. 2.3 For incoming packets 2.3.1 Extract the destination Layer 2 address from each frame. 2.3.2 If the destination Layer 2 address is not a broadcast (99H or FFH) or multicast address (61H), then determine if the destination Layer 2 address is an internal or external entity. 2.3.2.1 Internal Routing. If the destination Layer 2 address is an internal entity, then forward the packet to the user Layer 3 entity. 2.3.2.2 External Routing. If the destination Layer 2 address is an external entity, then determine the correct external port from the routing table and forward the packet to the appropriate Layer 2 queue for that port. In no instance shall the routing entity forward the same packet to the external port from which the packet was received. If the requested entity is not available or is accessible only via the same external port on which the packet was received, then the routing entity shall generate an Incompatible Destination service signal to the packet's originator. 2.3.3 If the destination Layer 2 address is a broadcast or multicast address, do the following: 2.3.3.1 Internal Routing. If there are addresses for internal entities implied in the broadcast or multicast address, then forward a copy of the packet to the user Layer 3 entity for distribution to the internal entities. 2.3.3.2 External Routing. Determine the correct Layer 2 addresses and external port(s) for each external entity implied in the broadcast or multicast address using the routing table. Forward a copy of the packet to each appropriate Layer 2 queue for each external port identified. In no instance shall the routing entity forward the same packet to the external port from which the packet was received. Commentary: Since routing decisions for incoming packets are made based upon the Layer 2 address, these decisions can be made as soon as the Layer 2 address arrives. This implies that manufacturers may implement routing mechanisms (i.e., Cut Through Routing) that are capable of making the routing decisions prior to the arrival of the entire packet. 2.4 Identifying Destination Entities Not On Board the Vehicle The destination entity is not an onboard entity if any of the following conditions are true: 2.4.1 The address type identifier for the destination ATCS address is 0, 2, 3, or 5. 2.4.2 The address type identifier for this vehicle is 1 and the address type identifier for the destination address is 4 or 6. 2.4.3 The address type identifier for this vehicle is 4 or 6, the address type identifier for the destination address is 1, and the destination address is not a broadcast address. 2.4.4 The address type identifier for the destination address is 1, 4, or 6 and the railroad number or vehicle number either does not match this vehicle or is a wildcard. 2.5 Assigning the Correct MCP Layer 2 Address On Board Vehicles Packets being sent to destination entities not on board the vehicle must be forwarded to the MCP using one of three Layer 2 addresses. Assign the correct MCP Layer 2 address to the packet according to the following logic: ver4.0 K-II–328 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX Z 2.5.1 If the destination address type identifier is 1, 4, 5, or 6 and it can be determined that this vehicle is out of coverage, then the correct Layer 2 address is 27H (RF User to RF User). 2.5.2 If the packet's priority is 0 and the destination address type identifier is 1, 4, 5, or 6, then the correct Layer 2 address is 25H (Emergency Broadcast). 2.5.3 If neither of the previous two conditions is met, then the correct Layer 2 address is 23H (Ground Network). 3.0 FIELD SYSTEM DEVICES 3.1 The network layer routing entity contained in field system devices shall perform the following functions: 3.1.1 Maintain a routing table containing the ATCS network address and Layer 2 address for internal addressable entities and the ATCS network address, Layer 2 address, and external port for all external entities to which it may send packets. When the field system device is configured with multiple external ports, all entities that may be accessed via each external port must be identified in the routing table. This information shall be initialized and maintained using information received from Layer 2 during the XID process. Information for devices that are hard-wired to the field system device shall be static entries in the routing table and not initialized and maintained via the XID process. The ATCS network addresses of these hard-wired devices shall be included in the XID messages emanating from the field system device in accordance with the requirements stated in Appendix V. Wayside interface units (WIUs) have a single Layer 2 address (03H). All messages directed to any of the WIU ATCS network addresses or its entities shall be sent to the WIU using its single Layer 2 address. This includes messages from other devices located at the same field site as the WIU. 3.1.2 For outgoing packets (from internal or hard-wired entities) 3.1.3 Extract the destination ATCS network address from each packet. 3.1.4 If the device containing this routing entity is not a WIU, then determine the correct external port for the WIU from the routing table. Assign the WIU Layer 2 address (03H) to the packet. Forward the packet to the appropriate Layer 2 queue for the assigned external port. 3.1.5 If the device containing this routing entity is a WIU and the destination ATCS network address is not a broadcast or multicast address, do the following: 3.1.5.1 Determine if the destination entity is located at this field site. 3.1.5.2 If the destination entity is located at this field site, then determine the appropriate Layer 2 address and external port using the routing table. Forward the packet to the appropriate Layer 2 queue for the assigned external port. 3.1.5.3 If the destination entity is not located at this field site, then determine the correct external port for accessing the RF via the MCP. Assign the correct MCP Layer 2 address to the packet. Forward the packet to the appropriate Layer 2 queue for the assigned external port. 3.1.6 If the device containing this routing entity is a WIU and the destination ATCS network address is a broadcast or multicast address, do the following: 3.1.6.1 Using the routing table, determine the correct Layer 2 addresses and external ports for each entity located at this field site and implied by the broadcast or multicast address. Forward a copy of the packet to each appropriate Layer 2 queue for the identified external ports. Table Z.2 shows the interpretation of broadcast and multicast addresses for field system devices. 3.1.6.2 Determine if the broadcast or multicast address implies any addresses for destination entities that are not located at this field site. 3/1/05 K-II–329 ver4.0 3/1/05 APPENDIX Z AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 3.1.6.3 If the broadcast or multicast address implies any addresses for destination entities not located at this field site, then determine the correct external port for accessing the RF via the MCP. Assign the correct MCP Layer 2 address to the packet. Forward the packet to the appropriate Layer 2 queue for the assigned external port. 3.1.7 For incoming packets 3.1.8 Extract the destination ATCS network address from each packet. 3.1.9 If the destination ATCS network address is not a broadcast or multicast address, then determine if the destination ATCS network address is an internal (including hard-wired) entity or external entity. 3.1.9.1 Internal Routing. If the destination ATCS network address is an internal or hard-wired entity, then forward the packet to the user Layer 3 entity. 3.1.9.2 External Routing. If the destination ATCS network address is an external entity, do the following: 3.1.9.2.1 Determine if the destination entity is located at this field site. 3.1.9.2.2 If the destination entity is located at this field site, then determine the appropriate Layer 2 address and external port using the routing table. Forward the packet to the appropriate Layer 2 queue for the assigned external port. In no instance shall the routing entity forward the same packet to the external port from which the packet was received. If the requested entity is not available or is accessible only via the same external port on which the packet was received, then the routing entity shall generate a Not Obtainable datagram service signal to the packet's originator. 3.1.9.2.3 If the destination entity is not located at this field site, then determine the correct external port for accessing the RF via the MCP. Assign the correct MCP Layer 2 address to the packet. Forward the packet to the appropriate Layer 2 queue for the assigned external port. 3.1.10 If the destination ATCS network address is a broadcast or multicast address, do the following: 3.1.10.1 Internal Routing. Forward a copy of the packet to the user Layer 3 entity for distribution to internal and hard-wired entities. 3.1.10.2 External Routing 3.1.10.2.1 Using the routing table, determine the correct Layer 2 addresses and external ports for each entity located at this field site and implied in the broadcast or multicast address. Forward a copy of the packet to each appropriate Layer 2 queue for each external port identified. In no instance shall the routing entity forward the same packet to the external port from which the packet was received. 3.1.10.2.2 Determine if the broadcast or multicast address implies addresses for destination entities not located at this field site. 3.1.10.2.3 If the broadcast or multicast address implies addresses for destination entities not located at this field site, then determine the correct external port for accessing the RF via the MCP. Assign the correct MCP Layer 2 address to the packet. Forward a copy of the packet to the appropriate Layer 2 queue for the assigned external port. 3.2 Identifying Destination Entities Not Located at Field Site The destination entity is not located at the same field site if either of the following conditions is true: 3.2.1 The address type identifier for the destination ATCS network address is 0, 1, 2, 4, or 6. ver4.0 K-II–330 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics APPENDIX Z 3.2.2 The address type identifier for the destination ATCS network address is 3 or 5 and the address is not one of the ATCS network addresses represented by this WIU. 3.3 Assigning the Correct MCP Layer 2 Address at Field Sites Packets being sent to destination entities not located at the same field site must be forwarded to the MCP using one of three Layer 2 addresses. Assign the correct MCP Layer 2 address to the packet according to the following logic: 3.3.1 If the address type identifier for this WIU is 5 and it can be determined that this WIU is out of coverage, then the correct Layer 2 address is 27H (RF User to RF User). 3.3.2 If the packet's priority is 0 and the destination address type identifier is 1, 4, 5, or 6, then the correct Layer 2 address is 25H (Emergency Broadcast). 3.3.3 If neither of the previous two conditions are met, then the correct Layer 2 address is 23H (Ground Network). Table Z.1 Onboard device Layer 3—broadcast and multicast address interpretation Destination Address 09 10000000DD 40000000DD 1RRR0000DD 4RRR0000DD 1000VVVVDD 4000VVVVDD 1RRRVVVV61 161 1RRRVVVV99 199 6RRR00000DD 600000000DD 6000VVVVVDD Locomotive Onboard Device Implied Addresses Internal RT clock and all onboard entities Entity DD if present Outbound Only Entity DD if present and RRR matches Outbound Only Non-Locomotive Onboard Device Implied Addresses Internal RT clock and all onboard entities Entity DD if present Entity DD if present Entity DD if present and RRR matches Entity DD if present and RRR matches Invalid Invalid If RRR and VVVV match, then all onboard display entities (PDSP) All onboard display entities (PDSP) If RRR and VVVV match, then all onboard entities (PALL) All onboard entities (PALL) Outbound only Outbound only Invalid If RRR and VVVV match, then all onboard display entities (PDSP) Invalid If RRR and VVVV match, then all onboard entities (PALL) Invalid Entity DD if present and RRR matches Entity DD if present Invalid Note: Definitions of the address device identifiers (DDs) are found in Appendix T. Address device identifiers shall be interpreted in accordance with Appendix T including those identifiers that imply multiple devices. Table Z.2 Field system device Layer 3—broadcast and multicast address interpretation Destination Address Field System Device Implied Addresses 09 Internal RT clock and all entities 3RRRWWWWWW00000 All entities within the specified field site 5RRRWWWWWW00000 3000WWWWWWDDXXX Invalid 5000WWWWWWDDXXX 3/1/05 K-II–331 ver4.0 3/1/05 APPENDIX AA AAR Manual of Standards and Recommended Practices Railway Electronics S-5800 APPENDIX AA GLOSSARY Term Definition ARQ Automatic repeat request—in ATCS, a system whereby messages are retried across the RF link or HDLC data link until a maximum try count is reached or an acknowledgment received. ANSI American National Standards Institute. ASCII American Standard Code for Information Interchange. The ATCS character set is ASCII ANSI X3.6. ATCS Advanced Train Control System. BCP Base communications package—the set of equipment installed at an ATCS base station site. CC Cluster controller—an ATCS ground network node responsible for the control of BCPs. CCITT Consultative Committee for International Telephone and Telegraph—an organization of the International Telecommunications Union that develops communications standards (“Recommendations”). Datagram A packet that is routed based on source and destination address, independent of how other packets are routed. DM Disconnected mode. EIA Electronic Industries Association. Emergency A situation that endangers life or property. Emergency Traffic Messages sent through the communications system that attempt to prevent, alleviate, or react to an emergency. The ATCS Communications Architecture provides several types of special handling for emergency traffic. FEP Front end processor—An ATCS ground network node responsible for providing network access to ground host and terminal users. FEP/CC Front end processor/cluster controller—an ATCS ground network node responsible for both the functions of a cluster controller and of a front end processor. Flow A mechanism used to prevent excessive network congestion by control inhibiting the transmission of traffic. HDLC High level data link control (an ISO Layer 2 protocol). I Information. ISO International Standards Organization. LAPB Link Access Procedure B as defined in X.25. Layer The communications handshaking logic in each ATCS device is divided into functional sections called layers. Each layer is responsible for handshaking directly with the layers immediately above and below it, and handshaking logically with its peer layer in another device. MCP Mobile communications package—the set of communications equipment installed on locomotives, in wayside devices, and in maintenance-of-way terminals to provide access to the ATCS communications network. ver4.0 K-II–332 3/1/05 3/1/05 S-5800 AAR Manual of Standards and Recommended Practices Railway Electronics Term APPENDIX AA Definition Message A complete set of information sent from one ATCS device to another. OSI Open systems interconnection—A model for developing communications architectures. P Poll. Packet A unit of information that can be passed through the ATCS Communications Network. A message (depending upon its length) may pass through the network as one or more packets. Protocol A set of procedures and data structures used to facilitate communications. RS 1. Reed-Solomon—a class of forward error correcting block codes. An RS code is used by ATCS on the radio network. 2. Recommended Standard—series of specifications issued by EIA. UI Unnumbered information. ULP Upper layer protocol (Layers 4–7). Vital A function in ATCS that could result in a physical conflict or other operational hazard of similar magnitude if an unsafe failure (including design error) occurs. Wildcard An address used to signify “any vehicle” to the wayside device. The wildcard vehicle address is 1000000013. X.25 A packet-based communications protocol developed by the CCITT. The ATCS communications network is based on X.25. 3/1/05 K-II–333 ver4.0 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 APPENDIX AB S-5800 APPENDIX AB CHANGE RECORD SHEET FOR S-5800 Revision 4.0 Date of Release 4/05 4.0 5/02 4.0 5/95 4.0 5/95 4.0 5/95 4.0 5/95 4.0 5/95 4.0 5/95 4.0 5/95 4.0 4.0 5/95 5/95 4.0 5/95 4.0 4.0 4.0 5/95 5/95 5/95 4.0 4.0 5/95 5/95 4.0 4.0 4.0 5/95 5/95 5/95 ver4.0 Affected Pages Appendix T Purpose of Change and Applicable SPRs SPR 41—expanded 2.0 Address Identifier List; expanded 5.0 Wayside Address Structure All Incorporated specification ATCS 200 into the AAR Manual of Standards and Recommended Practices, Section K-II, as Specification S-5800. Renumbered and reformatted document to meet the requirements of the MSRP Style Guide. Appendix D, E, P SPR 65, 232—incorporated message compression algorithm; added provision for compression of vital messages 3-29, 3-30 SPR 142—Section 3.4, Documentation—added new software maintenance requirements 3-8 SPR 144—Section 3.1.2.3.3—page 3-8—changed MIS interface definition 3-7, 3-8, Appendix H, SPR 152–155—incorporated 15-digit address structure for field P, R, Z devices; modified routing description for wayside messages; added provision for virtual node numbering Appendix H, L, P, U, V, SPR 157, 178—incorporated type 6 addressing into network layer and Z XID descriptions Appendix H SPR 158—page H-8—added second paragraph under Reset of MCP at Cluster Controller Boundaries 3-20, 3-21 SPR 164—Section 3.1.3.8 —added entire new section on base transmitter management, alternating frequencies, and optimal reuse Appendix P, R SPR 165—modified CC handoff logic for an MCP entering contact All SPR 179—checked specification for any grammatical/typo errors for consistency in specification format 2-1 SPR 180—added version numbers to specs under “Applicable Documents” section Appendix C, D, E, P SPR 198—added “Request Session Facility” All SPR 208—removed any references to withdrawn Spec 150 Appendix D, P SPR 218—modified packet retransmission logic at Layer 4 after receipt of a selective non-acknowledge (SNAK) packet Appendix I SPR 223—added section on LAPB system parameters Appendix K, T SPR 227—reformatted Appendix K; moved link layer addresses to Appendix T Appendix X SPR 233—added detailed description of standard test application Appendix T SPR 235—clarified field addressing structure Appendix P SPR 236—corrected grammatical/logic errors in Appendix P diagrams K-II–334 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 S-5800 Revision 3.0 Date of Release 3/93 2.1 3/91 2.0 6/90 1.0 2/89 0 0 4/88 4/88 0 4/88 0 12/87 3/1/05 APPENDIX AB Affected Pages All Purpose of Change and Applicable SPRs SPRs 6, 8, 9, 10, 18, 19, 20, 27, 32, 99, and 132—clarified and corrected MCP application and RF protocol logic. SPRS 4, 22, 28, 40, 43, and 106—clarified and corrected CC handoff application, tracking, and RF protocol logic. SPRs 11, 12, and 39—added message revision handling logic. SPRs 5, 17, 29, 77, 101, 110, 115, 125, and 131—clarified, corrected, and modified Layer 4 end-to-end signalling, including database mode changes and facility code processing changes/enhancements. SPR 68—added Appendix Z (routing logic). SPRs 63, 100, and 134—clarified and corrected CRC transmission and handling. SPR 73—clarified connectors and pin assignments. SPRs 135 and 136—clarified self-test and health reporting requirements. SPR 137—added address type 6 for trucks and personal portable terminals. SPR 109—incorporated address changes and 19200 transmission rate for LSI. SPRs 15 and 16—allowed use of some even-numbered addresses. SPR 30—added railroad IDs for testing. SPRs 13, 14, 23, 24, 25, 33, 34, 35, 36, 37, 38, 41, 44, 50, 52, 56, 57, 58, 59, 64, 75, 103, 105, 111, and 112—incorporated several additional minor clarifications and corrections. Published Revision 3.0. Appendices R and P Added state tables to Appendix R and published revised Appendix P drawings. 3-14, 3-15, 3-22, B-2, Added presentation CRC, added cluster controller handoff and B-3, D-3, D-4, broadcast routing definitions, clarified packet truncation at end of D-7–10, D-14–16, message at Layer 4. Defined MCP reset and capability negotiation. E-2–5, G-2, H-9–11, Added facilities for compression and suppression of transport J-1, J-3, K-1–4, L-4, duplicate elimination. L-5, N-1, 0-1, Appendix P, R-3, T-1–7, U-1, V-1–2, Appendix Y 3-8,3-9, Appendices Changed out-of-coverage comm to “talk around,” clarified FEC and C, H, J, L, N, P, V, and CRC encoding, added NACK, removed D-bit dependency for some service signals, corrected errors. Clarified polling in Layer 2 polled W protocol. X-1, 2, 3 Added Appendix X. P-VI–2, 3, 7, P-VI–8, Made corrections to session layer protocol drawings (Appendix P, part 9, 10, P-VI–12, 13, VI). P-VI–14, 18, P-VI–19, 23 O-1 Changed connector for RS422 synchronous connections from Cannon to Mil Spec connector. All Initial publication. K-II–335 ver4.0 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 APPENDIX AC S-5800 APPENDIX AC CROSS-REFERENCE TO PARAGRAPHS AND FIGURES IN PREVIOUS REVISION With this 2002 republishing, S-5800 (formerly ATCS Specification 200) has been completely reorganized by the Railway Electronics Task Force (RETF). The format, including the rule and paragraph numbering system, has been changed. In order to assist in locating tables, figures, and paragraphs in the new 2002 edition, the following cross-reference index has been created for this edition. This feature may not be maintained in subsequent editions and reprintings. ATCS 200 S-5800 ATCS 200 S-5800 ATCS 200 S-5800 ATCS 200 S-5800 Specification S-5800 Figure 3-6 Fig. 3.6 3.2.1.1 3.2.1.1 not numbered 3.4.3 1.0 Scope 1.0 not numbered 3.1.3.1.2 not numbered 3.2.1.1.1 1. 3.4.3.1 not numbered 1.1 not numbered 3.1.3.1.3 3.2.1.1.1 3.2.1.1.2 2. 3.4.3.2 not numbered 1.2 3.1.3.2 3.1.3.2 3.2.1.1.2 3.2.1.1.3 3. 3.4.3.3 2.0 not numbered 3.1.3.2.1 3.2.1.1.3 3.2.1.1.4 4. 3.4.3.4 3.0 3.0 not numbered 3.1.3.2.2 3.2.1.2 3.2.1.2 5. 3.4.3.5 3.1 3.1 not numbered 3.1.3.2.3 3.2.1.3 3.2.1.3 6. 3.4.3.6 3.1.1 3.1.1 not numbered 3.1.3.2.3.1 3.2.1.4 3.2.1.4 not numbered 3.4.4 not numbered 3.1.1.1 not numbered 3.1.3.2.3.2 3.2.1.5 3.2.1.5 1. 3.4.4.1 not numbered 3.1.1.2 not numbered 3.1.3.2.3.3 3.2.1.6 3.2.1.6 2. 3.4.4.2 Figure 3-1 Fig. 3.1 not numbered 3.1.3.2.4 not numbered 3.2.1.6.1 not numbered 3.4.5 3.1.2 3.1.2 3.1.3.3 3.1.3.3 not numbered Table 3.4 4.0 4.0 3.1.2.1 3.1.2.1 not numbered 3.1.3.3.1 not numbered 3.2.1.6.2 Appendix A not numbered 3.1.2.1.1 not numbered 3.1.3.3.2 not numbered 3.2.1.6.3 not numbered 1.0 not numbered 3.1.2.1.2 3.1.3.4 3.1.3.4 not numbered 3.2.1.6.4 not numbered 1.1 3.1.2.2 3.1.2.2 3.1.3.5 3.1.3.5 3.2.2 3.2.2 not numbered 1.2 not numbered 3.1.2.2.1 not numbered 3.1.3.5.1 3.2.3 3.2.3 not numbered 1.2.1 not numbered 3.1.2.2.2 not numbered 3.1.3.5.2 not numbered 3.2.3.1 not numbered 1.2.2 3.1.2.3 3.1.2.3 3.1.3.6 3.1.3.6 not numbered 3.2.3.2 not numbered 1.2.3 not numbered 3.1.2.3.1 3.1.3.6.1 3.1.3.6.1 3.2.3.1 3.2.3.3 not numbered 1.2.4 3.1.2.3.2 not tabled Table 3.2 not numbered 3.2.3.3.1 not numbered 1.2.5 3.1.2.3.1 3.1.2.3.3 3.1.3.6.2 3.1.3.6.2 not numbered 3.2.3.3.2 not numbered 1.2.6 3.1.2.3.2 3.1.2.3.4 not numbered 3.1.3.6.2.1 not numbered 3.2.3.3.3 not numbered 1.2.7 Figure 3-2 Fig. 3.2 not numbered 3.1.3.6.2.2 A. 3.2.3.3.3.1 not numbered 1.2.8 Fig. 3.3 3.1.3.6.3 3.1.3.6.3 B. 3.2.3.3.3.2 not numbered 1.2.9 3.1.2.3.3 3.1.2.3.5 not numbered Table 3.3 1. bulleted not numbered 1.2.10 3.1.2.3.4 3.1.2.3.6 3.1.3.7 3.1.3.7 2. bulleted not numbered 1.2.11 3.1.2.3.5 3.1.2.3.7 not numbered 3.1.3.7.1 3. bulleted not numbered 1.2.12 3.1.2.3.6 3.1.2.3.8 not numbered 3.1.3.7.1.1 4. bulleted Appendix B Figure 3-4 Fig. 3.4 not numbered 3.1.3.7.1.2 C. 3.2.3.3.3.3 not numbered 1.0 3.1.2.3.7 3.1.2.3.9 Figure 3-7 Fig. 3.7 D. 3.2.3.3.3.4 not numbered 1.1 3.1.2.4 3.1.2.4 not numbered 3.1.3.7.2 3.2.4 3.2.4 not numbered 1.2 not numbered 3.1.2.4.1 3.1.3.8 3.1.3.8 3.2.5 3.2.5 1) 1.2.1 not numbered 3.1.2.4.2 3.1.3.8.1 3.1.3.8.1 3.3 3.3 2) 1.2.2 not numbered Table 3.1 not numbered 3.1.3.8.1.1 not numbered 3.3.1 3) 1.2.3 not numbered 3.1.2.4.3 not numbered 3.1.3.8.1.2 Table 3-1 Table 3.5 not numbered 1.2.3.1 Figure 3-5 Fig. 3.5 3.1.3.8.2 3.1.3.8.2 not numbered 3.3.2 not numbered 1.2.3.2 3.1.2.4.4 not numbered 3.1.3.8.2.1 not numbered 3.3.3 not numbered 1.2.3.3 3.1.3 3.1.3 not numbered 3.1.3.8.2.2 3.4 3.4 4) 1.2.4 3.1.3.1 3.1.3.1 3.2 3.2 not numbered 3.4.1 5) 1.2.5 3.1.3.1.1 3.2.1 3.2.1 not numbered 3.4.2 6) 1.2.6 2.0 not numbered Figure 3-3 not numbered not numbered K-II–336 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 S-5800 ATCS 200 S-5800 ATCS 200 S-5800 ATCS 200 S-5800 APPENDIX AC ATCS 200 S-5800 7) 1.2.7 not numbered 2.6 1) 3.1 1) 4.1.4.1 8) 1.2.8 not numbered 2.7 2) 3.2 2) 4.1.4.2 9) 1.2.9 not numbered 2.8 3) 3.3 3) 4.1.4.3 10) 1.2.10 not numbered 2.9 a. 3.3.1 not numbered 4.2 not numbered 1.3 not numbered 2.10 b. 3.3.2 not numbered 4.2.1 not numbered 2.11 c. 3.3.3 not numbered 4.2.2 4.2.3 Appendix C not numbered 1.0 not numbered 2.12 d. 3.3.4 not numbered not numbered 1.1 not numbered 2.13 4) 3.4 not numbered 4.3 not numbered 1.2 not numbered 2.14 a. 3.4.1 not numbered 4.3.1 1) 1.2.1 not numbered 3.0 b. 3.4.2 not numbered 4.3.2 2) 1.2.2 1) 3.1 not numbered 4.0 Figure H-1 Table H.1 3) 1.2.3 2) 3.2 not numbered 5.0 Figure H-2 Table H.2 4) 1.2.4 not numbered 3.3 not numbered 6.0 not numbered 4.3.3 5) 1.2.5 not numbered 3.4 not numbered Table E.1 not numbered 4.4 6) 1.2.6 1) 3.4.1 not numbered Table E.2 Figure H-3 Table H.3 7) 1.2.7 2) 3.4.2 Appendix F—vacant not numbered 4.5 8) 1.2.8 3) 3.4.3 Appendix G not numbered 4.6 9) 1.2.9 4) 3.4.4 not numbered 1.0 not numbered 5.0 not numbered 2.0 5) 3.4.5 not numbered 1.1 not numbered 6.0 not numbered 2.1 6) 3.4.6 not numbered Fig. G.1 not numbered 7.0 not numbered 2.1.1 7) 3.4.7 not numbered 1.2 not numbered 7.1 not numbered 2.1.2 8) 3.4.8 not numbered 2.0 not numbered 7.2 not numbered 2.1.3 9) 3.4.9 not numbered 2.1 not numbered 7.3 not numbered 2.2 10) 3.4.10 not numbered 2.2 not numbered 8.0 not numbered 2.2.1 11) 3.4.11 not numbered 2.3 not numbered 9.0 not numbered 3.0 not numbered 4.0 not numbered 2.4 not numbered 10.0 not numbered 3.1 not numbered 4.1 not numbered 2.5 Appendix I not numbered 3.2 not tabled Table D.1 not numbered 2.6 not numbered 1.0 not numbered 4.0 not numbered 4.2 Appendix H not numbered 2.0 not numbered 4.1 not tabled Table D.2 not numbered 1.0 not numbered 2.1 not numbered 4.2 not numbered 5.0 not numbered 1.1 not numbered 2.2 not numbered 4.3 not tabled Table D.3 not numbered 1.2 Appendix J not numbered 5.0 not numbered 5.1 not numbered 1.3 not numbered 1.0 not numbered 5.1 not numbered 5.2 not numbered 1.4 not numbered 1.1 not numbered 5.2 not numbered 6.0 not numbered 2.0 not numbered 1.2 not numbered 5.3 not numbered 7.0 not numbered 3.0 not numbered 2.0 not numbered 5.3.1 not numbered 8.0 not numbered 3.1 not numbered 2.1 not numbered 5.3.2 Appendix E not numbered 3.2 not numbered 2.2 Figure C-1 Fig. C.1 not numbered 1.0 not numbered 4.0 not numbered 2.3 Table C-1 Table C.1 not numbered 2.0 not numbered 4.1 not numbered 2.4 Table C-2 Table C.2 1) 2.1 not numbered 4.1.1 not numbered 2.5 2) 2.2 not numbered 4.1.2 not numbered 2.6 Appendix D not numbered 1.0 3) 2.3 not numbered 4.1.3 not numbered 2.7 not numbered 2.0 4) 2.4 1) 4.1.3.1 not numbered 3.0 not numbered 2.1 5) 2.5 2) 4.1.3.2 not numbered 4.0 not numbered 2.2 6) 2.6 3) 4.1.3.3 Appendix K not numbered 2.3 a. 2.6.1 4) 4.1.3.4 not numbered 1.0 not numbered 2.4 b. 2.6.2 5) 4.1.3.5 not numbered 2.0 not numbered 2.5 not numbered 3.0 not numbered 4.1.4 not numbered 2.1 3/1/05 K-II–337 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 APPENDIX AC ATCS 200 S-5800 ATCS 200 S-5800 ATCS 200 S-5800 S-5800 ATCS 200 S-5800 not numbered 2.2 not numbered 6.0 Table P-6 Table P.5 not numbered Fig. P.42 not numbered 3.0 not numbered 7.0 Table P-7 Table P.6 not numbered Fig. P.43 not numbered 3.1 not numbered 7.1 Table P-8 Table P.7 not numbered Fig. P.44 not numbered 3.2 not numbered 7.2 Section I 3.0 not numbered Fig. P.45 not numbered 3.3 not numbered 8.0 not numbered 3.1 not numbered Fig. P.46 not numbered 3.4 not numbered 8.1 not numbered 3.2 not numbered Fig. P.47 not numbered 3.5 not numbered 8.2 not numbered Fig. P.2 not numbered Fig. P.48 not numbered 4.0 not numbered 9.0 not numbered Fig. P.3 not numbered Fig. P.49 not numbered 4.1 not numbered 10.0 not numbered Fig. P.4 Section III 5.0 not numbered 4.2 not numbered 10.1 Section II 4.0 not numbered 5.1 not numbered 4.2.1 not numbered 10.2 not numbered 4.1 not numbered 5.2 not numbered 4.2.2 not numbered 10.3 not numbered 4.2 not numbered Fig. P.50 not numbered 4.2.3 not numbered 11.0 not numbered Fig. P.5 not numbered Fig. P.51 not numbered 4.3 not numbered 11.1 not numbered Fig. P.6 not numbered Fig. P.52 not numbered 4.3.1 not numbered 11.2 not numbered Fig. P.7 not numbered Fig. P.53 not numbered 4.3.2 1. 11.2.1 not numbered Fig. P.8 not numbered Fig. P.54 not numbered 4.4 2. 11.2.2 not numbered Fig. P.9 not numbered Fig. P.55 not numbered 4.4.1 3. 11.2.3 not numbered Fig. P.10 not numbered Fig. P.56 not numbered 4.4.2 not numbered 12.0 not numbered Fig. P.11 not numbered Fig. P.57 not numbered 4.4.1 Appendix M not numbered Fig. P.12 not numbered Fig. P.58 not numbered 4.4.2 not numbered not numbered Fig. P.13 not numbered Fig. P.59 not numbered 4.5 Appendix N not numbered Fig. P.14 not numbered Fig. P.60 not numbered 4.6 not numbered 1.0 not numbered Fig. P.15 not numbered Fig. P.61 not numbered 4.6.1 not numbered 1.1 not numbered Fig. P.16 not numbered Fig. P.62 not numbered 4.6.2 not numbered 1.2 not numbered Fig. P.17 not numbered Fig. P.63 not numbered 4.7 not numbered 1.3 not numbered Fig. P.18 not numbered Fig. P.64 not numbered 4.8 Appendix O Appendix L 1.0 not numbered Fig. P.19 not numbered Fig. P.65 not numbered 1.0 not numbered Fig. P.20 not numbered Fig. P.66 not numbered 1.0 not numbered 1.1 not numbered Fig. P.21 not numbered Fig. P.67 not numbered 2.0 not numbered 1.2 not numbered Fig. P.22 not numbered Fig. P.68 not numbered 2.1 not numbered 1.3 not numbered Fig. P.23 not numbered Fig. P.69 not numbered 2.2 not numbered 1.4 not numbered Fig. P.24 not numbered Fig. P.70 Figure L-1 Fig. L.1 not numbered 1.5 not numbered Fig. P.25 not numbered Fig. P.71 not numbered 3.0 not numbered 1.6 not numbered Fig. P.26 not numbered Fig. P.72 A. 3.1 not numbered 1.7 not numbered Fig. P.27 not numbered Fig. P.73 B. 3.2 not numbered O.1 not numbered Fig. P.28 not numbered Fig. P.74 new 3.3 Appendix P not numbered Fig. P.29 not numbered Fig. P.75 C. 3.4 not numbered 1.0 not numbered Fig. P.30 not numbered Fig. P.76 not numbered 4.0 not numbered 1.1 not numbered Fig. P.31 not numbered Fig. P.77 not numbered 4.1 not numbered 1.2 not numbered Fig. P.32 not numbered Fig. P.78 not numbered 4.2 not numbered 1.3 not numbered Fig. P.33 not numbered Fig. P.79 not numbered 4.3 not numbered 1.4 not numbered Fig. P.34 not numbered Fig. P.80 not numbered 5.0 not numbered 1.5 not numbered Fig. P.35 not numbered Fig. P.81 not numbered 5.1 not numbered 2.0 not numbered Fig. P.36 not numbered Fig. P.82 not numbered 5.2 Table P-1 Fig. P.1 not numbered Fig. P.37 not numbered Fig. P.83 not numbered 5.3 Table P-2 Table P.1 not numbered Fig. P.38 not numbered Fig. P.84 not numbered 5.4 Table P-3 Table P.2 not numbered Fig. P.39 not numbered Fig. P.85 not numbered 5.5 Table P-4 Table P.3 not numbered Fig. P.40 not numbered Fig. P.86 not numbered 5.6 Table P-5 Table P.4 not numbered Fig. P.41 not numbered Fig. P.87 K-II–338 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 S-5800 ATCS 200 S-5800 ATCS 200 S-5800 ATCS 200 S-5800 APPENDIX AC ATCS 200 S-5800 not numbered Fig. P.88 not numbered Fig. P.131 not numbered Fig. P.177 not tabled Table R.9 not numbered Fig. P.89 not numbered Fig. P.132 not numbered Fig. P.178 Table R-2 Table R.10 not numbered Fig. P.90 not numbered Fig. P.133 not numbered Fig. P.179 Table R-3 Table R.11 not numbered Fig. P.91 not numbered Fig. P.134 not numbered Fig. P.180 Appendix S not numbered Fig. P.92 not numbered Fig. P.135 Section VII 9.0 not numbered not numbered Fig. P.93 not numbered Fig. P.136 not numbered 9.1 Appendix T not numbered Fig. P.94 not numbered Fig. P.137 not numbered 9.2 not numbered 1.0 not numbered Fig. P.95 not numbered Fig. P.138 not numbered Fig. P.181 not numbered 2.0 not numbered Fig. P.96 not numbered Fig. P.139 not numbered Fig. P.182 not numbered 3.0 not numbered Fig. P.97 not numbered Fig. P.140 not numbered Fig. P.183 not numbered 4.0 not numbered Fig. P.98 not numbered Fig. P.141 not numbered Fig. P.184 not numbered 4.1 not numbered Fig. P.99 not numbered Fig. P.142 Appendix Q not numbered 4.2 not numbered Fig. P.100 not numbered Fig. P.143 not numbered 1.0 not numbered 4.3 not numbered Fig. P.101 not numbered Fig. P.144 1) 1.1 not numbered 4.4 not numbered Fig. P.102 not numbered Fig. P.145 2) 1.2 not numbered 5.0 not numbered Fig. P.103 not numbered Fig. P.146 3) 1.3 not numbered 5.1 not numbered Fig. P.104 not numbered Fig. P.147 Appendix R not numbered 5.3 not numbered Fig. P.105 not numbered Fig. P.148 not numbered 1.0 not numbered 5.4 not numbered Fig. P.106 not numbered Fig. P.149 not numbered 1.1 not numbered 5.5 not numbered Fig. P.107 not numbered Fig. P.150 not numbered 1.2 not numbered 6.0 not numbered Fig. P.108 not numbered Fig. P.151 Table R-1 Table R.1 not numbered 7.0 Section IV 6.0 not numbered Fig. P.152 not numbered 2.0 not numbered 7.1 not numbered 6.1 not numbered Fig. P.153 not numbered 2.1 not numbered 7.2 not numbered 6.2 not numbered Fig. P.154 not numbered 2.2 not numbered 7.3 not numbered Fig. P.109 not numbered Fig. P.155 not numbered 2.2.1 not numbered 8.0 not numbered Fig. P.110 Section VI 8.0 not numbered 2.2.2 not numbered 8.1 not numbered Fig. P.111 not numbered 8.1 not numbered Table R.2 not numbered 8.2 not numbered Fig. P.112 not numbered 8.2 Figure R-1 Fig. R.1 Appendix U not numbered Fig. P.113 not numbered Fig. P.156 not numbered 2.2.3 not numbered not numbered Fig. P.114 not numbered Fig. P.157 not numbered 2.3 Appendix V Section V 7.0 not numbered Fig. P.158 not numbered 2.3.1 not numbered 1.0 not numbered 7.1 not numbered Fig. P.159 not numbered 2.3.2 not numbered 1.1 not numbered 7.2 not numbered Fig. P.160 not numbered 2.3.2.1 not numbered 1.2 not numbered Fig. P.115 not numbered Fig. P.161 not numbered 2.3.2.2 not numbered 1.3 not numbered Fig. P.116 not numbered Fig. P.162 not tabled Table R.3 not numbered 1.4 not numbered Fig. P.117 not numbered Fig. P.163 not numbered 2.3.2.3 not numbered 1.4 not numbered Fig. P.118 not numbered Fig. P.164 not tabled Table R.4 not numbered 1.5 not numbered Fig. P.119 not numbered Fig. P.165 not numbered 2.3.2.4 not numbered 1.6 not numbered Fig. P.120 not numbered Fig. P.166 not tabled Table R.5 not numbered 1.7 not numbered Fig. P.121 not numbered Fig. P.167 not numbered 2.3.2.5 not numbered 1.8 not numbered Fig. P.122 not numbered Fig. P.168 not tabled Table R.6 not numbered 1.9 not numbered Fig. P.123 not numbered Fig. P.169 not numbered 2.3.2.6 not numbered 1.10 not numbered Fig. P.124 not numbered Fig. P.170 not numbered 2.4 not numbered 1.11 not numbered Fig. P.125 not numbered Fig. P.171 not numbered 2.4.1 not numbered 1.12 not numbered Fig. P.126 not numbered Fig. P.172 not tabled Table R.7 not numbered 1.13 not numbered Fig. P.127 not numbered Fig. P.173 not numbered 2.4.2 not numbered 1.14 not numbered Fig. P.128 not numbered Fig. P.174 not numbered 2.4.3 Figure V-1 Fig. V.1 not numbered Fig. P.129 not numbered Fig. P.175 not tabled Table R.8 Figure V-2 Fig. V.2 not numbered Fig. P.130 not numbered Fig. P.176 not numbered 2.4.4 Figure V-3 Fig. V.3 3/1/05 K-II–339 1.0 1.0 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 APPENDIX AC ATCS 200 S-5800 ATCS 200 S-5800 Figure V-4 Fig. V.4 not numbered 3.0 Figure V-5 Fig. V.5 not numbered 3.1 Figure V-6 Fig. V.6 1) 3.1.1 2) 3.1.2 Appendix W S-5800 not numbered 1.0 3) 3.1.7 not numbered 1.1 not numbered 3.2 not numbered 1.2 not numbered 3.3 not numbered 1.3 1) 3.3.1 not numbered 2.0 2) 3.3.2 not numbered 3.0 3) 3.3.3 not numbered 3.1 Table Z-1 Table Z.1 not numbered 3.2 Table Z-2 Table Z.2 not numbered 4.0 not numbered 5.0 not numbered 6.0 Example 1 Example 1 Example 2 Example 2 Appendix X not numbered 1.0 not numbered 1.1 not numbered 1.2 not numbered 1.3 not numbered 1.4 not numbered 1.5 not numbered 1.6 not numbered Fig. X.1 not numbered Fig. X.2 not numbered Fig. X.3 Appendix Y not numbered 1.0 not numbered 1.1 not numbered 1.2 not numbered 1.3 not numbered 1.4 not numbered 1.5 not numbered Fig. Y.1 Appendix Z not numbered 1.0 not numbered 1.1 not numbered 1.2 not numbered 2.0 1) 2.1 2) 2.2 3) 2.3 not numbered 2.4 not numbered 2.5 1) 2.5.1 2) 2.5.2 3) 2.5.3 K-II–340 3/1/05 3/1/05 S-5810 AAR Manual of Standards and Recommended Practices Railway Electronics MOBILE COMMUNICATIONS PACKAGE Specification S-5810 (Formerly ATCS Specification 210) Adopted: 1987; Revised: 1995, 2002 1.0 SCOPE 1.1 This document sets forth the mobile communications package requirements for Advanced Train Control Systems (ATCS). It identifies the functions and the nature of the interfaces. There are companion specifications that describe the architecture of the ATCS communications system, locomotive equipment, track forces equipment, wayside equipment, and the computer-aided dispatch system. 1.2 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 that they consider to be cost-effective and appropriate. Suppliers and railroads purchasing hardware or software in accordance with this specification are responsible for ensuring that equipment and its application satisfy regulatory and safety requirements. 2.0 APPLICABLE DOCUMENTS The following documents are 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 100, Version 4.0, System Architecture Overview • ATCS Specification 110, Version 4.0, Environmental Considerations • 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 • AAR Manual of Standards and Recommended Practices, Specification 5800, Version 4.0, Communications System Architecture • AAR Manual of Standards and Recommended Practices, Specification 5825, Version 4.0, Cluster Controller • AAR Manual of Standards and Recommended Practices, Specification 5830, Version 4.0, Base Communications Package • ATCS Specification 250, Version 4.0, Message Formats • ATCS Specification 310, Version 4.0, Locomotive Computer • Government of Canada, Telecommunications Regulatory Service, Radio Standards Specification 119 • Government of Canada, Telecommunications Policy Branch, Spectrum Utilization Policy SP 300.4 • Government of Canada, Telecommunications Regulatory Service, Standard Radio System Plan SRSP 501 • FCC Rules, Parts 2, 15, and 90 • FCC General Docket No. 84-1233/RM-4829 • AAR Manual of Standards and Recommended Practices, Specification M-590, Locomotive System Integration Architecture Specification, Version 4.0. 3/1/05 K-II–341 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5810 3.0 REQUIREMENTS 3.1 System Definition The mobile communications package (MCP) includes the radio and computer hardware and software necessary to communicate through the ATCS datalink system. The MCP provides a standard interface with the ATCS data network for the following: • Intelligent terminals—to support track forces and locomotives without computers • Locomotive computers—and by extension the peripherals attached to the computer • Wayside interface units—which control wayside devices These devices are referred to as clients for the remainder of this specification. Coverage is defined to mean “within range of an ATCS base station.” 3.1.1 MCP Elements The MCP shall contain the following major functional elements: 3.1.1.1 Frequency Controller 3.1.1.1.1 Receives frequency command messages from the client and sets the radio channel. Receives frequency query messages, determines the currently tuned channel from the radio, and reports the channel to the requestor. Message numbers 17.3.3, 17.1.1, and 17.2.1 are the SET_FREQUENCY_MSG, QUERY_FREQUENCY_MSG, and FREQUENCY_RESPONSE_MSG messages, respectively. The frequency controller shall recall the last frequency command received and shall set the radio to that frequency if tuning is lost. The frequency controller shall be configured with a default frequency list. The default frequency list shall be ATCS channels 1–6 as defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix N. 3.1.1.1.2 When the MCP is configured with an RF-connected WIU, the frequency controller shall determine, via a manufacturer-defined mechanism, the correct channel at startup and set the radio to that frequency when the MCP is initialized. The mechanism for determining the startup channel shall facilitate configuring the MCP's startup radio channel when the MCP is installed at the field site. Commentary: The following mechanisms may be suitable for determining the correct channel at startup: • Dip switches • Storing the channel from the last frequency command received in nonvolatile memory and using this channel at startup • Other railroad approved methods 3.1.1.2 Radio Network Layer 3 Protocol Entity This element shall implement the radio network Layer 3 protocol as defined in Appendix H to ATCS Specification 200. It shall control retries of messages, sequence numbering, service signal generation and acknowledgment generation. The Layer 3 entity shall be configured with the addresses to which it must respond as described in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix V. 3.1.1.3 Local Routing Logic The MCP shall perform local routing according to the logic specified in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix Z. 3.1.1.4 Layer 2 (HDLC balanced) Entity This entity shall implement the HDLC balanced protocol as defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix K. It shall provide identity of active processes to Layer 3, Local Routing Logic. ver4.0 K-II–342 3/1/05 3/1/05 S-5810 AAR Manual of Standards and Recommended Practices Railway Electronics 3.1.1.5 Layer 2 (RF Network) Entity This entity shall implement the ATCS RF Data Link protocol as defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix L. This includes synchronization, framing, busy bit protocol, forward error correction, and Layer 2 CRC calculation and verification. 3.1.1.6 Layer 1 (RS422) Interface This entity shall implement the interface to physically connect the MCP to its client device as defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix O. Note that this interface is defined to require no Layer 1 call setup procedure. 3.1.1.7 Radio The MCP shall contain a radio that shall provide access to the ATCS radio network. 3.1.1.8 Packet Buffering and Queuing The MCP shall buffer packets to and from the radio, to and from the frequency controller, and to and from the HDLC/RS422 interface. The queues to each of these entities shall be prioritized as described in AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.1.3.6.2. 3.1.1.9 Self-Test The MCP shall perform a self-test when power is initially applied and upon request. Self-test shall be manufacturer defined but, at a minimum, shall verify MCP software integrity (CRC on ROM is acceptable), conduct a RAM integrity test, and verify that the radio is operational. Receipt of a DEVICE_RESET_REQUEST_MSG (4.1.6) shall cause the MCP to perform a hardware reset, conduct a new self-test, and report the self-test results. Receipt of a QUERY_FOR_SELF_TEST_MSG (4.1.1) shall cause the MCP to report the results of the most recent self-test. The SELF_TEST_RESULTS_MSG (4.2.1) shall be used to report self-test results to the client's WHEL, LHEL, or THEL application. 3.1.1.10 Health Reporting The MCP shall perform health reporting in accordance with the requirements specified in the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.2.1.6. 3.1.1.11 In-Coverage Contact Timer The MCP shall report via diagnostic message to its client(s) when it is in coverage and it has not received any valid frames from the base for 60 seconds. (Traffic need not be directed to this MCP to reset timer.) The message number for this report is 17.2.2 (LOST_CONTACT_MSG). Recovery from this condition occurs when the MCP hears a ground network transmission and reports it to client(s) using message number 17.2.3 (REGAINED_CONTACT_MSG). 3.1.2 Interfaces The MCP shall meet all applicable FCC or DOC requirements. This will include type certification. 3.1.2.1 RF Signals and Radio Operations 3.1.2.1.1 The radio signal to and from the MCP is a filtered baseband frequency shift keying signal at a bit rate of 4800 bits per second ±100 ppm. The filter is a Gaussian filter with BT (bandwidth time) = 0.5. The deviation is ±1.7 KHz. The radio shall meet the applicable FCC/DOC stability requirements over the temperature range specified in ATCS Specification 110. The radio shall not employ pre-emphasis/de-emphasis circuitry. A shift upward in carrier frequency equates to a logical “0” and a shift downward equates to a logical “1.” 3.1.2.1.2 When the transmitter is keyed, a timer shall be started in the MCP. If emergency information is being sent and the timer reaches 3 seconds, then the current packet is completed and the transmitter turned off. If non-emergency information is being sent, the time-out occurs after 1 second. Whenever the transmitter is unkeyed, the MCP shall wait at least 1.5 seconds before keying 3/1/05 K-II–343 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5810 the transmitter again. Note that keying the transmitter is always subject to the busy bit protocol defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix L. 3.1.2.1.3 The interface to control the MCP radio shall be manufacturer defined. 3.1.2.1.4 In all RF configurations, the MCP shall meet the applicable FCC or DOC requirements. The MCP is not required to meet both (base and mobile) requirements at the same time in any configuration. In the out-of-coverage with RF connected WIU client configuration, the MCP sends and receives on the BCP transmit channel. The MCP may optionally (but is not required to) implement full duplex operation. The MCP shall implement the busy bit channel access protocol as defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix L. The MCP shall always (in all configurations) set the busy bit on its send data to indicate that the channel is busy. 3.1.2.1.5 Other characteristics of the signal in space format (forward error correcting code, frame format, synchronization, etc.) are included in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendices L and N. 3.1.2.2 Client Interface The MCP shall interface to its client (terminal, computer, or wayside interface unit) via HDLC Balanced Mode/RS422 as described in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendices K and O. The MCP shall identify itself as l, 23, 25, and 27 during the XID process. Traffic from the client to link address 01 shall be directed to the frequency manager or self-test module. Traffic from the client to link address 23H shall be directed to the RF network using RF link address 23H. Traffic from the client to link address 27H shall be directed to the RF network using link address 27H. Traffic from the client to link address 25H shall be directed to the RF network using link address 25H. See the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix U for a table of RF link addresses and Appendix K for client link addresses. Note: All ATCS devices shall be capable of decoding packets with address lengths from 0–15 BCD digits. 3.1.2.3 Optional Wireline Interface The MCP may (optionally) implement an RS232 (DTE side) port to implement the ATCS/HDLC polled or balanced point-to-point protocol to allow wayside devices to connect via the MCP's optional port to the ground network. This option allows the client to communicate with other ATCS devices without using an MCP radio. When this option is selected, the MCP will not normally contain a radio. Configuration of this port is manufacturer defined (including pin usage) because not all commercial modems are identical. 3.1.2.4 Interface Quantities Railroads will specify the number and types of interfaces (client, wireline) to be included in the MCP when ordering. Normally, at least one client interface will be included. 3.1.3 OSI Model The MCP's major functions fall within Layers 1–3 of the OSI model. Higher layers are required for entities in the MCP that send and receive traffic (e.g., frequency manager). ver4.0 K-II–344 3/1/05 3/1/05 S-5810 AAR Manual of Standards and Recommended Practices Railway Electronics 3.1.4 MCP Basic Operation 3.1.4.1 The basic operational processing logic for the MCP shall be as described in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix P, paragraph 4.0. Commentary: At power-up, the MCP shall perform a manufacturer-defined self-test sequence (see paragraph 3.1.1.9, "Self-Test"). If the test is unsuccessful, then it shall repeat the test. If the test is unsuccessful the second time, then the MCP shall enter the FAILED state. If the self-test is successful, then the MCP shall initiate a Layer 2 connection to the client. This includes performing XID according to the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix V. The MCP shall then enter the appropriate operating state based on its configuration and the logic described in Specification S-5800, Appendix P, paragraph 4.0. In normal operation, the MCP shall obtain packets from the radio channel (using protocols defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendices H, L, and N) or the ground network wireline (using protocols defined in Appendices H, M, and [J or K]), prioritize and queue them for the client interface, and deliver them to the client. Packets addressed to other than the configured address(es) or to a broadcast address to which the MCP does not respond shall be ignored. The MCP shall not acknowledge any broadcast messages. The MCP shall also obtain packets from the client wireline link (using the protocols defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendices K and O). It shall route those addressed to the test and frequency control entities and prioritize and queue the others for the radio channel or ground network according to the protocol described in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix H. If the MCP is disabled or impaired (Self-Test Failure or other entry into the FAILED state), it shall attempt to notify its WHEL/LHEL/or THEL client by sending a diagnostic message (4.2.3). If the MCP is unable to send traffic or to verify that traffic requiring RF network acknowledgements has been acknowledged, it shall return out of order datagram signals to client originators. See the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.2.1.6 for health reporting requirements. 3.1.4.2 The MCP performs flow control at Layer 2 using the HDLC RNR frame to its client. The MCP shall perform flow control procedures to prevent deadlock as described in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix Q. Commentary: The MCP application entities are required to maintain several timers depending on the MCP configuration and operating state. These timers are as follows: • ACTIVE SCAN—Duration is 20 seconds. Used in the ACTIVE_SCAN state to control the active scan of the channels upon startup. (Only for client types 1 [locomotive] and 4 [other mobile]) • PASSIVE SCAN—Duration is 20 seconds. Used in the PASSIVE_SCAN state to control the passive scan of the channels. • LOST CONTACT RESET—Duration is 1 minute. Used in the LOST_CONTACT state in conjunction with the LOST_CONTACT_RESET_REQ_SENT flag to control the amount of MCP_RESET_REQUEST_MSGs sent. The intent is to allow the sending of MCP_RESET_REQUEST_MSGs at a minimum interval of 1 minute when ground contacts are detected in the LOST_CONTACT state. • HEALTH—Duration is specified by client. Minimum duration is 5 minutes. Used in all states to send periodic health reports to client after receipt of a SET_HEALTH_RPTING_RATE_MSG. • GROUND CONTACT—Duration is 1 minute. Used in the IN_COVERAGE state to alert the clients when there has not been a valid frame received within the last 60 seconds. 3/1/05 K-II–345 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5810 Timer is reset whenever a valid frame is received. If timer expires, then a LOST_CONTACT_MSG is sent to the client(s) and the LOST_CONTACT state is entered. • BEACON—Duration is based on counter value. For counter values less than 5, duration is 5 minutes. For values greater than 5, duration is 10 minutes. Used in the IN_COVERAGE state to track the last time that the MCP transmitted over the radio channel and to ensure that the MCP transmits at a minimum time interval. (Only for client types 1 [locomotive] and 4 [other mobile].) 3.2 MCP Characteristics 3.2.1 Performance Characteristics The MCP shall meet the following performance parameters over the environmental ranges specified in ATCS Specification 110. 3.2.1.1 Bit Synchronization The receiver shall be capable of maintaining bit synchronization through a series of up to 80 contiguous bits with the same logical value (80 logical 0s or 80 logical 1s). 3.2.1.2 Buffer Capacity The MCP shall have the ability to buffer at least 40 packets of 2408 bits each. 3.2.1.3 Power Consumption 3.2.1.3.1 Locomotive Configuration General The MCP shall derive its power from the locomotive central power supply. The central power supply converts the 74 Vdc available on the locomotive power bus to an intermediate voltage for direct use by the system components. In addition, the central power supply isolates the locomotive dc power bus from the input to the power supplies of the system components. Input Voltage The MCP shall perform in accordance with the requirements of this specification when provided with an input voltage of +15 Vdc +20%. Input/Output The MCP shall be capable of withstanding 500 Vdc applied continuously between Isolation its input and output terminals, and between any input or output terminal and its chassis. Voltage Spikes The MCP shall be capable of withstanding voltage spikes of 24 V peak. Voltage Ripple The MCP shall be capable of withstanding voltage ripple on the input line of 250 mV peak-to-peak or less. Connector The standard 15 Vdc box-mounted receptacle shall be an MS 3112 E 16-8 P connector or railroad-approved equivalent. The mating connector shall be an MS 3116 F 16-8 S or railroad-approved equivalent. Refer to Appendix A for power connector pin assignments. 3.2.1.3.2 Track Forces/Wayside Configuration The MCP power consumption shall be less than 240 W at 13.6 Vdc +20%, 0.5 Vpp ripple, or less than 300 W at 115–130 Vac. Commentary: A lower limit of 95 Vac may be required at some sites and is an installation issue. ver4.0 K-II–346 3/1/05 3/1/05 S-5810 AAR Manual of Standards and Recommended Practices Railway Electronics 3.2.1.4 Radio Parameters The radio portion of the MCP shall meet the following performance criteria: Turn On Time Less than 10 milliseconds (measured from time that MCP computer requests the radio transmitter until 90–120% of the nominal carrier power is available, the frequency offset is less than 250 Hz, and the MCP computer is notified to send). Turn Off Time Less than 10 milliseconds (measured from time MCP computer requests transmitter shut off until transmitter carrier power drops below 1% of nominal.) Turn Around Less than 15 milliseconds (measured from when MCP computer requests Time transmitter shut off until MCP is operating normally in receive mode). Receiver 1% BER at worst case frequency offset at a signal level of –112 dBm without use Sensitivity of the FEC decoder. Transmitter 30 W nominal/45 W maximum. Power Commentary: Lightning and surge suppression equipment are an integration issue to be handled during installation. 3.2.2 Physical Characteristics 3.2.2.1 MCP Case 3.2.2.1.1 The MCP physical characteristics shall comply with the ATCS equipment packaging and weight requirements published in the AAR Manual of Standards and Recommended Practices, Section M, Specification M-590, “Locomotive System Integration Architecture.” 3.2.2.1.2 The MCP shall not require forced cooling air nor employ any fan arrangement that incorporates a filter. Commentary: It is preferable not to employ a fan. 3.2.2.2 Connectors 3.2.2.2.1 Refer to the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix O for MCP client connector standards. The MCP power connector is defined in Appendix A of this document. 3.2.2.2.2 The MCP connector for the antenna cable shall be a type N (50 Ohms) female connector. 3.2.3 Safety The safety in ATCS is a system issue achieved through the interdependence of hardware, software, and the human element. The failure of the MCP will not in and of itself create an unsafe condition, because voice radio provides a communications backup and the trains will not be allowed to exceed their limits of authority in the absence of communications. The MCP is important to safety, however, in that it provides one of the media by which safety-related information is passed between the vehicle or wayside device and the rest of the railroad. The MCP shall contain no entity capable of calculating the Layer 4 (vital) CRC, precluding the origination of vital traffic in the MCP. 3.2.3.1 General Safety Principles 3.2.3.1.1 The following general principles deal with the concepts of safety, vitality, and reliability within the Advanced Train Control System project. These general principles are to be used as guidelines and reference points in the definition, development, documentation, testing, certification, and performance at ATCS components and subsystems. These general principles are intended to be both descriptive and prescriptive. They describe the meaning of safety, vitality, and reliability when used in the context of ATCS. They prescribe the use of the terms safety, vitality, and reliability when used in the context of ATCS. 3/1/05 K-II–347 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5810 3.2.3.1.2 The safety, vitality, and reliability requirements of ATCS are best understood when taken together. A central objective of ATCS is to ensure safe train movements and track occupancies that avoid physical conflict and other operational hazards of similar magnitude. The elements of ATCS involved in the accomplishment of that central objective are vital, since their individual or collective failure can result in life-threatening and property-damaging accidents. The reliability with which ATCS accomplishes that central objective must be high enough to sustain efficient railroad operations. 3.2.3.1.3 In ATCS, the following apply: Vital Function A function in ATCS that could result in a physical conflict or other operational hazard of similar magnitude if an unsafe failure (including design error) occurs. Vital Those elements related to the organization, issuance, safe execution, and Elements of enforcement of movement authorities. The following are the steps in the ATCS movement authority process: 1. Gather sufficient information to ensure safe operation of the systems. 2. Use logic-based dispatcher decision-making to create movement authorities, which include block, track, and route occupancies, and speeds where applicable, granted to trains, engines, maintenance personnel, and high-rail-equipped personnel. The logic shall ensure that no unsafe movement authority can be issued. 3. Convey and ensure accurate receipt of those movement authorities. 4. Execute and enforce those movement authorities, including overriding the engineer for train braking, when required. Failure of a If a failure of a vital element occurs, no matter what kind of failure, the system Vital Element shall only fail in safe modes. These predicted safe failure modes shall be selected to eliminate the hazardous consequences of a component or system failure. Equipment design must be such that any single, independent component-of-software system failure results in a safe condition. Component-of-software system failures that are not independent, that is, those failures that in turn can cause others, must be considered in combustion as a single failure and must not cause unsafe conditions. Reliability The probability that the system will perform as intended for a specified period of time when used under stated conditions. Reliability is not a substitute for safety design and predicted safe failure modes. The reliability of ATCS vital elements, individual and in sum, must result in a system reliability high enough so as not to impair efficient railroad operations. 3.2.4 Environmental The MCP will comply with the requirements of ATCS Specification 110 for onboard equipment if configured for locomotive or track forces operation. The MCP will comply with the requirements of ATCS Specification 110 for wayside equipment if configured for wayside client or wireline operation. 3.2.5 Reliability The MCP shall have the same mean time between failures as the data radio as specified in the AAR Manual of Standards and Recommended Practices, Section M, Specification M-590, “Locomotive System Integration Architecture.” A failure is defined as the inability to function as specified. ver4.0 K-II–348 3/1/05 3/1/05 S-5810 AAR Manual of Standards and Recommended Practices Railway Electronics 3.2.6 Maintainability A maintainer shall be able to repair (fault diagnose + fault isolation + remove/replace + performance verification test) the MCP within 30 minutes. The MCP shall contain sufficient built-in test equipment (BITE) or self-diagnostic circuitry to support this requirement. 3.2.7 Availability (Commentary) The MCP shall be designed to provide a high level of functional availability. Availability shall be calculated as follows: MTBF Availability [%] = ----------------------------------------------------------------------------------------------------------------------------- × 100 [%] MTBF + Mean Time to Repair + Mean Travel Time Travel time is defined as the length of time between a failure and the initiation of repairs. 3.3 Design and Construction The goal of ATCS is to provide specifications that ensure interoperability, compatibility, safety, reliability, and functionality of components without specifying all of the details of the design of those components. Accordingly, the detailed design and construction of the MCP is not contained in this specification. 3.4 Documentation The following (minimum) documentation shall be provided by the manufacturer of the MCP: • • • • • • Operating instructions Installation guide and instructions Basic troubleshooting guide Preventive maintenance guide Warranty information (if applicable) Point of contact of manufacturer for problems (including name, address, and telephone number) • Proof of FCC/DOC certification • The manufacturer shall provide specific descriptions of test points and test setups to verify bit synchronization; turn-on, turn-off, and turn-around times; and receiver sensitivity. These tests shall be able to be performed using off-the-shelf test equipment. Test points are not required to be accessible without removing the equipment cover. • The manufacturer shall provide a certificate indicating that the MCP contains no hardware or software to calculate the vital Layer 4 redundancy check defined in Specification 200, Appendix D. Additional documentation, required if the buyer is to perform maintenance, is listed in the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.4. 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 ATCS Specification 140. 3/1/05 K-II–349 ver4.0 3/1/05 APPENDIX A AAR Manual of Standards and Recommended Practices Railway Electronics S-5810 APPENDIX A MCP POWER CONNECTOR Pin assignments for the MS 3112 E-16-8 P box-mounted receptacle used for the MCP interface to the power source are shown below. Pin A B C D E F G H ver4.0 Signal Name Spare +15 Vdc. Spare Spare Spare Spare +15 Vdc return Shield K-II–350 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 S-5810 APPENDIX B APPENDIX B CHANGE RECORD SHEET FOR S-5810 Revision 4.0 Date of Release 5/02 4.0 5/95 4.0 5/95 4.0 5/95 4.0 5/95 4.0 5/95 4.0 5/95 3.0 Mar 93 2.1 Mar 91 2.0 1.0 Jun 90 Feb 89 0 0 Apr 88 Apr 88 3/1/05 Affected Pages Purpose of Change and Applicable SPRs All Incorporated specification ATCS 210 into the AAR Manual of Standards and Recommended Practices, Section K-II, as Specification S-5810. Renumbered and reformatted document to meet the requirements of the MSRP Style Guide. All SPR 179—checked for any grammatical/typo errors for consistency in specification format (200 series specifications did not have lead-in paragraph in section 2.0). 2-1 SPR 180— added version numbers to specifications in "Applicable Documents.” SPR 181— checked specification for any LSI reference and, if applicable, added version numbers to LSI specifications. All SPR 207—checked specification for any references to specifications 157–158; these specifications have been withdrawn. All SPR 208—checked specification for any references to Specification 150; this specification has been withdrawn. 2-1 SPR 173—deleted references to obsolete/withdrawn specs (315, 510, 520, and Test Plan). 3-6, A-1 SPR 238—section 3.2.1.3.1, page 3–6— changed volts to +15, deleted paragraph on overvoltage protection; page A-1—changed volts to +15. All Corrected typos. Clarified and corrected initialization and operating logic as per SPRs 6, 8, 9, 10, 27, 99, and 132. Changed power, physical case, physical connector, and reliability requirements to correspond to LSI requirements as per SPR 109. Made Availability commentary as per SPR 98. Moved local routing logic to Specification 200, clarified and corrected self-test requirements, and moved health reporting requirements to Specification 200 as per SPRs 135 & 136. Publish Revision 3.0. 3-2, 3-3, 3-4, A-1 Inserted Page A–1. Changed MCP out-of-coverage RF configuration to send and receive on BCP transmit channel. Changed power requirements. Moved connector specifications to Specification 200. Changed MCP power-up procedure. Added commentary on lightning and surge suppression. Added clarification of self-test requirements. Added note about 15-digit address requirements. Added ability to have MCP set the radio channel when out of coverage. 3-1, 3-2, 3-5, 3-6, 3-7 Redefined startup and health monitoring procedures. 3-2, 3-3, 3-5, 3-6, 3-7 Changed out of coverage definition to include use of “talk around” mode. Added bit rate tolerance rating (100 ppm). Changed turn-on time to 10 milliseconds, with a maximum frequency offset of 250 Hz. Clarified lost regain contact reporting to client and incorporated new message numbers. 3-8 Changed client connector to more generic model. A-1 Changed power connector pinout for consistency with current clean cab radio installations. K-II–351 ver4.0 3/1/05 APPENDIX B AAR Manual of Standards and Recommended Practices Railway Electronics Revision 0 Date of Release Apr 88 Affected Pages 3-1, 3-2, 3-5, 3-6 0 Dec 87 All ver4.0 S-5810 Purpose of Change and Applicable SPRs Changed references to message labels to message number for consistency with Specification 200. Initial publication K-II–352 3/1/05 3/1/05 S-5820 AAR Manual of Standards and Recommended Practices Railway Electronics FRONT END PROCESSOR Specification S-5820 (Formerly ATCS Specification 220) Adopted: 1987; Revised: 1995, 2002 1.0 SCOPE 1.1 This document sets forth the requirements for the Advanced Train Control Systems (ATCS) front end processor. It identifies its major functions and interfaces. There are companion specifications that describe the architecture of the ATCS, its major subsystems, and each of the subsystems’ major components. 1.2 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 that they consider to be cost-effective and appropriate. Suppliers and railroads purchasing hardware or software in accordance with this specification are responsible for ensuring that equipment and its application satisfy regulatory and safety requirements. 2.0 APPLICABLE DOCUMENTS The following documents are 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 Considerations • 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 • AAR Manual of Standards and Recommended Practices Specification 5800, Version 4.0, Communications System Architecture • AAR Manual of Standards and Recommended Practices, Specification 5810, Version 4.0, Mobile Communications Package • AAR Manual of Standards and Recommended Practices, Specification 5825, Version 4.0, Cluster Controller • AAR Manual of Standards and Recommended Practices, Specification 5830, Version 4.0, Base Communications Package • ATCS Specification 250, Version 4.0, Message Formats 3.0 REQUIREMENTS 3.1 System Definition The front end processor (FEP) provides the primary entry point to the ground network for ground-based hosts/terminals. It is responsible for routing and queuing traffic and for service signal generation. 3.1.1 Front End Processor Elements The FEP shall provide the following major functions: 3.1.1.1 Vehicle Following and Packet Routing The FEP shall route packets to proper CCs, FEP/CCs, or FEPs based on routing tables and vehicle location table as described in the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.1.3.5 and Appendix R. 3/1/05 K-II–353 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5820 3.1.1.2 Ground User Interface The FEP shall provide a Layer l, 2, and 3 interface to ground-based hosts and terminals. 3.1.1.3 Ground Network Trunks The FEP shall implement the Layer 1 and 2 interface to FEPs, CCS, and FEP/CCs. 3.1.1.4 Network Time Updates Upon receiving a message (106.4.15) addressed to network address 0RRRNN0002 from an authorized (2RRRNN0001) address, the FEP shall begin queuing all traffic on channel groups numbered higher than 3 for a period of 5 seconds. This ensures that the network is quiescent during the time mark. Upon receiving any message addressed to network address 09, the FEP shall forward that message to all attached cluster controllers (but not FEP/CCs) (and if an FEP/CC, to all attached base stations and wireline-connected wayside devices). 3.1.1.5 Flow Control The FEP shall implement flow control at Layer 2 and special flow control recovery procedures as defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix Q. 3.1.1.6 Buffering and Queuing The FEP shall implement buffering and prioritized queuing of packets (prioritized queue handling is described in the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.1.3.6). 3.1.1.7 Configuration The FEP shall provide a mechanism for online configuration of its operating parameters and tables (including routing tables for stationary devices, e.g., dispatch centers). 3.1.1.8 Failure/Alarm Reporting The FEP shall provide a mechanism for online failure/fault/alarm reporting, including either an attached printer it shall provide or the facility to send messages with alarm information to a remote entity or both. This alarm reporting mechanism shall be used to report FEP and communications line status. Refer to the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.2.1.6. 3.1.1.9 Self-Test The FEP shall perform a self-test when power is applied. The self-test shall be manufacturer defined but, at a minimum, shall verify FEP software integrity (CRC on ROM or EXE file is acceptable), RAM integrity, and communications line availability. Upon completion of the self-test, the FEP shall send a PROVIDE_SELF_TEST_LIST_MSG (4.2.12) to its configured health reporting address containing self-test information for the FEP and communications lines. If the FEP is an FEP/CC, then the FEP/CC shall also report the self-test results for all attached base stations and wireline connected devices. The FEP/CC shall send a QUERY_FOR_SELF_TEST_MSG (4.1.1) to all attached base stations and wireline connected devices, wait for 30 seconds (for responses to arrive), and then send the PROVIDE_SELF_TEST_LIST_MSG. 3.1.1.10 Health Reporting The FEP shall perform health reporting in accordance with the requirements specified in the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.2.1.6. ver4.0 K-II–354 3/1/05 3/1/05 S-5820 AAR Manual of Standards and Recommended Practices Railway Electronics 3.1.2 Front End Processor Interfaces 3.1.2.1 Mandatory Interfaces • The front end processor shall implement the LAPB protocol as defined by the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix I. • The front end processor shall implement the HDLC balanced procedure to communicate with other CCs, FEPs, and FEP/CCs. This protocol is described in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix K. • The front end processor shall implement the procedures defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix R for cooperation in building and maintaining vehicle routing tables. • The front end processor shall implement Layer 1 interfaces as described in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix M. Note: All ATCS devices shall be capable of decoding packets with address lengths from 0–15 BCD digits. 3.1.2.2 Optional Interfaces 3.1.2.2.1 Protocol Adaptors the Front End Processor may optionally implement the X.25 virtual circuit interfaces described in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix G to allow users to access the ground network via public or private data networks. 3.1.2.2.2 Combined Cluster Controller/Front End Processor The front end processor may be combined with a cluster controller into a single device (FEP/CC). This device shall implement all of the cluster controller’s mandatory elements and interfaces in addition to the FEP interfaces/functions. Fig. 3.1 illustrates the relationship of the FEP, FEP/CC, and CC. 3.1.2.2.3 Base Station Management The FEP/CC may optionally connect to “star”-configured BCPs (that are equipped to do so) using the HDLC balanced protocol or to multidropped base stations using the ATCS/HDLC polled protocol. If the HDLC balanced protocol is used, base station test initiation shall be via messages addressed to the base station instead of a Layer 2 command (the message used to perform this is the QUERY_FOR_SELF_TEST_MSG, message number 4.1.1). In either case, the RF network Layer 3 protocol shall be implemented as well. If the FEP/CC is directly connected to BCPs either via point-to-point or multidropped line(s), it shall ensure that each base transmits at least once every 15 seconds. If the FEP/CC is connected to BCPs, it shall be capable of sending message BCP_TURN_OFF_XMTR_MSG (106.4.12) to the BCP(s) to command it to turn off the BCP transmitter. 3.1.3 OSI Model The FEP’s major functions fall within Layers 1–3 of the OSI model. Higher layers are required for entities in the FEP that send and receive traffic (e.g., control, configuration, and hand-off functions). 3.1.4 Front End Processor Basic Operation 3.1.4.1 At power-up, the front end processor will perform a self-test of itself and its communications lines (and if an FEP/CC, all attached BCPs and wireline-connected devices) and indicate the results to the alarm reporting mechanism. See the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.2.1.6. 3.1.4.2 The FEP shall process traffic from trunk lines (or optional LAPB lines) to stationary devices with destination address identifiers 0 or 2 as follows: 3/1/05 K-II–355 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5820 Commentary: FEPs can have multiple node numbers to provide logical groupings for routing purposes. Allocation of node numbers is not a part of the ATCS specifications. 1. It shall determine if the destination node and railroad number (digits 2–6 of the destination address) match this FEP’s node number(s). 2. If the node did not match, it shall attempt to route the packet to the destination node. If unable to route to the destination node, it shall generate an out-of-order datagram service signal (and optionally an alarm). Note: There is no Layer 3 handshake on the trunk or LAPB lines. 3. If the node in the address matched the front end processor’s node number(s), it shall attempt to route the packet to the destination, and if the destination address is not configured or is out-of-order, it shall generate an incompatible destination or out-of-order service signal. 3.1.4.3 Traffic from trunk lines (or LAPB lines) to vehicles and/or WIUs shall be processed by the FEP as follows: 1. The FEP shall determine the controlling node from the vehicle following table (if the destination identifier is 1, 4, or 6) or by a railroad-defined procedure (if the destination identifier is 3 or 5). If a packet is addressed to a vehicle not in the FEP’s routing/following table, the FEP shall dispose of the packet and attempt to locate the vehicle using procedures defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix R. 2. If the node did not match this (FEP’s) node number(s), route the packet to the destination node. If unable to route to the destination node, the FEP shall generate an out-of-order datagram service signal if the D-bit is set and unless the originator’s identifier is 1, 3, 4, 5, or 6 (and optionally an alarm). 3. If the node matched the front end processor’s node number(s), then route the packet to the appropriate base station. Note: Layer 3 RF network handshaking is required in delivering the packet to the vehicle (this may result in queuing the packet before delivering it [to await the delivery of other packets] and/or service signal generation). 3.1.4.4 Traffic from vehicles or wayside devices received from a base station shall first be processed by the FEP’s RF network Layer 3 protocol (which updates the state variables and eliminates duplicates). The traffic shall then be processed as if it were received on a trunk line. Note that if the FEP is a combined FEP/CC and is connected to BCPs directly (and therefore implements the ARQ protocol), it shall inhibit outbound traffic to RF users when not in the state IN_CONTROL. See the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix R for details. 3.1.4.5 The front end processor shall perform online health monitoring, including monitoring of internal queues, flow control state, and other manufacturer-defined parameters. Problems shall be reported via the alarm mechanism. See the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.2.1.6. ver4.0 K-II–356 3/1/05 3/1/05 S-5820 AAR Manual of Standards and Recommended Practices Railway Electronics Fig. 3.1 ATCS ground network switching nodes 3.2 Characteristics 3.2.1 Performance Characteristics 3.2.1.1 The front end processor shall support communication lines that may be independently configured as trunk (HDLC-balanced) or LAPB-to-ground hosts/terminals. Optionally, these lines may be configured as base station control lines. 3.2.1.2 The front end processor shall be rated in packets per second (a packet in and a packet out = 1 packet switched) on a continuous basis. The front end processor shall be capable of buffering (and queuing) 300 2408-bit packets or 20 times its nominal rated capacity in packets per second, whichever is greater. Note: For the purpose of calculating (benchmarking) switching rate, packets shall be defined as follows: • A packet is either from a mobile address to a stationary address, or vice versa. An equal mixture of these shall be used for benchmarking. • A packet has a facility field length of 0. • A packet contains a transport header indicating it is nonvital. • A packet contains 123 bytes of Layer 7 data. • An “ack only” is not a packet. 3.2.1.3 Manufacturers shall specify the number of lines supported, switching rate, and packet buffering capacity of their product in both the operating instructions and installation guide. 3.2.1.4 Power 13.6 + 20% (EIA), 0.5 Vpp for ripple, 115–130 Vac Commentary: A lower limit of 95 Vac may be required at some sites and is an installation issue. 3.2.2 Physical Characteristics 3.2.2.1 the physical characteristics of the front end processor are not standardized in ATCS, although individual railroad buyers may have unique requirements in this regard. 3/1/05 K-II–357 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5820 3.2.2.2 Manufacturers shall provide detailed data in the installation guide on the physical characteristics of their product, including dimensions, weight, and drawing(s). 3.2.3 Safety The safety of ATCS shall not be compromised by the failure of a front end processor. This is achieved by requiring all trains to stop within a safe area in the event of a data communications failure. The front end processor has an important contribution to make in the area of safety in that it provides one of the links by which emergency and safety-related information may be conveyed among railroad elements. The front end processor shall contain no entity capable of calculating the Layer 4 (vital) CRC, precluding vital traffic from originating in the front end processor. 3.2.3.1 General Safety Principles 3.2.3.1.1 The following general principles deal with the concepts of safety, vitality, and reliability within the Advanced Train Control System project. These general principles are to be used as guidelines and reference points in the definition, development, documentation, testing, certification, and performance of ATCS components and subsystems. These general principles are intended to be both descriptive and prescriptive. They describe the meaning of safety, vitality, and reliability when used in the context of ATCS. They prescribe the use of the terms safety, vitality, and reliability when used in the context of ATCS. 3.2.3.1.2 The safety, vitality, and reliability requirements of ATCS are best understood when taken together. A central objective of ATCS is to ensure safe train movements and track occupancies that avoid physical conflict and other operational hazards of similar magnitude. The elements of ATCS involved in the accomplishment of that central objective are vital, since their individual or collective failure can result in life-threatening and property-damaging accidents. The reliability with which ATCS accomplishes that central objective must be high enough to sustain efficient railroad operations. ver4.0 K-II–358 3/1/05 3/1/05 S-5820 AAR Manual of Standards and Recommended Practices Railway Electronics 3.2.3.1.3 In ATCS, the following apply: Vital Function A function in ATCS that could result in a physical conflict or other operational hazard of similar magnitude if an unsafe failure (including design error) occurs. Vital Those elements related to the organization, issuance, safe execution, and Elements of enforcement of movement authorities. The following are the steps in the ATCS movement authority process: 1. Gather sufficient information to ensure safe operation of the systems. 2. Use logic-based dispatcher decision-making to create movement authorities, which include block, track, and route occupancies, and speeds where applicable, granted to trains, engines, maintenance personnel, and high-rail-equipped personnel. The logic shall ensure that no unsafe movement authority can be issued. 3. Convey and ensure accurate receipt of those movement authorities. 4. Execute and enforce those movement authorities, including overriding the engineer for train braking, when required. Failure of a If a failure of a vital element occurs, no matter what kind of failure, the system Vital Element shall only fail in safe modes. These predicted safe failure modes shall be selected to eliminate the hazardous consequences of a component or system failure. Equipment design must be such that any single, independent component-of-software system failure results in a safe condition. Component-of-software system failures that are not independent, that is, those failures that in turn can cause others, must be considered in combustion as a single failure and must not cause unsafe conditions. Reliability The probability that the system will perform as intended for a specified period of time when used under stated conditions. Reliability is not a substitute for safety design and predicted safe failure modes. The reliability of ATCS vital elements, individual and in sum, must result in a system reliability high enough so as not to impair efficient railroad operations. Commentary: Lightning and surge suppression equipment are an integration issue to be handled during installation. 3.2.4 Environmental The front end processor shall comply with the requirements of ATCS Specification 110 for office equipment. 3.2.5 Reliability The individual railroad shall establish reliability requirements. A design goal should be 5000 operating hours mean time between failures (MTBF). Note: Impairments of less than 60-second duration are not failures. 3.2.6 Maintainability A maintainer shall be able to repair (fault diagnose + fault isolation + remove/replace + performance verification test) the FEP within 60 minutes. The FEP shall contain sufficient built-in test equipment (BITE) or self-diagnostic circuitry to support this requirement. 3.2.7 Availability The FEP shall be designed to provide a high level of functional availability. A design goal should be at least 99.9% availability assuming the time between a failure and the initiation of repairs is 30 minutes. 3/1/05 K-II–359 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5820 3.3 Design and Construction The goal of ATCS is to provide specifications that ensure interoperability, compatibility, safety, reliability, and functionality of components without specifying all of the internal design of those components. Accordingly, the detailed design and construction of the front end processor is not contained in this specification. 3.4 Documentation The following (minimum) documentation shall be provided with each front end processor: • • • • • • Operating instructions, including configuration instructions Installation guide and instructions Basic troubleshooting guide Preventive maintenance guide Warranty information (if applicable) Point of contact at manufacturer for problems (including name, address, telephone number) • The manufacturer shall provide a certificate indicating that the FEP contains no hardware or software to calculate the Layer 4 “vital” redundancy check defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix D. Additional documentation, required if the buyer is to perform maintenance, is listed in the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.4. 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 ATCS Specification 140. ver4.0 K-II–360 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 S-5820 APPENDIX APPENDIX A CHANGE RECORD SHEET FOR S-5820 Revision 4.0 Date of Release 5/02 4.0 5/95 3-3, 3-5 4.0 5/95 All 4.0 5/95 2-1 4.0 5/95 All 4.0 3.0 5/95 3/93 2-1 All 2.1 3/91 3-2, 3-6, 3-7 2.0 0 6/90 12/87 3-2, 3-4, 3-5 All 3/1/05 Affected Pages All Purpose of Change and Applicable SPRs Incorporated specification ATCS 220 into the AAR Manual of Standards and Recommended Practices, Section K-II, as Specification S-5820. Renumbered and reformatted document to meet the requirements of the MSRP Style Guide. SPRs 152–-155— Section 3.1.4 modified description of message routing; included device type 6 when listing mobile devices. SPR 179—checked for any grammatical/typo errors for consistency in specification format (200 “Applicable Documents”). SPR 180—added version numbers to specifications in “Applicable Documents.” SPR 208— checked specification for any references to Specification 150; this spec has been withdrawn. SPR 173—deleted references to obsolete/withdrawn specifications. Correct typos. Clarify and correct self-test requirements and moved health reporting requirements to Specification 200 as per SPRs 135 and 136. Published Revision 3.0. Added power requirements. Moved connector specifications to Specification 200. Added commentary about lightning and surge suppression. Added self-test explanation. Added note about 15-digit address requirements. Added routing and health monitoring requirements. Initial publication K-II–361 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5825 CLUSTER CONTROLLER Specification S-5825 (Formerly ATCS Specification 225) Adopted: 1987; Revised: 1995, 2002 1.0 SCOPE 1.1 This document sets forth the requirements for the Advanced Train Control Systems (ATCS) cluster controller. It identifies the major functions and interfaces. There are companion specifications that describe the architecture of the ATCS, its major subsystems, and each subsystems’ major components. 1.2 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 that they consider to be cost-effective and appropriate. Suppliers and railroads purchasing hardware or software in accordance with this specification are responsible for ensuring that equipment and its application satisfy regulatory and safety requirements. 2.0 APPLICABLE DOCUMENTS The following documents are 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 Considerations • 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 • AAR Manual of Standards and Recommended Practices, Specification 5800, Version 4.0, Communications System Architecture • AAR Manual of Standards and Recommended Practices, Specification 5830, Version 4.0, Base Communications Package • ATCS Specification 250, Version 4.0, Message Formats 3.0 REQUIREMENTS 3.1 System Definition The cluster controller provides the focus of ground network control over the RF network. It is responsible for routing and queuing traffic, ARQ and service signal control, as well as base station health monitoring. 3.1.1 Cluster Controller Elements The cluster controller (CC) shall provide the following major functions: 3.1.1.1 Base Station Management The CC shall manage base stations in terms of directing self tests and health reporting of base stations, obtaining traffic from base stations, and sending traffic to base stations. 3.1.1.2 Vehicle Following and Packet Routing The CC shall route packets to proper base stations or to other CCs, FEP/CCs, or FEPs based on routing tables and vehicle location table as described in the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.1.3.5 and Appendix R. ver4.0 K-II–362 3/1/05 3/1/05 S-5825 AAR Manual of Standards and Recommended Practices Railway Electronics 3.1.1.3 RF Layer 3 Protocol The CC shall implement the RF network Layer 3 protocol, including ARQ mechanism, service signal generation, and queuing. 3.1.1.4 Ground Network Trunks The CC shall implement the Layer 1 and 2 interface to BCPs, FEPs, CCS, and FEP/CCs. 3.1.1.5 Network Time Updates Upon receiving a message (106.4.15) addressed to network address 0RRRNN0002 from an authorized (2RRRNN0001) address, the CC shall begin queuing all traffic on channel groups higher numbered than 3 for a period of 5 seconds. This ensures that the network is quiescent during the time mark. Upon receiving any message addressed to network address 09, the CC shall forward that message to all attached base stations and wireline-connected wayside devices. FEP/CCS shall also forward the message to any attached CCS. 3.1.1.6 Flow Control The CC shall implement flow control at Layer 2 and special flow control recovery procedures as defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix Q. 3.1.1.7 Buffering and Queuing The CC shall implement buffering and prioritized queuing of packets (prioritized queue handling is described in the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.1.3.6). 3.1.1.8 Address Initialization Upon request from an ATCS user to address 0RRRNN0001 (“GINT”), the cluster controller shall forward a table of network addresses to the requestor’s designated recipient “where to send.” Refer to messages 107.1.1 and 107.4.1 in ATCS Specification 250. 3.1.1.9 Configuration The CC shall provide a mechanism for online configuration of its operating parameters and tables (including routing tables for stationary devices, e.g., wayside devices). 3.1.1.10 Failure/Alarm Reporting The CC shall provide a mechanism for online failure/fault/alarm reporting, including either an attached printer or the facility to send messages with alarm information to a remote entity or both. This alarm reporting mechanism is used to report cluster controller status, attached base station status, and communications line status. Refer to the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.2.1.6. 3.1.1.11 Self-Test The CC shall perform a self-test when power is applied. The self-test shall be manufacturer defined but, at a minimum, shall verify CC software integrity (CRC on ROM or EXE file is acceptable), RAM integrity, and communications line availability. Upon completion of the self-test, the CC shall send a QUERY_FOR_SELF_TEST_MSG (4.1.1) to each attached BCP (if any), wait for 30 seconds, and then send a PROVIDE_SELF_TEST_LIST_MSG (4.2.12) to its configured health reporting address containing self-test information for the CC, communications lines, and any attached BCPs. 3.1.1.12 Health Reporting The CC shall perform health reporting in accordance with the requirements specified in the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.2.1.6. 3/1/05 K-II–363 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5825 3.1.2 Cluster Controller Interfaces 3.1.2.1 Mandatory Interfaces 3.1.2.1.1 The cluster controller shall implement the ground side of the datagram-RF network protocol as defined by the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix H. 3.1.2.1.2 The cluster controller shall implement the ATCS/HDLC polled protocol at Layer 2 (master side) to control base stations. This protocol is defined by the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix J. 3.1.2.1.3 The cluster controller shall implement the HDLC balanced procedure to communicate with other CCs, FEPs, and FEP/CCs. This protocol is described in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix K. 3.1.2.1.4 The cluster controller shall implement the procedures defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix R for cooperation in building and maintaining vehicle routing tables. 3.1.2.1.5 The cluster controller shall implement Layer 1 interfaces as described in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix M. Note: All ATCS devices shall be capable of decoding packets with address length from 0–15 BCD digits. 3.1.2.2 Optional Interfaces 3.1.2.2.1 Protocol Adaptors The cluster controller may optionally implement the X.25 virtual circuit interfaces described in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix G, to allow users to access the Cluster Controller via public or private data networks. 3.1.2.2.2 Base Station Management 3.1.2.2.2.1 The cluster controller may optionally connect to “star”-configured BCPs (that are equipped to do so) using the HDLC balanced protocol (vice the ATCS/HDLC polled protocol). Base station test initiation shall be via packets addressed to the base station instead of a Layer 2 command. The packet used to perform this is the DEVICE_RESET_REQUEST_MSG (message number 4.1.6). 3.1.2.2.2.2 The CC shall ensure that each base transmits at least once every 15 seconds. If no other transmission occurs for a 15-second interval, message 107.4.3 shall be used to cause the BCP to transmit the cluster controller identification. The CC shall be capable of sending message 106.4.12 to the BCP(s) to turn off their transmitter(s). Commentary: Individual railroads may require that cluster controllers provide interfaces to both star and multidrop connected base stations. 3.1.2.2.3 Combined Cluster Controller/Front End Processor The cluster controller may be combined with a front end processor into a single device (FEP/CC). This device shall implement all of the cluster controller’s mandatory elements and interfaces plus the optional LAPB Layer 2 protocol to interface to ground hosts or terminals. Fig. 3.1 illustrates the relationship of the FEP, FEP/CC, and CC. 3.1.2.2.4 Optional CC Turn Around 3.1.2.2.4.1 The cluster controller may optionally provide a turn-around mechanism for emergency broadcast traffic to facilitate the use of bufferless bases. The cluster controller would only provide this service to “star”-connected bases. The cluster controller would be required to turn around the packet (end flag in to begin flag out) within 1.0 seconds. The cluster controller would be ver4.0 K-II–364 3/1/05 3/1/05 S-5825 AAR Manual of Standards and Recommended Practices Railway Electronics precluded from flow controlling the bufferless base. Suppliers should notify railroads when implementing this option. Railroads should note that this option adds delay to the emergency broadcast mechanism and may preclude emergency traffic handling during a cluster controller failure. 3.1.2.2.4.2 Bufferless bases shall not be connected to cluster controllers that do not implement this option. 3.1.3 OSI Model The cluster controller’s major functions fall within Layers 1–3 of the OSI model. Higher layers are required for entities in the cluster controller that send and receive traffic (e.g., control, configuration, and hand-off functions). 3.1.4 Cluster Controller Basic Operation 3.1.4.1 At power-up, the cluster controller shall perform a self-test of itself, its connected BCPs, and communications lines and indicate the results to the alarm reporting mechanism. See the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.2.1.6 3.1.4.2 The cluster controller shall process traffic from trunk lines (or optional LAPB lines) to stationary devices with destination address identifiers 0 or 2 as follows: 1. It shall determine if the destination node and railroad (digits 2–6 of the destination address) match this node. 2. If the node did not match, it shall attempt to route the packet to the destination node. If unable to route to the destination node, it shall generate an out-of-order datagram service signal to the originator (and optionally an alarm). Note: There is no Layer 3 handshake on the trunk or optional LAPB lines. 3. If the node in the address matched the cluster controller’s node, the CC shall attempt to route the packet to the destination, and if the destination address is not configured or out-of-order, the CC shall generate an incompatible destination or out-of-order service signal unless the originator's identifier is 1, 3, 4, 5, or 6. Note: Traffic to wayside devices is sent using the Layer 3 RF network protocol. 3.1.4.3 The cluster controller shall process traffic from trunk lines (or optional LAPB lines) to vehicles and/or WIUs as follows. 1. The CC shall determine the controlling node from the vehicle following table (if the destination is 1, 4 or 6) or by a railroad-defined procedure (if the destination identifier is 3 or 5). If the packet is addressed to a vehicle not in the routing/following table, the CC shall attempt to locate the vehicle using procedures defined in Appendix R of ATCS Specification 200. 2. If the node did not match this node (CC), route the packet to the destination node. If unable to route to the destination node, the CC shall generate an out-of-order datagram service signal (and optionally an alarm). 3. If the node matched this cluster controller’s node number, the CC shall route the packet to the appropriate base station. Note: Layer 3 RF network handshaking is required in delivering the packet to the vehicle (this may result in queuing the packet before delivering it and/or service signal generation). 3.1.4.4 Traffic from vehicles or wayside devices received from a BCP shall first be processed by the cluster controller’s RF network Layer 3 protocol (which updates the state variables and eliminates duplicates). The traffic shall then be processed as if it were received on a trunk line. Note that the CC shall inhibit outbound traffic and acks/nacks to RF users when not in the state IN_CONTROL. See the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix R for details. 3/1/05 K-II–365 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5825 3.1.4.5 The cluster controller shall perform online health monitoring, including periodic base station testing, monitoring of internal queues and flow control state, and other manufacturer-defined parameters. Problems shall be reported via the alarm mechanism. Refer to the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.2.1.6. Fig. 3.1 ATCS ground network switching nodes 3.2 Characteristics 3.2.1 Performance Characteristics 3.2.1.1 The cluster controller shall support a minimum of six communication lines that may be independently configured as trunk (HDLC-balanced), base control (ATCS/HDLC polled protocol or HDLC-balanced), or optionally, LAPB-to-ground hosts/terminals. 3.2.1.2 The cluster controller will be rated in packets per second (a packet in and a packet out = 1 packet switched) on a continuous basis. The cluster controller shall be capable of buffering (and queuing) 300 2408-bit packets or 20 times its nominal rated capacity in packets per second, whichever is greater. Note: For the purpose of calculating (benchmarking) switching rate, packets shall be defined as follows: • A packet is either from a mobile address to a stationary address, or vice versa. An equal mixture should be used for benchmarking. • A packet has a facility field length of 0. • A packet contains a transport header indicating it is nonvital. • A packet contains 123 bytes of Layer 7 data. • An “ack only” is not a packet. • A “nack only” is not a packet. 3.2.1.3 Manufacturers shall specify in both the operating instructions and installation guide the number of lines supported, switching rate, and packet buffering capacity of their product. ver4.0 K-II–366 3/1/05 3/1/05 S-5825 AAR Manual of Standards and Recommended Practices Railway Electronics 3.2.1.4 Power 13.6 + 20% (EIA), 0.5 Vpp for ripple, 115–130 Vac Commentary: A lower limit of 95 Vac may be required at some sites and is an installation issue. 3.2.2 Physical Characteristics 3.2.2.1 The physical characteristics of the cluster controller are not standardized in ATCS, although individual railroad buyers may have unique requirements in this regard. 3.2.2.2 Manufacturers shall provide detailed data in the installation guide on the physical characteristics of their product, including dimensions, weight, and drawing(s). 3.2.3 Safety The safety of ATCS shall not be compromised by the failure of a cluster controller. This is achieved by requiring all trains to stop within a safe area in the event of a data communications failure. The cluster controller has an important contribution to make in the area of safety in that it provides one of the links by which emergency and safety-related information may be conveyed among railroad elements. The cluster controller shall contain no entity capable of calculating the Layer 4 (vital) CRC, precluding vital traffic from originating in the cluster controller. 3.2.3.1 General Safety Principles 3.2.3.1.1 The following general principles deal with the concepts of safety, vitality, and reliability within the Advanced Train Control System project. These general principles are to be used as guidelines and reference points in the definition, development, documentation, testing, certification, and performance of ATCS components and subsystems. These general principles are intended to be both descriptive and prescriptive. They describe the meaning of safety, vitality, and reliability when used in the context of ATCS. They prescribe the use of the terms safety, vitality, and reliability when used in the context of ATCS. 3.2.3.1.2 The safety, vitality, and reliability requirements of ATCS are best understood when taken together. A central objective of ATCS is to ensure safe train movements and track occupancies that avoid physical conflict and other operational hazards of similar magnitude. The elements of ATCS involved in the accomplishment of that central objective are vital, since their individual or collective failure can result in life-threatening and property-damaging accidents. The reliability with which ATCS accomplishes that central objective must be high enough to sustain efficient railroad operations. 3/1/05 K-II–367 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5825 3.2.3.1.3 In ATCS, the following apply: Vital Function A function in ATCS that could result in a physical conflict or other operational hazard of similar magnitude if an unsafe failure (including design error) occurs. Vital Those elements related to the organization, issuance, safe execution, and Elements of enforcement of movement authorities. The following are the steps in the ATCS movement authority process: 1. Gather sufficient information to ensure safe operation of the systems. 2. Use logic-based dispatcher decision-making to create movement authorities, which include block, track, and route occupancies, and speeds where applicable, granted to trains, engines, maintenance personnel, and high-rail-equipped personnel. The logic shall ensure that no unsafe movement authority can be issued. 3. Convey and ensure accurate receipt of those movement authorities. 4. Execute and enforce those movement authorities, including overriding the engineer for train braking, when required. Failure of a If a failure of a vital element occurs, no matter what kind of failure, the system Vital Element shall only fail in safe modes. These predicted safe failure modes shall be selected to eliminate the hazardous consequences of a component or system failure. Equipment design must be such that any single, independent component-of-software system failure results in a safe condition. Component-of-software system failures that are not independent, that is, those failures that in turn can cause others, must be considered in combustion as a single failure and must not cause unsafe conditions. Reliability The probability that the system will perform as intended for a specified period of time when used under stated conditions. Reliability is not a substitute for safety design and predicted safe failure modes. The reliability of ATCS vital elements, individual and in sum, must result in a system reliability high enough so as not to impair efficient railroad operations. Commentary: Lightning and surge suppression equipment are an integration issue to be handled during installation. 3.2.4 Environmental The cluster controller shall comply with the requirements of ATCS Specification 110 for office equipment. 3.2.5 Reliability The individual railroad shall establish reliability requirements. A design goal should be 5000 operating hours mean time between failures (MTBF). Note: Impairments of less than 60-second duration are not failures. 3.2.6 Maintainability A maintainer shall be able to repair (fault diagnose + fault isolation + remove/replace + performance verification test) the CC within 60 minutes. The CC shall contain sufficient built-in test equipment (BITE) or self-diagnostic circuitry to support this requirement. 3.2.7 Availability The CC shall be designed to provide a high level of functional availability. A design goal should be at least 99.9% availability assuming the time between a failure and the initiation of repairs is 30 minutes. ver4.0 K-II–368 3/1/05 3/1/05 S-5825 AAR Manual of Standards and Recommended Practices Railway Electronics 3.3 Design and Construction The goal of ATCS is to provide specifications that ensure interoperability, compatibility, safety, reliability, and functionality of components without specifying all of the internal design of those components. Accordingly, the detailed design and construction of the cluster controller is not contained in this specification. 3.4 Documentation The following (minimum) documentation shall be provided with each cluster controller: • • • • • • Operating instructions, including configuration instructions Installation guide and instructions Basic troubleshooting guide Preventive maintenance guide Warranty information (if applicable) Point of contact at manufacturer for problems (including name, address, telephone number). • The manufacturer shall provide a certificate indicating that the CC contains no hardware or software to calculate the Layer 4 “vital” redundancy check defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix D. Additional documentation, required if the buyer is to perform maintenance, is listed in the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.4. 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 ATCS Specification 140. 3/1/05 K-II–369 ver4.0 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 APPENDIX A S-5825 APPENDIX A CHANGE RECORD SHEET FOR S-5825 Revision 4.0 Date of Release 5/02 All 4.0 5/95 3-5 4.0 5/95 All 4.0 5/95 2-1 4.0 5/95 2-1 3.0 3/93 All 2.1 3/91 3-2, 3-6 2.0 1.0 6/90 2/89 3-2, 3-3, 3-5, 3-6 3-3, 3-5, 3-6 0 12/87 All ver4.0 Affected Pages Purpose of Change and Applicable SPRs Incorporated specification ATCS 225 into the AAR Manual of Standards and Recommended Practices, Section K-II, as Specification S-5825. Renumbered and reformatted document to meet the requirements of the MSRP Style Guide. SPRs 152–15—Section 3.1.4—modified description of message routing, included device type 6 when listing mobile devices. SPR 179—checked for any grammatical/typo errors for consistency in specification format (200 series specifications did not have lead-in paragraph in section 2.0 “Applicable Documents”). SPR 180—added version numbers to specifications in “Applicable Documents.” SPR 173—deleted references to obsolete/withdrawn specifications (Test Plan 225). Corrected typos. Clarified and corrected self-test requirements and moved health reporting requirements to Specification 200 as per SPRs 135 and 136. Published Revision 3.0. Added power requirements. Moved connector specifications to Specification 200. Added commentary about lightning and surge suppression. Added self-test explanation. Added note about 15-digit address requirements. Added routing and health monitoring requirements. Changed definition of cluster controller's technique for ensuring base transmits every 15 seconds. Clarified packet switching rate with regard to proposed NACK only packet. Initial publication K-II–370 3/1/05 3/1/05 S-5830 AAR Manual of Standards and Recommended Practices Railway Electronics BASE COMMUNICATIONS PACKAGE Specification S-5830 (Formerly ATCS Specification 230) Adopted: 1987; Revised: 1995, 2002 1.0 SCOPE 1.1 This document sets forth the requirements for the Advanced Train Control Systems (ATCS) base communications package (BCP). It identifies the major functions, external interfaces, and performance requirements for the BCP. There are companion specifications that describe the architecture of the ATCS communications system and the requirements for the other system components. 1.2 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 that they consider to be cost-effective and appropriate. Suppliers and railroads purchasing hardware or software in accordance with this specification are responsible for ensuring that equipment and its application satisfy regulatory and safety requirements. 2.0 APPLICABLE DOCUMENTS The following documents are 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 Considerations • 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 • AAR Manual of Standards and Recommended Practices, Specification 5800, Version 4.0, Communications System Architecture • AAR Manual of Standards and Recommended Practices, Specification 5830, Version 4.0, Base Communications Package • ATCS Specification 250, Version 4.0, Message Formats 3.0 REQUIREMENTS 3.1 BCP Definition 3.1.1 BCP Elements The BCP shall provide the following major functions: 3.1.1.1 Base Station Radio The BCP shall contain a base station radio that shall provide access to ATCS radio network. 3.1.1.2 Wireline Interface The BCP shall implement protocol(s) to pass traffic to/from cluster controller (CC) or combined cluster controller and front end processor (FEP/CC) as defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendices J and K. 3.1.1.3 Local Routing The BCP shall route packets over multiple radios (if connected) according to link layer address, shall route traffic to BCP control software, and shall relay emergency broadcast traffic received on 3/1/05 K-II–371 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5830 the inbound radio channel(s) onto each connected outbound radio channel. Commentary: The term inbound refers to traffic on the radio channel being received by a base station; outbound refers to traffic on the radio channel transmitted by the base station. 3.1.1.4 Radio Interface The BCP shall provide framing, forward error correction encoding/decoding, and link layer addressing and address recognition. 3.1.1.5 Self-Test The BCP shall perform a self-test when power is initially applied and upon request. The self-test sequence is manufacturer defined, but at a minimum shall verify BCP software integrity (CRC on ROM is acceptable), RAM integrity, and that the radio is operational. Receipt of a DEVICE_RESET_REQUEST_MSG (4.1.6) shall cause the BCP to perform a hardware reset, conduct a self test, and report the self-test results. Receipt of a QUERY_FOR_SELF_TEST_MSG (4.1.1) shall cause the BCP to report the results of the most recent self-test to the cluster controller's GHEL application (address 0RRRNN0004). The SELF_TEST_RESULTS_MSG (4.2.1) shall be used to report self-test results. Refer to the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.2.1.6 for details. 3.1.1.6 Health Reporting The BCP shall perform health reporting in accordance with the requirements specified in Refer to the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.2.1.6. 3.1.1.7 Buffering and Queuing BCP shall buffer traffic in prioritized queues, both inbound and outbound. Note: In “star”-configurations, buffering may be required only while the base is performing an emergency broadcast relay function or may be eliminated entirely if the CC turn-around option is selected. A bufferless BCP shall not be connected to a CC that does not support the turn-around option. 3.1.1.8 Signal Quality The BCP shall monitor the analog received signal quality/strength over the course of packets received on the radio and provide an average value at the end of the packet in the range (0–255), which is appended to the end of the packet before it is sent to the cluster controller. The value to be appended shall be calculated according to the following table: Table 3.1 Average signal quality Value 0 1 2 3 4 5–58 59 60 61 62–254 255 ver4.0 Meaning Not used –120 dBm –120 dBm –119 dBm –118 dBm –117 dBm –116 to–63 dBm in 1-dbm increments –62 dBm –61 dBm and higher signal strengths Not used Wireline connection K-II–372 3/1/05 3/1/05 S-5830 AAR Manual of Standards and Recommended Practices Railway Electronics 3.1.1.9 Receive Channel Health Monitoring The BCP shall send an alarm message to its diagnostic address when it detects a carrier with no data for more than 1.5 seconds. The label for this message is 4.2.3 (malfunction report). The diagnostic address is 0RRRNN0004 (“GHEL”). Refer to the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.2.1.6, for details. 3.1.1.10 Bufferless Option Where the BCP and the cluster controller are manufactured by the same supplier, and the railroad does not require compatibility with other supplier’s cluster controllers or BCPs, the following option may be implemented: • Eliminate all base station buffering. • Implement a CC turn around in the cluster controller so that an emergency broadcast message received by the base station is sent to the cluster controller and looped back to the base for retransmission. • The following special performance requirements and limitations apply to this option: • Only point-to-point (balanced) mode of HDLC shall be used between cluster controller and base. • Cluster controller shall not flow control base (inhibiting emergency function). • Cluster controller shall turn around all emergency broadcast packets (ending flag in to beginning flag out) within 1.0 second. • Supplier shall in all cases notify the buying railroad that this option is being implemented. • Buying railroad should note that this option adds delay to the emergency broadcast traffic and may preclude emergency traffic handling during a cluster controller failure. 3.1.2 BCP Interfaces The base station shall operate on the channels as defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix N. It shall meet all applicable FCC or DOC requirements. This will normally include type certification. 3.1.2.1 RF Signals and Radio Operations 3.1.2.1.1 The BCP is a full duplex device operating on a pair of ATCS radio channels at 4800 bits per second ±100 ppm. The method of modulation is baseband filtered frequency shift keying. The Gaussian filter has BT (bandwidth time) = 0.5, and the deviation is 1.7 KHz. The radio shall meet all FCC/DOC stability requirements over the temperature range specified in ATCS Specification 110. The radio shall not employ pre-emphasis/de-emphasis circuitry. A shift upward in carrier frequency equates to a logic “0” and a shift downward equates to a logical “1.” 3.1.2.1.2 The BCP transmitter and receiver shall be capable of sustaining a nominal 100% duty cycle. The BCP shall provide an indication of receive carrier status using the busy bit protocol as defined in AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendices L and P. Other characteristics of the signal in space format (forward error correcting code, frame format, synchronization, etc.) are included in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendices L and N. 3.1.2.2 BCP-to-Cluster-Controller Interface 3.1.2.2.1 The BCP-to-cluster-controller interface shall be either the ATCS/HDLC polled protocol as defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendices J (Layer 2) and M (Layer 1) or the HDLC balanced mode as described in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendices K (Layer 2) and M (Layer 1). Note: If the point-to-point (balanced mode) interface is used, the XID procedure is not used. 3/1/05 K-II–373 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5830 3.1.2.2.2 Connectors The BCP-to-antenna connectors shall be type “N” female (50 ohms). The base power connector shall be a standard three-prong grounded plug if the 120 Vac power supply is used. If the DC power supply option is selected, the connector shall be railroad defined. Note: All ATCS devices shall be capable of decoding packets with address lengths from 0–15 BCD digits. 3.1.2.3 Mode Selection The BCP shall be capable of operating its transmitter in a continuous (always on) mode or in an as-needed mode (turns on when an outbound message is available). The method of mode selection shall be manufacturer defined. When in the continuous mode, the BCP shall turn off its transmitter upon receiving a message with label 106.4.12 directed to its Layer 3 address. The transmitter shall be turned back on upon receipt of the next outbound message from the ground network (and the BCP shall reenter its configured mode). Commentary: Manufacturer may define this configuration to be done manually at the site or may define manufacturer-specific message(s) for this purpose. 3.1.3 OSI Model 3.1.3.1 The base communications package’s major functions fall within Layers 1–-3 of the OSI model. Higher layers are required for entities in the BCP that send and receive traffic (e.g., self test). 3.1.3.2 The BCP must provide the Layer 3 automatic repeat request mechanism defined for the MCP in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendices H and P for the purpose of correctly processing normal mode message packets between the BCP and the ground network or host-based applications. This includes the generation of ack and nack packets to the cluster controller, as well as service signal generation to its internal user Layer 3 entity. 3.2 Characteristics 3.2.1 Performance 3.2.1.1 The base communications package shall be capable of buffering at least fifteen 2408-bit packets (unless CC turn-around option is selected). 3.2.1.2 The forward error correction encoding and decoding shall be fast enough to simultaneously process a continuous stream of received frames, and process, encode, and send a continuous stream of send frames. The BCP shall implement the FEC coding/decoding as described above while performing all activities (except self-test) related to routing packets and the Layer 2 protocol to the cluster controller. ver4.0 K-II–374 3/1/05 3/1/05 S-5830 AAR Manual of Standards and Recommended Practices Railway Electronics 3.2.1.3 The BCP shall meet all stability requirements set forth by the FCC/DOC over the temperature range specified in ATCS Specification 110. Turn on Time Less than 10 ms (measured from the time the BCP computer requests the radio to turn on the transmitter until 90%–120% of nominal carrier power is available and the BCP computer is notified). Turn off Time Less than 15 ms (measured from the time the BCP computer ceases to request the transmitter until carrier output power drops to 1% of nominal). Receiver 1% BER at worst case frequency offset at a signal level of –112 dBm without use Sensitivity of the FEC decoder. Bit The receiver shall be capable of maintaining bit synchronization through a series Synchronization of up to 80 contiguous bits with the same logical value (80 logical 1s or 80 logical 0s). Carrier Detect BCP will detect and turn on busy bits within 5 ms of receiving a usable signal Time level. Note: There are cases (sync pattern) when a busy bit is not present within 5 ms; in these cases the next busy bit sent should be on. Power 115–130 Vac (50–65 Hz). Optionally 24 or 48 Vdc ± 20% with positive ground. Commentary: A lower limit of 95 Vac may be required at some sites and is an installation issue. 3.2.2 Physical Characteristics The BCP shall be mounted in a standard 19-in. rack. The power connector is a standard three-prong grounded plug unless the dc option is selected (the connector is then railroad specified). 3.2.3 Safety The safety in ATCS is a system issue achieved through the interdependence of hardware, software, and the human element. The failure of the base station controller will not in and of itself create an unsafe condition, because voice radio provides a communications backup, and the trains will not be allowed to exceed their limits of authority in the absence of communications. The BCP is important to safety, however, in that it provides one of the media by which safety-related information is passed between the vehicles/wayside devices and the rest of the railroad. The BCP shall contain no entity that is capable of calculating the Layer (vital) CRC, precluding the origination of vital traffic within the BCP. 3.2.3.1 General Safety Principles 3.2.3.1.1 The following general principles deal with the concepts of safety, vitality, and reliability within the Advanced Train Control System project. These general principles are to be used as guidelines and reference points in the definition, development, documentation, testing, certification, and performance of ATCS components and subsystems. These general principles are intended to be both descriptive and prescriptive. They describe the meaning of safety, vitality, and reliability when used in the context of ATCS. They prescribe the use of the terms safety, vitality, and reliability when used in the context of ATCS. 3.2.3.1.2 The safety, vitality, and reliability requirements of ATCS are best understood when taken together. A central objective of ATCS is to ensure safe train movements and track occupancies that avoid physical conflict and other operational hazards of similar magnitude. The elements of ATCS involved in the accomplishment of that central objective are vital, since their individual or collective failure can result in life-threatening and property-damaging accidents. The reliability with which ATCS accomplishes that central objective must be high enough to sustain efficient railroad operations. 3/1/05 K-II–375 ver4.0 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics S-5830 3.2.3.1.3 In ATCS, the following apply: Vital Function A function in ATCS that could result in a physical conflict or other operational hazard of similar magnitude if an unsafe failure (including design error) occurs. Vital Those elements related to the organization, issuance, safe execution, and Elements of enforcement of movement authorities. The following are the steps in the ATCS movement authority process: 1. Gather sufficient information to ensure safe operation of the systems. 2. Use logic-based dispatcher decision-making to create movement authorities, which include block, track, and route occupancies, and speeds where applicable, granted to trains, engines, maintenance personnel, and high-rail-equipped personnel. The logic shall ensure that no unsafe movement authority can be issued. 3. Convey and ensure accurate receipt of those movement authorities. 4. Execute and enforce those movement authorities, including overriding the engineer for train braking, when required. Failure of a If a failure of a vital element occurs, no matter what kind of failure, the system Vital Element shall only fail in safe modes. These predicted safe failure modes shall be selected to eliminate the hazardous consequences of a component or system failure. Equipment design must be such that any single, independent component-of-software system failure results in a safe condition. Component-of-software system failures that are not independent, that is, those failures that in turn can cause others, must be considered in combustion as a single failure and must not cause unsafe conditions. Reliability The probability that the system will perform as intended for a specified period of time when used under stated conditions. Reliability is not a substitute for safety design and predicted safe failure modes. The reliability of ATCS vital elements, individual and in sum, must result in a system reliability high enough so as not to impair efficient railroad operations. Commentary: Lightning and surge suppression equipment are an integration issue to be handled during installation. 3.2.4 Environmental The base station radio will comply with the requirements of ATCS Specification 110 for wayside equipment. 3.2.5 Reliability The individual railroad shall establish reliability requirements. A design goal should be 2500 operating hours mean time between failures (MTBF). 3.2.6 Maintainability A maintainer shall be able to repair (fault diagnose + fault isolation + remove/replace + performance verification test) the BCP within 30 minutes. The BCP shall contain sufficient built-in test equipment (BITE) or self-diagnostic circuitry to support this requirement. 3.2.7 Availability The BCP shall be designed to provide a high level of functional availability. A design goal should be at least 99.9% availability assuming the time between a failure and the initiation of repairs is 30 minutes. ver4.0 K-II–376 3/1/05 3/1/05 S-5830 AAR Manual of Standards and Recommended Practices Railway Electronics 3.3 Design and Construction The goal of ATCS is to provide specifications that ensure interoperability, compatibility, safety, reliability, and functionality of components without specifying all of the details of the design of those components. Accordingly, the detailed design and construction of the BCP is not contained in this specification. 3.4 Documentation The following (minimum) documentation shall be provided by the manufacturer of the base station radio: • • • • • • Operating instructions Installation guide and instructions Basic troubleshooting guide Preventive maintenance guide Warranty information (if applicable) Point of contact of manufacturer for problems (including name, address, and telephone number) • Proof of FCC/DOC certification • The manufacturer shall provide a certificate indicating that the BCP contains no hardware or software to calculate the Layer 4 vital redundancy check defined in the AAR Manual of Standards and Recommended Practices, Specification S-5800, Appendix D. • The manufacturer shall provide specific descriptions of test points and test steps to verify bit synchronization; turn on, turn off, and carrier detect times; and receiver sensitivity. These steps shall be able to be performed using off-the-shelf test equipment. Test points are not required to be accessible without removing the equipment cover. Additional documentation, required if the buyer is to perform maintenance, is listed in the AAR Manual of Standards and Recommended Practices, Specification S-5800, paragraph 3.4. 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 ATCS Specification 140. 3/1/05 K-II–377 ver4.0 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 APPENDIX A S-5830 APPENDIX A CHANGE RECORD SHEET FOR S-5830 Revision 4.0 Date of Release 5/02 All 4.0 5/95 All 4.0 5/95 2-1 4.0 5/95 3-4 4.0 5/95 2-1 3.0 3/93 All 2.1 3/91 3-1, 3-3, 3-5, 3-7 2.0 1.0 0 6/90 2/89 12/87 3-1, 3-2, 3-3 All All ver4.0 Affected Pages Purpose of Change and Applicable SPRs Incorporated specification ATCS 230 into the AAR Manual of Standards and Recommended Practices, Section K-II, as Specification S-5830. Renumbered and reformatted document to meet the requirements of the MSRP Style Guide. SPR 179—checked for any grammatical/typo errors for consistency in specification format (200 series specifications did not have lead-in paragraph in section 2.0 “Applicable Documents”). SPR 180—added version numbers to specifications in “Applicable Documents.” SPR 143—Section 3.1.—added paragraph in OSI model regarding base station protocol layer. SPR 173—deleted references to obsolete/withdrawn specifications (Test Plan 230). Corrected typos. Clarified and corrected self-test requirements and moved health reporting requirements to Specification 200 as per SPRs 135 and 136. Published Revision 3.0. Added commentary about power requirements. Added commentary about lightning and surge suppression requirements. Clarified self-test requirements. Added note about 15-digit address requirements. Clarified health monitoring requirements. Added signal strength table. Published Revision 1.0 Initial publication K-II–378 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 APPENDIX A Appendix A APPENDIX A REVISED PAGE DATES Shown below are the current dates applicable to each page of Section K-II of the AAR Manual of Standards and Recommended Practices. The printed page date is shown in either the lower left or lower right-hand corner of the page. In the event a new specification, standard, or recommended practice does not include an effective date, the printed page date will constitute the effective date. Page Numbers Page Numbers Front Front Reverse Reverse Copyright—3/1/05 K-II–73—3/1/05 K-II–74—3/1/05 K-II–i—3/1/05 K-II–ii—3/1/05 K-II–75—3/1/05 Appendix M K-II–76—3/1/05 Appendix N K-II–iii—3/1/05 K-II–iv—3/1/05 K-II–77—3/1/05 Appendix O K-II–78—3/1/05 K-II–v—3/1/05 K-II–vi—3/1/05 K-II–79—3/1/05 Appendix P K-II–80—3/1/05 Specification S-5800 K-II–81—3/1/05 K-II–82—3/1/05 K-II–1—3/1/05 K-II–2—3/1/05 K-II–83—3/1/05 K-II–84—3/1/05 K-II–3—3/1/05 K-II–4—3/1/05 K-II–85—3/1/05 K-II–86—3/1/05 K-II–5—3/1/05 K-II–6—3/1/05 K-II–87—3/1/05 K-II–88—3/1/05 K-II–8—3/1/05 K-II–89—3/1/05 K-II–90—3/1/05 K-II–9—3/1/05 K-II–10—3/1/05 K-II–91—3/1/05 K-II–92—3/1/05 K-II–11—3/1/05 K-II–12—3/1/05 K-II–93—3/1/05 K-II–94—3/1/05 K-II–13—3/1/05 K-II–14—3/1/05 K-II–95—3/1/05 K-II–96—3/1/05 K-II–16—3/1/05 K-II–97—3/1/05 K-II–98—3/1/05 K-II–17—3/1/05 K-II–18—3/1/05 K-II–99—3/1/05 K-II–100—3/1/05 K-II–19—3/1/05 K-II–20—3/1/05 K-II–101—3/1/05 K-II–102—3/1/05 K-II–21—3/1/05 K-II–22—3/1/05 K-II–103—3/1/05 K-II–104—3/1/05 K-II–24—3/1/05 K-II–105—3/1/05 K-II–106—3/1/05 K-II–25—3/1/05 K-II–26—3/1/05 K-II–107—3/1/05 K-II–108—3/1/05 K-II–27—3/1/05 Appendix A K-II–28—3/1/05 Appendix B K-II–109—3/1/05 K-II–110—3/1/05 K-II–29—3/1/05 K-II–30—3/1/05 K-II–111—3/1/05 K-II–112—3/1/05 K-II–31—3/1/05 K-II–32—3/1/05 K-II–113—3/1/05 K-II–114—3/1/05 K-II–33—3/1/05 K-II–34—3/1/05 K-II–115—3/1/05 K-II–116—3/1/05 K-II–35—3/1/05 K-II–36—3/1/05 Appendix C K-II–117—3/1/05 K-II–118—3/1/05 K-II–37—3/1/05 K-II–38—3/1/05 K-II–119—3/1/05 K-II–120—3/1/05 K-II–39—3/1/05 K-II–40—3/1/05 K-II–121—3/1/05 K-II–122—3/1/05 K-II–41—3/1/05 K-II–42—3/1/05 K-II–123—3/1/05 K-II–124—3/1/05 K-II–43—3/1/05 K-II–44—3/1/05 K-II–125—3/1/05 K-II–126—3/1/05 K-II–45—3/1/05 K-II–46—3/1/05 K-II–127—3/1/05 K-II–128—3/1/05 K-II–48—3/1/05 Appendix D K-II–129—3/1/05 K-II–130—3/1/05 K-II–49—3/1/05 Appendix E K-II–50—3/1/05 Appendix F K-II–131—3/1/05 K-II–132—3/1/05 K-II–51—3/1/05 K-II–52—3/1/05 K-II–133—3/1/05 K-II–134—3/1/05 K-II–53—3/1/05 K-II–54—3/1/05 K-II–135—3/1/05 K-II–136—3/1/05 K-II–56—3/1/05 Appendix H K-II–137—3/1/05 K-II–138—3/1/05 K-II–57—3/1/05 K-II–58—3/1/05 K-II–139—3/1/05 K-II–140—3/1/05 K-II–59—3/1/05 K-II–60—3/1/05 K-II–141—3/1/05 K-II–142—3/1/05 K-II–61—3/1/05 K-II–62—3/1/05 K-II–143—3/1/05 K-II–144—3/1/05 K-II–64—3/1/05 Appendix I K-II–145—3/1/05 K-II–146—3/1/05 K-II–65—3/1/05 Appendix J K-II–66—3/1/05 K-II–147—3/1/05 K-II–148—3/1/05 K-II–67—3/1/05 Appendix K K-II–68—3/1/05 K-II–149—3/1/05 K-II–150—3/1/05 K-II–69—3/1/05 K-II–70—3/1/05 Appendix L K-II–151—3/1/05 K-II–152—3/1/05 K-II–72—3/1/05 K-II–153—3/1/05 K-II–154—3/1/05 Cover—3/1/05 K-II–7—3/1/05 K-II–15—3/1/05 K-II–23—3/1/05 K-II–47—3/1/05 K-II–55—3/1/05 Appendix G K-II–63—3/1/05 K-II–71—3/1/05 3/1/05 K-II–379 3/1/05 APPENDIX A AAR Manual of Standards and Recommended Practices Railway Electronics Page Numbers Front Page Numbers Reverse Front Reverse K-II–155—3/1/05 K-II–156—3/1/05 K-II–251—3/1/05 K-II–252—3/1/05 K-II–157—3/1/05 K-II–158—3/1/05 K-II–253—3/1/05 K-II–254—3/1/05 K-II–159—3/1/05 K-II–160—3/1/05 K-II–255—3/1/05 K-II–256—3/1/05 K-II–161—3/1/05 K-II–162—3/1/05 K-II–257—3/1/05 K-II–258—3/1/05 K-II–163—3/1/05 K-II–164—3/1/05 K-II–259—3/1/05 K-II–260—3/1/05 K-II–165—3/1/05 K-II–166—3/1/05 K-II–261—3/1/05 K-II–262—3/1/05 K-II–167—3/1/05 K-II–168—3/1/05 K-II–263—3/1/05 K-II–264—3/1/05 Appendix Q K-II–169—3/1/05 K-II–170—3/1/05 K-II–265—3/1/05 Appendix R K-II–266—3/1/05 K-II–171—3/1/05 K-II–172—3/1/05 K-II–267—3/1/05 K-II–268—3/1/05 K-II–173—3/1/05 K-II–174—3/1/05 K-II–269—3/1/05 K-II–270—3/1/05 K-II–175—3/1/05 K-II–176—3/1/05 K-II–271—3/1/05 K-II–272—3/1/05 K-II–177—3/1/05 K-II–178—3/1/05 K-II–273—3/1/05 K-II–274—3/1/05 K-II–179—3/1/05 K-II–180—3/1/05 K-II–275—3/1/05 K-II–276—3/1/05 K-II–181—3/1/05 K-II–182—3/1/05 K-II–277—3/1/05 K-II–278—3/1/05 K-II–183—3/1/05 K-II–184—3/1/05 K-II–279—3/1/05 K-II–280—3/1/05 K-II–185—3/1/05 K-II–186—3/1/05 K-II–281—3/1/05 K-II–282—3/1/05 K-II–187—3/1/05 K-II–188—3/1/05 K-II–283—3/1/05 K-II–284—3/1/05 K-II–189—3/1/05 K-II–190—3/1/05 K-II–285—3/1/05 K-II–286—3/1/05 K-II–191—3/1/05 K-II–192—3/1/05 K-II–287—3/1/05 K-II–288—3/1/05 K-II–193—3/1/05 K-II–194—3/1/05 K-II–289—3/1/05 K-II–290—3/1/05 K-II–195—3/1/05 K-II–196—3/1/05 K-II–291—3/1/05 K-II–292—3/1/05 K-II–197—3/1/05 K-II–198—3/1/05 K-II–293—3/1/05 K-II–294—3/1/05 K-II–199—3/1/05 K-II–200—3/1/05 K-II–295—3/1/05 Appendix S K-II–296—3/1/05 Appendix T K-II–201—3/1/05 K-II–202—3/1/05 K-II–297—3/1/05 K-II–298—3/1/05 K-II–203—3/1/05 K-II–204—3/1/05 K-II–299—3/1/05 K-II–300—3/1/05 K-II–205—3/1/05 K-II–206—3/1/05 K-II–301—3/1/05 K-II–303—3/1/05 Appendix U K-II–207—3/1/05 K-II–208—3/1/05 K-II–304—3/1/05 Appendix V K-II–305—3/1/05 K-II–209—3/1/05 K-II–210—3/1/05 K-II–306—3/1/05 K-II–307—3/1/05 K-II–211—3/1/05 K-II–212—3/1/05 K-II–308—3/1/05 K-II–309—3/1/05 K-II–213—3/1/05 K-II–214—3/1/05 K-II–310—3/1/05 K-II–311—3/1/05 K-II–215—3/1/05 K-II–216—3/1/05 K-II–312—3/1/05 Appendix W K-II–313—3/1/05 K-II–217—3/1/05 K-II–218—3/1/05 K-II–314—3/1/05 K-II–315—3/1/05 K-II–219—3/1/05 K-II–220—3/1/05 K-II–316—3/1/05 Appendix X K-II–317—3/1/05 K-II–221—3/1/05 K-II–222—3/1/05 K-II–318—3/1/05 K-II–319—3/1/05 K-II–223—3/1/05 K-II–224—3/1/05 K-II–320—3/1/05 K-II–321—3/1/05 Appendix Y K-II–225—3/1/05 K-II–226—3/1/05 K-II–322—3/1/05 K-II–323—3/1/05 K-II–227—3/1/05 K-II–228—3/1/05 K-II–324—3/1/05 K-II–325—3/1/05 K-II–229—3/1/05 K-II–230—3/1/05 K-II–326—3/1/05 K-II–327—3/1/05 Appendix Z K-II–231—3/1/05 K-II–232—3/1/05 K-II–328—3/1/05 K-II–329—3/1/05 K-II–233—3/1/05 K-II–234—3/1/05 K-II–330—3/1/05 K-II–331—3/1/05 K-II–235—3/1/05 K-II–236—3/1/05 K-II–332—3/1/05 Appendix AA K-II–333—3/1/05 K-II–237—3/1/05 K-II–238—3/1/05 K-II–334—3/1/05 K-II–335—3/1/05 K-II–239—3/1/05 K-II–240—3/1/05 K-II–336—3/1/05 Appendix AB K-II–337—3/1/05 K-II–241—3/1/05 K-II–242—3/1/05 K-II–338—3/1/05 K-II–339—3/1/05 K-II–243—3/1/05 K-II–244—3/1/05 K-II–340—3/1/05 K-II–245—3/1/05 K-II–246—3/1/05 Specification S-5810 K-II–247—3/1/05 K-II–248—3/1/05 K-II–249—3/1/05 K-II–250—3/1/05 K-II–341—3/1/05 K-II–342—3/1/05 K-II–380 K-II–343—3/1/05 3/1/05 AAR Manual of Standards and Recommended Practices Railway Electronics 3/1/05 Page Numbers Front Reverse K-II–344—3/1/05 K-II–345—3/1/05 K-II–346—3/1/05 K-II–347—3/1/05 K-II–348—3/1/05 K-II–349—3/1/05 K-II–350—3/1/05 K-II–351—3/1/05 K-II–352—3/1/05 Specification S-5820 K-II–353—3/1/05 K-II–354—3/1/05 K-II–355—3/1/05 K-II–356—3/1/05 K-II–357—3/1/05 K-II–358—3/1/05 K-II–359—3/1/05 K-II–360—3/1/05 K-II–361—3/1/05 Specification S-5825 K-II–362—3/1/05 K-II–363—3/1/05 K-II–364—3/1/05 K-II–365—3/1/05 K-II–366—3/1/05 K-II–367—3/1/05 K-II–368—3/1/05 K-II–369—3/1/05 K-II–370—3/1/05 Specification S-5830 K-II–371—3/1/05 K-II–372—3/1/05 K-II–373—3/1/05 K-II–374—3/1/05 K-II–375—3/1/05 K-II–376—3/1/05 K-II–377—3/1/05 K-II–378—3/1/05 K-II–379—3/1/05 K-II–380—3/1/05 K-II–381—3/1/05 K-II–382—3/1/05 3/1/05 K-II–381 APPENDIX A 3/1/05 APPENDIX A AAR Manual of Standards and Recommended Practices Railway Electronics THIS PAGE LEFT BLANK INTENTIONALLY K-II–382 3/1/05
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.4 Linearized : Yes Encryption : Standard V1.2 (40-bit) User Access : Print, Fill forms, Extract, Assemble, Print high-res Modify Date : 2005:02:22 17:04:15-07:00 Create Date : 2005:01:28 09:34:22Z Subject : Railway Electronics Keywords : Advanced, Train, Control, Systems, ACTS, AEI Page Count : 390 Creation Date : 2005:01:28 09:34:22Z Mod Date : 2005:02:22 17:04:15-07:00 Producer : Acrobat Distiller 5.0.5 (Windows) Author : TTCI Technical Standards Publications Metadata Date : 2005:02:22 17:04:15-07:00 Creator : TTCI Technical Standards Publications Title : MSRP-K-II manual Description : Railway Electronics Page Mode : UseOutlines Has XFA : No Page Layout : OneColumnEXIF Metadata provided by EXIF.tools