CS 452/652 Winter 2023 - Lecture 12

Track/Train Measurements

• train control assignments need velocity information
  • preparatory measurements can be taken without full kernel
  • start early before the tracks fill up!
• default turnout setting - use captive loops: small (left/right), medium, large
• middle turnouts: do not set to C/C! (can lead to derailment)

Speed / Velocity

Basics

• speed: train setting 0-14
• velocity: actual travel distance per time
  1. non-linear with speed
  2. different for different trains
  3. different for different parts of track?
  4. changes over time (wear and tear)
  5. two velocities per speed level 1-13 - previous lower vs. higher
• handle at least 1. and 2. by measuring and storing velocity data
  • offline experiments → start now!
  • continuous online measurements?
  • data import/export?

Sensor Measurement

• assume ~60ms continuous sensor polling loop
• unknown (hopefully constant) measurement error
  • train controller box
  • signal latency
  • etc.
• variable measurement error: sensor trigger relative to polling loop → 0-60ms
• processing delays? later... (should be small with dedicated measurement program)

Speed Measurement

• velocity = distance / (stop - start)
• constant error in 'stop' and 'start' cancels out
• maximum variable error: up to 60ms
• at speed of 0.5m/sec, this corresponds to 3cm
• use averaging (and deviations) to deal with uncertainty
• to be revisited...

Data Representation

• word length 64 bits
• no floating point!
• if necessary, use fixed-point integer instead
• avoid rounding errors and overflow

Metrics

• time
  • clock: 1 Mhz
  • 32 bit (CLO) can represent > ~71 minutes
  • small numbers: 10ms tick
• location, distance
  • millimetre granularity sufficient
  • longest short path (without reverse): ~10.5m ⇒ no problem
  • keep in mind: size of train, location of pickup!
• velocity
  • distance in mm; velocity in mm/s
  • distance/velocity? fraction of second → scale up / rearrange

Server Patterns

• proprietor: restricted server
  • controls access to backend server(s)
  • no internal buffering, serial execution
  • can reply before processing request
  • if exclusive client to back-end server: can use Send()

  for (;;) {
    Receive(msg)
    SyncProcess()  // possibly interact with back-end server
    Reply()
    AsyncProcess() // possibly interact with back-end server
  }
  

• administrator: general server
  • reorder requests, buffer requests, and/or park clients
  • interact with multiple clients and servers

Suggestions

• build small independent control loops
  • localized location estimate vs. route-based location estimate
• deadlock avoidance
  • avoid circular send
  • avoid circular receive
  • ⇒ do not mix Send() & Receive() in same task!
    • notwithstanding exception in proprietor pattern (see above)
• higher concurrency through more smaller tasks
• modularity → lower complexity through more smaller tasks?
• possible reference design: one design idea - not necessarily perfect!
  • early paper (accessible from UW IP addresses):
    Message passing between sequential processes: The reply primitive and the administrator concept