IEEE WG14 P 1570 Standard for the Interface Between The Rail Subsystem and the Highway Subsystem at...
-
Upload
meryl-mosley -
Category
Documents
-
view
218 -
download
3
Transcript of IEEE WG14 P 1570 Standard for the Interface Between The Rail Subsystem and the Highway Subsystem at...
IEEE WG14P 1570
Standard for the Interface Between The Rail Subsystem and the
Highway Subsystem at a Highway Rail Intersection
• 9:00 Introductions and Housekeeping• 9:15 Objectives, Scope & Purpose• 9:30 IEEE Standards Process / RTVISC• 10:00 ITS Architecture• 11:00 NTCIP Communications• 12:00 Lunch on your own• 1:00 AREMA, FRA & MUTCD• 1:30 Standards Requirement Package 12• 2:30 Process / Strawman • 4:30 Adjourn
WG 14 Objectives
• Develop a Practical Standard of Value to the Industry
• Develop Standard in a Professional Environment
– All Comments solicited and evaluated• Target 12 month first draft, 6 month
review, 6 month ballot and final review• Provide support for operations center I/F
Today’s Objectives
• Review Background Material on ITS Architecture and Communications
• Review Background Material on relevant regulations
• Agree on Process to Move Forward• Review Strawman Outline• Next Meeting
P1570 Scope
This standard defines the logical and physical interfaces, and the performance attributes for the interface between the rail subsystem and the highway subsystem at a highway rail intersection.
P1570 Purpose
Coordination between the rail subsystem and the highway subsystem is part of creating a National Intelligent Transportation System covering multiple modes of transportation. Existing standards address analog interfaces between these subsystems at the highway rail intersection. This standard will extend that information to include serial digital communication. Standardizing the interface will allow interoperability between a wide variety of equipment and enhance safety through a set of well-defined interface and performance attributes.
IEEE Standards Process and Sponsoring Committee
Tom McGean
ITS Architecture
Bruce Eisenhart
Lockheed Martin
NTCIP
Jack Bailey
ARINC
FRA, AREMA, MUTCD
Highlight Relevant Regulations and Recommended Practices
Federal Railroad Administration
• Part 234 - Grade Crossing Signal System Safety (Title 49 of Code of Federal Regulations)
– Subpart A - General
– Subpart B - Reports
– Subpart C - Response to Reports of Warning System Malfunction
– Subpart D - Maintenance, Inspection & Testing
Part 234
• Imposes minimum maintenance, inspection, and testing standards for highway rail grade crossing warning systems.
• 234.203 Control Circuits
– Shall Operate on fail-safe principle• 234.253-257 Gates, Lights, Operation
– Operational check at least once per month
Part 234
• 234.261 Highway traffic signal pre-emption
– Highway traffic signal pre-emption interconnections, for which a railroad has maintenance responsibility, shall be tested at least once per month.
Part 236 Subpart H (Draft NPRM)
• 234.275 Highway Rail Grade Crossing Systems containing new or novel technology or provide safety-critical data to a railroad signal system shall comply with Subpart H of Part 236
• Deviations from 234.203 (Control Circuits) must be separately justified at the component, subsystem and system level per 236.909
Part 236 Subpart H (Draft NPRM)
• “Nothing in this section authorizes deviation from applicable design requirements of MUTCD”.
FHWA Manual of Uniform Traffic Control Devices
The MUTCD is the "bible" for traffic control devices (defined as "all signs, signals, markings, and devices placed on, over, or adjacent to a street or highway"). Since 1966, traffic control devices in all states must be in conformance with the standards issued or endorsed by the Federal Highway Administrator through the MUTCD.
FHWA MUTCD
• Title 23 Code of Federal Regulations Part 655
– Part 8: Traffic Control for Highway-Rail Grade Crossings (Proposed Update)
– Part 10: Traffic Controls for Highway-Light Rail Rail Transit Grade Crossings (Proposed Addition)
FHWA MUTCD
• 8D.6 Highway-rail control circuits, including those used for train detection, shall be designed on the fail-safe principle, which uses closed circuits
FHWA MUTCD
• 8D.7 Pre-emption feature shall have an electrical circuit of the closed-circuit principle or a supervised communication circuit between the control circuits of the highway-rail grade crossing warning system and the traffic control signal controller.
Supervised Interconnection Circuits
• Used to prevent a failure in the interconnection from continually pre-empting the traffic signal
AREMA
• American Railway Engineering and Maintenance of Way Association
• Manual of Recommended Practices for Communications and Signals
AREMA Section 3Highway-Rail Grade Crossing
Warning Systems• Provides Guidelines for Highway-Rail
Grade Crossing Warning Devices and Systems
– Functional and Operating (how it works)
– Application
– Design Criteria (including interfaces)
– Maintenance and Test
AREMA Section 3
• Covers Interface and Design Requirements for Gates / Flashers / Bells / Presence Detection / Controllers / Monitoring Equipment
• Section 3.1.10 Interconnection between Highway Traffic Signals and Highway Rail-Grade Crossing Warning Systems
The National ITS Architecture: HRI User Service Addition (2)
WaysideEquipment
IntelligentController
AutomaticGates/Barriers
TrafficSignals
VariableMessage Signs
Surveillance
Short RangeCommunications
TrackCircuits
TRAINAPPROACHING
Rail Operations Traffic Management
Traffic Management Subsystem
VehicleSubsystemWayside
EquipmentTerminator
RailOperationsTerminator
RoadwaySubsystem
AREMA Section 3.1.10
• Normally Closed, double break physical circuit which opens when train approaches and occupies the circuit
• Advance pre-emptions should be reviewed as restarts could result in reduced or no advance time.
Standards Requirements Package 12
Highway Rail Intersections
HRI Package 12
• Prepared by ITS Architecture Development Team for FHWA. (December 1999 Revision)
• Collects information from other ITS documents and organizes it to support development of critical ITS standards.
HRI Pkg Main Components• Message Transaction Sets
– Series of messages exchanged between subsystems
• Interface Decomposition
– Subsystem Interface -> Physical Architecture Flows -> Leveled Architecture Flows
• Communications Considerations• Constraints• Data Element Definition
HRI Package Introduction
• Train has right-of-way in all normal operating scenarios
• Manage Roadway Vehicle Traffic to maximize safety and minimize delays
• Coordination of Traffic Signals with Rail Signals as well as dissemination of crossing status information to aid in route planning
The National ITS Architecture: HRI User Service Addition (2)
WaysideEquipment
IntelligentController
AutomaticGates/Barriers
TrafficSignals
VariableMessage Signs
Surveillance
Short RangeCommunications
TrackCircuits
TRAINAPPROACHING
Rail Operations Traffic Management
Traffic Management Subsystem
VehicleSubsystemWayside
EquipmentTerminator
RailOperationsTerminator
RoadwaySubsystem
HRI Package Main Interfaces
• Roadway Subsystem and RR Wayside Equipment Terminator
– Main Area of WG14 Interest• Traffic Management Subsystem and Rail
Operations terminator
– Provide support to main SDO (TBD)
HRI Package Operations Level Interfaces
• Rail Operations to/from Traffic Operations (info only)
– Exchange Mgmt or near real-time data
– TO Traffic Mgmt System (TMS)
• train schedules, maintenance schedules (periodic, e.g. daily)
• Rail incidents which may affect vehicle traffic (near real-time)
HRI Package Operations Level Interfaces
• Rail Operations to/from Traffic Operations (info only)
– TO Rail Operations Center
• planned maintenance activities
• equipment failure, intersection blockage, or other incident information (e.g HAZMAT spill)
HRI Package Operations Level Interfaces
• Roadway Subsystem to/from Traffic Operations (info only)
– Status of HRI including crossing status, traffic info, crossing closure info (obtained from RR equipment)
– Info to be displayed on Variable Message Signs
Roadway
Advanced SpeedRail Crossing
WaysideEquipment
track status
crossingpermission
driverinformation
hristatus
hri status
hri control data
hri request
Intersectionblockage
notification arriving traininformation
HRI Package Subsystem Interfaces
• Rail Subsystem to Highway Subsystem
– Time Critical Data about an Approaching Train
– Operational Status Information• Highway Subsystem to Rail Subsystem
– Operational Status
– Indication that a grade crossing is obstructed or otherwise closed
HRI Package Communications
• Wireline Communications
Proposed Development Process
Proposed Process• Background Material has been reviewed• Walk Through Strawman Outline• Highlight any major additional areas that need
to be included• WAP to post outline on web, add more detailed
material. Volunteers Welcome. • WG to hurl darts, throw spears, etc. at posted
material (in terms of WRITTEN pros / cons / suggested changes for each section)
Proposed Process (cont.)
• WAP to post pros and cons on website (notifying group when something new is posted)
• WG to read comments, come to next meeting prepared to discuss & resolve any issues.
• Meeting Agenda to be limited to written comments.
P 1570 Strawman outline
P1570
• 1.0 Overview - Background, discussion• 2.0 Scope - Already Done• 3.0 Purpose - Already Done• 4.0 References• 5.0 Definitions - Reference Existing
Definitions• 6.0 Acronyms and Abbreviations
P1570• 7.0 Messages from Rail Subsystem to
Highway Subsystem
– 7.1 Time to Train Arrival At Crossing
• 7.1.1 Data Elements and Definitions
• 7.1.2 Message protocol (including Addressing, information encoding)
• 7.1.3 Timing Requirements (periodicity, accuracy, latency)
• 7.1.4 Functional Requirements related to Interface (e.g.expected response to message and operation
• 7.1.5 Safety Requirements
Issues To Consider
• Separate standards for data elements, message sets, communications ?
– Recommend 1 for now, consider separation later
• Use of NTCIP vs Alternative?
– Issues of safety, performance, etc.
– Balance RR / Highway desires• Point to Point vs. Networked
P 1570• 7.0 Messages from Rail Subsystem to
Highway Subsystem
– 7.2 Operational Status
• 7.2.1 Data Elements and Definitions
• 7.2.2 Message protocol (including Addressing, information encoding)
• 7.2.3 Timing Requirements (periodicity, accuracy, latency)
• 7.2.4 Functional Requirements related to Interface (e.g.expected response to message and operation
• 7.2.5 Safety Requirements
P1570• 8.0 Messages from Highway Subsystem
to Rail Subsystem
– 8.1 Crossing Status (Operational, Obstructed)
P1570
• 8.1.1 Data Elements and Definitions
• 8.1.2 Message protocol (including Addressing, information encoding)
• 8.1.3 Timing Requirements (periodicity, accuracy, latency)
• 8.1.4 Functional Requirements related to Interface (e.g.expected response to message and operation
• 8.1.5 Safety Requirements
P1570• 8.0 Messages from Highway Subsystem
to Rail Subsystem
– 8.2 Crossing Status (Health)
P 1570
• 8.1.1 Data Elements and Definitions
• 8.1.2 Message protocol (including Addressing, information encoding)
• 8.1.3 Timing Requirements (periodicity, accuracy, latency)
• 8.1.4 Functional Requirements related to Interface (e.g.expected response to message and operation
• 8.1.5 Safety Requirements
P 1570
• 9.0 Physical Communication Attributes
– Physical Link Information, Connector Information.
– Issues: Should we consider offering alternatives within the standard?
P1570
• Informative Appendices if needed.
Next Meeting
• Possibilities
– Approximately 3 months
– Wk of Sept 18th
– Thursday Sept 21st
• Louisville, KY
• Ontario, CA
• Volunteer Location ?