a new approach for Train Passenger Information Systems
D. Russo, A. Gatti, A. Ghelardini, G. Mancini, Trenitalia S.p.A., Firenze, Italy
A. Verduci, TSF S.p.A., Bologna, Italy – D. Amato, R. Battani Sadel S.p.A., Bologna, Italy
This paper was presented to the
Abstract
Standard train communication between different railway vehicles usually works on Wire Train Bus (WTB), with physical layer commonly on line 17-18 (TCN) or 7-8 (TCN* used by Trenitalia on older 13 poles train bus) of UIC cable.
Devices transmitting information on TCN or TCN* lines can be divided in two different categories: “critical systems” (driver desk, motor control, brakes, track signals, power electronics,), mainly used for command and control systems and “non critical systems” (passenger audio, passenger video, vehicle diagnostics) that usually have no real-time requirements.
In this paper we consider an alternative approach dividing “critical devices” and “non critical devices” and defining a new physical and communication layer for “non critical devices”.
In this alternative approach, the physical layer is deployed either on coaxial cables (commonly used for passenger audio on trainset) or UIC cable (on other trains). In the last case communication lines are placed on already used wires, like line 1 and 2, used for voice and general audio information to passengers, or line 10 and 11, used as remote control of train lights.
The transport of information on these lines is performed with a power line communication module (PLC). Each PLC provides an interface with a band-pass filter to avoid interference with existing audio and light systems. The main parameters of PLC communications are the transmission bandwidth (normally expressed in ranges of kHz or MHz) and theoretical bits per second rate (bps) reached during the communication.
This network architecture can be used both at train or vehicle level, providing two separated layers like the architecture adopted for WTB and MVB communication. In this system a PLCNODE is defined as the transceiver allowing bridging from train to vehicle networks and viceversa.
This architecture is currently under test on some Italian commuter trains, equipped with an “OBoE” system which broadcast updated journey information to “DOVE6” video devices connected with a PLC based network.
Introduction
In the last years all the Train Operator Companies put a big effort to increase passenger satisfaction providing audio and video information about travel (train position, estimated arrival time, next stop announcements and connections).
The so called Passenger Information System (PIS) implements these services as following described:
- Broadcasting audio information to all passengers.
- Managing external displays with information about train code, journey code and departing and arriving station for passengers standing on the platform.
- Managing internal displays with runtime journey information.
- Providing diagnostic data of the device belonging to the PIS
- Implementing a smart policy of power management, to avoid excessive current drainfrom train batteries by non-critical systems in case of lack of connection with the electrical supply line.
1 Train Network Analysis
The train communication between locomotive, coaches and driving trailer for most of the international European trains (Intercity and Eurocity) and Italian trains (commuter trains) is defined in fiche UIC568 [1] and fiche UIC558 [2]. Older UIC cable configuration (13 poles) was designed to support voice and music broadcasting in the passenger coaches, voice communications between train staff and driver on the locomotive and lights and doors commands and controls.
Actual UIC configuration cable with TCN (18 poles, see Table 1) is designed to meet the physical requirements for TCN communication layer, as specified in the IEC standard for Wire Train Bus (WTB) [3 ], also maintaining wires for functions and commands already supported by the previous 13 poles cables.
The WTB with TCN communication shall guarantee the functionality of remote traction control, permitting to handle push-pull trains. Other critical commands and status information (brakes, track signals, power electronics, radio) are transmitted by WTB bus which has to guarantee time-critical and reliability constrains.
For 18 poles cable the train communication network is achieved with a dedicated shielded twisted pair cable (wires 17,18,S) and it reaches a data rate of 1 Mbps. In Trenitalia application with older UIC 13 poles configuration cable, the train communication network is achieved on wire 7 (X*) and 8 (Y*) using the standard pair conductors. This communication is called TCN* and its maximum speed is 500 kbps, half of the TCN communication speed.
Pair of | wires | Function | Signal | Group |
1 | 2 | Audio towards train loudspeaker | 2 Veff (100-8000 Hz) | 1 |
3 | 4 | Voice communication towards: | 1.6 Veff (100-5000 Hz) | 1 |
3 (-) | 4 (+) | – the driver | 18-33 Vdc (permanent) | |
3 (+) | 4 (-) | – the switchboard | 18-33 Vdc (permanent) | |
5 (+) | 6 (-) | Switch on loudspeaker amplifiers | 18-33 Vdc (permanent) | 2 |
7 (+) 7 (X*) | 8 (-) 7 (Y*) | Priority of announcement command TCN* Communication | 18-33 Vdc (permanent) 6-9 Vpp (500 kpbs) | 2 |
9 (+) | 12 (-) | Remote command of door closing | 15-33 Vdc (pulse < 2 sec) | 3 |
10 (+) | 12 (-) | Remote command: light on | 15-33 Vdc (pulse < 2 sec) | 3 |
11 (+) | 12 (-) | Remote command: light off | 15-33 Vdc (pulse < 2 sec) | 3 |
14 (+) | 12 (-) | Unlock right doors command | 15-33 Vdc (pulse < 2 sec) | 4 |
15 (+) | 12 (-) | Unlock left doors command | 15-33 Vdc (pulse < 2 sec) | 4 |
16 (+) | 12 (-) | Remote condition control of door locked | Vdc level (permanent) | 4 |
17 (X) | 18 (Y) | TCN Communication | 6-9 Vpp (1 Mpbs) | |
S | Shield of wires 17-18 | – | – | |
13 | Common shield for all wires | – | – |
ETR500 fleet of High Speed Italian trains doesn’t use a standard cable, but it uses two custom train communication subsystems (Figure 1):
- Audio di bordo (AB): the passenger audio communication uses two RG213 coaxial cables starting from locomotive A and ending at locomotive B, passing on each coach. In each vehicle the audio amplifier is connected with an input and an output N connector. The features of RG213 cables allows bandwidth of hundreds of MHz with the train cable length of about 400 meters.
- Sistema informativo di bordo (SIB): the command and control onboard system uses two loops of a twisted pair cable. The serial communication over this cable can reach speeds up to 1Mbps.
2 Information Analysis
In most of the trains a single communication network (TCN or TCN*) is usually installed, sometimes with two communication levels (WTB at train level and MVB at vehicle level). The information of each device (air-conditioning status, brake commands, odometer readings, toilet status etc..) are addressed on the same bus along the entire train or a single vehicle. If we analyze the equipments related to these data we can find out two main categories. The first ones are “critical systems” (driver desk, motor control, brakes, track signals, power electronics), mainly used for train commands and controls with critical and hard real-time requirements. The second ones are “non-critical systems” (audio and video passenger information, vehicle diagnostics) that usually have soft or no real-time requirements. For these devices the exchanged information could be very different: from a video image of hundreds of kilobytes sent once an hour to a GPS position sent every second. We can classify non critical systems data through these features, strictly depending on the application:
- Dimension
- Delivery reliability level (low, medium, high level)
- Transfer frequency (timings)
Data | Delivery Reliability Level | Dimension | Transfer frequency |
GPS Position (date and time synchronization) | MEDIUM | < 50 Bytes | timer driven: every second |
Programmed train track | HIGH | ~ 5 kBytes | event driven / timer driven |
Track events | MEDIUM | < 50 Bytes | event driven |
Information about connections | MEDIUM | ~ 5 kBytes | event driven / timer driven |
General purpose notifications for passengers | MEDIUM | < 500 Bytes | event driven |
Compressed audio files for streaming or on-demand audio | LOW | > 3 MB | event driven |
Compressed video files for movies and advertisements | LOW | > 30 MB | event driven |
PIS diagnostic data | LOW | ~ 5 kBytes | event driven |
Other management data (reservation and payment, luggage management etc..) | HIGH | > 500 kB | event driven |
The dimension of these data can vary from 10 bytes, for keep-alive frames or alarms, to some Megabytes (MB), for working logs and records, depending on the required level of detail (see Table 2).
3 PLC Technology
Power Line Communication (PLC) technology uses standard coaxial cables or power supply cables to allow the communication between different devices. This technology is nowadays largely used in home, building and industry automation, because it avoids the installation of additional network cables. The PLC device provides an interface with a band-pass filter to avoid interference with power supply signal. In the train, also different existing cables (i.e. audio or light control) can be used instead of the power supply cable . The PLC modules can be divided in two main categories:
- Low Speed PLC (PLC-LS)
- High Speed PLC (PLC-HS)
The PLC-LS modules offer a nominal speed of few kilobytes per second and normally could be connected in a simple way to a cost-effective electronic equipment. The standard interface is a simple serial communication (RS232, RS485, RS422, TTL) to send and receive information from the computing device. The reachable distance is hundreds of meters and sometimes some kilometres but it obviously depends on the quality of the cable. The carrier frequency is usually around hundreds of kHz.
The PLC-HS modules offer a nominal speed from few Mb to hundreds of Mb per second and must be connected to a more complex electronic equipment with an Ethernet port/MII physical interface. The frequency band used by these devices reaches tens of MHz. For this reason PLC-HS communication works fine only if the physical layer of communication provides a larger bandwidth. Block diagram of PLC -LS and PLC-HS modules are shown in Figure 2 while Table 3 summarises the main features of a possible solution.
PLC-LS | PLC-HS | |
Transceiver | PL3120 (Echelon) | INT5500CS (Intellon) |
Maximum PHY bit rate | 5.4 kbps | 85 Mbps |
Communication technique | Dual Frequency BPSK | OFDM |
Communication frequency | 132 kHz (primary) | 4,5-21 MHz |
132 kHz (secondary) | ||
Maximum output voltage | 7 Vpp | 10 Vpp |
Interface | Serial (SCI and SPI) | MII / Ethernet |
Communication Standard | LonTalk [4] | HomePlug 1.0 [5] |
Channel access | Predictive p-persistent | CSMA/CA |
CSMA |
The following Figure shows the covering of the standard ISO-OSI protocol layers required for the above-mentioned technologies.
4 Proposed Solution
For non-critical information it is possible to use the cables already installed on the train to allow simultaneous communication with PLC-LS and PLC-HS technology.
If we consider the 18 poles UIC cable, we can choose line 1 and line 2. In this situation, on this couple of wires the following information are addressed:
- Analog audio communication for coach amplifier.
- PLC-LS for devices diagnostic and low-speed communication.
- PLC-HS for video information and high-speed communication.
The RG213 coax cable in ETR500 trains could be used in the same way giving the possibility to address additional modulated (FM) signals on frequency higher than 40 MHz. A complete frequency domain of injected signals on a single couple of wires is summarised in Figure 4.
The proposed PLC-HS network is an IP network, supplying all the interesting benefits of IP
communication, given by the complete support of ISO-OSI standard protocols:
- Support to reliable and unreliable data exchange (TCP/UDP).
- Support to any kind of addressing (unicast, multicast, broadcast).
- Layer 3 protocol routing.
- Interoperability, flexibility, ease of expansion of the application layer.
According to the requested reliability level, data shown in table 2 can be exchanged following different solutions: for example data implying a low level of reliability can be sent using UDP multicast/broadcast traffics while information needing a higher level of delivery reliability (medium/high level) can be sent via TCP unicast sessions. Hosts belonging to the PLC-HS network, called “Dispositivo Onde Convogliate di Treno” (DOC3N), fully benefit from the wide IP protocol suite (DHCP, DNS, HTTP and FTP transfers, RTP streams, NTP, etc..). In the PLC-HS network, for privacy and security requirements, in compliance with the HomePlug Standard, all devices composing the same backbone network need to have the same private network key. Traffic encryption is achieved through a symmetrical encryption scheme, based on a 56 bit key. Any other device sharing the medium is not able to communicate with the PLC-HS network.
The PLC-LS network allows a pervasive integration for systems supporting diagnostic data exchanges. Devices connected on the bus of the PLC-LS network have full knowledge of the other devices and can send their operating status and data related to any appliance they are monitoring, using the most appropriated data transfer between:
- Unreliable unacknowledged unicast, multicast and broadcast transfers for low level delivery reliability.
- Reliable or unacknowledged-repeated unicast and multicast transfers for medium or high level delivery reliability.
- Request-response transfers for high level delivery reliability.
In the PLC-LS network, for privacy and security requirements, a sender authentication service is implemented as a Layer 4 service.
5 Test on PLC- HS Setup
To properly validate the PLC-HS solution, we prepared an ad-hoc test plant implementing a bus. 14 PLC-HS hosts were connected through a RG213 coaxial cable, each node distant from the adjacent ones 30 meters. This situation represents a good approximation of the real installation over ETR500 trains. Each node consisted of a single board computer equipped with LX800 AMD Geode processor and 256 MB DDR RAM, running Windows XP Embedded. Figure 5 shows the topology of the simulation network.
We used Ixchariot by Ixia [6], as a test tool, by installing 13 endpoints and a control station acting even as an endpoint. Ixchariot is a powerful performance tool capable of generating real world TCP/UDP traffics, using the TCP/IP stacks of the host operating system and calculating important network characteristics such as throughput and latency. Tests consisted in running customized scripts on each endpoint, realizing a simulation of TCP data exchange between couples of non-adjacent nodes, that is nodes positioned in opposite points of the bus.
Tests has been conducted generating 7 simultaneous streams of data between different couples of nodes at increasing data rates to force bus congestion and access media contention. The following figures (Figure 6, 7 and 8) show the result of a simulation executing a 500kB file transfer, forcing a 2 Mbps maximum throughput for each couple of nodes
6 Experimental Results
The previous proposed PLC-LS and PLC-HS network can be implemented on both ETR500 and commuter trains. The main devices involved in this architecture (Figure 9) are:
- OBoE: the system able to communicate with the ground system with GSM/GPRS technology (optional Wi-Fi) and locate the train position with a GPS module. The equipment is directly interfaced to the train audio network to provide audio information and can send commands and read statuses of devices placed on the PLC-LS and PLCHS train network.
- DOC3N: the so called “ Coach Communication Box” interfaced with at least one PLCHS module and one PLC-LS module towards the train backbone. This device must communicate with other devices placed on the same coach with standard interface modules (Ethernet, serial, USB, CAN).
- DOVE6: the LCD display able to provide journey information to passengers: train position, arriving times and train connections at the next stop. These data are exchanged between OBoE and DOVE6 thanks to the train backbone.
- External displays and other PIS devices: generic equipment can receive commands and send the status with the local DOC3N device and exchange information with the ground system through OBoE and DOC3N train network.
The availability of a double coaxial RG213 cable allows a more complex and robust implementation of the two proposed networks, providing complete redundancy. Redundancy is achieved by connecting two transceivers to each host belonging to a network. In case of accidental interruption or extreme noise on one of the two RG213 cables, PLC-HS and PLC-LS networks are guaranteed of correct working, by automatically detecting the failure and changing the communication medium. Moreover, the use of the double RG213 coaxial cable as redundant physical layer allows an optimized access to the bus, maximizing the available bandwidth. In fact, an automated mechanism can be implemented on OBoE, acting as DHCP server, to distribute IP addresses belonging to two different IP scopes, one for each channel, splitting traffic between the two different media. On the other hand, DOC3N devices, during the boot process, run a DHCP client on a randomly chosen Ethernet interface (i.e. the coax channel) between the two supplied. If an IP address is assigned within a given timeout, DOC3N starts working on one channel, otherwise a new attempt is performed on the other interface, deactivating the former one. The information displayed during the test campaign on Italian commuter train is shown in Figure 10.
Conclusion
A flexible, cost-effective and unified approach to PIS devices is proposed in this paper with the usage of already installed cable (13-18 poles UIC cable or coax cable). A full solution of audio and video contents should be provided to Italian passengers for a more comfortable journey increasing the customer satisfaction.
References
[1] UIC 558 – Fiche No. 558 “Ligne de télécommande et d’information”
[2] UIC 568 – Fiche No. 568 “Sonorisation et téléphone des voitures RIC”
[3] IEC 61375-1 “Train Communication Network”
[4] LonTalk Protocol Specification, 1994
[5] HomePlug Alliance. HomePlug 1.0 Specification, 2001
[6] Ixia: www.ixiacom.com