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.
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|
|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|
|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:
- 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.
Subscribe to our monthly newsletter and stay tuned
Thanks for subscribing! We will be happy to keep you up to date, but first you need to confirm your email!
More Stories Like This:
The Right Decision: How Do You Know It’s Time to Switch to IP Communication in Public Transport?
Replacing analog technology in buses and trains with IP networks? This is a question that is currently occupying the minds of many public transport operators. We explain when is the best time to make the switch and what requirements must be met on...
Two Ways to Refit Vehicles in Public Transport
With increasing data volume and requirements for real-time data in public transport vehicles, IP-based communication has become a basic requirement for modern IT system architecture in vehicles. We use two examples to show how transport operators...
Practical Tips for Secure Networks on Buses and Trains
...Concepts and Levels of Security IT security in public transport must be understood as a holistic and overarching task. For example, the industry standard IEC 62443 describes the consideration of cyber security concepts from different points of...
Our products are fundamental for the digitalization in public transport. ROQSTAR M12 Ethernet Switches provide the network infrastructure for e-ticketing, passenger counting systems (PCS), dynamic passenger information (DPI) and closed-circuit television (CCTV).