810272-1732/01/$10.00 2001 IEEE

Automatic coupling of railway vehi-cles has existed since the mechanical Jenny cou-pler at the turn of the 19th century. The railwayindustry’s next challenge is automatic couplingof the vehicle’s electronic equipment through adata bus. This requires a worldwide standard-ization of onboard data communication. Ajoint effort by the International RailwaysUnion (Union Internationale des Chemins deFer, or UIC), Utrecht, Netherlands, and theInternational Electrotechnical Committee(IEC), Geneva, Switzerland has laid thegroundwork for this standardization. The UICgroups all national rail operators worldwide andensures cross-border traffic by standardizingtrack profiles, pneumatic hoses, traction volt-ages, operating procedures, and so on. The IECis well known to IEEE members for its impres-sive collection of standards in the electric world,and as the “electric sister” of the ISO.

Deputies from over 20 countries, includ-ing many European nations, the US, Japanand China representing major railways oper-ators and manufacturers, worked several yearswithin the IEC’s Working Group 22 (WG22)on the definition of the Train Communica-tion Network. The TCN was adopted as theinternational standard IEC 61375 in 1999.1

The IEEE Rail Transit Vehicle Interface Stan-

dards Committee Working Group 1 con-tributed to this work in the late phase andadopted TCN as IEEE Std. 1473-1999 TypeT with no modifications the same year.2

An international standardization of datacommunication is necessary at both the trainand vehicle levels. Trains with varying com-position during daily service—such as metros,or suburban and international trains—need astandard form of data communication for traincontrol, diagnostics, and passenger informa-tion. Such communication should configureitself when vehicles are coupled on the track.

At the vehicle level, a standard attachmentof equipment would serve manufacturers, sup-pliers, and operators. Manufacturers couldassemble pretested units, such as doors manu-factured by subcontractors, which include theirown computers. Parts suppliers who interfacewith different manufacturers could reducedevelopment costs by adhering to one standard.Railroad operators could reduce spare parts andsimplify maintenance and part replacement.

General architectureThe TCN architecture addresses all relevant

configurations found in rail vehicles. It com-prises the train bus connecting the vehicles andthe vehicle bus connecting the equipment

Hubert KirrmannABB Corporate Research

Pierre A. ZuberDaimlerChrysler

Rail Systems

RAILWAY OPERATORS AND MANUFACTURERS HAVE STANDARDIZED A DATA

COMMUNICATION NETWORK THAT INTERCONNECTS PROGRAMMABLE

EQUIPMENT BETWEEN AND WITHIN RAIL VEHICLES. THIS DATA BUS

ARCHITECTURE OFFERS A BASIS FOR STANDARDIZATION OF FUTURE

RAILWAYS APPLICATIONS.

THE IEC/IEEE TRAINCOMMUNICATION NETWORK

aboard a vehicle or group ofvehicles, as shown in Figure 1.

A vehicle may carry none,one, or several vehicle buses.The vehicle bus may span sev-eral vehicles, as in the case ofmass-transit train sets (multi-ple units) that are not sepa-rated during daily use. Inclosed train sets where thetrain bus needs no sequentialnumbering of nodes, the vehi-cle bus may serve as a trainbus, as shown in Figure 2.

Wire Train BusTo respond to the demand

for train-level standardization,WG22 specified the WireTrain Bus (WTB) as part ofthe TCN architecture. TheWTB interconnects vehiclesover hand-plug jumper cablesor automatic couplers, asshown in Figure 3.

WG22 considered severalmedia. It rejected coaxial cablebecause of its poor mechani-cal resistance to shock andvibration. Optical fiber wasalso dismissed because of dif-ficulties in building automat-ic couplers that couldwithstand shock and vibrationas well as harsh weather con-ditions. Therefore, as its nameimplies, the WTB uses a twist-ed shielded-wire pair, whichhas demonstrated its reliabili-

82

TRAIN NETWORK

IEEE MICRO

Train bus

Vehicle bus

Node

Vehicle bus

Node

Vehicle bus

Node

Figure 1. Train communication network.

MVBMVB

MVB MVB

MVB

860 meters (without repeater)

200 meters (without repeater)

200 meters (without repeater)

(a)

0 vehicle bus 1 vehicle bus(standard MVB)

2 vehicle buses(standard and not)

(c)1 vehicle bus 0 vehicle bus

(b)1 vehicle bus Not standard vehicle bus

0 node(conduction vehicle)

Figure 2. Open train with the Multifunction Vehicle Bus as vehicle bus (in some vehicles) andthe Wire Train Bus as train bus (a); connected train sets with the Wire Train Bus as the trainbus and the Multifunction Vehicle Bus interconnecting the vehicles (b); closed train, such as atilting train, with the Multifunction Vehicle Bus both as a train bus and as a vehicle bus—a non-standard bus can also be integrated as vehicle bus (c).

63 0201

Descending

21 Node 21 Node

Trunk cable

End vehicle End vehicle

21 2 2 1NodeNode

MasterAscending

StarboardBottom Top

Node

03 04

Jumper cable

Port

Intermediate vehicle(s) Intermediate vehicle(s)Node number

1

Figure 3. Wire Train Bus.

ty in several European trains.Originally the WTB sharedthe UIC cable with the wirecarrying the DC signals forcontrolling lights, loudspeak-ers, and doors in internation-al vehicles. Due to this wireslimited capacity and in view offuture requirements, the UICdecided to add to the UICcable a dedicated, twistedshielded-wire pair capable ofcarrying data at 1 Mbps. TheWTB layout is by principleredundant; one cable runs oneach side of the vehicle, asshown in Figure 4.

The WTB can span 860meters, a distance correspond-ing to 22 UIC vehicles, with-out a repeater. Thisrequirement allows connectingof older vehicles not equippedwith the new data bus onto atrain. It also allows bypassing ofvehicles with a low battery volt-age—a major concern becauseof battery discharge when vehi-cles are in the marshaling yard.The WTB may have to oper-ate under harsh environmentalconditions where oxidation ofcontacts can occur. To cleanoxidized connectors or con-tacts, a fritting voltage (clean-ing action of the coupler’scontact) can be superimposed on the lines.

The binary data are not transmitted overthe cable as a sequence of 1s and 0s, techni-cally known as nonreturn to zero. Instead, thebits have a Manchester encoding scheme,offering several advantages (see “Manchesterencoding” sidebar).

The WTB’s most salient feature (and aunique trait in the railroad industry) is that itautomatically numbers nodes in sequentialorder and lets all nodes distinguish betweenthe train’s right and left sides and aft and foredirections. Each time the train compositionchanges, for example, after adding or remov-ing vehicles, the train bus nodes execute theinauguration procedure, which connects elec-trically and assigns a sequential address to each

node. In general, there is one node per vehi-cle, but, as shown in Figure 3, there may bemore than one or none at all.

At the end of the inauguration, all vehiclesrecognize the train topography, including

• their own address, orientation (right andleft), and position with respect to the busmaster (aft and fore);

• other vehicles’ number and position inthe train;

• other vehicles’ type and version (loco-motive, coach, and so on) and their sup-ported functions; and

• their own and other vehicles’ dynamicproperties (for example, the presence ofa driver).

83MARCH–APRIL 2001

UIC jumper cable

Line B

Line A

Jumper

Line A

Vehicle VehicleWTB cable

Line B

112 2ClassicUIClines Jumper

ClassicUIC lines

Redundant nodes

WT

B n

ode

WT

B n

ode

WT

B n

ode

Figure 4. WTB cabling (top view).

Manchester encodingManchester encoding is a robust, synchronous encoding scheme used by several buses such as Ethernet. It

encodes bits in fixed time slots (cells); a “1” represented as a positive transition in the middle of a cell and a“0” as a negative transition (or the reverse). Since there is always one transition per bit, the signal clock maybe easily recovered from the signal.

In its simplest form, Manchester is decoded by sensing the zero crossings of the signal. This uses inexpen-sive RS-485 transceivers, such as those used by the MVB. Sensitivity is obtained by sampling the signal at itspeaks, see Figure A. A clock synchronized to the signal by a phase-locked loop evaluates the position of thepeak. To allow the phase-locked loop to adjust itself, useful data must be preceded by a preamble with a knownsequence, consisting usually of alternating 0s and 1s.

In WTB, the phase-locked loop is enhanced by signal processing techniques, similar to those used in DSL.Although Manchester encoding is used in the WTB because of compatibility reasons with DSL.

0 1 1 1 1 1 11101010101010101Line

datapreamble

Figure A. The Manchester encoding scheme signal sequence.

Each node comprises two high-level datalink (ISO 3309) control channels, one foreach direction (forward, backward) as shownin Figure 5. During operation, the end nodesinsert their termination resistors to close thebus, while the intermediate nodes establishbus continuity between the end nodes. Onthe end nodes, two channels are active, onefor the bus traffic and one for detecting addi-tional nodes. On the intermediate nodes, onlyone channel is active, the other is isolated toreduce bus load.

When a train composition consisting of Nnodes is operating, its end nodes send a “Weare N nodes” frame every 50 ms over the openextremity. The rest of the time it monitors foradditional nodes. When a second compositionconsisting of M nodes is coupled, the end nodeof the first composition detects the “We are Mnodes” frame and the new composition detectsthe “We are N nodes” composition. What fol-lows depends on the respective number ofnodes: If the second composition has morenodes (M > N), then the first composition dis-bands. If both compositions have the samestrength, the disbanding decision is random.The winning composition integrates the nodesof the disbanded composition one by one.Each time the winning bus integrates a node,the node receives its address and becomes thenext end node, while the former end nodeswitches to an intermediate position.

The principle is simple, but inaugurationis complex since it requires correct node num-bering and identification in many situations.

For instance, nodes may transition from low-power sleep mode to active mode in the mid-dle of an inaugurated composition, nodescould start operating as backup in cases wherea working node fails, or one of the redundantlines might fail (only one line is shown in Fig-ure 5) and this may not affect numbering. Fora fast recovery after bus disruption, every nodecan become bus master. In such an event, mas-tership automatically transfers to a neighbor-ing node. The dining car, for example, canbecome the bus master, but since all TCNtraffic is slave-to-slave, it will not control thetrain. The worst-case recovery time is less than1 second for 32 nodes.

Once inauguration is finished, the nodesbroadcast their configuration to each other,indicating, for instance, that they represent alocomotive, a motor coach, or a driver coach.They also broadcast properties, such as thelength between buffers and their weight. Thisrequires a strict definition of the dataexchanged and builds on the expertise of rail-way experts. The WTB data traffic and theexact meaning of each variable and each bit isstandardized in UIC leaflet 556.3

Multifunction Vehicle BusTo simplify assembly, commissioning, and

subsystem reuse, the TCN architecture spec-ifies the Multifunction Vehicle Bus (MVB) asa vehicle bus. The MVB connects equipmentwithin a vehicle or within different vehicles inclosed train sets. Figure 6 shows what subsys-tems it could connect in a locomotive. The

84

TRAIN NETWORK

IEEE MICRO

Bus controllers

One channel active

+ - + -

Bus controllers

One channel active

+ - + -

Bus controllers

Two channels active

+ - + -

Intermediate node(s)End node

Trunk cable

Jumper cable

Bus controllers

Terminators(inserted)

Two channels active

End node

Terminators(inserted)

+ - + -

Figure 5. Detailed view of WTB.

MVB operates at 1.5 Mbpsand over the following media:

• Optical fibers for dis-tances over 200 metersand for environmentssensitive to electromag-netic interference (inlocomotives). MVBspecifies 240-µm fibers,which are more robustagainst cracks and vibra-tions than standard tele-com fibers.

• Transformer-coupled, 120-ohm twisted-wire pairs for distances of up to 200meters to connect two or three vehiclesin a train set. These specifications resem-ble those of IEC 61158 but use 120 ohmfor robustness and low attenuation.

• RS-485/120-ohm cable for cost effectivedevice connections within the same cab-inet or on the same backplane with nogalvanic separation. When galvanicallyseparated, this cable can connect equip-ment in different vehicles in closed trainsets.

These different media can directly intercon-nect with repeaters, since they operate at thesame speed with the same signaling.

The MVB is based on the bus pioneered onthe Swiss Locomotive 460 and is used in over600 vehicles worldwide. The MVB enablesconsiderable reduction in the amount ofcabling and increased reliability with respectto conventional wiring.

A dedicated master controls the MVB andcan have backup from redundant masters toincrease availability. The MVB controller pro-vides redundancy at the physical layer: Adevice transmits on the redundant lines, butlistens to only one while monitoring the other.Other features include high integrity againstdata corruption and, due to its robust Man-chester encoding and checksums, fulfillmentof the IEC 60870-5 FT2 class. The Hammingdistance is 8 when using fiber optics.4

Common protocolsDespite differences at the physical and link

layer, the WTB and MVB adhere to the sameoperating principles.

Data trafficTCN buses transport two types of data:

process variables and messages. Process vari-ables reflect the train’s state, such as speed,motor current, and operator’s commands. Thetransfer time for process variables must beshort and deterministic (see the “Determin-ism for time-critical data transmission” side-bar). Railways require that the traincommunication network guarantee less than100 ms of delivery delay from a device on afirst vehicle bus to a device on a second vehi-cle bus, both vehicle buses being connected bythe train bus. Traction control over the vehiclebus requires guaranteed delivery from appli-cation to application for all critical variableswithin less than 16 ms. To guarantee thesedelays, the train communication networktransmits all process variables periodically.

Message data carry infrequent, but possiblylengthy information, for instance, diagnosticsor passenger information. Message lengthvaries between a few bytes to several kilobytes.Messages transmission delay must be short onthe average, but the application toleratesdelays up to several seconds. This slackenedrequirement lets the TCN transmit messageson demand.

Medium access control for periodic and sporadic trafficAll buses pertaining to the TCN provide

two basic medium accesses:

• periodic (for data like process variablesand

• sporadic (for on-demand data traffic,such as messages).

Periodic and sporadic data traffic share thesame bus, but devices treat each separately.

85MARCH–APRIL 2001

CockpitPower line

Diagnosis

Radio

Train Bus

Motor controlPower electronicsBrakes Track signals

Vehicle bus

Figure 6. MVB layout in a locomotive.

86

TRAIN NETWORK

IEEE MICRO

Controversy rages in the automation community betweenthose who think that deterministic operation is required andthose who think a weaker constraint is sufficient.1

Determinism means that the time between the detection ofa change and response to that change is bound by a maximalvalue, even when including some fault conditions (for example,transient communication error). These systems are also calledhard real time.

In this context, nondeterminism means that the system can-not provide an upper bound for its response time but will nor-mally react fast enough for all practical purposes. Such systemsare sometimes called soft real time.

The distinction between deterministic and nondeterministicsystems is visible in a plot of the probability of response versusthe response time, as shown in Figure B.

While a deterministic system responds before the deadlineunder all circumstances, the nondeterministic system has a non-zero probability of missing its deadline, although it usually reacts

faster under normalconditions.

Determinism is a sys-tem property. Every com-ponent (whether for dataacquisition, processing,transmission, or storage)must be deterministic forthe whole system to bedeterministic. A deter-ministic bus is no guaran-tee that the whole systemwill be hard real time.

Of course, no systembehaves deterministical-

ly under all failure scenarios. But a nondeterministic systemintroduces temporal errors because of its very nature and with-out any external influence.

Example systemsA safety system reads an emergency stop signal and should

stop the train before reaching a switch. Safety-critical systemsoperate in negative mode, meaning that the brake computerapplies the brakes if it doesn’t receive confirmation that theemergency stop is not activated. This protects against commu-nication disruption.

The deterministic bus will transmit the no_stop signal cycli-cally every 0.2 s. If transmission fails, the brake computer willwait for three cycles before applying the brakes, its timer beingset to 0.6 s, which leaves sufficient headway to stop the train.Emergency braking takes place in the unlikely case of three gar-bled transmissions in a series (an external cause).

The nondeterministic system lets the brake computer peri-odically ask for the emergency stop’s status. If it does not receivea positive response, it applies the brakes. Although the responseusually comes within 0.1 s, in some cases response time increas-es to 0.6 s. In this situation, the train will suffer an emergencystop because of data packet corruption or network congestion—neither are external causes. Increasing the time-out does notchange this situation, but requires longer rails and headway.

Both systems are safe, but availability—how often the trainstops because of false alarms—becomes the issue.

Achieving determinismDeterministic systems reserve system resources before oper-

ation, which prevents resource contention.Communication systems usually achieve determinism by

cyclic operation, using time division multiple access under eithera master-controlled, token-passing, or clocked operation. AllTCN buses are deterministic, a philosophy shared by the fieldbuses, such as IEC Std. 61158.

Systems can also achieve determinism in processing byenforcing time-bounded tasks and cyclic operation. Examplesof such systems include industrial programmable-logic con-trollers programmed in IEC Std. 61131 function block language.

Nondeterministic systems have no fixed preallocation ofresources. Examples include collision-based medium accessbuses, such as Ethernet; databases with semaphore access; andpreemptive operating systems, such as Unix or Windows.

The controversyThis controversy over the need for determinism is reflected

in everyday traffic. For example, commuters accept delays in themorning rush hours as a price for using a nondeterministic,event-driven transportation: their car.

Conversely, commuters expect scheduled public transporta-tion to behave deterministically. If delays occur, commutersexpect the operator to tell them about an external cause for thedelay, such as heavy snowfall, but too much traffic will neverbe an issue (airlines excepted). The amount of reserve time thatcommuters plan on to reach a destination will influence theirdecision on the type of transportation, with a clear advantageto the scheduled public transportation with tight time constraintsand heavy traffic. Estimating delays for the nondeterministicautomobile transportation requires an analysis of the situation,such as listening to traffic news.

Reference1. P. Koopman, “Tracking down Lost Messages and

System Failures,“ Embedded Systems Program-ming, Oct. 1996.

Determinism for time-critical data transmission

Time

Hardreal time

Softreal time

Dea

dlin

e

Pro

babi

lity

of d

elay

Figure B. Response delay probability for deter-ministic or hard real-time systems and for non-deterministic or soft real-time systems.

One device acting as master controls period-ic and sporadic data transmission, which guar-antees deterministic medium access. Toaccomplish this, the master alternates period-ic and sporadic phases, as shown in Figure 7.

Traffic is divided into basic periods of fixedduration—either 1 or 2 ms on the MVB and25 ms on the WTB. At the start of a period, themaster polls the process variables in sequenceduring a certain time period—the periodicphase. To reduce traffic, urgent data are trans-mitted every period and less urgent variables aretransmitted with an individual period every sec-ond, forth, eight, and so on basic period, withthe longest period being 1,024 ms.

After transmitting the process variables, thebus master checks for sporadic data to trans-mit. On the WTB, a flag in the periodic datasignals that a node has sporadic data pending.On the MVB, an arbitration procedure ensures

that one of several devices gets serviced. If thereare no sporadic data to transmit, the sporadicphase remains unused. If there are data, themaster checks that sufficient time remains untilthe start of the next period (it respects theguard time), and if so, invites a device to trans-mit its sporadic data. A highly precise start ofthe next period is needed because the first mas-ter frame of a period serves to synchronize allclocks with a jitter of some microseconds.

Process variable transmissionIn the first phase of process variable trans-

mission, the master broadcasts a frame to trig-ger transmission of a certain variable withoutspecifying the source device. In a second phase,the source device answers by broadcasting aframe containing the requested value to alldevices. Each device interested in this variablepicks up the value, as shown in Figure 8.

87MARCH–APRIL 2001

Periodic phase

?

Time

Sporadic phase

1 2 3 1 2 34 5 6

Guardtime

Basic period

Periodic phase

?

Basic period

1 2 7 8 9 10

Sporadic phase

1

Events ? Events ? Eventdata

Guardtime

? ? ? ? ?

Individual period

Figure 7. Alternating periodic and sporadic data transmissions lets a single bus transmit both types of data. Process variablesare transmitted at regular intervals (1 ms) and after transmission, the bus checks for sporadic traffic demand and transmits, ifrequested, a message packet, if the guard time is respected.

Sink Source Sink SinkBus

master

Variable value

Variable identifier

Devices(slaves)

Bus

Sink Source Sink SinkBus

masterDevices(slaves)

Bus

Subcribed devices

(a)

(b)

Figure 8. Source-addressed broadcast. In the first phase (a), the master broadcasts a short, master frame with the identifier ofa variable, taken from its poll list. In the second phase (b), the source device sends the variable’s value in a slave frame, alldevices interested in that value receive it. The master is normally neither source not sink of the variables.

To increase efficiency, slave frames carrynumerous variables having the same period,called a data set. A data set contains values andcheck bits, but no addresses. Each variable isidentified by its offset from the data set’sbeginning, each set is identified by the masterframe. To maintain determinism, the config-uration tools define the frame format and thepoll lists before operation starts, after this, thetraffic pattern cannot change. On the MVB,each device can subscribe (as either a sourceor sink) to up to 4,096 data sets. On theWTB, each node has only one data set tobroadcast, but it can receive up to 32 data setsfrom other nodes.

The sources or sink data sets with the val-ues of the variables are stored in a sharedmemory, called the traffic store. The applica-tion processor and the bus controller cansimultaneously access the traffic store on adevice. The traffic stores implement con-jointly a distributed database, as shown in Fig-ure 9, which the bus keeps synchronized. Forthe application programmers, the bus behaveslike a shared memory.

Source-addressed broadcast lets applicationsand the bus operate independently. The appli-

cation processor is only interrupted on recep-tion or transmission for time synchronization.End-to-end determinism is ensured by theperiodic nature of the application processesand the bus.

Since the master periodically requests thetransmission of process variables, there is noneed for an explicit retransmission after anoccasional loss. To cope with persistent faults,the bus controller maintains a counter for eachvariable, indicating how long ago the busrefreshed the variable. In addition, the appli-cation can transmit a check variable for eachvariable to certify the variable’s timely and cor-rect production.

The application accesses process variableseither individually or (more efficiently) byclusters. The process data application layermarshals transmitted data to the individualapplication variables. It also converts datatypes to the representation used by the con-sumer. The gateway between the WTB andMVB copies variables from one bus to theother and synchronizes the cycles. The gate-way can also combine variables, for example,it can build a compound variable indicatingthat all doors are closed in its vehicle.

88

TRAIN NETWORK

IEEE MICRO

Application 1

Bus controller

Cyclicalgorithms

Ports

Bus controller

Cyclicpoll

Periodiclist

Busmaster

Application 2

Cyclicalgorithms

Ports

Application 3

Cyclicalgorithms

Ports

Application 4

Cyclicalgorithms

Ports

Bus controller Bus controller Bus controller

Port dataPort address

Trafficstores

Sourceport

Sinkport

Sinkport

Bus

Figure 9. Broadcast of process variables.

Message transferApplications exchange messages transpar-

ently over the TCN. An application cannotdetermine whether its peer resides on the samebus, the same station, or anywhere else on thenetwork.

To cope with a variety of vehicles andequipment, the TCN uses logical addresseesfor messages. Every node of the train bus sup-ports several application functions, as shownin the map in Figure 10.

From an outside node on the WTB, theinternal organization of a vehicle is notdetectable, it seems as if the train bus nodeexecutes all the functions. One or moredevices or the train bus node can execute theapplication functions. A device might executeseveral functions, or different devices may exe-cute a function. The same principle applies tofunctions communicating over the vehiclebus—the application need not recognizewhere the other function resides.

Applications communicate on a client-serv-er basis. A conversation consists of a call sentby the client and a reply sent by the remoteserver. The network retains no memory of aconversation once transmission is successfulor timed out. This is more efficient in termsof memory and timers than TCP-like stream-oriented protocols and suits the dominantdiagnostics traffic.

The communication layer divides these callor reply messages into small packets for trans-mission. Each packet carries a full address,which identifies its source and destination.The train bus nodes route the packets using afunction directory that indicates which deviceis executing which function. This functiondirectory is static. A dynamic actualizationwould have been more analogous to plug-and-

play, but would have caused major fault-recov-ery delay. A classical sliding window retrans-mission protocol implements flow control anderror recovery. Only end devices execute thistransport protocol; intermediate nodes onlyintervene in exceptional cases (during inau-guration, for instance).

Network managementNetwork management helps configure,

commission, and maintain the TCN. A net-work manager can connect to the TCN, forinstance, as a vehicle device. The networkmanager has access to all devices—in any vehi-cle—connected to the TCN

The network manager can inspect andmodify other devices through an agent (anapplication task running in each station). Theagent has local access to managed objects suchas process variables, protocols, memory, tasks,and clocks. The standard specifies the man-agement services to read and write the man-aged objects, as well as the format of networkmanager messages.

Conformance testingInteroperation will only succeed if manu-

facturers can validate that devices conform tothe TCN specifications. Conformance test-ing guidelines let manufacturers test theirproducts against the standard. In particular,this requirement applies to WTB nodes,which must operate without adjustment whenvehicles of any origin are coupled. The MVBhas similar requirements when it comes toplug-in interchangeability.

To address conformance testing, WG22developed a set of guidelines. This is only thefirst step toward a full program of confor-mance testing that an independent agency,

89MARCH–APRIL 2001

Vehiclebus

Sensor bus

Trainbus

Device

Air condition

Brakes

Doors

Passenger info

Sensors/actors

Busmaster

Train-vehiclegateway

DoorsDevice Device Device Device

Figure 10. Map of logically addressed application functions that are typical in a railway car.

such as the European Railways Research Insti-tute, would perform. The IEC set up Work-ing Group 34 to develop a full suite ofconformance tests for a part of the standard.

State of the workStandardization has prompted numerous

railway manufacturers to support TCN-com-pliant product development. Applicationsinclude signaling, radio communication, andWeb access to rolling stock.

DevelopmentA joint development project by a group of

manufacturers—Adtranz, Siemens, and Fire-ma-Ercole Marelli—supports the TCN and hashelped to demonstrate its technical capabilities.

The joint development project memberscombined forces to develop a complete TCNwith all the necessary hardware and software.This group intends to make the componentsavailable to any interested party for their ownimplementations under reasonable conditions.

ERRI test trainAlthough the working group derived the

WTB and MVB from existing, railways-provensolutions, important modifications made inresponse to user requirements demanded acomplete test of the TCN. The UIC, throughthe European Railways Research Institute(ERRI), sponsored a full-scale TCN imple-mentation from May 1994 to September 1995.They tested the TCN on a special test installa-tion in the lab and on an existing track.

The study used test train equipped by dif-ferent manufacturers (Adtranz, Siemens, Fire-ma, and Holec) and with coaches from Italy,Switzerland, Germany, and the Netherlands.The ERRI put this train into revenue servicebetween Interlaken, Switzerland, and Ams-terdam, Netherlands.

This test validated the interoperation of amixed system and confirmed the standarddocuments’ completeness. The valuable expe-rience gained on this train improved the stan-dard, especially in relation to its impact onexisting systems and on exploitation issues(that is, the necessity for personnel to verifythat the two cables are plugged).

StandardizationAlthough the technical standard work was

nearly complete after the ERRI test train, ittook four more years to meet the qualityrequirements for a standard. This long delayis not uncommon in standards work: Whilethe original documents tend to focus on tech-nical aspects, the final documents focus oninterface aspects to ensure that standard-com-pliant devices are interoperable. Thisapproach differs from the current tendency tobase standards on product specifications,allowing different variants, profiles, andincompatible options. For instance, the con-formance test lists several device propertiesthat must exist to bear the name of IEC Std.61375. These properties range from the con-nector to the type of messages that the devicemust send and receive. The result is that theIEC passed this standard in 1999 with near-ly unanimous approval.

The IEEE Rail Transit Vehicle InterfaceStandards Committee adopted the TCN asIEEE Std. 1473 for onboard data communi-cation. Here, the focus of standardization wasdefining which applications the TCN covers,assuming that other bus types aboard the samevehicle exist. The IEC shares this focus, stat-ing that the WTB and MVB should be usedin situations requiring interoperability andinterchangeability. The IEC does not want toforce manufacturers to use TCN where opti-mized solutions already exist.

Eurocab projectA full-size test rig in Brussels demonstrated

the TCN’s application to safety tasks—in par-ticular, automatic train operation. Here, sig-naling equipment from differentmanufacturers with different safety philoso-phies interoperated on a simulated train. Thistest took place within the Eurocab project,and was part of the larger European TrainManagement System. The network’s deter-ministic nature let the safety analysis focus onhardware failures and disturbances.5

ROSIN projectA common communication protocol is

necessary but not sufficient to ensure inter-operation. Applications must also have stan-dardized ways to exchange data, so thatapplications can access equipment and sub-assemblies regardless of manufacturer.

To address this need, the European Union

90

TRAIN NETWORK

IEEE MICRO

set up the three-year ROSIN (Railways OpenSystem Interconnection Network) project.6

About 20 different firms collaborated on thisproject to define device profiles for differentapplications such as

• passenger trains with locomotives,• freight trains,• mass transit,• equipment interfaces (for propulsion,

brake, doors, air conditioning, and soon),

• radio links, and• signaling.

ROSIN defined the exchanged data downto the individual bit level. Standardized datarepresentation definitions exist, but it wouldhave been unrealistic to force all existing equip-ment to switch to a new data-encoding scheme,ignoring the installed base. Therefore, projectmembers defined a notation (ROSIN notationor retrofit notation) that can describe arbitrarybit fields. For instance, say that certain equip-ment exports a variable representing the vehi-cle speed; ROSIN’s preferred measurement is inSI units, representing meter/second as a 32-bitreal number. A manufacturer may howeverspecify a different representation in its device

description file, such as speed_mph as a 16-bitinteger from 0 to 200 miles per hour in little-endian format. By looking at this specification,the user of this device knows how to map thisvariable to other devices.

The ROSIN project concluded with ademonstration of Web access to the vehicles,called RoMain (ROSIN Maintenance). Thegroup equipped a local commuter trainbetween France and Spain with a radio linkand a Web server. This demonstrated that aPC-based Web server could understand thedata traffic on the MVB just by reading theequipment description files.

The demonstration was impressive—userscould inspect vehicle data while the train wasrunning with a standard browser from any-where in the world, via the system architec-ture shown in Figure 11. The main challengewas database management. Indeed, becauseof the radio links’ limited bandwidth, thedevices’ static information isn’t located on thedevices themselves but on the railway opera-tor’s Web server. This arrangement arose fromthe fear that mergers and sales among devicemanufacturers would rapidly make the Weblinks obsolete. This makes updating hand-books and maintenance manuals easy, butrequires a rather high administrative effort.

91MARCH–APRIL 2001

RemoteRoMain clients

ROSIN server(railways directory)

Open Doorsserver

Otherserver

Railways operators

HTTPserver

Train equipment

Proxy Proxy ProxyTCN

Internet

Access to dynamicequipment information(variable values, logs)

Access to staticequipment information

(Web pages)RoGate

RTPManager

EuroRailserver

TCN management messages

Manufacturers

Secure TCP/IPnetwork

RTPAgent TCN

devices RTPAgent

Figure 11: RoMain architecture for Web access to moving trains over radio links.

US initiativesAfter the IEEE Rail Transit Vehicle Interface

Standard Committee accepted the IEEE Std.1473, work continued in the IEC WorkingGroup 9 to define the equipment interface.This working group conidered the experienceof the American Public Transportation Associ-ation and the work of the Transit Communi-cation Interface Profile project. In parallel,Working Group 01 is developing an openTCN stack as a clean room implementation.The first WTB-equipped train in the USshould be the New Jersey’s Comet 5 train.

The IEC/UIC standardization of the TCNensures a good base for actual and future

developments. The number of TCNequipped vehicles is growing rapidly. All newprojects by Adtranz, Firema, Siemens, and sev-eral other manufacturers are TCN based.

Railways are now specifying TCN confor-mance in their public bids. The standardiza-tion of application functions is anindispensable further step to achieve plug-ininterchangeability of equipment and vehicles.

The TCN technology has spread outside ofthe railways community. It is used in high-voltage substation control and in printingmachines, where real-time constraints are asdemanding as in railways. MICRO

References1. Train Communication Network, IEC 61375,

International Electrotechnical Committee,Geneva, 1999; http://www.iec-tcn.org.

2. IEEE Std. 1473-1999, IEEE Standard forCommunications Protocol Aboard Trains,IEEE, Piscataway, N.J., 1999.

3. Information Transfer in Trains, UIC B 108.3,leaflet 556, 11th ed., Union Internationaledes Chemins de Fer [International RailwaysUnion], Utrecht, Netherlands, 1996.

4. P. Koopman and T. Chakravarty, Analysis ofthe Train Communication Network ProtocolError Detection Capabilities, ECEDepartment and ICES, Carnegie MellonUniversity, Pittsburgh, Pa.

5. B. Eschermann et al., Fail-Safe On-Board DataBus for Automatic Train Protection, Railtech,Birmingham, 1994; http://www.cordis.lu/transport/src/eurosig.htm.

6. Telematics Applications for TransportResearch Information, 4th Framework

Research Projects ROSIN TR 1045 RailwayOpen System Interconnection Network,European Union, Brussels, Belgium;www.labs.it/rosin.

Hubert Kirrmann is a senior scientist at ABBCorporate Research, Baden, Switzerland. Hisresearch interests include industrial automa-tion computer buses and fault-tolerant sys-tems. Kirrmann has a PhD from the SwissInstitute of Technology, Zurich. He is a mem-ber of the IEEE and of several interest groups.

Pierre A. Zuber is a fellow engineer at Daim-lerChrysler Rail Systems in Pittsburgh, Pa. Heparticipates in research, development anddesign of industrial control for automatic traincontrol and train communication equipment.Zuber has a BSEE in automated control fromthe Geneva School of Engineering, Switzer-land. He holds several patents and is a mem-ber of the IEEE.

Direct questions and comments about thisarticle to Hubert Kirrmann, ABB CorporateResearch, CH 5405 Baden, Switzerland;hubert.kirrmann@ch.abb.com.

92

TRAIN NETWORK

IEEE MICRO