Setting the Standards

Newly emerging interface standards for rail transit vehicles may help stem the rising costs of complex new technology

By Tom Sullivan, Contributing Editor

	The RTVISC met at Safetran Systems' Rancho Cucamonga facilities on March 14-15, 2000. Center rear, left to right: RTVISC Chair Tom McGean, WG3 Chair Linda Sue Boehmer of LSB Technology, and APTA Program Manager Lou Sanders. Behind Sanders is CANAC's Bill Moore Ede. Photo by Tom Sullivan

Over the last four years, a major effort has been under way in the U.S. to develop new rail transit vehicle interface standards. Transit Cooperative Research Program Project G4A and its Rail Transit Vehicle Interface Standards Committee (RTVISC), chaired by Tom McGean, is an FTA-supported effort funded by the National Academy of Sciences Transportation Research Board and managed by the American Public Transportation Association.

McGean's RTVISC is a veritable "who's-who" in rail transit. Virtually every major transit property in the U.S. has participated. Major international railcar builders, train control suppliers, subsystem suppliers, and consultants work side by side on RTVISC working groups. Also participating are such relative newcomers as Echelon Corp., whose widely-used control network technology, LonWorks, was recently adopted as an RTVISC standard (RA, August 1998, p. 63).

McGean selected the IEEE Standards Association as the framework for these new interface standards. An open consensus process requiring 75% of the voting members to agree, the RTVISC has produced an impressive number of new standards in a relatively short time. To date, all eight initial standards have been brought to ballot, and seven are now official IEEE standards. Additional draft standards are working their way through RTVISC working groups, and more can be expected.

Another reason for its success is that the RTVISC closely coordinates its activities with such related groups as the FRA's Positive Train Control effort, the LonMark Interoperability Association Transportation Task Group, the Object Management Group, and proposed TCIP Traffic Signal Priority Standards. Coordination activities have been initiated with the APTA Rolling Stock Equipment Committee and the new ITS/APTA Rail Subcommittee, headed by Tom Taylor of Parsons Brinckerhoff Transit and Rail Systems. Coordination also takes place with the Transit Standards Consortium, a new public-private partnership formed to coordinate and facilitate the development of transit standards. Most RTVISC meeting minutes and related documents are freely available to the public on its website, www.tsd.org/wg.htm. However, due to restrictions imposed by the IEEE, working draft standards are available only to RTVISC working group members.

Where's the benefit?
The widespread introduction of embedded microcomputers from major subsystems down to individual sensors is transforming rail transit and provides opportunities to significantly improve performance, availability, and safety. It can also reduce costs, but this is not guaranteed because advances in technology make it easy for suppliers to develop proprietary systems. Thus, standards are needed if technology is to really save money.

Standards can reduce costs to purchase, operate, and maintain equipment. Initial RTVISC estimates showed that railcar standards being drafted under the TCRP G4A project can save a third of a billion dollars annually. A recent example of these savings was cited by New Jersey Transit Manager-Advanced Public Transportation Systems James Kemp. His initial estimates were that one RTVISC standard alone, IEEE 1473 (see below), would save his agency $420,000 per year.

Off to a good start
Space does not permit discussion of all completed and on-going IEEE RTVISC standards efforts, but readers interested in additional information are encouraged to visit the RTVISC website. Following are some recent highlights:

To improve and maintain safety, IEEE 1483, "Verification of Vital Functions in Processor-Based Systems," now provides critically needed design guidance for those developing safety-related microprocessor-based systems for rail passenger vehicles. IEEE 1483 can soon be purchased from the IEEE Standards Association. Complementing 1483 is development of a new standard to establish uniform requirements for documenting software. That effort, led by Paul Jamieson of Wabtec, recently received approval from the IEEE Standards Board and is attracting interest from end-users and suppliers.

Safetran's Bill Petit now leads RTVISC Working Group 12, which was formed to standardize the highway/rail interface and ensure safety between wayside equipment and new intelligent traffic controllers (RA, April, p. 55).

The National Transportation Safety Board named transit vehicle event recorders as its "most wanted" transportation safety improvement. Responding to this need, RTVISC Working Group 3, led by LSB Technology's Linda Sue Boehmer, mounted a major effort to develop an event recorder standard for the transit industry. IEEE 1482.1 is now complete.

IEEE 1475, "Standard for the Functioning of and Interfaces among Propulsion, Friction Brake, and Train-borne Master Control on Rail Rapid Transit Vehicles," is also complete. It addresses three different technology levels, from basic to the most advanced. Developed under the leadership of APTA's Dave Phelps, 1475 is now available as an official IEEE standard.

Parsons Transportation Group's Dr. Alan Rumsey leads Working Group 2, "Communications-Based Train Control," which now has over 100 participants. Its IEEE 1474.1 functional and performance standard was approved late last year. In February, WG2 met in Philadelphia and identified such new standards activities as environmental requirements for wayside equipment, CBTC graphic display standards, and CBTC highway/rail interface standards. It also agreed to postpone development of interoperability interface standards for CBTC until a better sense of where suppliers stand on this sensitive issue is apparent. That probably won't occur until New York City Transit's CBTC pilot program (see related CBTC article) is further along.

An open or closed case?
The critical IEEE 1473 "Standard for Communications Protocol Aboard Trains" became an approved standard in 1999. Two sub-standards were defined in IEEE 1473: 1473-T and 1473-L, which essentially define two existing communications protocols, TCN and LonWorks.

TCN was a joint development of two European railcar builders. It was designed exclusively for use on trains to handle many complex functions automatically (such as when train initiation occurs and individual cars couple to form a train). This is especially important in Europe, because many passenger trains operate in more than one country. Currently, there is no published reference model for TCN, and prices for TCN products are not published. Therefore, most industry observers agree that TCN is not an open protocol.

LonWorks, in contrast, was developed by a network technology firm to be a non-proprietary, general-purpose control network protocol for use in many different industries. As a consequence, car-to-car interoperability and all needed train functions must be specifically defined, and the LonMark Association's new, user-supported Transportation Task Group is beginning to standardize on these new LonMark "Profiles." LonWorks has a published reference model, prices are published, and products are freely available from multiple suppliers. Therefore, most agree that LonWorks meets the commonly accepted definitions of an open protocol.

There are complementary advantages and disadvantages to both protocols, and some involved with them today believe it makes sense to build a network "gateway" to join the two technologies for use on multi-car trains. Under this proposed gateway architecture, 1473-T would be the train or inter-car network, and 1473-L would be the network used within each car. There are good reasons to do this, but there are also some non-obvious downsides. For example, unlike a router-which simply moves information from place to place without needing to know anything about the information itself-a gateway must be designed from the beginning so it completely understands everything on both sides. This is because a gateway's purpose is to translate information from one protocol to another. A concomitant side effect is that any change to a subsystem, or even a change in a message format, must include a change to every gateway that routes the information. Thus, changes to accommodate new-technology equipment or information in future railcars will be more difficult than if a single protocol is used.

Nevertheless, many, including the not-for-profit LonMark Interoperability Association (established to help LonWorks users and developers build open, interoperable systems), Adtranz, and others are working with IEEE RTVISC Working Group 9 to investigate this next potential level of interoperability.

Over the horizon: IP to the rescue?
Increasingly, many are beginning to believe that future railcar specification requirements, especially those for data logging and event recording, may overwhelm the capabilities of both protocols specified by IEEE 1473. Thus, even higher train network capabilities may be needed in the future.

Industry-standard Internet Protocol (IP) over Ethernet is IEEE's standards choice, and some are beginning to investigate the possibility of using 10BaseT and even 100BaseT (100 megabits/second) channels on trains as a future train communications backbone. Also, new "tunneling routers," like Echelon's new iLON router, facilitate interoperability between IP and IEEE-1473-L and may address some of the problems otherwise introduced by a gateway.

Even optical fiber technology may eventually find its way onto U.S. railcars and replace slow, twisted-pair cables-not only because of its ability to send data at much higher speeds, but also because of its inherent immunity to electrical noise. But currently, many in the conservative U.S. transit industry are reluctant to recommend optical fiber despite its maturity and wide acceptance in other industries.

The controls industry increasingly is developing new standards for IP over Ethernet in situations where dependable performance is necessary, despite that IP was once viewed as unacceptable because of its "non-deterministic behavior." But many involved with train network communications may have failed to appreciate that "deterministic behavior" may not really be necessary for safe operation in a rail transit control network. This is because, unlike an airplane, if a "proceed" command doesn't reach its destination in time (because of a "statistically improbable" communications blockage), a train can simply apply its brakes automatically. It's an old concept, perhaps to be reborn in the brave new world of communications-based train control.

Tom Sullivan is a principal at Transportation Systems Design and co-chairs the LonMark Interoperability Association Transportation Task Group with MTA NYC Transit. He welcomes comments and can be reached at tom.sullivan@tsd.org. For additional information on RTVISC and related transit standards activities, visit www.tsd.org.