CS452 - Real-Time Programming - Spring 2012

Lecture 27 - Demos, Reservations

Public Service Annoucements

1. Final exam date: 9.00 August 7 to 11.30 August 9
2. The gold standard for milestone 2 is
   • two trains on the track
   • each receiving a new, random destination each time it reaches its current destination
   • running for five minutes or so

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 type of problems you must solve in order to keep 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 covered by the track rather than lines the length of the track..

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

Hard Conditions

Needed to avoid collisions

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 piece of track should ever be reserved by more than one train.

Soft Conditions

Needed to keep the trains moving

1. Every train must release blocks it no longer occupies and will not occupy in the immediate future.
2. Every reservation held by a train must be contiguous
3. Trains should release unneeded blocks in front of themselves if they slow down or stop.
   • A stopped train will hold either one or two blocks.
   • Your system will behave perfectly well with only two trains if you do not enforce this condition, but it will often spontaneously thaw when a freeze occurs.

Who enforces these conditions?

• Nobody does so explicitly.
• There are constraints derived from the conditions above, such as
  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 server 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.
  5. And so on.
• Enforcement is provided by a protocol that every task obeys.

There is a situation in which the 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 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 imply the condition that the train must travel so that it can come to a complete stop without leaving any reserved block.
   • Grants must be provided in the correct order

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 AND it can stop within the reservation, it continues travelling at speed.
   • Otherwise it stops

     Or slows down enough to stop before the end of its reservation.

Reservation Implementation

You might decide that reservation negotiation will take place every time the train receives a sensor report.

• Just requesting reservations whenever they're needed has a problem.
• Train drivers are likely to poll
• Polling is extremely priority-dependent.
• Priority-dependent bugs are hard to find, harder to fix.

Every time a train receives a sensor report it does its reservation procedure

1. Release the reservation just vacated
2. Test stopping within the reservation at the next request time (sensor report).
3. If okay, finished
4. If no, how much do I need beyond my current reservation?
5. Request what's needed, possibly more
   • Indicate the order in which you want the reservations (contiguity).
   • This depends on the direction in which you are travelling, which it's not necessary for the reservation server to know.
   • It could be deduced by the reservation server, but why bother.
6. Reservation server gives as much as it can
7. Train rechecks stopping condition using the complete reservation.
8. If okay, finished
9. If no, either
   • stop,

   or

   • slow down enough to satisfy the stopping condition

Comment. We like slowing down, which we consider to be a more intelligent and aesthetic response to following a slow train than stop-start driving.

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 reports 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
     • Partly for testing, but don't disable it in your demo version because it can rescue a demo.
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

Useful debugging aids

1. Alter the track graph from the prompt.
2. Simulate sensor-triggering from the prompt.
3. From a low level log events that change track state.
   • Are they consistent with the track state shown in your UI?

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.
     • Has also been seen when one train is following another.
   • 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. (Editor's comment. It doesn't seem to me that `a train is getting lost', but that `a train is lost'.)
5. Enforce in the reservation server that all reservations must be contiguous.
   • Non-contiguous reservation requests 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 as turn-out switches
   • Improve acceleration/deceleration calibration
   • Improve train tracking
3. Switch turn-outs 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

All the above, plus

1. Add/subtract switches, sections of track from graph by hand from the prompt
2. By modifying the route-finder you can confine all routes to a subset of the tracks.
   • This allows you to solve the common problems without being affetced by uncommon ones.

Early Signs of Problems

Frequent train finding. (You should not be refinding trains every time they stop.)

Return to:

• Bill Cowan's lecture notes for CS452 in s12
• Bill Cowan's Spring 2012 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page