## 6 System Evaluation
### Complete System  
To assess the feasibility of the monitoring system, the proposed architecture described in Section 4.1 has been implemented and tested in-lab. Out of the three architectures based on radio \begin{table}
\begin{tabular}{c c c} \hline \hline \multicolumn{3}{c}{**Packet Sent**} \\ \hline  & **Packet** & **Kilobytes** \\ \hline
**Transmitter 1** & 16 & 1600 \\
**Transmitter 2** & 26 & 2600 \\
**Total** & 42 & 4200 \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Transmission and mobility tests with two transmitters (868 MHz, 0 dBi). \begin{table}
\begin{tabular}{c c c} \hline \hline \multicolumn{3}{c}{**Packet Sent**} \\ \hline  & **Packet** & **Kilobytes** \\ \hline
**Transmitter 1** & 13 & 1300 \\
**Transmitter 2** & 13 & 1300 \\
**Transmitter 3** & 24 & 2400 \\
**Total** & 50 & 5000 \\ \hline \hline \end{tabular}
\end{table} 
Table 7: Transmission and mobility tests with three transmitters (868 MHz, 0 dBi). Figure 15: Results of the transmission and mobility (868 MHz and 0 dBi antennas). transmitters presented, the one that combines two different modules has been chosen because of the following advantages:  
1. 868 MHz radio modules do not require association so they are more suitable for node-to-train communication. 2. 2.4 GHz communication is more reliable in short range communications and has a lower cost and power consumption so it is more suitable for node to node communication (in the railway infrastructure). 3. There is no interference between node-to-node and node-to-train communication. This architecture divides the nodes deployed in the railway infrastructure into different groups. The information generated in each group is collected by a coordinator node using ZigBee in the 2.4 GHz band (XBee PRO S2 radio module). Each time a train passes, the coordinator of each group uses the 868 MHz band (XBee 868 radio module) to send information to a receiver node installed on that train. We assume that the train has Internet connectivity. Therefore, once the information has been received on the train it will be sent to a remote database for storage. Figure 16 shows the overall system architecture. A set of nodes marked with circles are displayed. These nodes are organized into groups with a single coordinator. The group coordinator receives the information collected by other nodes using ZigBee. Coordinators then detect when a train is approaching and using point to point communication in the 868 MHz band send the information to the train. As stated in Section 3, once the train receives information it is sent to a remote database using the Internet (TCP/IP). Collecting information on the train and sending the data to the database is performed by a Python script that uses the Python-class library Xbee. The data is stored in a time series database called OpenTSDB [25]. This database has been especially optimized for temporal data like that collected by the monitoring system. Once the data is in the database, it can be accessed from any browser accessing the IP of the computer where the OpenTSDB server is deployed. Figure 16: Complete system communication architecture. Figure 17 illustrates the appearance of the devices used to implement the communication system prototype. For a realistic simulation we have implemented a simple train simulator. This simulator simulates the passing of a train every half an hour. The train passing by lasts 20 s which means that 20 s of acceleration data at 800 Hz will be collected. Once the data has been collected it is analyzed with the algorithm mentioned in Section 3.3. Once the peaks in the frequency domain have been identified, this information is sent to the coordinator of the monitoring group. Finally, when a data mule train is detected, all this information is sent to it. Figure 18 summarizes the schedule of the various activities that occur in the sensors with respect to the schedule of the trains.