CS452 - Real-Time Programming - Winter 2015

Lecture 25 - Controlling Multiple Trains

Public Service Annoucements

  1. Our compliments on the first train control demo.
  2. Second train control demo: Wednesday, 25 March, 2015.
  3. Exam: 10.00 13 April to 12.30 14 April

Multi-Train Control

Sensor Attribution

Communication bandwidth to train controller

Most projects had good precision (< 4cm) in the demos. This is fine for milestone 2. How it was done may, however, overtax communication with the train controller as a project develops. Then precision will fall and some solved problems will become unsolved. There are two obvious things that can be done.

  1. Confine all communication with the train controller to a single server that maintains the state of the train system: All tasks that need information about the state of the track query this server.
  2. Use a sequence of sensor triggers by the same train to get a better estimate of where it is.
  3. Route Finding

    You need to be able to route in the presence of obstacles.

    We require routes that reverse because it improves the performance of your project.

    Collision Avoidance

    This would not be too hard if the trains stopped instantaneously, but they don't.

    Your train program must plan ahead, at least as long as it takes two trains heading towards one another to stop.

    I like distributed solutions, where each train operates -- plans, drives, make decisions, etc -- as though there are no other trains on the track. Why do I like this?

    Treating the track as a shared resource

    Analogy to pixels in a window environment.

    A track server gives out and takes back pieces of track.

    What policy should it have?

    1. Trains can only occupy track they have obtained from the server.
    2. The server never gives out pices of track that are already out.
    3. To avoid leapfrog deadlock, all the track owned by a train must be contiguous.
    4. Track should be returned to the track server as soon as a train leaves it.

    The first two are necessary for correctness. Are they sufficient? The third avoids a common bug. The fourth both avoids bugs and improves performance.


    Somebody has been doing something right for the last century. The answer is reservations.

    Two Level Train Control

    The two levels are completely independent of one another.

    Upper Level

    1. Train asks dispatcher for a route
    2. Dispatcher provides a route that he/she thinks to be conflict free
    3. Train follows the route, reporting back to the dispatcher as landmarks (sensors) are passed.
      • The dispatcher gets two reports
        1. One from the hardware
        2. One from the engineer
      • It is up to the dispatcher to make certain that the policy is not violated by the routes handed out. The dispatcher sees a visualization of the track and changes routes as needed.
      • What is to come on the route is communicated to the train driver by the lights along the track

    Lower Level

    The lower level is encoded in the coloured lights you see along the track. In cases of conflict between the upper and lower levels, the lower level wins.

    Something that I think makes things easier

    Design and test your collision avoidance system before coding it.

    Before coding your reservation system work it out on paper and make sure that it works for all the generic cases you can think of

    1. One train following another
    2. Two trains on a collision course
    3. Short routes with many turn-outs in the path
    4. Single point failures.

    Return to: