CS452 - Real-Time Programming - Fall 2011

Lecture 25 - Reservations I

Public Service Annoucements

1. Sensors have a natural position to measure from.
   • You can use sensors as your only landmarks

   Many students like to use switches as landmarks also.

   • If you do choose an exact point on the switch that you are measuring from.
   • This may require you to adjust your track measurements by a few cm.
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.
   • If you lose the initiative, then we will start asking you questions.
   • You may never get back to what you wanted to show us.
   • Remember, `Nature abhors a vacuum.' When there is dead air we will, simply from politeness, say things to maintain the conversation.
2. Show everything you want to show.
   • If you are in control you can show us what you think is successful and neat.
   • If you don't show us we may never know about it.

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
   • is logical, and
   • leaves the train and track in the right state to show the next one.
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
   • Thick people, like professors, have to be told what they're seeing or they won't see it.
2. There are two of you; take advantage of it.
   • One should drive the train;
   • the other should tell us what we are seeing and what it shows about your program.
3. Drive the train around the track in preference to picking it up.
4. Ask us explicitly if we have any questions.
   • This gives you the right to stop taking questions and to go on to the next thing you want to show.
   • E.g., `Now we want to show you ...' should even shut up professors.
5. Swap roles
   • to give us variety
   • to give both/all of you the opportunity to practice each role

One Observation

1. No student has ever complained about a lecture ending before the end of class time.
   • That's human nature.
   • Profs and TAs are human too.

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
   • If the sensor X fails train n will to trigger sensor Y between t3 & t4
   • If switch A is set `incorrectly' train n will to trigger sensor Z between t5 & t6
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?
   • They are too close together.
   • Preventing trains from getting too close together requires something like reservations.

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

• One at a time.

Starting the next train

1. Start it slowly, you don't know where it is.
2. When it hits a sensor
   • make a prediction about the next sensor it will hit
   • get permission, probably a track reservation, to travel beyond the next 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

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

1. A train is about to enter block n, holding a reservation from block n-1 to block n+x.
   • x must be big enough that if the train starts to stop now it will not go beyond block n+x
   • but it might be bigger.
2. Must the train extend its reservation right now? Yes, unless it can some time in the future
   • request a reservation &
   • get a response &
   • stop before the end of its current reservation if the response is no.
3. How much should the train request?
   • Enough that its next opportunity to make a request fulfills the conditions immediately above.
4. The reservation server might provide only part of the reservation a train requests. If so, what should it do?
   • Travel at a reduced speed so that it can stop if it can't extend the reservation on the next occasion for a request.
5. First, suppose that the train will continue travelling at the same speed, s.
   • Then it will be travelling at the same speed when it enters block n+1
   • If it goes to train zero at the beginning of block n+1 where will it stop.
   • Say, before the end of block n+y, which you calculate using your calibration.
   • Necessarily, y >= x.
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'
   • Necessarily x <= y' < 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.
   • Suppose the answer is r.
9. Check using your calibration that you can reduce to the steady-state velocity of speed r by the beginning of block n+1.
   • You necessarily can by setting the speed to zero.
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?

• When an engineer takes over a train he/she is given printed orders that include the length of the train.
• There is a resetable counter in the locomotive that count the revolutions of the locomotives wheels
• When the locomotive passes a switch the engineer resets the counter.

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:

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