CS452 - Real-Time Programming - Winter 2015

Lecture 24 - Controlling Multiple Trains

Public Service Annoucements

  1. First train control demo: Wednesday, 11 March, 2015.
  2. Exam: 16.00 14 April to 18.30 15 April
  3. Suppose you decided in advance that you want a train to travel at exactly 28 cm/sec. A similar approach can be used to have one train follow another at a specific distance.

Multi-Train Control

By tomorrow you should be able to drive one train on the track, knowing exactly where it is.

By the next milestone you will be able to control two trains at the same time.

Sensor Attribution

The first problem occurs when you receive a sensor report. Which train triggered the sensor?

One way of doing this is to plan ahead.

Communication bandwidth to train controller

This is the scarcest resource.

The symptom that you are trying to use it too much is getting a lot of time-outs for events that actually occurred. Switches switching too late is another symptom.


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.

You can try a gradually harder approach.

  1. Make sure that you really have the train finding the shortest route using only one train.
  2. Make sure that you can route around one or more obstacles by manually removing an edge from the graph.
  3. Drive a second train to some point; make sure that you route around it automatically.
  4. Let the second train move in a simple way; make sure that you can route around.
  5. Make two trains route simultaneously.
When you are testing hand or mentally calculate the shortest route before you start the train moving.

It doesn't matter what shortest-path algorithm you use, with one exception: the Floyd-Warshall algorithm does NOT work.


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 the two trains to stop.

It is usually your method of collision avoidance that limits the number of trains that can run simultaneously.

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?

  1. Make sure that you really have the train finding the shortest route using only one train.
  2. Make sure that you can route around one or more obstacles by manually removing an edge from the graph.
  3. Drive a second train to some point; make sure that you route around it automatically

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.


Reservations

Somebody has been doing something right for over a 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.

Lower Level

The lower level is also communicated by the coloured lights. In cases of conflict between the upper and lower levels, the lower level overrides the upper level.

Something Essential that You Must Do

Design your reservation 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 much switching
  4. Single point failures.

There are one or more switches in the path


Return to: