STATERA Library · Series 07 · Volume 08 · Chapter 05 · EN
Source: https://github.com/Statera-Library/07_Vol_08_Railway_and_Aerospace_Protocols/blob/main/Chapter_05_ETB/Chapter_05_ETB_EN.md

Volume 08. Railway and Aerospace Protocols

Chapter 05. ETB

05.01. IEC 61375-2-5 (ETB) Standard

IEC 61375-2-5 defines the Ethernet Train Backbone (ETB), an Ethernet-based backbone communication technology within the Train Communication Network (TCN) family. ETB extends railway networking toward higher bandwidth while preserving the operational requirements of train communication. It is intended to interconnect consist networks across an entire train and provide a standardized backbone for exchanging operational, diagnostic, control, and passenger-related information.

The ETB architecture reflects the physical organization of a train. A train may consist of several independently configured consists, such as locomotives, passenger cars, or multiple-unit sections. Each consist can operate an internal Ethernet Consist Network, while ETB provides communication between these consists. This separation allows local networks to remain manageable while enabling train-wide applications to exchange information through a common backbone.

A fundamental characteristic of ETB is its use of switched Ethernet technology adapted to railway conditions. Conventional Ethernet provides high throughput and mature networking mechanisms, but railway operation introduces requirements related to deterministic behavior, topology changes, environmental robustness, and predictable communication. IEC 61375-2-5 therefore specifies mechanisms that transform Ethernet from a general-purpose network into a train-oriented backbone capable of supporting operational communication.

Train composition is not necessarily permanent. Vehicles or consists may be coupled, uncoupled, reordered, or replaced during operation and maintenance. ETB must therefore support dynamic train topology rather than assuming a permanently configured Ethernet installation. After the physical train composition changes, the communication system needs to discover the resulting network structure, establish connectivity between participating consists, and provide applications with a consistent representation of the train.

An important architectural element is the Ethernet Train Backbone Node, commonly called an ETBN. An ETBN connects a consist-level network to the train backbone and participates in establishing train-wide connectivity. From an architectural viewpoint, it forms the boundary between communication inside an individual consist and communication across the complete train. This gateway-like separation also helps contain local network behavior and organize traffic according to train-level communication requirements.

ETB topology management is closely associated with train inauguration. Inauguration is the process through which the communication system determines the currently connected train configuration and establishes the logical relationships required for communication. This is essential because railway vehicles cannot always depend on manually configured addresses or fixed physical positions. The network must accommodate operational changes while maintaining a coherent view of nodes and services throughout the train.

The concept of direction is particularly important in railway networking. Applications may need to distinguish vehicles according to their position and orientation within the train rather than simply by an Ethernet address. ETB therefore operates within a train communication architecture where topology information has operational meaning. Communication can consequently be associated with train structure, supporting functions that depend on relative vehicle location, consist identity, or the current composition of the train.

ETB carries different categories of railway data over a shared Ethernet infrastructure. Operational process information may coexist with diagnostics, maintenance information, monitoring data, passenger information, and other services. Ethernet bandwidth makes this consolidation considerably more practical than on legacy fieldbus technologies. However, increased capacity does not remove the need for traffic engineering; critical cyclic traffic must remain predictable even when other applications generate substantial network load.

Quality of Service mechanisms are therefore important in practical ETB implementations. Traffic classification and prioritization can distinguish time-sensitive operational information from less urgent data transfers. Switch queues, priority handling, multicast management, and bandwidth planning must be engineered as part of the complete communication system. The objective is not merely maximum throughput, but controlled delivery behavior under both normal operation and demanding traffic conditions.

Redundancy is another major concern because a train backbone represents shared communication infrastructure for many distributed systems. Railway Ethernet designs can employ redundant paths, ports, links, or network elements so that a single communication failure does not unnecessarily isolate large sections of the train. Redundancy must nevertheless be combined with controlled recovery behavior, because rapid restoration and predictable topology convergence are more important than simply providing additional physical links.

ETB also provides an important foundation for higher-layer railway communication protocols. In the structure of this volume, the following sections distinguish the physical and backbone characteristics of 100/1000 Mbps train networking from TRDP communication operating over ETB. This layered approach is important: ETB establishes train-wide Ethernet connectivity, while higher communication layers define how process data and message-oriented information are exchanged between railway applications.

Compared with the earlier Wire Train Bus concept, ETB represents a major increase in available communication capacity and architectural flexibility. WTB was designed for train-wide communication under much tighter bandwidth constraints, whereas Ethernet enables richer sensor information, extensive diagnostics, software services, condition monitoring, and increasingly data-intensive train functions. The transition is therefore more than a speed upgrade; it reflects the evolution of railway vehicles toward distributed digital systems.

Despite its Ethernet foundation, ETB should not be treated as ordinary office or enterprise Ethernet installed inside a train. Railway communication equipment must operate under vibration, temperature variation, electromagnetic disturbance, power transients, long service lifetimes, and demanding availability expectations. Network design must consequently coordinate protocol behavior with rugged hardware, connector engineering, EMC design, power architecture, diagnostics, and railway equipment qualification.

Cybersecurity has also become increasingly relevant as Ethernet expands connectivity between train subsystems. Segmentation, controlled forwarding, service isolation, authenticated management, secure configuration, and monitoring can reduce the possibility that a compromised or malfunctioning subsystem affects the complete train network. The backbone architecture must therefore be considered together with security boundaries, gateways, maintenance interfaces, and any external communication paths connected to onboard systems.

Diagnostics are particularly valuable in ETB because the backbone itself becomes an observable distributed system. Link status, switch statistics, topology information, packet loss, interface errors, bandwidth utilization, redundancy state, and node availability can be monitored to identify degradation before it becomes a train-level failure. Effective diagnostic design connects these network indicators with vehicle identity and train topology so maintenance personnel can locate faults efficiently.

Time-related behavior also requires system-level consideration. Ethernet transmission is fast, but end-to-end application latency includes source processing, queueing, switching, protocol handling, destination processing, and scheduling effects. A high link rate alone therefore does not guarantee deterministic control communication. Railway engineers must evaluate latency, jitter, update periods, network loading, failure recovery, and worst-case behavior against the requirements of each distributed function.

IEC 61375-2-5 is consequently best understood as an architectural bridge between conventional Ethernet technology and the special operational structure of railway trains. ETB combines high-bandwidth switched networking with train topology awareness, consist interconnection, inauguration, redundancy, traffic management, and railway-oriented operation. Within the broader TCN architecture, it enables modern rolling stock to use Ethernet without abandoning the disciplined communication principles required by distributed railway systems.

05.02. 100/1000Mbps Train Backbone

The 100/1000 Mbps Train Backbone represents the high-speed physical communication foundation of the Ethernet Train Backbone (ETB) within the IEC 61375 railway networking architecture. It provides substantially greater bandwidth than traditional train buses and enables modern rolling stock to exchange operational data, diagnostics, passenger information, monitoring streams, and increasingly data-intensive information across multiple consists.

The two commonly considered Ethernet rates, 100 Mbps and 1000 Mbps, correspond to different capacity requirements within railway communication architectures. A 100 Mbps backbone can support many conventional control, diagnostic, and management functions, while a 1000 Mbps or Gigabit Ethernet backbone provides additional capacity for cameras, extensive condition monitoring, software distribution, logging, and other high-volume applications.

The choice between 100 Mbps and 1000 Mbps should not be interpreted simply as selecting the fastest available interface. Railway network engineering considers aggregate traffic, peak utilization, cyclic communication periods, redundancy overhead, multicast traffic, future expansion, and required latency margins. A properly engineered 100 Mbps network may provide sufficient performance for a defined system, while Gigabit Ethernet offers greater headroom for increasingly connected train functions.

A train backbone normally interconnects several consists, each of which can contain its own Ethernet Consist Network (ECN). Ethernet Train Backbone Nodes (ETBNs) provide the interface between these consist-level networks and the train-wide ETB. Traffic generated inside one consist can therefore remain local when appropriate, while information required by other consists is forwarded through the backbone according to the communication architecture and configured network policies.

Switched Ethernet is fundamental to achieving useful performance at both 100 Mbps and 1000 Mbps. Instead of forcing all devices to compete for a single shared transmission medium, Ethernet switches establish individual links and forward frames toward their intended destinations. This architecture increases available aggregate bandwidth, limits unnecessary traffic propagation, and enables traffic prioritization, segmentation, redundancy, and network monitoring mechanisms required in complex railway systems.

Full-duplex communication further distinguishes modern Ethernet backbones from many traditional shared buses. A full-duplex link can transmit and receive simultaneously without the collision behavior associated with historical shared Ethernet. This allows the nominal link capacity to be used more efficiently and makes communication behavior more predictable. For train networks carrying simultaneous control, diagnostic, and service traffic, this property is particularly important.

Physical transmission performance depends not only on the nominal bit rate but also on the selected medium, connectors, cable routing, shielding, link length, electromagnetic environment, and installation quality. Railway vehicles contain traction equipment, converters, motors, switching power electronics, and long harness routes that can create severe electromagnetic disturbances. Consequently, reliable 100/1000 Mbps operation requires communication hardware and cabling engineered for railway environmental conditions.

Gigabit operation places greater demands on signal integrity than lower-speed communication. Cable characteristics, connector quality, impedance control, termination, shielding, grounding, and installation practices become increasingly important as signaling rates rise. A network that appears correct from a logical Ethernet perspective can still experience packet errors or intermittent link failures if its physical implementation does not maintain adequate electrical performance under vibration, temperature variation, and electromagnetic interference.

Bandwidth planning should distinguish nominal link speed from usable application throughput. Ethernet framing, higher-layer protocols, multicast distribution, management traffic, retransmission behavior, and processing overhead consume part of the available capacity. Traffic can also arrive in bursts rather than at a uniform rate. Engineers therefore evaluate worst-case network utilization and traffic patterns instead of assuming that a 100 Mbps or 1000 Mbps interface continuously provides its entire nominal rate to applications.

Traffic prioritization becomes essential when operational and non-operational applications share the backbone. Time-sensitive process data should not be delayed unpredictably by large diagnostic transfers, passenger services, log collection, or software distribution. Quality of Service (QoS) mechanisms can classify traffic into different priority classes so that important railway information receives appropriate forwarding treatment even when the network experiences periods of high utilization.

Multicast communication is particularly relevant to train networks because the same information may need to reach multiple systems distributed across several vehicles. Efficient multicast forwarding can avoid unnecessary duplication of individual point-to-point transmissions. However, uncontrolled multicast traffic can consume backbone bandwidth and processing resources. Proper multicast management therefore contributes directly to predictable utilization and scalable train-wide communication.

Redundant network paths can improve backbone availability when links, connectors, switches, or individual network interfaces fail. The performance of redundancy mechanisms must be considered together with link speed because recovery behavior affects communication continuity independently of raw bandwidth. A Gigabit link with poor recovery characteristics cannot compensate for an architecture that loses connectivity for an unacceptable period following a single network fault.

Latency and jitter are also different from bandwidth. Increasing a link from 100 Mbps to 1000 Mbps reduces serialization time and can provide additional capacity, but end-to-end delay still includes switching, queueing, protocol processing, application scheduling, and endpoint processing. Deterministic railway communication therefore requires control of the complete communication path rather than relying solely on higher Ethernet transmission speed.

The high-speed backbone also supports the layered TCN architecture in which ETB provides train-wide Ethernet connectivity and protocols such as the Train Real-time Data Protocol (TRDP) provide application-oriented communication services. In the supplied volume structure, TRDP over ETB follows directly after the 100/1000 Mbps backbone topic, emphasizing the distinction between network transport capacity and the higher-level mechanisms used to exchange railway process and message data.

Diagnostics should be designed into the backbone from the beginning. Useful indicators include link state, negotiated link speed, packet and byte counters, error statistics, dropped frames, port utilization, topology status, redundancy state, and communication availability. Monitoring these parameters allows maintenance systems to distinguish application failures from physical link degradation, network congestion, switch faults, or configuration problems and supports condition-based maintenance.

Migration from legacy railway buses to high-speed Ethernet does not necessarily mean that all existing communication technologies disappear. Modern rolling stock may contain MVB, CAN, serial networks, proprietary buses, ECNs, and ETB simultaneously. Gateways can connect these domains while controlling data exchange between them. The 100/1000 Mbps backbone therefore functions as a high-capacity integration layer within a heterogeneous vehicle communication architecture.

The importance of Gigabit capability will continue to increase as trains incorporate more cameras, intelligent sensors, predictive maintenance, centralized logging, cybersecurity monitoring, remote diagnostics, and software-defined functions. Nevertheless, engineering discipline remains more important than raw speed. Capacity margins, deterministic behavior, redundancy, EMC robustness, diagnostics, cybersecurity, and maintainability must be designed together if higher bandwidth is to translate into greater system capability.

The 100/1000 Mbps Train Backbone can therefore be understood as the scalable data highway of a modern Ethernet-based train. Its purpose is not simply to replace a slower bus with a faster cable, but to provide sufficient capacity and architectural flexibility for distributed railway systems while maintaining predictable communication across changing train configurations. Properly engineered, it forms the communication foundation connecting consist networks, ETBNs, higher-layer protocols, and modern digital railway applications.

05.03. TRDP over ETB

TRDP, the Train Real-time Data Protocol, provides an application-oriented communication layer for exchanging railway data over Ethernet-based networks such as the Ethernet Train Backbone (ETB). Within the structure of the Train Communication Network, ETB provides train-wide Ethernet connectivity, while TRDP defines how distributed applications exchange operational process data and message-oriented information across that network.

This separation between network infrastructure and application communication is fundamental. ETB establishes physical and logical connectivity between consists through Ethernet Train Backbone Nodes, switches, and backbone links. TRDP operates above the IP transport mechanisms and gives railway applications a standardized communication interface, allowing software functions to exchange information without directly managing the underlying Ethernet topology.

TRDP communication is generally divided into Process Data and Message Data. Process Data, commonly abbreviated as PD, is intended primarily for cyclic or event-driven exchange of relatively compact operational information. Typical examples include vehicle states, commands, measurements, door information, traction status, braking information, temperatures, and other values that distributed train functions must update repeatedly during operation.

Process Data communication is based primarily on a publisher-subscriber model. A publisher generates a defined dataset and transmits it according to the required communication cycle or event condition. One or more subscribers receive the corresponding information without requiring a dedicated connection between every pair of applications. This model is particularly effective in trains because the same operational state frequently needs to be distributed to several systems simultaneously.

Multicast IP communication can complement the publisher-subscriber architecture by allowing one transmitted Process Data packet to reach multiple interested subscribers. This reduces unnecessary duplication compared with establishing separate transmissions for every destination. On a train containing many distributed controllers, gateways, diagnostic systems, and monitoring functions, controlled multicast can therefore improve communication efficiency and network scalability.

Message Data, usually abbreviated as MD, serves communication patterns that differ from continuous cyclic Process Data exchange. It supports message-oriented interactions in which an application needs to request information, obtain a response, or transfer data associated with a particular service. Diagnostic queries, configuration operations, maintenance functions, and other transactional exchanges are representative applications for this type of communication.

The distinction between PD and MD allows the network architecture to match communication behavior to application requirements. A rapidly changing operational value can be distributed efficiently as cyclic Process Data, while an occasional diagnostic request does not need to consume permanent cyclic bandwidth. This separation contributes to efficient utilization of the 100/1000 Mbps ETB infrastructure and simplifies the design of distributed railway software.

TRDP commonly uses UDP for time-sensitive Process Data because UDP introduces relatively low protocol overhead and does not require connection establishment or acknowledgement for every transmission. This is appropriate for periodically refreshed information where a newer dataset can supersede an older packet. Reliability is then achieved through application-level supervision, sequence monitoring, timeout detection, validity checks, and appropriate system reactions.

The absence of transport-level retransmission for cyclic Process Data is an important design consideration. In many real-time systems, retransmitting an outdated control value may be less useful than receiving the next current value at the expected cycle. Applications therefore supervise whether information arrives within the permitted time window. Missing or stale data can be detected and converted into a defined degraded or safe system response.

TRDP datasets provide a structured representation of information exchanged between applications. Both communicating endpoints must share a consistent understanding of the dataset layout, data types, identifiers, and semantics. Interface engineering is therefore as important as network configuration. Incorrect interpretation of a valid Ethernet packet can produce a functional error even when the switches, links, IP addresses, and transport protocols operate correctly.

Communication identifiers allow applications to associate received traffic with particular information flows. This abstraction is valuable in distributed train systems because applications should identify the meaning of communicated data rather than depend exclusively on physical port positions or individual network devices. Consistent communication definitions consequently become part of the system interface specification and configuration-management process.

Operating TRDP over ETB also requires consideration of train topology. ETB may connect multiple consists whose physical composition can change when vehicles are coupled, uncoupled, replaced, or reordered. The underlying TCN architecture manages train-wide connectivity and topology information, while TRDP applications exchange data across the resulting logical network. Application design must therefore avoid unnecessary assumptions about permanently fixed train composition.

Quality of Service remains relevant because TRDP traffic shares ETB capacity with diagnostics, passenger services, monitoring, logging, software distribution, and other Ethernet applications. Important cyclic Process Data should receive suitable forwarding priority so that large background transfers do not create unacceptable latency or jitter. TRDP performance must consequently be evaluated together with Ethernet switching, queue configuration, traffic classification, and backbone utilization.

End-to-end timing is determined by more than the TRDP protocol itself. The complete delay includes publisher scheduling, dataset preparation, protocol processing, Ethernet transmission, switch forwarding, queueing, subscriber reception, and application scheduling. Engineers therefore define cycle times, timeout values, latency limits, jitter margins, and supervision behavior according to the requirements of the distributed railway function rather than relying only on nominal Ethernet speed.

Network redundancy at the ETB level complements TRDP communication availability. If a physical link or switching path fails, the backbone may provide an alternative communication path, while applications continue supervising the arrival and validity of their TRDP information. This illustrates the layered nature of railway communication reliability: physical redundancy, network recovery, protocol supervision, and application-level fault handling contribute together to overall availability.

Diagnostics should observe both the Ethernet infrastructure and the TRDP communication layer. Link state and switch counters can reveal physical or network problems, while TRDP-level monitoring can identify missing publishers, invalid datasets, sequence anomalies, timeout conditions, unexpected communication identifiers, or abnormal update rates. Combining these observations helps engineers determine whether a failure originates in hardware, networking, configuration, or application software.

Cybersecurity must also be considered because TRDP operates on standard Ethernet and IP technologies that can connect increasingly complex onboard systems. Network segmentation, controlled multicast forwarding, access restrictions, secure management, gateway filtering, and monitoring can limit unintended communication paths. Security measures must be designed carefully so that protection mechanisms do not introduce unpredictable delays into time-sensitive operational traffic.

TRDP over ETB therefore forms a practical bridge between high-bandwidth Ethernet infrastructure and distributed railway applications. ETB supplies scalable 100/1000 Mbps train-wide connectivity, while TRDP organizes the exchange of cyclic Process Data and service-oriented Message Data. Together they allow modern trains to integrate control, diagnostics, monitoring, and digital services within a structured Ethernet-based Train Communication Network while retaining the predictability required for railway operation.

05.04. ETB to UAV Fleet Analogy

The Ethernet Train Backbone (ETB) provides a useful architectural analogy for understanding communication within a coordinated UAV fleet. In a train, ETB connects multiple consists through a common high-speed backbone while preserving local communication inside each consist. A UAV fleet can be viewed similarly: each aircraft operates as an autonomous local system while participating in a larger communication structure that coordinates the fleet as a whole.

In this analogy, an individual UAV resembles a railway consist. A consist contains controllers, sensors, actuators, diagnostics, and local communication networks, while a UAV contains flight controllers, navigation sensors, payload computers, propulsion controllers, cameras, and mission systems. Both must continue performing essential local functions even when communication with the wider train or fleet is temporarily degraded or unavailable.

The Ethernet Consist Network (ECN) can therefore be compared with the onboard network of a UAV. Inside the aircraft, Ethernet, CAN, serial buses, or other interfaces connect avionics and payload equipment. These local networks handle high-rate sensor exchange and deterministic control functions that should not depend continuously on fleet communication. The fleet network should carry only information that must be shared between aircraft or with supervisory systems.

An Ethernet Train Backbone Node (ETBN) provides a conceptual counterpart to a UAV fleet communication gateway. In ETB, the ETBN connects the local consist network to the train-wide backbone. A UAV can similarly contain a gateway that separates onboard communication from fleet communication and manages routing, addressing, security, traffic classification, and protocol conversion between local avionics networks and external wireless communication links.

The physical communication medium represents one of the major differences between the two systems. ETB normally relies on wired Ethernet links between physically connected railway consists, whereas UAVs communicate through wireless technologies such as radio, Wi-Fi, cellular networks, mesh links, or specialized aviation datalinks. The analogy therefore applies primarily to logical architecture, topology management, traffic organization, and distributed coordination rather than to the physical transmission layer itself.

Dynamic train composition has a particularly useful parallel in fleet operation. Railway consists can be coupled, uncoupled, reordered, or replaced, requiring the train network to recognize its current topology. UAVs can similarly join a mission, leave because of low battery or failure, return after recovery, or be reassigned to another formation. Fleet communication must therefore maintain an updated representation of participating vehicles and their operational relationships.

Train inauguration can consequently be interpreted as an analogy for UAV fleet discovery and formation establishment. When a train composition changes, the communication architecture determines which consists are present and how they are logically organized. In a UAV fleet, an equivalent process could discover available aircraft, verify their identities and capabilities, assign fleet roles, establish communication paths, and distribute mission configuration before coordinated operation begins.

The publisher-subscriber communication model used by railway protocols over ETB also maps naturally to fleet information exchange. A UAV can publish position, velocity, heading, battery state, health, detected objects, or mission status, while other aircraft and supervisory nodes subscribe to information relevant to their tasks. This avoids requiring every vehicle to maintain a dedicated application-level connection with every other member of the fleet.

Process Data concepts are especially applicable to frequently updated fleet states. Position, velocity, formation error, health status, navigation state, and mission progress can be transmitted periodically or when significant changes occur. The newest information is normally more valuable than retransmission of an obsolete state. This resembles real-time railway communication in which cyclic operational data is continuously refreshed and supervised using update periods and timeout mechanisms.

Message-oriented communication provides a complementary mechanism for less frequent fleet interactions. A mission controller may request detailed diagnostic information, assign a new waypoint, change a payload configuration, command a vehicle to return, or retrieve stored mission data. Separating these transactions from continuously distributed state information allows communication resources to be allocated according to the temporal characteristics and importance of each information flow.

Traffic prioritization becomes even more important in a wireless fleet because available bandwidth can vary with distance, interference, terrain, antenna orientation, and network congestion. Flight-critical coordination, collision avoidance, emergency state, and command information should receive greater priority than bulk sensor uploads or maintenance logs. The ETB principle of separating operational traffic from lower-priority services therefore provides a useful reference for UAV fleet communication design.

Redundancy also has a strong conceptual correspondence. Railway backbones can employ redundant links or network paths so that communication continues after a failure. UAV fleets may obtain redundancy through multiple radios, alternative frequency bands, cellular and direct links, mesh routing, relay aircraft, or ground-station paths. The implementation differs, but the architectural objective remains similar: avoid allowing one communication failure to isolate critical parts of the distributed system.

A mesh-connected UAV fleet extends this idea beyond the predominantly structured topology of a train. Aircraft may forward information for other aircraft and dynamically establish alternative paths as relative positions change. Consequently, a fleet communication graph can change much more rapidly than an ETB topology. Routing, link-quality estimation, membership management, and communication recovery must therefore operate under mobility conditions that are significantly more dynamic than those of railway consists.

Diagnostics can also follow the layered philosophy used in railway Ethernet. Each UAV can monitor onboard interfaces, external link quality, packet loss, latency, available bandwidth, routing state, synchronization, and gateway health. A fleet supervisor can combine these observations to determine whether communication degradation originates from an individual aircraft, a wireless link, a relay path, network congestion, or a ground infrastructure problem.

Cybersecurity becomes critical because the UAV fleet backbone is exposed to a substantially less controlled physical environment than a wired train network. Vehicle authentication, encrypted communication, secure key management, access control, message integrity, network segmentation, and protection against unauthorized commands become essential. The ETB gateway concept remains useful, but a UAV fleet gateway requires stronger consideration of untrusted and potentially contested communication channels.

Time synchronization provides another important connection between railway and fleet architectures. Distributed applications often require consistent timestamps to correlate measurements and coordinate actions. UAV fleets additionally depend on accurate timing for navigation, sensor fusion, formation control, cooperative perception, and event reconstruction. Communication architecture must therefore distribute or maintain sufficiently consistent time references while accounting for variable wireless latency and temporary connectivity loss.

The analogy also highlights the importance of local autonomy. A railway consist should not lose every essential function merely because backbone communication is interrupted, and a UAV must not depend on continuous fleet connectivity to remain controllable. Flight stabilization, basic navigation, safety monitoring, and emergency behavior should remain onboard. Fleet communication should enhance coordination and collective intelligence rather than become an unnecessary single point of operational dependence.

At a higher architectural level, ETB suggests a scalable way to separate local intelligence from collective communication. Each UAV can maintain its own sensing, control, navigation, and safety loops while exchanging selected state and mission information through a fleet backbone. A ground station, edge computer, or fleet coordinator can then operate as a supervisory node without requiring all low-level sensor and actuator traffic to traverse the shared communication network.

The ETB-to-UAV fleet analogy should therefore be used as an architectural reference rather than as a direct protocol replacement. IEC 61375 ETB was developed for physically connected railway consists, while UAV fleets operate over mobile and uncertain wireless channels. Nevertheless, its principles of local network separation, backbone gateways, dynamic membership, structured data exchange, traffic prioritization, redundancy, diagnostics, and distributed supervision provide a valuable framework for designing scalable multi-UAV communication systems.