CS452 - Real-Time Programming - Spring 2017

Lecture 25 - Multiple Trains

Public Service Annoucements

  1. Train Control II demo on Tuesday, 18 July.
  2. The exam will start at 19.30, July 28, 2017 and finish at 22.00, 29 July 2017.


Multi-Train Control

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

Sensor Attribution

Route Finding and Following

Collision Avoidance

Treating the track as a shared resource

There is a good analogy with the X server providing parts of the display to different processes. The division into parts is dynamic as windows are opened, closed, moved, resized and so on. Some of these actions are initiated by the process that requested the server to open a window; others, such as the window being partially occuded by another window are invisible to it. Occasionally the server sends a message to the process asking it to do something, such as repainting the window.

A track server gives out and takes back pieces of track. Pieces can either

Policy

Collision avoidance is the goal. We want a policy that controls how the track server gives out track, and how the train uses the track that it gets. The policy should have two properties.

  1. Its should be easy to convince yourself that the policy prevents collisions.
  2. The policy should be easy to implement, taking into account the real properties of the trains and the track. This is the hard part.

Here is an example of a typical policy.

  1. The server ensures that zero or one train owns each section of track.
  2. A train may only occupy track that it owns.
  3. A train can only operate on track it owns. In practice, "operate on" means "switching turn-outs".
  4. Track should be returned to the track server as soon as a train leaves it.
  5. When a train slows or stops it may have track reserved ahead of it that it will not use in the immediate future. Such reservations should be returned to the track server.
  6. To avoid leapfrog deadlocks, all the track owned by a train must be contiguous.
Items 1 and 2 ensure that no collisions occur. Item 3 ensures that the state of track owned by a train is never changed by another train. Item 4 allows trains to drive on the same piece of track, albeit at different times, so that the demo continues. Item 5 improves performance. Item 6 saves us from the leapfrog bug, which is surprisingly common in practice.

There are many successfully policies. You only need one, but make sure that you understand the properties of the policy you use.


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. The upper level determines which track is given to trains; the lower level is a set of rules that a train driver must obey when driving.

Upper Level

  1. Train asks dispatcher for a route.
  2. Dispatcher provides a route that he/she expects 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 and test your reservation policy before you start to implement it.

Before starting to implement 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 failures of sensors and switches

There are one or more switches in the path

Implementing the policies.

No over-driving

Here is the sequence of events that occurs when a train stops.

  1. The train has enough track to continue driving.
  2. The train decides that it needs more track than it currently has.
  3. The train requests track, and is turned down.
  4. The train gives a "speed zero" command.
  5. The train slows, stopping one stopping distance from where it gave the sp 0 command.
If the train is to avoid overdriving its track when does step 2 need to occur?

Operating reserved track

A few questions to think about

Single owner

Something atomic, presumably a server, has to control who has what track.

No leapfrog deadlock

The server can control this. Or the server can be less smart and assume that input from the train is reliable. Then the train driver must be programmed to asked for pieces of track in the right order.

Returning reservations

Based on past history train drivers very commonly make errors when giving back reserved track. (Off by one errors are extremely common.) It's not hard for a track server to figure out that a train driver should have given back a section of track, but how to you get it from them.

Reservations can easily get fragmented because of bugs in the track returning code. Make sure that doesn't happen.

Timed Reservations

In the past students have experimented with timed reservations, where the reservation is returned, whether the train driver likes it or not, when its time has expired. Results have not been good. How can a server be sure that a train driver can exit a reservation before a pre-specified time? How can a train driver figure out that it won't leave in time, and if so what can it do?


Return to: