The nice thing about the static generation, you can use it to calibrate if you are aware of a slippage or deviation in a calc - known fixed input should generate a known, fixed output.
Your idea of the different profiles would support a more Arduino-based perspective. Then you could code in profiles like start, acceleration, running, coasting - something that more closely represents a "real world" experience.
I claim the "version 1" clause then on the simple calibration with a simple fixed rate for the device. Can it produce an accurate display with a fixed set of inputs? That way there is a baseline from which to adjust/adapt the overall solution.
Thinking forward to v1.5+ a more broad testing input may make more sense. At least it would be a constant, not varied based on a individual auto setup or scenario.
It would not be a replacement for real world validation, but hopefully get it closer before the real world intervenes - I'm thinking Murhpy here!
__________________
|