CS452 F23 Lecture Notes
Lecture 13 - 26 Oct 2023

1. Train Control System

For A0, dedicated control loop for simple interactive control
- hard to generalize
  - jobs need to be split into small (single iteration) pieces
  - need to keep track of many jobs-in-progress in the main loop
May have generalized this for K4 by moving jobs into OS-implemented tasks

Sends request for work (e.g, to server), waits for reply with work assignment
performs work, which might or might not involve blocking
Sends result (e.g, to requesting server), waits for reply with new work assignment
Stays blocked on Reply, unless there is work to do

imagine design at task level
- task responsibilities
- task pattern
- call graph

SensorReader (notifier)
- waits for incoming data on UART3, sends the data
- implementation involves some combination of
  - reading data from UART
  - polling or awaiting RX interrupt from UART
CommandWriter (worker)
- request is command to be issued, response acknowledges issue
- implementation involves some combination of
  - writing commands to UART
  - awaiting CTS interrupts
Alarm (notifier)
- sends periodic messages to indicate passage of time
- implementation is Send to Clock Server, or directly Await timer interrupts
TrackMonitor (server)
- receives requests to perform track/train commands, and requests to wait for sensor events
- issues commands or polling requests workers
  - enforces half-duplex and one-command at a time
- perhaps tracks sensor triggers
TrainDriver (worker)
- request is to execute a “train plan”
  - for TC1, maybe series of switch commands, train start command, and series of expected sensors/times, train stop command
  - sends commands, sensor requests to TrackMonitor
  - can abort plan early in case of unexpected behavior, reports plan result
Shell
- blocks on input from CONSOLE
- offloads work to planner, TrainDriver
Planner (worker)
- request is objective, result is a plan

from Sending the CommandWriter a request to receiving the reply
assume CommandWriter is highest priority server
latency includes
- SRR for request (includes a CS)
- request write
- Await interrupt (for CTS) - interrupt handle and another CS (unblock)
variability:
- we can assume CommandWriter runs immediately after interrupt, because it is highest priority
  - otherwise, we need to consider additional delay due to higher priority task(s)
- interrupts might occur while CommandWriter is running?
  - can try to estimate/bound number
  - this is why we want interrupt handling to be fast and predictable!
might need to measure primitive steps
- have already measured SRR, including CS
  - see unoptimized measurements and optimized measurements from K2 assignment
- easy to measure command writing time, by polling/being interrupted by CTS
- measure interrupt overhead?
  - in the kernel, using always-asserted interrupt, count and measure N occurrences

TrackMonitor sends poll command to CommandWriter, then waits for data from SensorReader, records result in memory
- we’ve already estimated time for command execution
- after command executes, Monitor needs to wait for data message from Sensor Driver
  - need to estimate time for sensor driver
  - in addition, when sensor message arrives at TrackMonitor:
    - TrackMonitor might be busy handling another request
    - Additional request messages might be waiting ahead of sensor report
- even when data message is available, TrackMonitor may not be running, depending on priorty
Strategy:
- try to estimate best- and worst- case times, using application knowledge
  - e.g., at most one message from CommandDriver, at most one from TrainDriver
  - what higher-priority tasks could be runnable?
    - utilization of high-priority tasks can be useful for this!