WG9 STANDARD P1544
TRANSIT COMMUNICATIONS INTERFACE PROFILES FOR RAIL
APPLICATIONS
Meeting called to order at 9:10 a.m.
2.0 Agenda & Minutes
The
minutes of meeting eight were previously reviewed by email with no changes
identified. The agenda was presented as
Attachment B.
3.0 Interoperability Task Force
The
second meeting of the WG9 Interoperability Task Force (WG9ITF) was held at the
offices of PB Transit & Rail Systems in Newark, NJ on January 27th,
2000. WG9 was asked to review critical data elements from R142 ( Attachment B )
against IEEE 1475 and other railcar experience to determine if list needs to be
expanded. Pierre Zuber will enter these data elements into the RoMain Database
to see how that process works.
WG9 did not review/refine list of data elements for
communication from rail transit to the rest of a multimodal transit system
prepared by Jim Kemp. This task is a TCIP activity which can wait for the
critical data elements entry to further define the process.
4.0 Database Format
Mike Barnett presented the consolidated Microsoft Access database program. Rob McHugh agreed to distribute this latest On-board database to facilitate the entry of working groups data elements. Mike also included a beta version of a windows type tree structure TCIP Explorer to aid in the manipulating of the database which will be posted on the WG9 TSD site for comments. Presently we have 3 ways to enter data elements; a TCIP form for common elements, a RoMain form for Rosin ( 1473.T style ) and a LonMark form for LonWorks (1473.L style).
The main product will be a
consolidated Microsoft Access database , a description of the database fields
and a description of the process to create new data elements. The data
dictionary will follow the guidelines of IEEE standard 1489 ; a pre-ballot copy
is available on request. WG9 message
set formats have yet to be determined but will follow the guidelines of IEEE
standard P1488. Coordination with
LONMARK and TCN will ensure as much commonality as possible The working group, and the PAR, is primarily
focussed on defining the data required to make IEEE 1473 work, on board the
train and to incorporate the requirements of the other RTISC WGs. The TCIP requirements should be able to be
derived as a subset of the WG9 database with some external ASN.1 expert help.
6.0
Internet
and Application Program Issues
The
website: http://www.tsd.org is
maintained by Tom Sullivan. Tom's site
is directly linked to the IEEE site where draft standards are password
protected. The user name and password
for accessing draft standards are "transit" and "railway". Posted Email attachments may be in
either Word 6.0/95 or Word 97. The P1488 is on the TSD website: (http://www.tsd.org/wg9.htm). It is security protected; contact Rob or Tom
Sullivan for the password. Documents which may have copyright issues will also
be identified.
Pierre Zuber identified some Microsoft Access 2000 compatibility issues
which he will investigate further.
Eva
Lerner-Lam gave an update on TCIP and the Transit Standards Consortium. . She
encouraged the WG to work through RTVICS Chair Tom McGean to obtain an
electronic copy of the Database that was compiled by Lockheed Martin for the IEEE
Data Registry effort, citing the fact that Functional Area Data Dictionaries
for several ITS User Groups were included in the Database, specifically: TCIP, Traffic Management Data Dictionary
(TMDD), Advanced Traveler Information Systems (ATIS) and National
Transportation Communications for ITS Protocols (NTCIP). IEEE 1473
provides the communications protocol standard;
IEEE P1544 provides the standard
profiles to make sure that the information carried by the protocol can be
formalized. The LonMark Interoperability
Association assures internal compatibility of
EIA 709 based elements and ROSIN provides the train specific engineering
designed into the IEC protocol. A
critical gateway between the European developed IEC protocol and the EIA
protocol widely used in the US has been proposed.
ITS HRI
interfaces between Rail Operations Centers and Traffic Management Centers are
at too high a level for WG9 which will
coordinate with IEEE RTVISC Working Group 14 and the IEEE data registry for the
purpose of standardizing the above interface.
It
was proposed that the next meeting be announced at a later date ( likely in
late Apr. or early May.).
Rob will arrange a venue and
finalize a date; exact date and location will be posted on http://www.tsd.org/
(Action items are printed in italicized bold font.)
Prepared by:
R.E.
McHugh, P.Eng.
Chair,
WG9
ATTACHMENT A
WG9 STANDARD P1544
9:00 -9:10 AM
Introductions, Meeting Purpose
9:10-10:00
AM
Task Force Update
Database format
Internet issues
Input from Working Groups
10:00
- 11:30 AM
P1544 Document structure review
Rosin Data Base review
LonWorks Rail Transit functional
profiles
11:30
-
Lunch
12:40
- 2:40 PM
Review of TCIP common and Rail
specific on-board data objects
TSC liaison; related standards &
publications
2:40-4:20
New Business
Meeting Time and Place, next meeting
Adjourn
ATTACHMENT C
Network Data Elements Required for Interoperability:
R142 Network Data:
Forward/Reverse: Mutually exclusive status of the direction selected on the reverser switch by the operator. Information sent on the RS Propulsion Network is the complement of that sent on the LS Propulsion Network. The "complementary" function shall be performed at the reverser switch electrical contact wiring level.
Power/Brake: Mutually exclusive status of the Master Controller handle position indicating whether it is in the brake or in the power range. Used to assess the encoder value.
Deadman: Status of the Master Controller handles Deadman state.
Encoder: The digital value of the Master Controller handle encoder position.
Full Service: Master Controller in Full Service brake position; used to control the brake pipe charging sequence.
Door Interlock restriction Status bit indicating the Master Controller logic itself may be creating an encoder vs. Power/Brake switch mismatch for door interlocking purpose.
T/O status: The all door closed and locked status including the EMV trainline not in emergency as read from the T/O indication in the cab (Train Operator Light). This consists of two identical status bits that shall match at all times.
Door bypass status: The door bypassed status as read from the Door Bypass indication on the console. This consists of two mutually exclusive status bits that shall be maintained to enable operation of the train. The Door bypass circuitry shall be arranged such that the T/O status is also set when the bypass is activated in order to enable the door interlocking functionality.
Brake released status: The air/parking brake released trainline status as read from the indicator on the console.
Brake bypass status: Indication of a brake interlock bypass operation. Brake bypassed operation is maintained as long as the Brake bypass status is present.
Regen/NoRegen/Friction Brake Test:
Mutually exclusive status of the Regen/NoRegen operator control indicating whether regenerative braking is enabled (Regen) or disabled (NoRegen). Both status bits set to off is defined as a valid combination and shall result in friction only brake operation (Friction Brake Test).
EMV status: The EMV trainline status. EMV is a hardwire overlay of the emergency brake pipe where: 1 = emergency and 0 = no emergency
Charge status Status indicating brake pipe charging initiation is taking place.
LVPI Status bit indicating the Low Voltage Power Input to the transmitting entity is within the valid range.
Snow Brake: Status of the Snow Brake operator control.
MSGID |
CIUID |
I/O1 |
I/O2 |
I/O3 |
CC |
Figure 1 - Cab Interface Unit message format
MSGID - Message identification - 1 byte Message type identifier used by other system to differentiate the message source. Set to ASCII value <C> (43h).
CIUID - Cab Interface Unit ID - 6 bytes The Neuronâ Chip 48 bits unique ID; used by the other systems to uniquely identify messages from the active Cab Interface Unit.
I/O1 - CIU inputs/status - 1 byte Each bit represents the status of a different discrete signal as defined below
·
Bit
1 - MSB Regen/NoRegen/Friction
Brake Test control - Regen contact status
Regen
= 1, NoRegen = 0, Friction Brake Test = 0
·
Bit
2 Regen/NoRegen/Friction
Brake Test control - NoRegen
contact status
NoRegen
= 1, Regen = 0, Friction Brake test = 0
·
Bit
3 T/O
status #1
T/O
light on = 1, T/O light off = 0
·
Bit
4 Door
bypass status #1
Bypass
on = 1, Bypass off = 0
·
Bit
5 Brake
released status
Brake
released = 1, Brake not released = 0Bit 6 EMV
trainline status
Energized
= 1, De-energized = 0
·
Bit
7 Always
0
·
Bit
8 - LSB Always
1
I/O2 - CIU inputs/status - 1 byte Each bit represents the status of a different discrete signal as defined below
·
Bit
1 - MSB T/O
status #2
T/O
light on = 1, T/O light off = 0
·
Bit
2 Door
bypass status #2
Bypass
on = 0, Bypass off = 1
·
Bit
3 Unused
·
Bit
4 Unused
·
Bit
5 Brake
bypass status
Bypass
on = 1, Bypass off = 0
·
Bit
6 Snow
brake command
Snow
brake on = 1, Snow brake off = 0
·
Bit
7 Always
0
·
Bit
8 - LSB Always
1
I/O3 - CIU inputs/status - 1 byte Each bit represents the status of a different discrete signal as defined below
·
Bit
1 - MSB Status
indicating brake pipe charging initiation
is taking place.
Initiated
= 1, Not initiated = 0
·
Bit
2 CIU
low voltage power input within the valid
range
In
range = 1, Out of range = 0
·
Bit
3 Unused
·
Bit
4 Unused
·
Bit
5 Unused
·
Bit
6 Unused
·
Bit
7 Always
0
·
Bit
8 - LSB Always
1
CC - 1 byte Circular Counter incremented at each transmission
MSGID |
MCID |
SW1 |
SW2 |
ENCODER |
CC |
Figure 2 - Master Controller message format
MSGID - Message identification - 1 byte Message type identifier used by other system to differentiate the message source. Set to ASCII value <M> (4Dh).
MCID - Master Controller ID - 6 bytes The Neuronâ Chip 48 bits unique ID; used by the other systems to uniquely identify messages from a Master Controller.
SW1 - Switch status - 1 byte Each bit represent the status of a different discrete signal as defined below
·
Bit
1 - MSB RS
Propulsion Network - Reverser switch
forward contact status
Forward
= 1, Reverse = 0
LS
Propulsion Network - Reverser switch
Reverse contact status
Reverse
= 1, Forward = 0
·
Bit
2 RS
Propulsion Network - Reverser switch
Reverse contact status
Reverse
= 1, Forward = 0
LS
Propulsion Network - Reverser switch forward
contact status
Forward
= 1, Reverse = 0
·
Bit
3 Master
Controller handle in Brake range switch
status
Brake
= 1, Power = 0
·
Bit
4 Master
Controller handle in Power range switch
status
Power
= 1, Brake = 0
·
Bit
5 Master
Controller handle Deadman switch status
Maintained
= 1, Released = 0
·
Bit
6 Door
Interlock restriction status
Restricted
= 1, Normal = 0
·
Bit
7 Full
Service position status
Full
Service = 1, Other = 0
·
Bit
8 - LSB Low
Voltage Power Input within the valid
range
In
range = 1, Out of range = 0
SW2 - Switch status - 1 byte Provisions for future use
ENCODER - 1 byte Master Controller handle position encoder value: Binary encoded.
CC - 1 byte Circular Counter incremented at each transmission.
Table 1 - Master Controller handle position encoding
Encoder
value |
Interpretation |
118 to 125 |
MC handle in Emergency position |
126 to 159 |
MC handle in brake range |
126 to 130 |
MC Handle in Full Service position |
155 to 159 |
MC Handle in Minimum Service position |
160 to 168 bits |
MC Handle in Coast position |
160 to 164 |
Power/Brake switch transition range |
169 to 209 |
MC handle in power range |
169 to 173 bits |
MC Handle in Minimum Power position |
203 to 209 bits |
MC Handle in Full Power position |