Professional Documents
Culture Documents
Rate Transition Blocks Explained
Rate Transition Blocks Explained
Rate Transition Blocks Explained
Introduction
Every Simulink
R
block has a sample time, whether it is explicitly defined or in-
R
herited. Simulink allows you to create models employing multiple sample times.
Using the default solver settings, your model will use multitasking if it contains two
or more different rates. In a multitasking environment, the code assigns each block
a task identifier (TID) to associate it with the task that executes at its sample rate.
The sample rate of any block must be an integer multiple of the base (i.e. the fastest)
sample rate. Blocks with the fastest sample rates are executed by the task with the
highest priority, the next slowest blocks are executed by a task with the next lower
priority, and so on. Time available in between the processing of high priority tasks
is used for processing lower priority tasks. Figure 1 shows a graphical representation
of this task handling.
There are two possible periodic sample rate transitions that can exist within a model:
1
High priority
Low priority
t0 t1 t2 t3 t4 t5 t
Task preemption by a
Task execution start or end higher priority task
You must also take into account that the execution time may vary, see Figure 2. For
example, if a slower block drives a faster block, two situations are possible. When
the slower task finishes execution before the next sample time of the faster block, its
output can be used immediately (at t3). On the other hand, when the execution of
the slower task takes longer and is preempted by the faster task (at t1), its output
should be used one sample time later (at t2). Moreover, the execution time of the
faster task can vary (at t4). Thus, if the duration and variation of execution times
are unknown, the timing of data transfer is not predictable, and the data transfer is
said to be nondeterministic.
2
0.01 s
0.02 s
t0 t1 t2 t3 t4 t5 t
Figure 2: Nondeterministic data transfer with loss of data integrity. Arrows indicate
data transfer with corrupted data.
After updating the diagram, a label appears on the Rate Transition block that
indicates the operation mode. These are listed in Table 1 and described in much
more detail in the next section. If both options are enabled, the operation modes
are ZOH for fast-to-slow transitions and 1/z for slow-to-fast transitions. The latter
introduces latency of one sample period of the slower task, which is a drawback of
this choice of settings. At IDSC, we generally find it more desirable not to have an
additional delay than to have deterministic data transfer, although it really depends
on the application. Our general recommendation is to disable the second option. In
this case, a Buf or Db buf operation mode is used. Finally, it goes without saying
that data integrity should be ensured at all times.
3
Rate Transition block operation modes
This section explains the functionality of each mode in much detail. This is done by
providing comprehensible illustrations and analyzing generated code.
ZOH
For fast-to-slow transitions, the Rate Transition block will operate as a zero-order
hold (ZOH) when the following options are used:
0.01 s RT RT RT
0.02 s
t0 t1 t2 t3 t4 t5 t
The generated code for the Rate Transition block is shown in Listing 1. There are two
interrupt service routines (ISR), one for each task identifier (TID). These correspond
to the fast and slow task in Figure 4, including the rate transition calculations. In
4
the first ISR, a flag named TIDO_1 switches between 0 and 1, which is responsible for
the ZOH behavior. When this flag equals 1, i.e. only after the first execution of the
fast task, the data is transferred to a temporary variable named RateTransition.
In the second ISR, i.e. for the slow task, this variable is used as an input.
1/z
For slow-to-fast transitions, the Rate Transition block will operate as a unit delay
(1/z) at the slower sample rate when the following options are used:
3 Ensure data integrity during data transfer
5
unit delay, because the output data of the slower task is only used in the next slower
period. This results in deterministic data transfer. Furthermore, every second time
that the faster task is executed, the same data as for the first execution is used.
Therefore, no data is transferred during the preemption (e.g. at t1) and so data
integrity is ensured.
1/z
double double
1 1
In Out
Sample Time 0.02 Rate Transition Sample Time 0.01
0.01 s RT RT RT
0.02 s RT RT RT
t0 t1 t2 t3 t4 t5 t
Figure 6: Task handling and slow-to-fast data transfer using a unit delay.
The generated code for the Rate Transition block is shown in Listing 2. It is very
similar to the generated code for the ZOH block, see Listing 1. The flag TIDO_1 is
used to update the input to the fast task only in the first execution. A temporary
variable named RateTransition_Buffer0 is used to safely transfer the data from
the slow to the fast task.
6
15 }
16
Buf
For fast-to-slow transitions, the Rate Transition block will operate as a buffer (Buf)
when the following options are used:
Constant Constant1
7
As soon as the calculations before the rate transition are finished, the data is loaded
from the buffer under semaphore [1] control, but only with respect to the calcula-
tions of the rate transition. This means that a preemption by the faster task may
still take place, but the data is not saved into the buffer (e.g. at t3). As a result,
data integrity is ensured.
0.01 s RT RT RT RT RT
0.02 s RT RT
t0 t1 t2 t3 t4 t5 t
The generated code for the Rate Transition block is shown in Listing 3. The cal-
culations of the Sum, Gain and Constant blocks happen before and after the rate
transition for the faster and slower task, respectively. While this is trivial, it can
also be seen that the semaphore control only applies to the calculations of the rate
transition (i.e. writing and reading the buffer). In the faster task, data is only writ-
ten to the buffer if the semaphore is not taken, whereas in the slower task, the
semaphore is only set while reading the buffer. Consequently, the buffer will often
be filled unnecessarily (e.g. between t1 and t2). The calculations of the integrator,
or, in general, of any block with some internal state(s), happen before the rate tran-
sition in the slower task. If these lines of code are interrupted, then the buffer is
read one faster time step later. Therefore, the data transfer is non-deterministic. If,
however, the slower task only contains algebraic blocks, then the buffer is read at
the very beginning of the slower ISR, and one might argue that the data transfer is
deterministic. But, even in that case the line of code that sets the semaphore (line
33) could be interrupted.
8
11 rtb_Sum = modelName_P.Gain_Gain * modelName_U.InSampleTime001 +
12 modelName_P.Constant_Value;
13
Db buf
For slow-to-fast transitions, the Rate Transition block will operate as a double buffer
(Db buf) when the following options are used:
3 Ensure data integrity during data transfer
Ensure deterministic data transfer
9
After updating the Simulink
R
diagram, the Rate Transition block will appear as
in Figure 9. The task handling and data transfer are illustrated in Figure 10. After
each execution of the slower task, the data is written to one of two buffers. The
faster task then reads the data from this buffer. In the meantime, new data from
a subsequent execution of the slower task is safely written to another buffer. When
this data transfer is finished, the buffer index is changed, and the new data can be
used by the faster task. When this happens depends on the duration of the calcula-
tions (e.g. see Figure 10), so that the data transfer is not necessarily deterministic.
However, the use of two buffers ensures data integrity.
Db_buf
double double
1 1
In Out
Sample Time 0.02 Rate Transition Sample Time 0.01
0.01 s
0.02 s RT RT RT
t0 t1 t2 t3 t4 t5 t
Figure 10: Task handling and slow-to-fast data transfer using a double buffer.
The generated code for the Rate Transition block is shown in Listing 4. Suppose the
buffer index ActiveBufIdx equals 0. Then, the input data for the faster task is read
from the first buffer. After the slower task is completed, the data is written into the
second buffer (ActiveBufIdx == 0 → true1 or 1) and the buffer index is set to 1
by using the same conditional statement.
1
Originally, the Boolean data type was not defined in the C programming language.
10
11 /* Model step function for TID1 */
12 void modelName_step1(void) /* Sample time: [0.02s, 0.0s] */
13 {
14 /* Update for RateTransition: ’<Root>/Rate Transition’ incorporates:
15 * Update for Inport: ’<Root>/In Sample Time 0.02’
16 */
17 modelName_DW.RateTransition_Buffer[modelName_DW.RateTransition_ActiveBufIdx ==
0]
18 = modelName_U.InSampleTime002;
19 modelName_DW.RateTransition_ActiveBufIdx = (int8_T)
20 (modelName_DW.RateTransition_ActiveBufIdx == 0);
21 }
The task handling and data transfer are illustrated in Figure 2. As already men-
tioned in the section there, data integrity and deterministic data transfer are not
ensured. The generated code for both the Copy and NoOp Rate Transition blocks
is identical and is shown in Listing 5 for a fast-to-slow transition.
11
Mixed
If the input and output to the Rate Transition block are vectors or buses with
elements that differ in sample time, the Rate Transition block will expand to multiple
blocks with different behaviors. An example is shown in Figure 11.
double double
1 1
sig1 <sig1>
In1 Mixed Out1
Sample Time 0.01 Sample Time 0.1
double double
2 2
sig2 Rate Transition <sig2>
In2 Out2
Sample Time 0.02 Sample Time 0.01
References
[1] Wikipedia. Semaphore (programming). https://en.wikipedia.org/wiki/
Semaphore_(programming). Accessed: 2015-08-21.
12