CS452 - Real-Time Programming - Spring 2010
Lecture 27 - Reservations
Public Service Announcements
- Due date for Tracking 1
- Wednesday, five days from today.
- Bring your documentation to class.
- Fraser's back.
Reservations
Somebody has been doing something right for the last century. The answer
is reservations.
Two Level Train Control
The two levels are completely independent of one another.
- On heavily used sections of track the lower level is done completely by
hardware with no possibility (almost) of human intervention
Upper Level
Objective
Engineer receives instructions.
- What must be done, if all goes well, to arrive at the destination.
- Engineer follows instructions, if possible.
- When the instructions cannot be followed, the engineer requests further
instructions
Method
- Train asks despatcher for a route
- Despatcher provides a route that he/she thinks to be conflict free
- Train follows the route, reporting back to the despatcher as landmarks
(sensors) are passed.
- The despatcher monitors progress on the basis of ongoing reports
from two sources
- The hardware
- The engineer
Train and despatcher interact frequently in the real world,
infrequently in your train application. Why?
- Humans are good at inferring unexpressed information.
- Computers are terrible at inferring unexpressed
information.
- Aside. This is what makes programming hard!
- It is up to the despatcher to detect inconsistencies in the two
sources of information
- Inconsistencies detected = `The train is lost.'
- Hint. Figure out which inconsistencies you can recover from.
- Order them in order of difficulty of recovery.
- Implement them in that order
But, if you are really ambitious you know that
- The need for recovery often indicates a shortcoming in the
overall design.
- If your plan is to improve the overall design, implement them
hardest first.
Lower Level
The lower level is encoded in the coloured lights you see along the
track
- Everything is rigidly enforced by hardware
- The human enters the loop only in that the lights tell the engineer
what he/she is allowed to do
- The engineer loses his licence, FOREVER, if he/she ever goes
through a red light.
- If the system ever gets something it doesn't understand, it enters a
failsafe mode
Here's how it works
- Train asks reservation system for several blocks of track
- 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.
- In practice this means:
- If all is clear, the train will travel at the same speed until
it makes a new request before the beginning of the next
block.
- At that point it will make a new request, and if that request
is not granted, then it must be able to stop without passing
beyond already reserved track
- In practice you would grant reservations as follows:
- Train is about to enter block n, and is holding reservations to
block n+x, where
- x is defined so that if the train goes to speed zero now it
will stop before the end of block n+x
- 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.
- Try to reserve to n+y: if sucessful keep travelling without
reducing speed, i.e. at speed s..
- If unsuccessful reserve as much as you can: say to the end of
block y'
- 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.
- 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.
- 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.
- Complete this before you enter the next
block.
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
- One train following another
- Two trains on a collision course
- There are one or more switches in the path
Feedback Control
Control Concepts
- System to be controlled
- Kinematic equation(s)
- Example: dx/dt = v(t)
- Time-dependent variables to be controlled
- Example: x(t), where we are at any moment
- x(t) = x(0) + \int_0^t v(t') dt'
- Control parameters
- Example: v(t), how fast we are going
- What if we are not able to change velocity instantaneously?
- Objectives (goals)
- Example: x(t) = v(t) = 0 at t = t0
- Commonly there is another objective such as minimizing the action:
A = \int_0^t0 a(t')^2 dt'
- Control algorithm
- Example: v(t) = B(t-t0), with B chosen to realise the objective.
- x(t) = x(0) - B t (t-2 t0) / 2
- x(t0) = 0 => B = 2 x(0) / t0^2
- This solves the control problem, in theory
Fundamental Problem is Noise
We try to set the velocity as we wish,
- But, really v(t) = B(t - t0) + e(t)
- e(t) certainly is not known, and is often stochastic
How do we tame noise?
- Measure the real position, y(t), as often as we can
- Modify the velocity to reduce y(t) - x(t), the difference of the
desired position from the real one.
- Example: v(t) = B(t-t0) - C(y(t) - x(t))
Suppose we can measure continuously and instantaneously. Then
- Set v(t) to calculated v(t) plus u(t), where
- u(t) = d(y(t) - x(t)) / dt = - C(y(t) - x(t))
- y(t) - x(t) ~ exp( -Ct ), and the difference is always being reduced.
- ( This equation was solved by hypothesizing a solution of the form
exp( -at ) and solving for a.)
This looks pretty good, BUT
There is always a Time Lag
At time t, we really know y(t-D), where D is an inevitable time lag. Now
what happens?
- u(t) = d(y(t) - x(t)) / dt = - C(y(t-D) - x(t)). This is pretty
intractable.
- However, we should know the lag, or the average lag, or whatever, and
we can solve
- d(y(t) - x(t)) / dt = - C(y(t-D) - x(t-D))
- Hypothesize a solution of the form exp( -zt ) and solve for z
- We use z because the solution might be complex
- If complex, the imaginary part oscillates and the real part is
exponential.
- z = C exp( zD ) or log(z) = zD + log(C)
- What is the solution?
- Draw a graph of the real part.
- Sometimes there is no real solution
- We can always find a real solution by making C close enough to
zero.
- You have experienced this in user interfaces, and
- sometimes you just can't slow down enough for the experience to be
tolerable.
The solution is Predictive Control
Change step 3 to
- d(y(t) - x(t)) / dt = - C(y(t-D) + Dv(t) - x(t)), which is close to
d(y(t) - x(t)) / dt = - C(y(t) - x(t))
- And we are back to a solution we like.
There are whole textbooks about different ways of doing predictive
control; there are whole journals with articles describing new ways of doing
predictive control.
Using predictive a little loosely, predictive control is what you are
doing.
Return to: