- Due date for Tracking 1
- Wednesday, five days from today.
- Bring your documentation to class.

- Tracking 1 description

The hardest problem to solve

- You just don't know what is possible
- Ask a question like:
- Is my kernel code at the limit of what is possible in terms of performance?
- We can compare the performance on message passing, etc., because
two kernels are pretty much the same.
- Compare a lot of kernels and you should be able to find a lower limit

- Can't do the same thing for train applications

The hardest thing to get right

- Sizing stacks used to be harder, but now we have lots of memory
- But last term, ...

- NP-hard for the human brain
- Practical method starts with all priorities the same, then adjusts
- symptoms of good priority assignment
- The higher priority, the more likely the ready queue is to be empty
- The shorter the run time in practice the higher the priority

Problems with priority

- Priority inversion
- One resource, many clients
- Tasks try to do too much

- Too many tasks
- blocked tasks don't count,
- lowest priority tasks almost don't count

- Layered abstraction are costly
- e.g. Notifier -> SerialServer -> InputAccumulater -> Parser -> TrackServer
- With the hardware you have this occurs only when you start passing around big messages.

- Access to the train controller

- Turn on optimization, but be careful
- There are places where you have done register allocation by hand

- Turn on caches
- locking is possible

- Size & align calibration tables by size & alignment of cache
lines
- linker command script
- I think that this is stretching it.

Somebody has been doing something right for the last century. The answer is reservations.

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

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

- 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 undetected = `The train is lost.'

- Hint. Figure out which cinconsistencies 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.

- The despatcher monitors progress on the basis of ongoing reports
from two sources

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
- All lights go red.

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'
- Necessarily x <= y' < 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.
- Suppose the answer is r.

- 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.**

- Train is about to enter block n, and is holding reservations to
block n+x, where

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.

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

- 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

- Example: v(t) = B(t-t0), with B chosen to realise the objective.

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

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.

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: