CS452 - Real-Time Programming - Spring 2015

Lecture 26 - Reservations, aka Collision Avoidance.

Public Service Annoucements

  1. Train Control I demo on Wednesday, 8 July.
  2. The exam has three start times. The end times are 26.5 hours after the start time.
    Answers to questions asked from 20.30, 4 August to 22.00, 4 August will be answered on the newsgroup, whether they arrive by e-mail or on the newsgroup.


Multi-Train Control

By the next 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

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. Trains can operate on track they have obtained from the server. In practice "operate on" means "switching turn-outs".
  3. The server never gives out pices of track that are already out.
  4. To avoid leapfrog deadlocks, all the track owned by a train must be contiguous.
  5. Track should be returned to the track server as soon as a train leaves it.

The first three are necessary for correctness. Are they sufficient? The fourth avoids a common bug. The fifth 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

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.
  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 occur?

Operating reserved track

How much must be controlled to ensure that this constraint is respected? Try listing all the things that might go wrong? Are willing to trust the train driver?

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. But once they have the track it's hard to get it back from them.

In the past students have experimented with timed reservations, where the reservation is reused, like 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: