CS 452/652 Fall 2019 - Lecture 22

Velocity (addendum)

• individual sensor measurements are uniformly distributed
• time interval between two sensors is sum of uniform distributions
  • general case: Irwin-Hall distribution
  • special case (N=2): triangular distribution
  • low-frequency sampling (70ms): sample distribution bi-modal (corner cases tri-modal)
• general recommendation: keep experiment raw data as much as possible
  • bug in processing → repeat only processing
  • new approach to data processing → possible with raw data

Kernel Testing

• repeat speed measurements as kernel testing method
  • should see similar measurements
• test reliability of train commands
  • speed variation and timing
  • change direction and verify using sensors
  • add lights on/off to increase command intensity

Train Control Caveat

• track interface is half-duplex
• alternate between reading requested sensor data and sending commands
• other train commands delay sensor loop - options:
  • reduced, fixed sensor queries - budget for train commands
  • add uncertaintly to sensor timing based on number of previous train commands
  • ignore additional error, because it is small

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

Resilience/Timeout

• timeout is a fundamental error detection mechanism
  • general systen: detect failure in communication or remote service
  • real-time system: detect timing violation
    • e.g., based on position and velocity estimate, sensor is expected to trigger during a certain interval
• asynchronous timeout implementation
  • start timeout notifier task(s)
  • what if timeout no longer needed (sensor has triggered)?
  • cancellation quickly becomes complex and error-prone
• synchronous timeout implementation
  • periodic timeout notification
  • keep track of pending timeouts
  • remove timeouts that are no longer needed
  • check (and fire) timeouts upon notification
  • trade-off in period
    • short period: more overhead, lower error margin
    • long period: less overhead, higher error margin
  • monitor idle times and utilization!

Priorities

• priorities are a mechanism to organize various components of a computer system
  • highly-loaded system: priorities determine latency and throughput (importance)
  • lightly-loaded system: priorities determine latency
• sensor → notifier → server → notifier → train control → command → UART
  • which part of the above processing path is less important than others?
  • distingush between unknown delay budget during first half
  • after train control: known delay budget to execute command
• at low utilization: priorities not as critical
• every tasks gets to execute
• use priorties for
  • low-level tasks to avoid loosing interrupts or input
  • background computation (route computation?), if applicable