CS 452/652 Winter 2022 - Lecture 25

TC1 Demo Review

• importance of robustness increases between TC1 and final project

Start/Stop Robustness

• being able to quit your program - and restart
  • without reload
  • without reboot
• good for demos, but also helps development
• initialize BSS
• initialize data
• keep constants for initialization
• always/periodically check for exit key

Other Notes

• use headlights to (manually) detect train's positioning during initialization
• use sensors to detect trains location and travel direction
• double-check kernel mechanisms: message passing & context switch
• double-check UART servers and interrupt handling (including CTS)
• double-check priorities
• double-check main bottleneck: serialization at half-duplex COM1

Interrupt Strategy

• objectives
  • avoid interrupts: performance and control
  • avoid buffering in kernel
• clock/timer: interrupts always needed
  • can count interrupts and deliver via AwaitEvent
    • expectations and error checking?
    • make clock server not the highest priority?
• UART: TX interrupt cannot be always on
• TX interrupt for every send? unnecessary...
• loop: try-send → enable interrupt → wait
• can still buffer characters in user-level
• RX interrupt?
  • think of tight loop: RX arrival → response needed → RX next arrival
  • make receiver notifier lower priority than response tasks: track vs. terminal?
• think about layered safety?
  • emergency stop (speed 15); regular stop (speed 0); collision avoidance
  • also for speed re destination & collisions

Train Control Objectives

• travel at constant speed level
  • can recalibrate velocity estimate
  • optional: 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
• fault resilience - handle one faulty part
  • fault testing? example: Chaos Monkey

Routing

Notes

• 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
• mid-travel reverse - relevant for merge nodes (and begin/end)
  model as extra link → augment track data

Path Finding

• online: on-demand routing?
  • compute path using track \ reserved route
  • single-node Dijkstra (overlay) is probably doable online
• offline: determine loop-free alternative path with loop threshold!
  • loop-free: take other edge, then remove turnout from consideration
  • or take loop to get out of the way