CS 452/652 Winter 2020 - Lecture 27

Mar 13, 2020 prev

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

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?

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
same-direction of conflict

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

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