CS452 - Real-Time Programming - Spring 2017
Lecture 25 - Multiple Trains
Public Service Annoucements
-
Train Control II demo on Tuesday, 18 July.
-
The exam will start at 19.30, July 28, 2017 and finish at 22.00,
29 July 2017.
Multi-Train Control
By the third 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
There is a good analogy with the X server providing parts of the
display to different processes. The division into parts is dynamic
as windows are opened, closed, moved, resized and so on. Some of
these actions are initiated by the process that requested the
server to open a window; others, such as the window being partially
occuded by another window are invisible to it. Occasionally the
server sends a message to the process asking it to do something,
such as repainting the window.
A track server gives out and takes back pieces of track. Pieces
can either
-
Discrete: the track is split into a finite set of resources,
almost always static; or
-
Continuous: the track is divided up into variable-sized
pieces as needed.
Policy
Collision avoidance is the goal. We want a policy that controls
how the track server gives out track, and how the train uses the
track that it gets. The policy should have two properties.
-
Its should be easy to convince yourself that the policy
prevents collisions.
-
The policy should be easy to implement, taking into account
the real properties of the trains and the track. This is the
hard part.
Here is an example of a typical policy.
-
The server ensures that zero or one train owns each section
of track.
-
A train may only occupy track that it owns.
-
A train can only operate on track it owns. In practice,
"operate on" means "switching turn-outs".
-
Track should be returned to the track server as soon as a
train leaves it.
-
When a train slows or stops it may have track reserved ahead
of it that it will not use in the immediate future. Such
reservations should be returned to the track server.
-
To avoid leapfrog deadlocks, all the track owned by a train
must be contiguous.
Items 1 and 2 ensure that no collisions occur. Item 3 ensures
that the state of track owned by a train is never changed by
another train. Item 4 allows trains to drive on the same piece
of track, albeit at different times, so that the demo continues.
Item 5 improves performance. Item 6 saves us from the leapfrog
bug, which is surprisingly common in practice.
There are many successfully policies. You only need one, but make
sure that you understand the properties of the policy you use.
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. The upper
level determines which track is given to trains; the lower level is a
set of rules that a train driver must obey when driving.
Upper Level
-
Train asks dispatcher for a route.
-
Dispatcher provides a route that he/she expects 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. Real conflicts are usually emergencies.
-
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 and test your reservation policy before you start to
implement it.
Before starting to implement 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 failures of sensors and switches
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 than it currently
has.
-
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
need to occur?
Operating reserved track
A few questions to think about
-
How much must be controlled to ensure that this constraint
is respected?
-
Try listing things that might go wrong?
-
Are you willing to trust the train driver code, especially
its real-time aspect? The problem occurs when the train is
too close to the switch when the command to throw it is given.
Some implementation like to have thw switch do the checking
rather than the train driver. Why?
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. (Off by one errors are extremely
common.) It's not hard for a track server to figure out that a
train driver should have given back a section of track, but how
to you get it from them.
Reservations can easily get fragmented because of bugs in the
track returning code. Make sure that doesn't happen.
Timed Reservations
In the past students have experimented with timed reservations,
where the reservation is returned, whether the train driver likes
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: