CS 452/652 Winter 2020 - 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

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

Real-Time Characteristics

• real-world timing constraints
  • upper bound - don't be too late
  • lower bound - don't be too early
  • synchronous/periodic processing: timer → action
  • asynchronous processing: event → action
• worst-case execution time (WCET) between trigger and action
  • resource management - priority
    • generalization: scheduling (cpu, network, disk)
  • bounded (low!) latency - preemption
    • keep uninterruptible kernel execution short
  • analysis: measure, declare, combine latency components

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

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