IEEE WG14
P 1570
Meeting 2 Sept 19,2000
Standard for the Interface
Between The Rail Subsystem and
the Highway Subsystem at a
Highway Rail Intersection
AGENDA

9:00 Introductions
 9:30 Review of Last Meeting / Draft Standard
 10:00 Review of Wayside Equipment I/F Std
 Noon Lunch
 1:00 Rail to Highway Messages
 2:00 Highway to Rail Messages
 3:30 Closing Business
WG 14 Objectives

Develop a Practical Standard of Value to the
Industry
 Develop Standard in a Professional
Environment


Schedule (based on 6/00 Kickoff)





All Comments solicited and evaluated
8/01
2/02
8/02
2/03
First Draft
Complete Initial Review
Ballot and final Review
Publish
Provide support for operations center I/F
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.
Today’s Objectives
 Brief
Review of Last Meeting
 Review of Wayside Equipment Interface
Specification
 Identify Messages and Attributes of
Interface Messages
Review of Last Meeting
 Objectives,
Scope and Purpose
 IEEE Standards Process
 ITS Architecture/ HRI Stds Rqmts Pkg
12
 NTCIP Communications Infrastructure
 AREMA, FRA and MUTCD Rqmts
 Process / Strawman
IEEE Standards Process

Highlighted that US Government policy
requires use of consensus standards in
regulatory efforts.
 Characteristics of Consensus Standards





Due Process
Openness
Consensus
Balance
Right of Appeal
IEEE STANDARDS
PROCESS

What IEEE Provides






Automatic ANSI Certification
Complies with PL 104-113 & OMB A-119
Rules, Procedures & Oversight already in place at
no cost to industry
Professional standards experts available to assist
at no cost
Large reservoir of existing case law
IEEE assumes standards liability risk
IEEE Standards Process
 Sponsoring
Committee is the Rail
Transit Interface Standards Committee
 Selected
as sponsoring committee at FRA
meeting with AAR, AREMA, ITE, APTA,
IEEE
 FRA likely to provide funding for standards
preparation support and communications
consultant support
IEEE Standards Process
 Key








Standards Published to Date
IEEE 1473-1999 Communications Protocol
IEEE 1474.1-1999 Communications Based Train
Control Performance & Function
IEEE 1482.1-1999 Event Recorder
IEEE 1475-1999 Propulsion, Braking & Train
Control
IEEE 1477-1998 Passenger Information
IEEE 1483-2000 Software Verification For Vital
Functions
IEEE 1476-2000 Auxiliary Power Interface
IEEE 11-1999 Electric Motors
IEEE Standards Process

Standards in Process









Environmental - Being balloted
Rail TCIP - Underway
Battery Physical Interface - Underway
Software Documentation - Underway
Electronic Control - Underway
NiCad Battery Peformance - PAR stage
HRI - Underway
Central Control CBTC Graphic Interface - Underway
Vehicle/Wayside Communication Protocol - Proposal
ITS Architecture
Current Architecture Version
• Published December 1999
User
Services
Phase I
Competition
1993
1994
Phase II
1995
Architecture
Published
1996
HRI
Update
1997
Version
2.0
1998
Version
3.0
1999
The National ITS Architecture:
HRI Update Summary

Rail Operations and Wayside Equipment
Added as Terminators


Terminators are used on edge of Architecture
Developed Standards Requirement Package
12 as starting point for development of HRI
Interface Standard
The National ITS Architecture: HRI User
Service Addition (2)
TRAIN
APPROACHING
Vehicle Presence Detection Traffic
Vehicle Barriers
Signals
Track
Circuits
Wayside
Equipment
Terminator
Automatic
Gates/Barriers
Wayside
Equipment
Variable
Message Signs
Roadway
Subsystem
Surveillance
Vehicle
Subsystem
Intelligent
Controller
Short Range
Communications
Rail
Operations
Terminator
Rail Operations
Traffic Management Subsystem
Traffic Management
How Can Architecture Support
Standards Development

Definition of Interfaces in National ITS
Architecture serves as starting point for
standards effort (Define interfaces in greater
detail)
 Where to find definition of HRI Interfaces:

Standards Requirements Package 12: Highway
Rail Intersections


Available on CD-ROM- Archdocs/Standards
Requirements Document (pages 640-663)
Essential information also on CD-ROM hypertext under
Hypertext View/Standards Requirements
Stds Rqmt Package 12:
Outline
1 Introduction to Standards Requirements Documentation
2 Introduction: Highway Rail Intersections (HRI)
3 Transaction Sets for Highway Rail Intersection Interfaces
3.1 Rail Operations and Traffic Management Subsystem
3.2 Roadway Subsystem and Traffic Management Subsystem
3.3 Roadway Subsystem and Wayside Equipment Terminator
4 Interface Decomposition
4.1 Traffic Management -> Rail Operations
4.2 Traffic Management -> Roadway Subsystem
4.3 Wayside Equipment -> Roadway Subsystem
4.4 Rail Operations -> Traffic Management
4.5 Roadway Subsystem -> Traffic Management
4.6 Roadway Subsystem -> Wayside Equipment
5 Communications Layer Requirements
6 Constraints
7 Data Dictionary Elements
HRI Interfaces
TMS
Traffic Management
hri status
intersection blockage notification
hri advisories
railroad advisories
railroad schedules
hri control data
hri request
Wayside Equipment
hri status
intersection blockage notification
arriving train
information
track
status
Rail Operations
RS
Roadway Subsystem
National
Regional
Product
None
HRI Information Flows
SOURCE
DESTINATION
INFORMATION
Wayside Terminator
Roadway Subsystem Arriving Train Info
Wayside Terminator
Roadway Subsystem Track Status
Roadway Subsystem Wayside Terminator
HRI Status
Roadway Subsystem Wayside Terminator
Intersection
Blockage Info
NTCIP Overview
National Architecture & NTCIP
NTCIP Center-to-Field
NTCIP Issues
 Lack
of support for peer to peer
communications at this level
 Not directly suitable for safety-critical
applications
Overview of Existing
Regulations and Standards
Existing Regulations and
Practices
 FRA Part
234
 FHWA Title 23 (MUTCD)
 Parts
8 and 10
 AREMA Signal
Manual
 Common Requirements
 Safety
Critical interface for traffic control
(pre-emption) based on closed circuit
principle and fail-safe design principles.
FRA 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
Action Items From Last
Meeting
Action Items
 Solicit Additional
members with highway
systems experience, transit experience
and railway experience
 Set up web site for discussion
 Post Strawman standard for discussion
 Start web discussion on issues
identified
Standards Development
Process
 Process Agreed
to at Kickoff Meeting
 Strawman Outline and Issue
discussions to be posted on website.
 Working Group to review comments and
come to meetings to resolve any issues.
 Meeting agenda to be limited to written
comments.
Draft Standard Outline
 Introduction
 1.0
Overview
 Scope,
 2.0
Purpose and Existing Applications
References
 3.0 Abbreviations, Acronyms and
Definitions
 4.0 Communication System
Draft Standard Outline
 5.0
Rail to Highway Messages
 Data
elements / Message Structure /
Timing Requirements / Functional
Requirements / Safety Requirements
 6.0
Highway to Rail Messages
 7.0 Physical Interconnection
Overview of Wayside
Equipment Interface
Specification
WEI Specification
 Developed
through open process
involving contracted systems engineers,
industry professionals and suppliers
 Defines Interface and Performance
Requirements for wayside equipment
WEI Specification
 Based
on Advanced Train Control
Specifications (ATCS Specs 200 and
250)
 Developed
through open forum process
 Initial Release 12/87
 Presently on V4.0
 In wide use today
 Maintained by AAR
WEI Scope

Specify Pieces of information provided by
wayside equipment components
 Specify the necessary bit patterns for
encoding information
 Specify how encoded information is to be
placed in messages
 Specify appropriate communications
parameters
 Specify Communication Protocols
WEI Scope

Hot Box Detector
 AEI Readers
 Wheel Impact Load Detectors
 Grade Crossing Devices
 Weigh Scale
 Clearance Detector (High/Wide Load)
 Dragging Equipment Detector
 Event Recorder
 Etc.
Communications Architecture
 Based
on 7 layer OSI Model (per ATCS
Spec 200)
 Provides
for alternative Layer 1 and Layer
2 implementations for maximum flexibility
 Time
sync capability not required
Layer 1 - Physical
 Allows
communication in a Master /
Slave combination (star) or multipoint to
multipoint
 Synchronous
RS-422
 Multiplexed Asynchronous RS-232
 Echelon LonTalk
Layer 2 - DataLink
 Sends
packets of data from one device
(node) on the network to another node
HDLC – LAPB (point to point)
 Asynchronous Framing where Echelon is
not used
 Echelon – uses Echelon “foreign frame” to
carry upper level messages.
 Synchronous
Layers 3 through 6
 Independent
of Layers 1 and 2
 Packet consists of a Layer 3 Header
and Layer 4 through 7 header
CRC
Coverage
DL
DL
DL
DL
DL
DL T
DL
DL
DL
DL
DL
DL
DL
DL
DL
DL
DL
DL
T
T
T
T
T
T
T
T
T
T
T
T
DL
DL
DL
DL
DL
T
T
T
T P
T P
DL
DL
DL
DL
DL
DL
DL
DL
DL
DL
T
T
T
T
MSB
LSB
Layer
Data Link Header (Format is Link-Dependent)
Confirm
Packet
Priority
Ack
Bit
Type
Field
Disable
Channel Number
Packet Send Sequence Number
Zero
Bit
Packet Receive Sequence Number
Zero
Bit
Source Address Length in Digits
Destination Address Length in
Digits
Destination Digit 1
Destination Digit 2
Destination Digit 3
Destination Digit 4
Destination Digit 5
Destination Digit 6
Destination Digit 7
Destination Digit 8
Destination Digit 9
Destination Digit 10
Source Digit 1
Source Digit 2
Source Digit 3
Source Digit 4
Source Digit 5
Source Digit 6
Source Digit 7
Source Digit 8
Source Digit 9
Source Digit 10
Message Number Field
More Bit
Part Number Field
End to
End Ack
bit
Message Length Field
Vital Bit
Message Label High Order Byte
Message Label Low Order Byte
Message Version Number
Application Message Data
2
2
Presentation (Vital) CRC High-Order Byte
Presentation (Vital) CRC
Presentation (Vital) CRC
Presentation (Vital) CRC Low-Order Byte
Transport (Vital) CRC High-Order Byte
Transport (Vital) CRC
Transport (Vital) CRC
Tranport (Vital) CRC Low-Order Byte
Data Link (non-vital) CRC High Order Byte
Data Link (non-vital) CRC Low-Order Byte
6
6
6
6
4
4
4
4
2
2
Qual Bit
3
3
3
3
¾
¾
¾
¾
¾
¾
¾
¾
¾
¾
4
4
4
6
6
6/7
7
Message Length
 Maximum
1 packet
Addressing
 14-digit
physical hierarchical wayside
addressing shall be used. Each wayside
device shall be assigned an address of
the format T.RRR.LLL.GGG.SS.DD
where






T
= Address type
RRR = Railroad number assigned by AAR (0 through 999)
LLL = Region / District . (Railroad specific) (0 through 999)
GGG = Control Group within this region (0 through 999)
SS = Equipment within control group (0 through 99)
DD = Internal device within equipment (0 through 99).
Layer 7 – Application Data
 Includes
16 bit label, 8 bit version /
specification number and application
data.
 Version
data refers to ATCS Specification
 Labels and Data Fields defined for this
application (some already defined, need to
define others)
Existing Defined Messages
Name: Ping Request
Revision Date: 9 /28/96
Message Number: 4.1.7 (Proposed) Source: Multiple Devices
Label: 2119
Destination: Multiple Devices
Transmission Rate: Upon Request Max Message Length:
1
Packet
Size Parameter:
8-88 Octets
Purpose: The Ping Request message is used to determine if a
specific application is up and running on an ATCS device. Any ATCS
device can initiate the Ping Request message and transmit the
message to any other ATCS device in the network to request the
operational status of a particular application.
The recipient of the Ping Request message transmits the message,
in its entirety, back to the originator, after verifying the requested
application is operational. If the requested application is not
operational, the recipient will not respond to the message originator.
Ping Request Frame Details
Description
Type
Range
Notes
Revision_Level
Byte
5 only
A
Rqst_Appl_Seq_Number Word
1-32767
B
Rqst_Appl_Ping_Start_Ti Byte [5]
me
See Note
C
Rqst_Appl_Data
See Note
D
Byte [080]
Name: Ping Response
Revision Date: 9 /28/96
Message Number: 4.2.18 (Proposed) Source: Multiple Devices
Label: 2194
Destination: Multiple Devices
Transmission Rate: Upon Response to Ping Request
Max Message Length: 1 Packet
Size Parameter:
8-88 Octets
Purpose: The Ping Response message is the positive reply to a Ping
Request message to determine if a specific application is up and
running on an ATCS device. The recipient of the Ping Request
message transmits the Ping Request message, in its entirety, back to
the originator, after verifying the requested application is operational.
If the requested application is not operational, the recipient will not
respond to the message originator.
Name: Loopback Message
Revision Date: 9 /28/96
Message Number: 4.4.1
Source:
Multiple Devices
Label: 2305
Destination: Multiple Devices
Transmission Rate: As Needed
Max Message Length: 1 Packet
Size Parameter:
87 Octets
Purpose: Purpose: This message is used to test the communication
link between ATCS devices (typically for verifying installation and
troubleshooting communication problems). Any ATCS device can
initiate the loopback message and transmit the message to any other
ATCS device in the network. The loopback message differs from the
ATCS health messages to the extent that the loopback message
provides a method for testing the communication links, independently
of the end applications and the end device's health status.
The recipient of the loopback message transmits the message, in its
entirety, back to the originator and adds the received signal strength
(if available) to the message. Any ATCS device that receives this
message destined for its "Loopback receiver" should echo the entire
message, as received, back to the "Loopback initiator's" address,
adding only the receive signal strength if it is available. End-to-end
message roundtrip throughput can be measured by the loopback
message initiator by comparing the TIMESTAMP_OUT data against
the originator's current time when processing the returned loopback
message.
Name: Health Message Request
Message Number: 4.1.2
Label: 2114
Transmission Rate: Upon Request
Max Message Length: 1 Packet
Size Parameter:
9 Octets
Revision Date: 3/31/93
Source: Multiple Devices
Destination: Multiple Devices
Purpose: The Health Request message is used to request a nondisruptive evaluation of static and general health information from a
device.
Name: Health Message Response
Revision
Date:
3/31/93
Message Number: 4.2.2
Source:
Multiple Devices
Label: 2178
Destination: Multiple Devices
Transmission Rate: Upon Response to Health Msg Request or
device start-up
Max Message Length: 1 Packet
Size Parameter:
123
Purpose: The Health Message Response message is used to
provide a non-disruptive evaluation of static and general health
information from a device in response to a Health Message Request
(4.1.2) or device start-up.
Name: Manufacturer Specific Data
Revision Date:
/28/96
Message Number: 2.4.1 (Proposed) Source:
Multiple Devices
Label: 1281
Destination: Multiple Devices
Transmission Rate: Upon Request
Max Message Length: 1 Packet
Size Parameter:
3+n Octets
9
Purpose: The Manufacturer Specific Data message is used for
transmitting private or manufacturer specific messages.
Name: Crossing Warning Defect Alarm
Revision Date:
/28/96
Message Number: 9.2.18 (Proposed) Source: Wayside Eqpt
Label: 4754
Destination: Multiple Devices
Transmission Rate: …
Max Message Length: 1 Packet
Size Parameter:
6
9
Purpose: The defect alarm message is used to identify short warning
time activation failures.
Name: Crossing Warning Info Report
Revision Date:
/28/96
Message Number: 9.4.10 (Proposed) Source: Wayside Eqpt
Label: 4874
Destination: Multiple Devices
Transmission Rate: Upon Request
Max Message Length: 1 Packet
Size Parameter:
10 Octets
9
Purpose: This message provides information on crossing activities
(Event Date, Event Time and Associated Data). Details are not
defined.
Additional Messages Needed
Name: Arriving Train Info
Revision Date:
Message Number:
Source:
Wayside Terminator
Label:
Destination: Roadway
Subsystem
Transmission Rate:
Max Message Length: 1 Packet
Size Parameter:
Purpose:
Information for a train approaching a highway-rail
intersection that may include direction and allow calculation of
approximate arrival time and closure duration.
This information is non-vital and used for traffic planning purposes
only.
Name: Track Status (Terrible name) Revision Date:
Message Number:
Source:
Wayside Terminator
Label:
Destination:
Roadway
Subsystem
Transmission Rate: Once per second
Max Message Length: 1 Packet
Size Parameter:
Purpose: This message provides vital information on time to arrival
at crossings and/or crossing occupied information.
Failure to receive this message at the destination at least once per
second will be interpreted as an approaching train.
Name: HRI Operational Status
Revision Date:
Message Number:
Source:
Roadway
Subsystem
Label:
Destination: Wayside Terminator
Transmission Rate:
Max Message Length: 1 Packet
Size Parameter:
Purpose: This provides a real-time status indication of the status at a
highway grade crossing (operational, not operational)
Name: Intersection Blockage Notification
Message Number:
Source:
Subsystem
Label:
Destination:
Revision Date:
Roadway
Wayside Terminator
Transmission Rate: Once per second
Max Message Length: 1 Packet
Size Parameter:
Purpose: This data item provides vital information indicating that a
highway grade crossing is obstructed or otherwise closed.
Failure of the Wayside terminator to receive this information once per
second will be interpreted as a blocked intersection.