CS 452/652 Winter 2026 - Lecture 12

Software Design and Train Timing

Feb 12, 2026 prev

Software Design

• Basics
  • each problem presents a complexity floor
    • how many inputs?
    • timing requirements?
    • computational complexity?
    • load & performance requirements?
  • no software design/engineering in the world can produce a simpler solution
    but: it is possible to screw up and build an unnecessarily complex solution!
• Objectives
  • performance → maximize concurrency
    • control → priority scheduling
    • responsiveness → watch your idle time
  • correctness → deadlock avoidance
  • simplicity → use simplest possible patterns!
• Patterns - semi-automatic reasoning about software
  • dimensions:
    • control flow
    • concurrency
    • communication
    • synchronization
  • patterns must be restrictive to be useful
    • simplicity can only be attained by excluding functionality
    • "It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove."
      Antoine de Saint Exupery
      https://en.wikiquote.org/wiki/Simplicity
• Task Types
  • server: backend logic; only blocks on receive
  • worker: simple!
  • client: application logic; isolating concerns

• Worker Patterns

  • notifier - blocks on events (interrupts)

    for (;;) {
        AwaitEvent()
        Send()
    }
    

  • courier - transmits data between servers

    for (;;) {
        Send(server1, req, msg); // pull from server1
        Send(server2, msg);      // push to server2
    }
    

Specific Server Patterns

• restricted logic, avoid complexity and overhead

• proprietor

  • controls access to backend server(s)
    • e.g. train/terminal server vs. UART server
  • no internal buffering, serial execution
  • can reply before processing request
  • 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

  • interact with multiple clients and other servers (via workers)
  • buffer requests, reorder requests, and/or park clients

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

Speed / Velocity

Basics

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

Sensor Measurement

• unknown measurement error
  • signal latency
  • CS3 processing
  • CAN bus
  • etc.
• RPi software processing delays? hopefully small

Speed Measurement

• velocity = distance / (stop - start)
• constant error in 'stop' and 'start' cancels out
• use averaging (and deviations) to deal with variability/uncertainty
• store raw, not processed, data!

Metrics

• time
  • clock: 1 Mhz
  • 32 bit (CLO) can represent > 71 minutes
  • small numbers: 10ms tick (or 1ms)
• location, distance
  • millimeter 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?)

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 only for presentation on screen