The Perfect Network Design in Trams – A Guide for Beginners and Advanced Users

Publich transport operators then quickly discover that they need to install new, intelligent components such as video surveillance, passenger counting systems and passenger information systems in the vehicles. All in order to improve quality and efficiency. But then the next question arises: How do we communicate with the individual components and where do we even connect them? At this point, at the latest, it becomes clear that we need a network infrastructure. What does this look like in buses and trams/streetcars? What does it depend on? We are providing you with a guideline on this subject.

Network Design for Trams – Planning is Half the Job

Benjamin Franklin already recognized that planning is an essential success factor in any project. His famous quote “If you fail to plan, you are planning to fail” sums it up. A network design as well as the underlying communication plan set the course for a successful implementation of the network infrastructure in public transport vehicles.

As a rule, network planning in public transport goes through four phases:

Concept: the first step of network planning is to develop the optimal network infrastructure, the feasibility of which needs to be verified and proven.

Pilot: The pilot phase represents a practical test under real operational conditions, the goal of which is to prove the finished network concept in regular operation.

Rollout: The network concept successfully tested in the pilot phase is now rolled out to the entire fleet. The rollout takes place within a fixed time frame.

Operation: This involves developing a concept for how the network can be expanded, modified or maintained remotely.

Checklist: Basic Questions about Network Design

To design the optimal network for trams, start by answering these basic questions:

• Which and how many components do we have in the vehicle?
• Which devices should communicate with each other?
• Which devices should not communicate with each other?
• Which network topology should we consider?
• Which IP address ranges do we want to use?
• Which IP addresses should we use in the vehicle, should they always be the same?
• How should the IP addresses be assigned?
• Which network settings do we need for our project?
• Do we need live diagnostics? If so, in what form?

 

Particularities of Trams

Standards

The use of electronic devices in rail vehicles is subject to internationally recognized standards, among others. EN 50155 describes the electrical as well as the environmental conditions for operation, EN 50121 defines the requirements regarding EMC, EN 45545 the fire protection requirements in rail vehicles. In addition, EN 50155 defines the scope for type testing and routine testing in production. A declaration of conformity by the manufacturer and a technical test report from an accredited laboratory certify compliance with the standard requirements. ROQSTAR Gigabit Switches meet all requirements for installation in rail vehicles.

Size and number of components

Depending on the length and expansion stage of the streetcar, up to 100 IP subscribers are installed in trams. Significantly more than in buses. To future-proof data transmission across the entire tram, it makes sense to use Gigabit Ethernet as a data highway. In this case, connections between switches have 1000 Mbit/s transmission speeds.

Fail-safety and topology selection

A ring topology ensures increased network availability. This means that even if errors such as cable breakage or component failure occur, the function of the network is still maintained.

Coupling transmission and dynamic coupling

Streetcars usually consist of several carriages that can be coupled together at will. This requires that the network is designed in such a way that there is no conflict of IP addresses.

Two-directional vehicles

Trams are often built as bidirectional vehicles to make it easy to change the direction of travel at terminus stations. From the point of view of the network infrastructure, this affects the number of components (driver’s cab A+B) as well as the settings in the network.

Components in the IP network

Typically, all or nearly all existing devices in the vehicle are connected into a network. In this example, we equip a tra with all devices necessary for efficient operation and an optimal passenger experience. This includes interior and exterior displays, ticketing systems, passenger counting systems, digital cameras or recorders, and passenger WLAN. The network design also takes into account the on-board computer, which plays a central role in network control, and the router, which establishes the network connection between the vehicle and the control center.

All components are individually addressable within the network via their own IP addresses and can be accessed via remote control.

The onboard devices to be installed in our example are listed below:

• Board computer x1
• Driver control unit x2
• Ticket validator x8
• Passenger counting system x8
• VOIP intercom station x2
• Camera x5
• Video recorder x1
• Travel indicator x6
• Passenger information system x8
• Passenger WLAN x2
• Router x1
• Managed Fast Ethernet Switch x4

Only at the end we choose the type of switches we will use to build our network. Since our network is complex and requires control capabilities, we choose managed switches. How many switches are needed and how many ports per switch depends on the number of peripherals. It’s important to leave at least one port per switch free for maintenance access to the entire network, as well as for future network expansion.

Topology of the IP Network of a Tram

In practice, the ring topology dominates in trams. Here, the switches are first connected to each other in a line, and then the first switch is connected to the last switch. This creates a ring. The ring topology has the advantage that if the cabling or the switches themselves fail, the network is maintained. Except for the failed component, the network is fully functional. The disadvantage is that extra installation space is required for the Ethernet cabling. A ring structure requires the use of managed switches.

Installation space can be a problem, especially when retrofitting trams. If the installation space for a second Ethernet line is not available, a line topology is implemented. To increase reliability, devices with a bypass relay are used. This function only plays a role in the event of a switch failure. If a switch fails, the relay is switched and the network data is forwarded to the next switch.

Creating a Network Plan for a Tram

Communication within the network can be controlled by using managed switches. This can prevent sensitive data from reaching network participants who do not need or should not receive it. A network plan defines which components in the streetcar should communicate with each other and which not.

Data flows are separated by logical subnetworks, which are implemented by the managed switches. A good example that requires data separation by subnetworks is represented by the passenger WLAN. To ensure data privacy, it should not receive data from payment systems or cameras.

Network Separation for Public Transport Vehicles

The network plan is in place – now we move on to creating an infrastructure for the subnetworks. It will be implemented by virtual LANs (VLANs), which are to be mapped visually in the plan.

As can be seen in the figure, cameras and videorecorders exchange data with each other, but only within their virtual video network. Only critical IP components such as on-board computers, routers and switches can access all VLANs.

Since not all devices in a network are usually VLAN-capable, network separation is (partly) implemented by the managed switches. In this process, each switch port is assigned a specific VLAN. The subscriber connected to it is only able to communicate within this VLAN.

At this point, we would like to mention another possibility for solving the problem of network or data separation. Some onboard routers are capable of managing both communication with the control center and the passenger WLAN. This eliminates the need to separate at least the passenger WLAN subnetwork.

Finally, we assign each network node an individual IP address so that it can be located within the network.

Node	IP address	VLAN Member
MADT	10.13.201.1	Management, journey data, video, Wi-Fi, ticket
Router	10.13.201.2	Management, journey data, video, Wi-Fi, ticket
Switch 1	10.13.201.3	Management, journey data, video, Wi-Fi, ticket
Switch 2	10.13.201.4	Management, journey data, video, Wi-Fi, ticket
Switch 3	10.13.201.5	Management, journey data, video, Wi-Fi, ticket
Switch 4	10.13.201.6	Management, journey data, video, Wi-Fi, ticket
Destination sign 1	10.13.201.10	Journey data
Destination sign 2	10.13.201.11	Journey data
Destination sign 3	10.13.201.12	Journey data
Destination sign 4	10.13.201.13	Journey data
Destination sign 5	10.13.201.14	Journey data
Destination sign 6	10.13.201.15	Journey data
Video recorder	172.168.1.10	Video
Camera 1	172.168.1.12	Video
Camera 2	172.168.1.13	Video
Camera 3	172.168.1.14	Video
Camera 4	172.168.1.15	Video
Camera 5	172.168.1.16	Video
VOIP intercom station 1	10.13.201.40	Journey data
VOIP intercom station 2	10.13.201.41	Journey data
Vehicle Communication Gateway 1	10.13.201.42	Journey data
Vehicle Communication Gateway 2	10.13.201.42	Journey data
Ticket validator 1	10.10.201.10	Ticket
Ticket validator 2	10.10.201.11	Ticket
Ticket validator 3	10.10.201.12	Ticket
Ticket validator 4	10.10.201.13	Ticket
Ticket validator 5	10.10.201.14	Ticket
Ticket validator 6	10.10.201.15	Ticket
Ticket validator 7	10.10.201.16	Ticket
Ticket validator 8	10.10.201.17	Ticket
Passenger counting system 1	10.13.201.60	Journey data
Passenger counting system 2	10.13.201.61	Journey data
Passenger counting system 3	10.13.201.62	Journey data
Passenger counting system 4	10.13.201.63	Journey data
Passenger counting system 5	10.13.201.64	Journey data
Passenger counting system 6	10.13.201.65	Journey data
Passenger counting system 7	10.13.201.66	Journey data
Passenger counting system 8	10.13.201.67	Journey data
Passenger Wi-fi	172.168.2.10	Wi-fi
Maintenance access	10.13.201.250	Management, journey data, video, Wi-Fi, ticket

 

Diagnosis/Monitoring of an IP Network in Public Transport

To ensure the faultless functioning of the digital IP network on board our trams, we provide permanent network monitoring. Sometimes the on-board computer can take over this task. However, diagnostics by means of a managed Ethernet switch proves to be more effective, since switches have a physical connection to each individual node in the network.

Permanent network monitoring is particularly useful in the following cases:

1. for troubleshooting
2. monitoring of ongoing operation.

With the help of special protocols, managed switches can provide information about the network status:

• ITxPT Inventory Service x-status: This is functionally relevant monitoring that is event-based. In case of a critical event, a message is sent to all nodes via DNS. The router forwards the fault message directly to the control center. Through the ITxPT Inventory Service x-status, transport companies maintain an overview of the entire vehicle fleet.
• Remote logging: All events logged by the switch are sent to a remote server in the control center. Remote logging enables comprehensive monitoring and initial diagnostics.
• SNMP Trap: Error messages can be sent using the “Simple Network Management Protocol”.

Please inform yourself in advance which of these protocols the Ethernet switch of your choice supports.