Content
The Perfect Network Design in Trams – A Guide for Beginners and Advanced Users
Public transport operators (PTOs) pursue the same goal: to obtain live data from the vehicles in order to offer passengers the best possible comfort, safety and real-time information. At the same time, PTOs need data to efficiently implement daily fleet operations: How much capacity do we need and when? How effectively and passenger-friendly do our drivers steer the buses and streetcars? Do the measured passenger numbers match the tickets purchased?
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
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.
NodeIP addressVLAN MemberMADT10.13.201.1Management, journey data, video, Wi-Fi, ticketRouter10.13.201.2Management, journey data, video, Wi-Fi, ticketSwitch 110.13.201.3Management, journey data, video, Wi-Fi, ticketSwitch 210.13.201.4Management, journey data, video, Wi-Fi, ticketSwitch 310.13.201.5Management, journey data, video, Wi-Fi, ticketSwitch 410.13.201.6Management, journey data, video, Wi-Fi, ticketDestination sign 110.13.201.10Journey dataDestination sign 210.13.201.11Journey dataDestination sign 310.13.201.12Journey dataDestination sign 410.13.201.13Journey dataDestination sign 510.13.201.14Journey dataDestination sign 610.13.201.15Journey dataVideo recorder172.168.1.10VideoCamera 1172.168.1.12VideoCamera 2172.168.1.13VideoCamera 3172.168.1.14VideoCamera 4172.168.1.15VideoCamera 5172.168.1.16VideoVOIP intercom station 110.13.201.40Journey dataVOIP intercom station 210.13.201.41Journey dataVehicle Communication Gateway 110.13.201.42Journey dataVehicle Communication Gateway 210.13.201.42Journey dataTicket validator 110.10.201.10TicketTicket validator 210.10.201.11TicketTicket validator 310.10.201.12TicketTicket validator 410.10.201.13TicketTicket validator 510.10.201.14TicketTicket validator 610.10.201.15TicketTicket validator 710.10.201.16TicketTicket validator 810.10.201.17TicketPassenger counting system 110.13.201.60Journey dataPassenger counting system 210.13.201.61Journey dataPassenger counting system 310.13.201.62Journey dataPassenger counting system 410.13.201.63Journey dataPassenger counting system 510.13.201.64Journey dataPassenger counting system 610.13.201.65Journey dataPassenger counting system 710.13.201.66Journey dataPassenger counting system 810.13.201.67Journey dataPassenger Wi-fi172.168.2.10Wi-fiMaintenance access10.13.201.250Management, 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:
for troubleshooting
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.
