IEEE WG14P 1570Meeting 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

All Comments solicited and evaluated Schedule (based on 6/00 Kickoff)

8/01 First Draft 2/02 Complete Initial Review 8/02 Ballot and final Review 2/03 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 PurposeCoordination 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 ObjectivesBrief Review of Last MeetingReview of Wayside Equipment Interface

Specification Identify Messages and Attributes of

Interface Messages

Review of Last MeetingObjectives, Scope and Purpose IEEE Standards Process ITS Architecture/ HRI Stds Rqmts Pkg

12NTCIP Communications InfrastructureAREMA, FRA and MUTCD RqmtsProcess / 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 ProcessSponsoring 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 ProcessKey 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

Version2.0

19931994

1995

19961997 1998

UserServices

Phase ICompetition

Phase IIArchitecture

PublishedHRI

Update

Current Architecture VersionCurrent Architecture Version

• Published December 1999

Version3.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)

WaysideEquipment

IntelligentController

AutomaticGates/Barriers

TrafficSignals

VariableMessage Signs

Surveillance

Short RangeCommunications

TrackCircuits

TRAINAPPROACHING

Rail Operations Traffic Management

Traffic Management Subsystem

VehicleSubsystemWayside

EquipmentTerminator

RailOperationsTerminator

RoadwaySubsystem

Vehicle Presence DetectionVehicle Barriers

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: Outline1 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

RS Roadway Subsystem

TMS Traffic Management

Wayside Equipment

Rail Operations

hri status intersection blockage notification

hri status intersection blockage notification

hri control data hri request

hri advisories

arriving train information track status

railroad advisories railroad schedules

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 Center-to-Center

NTCIP IssuesLack of support for peer to peer

communications at this levelNot directly suitable for safety-critical

applications

Overview of Existing Regulations and Standards

Existing Regulations and PracticesFRA Part 234FHWA Title 23 (MUTCD)

Parts 8 and 10AREMA Signal ManualCommon 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 ItemsSolicit Additional members with highway

systems experience, transit experience and railway experience

Set up web site for discussionPost Strawman standard for discussionStart web discussion on issues

identified

Standards Development ProcessProcess Agreed to at Kickoff MeetingStrawman 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 Introduction1.0 Overview

Scope, Purpose and Existing Applications2.0 References3.0 Abbreviations, Acronyms and

Definitions4.0 Communication System

Draft Standard Outline5.0 Rail to Highway Messages

Data elements / Message Structure / Timing Requirements / Functional Requirements / Safety Requirements

6.0 Highway to Rail Messages7.0 Physical Interconnection

Overview of Wayside Equipment Interface

Specification

WEI SpecificationDeveloped through open process

involving contracted systems engineers, industry professionals and suppliers

Defines Interface and Performance Requirements for wayside equipment

WEI SpecificationBased 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 ArchitectureBased on 7 layer OSI Model (per ATCS

Spec 200) Provides for alternative Layer 1 and Layer

2 implementations for maximum flexibilityTime sync capability not required

Layer 1 - PhysicalAllows communication in a Master /

Slave combination (star) or multipoint to multipoint Synchronous RS-422 Multiplexed Asynchronous RS-232 Echelon LonTalk

Layer 2 - DataLinkSends packets of data from one device

(node) on the network to another node Synchronous HDLC – LAPB (point to point) Asynchronous Framing where Echelon is

not used Echelon – uses Echelon “foreign frame” to

carry upper level messages.

Layers 3 through 6 Independent of Layers 1 and 2Packet consists of a Layer 3 Header

and Layer 4 through 7 header

CRC

Coverage MSB LSB

Layer

DL Data Link Header (Format is Link-Dependent) 2 DL Qual Bit Confirm

Bit Packet Type

Priority Field

Ack Disable

2

DL Channel Number 3 DL Packet Send Sequence Number Zero

Bit 3

DL Packet Receive Sequence Number Zero Bit

3

DL T Source Address Length in Digits Destination Address Length in Digits

3

DL T Destination Digit 1 Destination Digit 2 ¾ DL T Destination Digit 3 Destination Digit 4 ¾ DL T Destination Digit 5 Destination Digit 6 ¾ DL T Destination Digit 7 Destination Digit 8 ¾ DL T Destination Digit 9 Destination Digit 10 ¾ DL T Source Digit 1 Source Digit 2 ¾ DL T Source Digit 3 Source Digit 4 ¾ DL T Source Digit 5 Source Digit 6 ¾ DL T Source Digit 7 Source Digit 8 ¾ DL T Source Digit 9 Source Digit 10 ¾ DL T Message Number Field More Bit 4 DL T Part Number Field End to

End Ack bit

4

DL T Message Length Field Vital Bit 4 DL T Message Label High Order Byte 6 DL T Message Label Low Order Byte 6 DL T P Message Version Number 6/7 DL T P Application Message Data

7

DL T Presentation (Vital) CRC High-Order Byte 6 DL T Presentation (Vital) CRC 6 DL T Presentation (Vital) CRC 6 DL T Presentation (Vital) CRC Low-Order Byte 6 DL Transport (Vital) CRC High-Order Byte 4 DL Transport (Vital) CRC 4 DL Transport (Vital) CRC 4 DL Tranport (Vital) CRC Low-Order Byte 4 DL Data Link (non-vital) CRC High Order Byte 2 DL Data Link (non-vital) CRC Low-Order Byte 2

Message LengthMaximum 1 packet

Addressing14-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/96Message Number: 4.1.7 (Proposed) Source:Multiple DevicesLabel: 2119 Destination:Multiple DevicesTransmission Rate: Upon Request Max Message Length: 1 PacketSize 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.

Description Type Range Notes

Revision_Level Byte 5 only A

Rqst_Appl_Seq_Number Word 1-32767 B

Rqst_Appl_Ping_Start_Time

Byte [5] See Note C

Rqst_Appl_Data Byte [0-80]

See Note D

Ping Request Frame Details

Name: Ping Response Revision Date: 9 /28/96Message Number: 4.2.18 (Proposed) Source:Multiple DevicesLabel: 2194 Destination:Multiple DevicesTransmission Rate: Upon Response to Ping RequestMax Message Length:1 PacketSize 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/96Message Number: 4.4.1 Source: Multiple DevicesLabel: 2305 Destination:Multiple DevicesTransmission Rate: As NeededMax Message Length:1 PacketSize 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 Revision Date: 3/31/93Message Number: 4.1.2 Source: Multiple DevicesLabel: 2114 Destination: Multiple DevicesTransmission Rate: Upon RequestMax Message Length:1 PacketSize Parameter: 9 Octets Purpose: The Health Request message is used to request a non-disruptive evaluation of static and general health information from a device.

Name: Health Message Response Revision Date: 3/31/93Message Number: 4.2.2 Source: Multiple DevicesLabel: 2178 Destination:Multiple DevicesTransmission Rate: Upon Response to Health Msg Request or device start-upMax Message Length:1 PacketSize 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 DataRevision Date: 9 /28/96Message Number: 2.4.1 (Proposed) Source: Multiple DevicesLabel: 1281 Destination:Multiple DevicesTransmission Rate: Upon RequestMax Message Length:1 PacketSize Parameter: 3+n Octets Purpose: The Manufacturer Specific Data message is used for transmitting private or manufacturer specific messages.

Name: Crossing Warning Defect Alarm Revision Date: 9 /28/96Message Number: 9.2.18 (Proposed) Source:Wayside EqptLabel: 4754 Destination:Multiple DevicesTransmission Rate: …Max Message Length:1 PacketSize Parameter: 6 Purpose: The defect alarm message is used to identify short warning time activation failures.

Name: Crossing Warning Info ReportRevision Date: 9 /28/96Message Number: 9.4.10 (Proposed) Source:Wayside EqptLabel: 4874 Destination:Multiple DevicesTransmission Rate: Upon RequestMax Message Length:1 PacketSize Parameter: 10 Octets 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 TerminatorLabel: Destination:Roadway SubsystemTransmission Rate: Max Message Length:1 PacketSize 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 TerminatorLabel: Destination: Roadway SubsystemTransmission Rate: Once per secondMax Message Length:1 PacketSize 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 SubsystemLabel: Destination: Wayside TerminatorTransmission Rate: Max Message Length:1 PacketSize Parameter: Purpose: This provides a real-time status indication of the status at a highway grade crossing (operational, not operational)

Name: Intersection Blockage Notification Revision Date:Message Number: Source: Roadway SubsystemLabel: Destination: Wayside TerminatorTransmission Rate: Once per secondMax Message Length:1 PacketSize 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.