CS452 - Real-Time Programming - Fall 2011

Lecture 25 - Reservations I

Public Service Annoucements

  1. Sensors have a natural position to measure from.

    Many students like to use switches as landmarks also.

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

How to Give a Demo

Two Related Rules

  1. Don't lose the initiative.
  2. Show everything you want to show.

Practical Ideas for Following the Rules

Do these BEFORE the demo.

  1. Sit down with your partner and decide what you would like to show us.
  2. Determine an order of these things that
  3. Choose things like where the train will start and what it will do.
  4. Write a list so that when you are nervous at the demo you don't forget what you want to do next.
  5. Try out what you want to do to make sure that your list makes sense.

Do these AT the demo.

  1. Tell us what you are showing us and why we should be impressed
  2. There are two of you; take advantage of it.
  3. Drive the train around the track in preference to picking it up.
  4. Ask us explicitly if we have any questions.
  5. Swap roles

One Observation

  1. No student has ever complained about a lecture ending before the end of class time.

Sensor Attribution

For each train there is a set of predictions

  1. The primary prediction: if the world is perfect train n will trigger sensor X between t1 & t2.
  2. One or more secondary predictions, having one of the two following forms
  3. Attribute a sensor hit to train n if it fulfils one of train n's predictions.
  4. What if two trains are making the same prediction?

This works fine once you have trains moving. How do you get them moving?

Starting the next train

  1. Start it slowly, you don't know where it is.
  2. When it hits a sensor
  3. Conclude that you know where the train is when it hits the predicted sensor.

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 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. 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:

  1. A train is about to enter block n, holding a reservation from block n-1 to block n+x.
  2. Must the train extend its reservation right now? Yes, unless it can some time in the future
  3. How much should the train request?
  4. The reservation server might provide only part of the reservation a train requests. If so, what should it do?
  5. First, suppose that the train will continue travelling at the same speed, s.
  6. Try to reserve to n+y: if sucessful keep travelling without reducing speed, i.e. at speed s..
  7. If unsuccessful reserve as much as you can: say to the end of block y'
  8. Calculate, using your calibration, the speed that allows you to stop by the end of block n+y' if you set the speed to zero at the beginning of block n+1.
  9. Check using your calibration that you can reduce to the steady-state velocity of speed r by the beginning of block n+1.
  10. Set your speed to the highest speed that allows you to get to the velocity of speed r by the end of block n+1.

An Interesting Tit-bit That Doesn't Concern You

Real trains are long and sometimes occupy several blocks at once. How does the engineer know that the end of a train is clear of a switch?

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

Return to: