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

• systems similar to the one described below
• systems that didn't break the track into blocks but gave out reservations of arbitrary size
• systems that gave reservation that were areas rather than blocks.

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.
   • If a train is stopped it would normally have a reservation for only one block, but it might have a reservation for two blocks.

(** failsafe conditions)

Who enforces these conditions?

• Nobody does so explicitly.
• There are several constraints
  1. The reservation server always gives out reservations that are contiguous.
  2. The reservation server never gives out an already reserved piece of track.
  3. The reservation serve never revokes a reservation.
  4. The train always travels slowly enough that it can stop within its current reservation if a request for extension is refused.
• Responsibility for enforcement is distributed.

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

• What is it?

Here's how it works in theory

1. Train gets a route from the route finder, and looks ahead along the route.
   • Train has a desired speed.
2. Train asks reservation system for several blocks of track along the route
   • Blocks usually end at switches and/or sensors
   • If you are ending blocks at switches you must know well enough how enough where the train is to be confident it is completely clear of the switch.
3. Reservation system grants the blocks if they are available
   • Grants include the condition that the train must travel so that it can come to a complete stop without leaving any reserved block.

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.
   • The reservation includes enough track at the end of these blocks so that the train can stop before reaching the end of its reservation.
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
   • Symptom: trains split and/or merge
   • One is bound to get inconsistent state
   • Should be solved by the reservation system
2. Spurious sensor report that a train is actually expecting.
   • Most often for a secondary prediction,
     • because the temporal window for a secondary prediction can precede the time window for the primary one.
   • Tightening temporal windows helps this
     • but can't eliminate it
   • Could look further ahead so that secondary predictions alway lag behind primary ones
   • Recover from such an error by back-tracking
3. Permanently malfunctioning turn outs
   • Can't be switched or always derails
   • Alter track graph
     • Important to be able to alter the track graph from the prompt
4. Permanently malfunctioning sensors
   • Usually fail on because of sticking
   • Unstick by hand
   • Alter track graph and mask reports
     • See above for track graph
     • Mask at as low a level as possible
5. Finding the trains at the beginning
   • One at a time
   • Move slowly

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
   • Reservations branch out ahead and cover a lot of the track
   • Trains give back unneeded reservations as they slow down
2. Reservations are not released.
   • Usually shows itself only when the project is well advanced
   • Looks as though there are phantom trains in the system
   • Usually most of a reservation is released, but not all.
3. Reservation leap-frogging
   • Two trains are approaching one another; each gets a reservation behind the other. (Badly needs a diagram.)
   • Ask for and/or give out reservations in the right order

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.
   • One partner watches the map while the other observes the trains
4. Trains can get sensor reports only for sensors with the reservations they hold.
   • This is often the earliest symptom of a train getting lost.
5. Enforce in the reservation server that all reservations must be contiguous.
   • Non-contiguous reservations are an early symptom of reservation system failure.

Common Route-Finding/Following Bugs

1. Train derails on turn-out after train changes direction
   • Improve acceleration/deceleration calibration
   • Switch turn-outs for both directions of travel
2. Train derails on turn-out after turn-out changes direction
   • Improve acceleration/deceleration calibration
3. Switch switches too late
   • Treat command latencies systematically
4. Train collides with stationary train
   • Be certain that stationary trains have reservations
   • Insert/remove reservations by hand from the prompt

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:

• Bill Cowan's Fall 2011 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page