I am now waltzing into a short 1-2-3 posting on scheduling. Multi-rate systems exist for two reasons, either the calculations do not need to update frequently, or the calculations take too long to fit them all into one rate. In either case the “offset” is a valuable tool.
Lets take the hypothetical case of a 3 task system
- Task 1: Runs at 0.2 sec rate
- Task 2: Runs at 0.4 sec rate
- Task 3: Runs at 0.4 sec rate
The first way of arranging these would be (a very simple dance with a high probability of stepping on your partner’s toes).
If the total execution time of T1, T2 and T3 is less than your base rate (0.1 seconds here) you are fine but if not, you have overruns. The next option is to introduce an offset (and in this version of the waltz, you have no chance of toe stepping).
In this case, each task is running at a different time and the order of execution is the same (1, then 2, then 3). Everything is good right?
What about incoming data?
When everything runs at the same time step, then everything is using data from the same time step, e.g. T1, T2 and T3 are all using T(0), then T(0.2), then… input data. In the offset case for the first execution it looks like
- T1 uses T(0) data
- T2 uses T(0.1) data
- T1 uses T(0.2) data
- T3 uses T(0.3) data…
In many (if not most) cases, using the freshest data will not cause an issue. However if there are synchronization issues then using a “sample and hold” approach to the data may be required.