Typical application examples:

1. During rush hours of commuter traffic, capacity is increased by 2 car sections. During off-peak hours, the car sections are again separated into two individual train units to serve secondary routes.
2. In order to better handle large passenger volumes due to events on weekends (concerts, sports events), several carriages will be coupled together to form a larger train unit (5-car composition). On weekdays, more trains are again needed on other lines (2-unit and 3-unit composition).

Implementation of Network Infrastructure for Dynamic Coupling of Trams

Static IP addressing

From the network architecture point of view, there are several approaches to solve dynamic coupling and decoupling. For a few vehicles and a manageable number of IP components in the entire fleet, static assignment of IP addresses for all participants is possible. Depending on the number of IP components, the subnet must be defined accordingly. For example, with fewer than 254 IP subscribers, the subnet mask could look like this: 255.255.255.0

However, the configuration effort increases with the number of IP components. Each participant must be assigned a static IP address. Automating IP addressing can quickly become confusing and complicated when there are several thousand participants.

Encapsulation of wagons

Another solution approach based on VDV document 301-2-14 is to set up two subnets:

1. train-wide IP network
2. intra-wagon IP network

The train-wide IP network is used for communication across the train composition and the internal wagon IP network for communication within the wagon sections. By having two different subnets, the individual wagon parts can use identical IP addresses without causing an IP address conflict. For the workshop, this results in significant advantages during installation and maintenance.

Each component has the same IP address, regardless of which wagon it is located in. Another advantage is the number of IP addresses that can be managed. These are limited to the number of train sections and not to the number of IP components. This makes it easy to manage larger fleets.

You can read exactly how this works technically in our use case here: