Rate Transitions

What Is a Rate Transition?

Rate transitions exist in multirate models between blocks that exchange data over a signal line and are configured to use different sample times. A rate transition is represented in a model as a Rate Transition block that the Simulink^® engine inserts for you or you insert manually on the signal line that connects the blocks that exchange data.

For information about tradeoffs that you can make regarding rate transitions and how to configure them, see Control Data Transfer Behavior in Generated Code (Embedded Coder).

Types of Rate Transitions

Type	Description
Periodic fast-to-slow	A block configured to use a faster periodic sample time drives a block that is configured to use a slower periodic sample time.
Periodic slow-to-fast	A block configured to use a slower periodic sample time drives a block that is configured to use a faster periodic sample time.
Asynchronous-to-periodic	A block configured to use an asynchronous sample time drives a block that is configured to use a periodic sample time.
Asynchronous-to-asynchronous	A block configured to use an asynchronous sample time drives another block that is configured to use an asynchronous sample time.

In multirate systems, differing sample rates can cause blocks to execute in the wrong order. To prevent possible errors in calculated data, you must control model execution at these transitions. When connected blocks have different sample rates, you or the Simulink engine must add a Rate Transition block between them.

This figure shows a periodic fast-to-slow rate transition. The faster block that is configured to use a sample rate of 1 second drives a slower block that is configured to use a sample rate of 2 seconds. The inserted Rate Transition block handles the transfer of data between the blocks operating at different rates.

This figure shows a periodic slow-to-fast rate transition. The slower block that is configured to use a sample rate of 2 seconds drives a faster block that is configured to use a sample rate of 1 second. Again, the inserted Rate Transition block handles the transfer of data between the blocks operating at different rates.

The preceding figures show models configured to use periodic sample times with a zero offset. Other considerations apply to multirate models that involve asynchronous tasks. For details on how to generate code for asynchronous multitasking, see 非同期のサポート.

Fast-to-Slow Periodic Rate Transitions During Simulation

During simulation of a model that includes a faster block that drives a slower block that has a direct feedthrough, the output of the faster block is computed first. During simulation intervals when the slower block does not execute, the simulation progresses more rapidly because there are fewer blocks to execute.

This figure illustrates this situation. The timing diagram assumes that the Rate Transition block is used in its default (protected/deterministic) mode.

The simulation does not execute in real time, which means that it is not bound by real-time constraints. The simulation waits for, or moves ahead to, whatever tasks are required to complete simulation flow. The actual time interval between sample time steps can vary.

Fast-to-Slow Periodic Rate Transitions During Generated Code Execution

During execution of code generated from a model where a faster block drives a slower block, you must compensate for execution of the task for the slower block possibly spanning multiple execution periods of the task for the faster block. As a result, the output of the task for the faster block can change before the task for the slower block finishes computing its output.

This figure shows this situation, where T equals the sample time. Higher priority tasks preempt lower priority tasks before the lower priority tasks finish executing. The timing diagram assumes that the Rate Transition block is used in its default (protected/deterministic) mode.

In the preceding figure, the task for the faster block executes a second time before the task for the slower block finishes executing. This can cause unpredictable results because the input data to the slower task changes. In this situation, data integrity might not be maintained.

To maintain data integrity, the Simulink engine must hold the output of the task for the faster block until the task for the slower block finishes executing. To accomplish this, insert a Rate Transition block between the faster and slower blocks. The Rate Transition block enables the task for the slower block to preserve its input during its execution, maintaining data integrity.

For this timing diagram, the code for the Rate Transition block executes at the sample rate of the task for the slower block, but with the priority of the task for the faster block.

When you add a Rate Transition block, code for the block executes before the task for the slower block (its priority is higher) and its output value is held constant while the task for the slower block executes (it executes at the slower sample rate).

Slow-to-Fast Periodic Rate Transitions During Simulation

During simulation of a model that includes a slower block that drives a faster block, the Simulink engine computes the output of the driving block first. During sample intervals where only the faster block executes, the simulation progresses more rapidly.

This figure shows the execution sequence. The timing diagram assumes that the Rate Transition block is used in its default (protected/deterministic) mode.

As the figure shows, the Simulink engine can simulate models with multiple sample rates efficiently. However, a Simulink simulation does not operate in real time.

Slow-to-Fast Periodic Rate Transitions During Generated Code Execution

In models that include a slower block that drives a faster block, the generated code assigns the task for the faster block a higher priority than the task for the slower block. This means the task for the faster block executes before the task for the slower block. To avoid incorrect results, this situation requires special care.

This timing diagram illustrates two problems:

Execution of the task for the slower block is split across multiple faster block intervals. The task for the faster block executes a second time before the task for the slower block finishes executing. This means the inputs to the faster task can have incorrect values some of the time.
The task for the faster block executes before the task for the slower block, which is backward from the way a simulation operates. In this case, the task for the faster block executes first. However, input to the faster task has not been computed. This can cause unpredictable results.

To eliminate these problems, you must insert a Rate Transition block between the slower and faster blocks.

This figure shows the timing sequence that results with an added Rate Transition block in its default (protected/deterministic) mode.

The figure highlights three rate transition problems (in the figure, refer to the circled numbers):

The Rate Transition block output runs in the task for the faster block, but at a slower rate (2 seconds). The output of the Rate Transition block feeds the task for the faster block.
The Rate Transition block update uses the output of the task for the slower block to update its internal state.
The Rate Transition block output in the task for the faster block uses the state of the Rate Transition block that was updated in the task of the slower block.

The first problem is addressed because the Rate Transition block is updating at a slower rate and at the priority of the task for the slower block. The input to the Rate Transition block, which is the output of the task for the slower block, is read after the task for the slower block finishes executing.

The second problem is addressed because the Rate Transition block executes at a slower rate and its output does not change during the computation of the task for the faster block that it is driving. The output of the code for a Rate Transition block executes at the sample rate of the task for the slower block, but with the priority of the task for the faster block. Since the code for the Rate Transition block drives the task for the faster block and has effectively the same priority, it executes before the task for the faster block.

This use of the Rate Transition block changes the model. The output of the task for the slower block is now delayed by one time step compared to the output without a Rate Transition block.

Asynchronous Rate Transitions

Asynchronous function-call subsystems can preempt or be preempted by other model code. In models that include an asynchronous function-call subsystem that drives another function-call subsystem (periodic or asynchronous), priorities of tasks associated with the subsystems determine task preemption rules, which can impact data transfers.

The Simulink engine assigns priorities to periodic tasks based on settings of solver model configuration parameters. When the Periodic sample time constraint parameter is set to Unconstrained, Simulink assigns priority 40 to the sample time that corresponds to the fixed step size for the simulation. The software increments or decrements from 40 by 1 to assign priorities to other tasks depending on the setting of parameter Higher priority value indicates higher task priority.

For asynchronous tasks, the block initiating a trigger event, such as an Async Interrupt block, assigns priorities to connected function-call subsystems. The Async Interrupt block parameter Simulink task priority(s) specifies an array of required priority levels, where each priority-level corresponds to an interrupt number specified for block parameter VME interrupt number(s). The priority array sets the priorities of the subsystems connected to each VME interrupt.

Because an asynchronous function-call subsystem can preempt or be preempted by other model code, an inconsistency arises when multiple signal lines connect to an asynchronous block. A preemption can occur while the function-call subsystem reads and writes the signal data. As a result, some old and some new data gets used. This situation can occur also with signal scalar data. For example, if signal data is of type double (8 bytes), the read or write operation might require two machine instructions.

メモ

The Async Interrupt is in the Interrupt Templates block library. The blocks in that library serve as examples to help you develop custom blocks for a specific target environment.

参考

Rate Transition