CS 452/652 Winter 2024 - Lecture 19

Train Control

Mar 19, 2024 prev next

better to avoid manual entry of initial train position: easier, more robust
simple strategy: move slowly until first sensor trip
You can make assumptions about where trains are initially placed
- the weaker the assumptions, the better
for TC2, avoid manual entry
use headlights to (manually) detect train's orientation during initialization

being able to quit your program - and restart without reload, without reboot
- good for demos, but also helps development
reset track & trains at start and stop
- use emergency stop (speed level 15) at end or failure
always/periodically check for emergency exit key

computation / loop with easily verifiable results
high register coverage
use subroutine, recursion (to a limit)
trigger frequent timer interrupt
- randomized timeout
- interrupt handler (kernel): perform similar computation
- clobber as much state as possible
test with and without optimization

repeat speed measurements as kernel testing method
- should see similar measurements
test reliability of train commands
- speed variation and timing
- change direction and verify using sensors
- add lights on/off to increase command intensity

develop independent control components from the bottom up!
start from track server representing current state of track (turnouts)
1. train tracking
2. collision detection
3. reservations
4. routing

sensor hit is either
- train - which one?
- spurious
keep track of expected sensor, expected time of trigger
- train N, time T +/- error margin
  - error margin not necessarily symmetric
  - velocity estimate
  - sensor reporting latency

sensor errors:
- unexpected sensor is triggered
- expected sensor is triggered too soon
- expected sensor is not triggered within error window (timeout)
multiple possible causes for each error
- triggered too soon?
  - hardware failure: spurious or missing trigger
  - timing failure: inaccurate prediction
- try to tolerate at least a single hardware failure
  - in case of error, track multiple possible next events to disambiguate the error
- tracking train on route, next sensor is S, next next sensor is S'
- failure for S → wait for S' to disambiguate
- can handle switching failures using the same framework
  - If planned route sets switch straight, also monitor next sensor in curve direction and vice versa.
- handling multi-errors
  - during testing, treat as critical
  - during demo, continue and hope for the best?
simulate failures!
- drop switch command
- drop sensor read
- fake sensor read
- see for example Netflix Chaos Monkey

immediate: stop, reverse, wait, try again
- use randomization to avoid deadlock: exponentially increase wait time?
planning: reservations

reservation system: full-path vs. on-demand
granularity? segments between switches
planning horizon?
- consider speed and stopping distance
- topology (potential for evasion)
- trade-off: safety vs. efficiency
reservation failure
- wait and/or re-route
direction of conflict?
- stationary obstacle → reroute
- same direction → slow or stop
- head-on → likely reroute
deadlock detection
- cycle checking in wait-for graph
- timeout
deadlock avoidance
- prioritize trains?
- resource (segment) ordering?
- must lock in resource order!
time-domain locking
- plan predicts zones that will be needed, and when
- reserve segment from time t₁ to t₂
- allows for advance reservation for entire route
- train control slows/stops train to ensure that it does not arrive too early/late
- quickly gets complicated

shortest path routing is often presented as optimal
but not always the best choice → bottlenecks!
common optimisation criterion required for consistent path computation
- from the perspective of different nodes, especially in distributed setup
run Dijkstra algorithm only for branch nodes
use overlay data structure for reservations and faults
- find path using track \ reservations
consider online routing vs. offline precomputation