CS 452/652 Winter 2022 - Lecture 26

March 14, 2022 prev next

overall: finish trips as fast a possible
technical objectives
- route finding
- robust sensor attribution
- collision avoidance
indirect objective: on-demand turnout switching

offline: precompute (some) routing information at system startup
- including knowledge about track deficiencies
finish path computation online
- e.g. Dijkstra previous hop tracing
- e.g. find alternative routes
on-demand routing: compute entire end-to-end path online
- including knowledge about other planned routes
- single-node Dijkstra feasible
on-demand conflict resolution

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

error: unexpected sensor is triggered
error detection critically depends on assumptions
here: assume at most one failure, not two in a row
- can observation be explained by a single turnout failure or a single sensor failure?
spurious sensor hit?
- testing: treat as critical error
- demo: ignore and hope for the best
enhanced error model?
- one error → (detected by attribution) recover
- two errors → (detected by timeout) abort
- anything else → spurious/ignore?
broken turnout complicates matters...

direct: check other trains
indirect: use reservation system (server)
full-path vs. on-demand reservation and release
planning horizon?
- consider speed and stopping distance
- topology (potential for evasion)
- trade-off: safety vs. efficiency

avoid deadlock
direction of conflict?
- stationary obstacle → reroute
- same direction → slow or stop
- head-on → reroute

avoid switching turnout while train passes
integrate with track reservation system?
or indepdent switch protection layer?
- block turnout during travel, treat as (transient) turnout error