CS 452/652 Winter 2025 - Lecture 20
Train Control and Software Design Recap
Mar 20, 2025 prev next
Train Control
Though Experiment: Perfect Train Control?
- need exact problem specification, example:
- given a topology, a set of trains, and a list of destinations for each train
→ determine optimal schedule
- but: what is optimal?
- time to last train at last destination?
- average trip duration?
- many other criteria possible
- also: assume error-free operation?
- with exact problem specification
- formulate and solve optimization problem - computational complexity
- centralized computation difficult for many real world control problems
- or: design ad-hoc solution accommodate uncertainty (our approach)
- our goal is not overall perfection (which is not even properly specified), but:
- build interesting multi-task, real-time application
- model decentralized aspects of real-world system
Travel Objectives
- travel at constant speed level
- can recalibrate velocity estimate
- recommendation: slow down before stopping
- travel at specific velocity
- timed adjustment of speed level, verify via sensors
- travel in cohort: multiple trains at specific distance
- adjust one or both trains, verify via sensors
- travel fast, stop accurately
Design Approach
- track server
- query current state of turnouts
- request changes
- train task
- estimate location and predict path
- more below...
- attribution server
- all paths with expected timing
- disregard conflicts
- query interface: <location, time> → train(s)
- collision avoidance server
- short-term travel plans only
- no timing information
- check for conflicts
- routing server
- determine path & feasibility (e.g. short move?)
- take into account track exclusions? query interface?
- reservation server
- continuous reservations (no leapfrogging)
- consider directionality of reservation
- reservation interface: <train, segment, direction> → result
- result: segment available or direction of reservation
- timing information?
- sensor task
- receive sensor reports
- query attribution server
- send notifications to train tasks
- train task
- source/dest → obtain route from route server
- drive train loop
- reserve track segments
- reserve beyond branches
- reservation denied: slow/stop
- invariant: reservation distance > stop distance
- switch reserved turnouts
- core loop
- update/submit travel plan
- set train speed
- request & handle sensor, timeout notifications
- any problem? stop/slow, make new plan (timing and/or routing)
- release track segments
- periodic or sensor-based updates
- leave segment → release segment
- pass turnout → release alternative path
- stop → release rest of path
- conflict resolution:
- contention → back off
- move/avoid conflict zone by changing speeds
- find alternative paths
- computational overhead with more trains?