CS 452/652 Spring 2025 - Lecture 19

Train Control

July 10, 2025 prev next

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

being able to reset your program - and restart without reload, reboot
always/periodically check for emergency exit key
at the end (reset/abort) - stop all trains with emergency stop (speed level 15)
- stop train control with command 0x61

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 (CTS)
- 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. track reservation / collision avoidance
3. routing / path finding
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)
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 multiple 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

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!
- 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
use overlay data structure for reservations and faults
- find path using track \ reservations
consider online routing vs. offline precomputation