CS452 - Real-Time Programming - Fall 2011

Lecture 27 - Reservations III

Public Service Annoucements

  1. 14 November, 2011. Project Proposals due.
  2. First train control demo: 15 November, 2011.
  3. Second train control demo: 24 November, 2011.
  4. Final exam: 10.30, Friday, 10 December, 2011 to 13.30, Saturday, 11 December, 2011.

Sensor Attribution

A Typical Reservation System

A reservation system is not the only way to keep trains from hitting one another.

The reservation system described below is not the only reservation system that works. I created it to illustrate the problems you must solve when you are keeping trains from colliding.

In past terms, students have succeeded using

Reducing the need for communication with the train controller by doing more computation on the CPU consistenly outperform.

Hard Conditions

  1. **Every train must have a reservation for the track it occupies.
  2. **Every train must travel at a low enough velocity that it can stop before the end of the track it has reserved.
  3. **Every train should reserve enough to handle single sensor or (exclusive) single switch errors.
  4. **No track should ever be reserved by more than one train.
  5. Every train must release blocks it no longer occupies and will not occupy in the immediate future.

(** failsafe conditions)

Who enforces these conditions?

There is a situation in which these conditions cannot be enforced?

Here's how it works in theory

  1. Train gets a route from the route finder, and looks ahead along the route.
  2. Train asks reservation system for several blocks of track along the route
  3. Reservation system grants the blocks if they are available

Here's one way for it to work in practice

  1. A train receives a reservation that will allow it to travel at its desired speed for one or more blocks.
  2. Each time the train leaves a block it frees the reservation it had for that block.
  3. Before reaching the end of the blocks on which it can travel at speed, it requests an extention of its reservation.
  4. If the request is granted it continues travelling at speed.

    Otherwise it starts slowing down so that it stops before the end of its reservation.

You would grant reservations as follows:

<< This needs something a lot easier to understand.>>

Problems I Have Seen More than Once

Common Multi-train Tracking Problems

  1. Two trains waiting on the same sensor report
  2. Spurious sensor report that a train is actually expecting.
  3. Permanently malfunctioning turn outs
  4. Permanently malfunctioning sensors
  5. Finding the trains at the beginning

Useful debugging aids

  1. Alter the track graph from the prompt.
  2. Simulate sensor-triggering from the prompt.

Common Reservation System Problems

  1. System freezes
  2. Reservations are not released.
  3. Reservation leap-frogging

Useful debugging aids

  1. Insert/remove reservations by hand from the prompt
  2. Query reservations (and who holds them) from the prompt
  3. Track map showing reservations in real-time.
  4. Trains can get sensor reports only for sensors with the reservations they hold.
  5. Enforce in the reservation server that all reservations must be contiguous.

Common Route-Finding/Following Bugs

  1. Train derails on turn-out after train changes direction
  2. Train derails on turn-out after turn-out changes direction
  3. Switch switches too late
  4. Train collides with stationary train

Useful debugging aids

  1. Add/subtract switches, sections of track from graph by hand from the prompt

Early Signs of Problems

  1. Frequent train finding. Do not refind train every time you stop.

Return to: