CS 452/652 Winter 2024 - Lecture 12

Train Velocity, Design Approach

Feb 15, 2024 prev next

SRR Performance

• effect of programming details
• effect of compiler optimization
• effect of i-cache
• no effect of d-cache

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 each way
• at speed of 0.5m/sec, this corresponds to 3cm
• use averaging (and deviations) to deal with uncertainty
  to be revisited...
• store raw, not processed, data!

Data Representation

• word length 64 bits
• no floating point!
• if necessary, use fixed-point integer instead
• avoid integer rounding: a / (b / c) = (a * c) / b
• but also consider overflow: (a * c) / b = a * (c / b)
• compute human-readable numbers for presentation on screen

Metrics

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

Server Patterns

• proprietor: restricted server (restricted logic)

  • controls access to backend server(s)
    • e.g. train/terminal server vs. UART server
  • 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 (via workers)

Suggestions

• build small independent control "circuits"
• 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 or via library proxy):
    Message passing between sequential processes: The reply primitive and the administrator concept