1、IEEE Std 1570-2002IEEE Standards1570TMIEEE Standard for the InterfaceBetween the Rail Subsystem and theHighway Subsystem at a HighwayRail IntersectionPublished by The Institute of Electrical and Electronics Engineers, Inc.3 Park Avenue, New York, NY 10016-5997, USA18 October 2002IEEE Vehicular Techn
2、ology SocietySponsored by theRail Transit Vehicle Interface Standards CommitteeIEEE StandardsPrint: SH95022PDF: SS95022The Institute of Electrical and Electronics Engineers, Inc.3 Park Avenue, New York, NY 10016-5997, USACopyright 2002 by the Institute of Electrical and Electronics Engineers, Inc.Al
3、l rights reserved. Published 18 October 2002. Printed in the United States of America.Print: ISBN 0-7381-3367-1 SH95022PDF: ISBN 0-7381-3368-X SS95022No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the
4、 publisher.IEEE Std 1570-2002 (R2008)IEEE Standard for the Interface Between the Rail Subsystem and the Highway Subsystem at a Highway Rail IntersectionSponsorRail Transit Vehicle Interface Standards Committeeof theIEEE Vehicular Technology SocietyReaffirmed 10 December 2008Approved 11 September 200
5、2IEEE-SA Standards BoardAbstract: The logical and physical interfaces and the performance attributes for the interface be-tween the rail subsystem and the highway subsystem at a highway rail intersection are defined inthis standard.Keywords: highway rail grade crossing, highway rail intersectionIEEE
6、 Standardsdocuments are developed within the IEEE Societies and the Standards Coordinating Committees of theIEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards through a consensus develop-ment process, approved by the American National Standards Institute, which bri
7、ngs together volunteers representing variedviewpoints and interests to achieve the nal product. Volunteers are not necessarily members of the Institute and serve with-out compensation. While the IEEE administers the process and establishes rules to promote fairness in the consensus devel-opment proc
8、ess, the IEEE does not independently evaluate, test, or verify the accuracy of any of the information containedin its standards.Use of an IEEE Standard is wholly voluntary. The IEEE disclaims liability for any personal injury, property or other dam-age, of any nature whatsoever, whether special, ind
9、irect, consequential, or compensatory, directly or indirectly resultingfrom the publication, use of, or reliance upon this, or any other IEEE Standard document.The IEEE does not warrant or represent the accuracy or content of the material contained herein, and expressly disclaimsany express or impli
10、ed warranty, including any implied warranty of merchantability or tness for a specic purpose, or thatthe use of the material contained herein is free from patent infringement. IEEE Standards documents are supplied “AS IS.”The existence of an IEEE Standard does not imply that there are no other ways
11、to produce, test, measure, purchase, market,or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at thetime a standard is approved and issued is subject to change brought about through developments in the state of the art andcomments rec
12、eived from users of the standard. Every IEEE Standard is subjected to review at least every ve years for revi-sion or reafrmation. When a document is more than ve years old and has not been reafrmed, it is reasonable to concludethat its contents, although still of some value, do not wholly reect the
13、 present state of the art. Users are cautioned to checkto determine that they have the latest edition of any IEEE Standard.In publishing and making this document available, the IEEE is not suggesting or rendering professional or other servicesfor, or on behalf of, any person or entity. Nor is the IE
14、EE undertaking to perform any duty owed by any other person orentity to another. Any person utilizing this, and any other IEEE Standards document, should rely upon the advice of a com-petent professional in determining the exercise of reasonable care in any given circumstances.Interpretations: Occas
15、ionally questions may arise regarding the meaning of portions of standards as they relate to specicapplications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepareappropriate responses. Since IEEE Standards represent a consensus of co
16、ncerned interests, it is important to ensure that anyinterpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the members of its soci-eties and Standards Coordinating Committees are not able to provide an instant response to interpretation requests except
17、 inthose cases where the matter has previously received formal consideration. Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership afliation withIEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together
18、with appropriatesupporting comments. Comments on standards and requests for interpretations should be addressed to:Secretary, IEEE-SA Standards Board445 Hoes LaneP.O. Box 1331Piscataway, NJ 08855-1331USAThe IEEE and its designees are the sole entities that may authorize the use of the IEEE-owned cer
19、tication marks and/ortrademarks to indicate compliance with the materials set forth herein.Authorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute ofElectrical and Electronics Engineers, Inc., provided that the appropriate fee is paid t
20、o Copyright Clearance Center. Toarrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive,Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for educationalclassroom use can also be obtained
21、through the Copyright Clearance Center.Note: Attention is called to the possibility that implementation of this standard may require use of subject mat-ter covered by patent rights. By publication of this standard, no position is taken with respect to the existence orvalidity of any patent rights in
22、 connection therewith. The IEEE shall not be responsible for identifying patentsfor which a license may be required by an IEEE standard or for conducting inquiries into the legal validity orscope of those patents that are brought to its attention.Copyright 2002 IEEE. All rights reserved.iiiIntroduct
23、ion(This introduction is not part of IEEE Std 1570-2002, IEEE Standard for the Interface Between the Rail Subsystem andthe Highway Subsystem at a Highway Rail Intersection.)A highway rail intersection (HRI) is the name given by the National Intelligent Transportation System (ITS)Architecture to a hi
24、ghway-rail grade crossing. The Federal Railroad Administration (FRA) denes a high-way-rail grade crossing as “a location where a public highway, road, street, or private roadway, includingassociated sidewalks and pathways, crosses one or more railroad tracks at grade.” This applies equally towhether
25、 the rail subsystem is part of the general system of freight railroads or part of the general passengerrail system including intercity passenger and commuter rail and rapid transit. The Federal Highway Admin-istration (FHWA) denes a highway-rail grade crossing as “the general area where a highway an
26、d a rail-roads right of way cross at the same level, within which are included the railroad tracks, highway, and trafccontrol devices for highway trafc traversing that area.” The FHWA continues on to dene a train as “one ormore locomotives, with or without cars, that operate on rails or tracks and t
27、o which all other trafc mustyield the right-of-way by law at highway-rail grade crossings.” This denition also applies to either mainlinerailroads or rail rapid transit systems.This standard denes the interface between the railroad side and the highway side of a highway-rail gradecrossing. One of th
28、e prime purposes of this interface has been to preempt trafc signal operation when atrain is approaching in order to allow trafc to clear from the vicinity of the crossing. Historically, this hasbeen done with a voltage conveyed by a pair of wires where the absence of the voltage causes the highwayt
29、rafc signal to begin its preemption operation. This interface is designed according to both fail-safe andclosed-loop principles (and is required to be so designed by federal regulations). This standard prescribes adigital communications interface providing equivalent functions while maintaining the
30、required safetyattributes. Within the dened interface, exibility has been provided for information to be provided that hasnot historically been available. As a minimum, this interface will support preemption operation as is pres-ently done by an interconnection circuit. Future upgrades in functional
31、ity are supported by this interface butthe user must be aware that this may increase the overall cost of the systems. This standard only allows forthe possibility of additional functionality on either side of the interface; it does not mandate that functional-ity. This standard also follows the arch
32、itecture dened in the National ITS Architecture.Figure INT-1 shows a typical installation of equipment at a highway-rail grade crossing. There was substan-tial discussion on the allocation of components within either the roadway or the railroad subsystem. Sincethis standard focuses on the interface
33、between the railroad wayside equipment terminator and the roadwaysubsystem, actual allocation of components is irrelevant as the interface is exible enough to support alterna-tive placements should they prove viable in the future. Figure INT-1 shows the predominant congurationfor existing equipment
34、(supported by existing or in-process standards). Clause 2 of this standard identiesexisting standards for these interfaces.ivCopyright 2002 IEEE. All rights reserved.All direct digital communications between the railroad and roadway systems take place via wayside equip-ment terminators in the railwa
35、y system and advanced transportation controllers (or highway trafc signalcontrollers) in the roadway system. This HRI interface standard species direct communications onlybetween wayside equipment terminators and advanced transportation controllers and does not cover commu-nications to/from/between
36、rail operations terminators and trafc management systems, which will be thesubject of a separate standard.Wayside equipment terminators consist of numerous railway control functions such as crossing controllers,grade crossing predictors, event recorders, etc. These functions typically reside in phys
37、ically separatedevices and communicate with one another via an internal communications network. This standard makesno assumptions about technologies used to implement any of the functions.Likewise, the advanced transportation controller may consist of numerous roadway control functions such asvehicl
38、e presence detectors, trafc controllers, etc. The advanced transportation controller is the National ITSArchitecture denition for the device that controls a variety of roadway functions. For this standard, it isintended that this ATC denition also apply to highway trafc signal controllers. Like the
39、railroad waysidefunctions, these roadway functions also communicate to one another via an internal communicationsnetwork. The HRI interface provides the means for control functions in either the wayside equipment termi-nators or the advanced transportation controllers to communicate with one another
40、.The HRI interface can be thought of as consisting of both a virtual (logical) component and a physical com-ponent. The virtual component provides the communications channel between functions in the waysideequipment terminators and the advanced transportation controllers. This component consists of
41、the messageformats and information content that ow between the two systems. The physical component of the HRIinterface facilitates the transfer of data between the internal data network within the wayside equipment ter-minators and the internal network within the advanced transportation controllers.
42、 This physical componentacts as a bridge between these two independent networks. The virtual and physical HRI interfaces are illus-trated in the point-to-point HRI interface conguration shown in Figure INT-2. The HRI physical interfacemay consist of either a simple point-to-point conguration as illu
43、strated, or as a multipoint-to-multipointinterconnection (i.e. network) of wayside equipment gateways and ATC gateways.Figure INT-1HRI interface overviewCopyright 2002 IEEE. All rights reserved.vAs shown in Figure INT-2, the HRI interface architecture consists of four functional entities:Wayside fun
44、ctions:These are the functions within the railroad wayside equipment terminator thatobtain, calculate, or otherwise generate the railroad system information that is to be transmittedacross the HRI interface to the roadway system. These functions may also process data received fromthe roadway system
45、over the HRI interface. There are typically multiple wayside functions within asingle wayside equipment terminator.Wayside gateway:The railroad wayside gateway function acts as both an internal router and an inter-face bridge controller. The wayside gateway is responsible for interfacing to the indi
46、vidual waysidefunctions within a wayside equipment terminator and routing outgoing HRI messages across the HRIinterface to the appropriate ATC gateway. Likewise, the wayside gateway function routes incominginformation received from an ATC gateway to the appropriate wayside function within the waysid
47、eequipment terminator.ATC gateway:The roadway ATC gateway function is the companion function to the wayside gate-way on the roadway side of the HRI physical interface. It routes incoming messages received overthe HRI interface to the appropriate ATC function over the internal ATC network. Likewise,
48、the ATCgateway also routes outgoing messages from the source ATC function to the appropriate waysidegateway.ATC functions:These functions are the companion functions to the wayside functions in the railroadsystem. The ATC functions are the functions within the advanced trafc controller that obtain,
49、calcu-late, or otherwise generate the roadway system information that is to be transmitted across the HRIinterface to the railroad system. Likewise, these functions may also process data received from therailroad system over the HRI interface. There are typically multiple ATC functions within a singleadvanced trafc controller.Figure INT-2HRI interfaceviCopyright 2002 IEEE. All rights reserved.The selection of the protocol standards for the HRI interface was driven by the following high-levelconsiderations:Railroad and roadway system i
