Hubbry Logo
Train communication networkTrain communication networkMain
Open search
Train communication network
Community hub
Train communication network
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Train communication network
Train communication network
Train communication network
View on Wikipedia
from Wikipedia

The train communication network (TCN) is a hierarchical combination of two fieldbus networks for data transmission within trains. It consists of the Multifunction Vehicle Bus (MVB) inside each vehicle and of the Wire Train Bus (WTB) to connect the different vehicles. The TCN components have been standardized in IEC 61375.

Key Information

Multifunction vehicle bus (MVB)

[edit]

The MVB connects individual nodes within a vehicle or closed train set. Unlike the WTB, there is no single connector standard for the MVB – instead, there are 3 defined media and connector classes:

  • OGF (Optical Glass Fibre) uses 240 micron fiber up to 2000 m
  • EMD (Electrical Medium Distance) uses shielded twisted pair with RS-485 transmitters and transformers for galvanic isolation, up to 200 m
  • ESD (Electrical Short Distance) uses simple backplane wiring without galvanic isolation, up to 20 m

The plugs and sockets are the same as used by Profibus, with 2 x DE-9 sockets per device.[1]

For OGF, the media sources are connected by repeaters[citation needed] (signal generators) being joined on a central star coupler. A repeater is also used for the transition between mediums.

There is no inauguration, the addresses are statically allocated. The number of addressable devices depends on the configuration of the vehicle bus – there may be up to 4095 simple sensors/actuators (Class I) and up to 255 programmable stations (Class 2, with configuration slots). The physical level is using transmissions at a 1.5 Mbit/s data rate using Manchester II encoding. The maximum distance is determined on the restriction of a maximum allowed reply delay of 42.7 μs (where for longer distances a second mode is used that allows up to 83.4 μs with reduced throughput, in case MVB is used for switchgear on the track side) while most system parts communicate with a response time of a typical 10 μs.[1]

History

[edit]

MVB was derived from the P215 bus developed by Brown Boveri Cie, Switzerland (now ABB), incorporating the publisher/subscriber principle from early field busses (DATRAS)[citation needed]. Back in 1984, IEC TC 57 defined the requirement specifications for busses to be used in electrical substation in collaboration with IEC SC65C. MVB presents many similarities with the FIP field bus (originally from French "Flux d'Information vers le Processus", relabeled as Factory Instrumentation Protocol or some references also use the hybrid "Flux Information Protocol") that was developed in the French NFC 46602 standard series.[2] Since both stemmed from the same IEC TC 57 specifications. This explains why MVB and FIP have similar operation (cyclic and event-driven), only the arbitration method in case of multiple access differs, as MVB used a binary bisection mode relying of collision detection while FIP piggy-backed a "look-at-me" bit over periodic data. Efforts to merge FIP and MVB failed at the stubbornness of the two parties[citation needed]. MVB, Profibus and WorldFIP were proposed as a substation bus in IEC TC 57, but to avoid parallel solutions, IEC TC 57 decided that none will be used and favored Ethernet as a common denominator[citation needed].

The MVB frames are not compatible with IEC 61158-2 fieldbus frames as it omits most of the preamble synchronization (which is not required if zero-crossing detection is possible).[1] The paradox situation is that the IEC 61158 field bus and MVB physical layer were developed by the same persons in IEC TC 57. The difference came from the fieldbus physical layer which assumes a phase-locked loop to decode the Manchester data, requiring a preamble to synthonize the decoder, while MVB operated principally with optical fibres[citation needed] where this method is useless, MVB's decoding relies on zero-crossing detectors and Manchester pattern recognition.

However most of the modern development and test equipment can equally communicate WTB/MVB frames as well as Profibus frames on the line[citation needed] as the telegram structure similar to Profibus.

The WorldFIP connectors found usage in train equipment in France and North America (by Bombardier) until a joined effort on a common UIC train bus was started (with Siemens and other industry partners) that led to the WTB/MVB standard in late 1999[citation needed].

Alternate vehicle buses

[edit]

The MVB standard was introduced to replace the multitude of field buses in the train equipment. Despite the advantages of the MVB field bus, many vehicle buses are still built from CANopen, WorldFIP (in France), LonWorks (in the USA) and Profibus components. While the WorldFIP, CANopen, Lonworks and Profinet are controlled by international manufacturer associations targeting a wide range of application, MVB was tailored to the rolling stock application, with the goal of plug-compatibility, and therefore allows no options. This was intentional as the fight between the field busses raged in the 1990s[citation needed] and the decision of the IEC that any of the eight[citation needed] field busses was a standard did not help plug-compatibility.

MVB modules are more expensive than for instance CANopen or LonWorks components. This is not due to the communication technology: most devices implement the MVB protocol machine in a small area of an FPGA which is today anyhow present, and the costliest component remains the connector[citation needed]. But railways certification is costly and not always needed for uncritical applications such as comfort and passenger information. When total cost of ownership is considered, the cost of the hardware elements can easily be outweighed by additional engineering costs in the railways market with its small series.

In the USA, the IEEE RTVISC evaluated both MVB and LON as vehicle and train bus. The IEEE finally decided to standardize both in IEEE 1374, with a clear separation of tasks[citation needed]:

  • MVB for critical operation such as traction control and signalling in the driver's cab,
  • LON for uncritical and slow data transfer, but low-cost connections such as passenger displays and diagnostics. This separation is not always observed[citation needed].

Additionally more and more components are added to rail vehicles that need far more bandwidth than any field bus can provide (e.g. for video surveillance), so switched Ethernet IEEE 802.3 with 100 Mbit/s is being introduced into train sets (according to the EN 50155 profile). Still all the alternate vehicle buses are connected to the Wire Train Bus.[3]

MVB is similar to FlexRay, both have the "process data", which is called "static segment" in FlexRay, and "message data", which is the "dynamic segment" and are driven by a fixed TDMA scheme. Running FlexRay with 2.5 Mbit, an RS-485 physical layer and only one "coldstarter" would lead to a very similar behavior in respect to the application. Despite the similarities, no rail-manufacturer has considered FlexRay, since they valuated a common solution higher than a multitude of better busses. Conversely, in 1999, the automotive industry evaluated MVB[citation needed] (in an extended 24 Mbit/s version), but dropped it because of the costs, which should be unreasonably low for the mass-market of millions of vehicles.

Wire train bus (WTB)

[edit]

The wire train bus has been designed for international passenger trains with variable composition, consisting of up to 22 vehicles.

The medium consists of a duplicated shielded twisted pair cable, which runs in the UIC cables between the vehicles.

The connector between the vehicles is the 18-pole UIC connector. Since connectors are exposed and can oxidize, a current pulse is applied at connection establishment to evaporate the oxide layer, called fritting. The standard connector for the WTB nodes is a DIN 9 pin connector.

The physical level uses RS-485 levels at 1 Mbit/s data rate. The encoding uses a Manchester II code and a HDLC frame protocol with proper voltage balancing to avoid DC components in the galvanic isolation transformers. The Manchester decoder uses a phase/quadrature demodulation (not RS-485, that operates with zero-crossings) which allows to span 750 m under worst-case conditions, especially when only the two extremity vehicles are equipped, as is the case with multiple traction for freight trains. No repeaters are foreseen since vehicles in between can have discharged batteries.

A unique property of the WTB is the train inauguration (In German: Zugtaufe) in which the newly connected vehicles receive an address in sequence and can identify the vehicle side (called port and starboard like in the marine) so that doors open on the correct side. Up to 32 addresses can be dynamically allocated. When two train compositions join, the addresses are reallocated to form a new composition of vehicles with a sequential address. Vehicles without WTB node ("conduction vehicles") are not counted.

The frames have a maximum payload of 1024 bits.

The WTB operates cyclically to provide deterministic operation, with a period of 25 ms, used mainly for the traction control[citation needed]. The WTB also supports sporadic data transmission for diagnostics. The content of the periodic and sporadic frames is governed by the UIC 556 standard.[4] Since frame size is limited, a version of TCP with reduced overhead was used for message segmenting and reassembly, that at the same time allows to cope with changes in composition, called RTP (Real-Time Protocol).

Alternate train buses

[edit]
Main article: Ethernet train backbone

History

[edit]

The WTB was derived from the German DIN bus developed by ABB Henschel[citation needed] (now Bombardier[citation needed]). It benefited from the phase/quadrature decoding provided by Italy and from an improved train inauguration provided by Switzerland, based on the experience with the FSK multiple traction bus of ABB Secheron, Geneva used in the SBB freight trains[citation needed]. The physical layer of WTB shows similarities with the WorldFIP field bus (EN 50170 part 4) - its "voltage mode" did use 1 Mbit/s and a maximum of 32 stations on the bus with a maximum length of 750 meters, the use of FIP transceivers was studied early[citation needed] in the TCN evaluation, but the Phase/Quadrature decoding was used instead.

Usage

[edit]

The TCN is used in most of the modern train control systems usually connecting the vehicles with an 18-pin UIC 558, including:

IEC 61375 standards

[edit]

IEC 61375 is a suite of standards.

IEC 61375 suite of standards
Code Title Abstract
IEC 61375-2-1:2012 Electronic railway equipment - Train communication network (TCN) - Part 2-1: Wire Train Bus (WTB) IEC 61375-2-1:2012 applies to data communication in Open Trains, i.e. it covers data communication between consists of the said open trains and data communication within the consists of the said open trains.
IEC 61375-2-2:2012 Electronic railway equipment - Train communication network (TCN) - Part 2-2: Wire Train Bus conformance testing IEC 61375-2-2:2012 applies to all equipment and devices implemented according to IEC 61375-2-1, i.e. it covers the procedures to be applied to such equipment and devices when the conformance should be proven. The applicability of this standard to a TCN implementation allows for individual conformance checking of the implementation itself and is a pre-requisite for further interoperability checking between different TCN implementations.
IEC 61375-2-3:2015 Electronic railway equipment - Train communication network (TCN) - Part 2-3: TCN communication profile IEC 61375-2-3:2015 specifies rules for the data exchange between consists in trains. The aggregation of these rules defines the TCN communication profile. The objective of the communication profile is to ensure interoperability between consists of the said trains with respect to the exchange of information. For this purpose it defines all items which are necessary for communication interoperability:
  • an architecture with defined train directions related to different train views;
  • a common functional addressing concept;
  • common communication protocol for data exchange between functions;
  • a set of services for train communication control.

The contents of the corrigendum of December 2015 and October 2016 have been included in this copy.

IEC TS 61375-2-4:2017 Electronic railway equipment - Train communication network (TCN) - Part 2-4: TCN application profile IEC TS 61375-2-4:2017(E) applies to the applications in trains, i.e. it covers the application profile for functions belonging to the Train Control and Monitoring System (TCMS). The application profile is based on the TCN communication system for the data communication between consists of the said trains. This document provides for a data interface with parameters and addressing of TCMS functions based on the communication profile laid out in IEC 61375-2-3. This document is applicable in rolling stock requiring interoperable coupling and uncoupling. This part of IEC 61375 may be additionally applicable to closed trains and multiple unit trains when so agreed between purchaser and supplier.
IEC 61375-2-5:2014 Electronic railway equipment - Train communication network (TCN) - Part 2-5: Ethernet train backbone IEC 61375-2-5:2014 defines Ethernet Train Backbone (ETB) requirements to fulfil open train data communication system based on Ethernet technology. Respect of this standard ensures interoperability between local Consist subnets whatever Consist network technology (see IEC 61375-1 for more details). All Consist network definitions should take into account this standard to preserve interoperability. This standard may be additionally applicable to closed trains and multiple-unit trains when so agreed between purchaser and supplier.
IEC 61375-2-6:2018 Electronic railway equipment - Train communication network (TCN) - Part 2-6: On-board to ground communication IEC 61375-2-6:2018 establishes the specification for the communication between the on-board subsystems and the ground subsystems. The communication system, interfaces and protocols are specified as a mobile communication function, using any available wireless technology. This document provides requirements in order to:

a) select the wireless network on the basis of QoS parameters requested by the application; b) allow TCMS and/or OMTS applications, installed on-board and communicating on the on-board communication network, to have a remote access to applications running on ground installations; c) allow applications running on ground installations to have a remote access to the TCMS and/or OMTS applications installed on-board.

IEC TR 61375-2-7:2014 Electronic railway equipment - Train communication network (TCN) - Part 2-7: Wireless Train Backbone (WLTB) IEC TR 61375-2-7:2014 describes the protocols stack of a radio based wireless train backbone which is used in distributed power freight trains. This part provides information on the physical layer, the data link layer, the application layer and distributed power application.
IEC 61375-2-8:2021 Electronic railway equipment - Train communication network (TCN) - Part 2-8: TCN conformance test IEC 61375-2-8:2021 applies to all equipment and devices implemented according to IEC 61375-2-3:2015, IEC 61375-2-5:2014 and IEC 61375-3-4:2014, i.e. it covers the procedures to be applied to such equipment and devices when the conformance should be proven. The applicability of this document to a TCN implementation allows for individual conformance checking of the implementation itself, and is a pre-requisite for further interoperability checking between different TCN implementations.
IEC 61375-3-1:2012 Electronic railway equipment - Train communication network (TCN) - Part 3-1: Multifunction Vehicle Bus (MVB) IEC 61375-3-1:2012 applies where MVB is required.
IEC 61375-3-2:2012 Electronic railway equipment - Train communication network (TCN) - Part 3-2: MVB (Multifunction Vehicle Bus) conformance testing IEC 61375-3-2:2012 applies to all equipment and devices implemented according to IEC 61375-3-1, i.e. it covers the procedures to be applied to such equipment and devices when the conformance should be proven. The applicability of this standard to a TCN implementation allows for individual conformance checking of the implementation itself and is a pre-requisite for further interoperability checking between different TCN implementations.
IEC 61375-3-3 Electronic railway equipment - Train communication network (TCN) - Part 3-3: CANopen Consist Network (CCN) IEC 61375-3-3:2012 specifies the data communication bus inside consists that are based on CANopen. CANopen was developed for use in, but is not limited to, industrial automation applications. These applications may include devices such as input/output modules, motion controllers, human machine interfaces, sensors, closed-loop controllers, encoders, hydraulic valves or programmable controllers. This part of IEC 61375 applies to all equipment and devices operated on a CANopen-based consist network within TCN architecture as described in IEC 61375-1.
IEC 61375-3-4:2014 Electronic railway equipment - Train communication network (TCN) - Part 3-4: Ethernet Consist Network (ECN) IEC 61375-3-4:2014 specifies the data communication network inside a Consist based on Ethernet technology, the Ethernet Consist Network (ECN). The applicability of this part of IEC 61375 to the Consist Network allows for interoperability of individual vehicles within Open Trains in international traffic. This part of IEC 61375 may be additionally applicable to closed trains and Multiple Unit Trains when so agreed between purchaser and supplier.


Further reading

[edit]

Notes and references

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Train communication network

View on Grokipedia
from Grokipedia
A train communication network (TCN) is a standardized digital communication system designed for railway vehicles, enabling the reliable exchange of data between subsystems across multiple train cars to support essential functions such as , vehicle diagnostics, passenger information, and operational monitoring. The TCN facilitates in open train configurations, allowing electronic equipment from different manufacturers to connect seamlessly without custom adaptations. Originating from efforts by the (UIC) in the 1990s, including the project for standardized data exchange, the TCN was developed through international collaboration and first adopted as the IEC 61375 standard in 1999 by the (IEC) and harmonized with IEEE Std. 1473-1999 for rail transit vehicles. This standard defines a multi-level to ensure real-time performance, , and , with ongoing updates, including the fourth edition of IEC 61375-1 under publication in 2025, to incorporate advancements like enhanced video streaming and train-to-ground interfaces. The primarily comprises two key buses: the Wire Train Bus (WTB), which interconnects up to 22 vehicles over distances up to 860 meters using a 1 Mbps twisted-pair cable for backbone communication, and the Multifunction Vehicle Bus (MVB), operating at 1.5 Mbps to link subsystems within a single vehicle via twisted-wire pairs or optical fibers. The TCN's design emphasizes and , incorporating deterministic protocols to handle non-vital data transmission while supporting integration with vital safety systems. It has been widely implemented in European and global rail networks, promoting cost efficiency through standardized components and reducing wiring complexity in modern trains. Recent evolutions, including parts of the IEC 61375 series like IEC 61375-2-3 for the TCN communication profile supporting video services, address emerging needs such as high-bandwidth applications in smart rail systems.

Introduction

Definition and purpose

The Train Communication Network (TCN) is a hierarchical, real-time system designed for transmitting control, status, and diagnostic data across various components of a train, serving as the foundational communication infrastructure within Train Control and Management Systems (TCMS). Standardized under IEC 61375, it enables seamless data exchange between programmable equipment inside vehicles and across multiple coupled vehicles, ensuring reliable operation in rail environments. The primary purposes of TCN include facilitating among vehicles manufactured by different suppliers, thereby allowing flexible train compositions without custom wiring adaptations. It supports essential control functions such as braking, , and systems, while providing fault-tolerant mechanisms to maintain communication integrity during failures. Additionally, TCN enables real-time monitoring and diagnostics for subsystems, enhancing overall and efficiency. At its core, TCN comprises a for intra-vehicle connections linking local devices and controllers, and a train bus for inter-vehicle links that extend communication across the entire consist. This structure supports the hierarchical architecture detailed in subsequent sections on system design. Key benefits include reduced wiring complexity by replacing extensive point-to-point cabling with networked links, deterministic data transmission critical for applications, and to accommodate trains of varying lengths and configurations.

Historical background

In the pre-TCN era, European railway systems relied on ad-hoc wiring and proprietary bus systems for onboard communication, such as point-to-point connections and early standards like the UIC cable for basic electrical interfaces, which limited as trains were often composed of vehicles from different manufacturers. These fragmented approaches became increasingly inadequate with the growing complexity of electronic controls for traction, braking, and diagnostics in the 1980s. The push for a standardized Train Communication Network (TCN) emerged in the late 1980s and early 1990s, driven by the (UIC) initiatives to replace proprietary wiring with a unified system for real-time data exchange across vehicles, enabling flexible train formations and reducing installation costs. This effort was accelerated by European rail liberalization, particularly the 1991 EU Council Directive 91/440/EEC, which promoted market opening and harmonization of technical standards to foster cross-border operations and competition among operators. Under IEC Technical Committee 9's Working Group 22 (WG22), involving experts from over 20 countries, the TCN was conceptualized as a hierarchical combining vehicle-level and train-level buses. Key milestones included the early 1990s development of Multifunction Vehicle Bus (MVB) and Wire Train Bus (WTB) prototypes by European consortia such as the Joint Development Project (JDP) and IGZ, which tested master-slave protocols on twisted-pair cabling integrated with the existing UIC cable. Influential projects like the European Railways Research Institute (ERRI) test train in 1994-1995 validated the full TCN system over routes from , , to , , demonstrating reliable communication for control and monitoring. The standard was formally adopted as IEC 61375 in 1999, marking the culmination of UIC-IEC collaboration. Initial commercial implementations occurred in the late 1990s, with deployments in high-speed trains such as Germany's (), where precursor DIN 43322 buses evolved into TCN for distributed control functions.

System Architecture

Hierarchical structure

The Train Communication Network (TCN) employs a two-level hierarchical architecture to manage data transmission efficiently across rail vehicles, as defined in the IEC 61375-1. At the lower level, the consist network facilitates intra-vehicle communication among devices within a single vehicle or a tightly coupled group of vehicles forming a consist. The upper level, known as the train backbone, enables inter-vehicle and consist-to-consist connectivity, allowing coordinated operations across the entire train formation. This layered design ensures localized control remains efficient while supporting global train management without excessive wiring complexity. Data flows from sensors and actuators connected to the consist-level bus, where local processing occurs for vehicle-specific functions, before being routed upward via gateways to the train backbone for train-wide applications such as synchronized door operations or traction coordination. This model promotes modularity, with the consist network handling high-density, real-time device interactions and the backbone distributing aggregated information to maintain overall train integrity. For instance, environmental sensors in one vehicle can contribute data to climate control across multiple consists through this upward pathway. Gateway devices serve as critical intermediaries in the , performing protocol translation and intelligent between the consist bus—such as the Multifunction Vehicle Bus (MVB)—and the train backbone, like the Wire Train Bus (WTB), while preserving real-time priorities for safety-critical messages. These gateways ensure seamless data exchange by mapping messages, managing traffic prioritization, and isolating faults to prevent propagation across levels. The TCN architecture supports scalability for trains comprising up to 22 vehicles, accommodating variable formations typical of international passenger services, with a maximum transmission distance of approximately 860 meters on the backbone without . is incorporated through dual bus paths on the train backbone, providing fault-tolerant operation by allowing automatic in case of cable or node failures, thereby enhancing reliability in dynamic rail environments.

Key principles and interoperability

The Train Communication Network (TCN) is designed around core principles that prioritize , reliability, and in railway operations. Deterministic communication forms a foundational element, ensuring predictable data transmission through fixed cycle times and real-time protocols that support periodic broadcasting of process variables as well as on-demand or messaging. This aligns with philosophies, such as those in IEC 61158, to guarantee timely delivery critical for safety-critical functions. Additionally, the multimaster enables distributed control, where multiple nodes can act as masters for and coordination without a single point of failure, enhancing across the hierarchical structure. Open standards, modeled after the ISO/IEC 7498-1 OSI , promote vendor-neutral operation and avoid lock-in by defining layered protocols that facilitate integration from diverse manufacturers. Interoperability is achieved through standardized interfaces and rigorous testing protocols that ensure seamless connectivity across train consists. Physical and logical interfaces, such as the UIC 558 connectors with 18-conductor cabling, provide consistent electrical and mechanical connections for TCN implementation, supporting both parallel and serial transmission. requirements, outlined in IEC 61375 series, verify compliance at physical, link, and application layers, including procedures for individual device validation prior to full . Protocol conformance classes categorize implementations by complexity, allowing basic to advanced features while maintaining core compatibility, such as Class 1 for essential real-time services and higher classes for extended diagnostics. These features enable multi-vendor ecosystems, where equipment from different suppliers can interoperate without custom adaptations. Safety and reliability are embedded in TCN design through integration with Safety Integrity Level (SIL) requirements as per EN 50128 for software and EN 50129 for hardware in signalling systems. Error detection mechanisms, including (CRC) via frame check sequences, identify transmission faults, while bus monitoring continuously assesses network health to detect anomalies like bit errors or protocol violations. Redundant pathways and fault-tolerant protocols further support SIL 1 to SIL 4 classifications, ensuring hazardous failures are minimized to probabilities below 10^{-9} per hour for highest levels. Modularity in TCN allows for flexible configurations that accommodate varying train compositions while upholding compliance. The architecture supports the addition or removal of nodes and consists through standardized gateways, enabling scalable deployments from regional to high-speed trains. Application-specific profiles permit customization for particular use cases, such as traction control or passenger information, by defining process data marshalling and message services tailored to railway needs, yet all must adhere to core TCN protocols to preserve . This balance ensures that while innovations can be incorporated, the foundational reliability remains intact across the network.

Vehicle-Level Communication

Multifunction Vehicle Bus (MVB)

The Multifunction Vehicle Bus (MVB) serves as the primary intra-vehicle communication bus within the Train Communication Network (TCN), enabling the interconnection of sensors, actuators, and control devices inside a single rail vehicle. Specified in IEC 61375-3-1:2012, the MVB operates at a data rate of 1.5 Mbit/s using II encoding, which combines data transmission with and frame delimiting for reliable over noisy environments typical in rail applications. The access method employs a master-slave with token-passing among up to 256 possible masters, ensuring deterministic behavior through centralized control where one active master polls slaves while backups await token transfer for . The of the MVB supports multiple media types to accommodate varying installation needs: Optical Glass Fibre (OGF) for distances up to 2000 m, Electrical Middle Distance (EMD) using twisted-pair cabling up to 200 m, and Electrical Short Distance (ESD) for connections up to 20 m. Topologies include linear bus configurations for copper media, ring or star setups for optical fibers (with active or passive couplers), providing flexibility for vehicle wiring while maintaining signal integrity through compatible electrical signaling. These options ensure scalability across vehicle segments, from compact control cabinets to extended coach layouts. MVB devices are categorized into classes based on functionality and capabilities, with Class 1 devices dedicated to sensors and actuators that handle up to 4095 total devices on the bus and operate in an event-driven manner for data exchange. Class 2 devices, typically programmable controllers, support cyclic data updates via a process image, enabling periodic polling for real-time control tasks like monitoring vital systems. Higher classes (3-5) extend these with communication for diagnostics and configuration, but Class 1 and 2 form the core for most intra-vehicle applications. At the protocol level, feature variable lengths up to 256 bits for slave responses (equivalent to 32 bytes including overhead), allowing efficient transmission of or tailored to device needs. Scheduling combines priority-based mechanisms, including a periodic list for fixed-cycle (with basic periods of 1-8 ms) and event rounds for sporadic high-priority events, optimizing bus utilization for mixed real-time and non-real-time traffic. Diagnostic features encompass live list maintenance through device status polling and scan protocols, which detect bus changes, monitor freshness of updates, and facilitate fault isolation without disrupting ongoing communication.

Alternatives to MVB

While the Multifunction Vehicle Bus (MVB) provides deterministic token-passing communication at 1.5 Mbit/s for intra-vehicle needs in Train Communication Networks (TCN), several alternative fieldbus systems have been adopted in railway applications, particularly where cost, simplicity, or legacy compatibility take precedence over full TCN interoperability. These alternatives, drawn from industrial and automotive domains, include the Controller Area Network (CAN), Profibus DP, WorldFIP, and LonWorks, each offering distinct trade-offs in performance and suitability for vehicle-level control. CAN, standardized under ISO 11898-1, operates as a multi-master bus using arbitration, supporting data rates up to 1 Mbit/s over twisted-pair cabling. In contrast to MVB's centralized token-passing for guaranteed real-time performance, CAN's non-deterministic access suits less critical peripheral controls, such as door operations or in vehicles and trams, where full TCN integration is unnecessary. Its low-cost implementation, derived from automotive applications, makes it ideal for smaller-scale or cost-sensitive setups, though it requires gateways for TCN connectivity due to lacking native rail-specific features. Profibus DP, a token-ring or master-slave protocol from industrial automation, achieves higher speeds of up to 12 Mbit/s, enabling faster cyclic data exchange for control tasks compared to MVB's 1.5 Mbit/s limit. Historically used in older European before widespread TCN adoption, it facilitated integration of sensors and actuators in legacy trains for functions like braking subsystems or HVAC monitoring. However, its less rail-optimized design often necessitates adapters or bridges to interface with TCN gateways, increasing complexity in mixed environments and limiting seamless train-wide . WorldFIP, a producer-consumer prevalent in French systems, operates at typical rates of 1 Mbit/s and emphasizes scheduled messaging for automation, differing from MVB's master-slave focus. Deployed in high-speed like the for intra-vehicle sensor networks, it supports deterministic exchanges but sees limited global adoption outside and . Its constraints include lower bandwidth scalability and the need for custom gateways in TCN setups, potentially compromising efficiency in dynamic consist configurations. LonWorks, employing a , event-driven protocol at up to 1.25 Mbit/s, has found niche use in North American freight and for distributed control, such as electronically controlled pneumatic (ECP) braking across consists. Unlike MVB's fixed , LonWorks' twisted-pair or powerline transmission offers flexibility for retrofits in older vehicles, but its non-deterministic nature and regional specificity often demand additional interfacing for TCN compliance, raising integration costs.
AlternativeMax Data RateProtocol TypeKey Use Case in RailwaysLimitation vs. MVB
CAN1 Mbit/sMulti-master CSMA/CAPeripheral control in light rail/tramsNon-deterministic; requires TCN gateways
Profibus DP12 Mbit/sToken-ring/master-slaveLegacy European rolling stock automationLess rail-specific; adapter needs
WorldFIP1 Mbit/sProducer-consumer scheduledSensor networks in TGV-like trainsLimited adoption; bandwidth constraints
1.25 Mbit/s event-drivenECP braking in North American freightRegional focus; integration overhead

Train-Level Communication

Wire Train Bus (WTB)

The Wire Train Bus (WTB) functions as the primary backbone for inter-vehicle data exchange in the Train Communication Network (TCN), facilitating real-time transmission of operational commands and status updates across train consists. Defined in IEC 61375-2-1, it employs a protocol optimized for reliability in dynamic rail environments, supporting functions like control and passenger information systems. Key technical specifications include a 1 Mbit/s data rate achieved via II encoding, an HDLC-based protocol for frame handling, and shielded twisted-pair cabling that permits a total network length of up to 860 m without . The ensures and robustness against vibrations and interference common in applications. The network topology adopts a daisy-chain configuration, linking up to 22 vehicles in a linear bus structure where each node connects sequentially via couplers at vehicle ends. Upon train formation, an automated process initializes the network by detecting connected devices, assigning dynamic addresses based on position and orientation, and establishing bus to monitor and detect faults such as disconnections or noise. This self-configuration ensures seamless operation even as consists are added or removed during . Data transmission occurs in fixed 25 ms cycles, dividing time into periodic and event-driven phases to prioritize critical messages while maintaining . Frames follow an HDLC structure with variable payloads up to 1024 bits, enabling efficient handling of train-wide messages such as emergency brake activation, door control synchronization, and consist configuration updates. These cycles support both cyclic process data for ongoing monitoring and acyclic messages for on-demand responses. Redundancy is implemented through an optional dual-bus , where parallel cables run along both sides of the train for ; in case of a on one bus, nodes automatically switch over within a single cycle to maintain continuity. This design, combined with HDLC frame check sequences and encoding's inherent error detection, achieves bit error rates below 10−910^{-9}, ensuring high integrity for safety-critical operations. The WTB briefly interfaces with vehicle-level buses like the MVB to propagate data across the hierarchical TCN structure.

Alternatives to WTB

While the Wire Train Bus (WTB) serves as the standard backbone for train-level communication in the Train Communication Network (TCN), several alternatives have been employed for specific scenarios, particularly in shorter configurations or legacy systems outside full TCN compliance. These include extensions of the Multifunction Vehicle Bus (MVB) for fixed consists, the WorldFIP protocol in select applications, and early non-standardized Ethernet pilots. These options often prioritize or existing but and . The extended use of MVB, as defined in IEC 61375-3, allows it to function beyond a single for closed train sets, such as short regional trains where vehicles are permanently coupled. This approach leverages MVB's 1.5 Mbit/s data rate over shielded twisted-pair cabling, suitable for distances up to approximately 200 meters without repeaters, making it viable for consists of limited length. However, MVB's master-slave access method and reply delay limits (42.7 μs maximum) restrict it to intra-consist communication, rendering it unsuitable for longer, reconfigurable s that require WTB's token-passing across up to 22 vehicles over 860 meters. In practice, this has been applied in fixed-formation trains to avoid the need for a separate backbone, though it demands careful configuration to maintain real-time performance. WorldFIP, a protocol standardized under EN 50170, has been adopted in French rail systems for train-level exchange, particularly in pre-TCN deployments. Operating at speeds including 31.25 kbit/s over shielded twisted-pair for low-speed segments, it supports transmission up to 255 stations per segment with up to three , enabling basic train-wide messaging. Unlike WTB's token-based point-to-point , WorldFIP employs a producer-consumer model where a single producer broadcasts variables to multiple consumers via a central arbitrator, facilitating efficient periodic distribution for control signals. This was notably used in early high-speed applications like TGV precursors, supporting up to 32 connection points per network before the shift to unified TCN standards. Its three-layer architecture (physical, data link, application) ensures deterministic behavior but limits throughput compared to WTB's 1 Mbit/s. Early ad-hoc Ethernet implementations have served as pilots in non-standardized train networks, often supplementing or replacing serial buses in regional operations. For instance, Bombardier deployed Ethernet-based systems in German and Dutch regional trains, integrating devices like cameras, , and propulsion controls over a single network using industrial switches. These setups, running at 100 Mbit/s, initially coexisted with TCN elements, with segments limited to 100 meters requiring repeaters for longer trains, and full migration planned over 2-3 years. Such pilots demonstrated Ethernet's high bandwidth for alongside control data but lacked TCN's safety certifications, necessitating custom validation. A common challenge across these alternatives is reduced with standard TCN components, often requiring gateways to bridge protocols like MVB-to-WTB or WorldFIP-to-Ethernet. For example, WorldFIP networks in legacy French systems needed interfaces for integration with emerging TCN, increasing and costs while compromising plug-and-play reconfiguration. Similarly, extended MVB applications in short trains may employ gateways for external connections, but this introduces latency and potential single points of failure not present in native WTB designs. Overall, these alternatives suit niche or transitional uses but underscore WTB's role in ensuring robust, vendor-independent train-level communication.

Modern Extensions

Ethernet Consist Network (ECN)

The Ethernet Consist Network (ECN) is a network designed for intra-consist connectivity in vehicles, standardized as part of the Train Communication Network (TCN) framework. Defined in IEC 61375-3-4:2014, ECN leverages Ethernet technology to enable communication among end devices within a single consist, such as control units, sensors, and actuators. It operates at speeds of 10 Mbps or 100 Mbps, with modern implementations supporting up to 1 Gbps or higher through compatible hardware. Modern implementations of ECN incorporate (TSN) features, including the Time-Aware Shaper (IEEE 802.1Qbv) for deterministic scheduling and IEEE 1588 for precise time synchronization, to ensure real-time performance for safety-critical applications with low latency and in mixed traffic environments. ECN integrates with the broader TCN architecture by providing a pathway for legacy protocols, such as those from the Multifunction Vehicle Bus (MVB), through encapsulation and gateway mechanisms that map serial data onto Ethernet frames. This allows seamless migration from older systems while supporting up to hundreds of nodes per consist, facilitated by Ethernet switches that scale the network beyond the limitations of bus-based predecessors. The network maintains TCN conformance per IEC 61375-1, ensuring across open train configurations. Key advantages of ECN include its significantly higher bandwidth compared to traditional fieldbuses, enabling support for bandwidth-intensive applications like video surveillance and passenger information systems. It also simplifies integration with IP-based systems, such as diagnostic tools and wireless networks, by natively supporting alongside rail-specific protocols like the Train Real-Time Protocol (TRDP). Despite these enhancements, ECN upholds TCN's and reliability standards through structured . In implementation, ECN typically employs a switched star or ring topology using consist switches to connect end devices, with provisions for redundant paths to achieve and prevent single points of failure. Traffic management relies on priority tagging as defined in , assigning higher priorities to process and safety-related data over best-effort streams, complemented by ingress and egress shaping for congestion control. This configuration supports diverse data types—process, , , and supervisory—while minimizing lifecycle costs through consolidated .

Ethernet Train Backbone (ETB)

The Ethernet Train Backbone (ETB) serves as the high-speed interconnect for train-level communication within the Train Communication Network (TCN), enabling seamless exchange across multiple consists using Ethernet technology. Defined in IEC 61375-2-5:2014 (with a draft for Edition 2 as of October 2024), the ETB operates on full-duplex Ethernet over twisted-pair or optic cables, supporting rates up to 1 Gbit/s to handle increased bandwidth demands for modern rail applications such as real-time diagnostics and systems. This standard ensures among vehicles from different manufacturers by specifying a linear or ring topology that spans the entire train formation. Modern implementations often integrate (TSN) for enhanced determinism. Key features of the ETB include automated train inauguration facilitated by the Train Topology Discovery Protocol (TTDP), which builds on the (LLDP) to detect and configure network nodes dynamically upon coupling or decoupling of consists. The protocol supports configurations with up to 64 consists, allowing for flexible train compositions while integrating with Ethernet Consist Network (ECN) gateways to bridge intra-vehicle and inter-vehicle communications. Protocol adaptations map legacy Wire Train Bus (WTB) services onto Ethernet frames, preserving compatibility with existing TCN elements through standardized encapsulation. This includes the use of multicast addressing for efficient train-wide announcements, such as process data distribution, and tagging per for segregating traffic types like control and diagnostic streams. To achieve , the ETB incorporates mechanisms compliant with IEC 62439, including the Parallel Redundancy Protocol (PRP) for duplicated network paths and the (HSR) protocol for ring-based topologies, enabling seamless zero-recovery-time . These protocols duplicate frames across parallel links or integrate them in a single ring, ensuring continuous operation even during cable faults or node failures common in environments. Overall, the ETB enhances the TCN's scalability and reliability, facilitating the transition from serial bus systems to IP-based Ethernet infrastructures without disrupting established rail operations.

Standards and Specifications

IEC 61375 series overview

The IEC 61375 series establishes the standards for the Train Communication Network (TCN), a hierarchical system designed for open trains to enable among vehicles and subsystems. This series defines the overall , protocols, and interfaces necessary for reliable train-wide and intra-vehicle data exchange, supporting functions such as train control, monitoring, and diagnostics. Part 1 of the series outlines the general of the TCN, specifying it as a multi-bus that includes a backbone level for interconnecting consists across the and (consist) levels for internal communications within each . It covers key elements such as communication patterns, addressing schemes, data classification, and interoperability in dynamic configurations. Part 2-1 focuses on the Wire Train Bus (WTB) as the traditional , detailing specifications for cabling, connectors, transmission, and the protocol for process and message data exchange between vehicles. Part 2-3 defines the TCN communication profile, which aggregates rules for consistent consist-to-consist data exchange, including mapping of safety-related and non-safety data across the network. Part 3-1 provides comprehensive details on the Multifunction Vehicle Bus (MVB) for consist networks, specifying the (including cabling and transceivers), (with master-slave token-passing access), and conformance requirements for real-time device interconnections. For modern Ethernet-based extensions, Part 2-5 specifies the Ethernet Train Backbone (ETB), outlining requirements for full-duplex Ethernet switching to support high-bandwidth backbone communications while maintaining TCN compatibility. Similarly, Part 3-4 details the Ethernet Consist Network (ECN), defining Ethernet protocols adapted for intra-vehicle networks to handle diverse traffic types in rail environments. The overall scope of the IEC 61375 series extends to , diagnostic procedures, and application profiles tailored for rail-specific uses, ensuring robust performance, , and seamless integration in systems.

Evolution and updates

The IEC 61375 series has undergone several revisions since its initial establishment, with key updates reflecting advancements in rail communication technologies. The second edition of IEC 61375-1, published in , emphasized serial bus architectures such as the Wire Train Bus (WTB) and Multifunction Vehicle Bus (MVB) to ensure reliable data exchange in traditional train consists. This edition refined interface specifications for plug-in compatibility across vehicles, prioritizing deterministic performance for process control and safety-related data. Subsequent revisions in introduced greater flexibility by incorporating Ethernet-based options into the general , enabling higher bandwidth for and diagnostic applications while maintaining compatibility with legacy serial systems. The third edition of IEC 61375-1 outlined hierarchical structures that supported both serial and Ethernet topologies, facilitating the transition to IP-enabled networks for improved scalability in open trains. Building on this, IEC 61375-2-3:2015 defined the TCN communication profile, enhancing consist-level data exchange through standardized rules for Ethernet Train Backbone (ETB) and Ethernet Consist Network (ECN) integration, which improved between vehicle groups. Recent developments have addressed emerging challenges in rail operations. In 2021, IEC 61375-2-8 was published, providing procedures for TCN equipment and devices to ensure . More significantly, the draft for the fourth edition of IEC 61375-1 (as of 2025, still in preparation) introduces a dedicated clause on cybersecurity, integrating principles from for network , protection, and segmentation to mitigate risks in connected rail systems. This revision also refines ETB and ECN specifications with support and redundancy options, enhancing resilience without disrupting existing TCN deployments. Ongoing work includes IEC 61375-2-9 for Communications backbone and updates to Part 2-6 for video services. These evolutions are driven by the need for higher throughput in modern trains, where Ethernet replaces serial buses to support bandwidth-intensive applications like real-time video and . IoT integration has further necessitated updates, allowing seamless connectivity for onboard devices and tools. Compliance with initiatives like EULYNX ensures standardized interfaces for train-ground signaling, enabling efficient flow between onboard TCN and external systems. Looking ahead, the series is poised for full migration to IP-based protocols in ETB and ECN, as outlined in ongoing drafts, to accommodate future demands like advanced diagnostics and extensions while preserving with WTB and MVB for legacy fleets. This approach balances innovation with the reliability required for safety-critical rail operations.

Implementation and Usage

Applications in rail systems

Train Communication Networks (TCNs) serve as the backbone for critical onboard functions in rail systems, particularly in train control where they integrate with the (ETCS) to enable secure signaling and automatic train protection. This integration allows real-time data exchange between onboard subsystems and external signaling infrastructure, ensuring compliance with safety standards like those outlined in IEC 61375. Beyond control, TCNs manage environmental systems such as heating, ventilation, and air conditioning (HVAC) as well as lighting, optimizing energy use and comfort through centralized monitoring via the Train Control and (TCMS). information systems (PIS) also rely on TCNs to deliver dynamic announcements, route updates, and content across train consists, enhancing operational efficiency and user experience. TCNs are widely deployed in European networks, including services where the e320 fleet utilizes a TCN comprising the Wire Train Bus (WTB) for inter-vehicle connectivity and Multifunction Vehicle Bus (MVB) for intra-vehicle communications to support seamless cross-border operations. In urban metro environments, such as London's Underground, TCNs underpin train-internal communications in modern , enabling coordinated control across multi-car formations despite the predominance of (CBTC) for wayside interactions. TCNs integrate with external systems to extend their utility in urban rail, particularly linking to CBTC for precise train positioning and automated operation in dense networks, where onboard TCN gateways relay vital data to wayside equipment. For maintenance, TCNs connect to diagnostic tools that support predictive strategies by aggregating sensor data from components like brakes and traction systems, allowing remote analysis to forecast failures and minimize downtime. This connectivity, often via IP-based protocols in modern extensions, enables continuous health monitoring across the train fleet. In practical deployments, regional trains employ TCN for vehicle-level and train-wide control of doors, HVAC, and PIS, demonstrating TCN's role in scalable, interoperable designs for commuter services. Similarly, Alstom's Avelia high-speed trains support advanced diagnostics that reduce maintenance costs by up to 30% through predictive tele-monitoring of systems like propulsion and passenger amenities. These case studies highlight TCN's adaptability in diverse rail types, from regional to high-speed, ensuring reliable performance in operational environments.

Advantages and limitations

The Train Communication Network (TCN) offers several key advantages in operational rail environments, primarily stemming from its hierarchical and redundant design. One major strength is its high reliability, achieved through redundant topologies such as ring configurations and standby mechanisms, which ensure continued operation even in the event of component failures. Deterministic communication protocols, like those in the Multifunction Vehicle Bus (MVB), further support real-time control essential for safety-critical functions. Additionally, TCN reduces cabling complexity compared to traditional point-to-point wiring systems, leading to lower installation and costs by minimizing the physical required for transmission across train consists. This efficiency makes TCN superior to older wiring approaches in terms of scalability and reduced material needs. Future-proofing is another benefit, as TCN's architecture allows seamless integration with Ethernet-based upgrades, such as the Ethernet Consist Network (ECN) and Ethernet Train Backbone (ETB), enabling higher data rates from 100 Mbps to 1 Gbps to accommodate evolving applications like advanced diagnostics. These extensions maintain while addressing growing data demands without overhauling the entire system. Despite these strengths, TCN faces notable limitations in modern operational contexts. Configuration complexity arises particularly in gateway setups for integrating legacy and new components, as ring topologies increase the number of elements and demand precise to avoid disruptions. Legacy serial modes, such as the Wire Train Bus (WTB) at 1 Mbit/s and MVB at 1.5 Mbit/s, create bandwidth bottlenecks that hinder high-data applications like video surveillance or passenger services. Retrofit challenges in older fleets are significant, as integrating TCN into pre-existing systems often requires extensive modifications due to limitations in serial links. To mitigate these issues, modular upgrades such as MVB-to-ECN converters facilitate protocol translation and , allowing gradual transitions without full replacements. Redundant designs and quality-of-service features like VLANs also enhance . However, cybersecurity remains an ongoing concern, as legacy TCN components often lack robust , , or update mechanisms, exposing trains to threats in increasingly connected environments. While TCN outperforms point-to-point wiring in efficiency, it is challenged by emerging all-IP alternatives like (TSN), which provide superior and bandwidth for non-rail sectors and are being adapted to address TCN's gaps.

References

  1. https://www.dca.ufrn.br/~affonso/DCA_STR/trabalhos/rt-diversos/The%20IEC-IEEE%20train%20communication%20network.pdf
  2. https://ieeexplore.ieee.org/document/851393/
  3. http://www.tc9.cn/qbw/upload/file/20241202/1733102553939022326.pdf
  4. http://www.tc278.csrzic.com/qbw/upload/file/20240701/1719800567080069266.pdf
  5. https://www.eke-electronics.com/what-is-a-train-communication-network-tcn/
  6. https://www.researchgate.net/publication/3215181_The_IECEEE_train_communication_network
  7. https://ieeexplore.ieee.org/document/851393
  8. https://www.moxa.com/en/articles/tsn-rolling-towards-safer-train-networks
  9. https://www.eke-electronics.com/what-is-tcms/
  10. https://www.haslerrail.com/products-solutions/obe/train-backbone-communication/wtb-mvb-gateways/
  11. https://www.eke-electronics.com/train-communication-network-tcn-gateways/
  12. http://www.unicontrols.cz/eng/products/tcn/tcn.asp
  13. https://cdn.standards.iteh.ai/samples/17096/2e4a5fa498d347058defad47804d8ee2/IEC-61375-2-1-2012.pdf
  14. https://www.tme.eu/Document/63fdbf69fe082cb606f46e848b7d521d/UIC558EN.pdf
  15. https://link.springer.com/content/pdf/10.1007/978-3-031-82247-6_6
  16. https://users.ece.cmu.edu/~koopman/roses/tcn/tcnanalysis01.pdf
  17. https://ldra.com/documents/a-detailed-look-at-en-50126-en-50128-and-en-50129-automated-cost-effective-software-certification-from-basic-integrity-to-sil-4/
  18. https://www.mdpi.com/2076-3417/13/24/13128
  19. https://dl.ifip.org/db/conf/ifip12/ccta2010-4/LiYX10.pdf
  20. https://www.daube.ch/ddd/files/mvb_kit_c2.pdf
  21. https://cdn.standards.iteh.ai/samples/17097/5f27d9dba5294e9382c4a02460da8225/IEC-61375-3-1-2012.pdf
  22. http://wingtecher.com/themes/WingTecherResearch/assets/papers/fm16-safety-assured.pdf
  23. https://doi.org/10.1109/MCOM.001.1800957
  24. https://www.iso.org/standard/63648.html
  25. https://www.eke-electronics.com/train-control-and-management-system-tcms/
  26. https://us.profinet.com/how-does-profibus-dp-work/
  27. https://webstore.iec.ch/en/publication/5398
  28. https://iebmedia.com/tsn-in-the-railway-sector-why-what-and-how/
  29. https://iopscience.iop.org/article/10.1088/1742-6596/1828/1/012066/pdf
  30. https://patents.google.com/patent/EP3441278A1/fr
  31. https://www.eke-electronics.com/interface-modules/wire-train-bus-interface-module/
  32. https://www.researchgate.net/publication/349819973_Key_Technology_and_Open_Test_Method_of_Rail_Train_Field_bus
  33. https://www.bh-automation.com/Download/Resources/world-fip-protocol.pdf
  34. https://www.westermo.com/-/media/Files/Success-stories/westermo_ss_ethernet_train.pdf
  35. https://www.eke-electronics.com/what-is-a-gateway/
  36. https://webstore.iec.ch/en/publication/5405
  37. https://cdn.standards.iteh.ai/samples/16391/33079663d4e8444d9b39dd6c2d7689b0/IEC-61375-3-4-2014.pdf
  38. https://soc-e.com/wp-content/uploads/2024/11/RelyUm-tsn_trains-211108.pdf
  39. https://www.lantechcom.tw/global/eng/download/ePaper/Wh-IEC_61375_v1.2.pdf
  40. https://webstore.iec.ch/en/publication/5400
  41. http://www.tc9.cn/qbw/upload/file/20241018/1729219081125022111.pdf
  42. https://www.researchgate.net/publication/340365832_A_Study_on_the_Redundancy_of_Ethernet_Train_Backbone_Based_on_Dual-Link_Topology
  43. https://webstore.iec.ch/en/publication/5397
  44. https://standards.globalspec.com/std/1529862/iec-61375-2-1
  45. https://webstore.iec.ch/en/publication/22903
  46. https://webstore.iec.ch/en/publication/5402
  47. https://webstore.iec.ch/en/publication/26418
  48. https://webstore.iec.ch/en/publication/19722
  49. http://www.tc278.csrzic.com/qbw/upload/file/20240815/1723687828555010826.pdf
  50. https://webstore.iec.ch/publication/30351
  51. https://elib.dlr.de/129486/2/TCNpaper_PostPrint_elib.dlr.de.pdf
  52. https://pmc.ncbi.nlm.nih.gov/articles/PMC5492363/
  53. https://rail-research.europa.eu/wp-content/uploads/2025/08/D23.4-%25E2%2580%2593-Proposal-on-TSI202x-SS147.pdf
  54. https://standards.iteh.ai/catalog/standards/clc/679aa0a8-9d0c-4130-9cab-a0dc62dba26c/en-iec-61375-2-8-2021
  55. https://sellacontrols.com/train-control-and-management-system-tcms/
  56. https://assets.new.siemens.com/siemens/assets/api/uuid:fc722e25-fad5-4d52-9fc9-bfa0714d3acf/broschuere-velaro-e320-eurostar-en.pdf
  57. https://www.duagon.com/duagon-gateways/
  58. https://www.intertechrail.com/railway-communication-protocols
  59. https://iris.cnr.it/retrieve/a8d976fb-fde6-4d5a-b2bc-1415280dd091/TesiMillitari_versione1.pdf
  60. https://www.alstom.com/solutions/rolling-stock/avelia-high-speed-trains-best-way-travel-fast
  61. https://www.rail-suppliers.com/product/mvb-to-x-protocol-converters/
Add your contribution
Related Hubs
User Avatar
No comments yet.