CS 452/652 Winter 2026 - Lecture 18

Train Control

Mar 12, 2026 prev next

computation / loop with easily verifiable results
high register coverage, stack dynamics
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/track commands
- vary speed level and verify/update timing
- change direction and verify using sensors
- add lights on/off to increase command intensity

initialize all turnouts and trains
use headlights to verify train's orientation
- and detect dead spots
make assumptions about where trains are initially placed
- weaker assumptions are better
auto detection? move slowly until first sensor trip
- dedicated entry lane / order?

develop independent control components from the bottom up!
start from track server representing current state of track (turnouts)
1. train tracking / collision prediction
2. track reservation / collision avoidance
3. routing / path finding / collision resolution
4. on-demand turnout switching

sensor hit is either
- train - which one?
- spurious
keep track of expected sensor, expected time of trigger
- train N, time T +/- error margin

sensor errors:
- unexpected sensor is triggered
- expected sensor is triggered too soon
- expected sensor is not triggered within error window (timeout)
  - ignore timing sample
multiple possible causes for each error
- 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 multiple errors
- during testing, treat as critical
- during demo, continue and hope for the best?
simulate failures in CAN server
- drop switch command
- drop sensor read
- fake sensor read
- see for example Netflix Chaos Monkey

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 reroute (randomly?)
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!
- use randomization to avoid deadlock: exponentially increase wait time?
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
consider online routing vs. offline precomputation
use overlay data structure for reservations and faults
- eliminate known problems (hardware failures)
- temporarily remove existing reservations

decouple stopping from sensor hit
- estimate stopping time as good as possible