Interoperable Train Control

Wayside Interface Unit Requirements

Railway Electronics
AAR S‐9202

Issue of 2011
Version 1.2.8
03/09/2011

ITC Accepted
AAR Draft

Compiled under the direction of the Committees responsible for the subject matter herein.

© Copyright Association of American Railroads

Page 1 of 47

Interoperable Train Control Wayside Interface Requirements

 Table of Contents

1 VERSION HISTORY ................................................................................................................ 5

2 REFERENCES......................................................................................................................... 7

3 NOTES AND DEFINITIONS..................................................................................................... 8

4 POSITIVE TRAIN CONTROL (PTC)REFERENCES............................................................... 9

5 KEYED-HASH MESSAGE AUTHENTICATION CODE (HMAC)........................................... 26

6 WAYSIDE CODES ................................................................................................................. 29

7 WIU DEVICE STATUS STRUCTURE ................................................................................... 30

8 CONFIGURABLE PARAMETERS ......................................................................................... 31

9 TIME INTERFACE SPECIFICATIONS .................................................................................. 35

10 DIAGNOSTICS AND SYSTEMS MANAGEMENT ............................................................. 38

11 POWER SUPPLY AND I/O REQUIREMENTS FOR STANDALONE WIUS...................... 43

12 CODE LINE (FUTURE) ...................................................................................................... 46

13 CROSSING MESSAGES .................................................................................................. 47

Page 2 of 47

Interoperable Train Control Wayside Interface Requirements

 Table of Figures

FIGURE 1 - WIU CONFIG FILE SCHEMA ............................................................................................. 13

FIGURE 2 - DEVICE TYPE FILE SCHEMA ............................................................................................. 14

FIGURE 3 - WIU WSM HMAC GENERATION ..................................................................................... 27

FIGURE 4 - WIU HMAC VALIDATION OF LRM.................................................................................... 28

FIGURE 5 - WSM DEVICE STATUS DATA ........................................................................................... 30

FIGURE 6 - CODE LINE CONNECTIVITY............................................................................................... 46

Page 3 of 47

Interoperable Train Control Wayside Interface Requirements

 Table of Tables

TABLE 1 - WIUSTATUS MESSAGE BODY ........................................................................................... 16

TABLE 2 - MESSAGE FORMAT WIUSTATUS TIMED BEACON ................................................................ 18

TABLE 3 - MESSAGE FORMAT WIUSTATUS IN RESPONSE TO GETWIUSTATUS ................................... 19

TABLE 4 - MESSAGE FORMAT GETWIUSTATUS ................................................................................. 20

TABLE 5 - MESSAGE FORMAT BEACONON ......................................................................................... 21

TABLE 6 - SIGNAL NAMES CODES ..................................................................................................... 29

TABLE 7 - CONFIGURABLE PARAMETERS SUMMARY ........................................................................... 34

TABLE 8 - MESSAGE FORMAT TIME ................................................................................................... 37

TABLE 9 - WAYSIDE SYSTEM MANAGEMENT MESSAGES ..................................................................... 42

TABLE 10 - POWER SUPPLY RATINGS ............................................................................................... 43

Page 4 of 47

Interoperable Train Control Wayside Interface Requirements

1 Version History

Version Date Comments By

1.1 03/30/2009 Initial Version ITC Wayside
1.2 08/13/2009 Updated per comments ITC Wayside
1.2.1 09/19/2009 Updated per comments ITC Wayside
1.2.2 11/05/2009 Updated per comments ITC Wayside
1.2.3 02/24/2010 Updated per comments ITC Wayside
1.2.4 03/12/2010 In each of the Message Tables the EMP header ITC Wayside
ProtocolVersion was changed from 2 to 0x4(4) and
DataLength was changed from 3 bytes to 24 bits.
In Part 8 Configurable Parameters, EMP flags Bit
0, Always set to 1 was added.
1.2.5 06/27/2010 ITP replaced with ITCM, WSM broadcast rate at ITC Wayside
least 1 sec., ATCS address is a numeric 40 bit
number, POSIX changed to 32 bit message time
per EMP, message sequence number added to
WSMs, LRMs have the HMAC moved to the EMP
CRC, additional configurable parameters for time,
time behavior added, alarms added to Systems
Management, crossing section referenced a
separate document.
1.2.6 08/10/2010 Removed (not populated) from the Destination in ITC Wayside
the WIUStatus In Response to GetWIUStatus,
added foreword in Section 9 describing EMP and
NTP time synchronization methods, corrected
Figure 3 and 4 references in 5.7.1, removed the
time bubble from Figure 4, added ranges to time
parameters and two more configurable parameters
to Table 7, and made clarification changes to 9.10-
9.18.
1.2.7 09/072010 Added “EMP address of GetWIUStatus sender” to ITC Wayside
the Destination field in Table 3. Added “(Timed
Beacon)” to EMP Dest Address and changed
default value to “None” in Table 7.
1.2.8 03/09/2011 Changed BeaconBitTime and BeaconEndTime in
4.1.10 to match Table 7. Added general broadcast
address to Destination in Table 2 and Table 7.
Changed Configurable In parameter for X509,
EMP Header Source Sdress, Clas C Multicast
Address, Class C Port Address, Emp Destination
Address, in Table 7. Added configurable parameter
“Class D Data Ack Timeout” and revised setting on
Class D Keep Alive Interval and Class D
Page 5 of 47

Interoperable Train Control Wayside Interface Requirements

Version Date Comments By
Acknowledgement Timeout in Table 7. Data
Length was changed to 0 in the Time Message
Format Table 8.

Page 6 of 47

Interoperable Train Control Wayside Interface Requirements

2 References

2.1 Federal Information Processing Standards (FIPS) publication 198 (dated 3/6/2002),
“The Keyed-Hash Message Authentication Code (HMAC).”

2.2 Federal Information Processing Standards (FIPS) publication 180-2.

2.3 EMP Message Format Specifications v2.2.

2.4 Class C Messaging Specifications v1.6.

2.5 Class D Messaging Specification v3.2.

2.6 AREMA Communication and Signal Manual – 2010

2.7 AAR Specification S-5800 (Formerly ATCS Specification 200)

2.8 Wayside System Management Guidelines

2.9 Interoperable Train Control Wayside Interface Architecture– 10/28/2009

2.10 PTC Data Model Definition rev M – 02/10/2010 draft

2.11 Advance Highway-Grade Crossing Starts (under development)

2.12 Interoperable Train Control Messaging Architecture (under development).

2.13 WIU_config.xsd – xml schema for WIU data v0.2 02/03/2010

.

Page 7 of 47

Interoperable Train Control Wayside Interface Requirements

3 Notes and Definitions
3.1 The term Wayside Status Message (WSM) shall be used to represent the EMP
message generated by the WIU that contains 1 or more device statuses.
3.2 The term Locomotive Request Message (LRM) (GetWIUStatus, BeaconOn) shall be
used to represent the EMP messages accepted by the WIU that initiate WSMs and/or
provide device statuses on alternate path.
3.3 The term Keyed-Hash Message Authentication Code (HMAC) represents a value that
is calculated by the WIU and included in the vital payload of the WSM. The calculation
of this HMAC uses a “truncated SHA-1” algorithm, as described in section 4 of
reference #1, based on various messages attributes such as the payload, the WIU
time, and WIU software version. The TMC, back office, etc. use this HMAC to detect
the validity and integrity of the payload.
3.4 (deleted item)
3.5 Some timing requirements are estimates that need to be validated with the subject
matter experts and prospective vendors. These values are in bold type. An example is
timing requirements are levied in order to determine the worst case age of a wayside
device status at the TMC.
3.6 This draft of the requirements only covers basic wayside operations. Additional
operation descriptions will be in future supplemental requirements including codeline,
crossing messages, and other optional requirements.
3.7 QoS means Quality of Service.
3.8 TMC means Train Management Computer.
3.9 ELM – External Link Manager as defined in the ITCM Archictectue Document can be
external or internal to the WIU
3.10 AG – Application Gateway as defined in the ITCM Archictectue Document can be
external or internal to the WIU
3.11 BeaconTTL Bit is the time-to-live bit used in the wayside status message.
3.12 WCM is the PTC Wayside Communication Module (Radio)
3.13 LCM is the Locomotive Communication Module (Radio)
3.14 ITCM is Interoperable Train Control Messaging.

Page 8 of 47

Interoperable Train Control Wayside Interface Requirements

4 Positive Train Control (PTC)
4.1 Wayside Interface Unit Requirements
The Wayside Signal System shall provide wayside Signal System device information to the TMC
in a vital manner. This interface, used for existing wayside signal system installations, shall be
known as a “Wayside Interface Unit” (WIU). WIU installations can be stand alone or installations
of Signal Systems can be integrated with the WIU such that the WIU becomes an internal
function of the signal system equipment.

This requirements document permits the WIU specification to support both current
communications technology with a variable data payload capability and communications with
larger data payload capabilities. The status information for the signal system related devices
being monitored by a WIU can be allocated to the WIU device status, permitting the optimization
of the WIU physical configuration while matching the data transport limitations of the current
communications devices (e.g.: ability to aggregate multiple WIUs in a single EMP message).
The industry standard protocols (AAR RESC Class C, Class D, and/or EMP) shall be used for the
WIU messages. The protocols directly support the capability to broadcast time-sensitive
information to any number of interested “consumers”.
4.1.1 WIU functionality can be either internal or external to existing signal equipment.
4.1.2 The WIU shall interface to the existing signal equipment, including signal lamps,
switches and hazard detectors and must not falsely interpret the state of signals,
switches, and hazard detectors in a permissive manner.
4.1.3 The WIU shall provide vital messages (WSM) containing the status information to
the TMC regardless of the communications mechanism utilized. (WIUStatus in
Response to GetWIUStatus, WIUStatus Timed Beacon)
4.1.4 The WIU for individual railroad requirements may be required to run the ITCM
stack. ITCM functionality may be provided within the WIU or an external box.
4.1.5 The WIU shall accept LRMs – BeaconOn and GetWIUStatus.
4.1.6 The WIU, receiving the WIUBeaconOn message, shall internally approach light
signals (if so configured) or approach light signals through an external output, set
the BeaconTTL bit to 1, and begin sending WSMs.with QoS for the normal
Comm path. The signals shall remain approach lit until both the BeaconBitTime
and BeaconEnd timers expire. If the timers expire the signals shall be allowed to
immediately relight.
4.1.7 The PTC WIU shall broadcast aspects, regardless of approach lighting when set
to beacon continuously. So in the case of an integrated WIU where the WIU
continuously sample all lamps, and the plant was dark, it may be possible with
executive and application logic, instead of broadcasting a dark aspect, the WIU
shall broadcast the aspect it’s going to display once lit.
4.1.8 The WIU, receiving the GetWIUStatus message, shall internally approach light
signals (if so configured) or approach light signals through an external output, set
the BeaconTTL bit to 1, send a single WSM with a different QoS for alternate
Comm path, and begin beaconing with the normal QoS. Whenever sending out
an immediate WIUStatus in response to a GetWIUStatus, also send a copy of
the same WIUStatus as a beacon as well to ensure that the next beaconed
message shall not be older than the immediately sent WIUStatus message. The
signals shall remain approach lit until both the BeaconBitTime and BeaconEnd
timers expire. If the timers expire the signals shall be allowed to immediately
relight. The WIU shall continue sending WSM’s or begin sending WSMs with
normal Comm path QoS if not already beaconing. For GetWIUStatus the
approach lighting shall be employed, timers started, etc. If there is a WIUStatus
change approach lighting shall not be evoked. If a signal goes from green to dark
Page 9 of 47

Interoperable Train Control Wayside Interface Requirements

 at the end of the approach lighting timers, the WIUStatus changes to dark for the
signals, there is no need to relight the signals. Just send the current 'de-
bounced' status.
4.1.9 WSM’s shall have a BeaconTTL bit. The BeaconTTL bit shall always be set to 1
if BeaconContinuous is set to On or 1. If the BeaconContinuous is set to On or 1
then the WIU shall continuously beacon.
4.1.10 If not continuously beaconing, the BeaconTTL bit shall initially be set to 0 and
change to a 1 when a WIUBeaconOn or GetWIUStatus message is received.
When bit is 1, WIU shall continue to beacon from configurable BeaconBitTime (1
– 30 minutes) after which time the WIU shall set the BeaconTTL bit to 0. The
WIU shall continue to beacon when bit is 0, after which the WIU shall cease to
beacon in configurable BeaconEnd time (1-30 minutes). The BeaconStartTimer
and the BeaconEnd timer shall restart their time after receiving either a
WIUBeaconOn or a GetWIUStatus message.
4.1.11 If the WIU is configured to not beacon continuously, a MaxBeaconInterval
parameter shall initiate timed beacon WIUStatus messages for the BeaconEnd
time period at the MaxBeaconInterval time for monitoring health by the back
office. The MaxBeaconInterval default shall be 900 seconds. The
MaxBeaconInterval shall also have a method to disable this interval. When not
configured to Beacon continuously, any change in the WSM shall be broadcast
unless the MaxBeaconInterval is disabled. When sending out the
MaxBeaconInterval message approach lighting shall not be invoked. This is
meant to give the back office a "heartbeat" from the site. If approach lighting is
not already active or the site is not constantly lit, then the location shall send a
dark. Only BeaconOn and GetWIUStatus evoke approach lighting, timers, etc.
4.1.12 WSM shall contain Mod16 time to get low-order 4-bits of the time value
maintained by the WIU.
4.1.13 All WIU messages, except time, shall be HMAC protected.
4.1.14 The WIU shall maintain clock synchronization from an external device with a one
second resolution. See Section 9 for this interface. The time message shall be
EMP transported over Class C. The WIU shall support the use of native IP NTP
version 3 as specified in the IETF RFC 1305 or SNTP version 4 as per RFC
4330, as a protocol for synchronizing the time clock. (Both shall be required
(EMP or SNTP), but only one shall enabled at a time.)
4.1.15 The WIU shall support 802.3 (10/100 with auto negotiate) Ethernet interface.
4.1.16 The WIU shall support 2 simultaneous (separate NICs) PTC comm paths with
ability to do local maintenance and access diagnostics without disconnecting
either of these 2 paths, plus the ability for maintainer to access local
maintenance and access diagnostics without manually changing PC network
settings.
4.1.17 The WIU shall utilize web browser interface standard tools where possible for the
programming and configuration of the WIU.
4.1.18 The WIU shall provide the capability to represent RAILROAD SPECIFIC signal
aspects and other device type states in an N bit group (WIUDeviceStatus). N
shall default to 5 bits for signals, 2 bits for switches, and 1 bit for hazard
detectors. Each signal mast at a location, regardless of the number or heads or
lamps, would require one 5-bit aspect “code” in a WIUDeviceStatus field. Refer
to individual railroads for ASPECT TABLES. Flash rates for flashing aspects
may vary from 35 to 75 flashes per minute.
4.1.19 The WIU shall encode the WIUDeviceStatus as described in Section 7 WIU
Device Status Structure.
4.1.20 The WIU compiler/tools program shall provide the capability to manipulate
individual bits to create and order device states in the WIUDeviceStatus. It is
preferred that a graphical user interface (preconfigured tables, with a drag and
Page 10 of 47

Interoperable Train Control Wayside Interface Requirements

 drop of selection process, etc. to eliminate errors in aspect assignments.) tool be
provided for configuration.
4.1.21 The WIU device status value shall use a default value of 0 for devices and
WIUDeviceStatuses that are not in the configuration (e.g.: link down on a remote
unit, remote unit not installed, non-assigned gaps in the payload, etc.).
4.1.22 The WIU shall transport device statuses (WSM) to the ITCM using the Class D
protocol according to the AAR RESC Class D specifications.
4.1.23 WIU shall support a Class D Basic Node implementation. Class D Built in Test
Mode shall be supported in future implementations.
4.1.24 The WIU shall be configured as the TCP client for Class D links to the ITCM.
4.1.25 The WIU shall support the reception of the BeaconOn, GetWIUStatus,
diagnostics, codeline, and crossing messages from the ITCM using the Class D
protocol.
4.1.26 The WIU shall provide the capability to configure the broadcast rate of a WIU-
Message (WSM) with current device statuses in a range from a minimum of the
greater of 1000 milliseconds or mainloop time to 60000 milliseconds. The 1000
ms minimum period provides the ability to keep messages from having the same
second. Default shall be the longer of mainloop time or 1000 milliseconds (1
second).
4.1.27 The WIU shall provide the capability to be configured to broadcast a device
status change in a WIUStatus message immediately after it occurs (e.g. event
driven) when it is not continuously beaconing. The messages shall continue to
beacon for the BeaconEnd time. If the "Broadcast on Change" parameter is
enabled, a WIU would always send a WSM on change. In the case of signal
territory where the plant would be dark if not beaconing continuously, no change
would be expected; but if there was a change it would be sent immediately. In
dark territory, where a switch change was detected a WSM shall be sent before a
heartbeat WSM.
4.1.28 Where status inputs may be temporarily in an invalid state (e.g: searchlight
mechanism passing through red when changed from yellow to green) a
debounce time of the input, input status, device status that does not meet the
library rules, or other method shall be configurable. The debounce time should
be configurable from mainloop time to 6 seconds. For WIUs where the debounce
is done on the Wayside Device Statuses (as opposed to the WIU inputs) and a
particular status is determined to be invalid, the last known valid state should be
held either a) for the length of the debounce timer or b) until a valid state is
evaluated that matches the mechanism control.
4.1.29 Device Statuses shall be able to be debounced for (e.g.: switch, hazard detector,
etc.). The debounce time may be configured in the wayside application program
or in the PTC application program. The time should be configurable from
mainloop time to 6 seconds.
4.1.30 The WIU shall ensure that the transmission of a device status change message
(WSM) using Class D to the ITCM is completed (placed on network medium) in
less than (configurable broadcast rate + 400 ms) . (for example if the default
broadcast rate of 1000 ms is used this would require the WIU to ensure that the
device status (WSM) is available for consumption by the ITCM using Class D
transport in less than 1400 ms). This requirement covers the period from when
the WIU determines that a wayside device status changes until that status
change (WSM) is available over Class D message (WSM) for consumption by
the ITCM.
4.1.31 The methodology of configuring the WIU shall support processes for the
managing and configuring the WIU so that process conforms to and supports all
FRA Requirements for Configuration Management (See 236 Subpart H and I).

Page 11 of 47

Interoperable Train Control Wayside Interface Requirements

 Access shall be available for extracting/downloading configuration information
without service interruption.
4.1.32 The compiler/tools for the WIU application program shall allow an authorized
user to configure the size of the target fields in the WIU-Message (WSM), to map
configuration and device information into these fields, and to alert if the data in a
field being moved / converted would exceed the configured field size.
4.1.33 The compiler/tools for the WIU application program shall ensure that it does not
accept address assignments that would overflow the specified address size.
(consistency/range checking)
4.1.34 The compiler/tools for the WIU application program shall ensure that it does not
generate messages with message types that will overflow the specified message
type size. (consistency/range checking)
4.1.35 The compiler/tools for the WIU application program shall ensure that it does not
generate messages with message versions that will overflow the specified
message version size. (consistency/range checking)
4.1.36 The compiler/tools shall be able to put out an XML file (reference XML schema –
WIU_config.xsd) that will include as much of the information as available to be
used for populating the track database and configuration management
information. All fields shall be editable.
4.1.36.1 TimeStamp (Schema version, timestamp)
4.1.36.2 WIUAddress (EMP address)
4.1.36.3 WIUName
4.1.36.4 BeaconFlag
4.1.36.5 EncrypedHMACkey
4.1.36.6 ConfigCRC for use on in the decrypting HMAC
4.1.36.7 ApplicationProgramName (PTC application name for configuration
management use.)
4.1.36.8 ApplicationProgramCRC (PTC application program CRC for
configuration management use.)
4.1.36.9 DeviceStatusConfigSCAC
4.1.36.10 DevideStatusConfigTableID
4.1.36.11 DeviceStatusConfigVersion
4.1.36.12 DeviceType (signal, switch, hazard detector).
4.1.36.13 SiteDeviceID (railroad specific Object ID number)
4.1.36.14 Description (2W, 2E, 1, 3, etc.), SiteName, TrackName,
SubdivisionNumber, and Milepost
4.1.36.15 WIUStatusIndex (bit offset numeric 0-1943)

Page 12 of 47

Interoperable Train Control Wayside Interface Requirements

 Figure 1 - WIU Config File Schema

Page 13 of 47

Interoperable Train Control Wayside Interface Requirements

 Figure 2 - Device Type File Schema

Page 14 of 47

Interoperable Train Control Wayside Interface Requirements

4.1.37 The WIU addresses (EMP, WIU) shall be configurable. The WIU address is a
whole number representing an ATCS address. The WIU address shall be
entered as a 12 digit number. The ATCS address shall be converted to a 40 bit
binary number and used in the wayside message body. The WIU address used
in EMP headers (e.g.: bnsf.w.lllggg:ss.wiu) shall use the lllgggss number as
originally entered. The WIU shall require configuration of a unique logical 40-bit
address for each WIU.
4.1.38 The WIU shall provide the capability to map device statuses
(WIUDeviceStatuses) for the WIUStatus Message. This provides the ability to
manually place the signals, switches, and hazard detectors in any order within
the vital payload.
4.1.39 The WIU shall support the ability to remotely update configuration parameters as
shown on Section 8, Table 7 – Configurable Parameters Summary.
4.1.40 (Item removed)
4.1.41 The WIU shall provide the capability to store any configuration information
required to support Class C, Class D, and ITCM messaging, including an internet
protocol (IP) address, an IP network mask, and an optional IP gateway.
4.1.42 (Item removed)
4.1.43 The WIU shall support the EMP Message Format specifications for generating
unique message numbers incremented for each message that it broadcasts.
4.1.44 The WIU shall support the EMP Message Format specification for generating a
time stamp (absolute time) for each message that it broadcasts.
4.1.45 The WIU shall provide the capability to store an IP multicast address and any
other required information to be used in support of the Class C protocol for a
WIU. The IP multicast address is used to receive time sync messages.
4.1.46 The WIU shall provide default values for all field configurable parameters. See
Section 8.
4.1.47 In a vital logic controller system with integrated WIU functionality, any failures of
WIU-specific hardware within the vital logic controller system shall not impair the
basic signaling function of the equipment.
4.1.48 Internal WIU for retrofit of existing controller shall be designed to minimize
disarrangement and validation testing.
4.1.49 In a vital logic controller system with integrated WIU functionality, it shall be
possible to update the WIU application software without affecting the vital logic
controller operation.
4.1.50 The WIU shall generate a configurable vital payload representing the wayside
statuses shown as Device Status in Table 1 – WIUStatus Message Body shows
the message body transmitted by the WCM
4.1.51 WSMDeviceStatus shall be padded with zeros to fill out the last byte.
4.1.52 Unrecognized message versions and message types, received by the WIU shall
be discarded and the message not utilized by the WIU. If the BeaconOn or
GetWIUStatus message received is over 12 seconds old, the message shall be
acted upon.

Page 15 of 47

Interoperable Train Control Wayside Interface Requirements

 Descriptio Size in Notes
n bits
WIU address 40 bits • ATCS Type Address
IRRRLLLGGGSS Numeric
BeaconTTL 1 bit • Beacon expiration
Vital message type 6 bits • Defined by WIU
Vital message 5 bits
version
Mod 16 time 4 bits • Modified timestamp
Message Sequence 8 bits • 0-255 binary
Number
Device status 1-1944 • Device status
bits • Generated by WIU
VDIV 32 bits • HMAC vital data integrity
value
• Calculated by WIU
Table 1 - WIUStatus Message Body
4.1.53 WIU shall generate WSMs defined in Table 1 – WIUStatus Message Body as
EMP messages transported over Class D using the following EMP message
format when beaconing.

Group Field Size Values Description

(in
bits)
EMP ProtocolVersion 8 0x4(4) Version of EMP header
Header
MessageType 16 5100 Decimal Application message ID
MessageVersion 8 0 Application message
version
Flags 8 Options used in
constructing the header
DataLength 24 bits 12 bytes + Size of message body
DeviceStatus field
length
MessageNumber 32 0 = no sequence Application level
number message ID or
sequence number
MessageTime 32 32 bit message time Time of message
per EMP creation

Page 16 of 47

Interoperable Train Control Wayside Interface Requirements

Group Field Size Values Description
(in
bits)
specification
VariableHeaderSize 8 (size of remaining Size of the remainder
header) (variable portion) of the
header
TimeToLive 16 12 (default, Time in seconds that the
configurable) comm system should
continue to attempt
delivery of the msg
QoS 16 Field Configurable Quality of Service for the
msg
Source Up to (WIU address) Source address for the
64 message
bytes ns.w.lllggg:ss.wiu
bnsf.w.lllggg:ss.wiu
up.w.lllggg:ss.wiu
csx.w.lllggg:ss.wiu
Destination Up to (from configuration) Destination address for
64 the message
bytes XX.L.X.000000:tmc (general
broadcast address, where XX
is any railroad, and X.000000
is any locomotive.

Body WIUAddress 40 (7RRRLLLGGGSS ATCS type address

40 bits)
Beacon TTL 1 0 or 1 When True, indicates
that the beacon will not
expire (go into sleep
mode) soon (in a
configurable amount of
time)
VitalMessageType 6 1
VitalMessageVersion 5 0
Mod16Time 4 (low order 4 bits of
timestamp)
MessageSequenceNumbe 8 bits 0-255 binary
r
DeviceStatus 1 to (device status) Device status generated
1944 by WIU
VitalDataIntegrityValue 32 (HMAC) Calculated by WIU
EMP Data Integrity 32 CRC per EMP spec Calculated on entire
CRC message (header and
body) Calculated by
Page 17 of 47

Interoperable Train Control Wayside Interface Requirements

Group Field Size Values Description
(in
bits)
WIU.

Table 2 - Message Format WIUStatus Timed Beacon

4.1.54 WIU shall generate one WSM as defined in Table 1 – WIUStatus Message Body
as an EMP message transported over Class D using the following EMP message
format when in response to each GetWIUStatus message from the Locomotive.

Group Field Size Values Description

(in
bits)
EMP ProtocolVersion 8 0x4(4) Version of EMP header
Header
MessageType 16 5101 Decimal Application message ID
MessageVersion 8 0 Application message
version
Flags 8 Options used in
constructing the header
DataLength 24 bits 12 bytes + Size of message body
DeviceStatus field
length
MessageNumber 32 0 = no sequence Application level
number message ID or
sequence number
MessageTime 32 32 bit message time Time of message
per EMP creation
specification
VariableHeaderSize 8 (size of remaining Size of the remainder
header) (variable portion) of the
header
TimeToLive 16 12 (default, Time in seconds that the
configurable) comm system should
continue to attempt
delivery of the msg
QoS 16 Field Configurable Quality of Service for the
msg
Source Up to (WIU address) Source address for the
64 message
bytes ns.w.lllggg:ss.wiu
bnsf.w.lllggg:ss.wiu
up.w.lllggg:ss.wiu

Page 18 of 47

Interoperable Train Control Wayside Interface Requirements

Group Field Size Values Description
(in
bits)
csx.w.lllggg:ss.wiu

Destination Up to (EMP address of Destination address for

64 GetWIUStatus the message
bytes sender)
Body WIUAddress 40 (7RRRLLLGGGSS ATCS type address
40 bits)
Beacon TTL 1 1 The GetWIUStatus
resets the Beacon TTL
to 1
VitalMessageType 6 2
VitalMessageVersion 5 0
Mod16Time 4 (low order 4 bits of
timestamp)
MessageSequenceNumbe 8 bits 0-255 binary
r
DeviceStatus 1 to (device status) Device status generated
1944 by WIU
VitalDataIntegrityValue 32 (HMAC) Calculated by WIU
EMP Data Integrity 32 CRC per EMP spec Calculated on entire
CRC message (header and
body) Calculated by
WIU.

Table 3 - Message Format WIUStatus In Response to GetWIUStatus

4.1.55 The WIU determines which message to send based on the message type in the
EMP header.
4.1.56 The WIU shall receive Locomotive to Wayside message GetWIUStatus as an
EMP message delivered over Class D with the following EMP message format.
The WIU shall only act upon GetWIUStatus messages addressed to it’s WIU
address.

Group Field Size Values Description

(in
bits)
EMP ProtocolVersion 8 0x4(4) Version of EMP header
Header
MessageType 16 5201 Decimal Application message ID

Page 19 of 47

Interoperable Train Control Wayside Interface Requirements

Group Field Size Values Description
(in
bits)
MessageVersion 8 0 Application message
version
Flags 8 Options used in
constructing the header
DataLength 24 bits 0 Size of message body
MessageNumber 32 0 = no Application level message
sequence ID or sequence number
number
MessageTime 32 32 bit message Time of message creation
time per EMP
specification
VariableHeaderSize 8 (size of Size of the remainder
remaining (variable portion) of the
header) header
TimeToLive 16 12 (default, Time in seconds that the
configurable) comm system should
continue to attempt
delivery of the msg
QoS 16 Loco Quality of Service for the
Configurable msg
Source Up to (Loco) Source address for the
64 message
bytes
Destination Up to (WIU address) Destination address for the
64 message
bytes
EMP Data Integrity 32 HMAC Calculated on entire
CRC message (header and
body) Verified by WIU.

Table 4 - Message Format GetWIUStatus

4.1.57 The WIU shall receive Locomotive to Wayside message BeaconOn as an EMP
message delivered over Class D message with the following EMP message
format. The WIU shall only act upon the BeaconOn messages addressed to it’s
WIU address.

Page 20 of 47

Interoperable Train Control Wayside Interface Requirements

Group Field Size Values Description
(in
bits)
EMP ProtocolVersion 8 0x4(4) Version of EMP header
Header
MessageType 16 5200 Decimal Application message ID
MessageVersion 8 0 Application message
version
Flags 8 Options used in
constructing the header
DataLength 24 bits 0 Size of message body
MessageNumber 32 0 = no sequence Application level message
number ID or sequence number
MessageTime 32 32 bit message Time of message creation
time per EMP
specification
VariableHeaderSize 8 (size of Size of the remainder
remaining (variable portion) of the
header) header
TimeToLive 16 12 (default, Time in seconds that the
configurable) comm system should
continue to attempt delivery
of the msg
QoS 16 Loco Quality of Service for the
Configurable msg
Source Up to (Loco) Source address for the
64 message
bytes
Destination Up to (WIU address) Destination address for the
64 message
bytes
EMP Data Integrity 32 HMAC Calculated on entire
CRC message (header and
body) Verified by WIU.

Table 5 - Message Format BeaconOn

Page 21 of 47

Interoperable Train Control Wayside Interface Requirements

4.2 Other Requirements – General
4.2.1 System shall conform to AREMA Manual Part 1.4.1 (Identical Items “Boilerplate”
for All Manual Parts) sections on Dielectric Requirements and Painting.
4.2.2 System shall withstand voltage surges in sensor(s), input, output and power
supply leads when protected as described in AREMA Manual Part 11.2.1
(Recommended General Practices for Electrical Surge Protection for Signal
Systems), and as required by the manufacturer.
4.2.3 Device(s) shall meet surge withstand requirements of AREMA Manual Part
11.3.3 (Recommended Design Criteria for Surge Withstand Capability of
Electronic Signal Equipment for Signal Systems).
4.2.4 Device(s) shall conform to requirements set forth in Federal Communications
Commission Rules Part 15 for spurious RF emissions.
4.2.5 System operation shall not be susceptible to electrical noise commonly found in
the wayside railroad environment. All apparatus designated as vital shall be fail-
safe in all modes of operation.
4.2.6 Manufacturer shall provide documentation of system hardware, software,
organization, and quality control to prove and demonstrate failsafe performance
as specified by the user.
4.2.7 System shall conform to AREMA Manual Part 11.1.1 (Recommended
Functional/Operating Guidelines for Electrical Safety).
4.2.8 Supplier shall also support the product per the requirements of the CFR 236 PTC
regulations.
4.2.9 System should provide or attempt to provide high availability. Shutdown due to
failures should be orderly and sequenced to prevent system shutdown except
when required to maintain system vitality. System design should support graceful
degradation.

4.3 Environment
4.3.1 System shall conform to AREMA Manual Part 11.5.1 (Recommended
Environmental Requirements for Electrical and Electronic Railroad Signal
System Equipment). Each component of the system shall conform to the
appropriate class for the environment in which it is located.

4.4 Electrical Design

4.4.1 Systems operated with power supplied by the Railroad shall conform to AREMA
Manual Part 1.5.15 (Recommended Practice for Electrical Interfaces between
Signal, Train Control and Grade Crossing Equipment).
4.4.2 System shall be designed not to introduce earth ground into vital power sources.
See AREMA Manual Part 16.3.2 (Recommended Application Design Guidelines
for Isolation of Power Supplies Used in Vital Signal Systems). Ethernet, shielded
Ethernet. USB or any other external connections shall not introduce earth ground
into vital power sources.
4.4.3 System should be designed to minimize power requirements for existing signal
installations as well as solar, wind, or alternative power installations.

Page 22 of 47

Interoperable Train Control Wayside Interface Requirements

4.5 System and Safety Assurance
4.5.1 Systems shall be designed in accordance with the following Manual Parts, or
equivalent.
4.5.1.1 AREMA Manual Part 17.2.1 (Recommended Quality Assurance Program
for Electronic and/or Software Based Products Used in Vital Signal
Applications).
4.5.1.2 AREMA Manual Part 17.3.1 (Recommended Safety Assurance Program
for Electronic/Software Based Products Used in Safety-Critical (Vital)
Applications).
4.5.1.3 AREMA Manual Part 17.4.1 (Recommended Reliability and
Maintainability Assurance Program for Electronic/Software Based
Products Used in Vital Signal Applications).
4.5.1.4 AREMA Manual Part 17.5.1 (Recommended Configuration Management
Program for Electronic/Software Based Products Used in Vital Signal
Applications).

4.6 Mechanical Design

4.6.1 Systems intended for installation in wayside instrument housings should be
housed in an enclosure suitable for shelf, backboard or Electronic Industries
Alliance (EIA) rack.
4.6.2 System packaging should utilize field replaceable plug or terminal connected
modules to facilitate testing and maintenance.
4.6.3 Electrical and/or mechanical keying of plug-in modules shall be employed to
prevent unsafe operation due to incorrect substitution of modules. Identification
of plug-in modules and their respective location should be provided.
4.6.4 All field replaceable modules of the same type should be interchangeable without
adversely affecting the location-specific programming of the system.
4.6.5 All connections to external safety critical apparatus and dc power, where safety
is assured by physical isolation between connectors, shall conform to Manual
Parts in Section 14.1 (Recommended Wire Connectors, Terminals).
4.6.6 All connections to external electronic vital and non-vital signal apparatus shall be
as described in number 5 above or by means of user approved plug couplers.

4.7 Other Design Requirements

4.7.1 Potential hazards due to repeated restarts shall be considered in the required
safety analysis.
4.7.2 System shall not generate any permissive outputs until initialization software and
hardware tests have been completed to determine that the system is operating
properly as designed.
4.7.3 (Item deleted.).

Page 23 of 47

Interoperable Train Control Wayside Interface Requirements

4.8 Software Design
4.8.1 All executive and vital system software (including all self-checks) shall be
programmed by the manufacturer.
4.8.2 All executive and location specific system software (including all self checks)
shall be installed in the system in a manner that shall prevent unintentional
changes by the user.
4.8.3 When aggregating device statuses from multiple WIU’s to combine into a single
WSM, the system shall be capable of vital communication with other similar
systems. Communication protocol should be programmed by the manufacturer.
4.8.4 (Item deleted.)
4.8.5 Standalone WIU system shall be capable of any relay equivalent such as slow
pickup, slow release, or providing slow pickup and release, with all time delays
being vital. Time delays shall be individually programmed. The range of time
delay should be at least 1 second to 30 minutes.
4.8.6 System should have internal diagnostics, built-in displays, and provision to
internally store failure data to permit rapid troubleshooting. System shall have
provision for online monitoring of the status of inputs, outputs, and internal relay
equivalents, without system shutdown or disturbance of normal operation.
4.8.7 (Item deleted.)
4.8.8 System shall automatically reset and attempt restart after an external condition
causing system shutdown (power failure, loss of vital communication link, etc.) is
eliminated.
4.8.9 System shall provide for generation of location specific vital system logic
software. All mechanisms for generating location specific vital system logic shall
employ a validated compiler, with validation of the compiler being the
responsibility of the system manufacturer. System manufacturer shall also
provide a means for transferring the compiled code files into non-volatile system
memory. This process shall verify the integrity of the data transferred against the
output of the validated compiler. Refer to AREMA Manual Part 17 (Quality
Principles).
4.8.10 The field length of inputs, outputs, and internal relay equivalents of the system
should be identified in the software by alphanumeric names to allow at least 12
characters. Names may be specified by the user.
4.8.11 System should support software being divided into the following separate and
distinct sections, as required:
4.8.11.1 Software defined system control statements.
4.8.11.2 Software defined system indicator statements.
4.8.11.3 Vital local input and output definition statements.
4.8.11.4 Vital remote input and output definition statements.
4.8.11.5 Vital serial communication input and output definition statements.
4.8.11.6 Non-vital local input and output definition statements.
4.8.11.7 Non-vital remote input and output definition statements.
4.8.11.8 Non-vital serial communication input and output definition
statements.
4.8.11.9 Internal relay equivalent definition statements.
4.8.11.10 Time delay and flashing/coding definition statements.
4.8.11.11 Application logic statements.

Page 24 of 47

Interoperable Train Control Wayside Interface Requirements

4.8.12 When changes are required at a location, a means shall be provided to verify all
location specific software. Manufacturer should provide a means to identify all
system software installed and running without system shutdown or disturbance of
normal operation. At a minimum this information shall include revision name,
revision number, revision date, and CRCs.

Page 25 of 47

Interoperable Train Control Wayside Interface Requirements

5 Keyed-Hash Message Authentication Code
(HMAC)
5.1 The WIU shall include the capability to calculate a Keyed-Hash Message Authentication
Code (HMAC) through a designated message authentication / protection algorithm as
described below.
5.2 The WIU shall include capability to store in non-volatile memory and use any information
such as “encrypted keys and certificates” (HMAC Key, RC2 Key) that are necessary to
support the HMAC calculations.
5.3 The WIU shall include the capability to decrypt the stored encrypted HMAC keys using
the RC2 encryption algorithm.
5.4 The WIU shall ensure that the RC2 embedded password used to decrypt keys used in
the HMAC calculations is not made available (viewable) to field personnel. . A tool will be
provided by the manufacturer to encrypt the RC2 embedded password for delivery to the
field.
5.5 The WIU shall provide the capability to include the WIU clock time (UTC (including leap
seconds) expressed as a 32 bit absolute number (32 bit message time per EMP
specification) representing the number of seconds since midnight, January 1, 1970) in
the calculation of the HMAC.
5.6 WIU shall accept x.509 certificate for use with remote web interface.
5.7 The WIU ConfigCRC included in the HMAC calculation shall include the PTC
application’s CRC. When the WIU program allows field configurable configurations of
heads, lamps, switches, hazard detectors, and offset in message, the CRC shall also
include those configurations. When WIU is hosted internally, WIU ConfigCRC shall
reflect application CRC (or CRC for vital lamp statuses) of the hosting equipment.
Depending on the vendor’s executive, recompiling the PTC application should not be
required when changing the wayside application logic. Supplier shall furnish a tool that
will provide a CRC value to be used in the TMC’s on-board database for HMAC
verification. The tool shall calculate a WIU CRC based on vital application CRC and
WIU configurations of heads, lamps, switches, hazard detectors, and offset in message;
but not WIU address.
5.7.1 The HMAC generated by the WIU and TMC shall be implemented as a
“truncated SHA-1” as described in Federal Information Processing Standards
(FIPS) publication 198, “The Keyed-Hash Message Authentication Code
(HMAC).” Section 4 of that document specifically describes how to truncate the
160-bit message digest to 32 bits. Figure 3 - WIU WSM HMAC Generation
illustrates the HMAC generation at the WIU. Figure 4 WIU HMAC Validation of
LRM illustrates the HMAC check at the WIU.
5.7.2 The RC2 Key and HMAC Key are PTC operating values. PTC operating values
are any value used in message validation by Train Management Computer TMC
and/or any value used for message space configuration or coordination.
5.7.3 PTC operating values shall not reside in the WIU executive, WIU compiler or the
WIU application program. Changes in PTC operating values shall not result is a
corresponding version change in WIU compiler, executive, and/or application
program name/checksums/CRCs/date of compilation. Alternatively, revisions to
WIU complier, executive, and/or application program
name/checksums/CRCs/date of compilation shall not result in a change in PTC
operating values. The intent is to not store the decrypted HMAC Key and RC2
Key in the various WIU software.
5.7.4 PTC operating values shall reside in a separate memory space in the WIU. The
WIU should be provided with an independent utility for modifying/updating PTC
operating values. The memory space can be expandable and utility designed to

Page 26 of 47

Interoperable Train Control Wayside Interface Requirements

 allow additional operating values to be loaded into the WIU as the PTC system
message specifications needs change and grow. WIU vendor shall include utility
for maintaining PTC operating values as part of WIU maintenance tools.
5.7.5 PTC operating values must not be maintained in the unsecured databases or
databases with wide access. Railroad databases will track WIU application
program names, checksums, CRCs, date of compilation and WIU executive
software versions.
5.7.6 Therefore, modification/maintenance of (PTC operating values) and (WIU
application program names, checksums, CRCs, date of compilation, WIU
executive software versions) shall be mutually exclusive.
5.7.7 PTC operating values, versions of WIU software utilities, and versions of WIU
executive will be available prior to rolling out installations.
5.7.8 The WIU shall include the ability to modify Encrypted HMAC Key via wireless
communications by the back office.
5.7.9 RC2 Key changes do not affect WIU ConfigCRC.
5.7.10 HMAC Key changes do not affect WIU ConfigCRC.
5.7.11 RC2 key can be changed in the field but not viewable.
5.7.12 The RC2 key shall be able to be copied to the WIU.
5.7.13 Encrypted HMAC shall be able to be copied to the WIU.
5.7.14 The non-encrypted HMAC key size is fixed at 20 bytes. The encrypted size is 24
hex bytes. The RC2 key is 20 bytes. Trailing 0’s in the entered 20-byte RC2 key
shall be truncated, and the truncated value is used in the computation. If a
shorter HMAC string is entered, it shall be padded with 0’s to make 24 bytes.
5.7.15 The key should be provided in a txt format for cut and paste or copy operation to
the WIU
5.7.16 The initialization vector utilized shall be 0s.

Extended HMAC Data (64) Over-the-air Payload (varies)

WIU WIU WIU Bea- Msg. Msg. Mod Msg, Wayside HMAC
Clock Config. Source con Type Ver. 16 Seq. Status
CRC Address TTL Time Num. (1-1944 (32)
(32) (32) (40) (1) (4) (8) bits)

Truncated
RC2 Decryption SHA-1
Key
WIU Configuration or Static Data

Encrypted Decrypted Dynamic WIU Data

HMAC RC2 HMAC
Key Key Computation

Figure 3 - WIU WSM HMAC Generation

Page 27 of 47

Interoperable Train Control Wayside Interface Requirements

 EMP Header HMAC
(32)

HMAC Comparison
Truncated To Message
(32) HMAC
SHA-1
RC2 Decryption
Key WIU Configuration or Static Data

WIU Dynamic Data

Encrypted Decrypted
HMAC RC2 HMAC TMC Message Data
Key Key
Computation

Figure 4 - WIU HMAC Validation of LRM

Page 28 of 47

Interoperable Train Control Wayside Interface Requirements

6 Wayside Codes
6.1 The WIU shall be capable of supporting individual railroad aspect rules in a compiled
application.
6.2 Table 6 – Signal Names Codes describes codes assigned for each indicated device.

Signals Signals are indicated with 5 bits.

See individual railroad for the table of aspect codes.

Switches Switches are indicated with 2 bits.

10 Normal
01 Reverse
00 Non-Indicating (in transition)
11 Error

Hazard Detectors (High water, slide, slump, ballast movement, track

Hazard integrity, bridge alignment, bridge impact, fire, etc.) are indicated with 1
Detectors bit.
1 Normal (Ok)
0 Non-indicating (Detected hazard)
Table 6 - Signal Names Codes
A code for an improperly displayed signal should be used when a signal not conforming to the
aspect table in the PTC program is detected. 00 for switches is unknown state and 0 for hazard
detector is the only acceptable codes for an unknown state.
31 = Invalid (doesn't match aspect table, potential improperly displayed signal)
00000 = signal aspect for loss of communication to a vital wayside controller
00 = switch loss of communication to a vital wayside controller or switch out of correspondence
11 = switch invalid (doesn't match table, improper indication).
0 = hazard detector loss of communication to vital wayside controller or detector detecting hazard

Page 29 of 47

Interoperable Train Control Wayside Interface Requirements

7 WIU Device Status Structure
7.1 This section defines how the WIU Device Status shall be stored in the vital payload
section of the WSM. This information shall be encoded and stored in the WSM by the
WIU. It will be accessed by the TMC. The Device Status Data in the vital payload portion
of the WSM shall be organized according to the following requirements:
7.2 The Signal Device Status shall be ordered such that the most significant N bits
(assuming a Device Status size of N) of the Device Status Data contain the status of
device index 0.
7.3 The most significant bit of the Signal Device Status shall contain the least significant bit
of the device status value.
7.3.1 Example: If the device status is 6 (00110) for a given signal, the bits are
reversed to give 01100. For a switch if the device status is normal (10) for the
switch, the bits are reversed to give 01.

Vital Payload Generated by the WIU

WIU Bea- Msg. Msg. Mod Msg. Wayside HMAC

Source con Type Ver. 16 Seq. Status (32)
Address TTL (6) (5) Time Num. (1-243
(40) (1) (4) (8) bytes)

Device Status Data

Device Device Device Device P

1 2 3 n a
State State State State d

Signal Aspect

LSB MSB

Switch Indication

RWR NWR

Hazard Detector

MSB

Figure 5 - WSM Device Status Data

Page 30 of 47

Interoperable Train Control Wayside Interface Requirements

 8 CONFIGURABLE PARAMETERS
Below contains a summary of the configurable parameters and an indication of whether the
parameter is configurable in the field or the factory. Default values are also included. A default
value of N/A indicates that each component is expected to have a different value for that field.
Each back office configurable parameter shall be able to be configured for local presence
required or local presence not required, (Yes, No, default = No).

Compo Parameter Configurable Default value Notes

nent in
WIU Broadcast rate Field or by 1000 ms (Greater of 1000
ms or Mainloop
back office time to 60
seconds)

WIU BroadcastOnChang Field or by No (Yes, No)

e (event driven) back office
WIU BeaconContinuous Field or by 1 1 = Continuous
0 = Times out
back office
WIU BeaconBitTime Field or by 300 seconds Time from Beacon
on until
back office BeaconTTL bit set
to 0 (60 to 1800
seconds)

WIU BeaconEnd Field or by 120 seconds Time from

BeaconTTL bit 0
back office until end of
beacon, Broadcast
rate stops. (60 to
1800 seconds)

WIU MaxBeaconInterval Field or by Disabled (If Interval between

Beacons when not
back office BeaconContinuous is 0 this continuously
defaults to 900 seconds) beaconing.
Location shall still
beacon a change
unless set to
Disabled.
(Disabled, 60 to
86400 seconds)

WIU Vital payload size Factory 1-255 bytes

limits
WIU Address size Factory 40 bits
WIU Message type size Factory 6 bits
WIU Message version Factory 5 bits
size
WIU WIUaddress Field 0
WIU X.509 Certificate Field or Back 0 Back Office
Office Encrypted
session

Page 31 of 47

Interoperable Train Control Wayside Interface Requirements

Compo Parameter Configurable Default value Notes
nent in
WIU RC2 key Factory/Field 0 Back Office
Encrypted
session
WIU HMAC Key Field or by 0 Back Office
back office Encrypted
session
WIU EMP header Field or by 0
source address back office
WIU Class C multicast Field or by 239.255.0.5
address back office
WIU Class C port Field or by 32768
address back office
WIU TimeToLive per Field or by Default as shown in EMP
EMP message back office message, configurable by
message type.
WIU EMP Dest Address Field or by XX.L.X.000000:tmc (general
(Timed Beacon) back office broadcast address, where XX is
any railroad, and X.000000 is any
locomotive.

WIU EMP Flags Field or by 1. Bit 0: Timestamp format Suggested

back office a. 0 = relative time defaults in
(elapsed time since bold.
last message Bits 3 and 4
creation) are set to
b. 1 = absolute time insert the
(UTC time HMAC in LRM
according to EMP Headers
specifications in
section EMP
Specification Flags =
3.2.2.2 Message 00001001 or
Timestamp) 00010001
Always set to 1.
2. Bit 1: Encryption
a. 0 = body is not
encrypted
b. 1 = body is
encrypted
3. Bit 2: Compression
a. 0 = body is not
compressed
b. 1 = body is
compressed
4. Bits 3-4: Data integrity
a. 0 = no data integrity
support
b. 1 = CRC calculated
Page 32 of 47

Interoperable Train Control Wayside Interface Requirements

Compo Parameter Configurable Default value Notes
nent in
per specifications
c. 2 = Application
specific data
integrity value
used
d. 3 = reserved
5. Bits 5-7: Reserved

WIU QoS per EMP Field or by As shown in EMP message

message back office
WIU Class D Mode Field or by Bidirectional
back office
WIU AG IP Address Field or by 10.255.255.210
back office
(Class D)
WIU AG Port Field or by 3001
back office
(Class D)
WIU Class D Keep Alive Field or by 30 sec
Interval back office
WIU Class D Field or by 15 sec
Acknowledgement back office
Timeout
WIU Class D Data Ack Field or by 15 sec
Timeout back office
WIU Class D NAK Retry Field or by 3
Count back office
WIU Class D Retransmit Field or by No
Delay back office
WIU Class D Connect Field or by 30 sec
Attempt Timeout back office
WIU Class D Connect Field or by 60 sec
Attempt Delay back office
WIU Class D Connect Field or by -1 ‐1 = forever
Attempt Retry back office (default)
Count
WIU Class D Reconnect Field or by -1 ‐1 = forever
Attempt Retry back office (default)
Count
WIU Class D Data ACK Field or by Yes
enabled back office
WIU Class D Log traffic Field or by No
back office
Page 33 of 47

Interoperable Train Control Wayside Interface Requirements

Compo Parameter Configurable Default value Notes
nent in
WIU Time Messages Field or by 5 Adjustable 1-
Before Sending back office 10
WSM
WIU Time Message Field or by 1 Adjustable 0-3
Deviation back office
WIU Ignored Time Field or by 3 Adjustable 1-
Difference back office 10
WIU Maximum Seconds Field or by 3 Adjustable 1-
Time Change back office 10
WIU Maximum Time Field or by 60 Adjustable 1-
Change within back office 120
Minutes
WIU LRM Maximum Field or by 3 Adjustable 0-
Seconds Time back office 20
Difference
WIU No Time Sync Field or by 6 (minutes) Adjustable 1-6
Message back office

Table 7 - Configurable Parameters Summary

Page 34 of 47

Interoperable Train Control Wayside Interface Requirements

9 Time Interface Specifications
The WIU shall maintain clock synchronization from an external device with a one second
resolution. Two methods shall be supported by the WIU for this synchronization. The WIU shall
be configurable to accept an EMP based time message transported over Class C, or the WIU
shall support the use of native IP NTP version 3 as specified in the IETF RFC 1305 or SNTP
version 4 as per RFC 4330, as a protocol for synchronizing the time clock. Both time
synchronization methods shall be required (EMP or NTP/SNTP), but only one shall be enabled in
the WIU’s configuration at a time.

The following is a detailed description of the EMP based time synchronization process and the
time change process in the WIU.

9.1 This section specifies the interfaces and protocols for GPS time delivered to the WIU
through the Ethernet connection.
9.2 The WIU clock must be updated on reboot/power up before any messages are
calculated. If the WIU is not able to maintain its internal clock to a +/-2 second accuracy
during loss of time synchronization messages, it shall stop transmitting WSMs and log an
error once it has reached a point in time it can no longer guarantee this accuracy.
9.3 In the absence of time information the WIU shall be capable of maintaining its WIU clock
time so that the drift from clock time does not exceed +/- 2000 ms for at least an 8 hour
period. WIU vendors may specify a duration greater than 8 hours. Over the life of the
product, once temperature and life are factored in, the clock drift shall not exceed +/-
2000 ms for at least a 2 hour period.
9.4 The time message sent over a link inside the bungalow from a local WCM does not need
HMAC on the time message.
9.5 If the WIU regains time information, the WIU shall resume transmitting WSMs.
9.6 WIU should receive a time sync message at a period of no less than every 30 seconds
9.7 The EMP header carries a 32 bit time stamp that indicates Absolute time, which is UTC
time expressed as the absolute number of seconds since midnight, January 1, 1970,
including leap seconds (32 bit message time per EMP specification). Using an absolute
value implies that times prior to the epoch are not supported (this allows a 32 bit valued
to not roll over until after the year 2100).
9.8 The EMP header time can be used as the basis for conveying time between the WCM
and the WIU. The WIU can use this data to update an internal clock. The EMP header
time is the time of the EPM message construction.
9.9 The Time message is defined so that it can be recognized as being sent as a time
update and be transmitted as near as practical to the start of the GPS second. The
message does not need to contain time data because it conveys the time within the EMP
header.
9.10 To limit time jitter, if a time message is received (see 9.14) with a time that is forward of
the clock time of the WIU, the time should be set forward to the new time. WIU System
Time should only be decremented if two Time Sync messages in a row indicate the need
to do so (except for the first Time Sync after Power up/ Reset).
9.11 A sequence number in the payload (8bit – 0-255) shall be used to verify message order.
All WSMs increment the sequence number.
9.12 WIU Main Menu shall display internal WIU UTC date and time as defined in 5.5.
9.13 On power up, re-syncing time after loss of time messages for more than 8 hours, or
reboot, the WIU shall set its internal WIU UTC time based on the first valid GPS time
message received. WIU shall not send WSM's until a configurable Time Messages
Before Sending WSM (default 5) valid GPS time messages are received (unless
Page 35 of 47

Interoperable Train Control Wayside Interface Requirements

 configured for NTP) each of which are within +/- a configurable Time Message Deviation
(default 1) seconds of the current internal WIU UTC time. The Class D link can be
established before the time messages are received, so the class D link is present for
Systems Management, even if time updates are not present.
9.14 A single time message shall be ignored if received with a time message outside of the
configurable Ignored Time Difference (default 3) seconds from the internal WIU UTC
time - other than at power up, re-syncing time after loss of time messages more than 8
hours, or reboot. WIU shall cease sending WSM's upon receiving consecutive time
messages with configurable ± 3 sec time change - other than at power up, re-syncing
time after loss of time messages more than 8 hours, or reboot.
9.15 The WIU shall cease sending WSMs if the cumulative effect of GPS time updates
causes the internal WIU UTC time to drift (forward or backward) more than the
configurable Maximum Seconds Time Change (default 3) seconds over the configurable
Maximum Time Change Within Minutes (default 60) minutes. The Maximum Time
Change Within Minutes constitutes a sliding window of time within which each past GPS
time update represents a data point for calculating the drift..
9.16 WIU shall alarm the failure conditions of the two previous statements above with a
systems management message and display the alarm that caused the stoppage on the
main menu.
9.17 The WIU shall generate an alarm if a LRM is received that is greater than the LRM
Maximum Seconds Time Difference (default 3) in the future.
9.18 The WIU shall generate an alarm if a Time sync message is not received after power on
or reboot after No Time Sync Message default 6 minutes.

Group Field Size Values Description

(in
bits)
EMP ProtocolVersion 8 0x4(4) Version of EMP header
Header
MessageType 16 5300 Decimal Application message ID
MessageVersion 8 0 Application message
version
Flags 8 Options used in
constructing the header
DataLength 24 bits 0 Size of message body
MessageNumber 32 0 = no Application level message
sequence ID or sequence number
number
MessageTime 32 32 bit timestamp Time of message creation
VariableHeaderSize 8 0 (size of Size of the remainder
remaining (variable portion) of the
header) header

TimeToLive 16 N/A Time in seconds that the

comm system should
continue to attempt delivery
of the msg
QoS 16 N/A Quality of Service for the

Page 36 of 47

Interoperable Train Control Wayside Interface Requirements

Group Field Size Values Description
(in
bits)
msg
Source Up to N/A Source address for the
64 message
bytes
Destination Up to N/A Destination address for the
64 message
bytes
EMP Data Integrity 32 CRC per EMP Calculated on entire
CRC spec message (header and body)
Verified by WIU.

Table 8 - Message Format Time

Page 37 of 47

Interoperable Train Control Wayside Interface Requirements

10 Diagnostics and Systems Management

10.1 Diagnostics
Local User Interface:
10.1.1 An Ethernet web-based interface shall be provided to upload the PTC program
and parameters to the WIU. A USB interface should be provided to upload the
PTC program and parameters to the WIU. These same interfaces shall allow
download of logs, program and parameters from the WIU and to be able to view
and print WIU parameter settings and program information. During the upload
the WIU shall continue to operate in revenue service while diagnostic port is
being accessed.
10.1.2 Any WIU settings that can affect the safety, vitality, or critical performance of the
system shall be password protected and require local presence to take effect,
unless covered by another methodology (certificates).
10.1.3 Vital and safety related modifications are to be performed through USB or
Ethernet ports with proper system approval.
10.1.4 A minimum of the following visual status indications should be provided on the
WIU. Other diagnostic indications or displays should be provided as necessary
to troubleshoot the WIU:
10.1.4.1 No Fault (System operation)
10.1.4.2 Transmit (each port)
10.1.4.3 Receive (each port)

10.2 Systems Management

10.2.1 System management messages are intended to do what they say to add little
additional complexity and be much clearer. They should be as simple as
“Command reboot” instead of “Set rebootTime=5sec”.
10.2.2 If the system management message is an EMP message based application it
should be managed with EMP messages
10.2.3 If the system management is an ITCM component then management should be
managed with ITCM System Mangement messages
10.2.4 Refer to the Wayside System Management Guidelines for other system
management requirements.
10.2.5 SNMP shall be supported for IP connected units and SMP for over the air, radio
connected, units.
10.2.6 SMP shall be implemented as soon as practicable after release of ITC SMP
documentation.

Page 38 of 47

Interoperable Train Control Wayside Interface Requirements

 Wayside System Management Information

The following statuses to be available remotely unless otherwise stated.

Status requirements are listed below. Messag Message QOS Payload Payload
e Type Type Length
Get1 Respons
e
Current Aspect/Indication State: Upon remote Varies See Vital
request or at time intervals set by railroad or Wayside
required by regulations Message
Varies See Vital
New Aspect/Indication State: Upon remote Wayside
request or at time intervals set by railroad. Message
16 bits Binary
value
Battery voltage
Varies Binary
values per
I/O Status (inputs and outputs standalone unit) board
Varies Failure
codes (4
digit hex)
WIU Board Status (Health) per board
Varies Failure
codes (4
digit hex)
Overall device status (Communication ports) per port
Inspection/Query requirements are listed below. Messag Message QOS Payload Payload
e Type Type Length
Get Respons
e
Software Type Varies Text
Equipment/Name/Version/CRC/Checksum/Dat string,
e of Compilation (Executive and application) comma
delimited
Vital Controller Status (Hosted) Varies Failure
codes (4
digit hex)
per board
WIU Status (software health) Varies Failure
codes (4
digit hex)

Page 39 of 47

Interoperable Train Control Wayside Interface Requirements

HMAC Rejection (Quantity over time) since 16 bits
midnight UTC
Message Rejection (Quantity over time) since 16 bits
midnight UTC
Event Log (limited use over RF) Varies Text

Error Log (limited use over RF) Varies Text

Alarm log (limited use over RF) Varies Text

Diagnostics requirements are listed below. Messag Message QOS Payload Payload
e Type Type Length
Get Respons
e
Loop Back Tests (All communications assets Varies Text
and WIU) move to another group
Low Battery voltage – Individual devices - 16 bits Binary
Code unit, WIU value
Lost local communications links. Varies Text
Device Errors (WIU, Communication assets, Varies Failure
vital logic controller) codes (4
digit hex)
per item
Individual board error, comm. errors or down, Varies Failure
etc. errors codes (4
digit hex)
per item
All Aspect State Change( Signals, Switches, Varies Failure
and Hazard Detectors) errors codes (4
digit hex)
per item
WIU Failures - ELM/AG internal error(s) Varies Failure
codes (4
digit hex)
per item
WIU Failures - Manufacturer Specific (Memory, Varies Failure
Logic, Software) codes (4
digit hex)
per item
HMAC Rejection 0
Message Rejection 0
Configuration management anomalies Varies Failure
codes (4
digit hex)
per item
Time Synchronization Errors (time since sync) 24 bits

Page 40 of 47

Interoperable Train Control Wayside Interface Requirements

Control requirements are listed below. Messag Message QOS Payload Payload
e Type Type Length
Get Respons
e
Shutdown/Restart/Reboot (Communication 0
assets and WIU)
Beacon On/Off 1Bit

GetWIUStatus Message 32 See Get

WIUStatu
s
Message
BroadcastRate (ms) 16 bits

BroadcastOnChange 1 Bit

BeaconContinuous 1 Bit

BeaconBitTime 16 bits

BeaconEnd 16 bits

MaxBeaconInterval 16 bits

Encrypted HMAC Certificate (secure link) Varies

List the Configuration Management Messag Message QOS Payload Payload

requirements below. e Type Type Length
Get Respons
e

Change RC2/Certificates/Keys (secure link) Varies

Configuration Changes/Software Upgrades or Varies

patches
List the System Management Alarm Messag Message QOS Payload Payload
requirements below. e Type Type Length
Respons
e
Loss of time messages for more than 8 hours,
time change by more than 3 seconds, initial
time messages not within +/- the configurable
Time Message Deviation (default 1) seconds of
the current internal WIU UTC time, LRM is
received that is greater than the Maximum
Seconds Time Change (default 3), GPS time
messages change (forward or back) internal
WIU UTC time more than the configurable
Maximum Seconds Time Change (default 3)
seconds in the configurable Maximum Time
Change within Minutes (default 60) minutes,
Time sync message is not received after power

Page 41 of 47

Interoperable Train Control Wayside Interface Requirements

 on or reboot after 6 minutes if Class D is
available
Low battery

Card failures,

Loss of AC power

Temperature outside of range

Door open

WIU health

Aspect state unknown (error)

Switch position error

Table 9 - Wayside System Management Messages

Page 42 of 47

Interoperable Train Control Wayside Interface Requirements

11 Power Supply and I/O Requirements for
Standalone WIUs

11.1 Power Supply Ratings

11.1.1 Power supplies shall conform to AREMA Manual Part 1.5.15 (Recommended
Practice for Electrical Interfaces between Signal, Train Control and Grade
Crossing Equipment). The power supply voltage category shall comply with
Voltage Category 1 and 4.

Voltage DC Voltage Voltage Maximum Maximum Typical

Category Source Range DC Ripple Battery
Nominal/
VDC Withstand Voltage Configuration
Description
Voltage Vp-p
VDC
1 12 Volt 10.0 – 16.5 18.0 1.2 6–7 cells LA
Operating
9–10 cells NiCad
4 12 Volt Control 10.0 – 16.5 18.0 1.2 6–7 cells LA
9–10 cells NiCad

Table 10 - Power Supply Ratings

11.1.2 Included within the Maximum DC Withstand Voltage is the maximum level that
may be seen in the event that the equipment is connected only to a half-wave
rectifier used for charging the batteries. Equipment is not required to work on the
half-wave rectified source but its effects (e.g. if the battery was disconnected)
must be considered in the safety analysis.
11.1.3 When battery voltage is lower than the WIU’s operating limit, the WIU shall stop
broadcasts and enter a safe state.

11.2 WIU Inputs

11.2.1 Where inputs are utilized to obtain aspect, switch, hazard detector, or other
information, the inputs shall comply with the following:
11.2.2 Inputs must be able to respond to circuits that are flashing (if connected to a
lamp circuit), on, or off. Where the input is tied to AC (e.g.: lighting circuit) the
input needs to respond to AC.
11.2.3 If an input is tapped onto a lamp circuit to monitor voltage there may be lamp self
checks on electronic equipment and contact transfers that occur on a periodic
basis. These self test pulses or brief off states must not be interpreted as a
flash, unless the lamp is actually flashing. During the periodic operational check
pulses used by many processor-based devices, the pulses may be of full output
power but less than 5 ms duration. The repetition rate of these pulses may vary
from 100 ms to 1 sec.
11.2.4 Inputs must conform to AREMA Manual Part 1.5.15 (Recommended Practice for
Electrical Interfaces between Signal, Train Control and Grade Crossing

Page 43 of 47

Interoperable Train Control Wayside Interface Requirements

 Equipment), Subsection E, with the following exceptions and modifications to that
subsection.
11.2.4.1 Operational Input AC Immunity and Safety Input AC Immunity
requirements apply only to inputs used for DC-only inputs, not AC inputs or
AC and DC inputs..
11.2.4.2 Inputs are not required to have an impedance between 200 and 2500
ohms resistive, but their input impedance must not negatively impact lighting
circuits when voltage monitoring is used to monitor lamps.
11.2.4.3 Subsection E, paragraph f does not apply.

11.3 Current Sensor Inputs

Since not all lighting circuits provide downgrades when one or more lamps are disabled
or burn out, some lamp circuits require monitoring by current sensors to limit wayside
signal rewiring.
11.3.1 The current sensor unit must allow for wiring without disarranging the signal
circuitry. Removing one end of one lamp wire for wiring to the current sensor is
allowed.
11.3.2 Current sensors must be able to respond to both ac and dc current since signal
lamp circuitry may utilize either ac and/or dc lighting. An example, where both
ac and dc are used to power a lamp, is where lamp circuits operate on ac if the
power is on and operate on dc when the power is off. The lamp is powered by
either ac or dc, not both at the same time.
11.3.3 In some lamp circuitry, typically where flashing aspects are used or lamp current
is sourced through an electronic unit (e.g.: FR-2), residual current is supplied to
the lamp when the lamp is in the off state while flashing. This current is utilized
to keep the Light Out Relay (LOR) energized and the amount of current may vary
with the wattage of the lamp, the source electronic unit, the current required by
the LOR, or the size resistor across the flasher contact. The off state of the flash
must be detected by the current sensor to determine that the lamp is flashing.
11.3.4 Current sensors must be checked by the unit. These checks should be made on
every aspect change and on a periodic basis. Current sensors must be checked
before an upgrade aspect is provided by the unit.
11.3.5 Current sensor status must be available for diagnostics and system
management. Each current sensor state (e.g.: 1, 0, Flashing, Fail) must be
available for both diagnostics and system management.
11.3.6 Lamp self checks on electronic equipment and contact transfers occur on a
periodic basis. These self test pulses or brief off states must not be interpreted
as a flash, unless the lamp is actually flashing. The periodic operational check
pulses used by many processor-based devices may be of full output power but
less than 5 ms duration. The repetition rate of these pulses may vary from 100
ms to 1 second. These pulses may be in the form of an on or off state.
11.3.7 The current sensors can either be integrated into the WIU unit or utilize a
separate enclosure for mounting the sensor in a remote location in the housing.

11.4 Outputs
Outputs from the WIU may be required for a location to operate approach lighting,
crossing start, or other use.
Outputs must conform to Manual Part 1.5.15 (Recommended Practice for Electrical
Interfaces between Signal, Train Control and Grade Crossing Equipment). The
following are some of the requirements of that Part.

Page 44 of 47

Interoperable Train Control Wayside Interface Requirements

11.4.1 Outputs shall be capable of driving a load impedance from 250 to 1000 ohms
resistive. (This may be a result of a single output driving multiple inputs and must
be considered by system designer).
11.4.2 The Output Zero Threshold shall be less than or equal to 2.5 VDC (or shall
source less than 5 milliamperes current) for Category 4 devices or shall be less
than or equal to 5 VDC.
11.4.3 The Output One Threshold shall be greater than or equal to 8.5 VDC for
Category 4 Devices.
11.4.4 The output voltage shall not exceed the maximum value of the operating voltage
range for the applicable Voltage Category.
11.4.5 Outputs shall not generate greater than 600 millivolts p-p ripple over the
frequency range of 25 Hz to 300 KHz.
11.4.6 Outputs shall maintain appropriate dielectric strengths as defined in AREMA
Manual Part 11.5.1.
11.4.7 Output check pulse duration shall be less than 4 milliseconds in duration and
shall not occur more frequently than once every 100 milliseconds. This check
pulse will not be included in the specified limit.
11.4.8 When an output is turned off and is loaded by at least 10K ohms resistive, it shall
decay from Output One to Output Zero level within 1 second. (This is required
where a wire may have an intermittent open, is opened for testing or is
connected to a high impedance recorder input. This ensures that the Output that
has been turned off shall not energize another input or relay after 1 second.)
11.4.9 Outputs shall include short circuit protection.
11.4.10 Safety-Critical Output Requirements
11.4.10.1 These requirements are based on the system design characteristic
that a ZERO indication leads to a safe state. Under failure
conditions, the Output Zero Threshold shall not increase.

Page 45 of 47

Interoperable Train Control Wayside Interface Requirements

12 Code Line (Future)
12.1 Code line messages will utilize ATCS messages, wrapped in an HMAC, then enclosed in
EMP and transported over Class D to the ITCM.
Insert Diagrams of ATCS Codeline messages.
12.2 A serial output or Ethernet to the logic controller will be provided for connection to the
VLP.
12.3 Conversion to standard logic controller interface protocols [Genisys, ATCS (RS-422,
9600, Synchronous HDLC), MCS-1, or logic controller specific protocol] shall be provided
to be compatible with existing systems.
12.4 System should be capable of non-vital serial communication (with backup port) with
either an external field code system or office code system. The communication protocol
should be programmed by the manufacturer.

Figure 6 - Code Line Connectivity

Page 46 of 47

Interoperable Train Control Wayside Interface Requirements

13 Crossing Messages

The purpose of this section is to describe the advance crossing start operation of PTC controlled
highway-rail grade crossings for higher speed trains than the physical on-track crossing start is
circuited or physical limitations of the crossings.

Refer to separate Advance Highway-Grade Crossing Start document.

Page 47 of 47

Interoperable Train Control Wayside Interface Requirements