CS452 - Real-Time Programming - Spring 2011

Lecture 25 - Reservation Bugs

Pubilic Service Announcement

1. Project proposals.
2. Train availability.
3. Second train control demo. `I must have been insane.'

Reservations

A Typical Reservation System

Hard Conditions

1. **Every train must have a reservation for the block it occupies.
2. **Every train must travel at a low enough velocity that it can stop before the end of the blocks it has reserved.
3. **Every train should reserve enough to handle single sensor or (exclusive) single switch errors.
4. Trains can switch turn-outs only on track they have reserved.
5. Possibly, trains can query sensors only on track they have reserved.
6. 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?

• What is it?

Here's how it works

1. Train gets a route from the route finder, and looks ahead along the route.
   • Train has a desired speed (n), with velocity v(n), and a current velocity (v)
   • It is in block b(0).
   • The train currently owns enough blocks that if it gets a stop signal at the beginning of the next block, b(1), it can stop without over-running its reservation.
     • e.g. If v = 0 then the train has only the block it occupies, b(0), reserved
   • Call the last reserved block b(x)
2. Train asks reservation system for several blocks of track. How many?
   • It would like to be travelling at v(n).
     • It needs the next block, b(1), and
     • If it starts accelerating towards v(n) it will achieve a velocity v' at the beginning of b(2), then it needs enough blocks that it can stop from that speed if it receives a stop signal at the beginning of b(2).
     • Call the last block it needs b(y): y >= x
     • It asks for blocks b(x+1) to b(y), which may be zero
   • It needs the next block, b(1)
   • 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
   • That is, if b(x+1) to b(y) are unreserved, and the train proceeds as planned.
   • If some are available, but not all, the the ones available are granted and it is up to the train to modify its speed accordingly.

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. There are one or more switches in the path

Problems I Have Seen More than Once

Common Multi-train Tracking Problems

1. Two trains waiting on the same sensor report
   • 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 likely to be 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

Useful debugging aids

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

Return to:

• Bill Cowan's lecture notes for CS452 in s11
• Bill Cowan's Spring 2011 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching pagelu