CS 452/652 Fall 2022 - Lecture 16
Nov 8, 2022
Train Modelling (cont'd)
- special case of deceleration
- manual experiment
- send stop command when sensor is triggered
- manually measure stop distance
- compute using acceleration model
- experiment with two sensors close to each other?
- experiment by trying to stop right after sensor
- use search algorithm to find right time: could be automated
- stop time + velocity → compute stop distance?
- search algorithm (e.g., binary search) might be brittle and need many experiments
- special case of acceleration
- measure based on known estimate for stop time/distance
- stop at known location, then start
- measure time to sensor
- can compute acceleration
- similar caveat as acceleration measurement: did train reach target velocity?
- stop before reaching target velocity
- manual experiments with different (short) times between start and stop
The material covered in class should be sufficient for train modelling.
However, during the past years, various documents have described train
modelling and calibration in the context of CS 452/652. The various
versions are made available here with the caveat that they might or might
not be helpful:
The Kinematics of Train Calibration (2017)
The Kinematics of Train Calibration (2015)
Reverse Engineering Acceleration/Deceleration(2011)
- think of program as graph
- computation & termination vs. control/service loop
- control/service loop: throughput vs. latency
- timing of edges: busy vs. block
- throughput: compare average busy cost of paths to offered load / arrival rate
- latency: take into account busy and blocked cost
- no balancing between lower and higher latencies
- service loop: outliers change mean - potentially skews utility
- late response is useless, regardless of how late
- control loop: mean masks outliers - potentially hides catastrophic problem
- how often a train enters a critical track section matters more than how much it overshoots
- analysis must work with latency distribution
- service loop: high order percentile (tail latency)
- control loop: worst-case latency
- rare exceptions where average latency is relevant
- worst-case execution time (WCET)
- identify (safety-)critical paths or worst-case execution path (WCEP)
- busy: memory pipelining/caching/sharing effects?
- cache: no miss, one miss, all misses -> reality?
- block: contributes to latency, but not throughput
- internal loops - bounds?
- standing queue - contributes to latency, but does not affect throughput
- queueing theory: latency increases as arrivals approach capacity
- cannot "save" capacity during low-arrival times for later high-arrival
- static analysis: NP-hard
- experimental measurement: no worst-case guarantee!
- hybrid: measure single feasible paths (SFP) & analyze combination
- automatic analysis: loop counts, recursion depth? needs bounds/annotations
- preemptive scheduling: shortcut to loop start
- small tasks: shorter graph edges
- critical path: sensor event → action → effect
- preemption: keep uninterruptible kernel execution short!
- priorities: support resource management via scheduling
- priorities are a mechanism to organize various components of a computer system
- critical path: sensor → uart → supervisor → engineer → track → uart → command
- plus requisite notifiers, couriers, etc.
- critical path? everything is important! what can be bumped down?
- computation such as routing and path planning?
- at low utilization: priorities not as critical
- priority determines worst-case latency
- low-level tasks: low priority could loose interrupts or input
- use higher priority and/or buffer
Reminder: Train Control Caveat
- track interface is half-duplex
- alternate between reading requested sensor data and sending commands
- train control commands delay sensor loop - options:
- single-bank 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?
- participants: demo group, instructor, teaching assistant
- 45 minutes, roughly 3 parts of 15 minutes max
- no requirement to fill the 15 minutes alloted time!
- software deadline as given in the assignment description: Wed 9am!
- you are in control → stay in control!
- get back in control, if necessary: harrumph, set up next demo, speak louder!
- compe prepared
- don't leave dead air
- two students: one presenter, one operator
- switch roles at some point
- for each step of the demo:
- before: explain what is going to happen and why
- during: point out what to pay attention to
- after: provide more details, if necessary
- take into account knowledge of audience
- general knowledge and experience with subject matter
- no detailed knowledge about your particular project, difficulties, trade-offs, etc.
Part 1 - scripted
- plan what you are going to do and who will do it
- know which parts of your program working and only show working parts
- explain what does not work
- if necessary, show partial functionality using different programs
- think about timing and specific phrases you want to use
- despite your best preparations, things might still go wrong...
- prepare to explain:
- what does a particular part of the demo show?
- where will the train(s) go? why?
- what does train motion show about your speed calibration?
- what is the operator doing at the terminal? show us!
- what parts of the demo are done automatically vs. manually?
- increase chances for success
- dry-run entire demo
- keep copy of working executable
Part 2 - unscripted
- we might ask questions, such as
- can you do this with another train?
- can you do this on the other track?
- can we fake sensor triggers?
- can the train go to this or that location?
Part 3 - discussion & code review
- be prepared to explain and justify your design and coding decisions