CS452 - Real-Time Programming - Spring 2012
Lecture 26 - Demos, Reservations
Public Service Annoucements
- Final exam date
- Comments from yesterday's demo
- We had a positive impression
- It is normal for groups to be a different levels, because it is
unpredictable when the 48 hou and 72-hour bugs will appear
- Remember that this milestone had three discrete parts
- Knowing the stopping distance
- Knowing where the train is when travelling at a fixed speed
- Knowing where the train is when accelerating and
decelerating
- There were a variety of ways for doing accel/decel
- All the ones we saw will work
- We don't know enough to assess how time-efficient different
approaches are.
- There is a workaround for acceleration/deceleration that works
pretty well
- Try using one dynamic parameter to tune all the other parameters
- Normalized units are very helpful here
- A good UI shows you a lot of information that is useful when
something funny occurs
- E.g. a turn-out switches under a traveling train
- Was the train ahead of its calibration? Or was the switch
command given too late?
- Some groups had demos that seemed unsatisfactory because everything
was 80% done
- Some things we saw may give problems when you have more than one
train on the tracks
- Setting all the switches at once
- Refinding the train as standard operating procedure
- Not keeping track of train position as it is stopping
Sensor Attribution
Predictions work fine once you know where the trains are. How do you find
them at the beginning?
- Easy when there is only one train on the track
- Move it very slowly until you encounter a sensor, now you know
where it is
- Not a bad idea to get a second sensor to confirm direction.
- Hard when there is more than one train on the track
- To which train do you attribute the next sensor hit
- Trains may collide before they are found
How might you do this for multiple trains?
Starting the next train
- Stop the previous trains in convenient places
- Start start this train slowly, you don't know where it is.
- 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
- 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 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
- **Every train must have a reservation for the track it occupies.
- **Every train must travel at a low enough velocity that it can stop
before the end of the track it has reserved.
- **Every train should reserve enough to handle single sensor or
(exclusive) single switch errors.
- **No piece of track should ever be reserved by more than one train.
Soft Conditions
Needed to keep the trains moving
- 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.
- Every reservation held by a train should be contiguous
Who enforces these conditions?
- Nobody does so explicitly.
- There are several constraints
- The reservation server always gives out reservations that are
contiguous.
- The reservation server never gives out an already reserved piece of
track.
- The reservation serve never revokes a reservation.
- 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?
Here's how it works in theory
- Train gets a route from the route finder, and looks ahead along the
route.
- Train has a desired speed.
- 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.
- 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
- 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.
- Each time the train leaves a block it frees the reservation it had for
that block.
- Before reaching the end of the blocks on which it can travel at speed,
it requests an extention of its reservation.
- 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.
Reservation Implementation
You might grant reservations as follows:
Every time a train receives a sensor report it does its reservation procedure
- Release the reservation I just vacated
- If I give a stop signal at the next sensor can I stop within my
reservation?
- If yes, finished
- If no, how much do I need beyond my current reservation?
- 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.
- Reservation server gives as much as it can
- Train rechecks stopping condition using the complete reservation.
- If yes, finished
- If no, stop, or slow down so that the stopping condition is yes.
Return to: