THE IEC/IEEE TRAIN
`COMMUNICATION NETWORK
`
`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.
`
`Automatic coupling of railway vehi-
`cles has existed since the mechanical Jenny cou-
`pler at the turn of the 19th century. The railway
`industry’s next challenge is automatic coupling
`of the vehicle’s electronic equipment through a
`data bus. This requires a worldwide standard-
`ization of onboard data communication. A
`joint effort by the International Railways
`Union (Union Internationale des Chemins de
`Fer, or UIC), Utrecht, Netherlands, and the
`International Electrotechnical Committee
`(IEC), Geneva, Switzerland has laid the
`groundwork for this standardization. The UIC
`groups all national rail operators worldwide and
`ensures cross-border traffic by standardizing
`track profiles, pneumatic hoses, traction volt-
`ages, operating procedures, and so on. The IEC
`is 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, Japan
`and China representing major railways oper-
`ators and manufacturers, worked several years
`within the IEC’s Working Group 22 (WG22)
`on the definition of the Train Communica-
`tion Network. The TCN was adopted as the
`international 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 and
`adopted TCN as IEEE Std. 1473-1999 Type
`T with no modifications the same year.2
`An international standardization of data
`communication is necessary at both the train
`and vehicle levels. Trains with varying com-
`position during daily service—such as metros,
`or suburban and international trains—need a
`standard form of data communication for train
`control, diagnostics, and passenger informa-
`tion. Such communication should configure
`itself when vehicles are coupled on the track.
`At the vehicle level, a standard attachment
`of equipment would serve manufacturers, sup-
`pliers, and operators. Manufacturers could
`assemble pretested units, such as doors manu-
`factured by subcontractors, which include their
`own computers. Parts suppliers who interface
`with different manufacturers could reduce
`development costs by adhering to one standard.
`Railroad operators could reduce spare parts and
`simplify maintenance and part replacement.
`
`General architecture
`The TCN architecture addresses all relevant
`configurations found in rail vehicles. It com-
`prises the train bus connecting the vehicles and
`the vehicle bus connecting the equipment
`
`Hubert Kirrmann
`ABB Corporate Research
`
`Pierre A. Zuber
`DaimlerChrysler
`Rail Systems
`
`0272-1732/01/$10.00  2001 IEEE
`
`81
`
`Page 1 of 12
`
`Mercedes Exhibit 1014
`
`

`
`TRAIN NETWORK
`
`Node
`
`Train bus
`
`Node
`
`Node
`
`Vehicle bus
`
`Vehicle bus
`
`Vehicle bus
`
`Figure 1. Train communication network.
`
`860 meters (without repeater)
`
`MVB
`
`MVB
`
`0 node
`(conduction vehicle)
`(a)
`
`0 vehicle bus
`
`1 vehicle bus
`(standard MVB)
`
`2 vehicle buses
`(standard and not)
`
`200 meters (without repeater)
`
`MVB
`
`1 vehicle bus
`
`Not standard vehicle bus
`
`200 meters (without repeater)
`
`MVB
`
`MVB
`
`1 vehicle bus
`
`0 vehicle bus
`
`(b)
`
`(c)
`
`Figure 2. Open train with the Multifunction Vehicle Bus as vehicle bus (in some vehicles) and
`the Wire Train Bus as train bus (a); connected train sets with the Wire Train Bus as the train
`bus and the Multifunction Vehicle Bus interconnecting an (inseparable) vehicle set (b); closed
`train, such as a tilting train, with the Multifunction Vehicle Bus both as a train bus and as a
`vehicle bus—a nonstandard bus can also be integrated as vehicle bus (c).
`
`aboard a vehicle or group of
`vehicles, 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 of
`mass-transit train sets (multi-
`ple units) that are not sepa-
`rated during daily use. In
`closed train sets where the
`train bus needs no sequential
`numbering of nodes, the vehi-
`cle bus may serve as a train
`bus, as shown in Figure 2.
`
`Wire Train Bus
`To respond to the demand
`for train-level standardization,
`WG22 specified the Wire
`Train Bus (WTB) as part of
`the TCN architecture. The
`WTB interconnects vehicles
`over hand-plug jumper cables
`or automatic couplers, as
`shown in Figure 3.
`WG22 considered several
`media. It rejected coaxial cable
`because of its poor mechani-
`cal resistance to shock and
`vibration. Optical fiber was
`also dismissed because of dif-
`ficulties in building automat-
`ic
`couplers
`that
`could
`withstand shock and vibration
`as well as harsh weather con-
`ditions. Therefore, as its name
`implies, the WTB uses a twist-
`ed shielded-wire pair, which
`has demonstrated its reliabili-
`
`Port
`
`Bottom
`
`Descending
`
`Jumper cable
`
`Master
`
`Top
`Starboard
`
`Trunk cable
`
`Ascending
`
`1 Node
`
`2
`
`1 Node
`
`2
`
`1
`
`Node
`
`2
`
`2
`
`Node
`
`1
`
`2
`
`Node
`
`1
`
`Intermediate vehicle(s)
`01
`
`Intermediate vehicle(s)
`02
`
`End vehicle
`04
`
`03
`
`End vehicle
`Node number
`63
`
`Figure 3. Wire Train Bus.
`
`82
`
`IEEE MICRO
`
`Page 2 of 12
`
`

`
`ty in several European trains.
`Originally the WTB shared
`the UIC cable with the stan-
`dard wires carrying the DC
`signals for controlling lights,
`loudspeakers, and doors in
`international vehicles. Due to
`these wires limited capacity
`and in view of future require-
`ments, the UIC decided to
`add to the UIC cable a dedi-
`cated, twisted shielded-wire
`pair capable of carrying data at
`1 Mbps. The WTB layout is
`by principle redundant; one
`cable runs on each side of the
`vehicle, as shown in Figure 4.
`The WTB can span 860
`meters, a distance correspond-
`ing to 22 UIC vehicles,
`without a repeater. This
`requirement allows connecting
`of older vehicles not equipped
`with the new data bus onto a
`train. It also allows bypassing of
`vehicles with a low battery volt-
`age—a major concern because
`of battery discharge when vehi-
`cles are in the marshaling yard.
`The WTB may have to oper-
`ate under harsh environmental
`conditions where oxidation of
`contacts can occur. To clean
`oxidized connectors or con-
`tacts, a fritting voltage (clean-
`ing action of the coupler’s
`contact) can be superimposed on the lines.
`The binary data are not transmitted over
`the cable as a sequence of 1s and 0s, techni-
`cally known as nonreturn to zero. Instead, the
`bits have a Manchester encoding scheme,
`offering several advantages (see “Manchester
`encoding” sidebar).
`The WTB’s most salient feature (and a
`unique trait in the railroad industry) is that it
`automatically numbers nodes in sequential
`order and lets all nodes distinguish between
`the train’s right and left sides and aft and fore
`directions. Each time the train composition
`changes, for example, after adding or remov-
`ing vehicles, the train bus nodes execute the
`inauguration procedure, which connects elec-
`trically and assigns a sequential address to each
`
`Redundant nodes
`
`2
`
`WTB node
`
`WTB node
`
`Vehicle
`
`Line B
`
`1
`
`Classic
`UIC lines
`
`WTB cable
`
`Jumper
`
`1
`
`Classic
`UIC
`lines
`
`WTB node
`
`Jumper
`
`Line A
`
`UIC jumper cable
`
`Vehicle
`
`Line A
`
`2
`
`Line B
`
`Figure 4. WTB cabling (top view).
`
`Manchester encoding
`Manchester 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 may
`be 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 increased by sampling the signal at its
`peaks, see Figure A. A clock synchronized to the signal by a phase-locked loop evaluates the position of the
`peak. To allow the phase-locked loop to adjust itself, useful data must be preceded by a preamble with a known
`sequence, 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.
`
`1101010101010101
`
`0 1 1 1 1 1 1
`
`Line
`
`preamble
`
`data
`
`Figure A. The Manchester encoding scheme signal sequence.
`
`node. In general, there is one node per vehi-
`cle, but, as shown in Figure 3, there may be
`more than one or none at all.
`At the end of the inauguration, all vehicles
`recognize the train topography, including
`
`• their own address, orientation (right and
`left), and position with respect to the bus
`master (aft and fore);
`• other vehicles’ number and position in
`the train;
`• other vehicles’ type and version (loco-
`motive, coach, and so on) and their sup-
`ported functions; and
`• their own and other vehicles’ dynamic
`properties (for example, the presence of
`a driver).
`
`MARCH–APRIL 2001
`
`83
`
`Page 3 of 12
`
`

`
`TRAIN NETWORK
`
`End node
`
`Intermediate node(s)
`
`End node
`
`Terminators
`(inserted)
`
`Trunk cable
`
`Jumper cable
`
`Terminators
`(inserted)
`
`+ -
`
`+ -
`
`+ -
`
`+ -
`
`+ -
`
`+ -
`
`+ -
`
`+ -
`
`Bus controllers
`
`Bus controllers
`
`Bus controllers
`
`Bus controllers
`
`Two channels active
`
`One channel active
`
`One channel active
`
`Two channels active
`
`Figure 5. Detailed view of WTB.
`
`Each node comprises two high-level data
`link (ISO 3309) control channels, one for
`each direction (forward, backward) as shown
`in Figure 5. During operation, the end nodes
`insert their termination resistors to close the
`bus, while the intermediate nodes establish
`bus continuity between the end nodes. On
`the end nodes, two channels are active, one
`for the bus traffic and one for detecting addi-
`tional nodes. On the intermediate nodes, only
`one channel is active, the other is isolated to
`reduce bus load.
`When a train composition consisting of N
`nodes is operating, its end nodes send a “We
`are N nodes” frame every 50 ms over the open
`extremity. The rest of the time they “listen” for
`additional nodes. When a second composition
`consisting of M nodes is coupled, the end node
`of the first composition detects the “We are M
`nodes,” while the second composition detects
`the “We are N nodes” of the first composition.
`What follows depends on the respective num-
`ber of nodes: If the second composition has
`more nodes (M > N), then the first composi-
`tion disbands. If both compositions have the
`same strength, the disbanding decision is ran-
`dom. The winning composition integrates the
`nodes of the disbanded composition one by
`one. Each time the winning bus integrates a
`node, the node receives its address and
`becomes the next end node, while the former
`end node switches to an intermediate position.
`The principle is simple, but inauguration
`is complex since it requires correct node num-
`bering and identification in many situations.
`
`For instance, nodes may wake up from low-
`power sleep mode to active mode in the mid-
`dle of an inaugurated composition, nodes
`could start operating as backup in cases where
`a working node fails, or one of the redundant
`lines might fail (only one line is shown in Fig-
`ure 5) and this may not affect numbering. For
`a fast recovery after bus disruption, every node
`can become bus master. In such an event, mas-
`tership automatically transfers to a neighbor-
`ing node. The dining car, for example, can
`become the bus master, but since all TCN
`traffic is slave-to-slave, it will not control the
`train. The worst-case recovery time is less than
`1 second for 32 nodes.
`Once inauguration is finished, the nodes
`broadcast their configuration to each other,
`indicating, for instance, that they represent a
`locomotive, a motor coach, or a driver coach.
`They also broadcast properties, such as the
`length between buffers and their weight. This
`requires a strict definition of the data
`exchanged and builds on the expertise of rail-
`way experts. The WTB data traffic and the
`exact meaning of each variable and each bit is
`standardized in UIC leaflet 556.3
`
`Multifunction Vehicle Bus
`To simplify assembly, commissioning, and
`subsystem reuse, the TCN architecture spec-
`ifies the Multifunction Vehicle Bus (MVB) as
`a vehicle bus. The MVB connects equipment
`within a vehicle or within different vehicles in
`closed train sets. Figure 6 shows what subsys-
`tems it could connect in a locomotive. The
`
`84
`
`IEEE MICRO
`
`Page 4 of 12
`
`

`
`MVB operates at 1.5 Mbps
`and over the following media:
`
`Radio
`
`Power line
`
`Cockpit
`
`Diagnosis
`
`Brakes
`
`Vehicle bus
`
`Train Bus
`
`Power electronics
`
`Motor control
`
`Track signals
`
`• Optical fibers for dis-
`tances over 200 meters
`and for environments
`sensitive to electromag-
`netic interference (in
`locomotives). MVB
`specifies 240-µm fibers,
`which are more robust
`against cracks and vibra-
`tions than standard tele-
`com fibers.
`• Transformer-coupled, 120-ohm twisted-
`wire pairs for distances of up to 200
`meters to connect two or three vehicles
`in a train set. These specifications resem-
`ble those of IEC 61158 but use 120 ohm
`for robustness and low attenuation.
`• RS-485/120-ohm cable for cost effective
`device connections within the same cab-
`inet or on the same backplane with no
`galvanic separation. When galvanically
`separated, this cable can connect equip-
`ment in different vehicles in closed train
`sets.
`
`Figure 6. MVB layout in a locomotive.
`
`Data traffic
`TCN 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. The
`transfer time for process variables must be
`short and deterministic (see the “Determin-
`ism for time-critical data transmission” side-
`bar). Railways require that the train
`communication network guarantee less than
`100 ms of delivery delay from a device on a
`first vehicle bus to a device on a second vehi-
`cle bus, both vehicle buses being connected by
`the train bus. Traction control over the vehicle
`bus requires guaranteed delivery from appli-
`cation to application for all critical variables
`within less than 16 ms. To guarantee these
`delays, the train communication network
`transmits all process variables periodically.
`Message data carry infrequent, but possibly
`lengthy information, for instance, diagnostics
`or passenger information. Message length
`varies between a few bytes to several kilobytes.
`Messages transmission delay must be short on
`the average, but the application tolerates
`delays up to several seconds. This slackened
`requirement lets the TCN transmit messages
`on demand.
`
`Medium access control for periodic and sporadic traffic
`All buses pertaining to the TCN provide
`two basic medium accesses:
`
`• periodic (for data like process variables
`and
`• sporadic (for on-demand data traffic,
`such as messages).
`
`Periodic and sporadic data traffic share the
`same bus, but devices treat each separately.
`
`MARCH–APRIL 2001
`
`85
`
`These different media can by directly con-
`nected with repeaters, since they operate at
`the same speed with the same signaling.
`The MVB is based on the bus pioneered on
`the Swiss Locomotive 460 and is used in over
`600 vehicles worldwide. The MVB enables
`considerable reduction in the amount of
`cabling and increased reliability with respect
`to conventional wiring.
`A dedicated master controls the MVB and
`can have backup from redundant masters to
`increase availability. The MVB controller pro-
`vides redundancy at the physical layer: A
`device transmits on the redundant lines, but
`listens to only one while monitoring the other.
`Other features include high integrity against
`data corruption and, due to its robust Man-
`chester encoding and checksums, fulfillment
`of the IEC 60870-5 FT2 class. The Hamming
`distance is 8 when using fiber optics.4
`
`Common protocols
`Despite differences at the physical and link
`layer, the WTB and MVB adhere to the same
`operating principles.
`
`Page 5 of 12
`
`

`
`Achieving determinism
`Deterministic 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 either
`a master-controlled, token-passing, or clocked operation. All
`TCN buses are deterministic, a philosophy shared by the field
`buses, such as IEC Std. 61158.
`Systems can also achieve determinism in processing by
`enforcing time-bounded tasks and cyclic operation. Examples
`of such systems include industrial programmable-logic con-
`trollers programmed in IEC Std. 61131 function block language.
`Nondeterministic systems have no fixed preallocation of
`resources. Examples include collision-based medium access
`buses, such as Ethernet; databases with semaphore access; and
`preemptive operating systems, such as Unix or Windows.
`
`The controversy
`This controversy over the need for determinism is reflected
`in everyday traffic. For example, commuters accept delays in the
`morning 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, commuters
`expect the operator to tell them about an external cause for the
`delay, such as heavy snowfall, but too much traffic will never
`be an issue (airlines excepted). The amount of reserve time that
`commuters plan on to reach a destination will influence their
`decision on the type of transportation, with a clear advantage
`to the scheduled public transportation with tight time constraints
`and heavy traffic. Estimating delays for the nondeterministic
`automobile transportation requires an analysis of the situation,
`such as listening to traffic news.
`
`Reference
`1. P. Koopman, “Tracking down Lost Messages and
`System Failures,“ Embedded Systems Program-
`ming, Oct. 1996.
`
`TRAIN NETWORK
`
`Deadline
`
`Hard
`real time
`
`Time
`
`Soft
`real time
`
`Probability of delay
`
`Determinism for time-critical data transmission
`The nondeterministic system lets the brake computer peri-
`Controversy rages in the automation community between
`odically ask for the emergency stop’s status. If it does not receive
`those who think that deterministic operation is required and
`those who think a weaker constraint is sufficient.1
`a positive response, it applies the brakes. Although the response
`usually comes within 0.1 s, in some cases response time increas-
`Determinism means that the time between the detection of
`es to 0.6 s. In this situation, the train will suffer an emergency
`a change and response to that change is bound by a maximal
`stop because of data packet corruption or network congestion—
`value, even when including some fault conditions (for example,
`neither are external causes. Increasing the time-out does not
`transient communication error). These systems are also called
`change this situation, but requires longer rails and headway.
`hard real time.
`Both systems are safe, but availability—how often the train
`In this context, nondeterminism means that the system can-
`stops because of false alarms—becomes the issue.
`not provide an upper bound for its response time but will nor-
`mally react fast enough for all practical purposes. Such systems
`are sometimes called soft real time.
`The distinction between deterministic and nondeterministic
`systems is visible in a plot of the probability of response versus
`the response time, as shown in Figure B.
`While a deterministic system responds before the deadline
`under all circumstances, the nondeterministic system has a non-
`zero probability of missing its deadline, although it usually reacts
`faster under normal
`conditions.
`Determinism is a sys-
`tem property. Every com-
`ponent (whether for data
`acquisition, processing,
`transmission, or storage)
`must be deterministic for
`the whole system to be
`deterministic. A deter-
`ministic bus is no guaran-
`tee that the whole system
`will be hard real time.
`Of course, no system
`behaves deterministical-
`ly under all failure scenarios. But a nondeterministic system
`introduces temporal errors because of its very nature and with-
`out any external influence.
`
`Figure B. Response delay probability for deter-
`ministic or hard real-time systems and for non-
`deterministic or soft real-time systems.
`
`Example systems
`A safety system reads an emergency stop signal and should
`stop the train before reaching a switch. Safety-critical systems
`operate in negative mode, meaning that the brake computer
`applies the brakes if it doesn’t receive confirmation that the
`emergency 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 will
`wait for three cycles before applying the brakes, its timer being
`set 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).
`
`86
`
`IEEE MICRO
`
`Page 6 of 12
`
`

`
`Basic period
`
`Basic period
`
`Periodic phase
`
`Sporadic phase
`
`Periodic phase
`
`Sporadic phase
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`?
`
`?
`
`?
`
`?
`
`1
`
`2
`
`7
`
`8
`
`9
`
`10
`
`?
`
`1
`
`?
`
`?
`
`1
`
`2
`
`3
`
`Events ?
`
`Guard
`time
`
`Individual period
`
`Events ?
`
`Event
`data
`
`Guard
`time
`
`Time
`
`Figure 7. Alternating periodic and sporadic data transmissions lets a single bus transmit both types of data. Process variables
`are transmitted at regular intervals (1 ms) and after transmission, the bus checks for sporadic traffic demand and transmits, if
`requested, a message packet, if the guard time is respected.
`
`Bus
`master
`
`Bus
`master
`
`Sink
`
`Source
`
`Sink
`
`Sink
`
`Variable identifier
`
`Sink
`
`Source
`
`Sink
`
`Sink
`
`Devices
`(slaves)
`
`Bus
`
`Devices
`(slaves)
`
`Bus
`
`Subcribed devices
`
`Variable value
`
`(a)
`
`(b)
`
`Figure 8. Source-addressed broadcast. In the first phase (a), the master broadcasts a short, master frame with the identifier of
`a variable, taken from its poll list. In the second phase (b), the source device sends the variable’s value in a slave frame, all
`devices interested in that value receive it. The master is normally neither source not sink of the variables.
`
`One device acting as master controls period-
`ic and sporadic data transmission, which guar-
`antees deterministic medium access. To
`accomplish this, the master alternates period-
`ic and sporadic phases, as shown in Figure 7.
`Traffic is divided into basic periods of fixed
`duration—either 1 or 2 ms on the MVB and
`25 ms on the WTB. At the start of a period, the
`master polls the process variables in sequence
`during a certain time period—the periodic
`phase. To reduce traffic, urgent data are trans-
`mitted every period and less urgent variables are
`transmitted with an individual period every sec-
`ond, forth, eight, and so on basic period, with
`the longest period being 1,024 ms.
`After transmitting the process variables, the
`bus master checks for sporadic data to trans-
`mit. On the WTB, a flag in the periodic data
`signals that a node has sporadic data pending.
`On the MVB, an arbitration procedure ensures
`
`that one of several devices gets serviced. If there
`are no sporadic data to transmit, the sporadic
`phase remains unused. If there are data, the
`master checks that sufficient time remains until
`the start of the next period (it respects the
`guard time), and if so, invites a device to trans-
`mit its sporadic data. A highly precise start of
`the next period is needed because the first mas-
`ter frame of a period serves to synchronize all
`clocks with a jitter of some microseconds.
`
`Process variable transmission
`In the first phase of process variable trans-
`mission, the master broadcasts a frame to trig-
`ger transmission of a certain variable without
`specifying the source device. In a second phase,
`the source device answers by broadcasting a
`frame containing the requested value to all
`devices. Each device interested in this variable
`picks up the value, as shown in Figure 8.
`
`MARCH–APRIL 2001
`
`87
`
`Page 7 of 12
`
`

`
`TRAIN NETWORK
`
`Cyclic
`algorithms
`
`Cyclic
`algorithms
`
`Cyclic
`algorithms
`
`Cyclic
`algorithms
`
`Cyclic
`poll
`
`Bus
`master
`
`Periodic
`list
`
`Application 1
`
`Application 2
`
`Application 3
`
`Application 4
`
`Source
`port
`
`Ports
`
`Ports
`
`Ports
`
`Ports
`
`Traffic
`stores
`
`Sink
`port
`
`Sink
`port
`
`Bus controller
`
`Bus controller
`
`Bus controller
`
`Bus controller
`
`Bus controller
`
`Bus
`
`Port address
`
`Figure 9. Broadcast of process variables.
`
`Port data
`
`To increase efficiency, slave frames carry
`numerous variables having the same period,
`called a data set. A data set contains values and
`check bits, but no addresses. Each variable is
`identified by its offset from the data set’s
`beginning, each set is identified by the master
`frame. To maintain determinism, the config-
`uration tools define the frame format and the
`poll lists before operation starts, after this, the
`traffic pattern cannot change. On the MVB,
`each device can subscribe (as either a source
`or sink) to up to 4,096 data sets. On the
`WTB, each node has only one data set to
`broadcast, but it can receive up to 32 data sets
`from other nodes.
`The sources or sink data sets with the val-
`ues of the variables are stored in a shared
`memory, called the traffic store. The applica-
`tion processor and the bus controller can
`simultaneously access the traffic store on a
`device. The traffic stores implement con-
`jointly a distributed database, as shown in Fig-
`ure 9, which the bus keeps synchronized. For
`the application programmers, the bus behaves
`like a shared memory.
`Source-addressed broadcast lets applications
`and 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 the
`periodic nature of the application processes
`and the bus.
`Since the master periodically requests the
`transmission of process variables, there is no
`need for an explicit retransmission after an
`occasional loss. To cope with persistent faults,
`the bus controller maintains a counter for each
`variable, indicating how long ago the bus
`refreshed the variable. In addition, the appli-
`cation can transmit a check variable for each
`variable to certify the variable’s timely and cor-
`rect production.
`The application accesses process variables
`either individually or (more efficiently) by
`clusters. The process data application layer
`marshals transmitted data to the individual
`application variables. It also converts data
`types to the representation used by the con-
`sumer. The gateway between the WTB and
`MVB copies variables from one bus to the
`other and synchronizes the cycles. The gate-
`way can also combine variables, for example,
`it can build a compound variable indicating
`that all doors are closed in its vehicle.
`
`88
`
`IEEE MICRO
`
`Page 8 of 12
`
`

`
`Train
`bus
`
`Bus
`master
`
`Train-vehicle
`gateway
`
`Air condition
`
`Passenger info
`
`Vehicle
`bus
`
`Device
`Doors
`
`Sensors/
`actors
`
`Device
`
`Device
`
`Device
`Sensor bus
`
`Device
`Doors
`
`Brakes
`
`Figure 10. Map of logically addressed application functions that are typical in a railway car.
`
`Message transfer
`Applications exchange messages transpar-
`ently over the TCN. An application cannot
`determine whether its peer resides on the same
`bus, the same station, or anywhere else on the
`network.
`To cope with a variety of vehicles and
`equipment, the TCN uses logical addressees
`for messages. Every node of the train bus sup-
`ports several application functions, as shown
`in the map in Figure 10.
`From an outside node on the WTB, the
`internal organization of a vehicle is not
`detectable, it seems as if the train bus node
`executes all the functions. One or more
`devices or the train bus node can execute the
`application functions. A device might execute
`several functions, or different devices may exe-
`cute a function. The same principle applies to
`functions communicating over the vehicle
`bus—the application need not recognize
`where the other function resides.
`Applications communicate on a client-serv-
`er basis. A conversation consists of a call sent
`by the client and a reply sent by the remote
`server. The network retains no memory of a
`conversation once transmission is successful
`or timed out. This is more efficient in terms
`of memory and timers than TCP-like stream-
`oriented protocols and suits the dominant
`diagnostics traffic.
`The communication layer divides these call
`or 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 a
`function directory that indicates which device
`is executing which function. This function
`directory is static. A dynamic actualization
`would 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 and
`error recovery. Only end devices execute this
`transport protocol; intermediate nodes only
`intervene in exceptional cases (during inau-
`guration, for instance).
`
`Network management
`Network management helps configure,
`commission, and maintain the TCN. A net-
`work manager can connect to the TCN, for
`instance, as a vehicle device. The network
`manager has access to all devices—in any vehi-
`cle—connected to the TCN
`The network manager can inspect and
`modify other devices through an agent (an
`application task running in each station). The
`agent has local access to managed objects such
`as 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 network
`manager messages.
`
`Conformance testing
`Interoperation will only succeed if manu-
`facturers can validate that devices conform to
`the TCN specifications. Conformance test-
`ing guidelines let manufacturers test their
`products against the standard. In particular,
`this requirement applies to WTB nodes,
`which must operate without adjustment when
`vehicles of any origin are coupled. The MVB
`has similar requirements when it comes to
`plug-in interchangeability.
`To address conformance testing, WG22
`developed a set of guidelines. This is only the
`first step toward a full program of conformance
`testing that an independent agency, such as the
`
`MARCH–APRIL 2001
`
`89
`
`Page 9 of 12
`
`

`
`TRAIN NETWORK
`
`European Railways Research Institute, would
`perform. The IEC set up Working Group 34
`to develop a full suite of conformance tests as
`a second part of the standard.
`
`State of the work
`Standardization has prompted numerous
`railway manufacturers to support TCN-com-
`pliant product development. Applications
`include signaling, radio communication, and
`Web access to rolling stock.
`
`Development
`A joint development project by a group of
`manufacturers—Adtranz, Siemens, and Fire-
`ma-Ercole Marelli—supports the TCN and has
`helped to demonstrate its technical capabilities.
`The joint development project members
`combined forces to develop a complete TCN
`with all the necessary hardware and software.
`This group intends to make the components
`available to any interested party for their own
`implementations under reasonable conditions.
`
`ERRI test train
`Although the working group derived the
`WTB and MVB from existing, railways-proven
`solutions, important modifications made in
`response to user requirements demanded a
`complete test of the TCN. The UIC, through
`the 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 service
`between Interlaken, Switzerland, and Ams-
`terdam, Netherlands.
`This test validated the interoperation of a
`mixed system and confirmed the standard
`documents’ completeness. The valuable expe-
`rience gained on this train improved the stan-
`dard, especially in relation to its impact on
`existing systems and on exploitation issues (for
`example, the necessity for personnel to verify
`that the two cables are plugged).
`
`Standardization
`Although the technical standard work was
`
`nearly complete after the ERRI test train, it
`took four more years to meet the quality
`requirements for a standard. This long delay
`is not uncommon in standards work: While
`the original documents tend to focus on tech-
`nical aspects, the final documents focus on
`interface aspects to ensure that standard-com-
`pliant devices are
`interoperable. This
`approach differs from the current tendency to
`base standards on product specifications,
`allowing different variants, profiles, and
`incompatible options. For instance, the con-
`formance test lists several device properties
`that must exist to bear the name of IEC Std.
`61375. These properti