CS452 - Real-Time Programming - Spring 2015
Lecture 26 - Reservations, aka Collision Avoidance.
Public Service Annoucements
-
Train Control I demo on Wednesday, 8 July.
-
The exam has three start times.
-
20.30, August 4
-
09.30, August 5
-
20.30, August 5
The end times are 26.5 hours after the start time.
Answers to questions asked from 20.30, 4 August to 22.00,
4 August will be answered on the newsgroup, whether they
arrive by e-mail or on the newsgroup.
Multi-Train Control
By the next milestone you will be able to control two trains at
the same time.
Sensor Attribution
Route Finding and Following
Collision Avoidance
Treating the track as a shared resource
A track server gives out and takes back pieces of track.
What policy should it have?
-
Trains can only occupy track they have obtained from the server.
-
Trains can operate on track they have obtained from the server.
In practice "operate on" means "switching turn-outs".
-
The server never gives out pices of track that are already out.
-
To avoid leapfrog deadlocks, all the track owned by a train must
be contiguous.
-
Track should be returned to the track server as soon as a train
leaves it.
The first three are necessary for correctness. Are they sufficient?
The fourth avoids a common bug. The fifth both avoids bugs and
improves performance.
Reservations
Somebody has been doing something right for over a 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
- Train asks dispatcher for a route
- Dispatcher provides a route that he/she thinks to be conflict free
- Train follows the route, reporting back to the dispatcher as landmarks
(sensors) are passed.
- The dispatcher gets two reports
- One from the track hardware
- One from the engineer
-
It is up to the dispatcher to make certain that they do not
conflict.
-
What is communicated to the train driver by the coloured
lights you see along the track
Lower Level
The lower level is also communicated by the coloured lights. In
cases of conflict between the upper and lower levels, the lower
level overrides the upper level.
- 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 detects a violation of its rules or a state
that should never occur it enters a failsafe mode: all lights
red.
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
- Short routes with much switching
- Single point failures.
There are one or more switches in the path
Implementing the policies.
No over-driving
Here is the sequence of events that occurs when a train stops.
-
The train has enough track to continue driving.
-
The train decides that it needs more track.
-
The train requests track, and is turned down.
-
The train gives a "speed zero" command.
-
The train slows, stopping one stopping distance from where
it gave the
sp 0
command.
If the train is to avoid overdriving its track when does step 2
occur?
Operating reserved track
How much must be controlled to ensure that this constraint is
respected? Try listing all the things that might go wrong? Are
willing to trust the train driver?
Single owner
Something atomic, presumably a server, has to control who has
what track.
No leapfrog deadlock
The server can control this. Or the server can be less smart and
assume that input from the train is reliable. Then the train
driver must be programmed to asked for pieces of track in the
right order.
Returning reservations
Based on past history train drivers very commonly make errors
when giving back reserved track. But once they have the track
it's hard to get it back from them.
In the past students have experimented with timed reservations,
where the reservation is reused, like it or not, when its time
has expired. Results have not been good. How can a server be sure
that a train driver can exit a reservation before a pre-specified
time? How can a train driver figure out that it won't leave in
time, and if so what can it do?
Return to: