Simulating Communication Based Train Control (CBTC) systems

Simulating Communication Based Train Control (CBTC) systems


The main contribution of this work is the implemlentation and the presentation of new modules for NS3 |ns3|. These modules have been applied in an industrial field, i.e. Communication Based Train Control (CBTC). The main objective of the simulation study is the evaluation of some performance metrics of a typical signalling system implementation for metro by Alstom Transport; one of the world largest company in the domain of rail transport and signalling. The communication between trains and a central server is done using WiFi technology. Then, the simulation is used to investigate the dimension of the radio access networks and to assess the impact of different factors (e.g. interference, packet loss, handover, congestion due to bursty traffic, interference, etc.) on the critical message availability.

Acknowledgment
##############
This work is partially funded by the Inria-Alstom Transport virtual lab. The people implied in the project are (alphabetically ordered): S. Alouf, A. Dandoush, P. Derouet, P. Dersin, G. Neglia, S. Simoens, and A. Tuholukova.

Model Description
*****************

The source code for the new module lives in the directory ``src/cbtc-manager`` and in ``src/applications``.

In order to avoid collisions between consecutive trains traveling on the same track, the track is traditionally divided in fixed sections---called blocks---, only one train at a time is allowed to be in a given block. The cost of the required trackside equipment limits blocks' granularity and determines a lower bound for the trains' headway, i.e. the minimum distance (or time) achievable between two consecutive trains. The minimum headway determines the maximum line capacity, e.g. expressed in number of passengers per hour.

The increasing demand for efficient mass transit transport requires to utilize train lines more efficiently. The improvements of train-sidetrack wireless communications, on board processing and actuators have made possible the introduction in the last 15 years of moving block systems, where blocks are dynamically calculated. The moving-block control can reduce the headway taking into account the actual distance between the trains as well as their speeds. It is being deployed as Communication-Based Train Control (CBTC) for  urban mass transit system and is under consideration for next generation of European Train Control System (ETCS level 3 under standardization).

In moving-block systems an on board local controller, called the Carborne Controller (CC), continuously collects and processes data about different quantities of interest like the train's position, its speed, etc. This information so-called LOC (location report) is sent periodically to an external ground controller, which is called the Zone Controller (ZC) because it monitors all the trains in a given zone. On the basis of the information collected from all the trains, the ZC computes the End of movement Authority (EoA) for each train and sends it to the corresponding CC, using standard or proprietary radio technologies. Messages can be sent redundantly through multiple independent channels to reduce the risk that the information is lost, nevertheless such event can always occur. Given that ZC messages carry movement authorities that are safety-critical, if no EoA message is received during a given interval then the CC will no longer have valid guarantees that train movement is still safe and will trigger an Emergency Brake (EB). It is clearly desirable to limit the frequency of spurious emergency brakes, i.e. emergency brakes that are simply due to losses on the wireless channel and not to a potential collision risk. Indeed spurious emergency brake can be themselves a cause of danger, with trains potentially blocked in tunnels, risks of passengers disembarking on the tracks, etc. Moreover, a spurious EB can generate legitimate EBs on the following trains on the track, causing in this way major service disturbance.
For this reason, the so-called performance based contracts (similar to service level agreements for network operators) can bind rail transport companies to specify the maximum number of spurious emergency brakes over a given period of time.

Documentation, example and usage
********************************

Please see the src/cbtc-manager/doc/cbtc-manager.rst
 file for a good documentation and usage example. A complete example is provided in src/cbtc-manager/examples.

[adandoush, 2016-02-12 10:56:45]

Dear ns-3 reviewers,

I thank you in advance to consider the following new issue for reviewing
process:

https://codereview.appspot.com/289110043/

The main contribution of this work is the implementation and the presentation of
new modules for NS3. These modules have been applied in an industrial field,
i.e. Communication Based Train Control (CBTC). The main objective of the
simulation study is the evaluation of some performance metrics of a typical
signaling system implementation for metro by Alstom Transport; one of the world
largest company in the domain of rail transport and signaling. The communication
between trains and a central server is done using WiFi technology. Then, the
simulation is used to investigate the dimension of the radio access networks and
to assess the impact of different factors (e.g. interference, packet loss,
handover, congestion due to bursty traffic, interference, etc.) on the critical
message availability.

Documentation about the protocol design, the implementation overview, and the
usage with an example is provided.

Acknowledgment
##############
This work is partially funded by the Inria-Alstom Transport virtual lab. The
people implied in the project are (alphabetically ordered): S. Alouf, A.
Dandoush, P. Derouet, P. Dersin, G. Neglia, S. Simoens, and A. Tuholukova.

Best regards,

Abdulhalim Dandoush

[Tommaso Pecorella, 2016-02-13 21:11:15]

Hi,

I understand that you can't say everything, probably due to NDAs, and I
understand that some quite puzzling decisions are coming directly from the
companies you're working with, however...

- The figure referenced in the .rst is not available,
- The .rst file itself is not correctly formatted (please use .rst format for
lists and use an 80 columns formatting)
- The decision to use IPv4 is to be triple checked. I know for sure that all the
EU projects explicitly require IPv6, and ETSI projects as well. I can't care
less if Alstom is thinking they can do what they want and/or if Alcatel Lucent
(or Selex ES) thinks they ave to empty their shelves. I know more than you may
think about this.

Moreover, please take your time to double check everything, especially the dead
code (commented or not) and the documentation.
From the doc it is unclear what scenario this module is meant to simulate (urban
train, low speed I bet), and it is unclear what every component does or should
do. This must be very clear, or the users will flood the forums with bad
questions based on false beliefs.

As an example, you name ECTS standards. Which one are you referring to ? What
parts have you implemented ? What are the limitations ?
etc.

Beside my points (and don't doubt, I'll have more), I'd strongly encourage you
to keep on with the review process. The final product will be undoubtedly
interesting.

T.