IEEE Rail Transit Vehicle Interface Standards Committee
WG9 – Transit Communications Interface Profiles
Meeting 23 – 27 February 2003
APTA Headquarters, Washington, D.C.
1. Introductions
Isabelle Cornelus, Alstom
Jim Dietz, LTK
David Gregson, Quester Tangent
Jim Kightley, Quester Tangent
Anssi Laakkonen, EKE
Vlad Mitroi, Alcatel
Dave Phelps, APTA
Benoit Racicot, Bombardier
Fred Woolsey, LTK (Chair)
Pierre Zuber, Bombardier
2. Administrative Issues
Jim Kightley volunteered to act as Recording Secretary.
Minutes should focus on recording the results of discussions, with less emphasis on the
discussion itself. IEEE policy for meeting minutes is to record names only for formal proposals
and actions; general discussions should not be attributed. A summary of the major points of the
discussion is useful as a record of how the Working Group arrived at a decision. Any issues left
unresolved should also be recorded.
The format of meeting minutes was briefly discussed.
Some documents  including meeting minutes  intended to be posted on the IEEE WG9 website
have failed to appear. It would be useful to have documents that are to be discussed posted in
advance of a meeting. Fred Woolsey will look into expediting future postings.
No minutes from the previous Working Group meeting were available for approval.
3. RTVISC Meeting Recap
Jim Dietz (RTVISC chair) reported that the RTVISC has overseen publication of 10 standards to
date, with 13 more in progress. There is potential to start another four standards development
working groups in the next few months.
WG15 (train to wayside wireless communications) is starting up, but currently has no chair.
David Gregson has been nominated as the new chair.
4. Interactions with Other Working Groups
WG9’s scope is closely associated with WG15 (train to wayside communications), WG1
(communications protocols aboard trains) and WG3 (monitoring and diagnostic systems). Better
coordination between these groups is desirable.
WG9 (and WG15) would be well-advised to establish better links with European standards
groups working in the same areas.
WG9 has not yet sought formal approval to use UIC 556 as a basis for IEEE 1544. WG9 will ask
the IEEE to address this issue at a later date.
WG9 Meeting 27 Feb 2003
1 of 5
TCN technology is now being used or will be used by a number of rail systems in North America:
Train Urbano (Puerto Rico), Houston light rail, Portland metro (?), NYCT R142/R142A/R143
(propulsion system), Boston Blue Line, Dallas/Forth Worth (people mover), New Jersey Transit.
Because Siemens is installing several of these systems, it would be useful to encourage their
involvement in WG9.
There is currently too much diversity in train-based communications, even within a single train
such as New Jersey’s Comet V.
IEEE 1473 is due for renewal in a year, so WG1 will need to be reactivated. Since the standard
was published (1999), communications technology has evolved considerably, in particular high
bandwidth audio and visual data. Various parties are pushing to use Ether net (and other IEEE
802 protocols) for transit-related functions. There is no need to open up the scope of IEEE 1473
to accommodate these new areas, however its scope should be clarified. WG1 can develop new
train-based standards instead, coordinating with WG15 for wireless communications.
IEEE 1475 will also be due for renewal shortly, so WG5 will be reactivated. The standard defines
some data elements that do not align with WG9’s efforts (IEEE 1544). Coordination is needed.
It was proposed that RTVISC establish a sub-committee to oversee WG1, WG3, WG9, WG15
(and others?), similar to the structure of the Overhead Contact Systems (catenary) sub-committee.
It was agreed that such a structure should be put in place, but that it be informal at present. Jim
Dietz will coordinate. If the arrangement works out in practice, then it will be formalized.
5. Gateways
5.1.
Standard Gateway
Fred Woolsey proposed that WG9 no longer pursue development of a general-purpose, singlestep TCN-WTB to LonWorks gateway, because there has been little or no activity and no interest
from the industry. The proposal met with general agreement.
A courtesy letter should be written to NJT and TCRP explaining this decision.
Action: Fred Woolsey will write these letters.
This decision has no material impact on WG9’s current activities.
5.2.
General Gateway Discussion
IEEE 1473 mentions TCN to LonWorks gateways, but does not depend on existence of a
standardized gateway.
WG9 has focused on defining standardized data elements for the train bus. Work will then
proceed to the vehicle bus, but it is important to finish the train bus standard first. The buses are
quite different in nature: train bus is gateway-to-gateway; vehicle bus is gateway-to-subsystem.
This difference dictates distinct data structures. Ideally, the same set of data elements will be used
on both buses, so that a gateway has only to shuffle data elements between data structures and
does not need to translate data values.
The presence of a data element in a data structure defined by UIC 556 and/or IEEE 1544 does not
require its use. For example, a car builder may choose to replace the “Door Enable” data element
with a trainline (to ensure safety).
WG9 Meeting 27 Feb 2003
2 of 5
6. Current Status of Draft Standard
6.1.
Access via Website
Draft 3 of IEEE 1544 was posted to the WG9 website last July. IEEE requires that it is password
protected. The password is specific to WG9 and the standard. All documents posted to the
RTVISC website (accessible via the link www.rtvisc.org) use the same generic password. The
next draft of IEEE 1544 will be posted to the RTVISC website with the generic password.
Issues arise for some overseas parties with password-protected Zip files. It may be preferable to
post unencrypted files (Zipped to save bandwidth on download) and to require users to login to
gain access to the download area.
6.2.
Project Authorization Request
WG9’s PAR for the IEEE 1544 standard ran out at the end of 2002. The IEEE has granted an
extension for one year. Several sections of the draft standard still need attention.
6.3.
Introduction (Section 1)
Dave Phelps volunteered to write an introduction.
6.4.
References (Section 2)
Section 2 references UIC 556 (2nd edition), which is released but is not freely available because
the UIC is not selling it. IEEE policy is that a reference section contains only documents that are
needed to use the standard. All other documents are listed in a bibliography.
Section 2 references ASN.1 syntax, which is defined in a standard issued by the International
Telecommunication Union (ITU). The ITU sector responsible was formerly called CCITT.
6.5.
Mapping to UIC 556 Telegrams (Annex B)
Annex B provides a mapping of data elements from UIC 556 to IEEE 1544 train bus telegrams.
The top half has been filled in, but there are many more data elements to be analyzed and
described. The main tasks are to translate data types, and provide better descriptions where UIC
556 is ambiguous or uses terminology that does not match North American usage.
The intent of Annex B is to make it easy for the UIC 556 Steering Committee to review the
modifications and interpretation applied by the IEEE standard. Anssi Laakkonen, who sits on the
Steering Committee, stated that there was indeed interest in this information.
Annex A3 provides a normative list of all data elements defined by the standard. Annex B is
informative. This distinction is not yet made clear in the body of the draft standard.
Arguments were made for replacing Annex B with a simple reference. The Chair pointed out that
the format and content of the Annex had been discussed and agreed on at previous Working
Group meetings, but he allowed the issue to be reopened. The following comments were made on
this topic:
Removing Annex B would make the standard less intractable and reduce the risk of errors.
Even if not included in the first standard, the text could be provided to the UIC 556 Steering
Committee and kept in reserve for a future standard.
The remainder of the standard deals mainly with data elements, without reference to data
structures (telegrams).
WG9 Meeting 27 Feb 2003
3 of 5
The standard alone does not ensure interoperability. Implementation-specific details, such as
timing characteristics are needed, so this change would not jeopardize interoperability
between existing and future NJT trains.
This change might remove most of the useful content of the standard.
This change will render the standard less potent, but it will still fulfill its main purpose.
Agreement: Annexes B1 and B2 of Draft 3 will be removed. Standard 1544 will focus
exclusively on data elements and will no longer reference the train bus.
The current draft standard defines some data elements that are WTB-specific. Such data elements
would be out of place if the standard no longer references the train bus, so they should also be
removed.
6.6.
Standard Series
Standard 1544 should be viewed as the first in a series, e.g. 1544.1, 1544.2. A section within the
current draft 1544 anticipates this organization.
Each new standard will require IEEE to issue a PAR. A standard cannot anticipate future creation
of a standard for which the IEEE has not yet issued a PAR.
6.7.
Annex Reorganization
Agreement: Annexes will be reorganized as follows:
Annex A1 becomes Annex A (Primitive Type Definitions)
Annex A2 becomes Annex B (Physical Type Definitions)
Annex C remains (Data Element Dictionary)
Former Annex B and Annexes D through H will be removed (moved to future standard)
6.8.
Data Element Syntax
The ITS community standardized on ASN.1 syntax a few years ago. However, the community is
now transitioning to XML.
Annex F lists data elements using ASN.1 syntax. This listing was created using a custom report
generated from the MS Access database that contains the original data element definitions. It
would be possible to regenerate the Annex using XML instead.
If essential information is expressed then syntax is irrelevant. Instead of providing a (long) listing
of data elements in any particular syntax format, provide a description of how to format the data
elements, with one worked example.
Agreement: Remove ASN.1 definitions. Do not replace with equivalent XML definitions.
Action: Fred Woolsey will write an informative annex to describe creation of XML schema.
6.9.
Data Element Database Publication
Either ASN.1 or XML is inconvenient to a human reader in a printed document. Better to publish
the data element database electronically, e.g. on a CD inserted in the jacket of a paper copy of the
body of the standard. The IEEE currently publishes only paper documents.
APTA has recently faced a similar issue, and has decided to publish TCIP standards
electronically (using C code).
WG9 Meeting 27 Feb 2003
4 of 5
Action: Jim Dietz will investigate whether the IEEE can handle electronic publications, and in
what form.
Electronic files require tools to view the data. It is preferable to use tools that allow for
sophisticated searching, rather than just PDF. A good example is the previous release of the
LonMark SNVT and SCPT Master List, which was published as a Windows Help file. Another
option is to translate the database from MS Access to MySQL, which is an open source database
running under Linux and available at no cost.
It is important not to create a tool barrier in front of the database; otherwise people will find it
inconvenient or too expensive to access.
7. Other Issues
7.1.
Multicasting
The TCN standard defines multicasting for WTB Message Data, but UIC 556 does not describe
its usage. UIC 556 does describe a sequence of point-to-point message transfers, with
acknowledgment at each hop.
One NJT application is for time synchronization. Every Comet V gateway transmits its own clock
in Process Data, but the train does not have a well-defined time master. A solution can be created
based on implementation-specific details, e.g. location of GPS time source.
Another application is for file transfer of the passenger information system database.
It was suggested that the train bus standard (IEEE 1544.1) express the wish for WTB multicast,
and hope that the next edition of UIC 556 will include the feature.
8. Work Assignments
Draft 1544 standard:
Dave Phelps: Introduction
Pierre Zuber: Remainder of body
Fred Woolsey: Annexes, including XML translation description
Other Working Group members are encouraged to provide feedback. The target is to have the
draft standard ready for line-by-line review by the next meeting.
9. Closure
Next meeting will be on Thursday May 15, 2003 in Philadelphia. Schedule and location are
coordinated with the next RTVISC meeting. The exact venue is to be determined; Fred Woolsey
will investigate options.
Meeting adjourned at 2:15.
WG9 Meeting 27 Feb 2003
5 of 5