CS 452/652 Winter 2020 - Lecture 27
Mar 13, 2020
- 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?
- 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?
Collision Avoidance - Detection
- 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
Collision Avoidance - Reaction
- avoid deadlock
- direction of conflict?
- same direction → slow or stop
- head-on → reroute
- 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
- integrate everything via reservation system?
- or combine independent components?