Control and Display Execution Order

Theexecution orderfor a model is the order in which Simulink^®invokes the block output methods during simulation. Simulink determines this order during a model update, which you can initiate by clickingUpdate Modelon theModelingtab. Simulink also updates the model during simulation.

You cannot set the execution order, but you can assign priorities to nonvirtual blocks to indicate their execution order relative to other blocks in the corresponding block diagram.

Some nonvirtual blocks do not support block priorities. For example, Simulink ignores priorities set on these blocks:

Mergeblocks
Blocks with function-call input ports, such asFunction-Call Subsystemblocks andModelblocks that reference export-function models
Blocks with action ports, such asIf Action SubsystemandSwitch Case Action Subsystemblocks

If a priority is set on these blocks, theBlock priority violationconfiguration parameter setting determines whether you receive a warning or error.

Simulink tries to honor block priority settings unless there is a conflict with data dependencies. To confirm the results of the priorities you have set or to debug your model, display and review the execution order of your nonvirtual blocks and subsystems.

For more information about block methods and execution, see:

Execution Order Viewer

On theDebugtab, selectInformation Overlays>Execution Order. The Execution Order viewer opens in a pane on the right side of the Simulink Editor.

Execution Order viewer

The Execution Order viewer displays a list of tasks for the current system.

Each nonvirtual subsystem has its ownSystem Indexvalue that is unique within the model. Blocks that are directly inside the nonvirtual subsystem have the sameSystem Indexvalue as the subsystem. In model reference hierarchies, the sameSystem Indexvalue may be used multiple times, but it remains unique within each model in that hierarchy. To determine whether subsystems are part of the same system within a model, compare theirSystem Indexvalues.

Each task listed in theTask IDcolumn corresponds to a group of blocks that execute in the same task. For fixed-step sizes, theTreat each discrete rate as a separate taskconfiguration parameter determines whether Simulink executes blocks with discrete rates in one or multiple tasks.

Selecting a task in the Execution Order viewer highlights the blocks that belong to the task and displays their execution order. By default, Simulink selects the first task that corresponds to the active block diagram.

When the active block diagram does not contain any blocks that execute as part of a given task, you cannot select the task in the Execution Order viewer. The active block diagram may contain virtual blocks, such asInportblocks, that are part of this task.

To hide the highlighting and execution order, click theClear Highlightingbutton.

Navigation from Blocks to Tasks

To display the tasks in which a block executes, click on a block.

The selected Subsystem block has an information overlay that says

任务的数字标签链接你can click to select the corresponding task in the Execution Order viewer. When a model has many tasks, these links provide an alternative to scrolling through the list of tasks in the Execution Order viewer.

To compare tasks among blocks, select multiple blocks.

Execution Order Notation

Simulink displays a number at the top-right corner of each nonvirtual block. These numbers indicate the order in which the blocks execute. The first block to execute has the lowest execution order, which is usually1. The displayed execution order may skip numbers, but the blocks always execute in order of the visible numbers. Suppose a task displays execution orders 1, 2, and 4. The block labeled 1 executes before the block labeled 2, which executes before the block labeled 4.

For example, in thevdpmodel, the block execution order ranges from1to9, with each nonvirtual block receiving an execution order.

Execution Order viewer for the vdp model

Virtual and Nonvirtual Subsystems

VirtualSubsystem块只存在图形,不执行。Consequently, they are not part of the execution order. Creating virtual subsystems can affect the execution order of blocks when the blocks are sorted by block path. Each block within a virtual subsystem executes as an atomic unit and has an execution order in the context of the root-level model or, if the virtual subsystem is inside a nonvirtual subsystem, in the context of the parent nonvirtual subsystem. For virtual subsystems, block execution order within the subsystem is listed in curly brackets {}.

NonvirtualSubsystemblocks exist functionally and execute as a unit. They have a single execution order and a different system index than the root-level model or any parent nonvirtual subsystem. The blocks inside a nonvirtual subsystem have their own execution orders, which are independent of the root-level model or any parent nonvirtual subsystem.

例如,该模型包含了一个虚拟subsystem named Car Dynamics and an atomic, nonvirtual subsystem named Discrete Cruise Controller.

The virtual Car Dynamics subsystem shows a list of execution orders within curly brackets for the blocks it contains. The blocks it contains execute at the same level as theStep,Sum, andScopeblocks and the Discrete Cruise Controller nonvirtual subsystem. TheIntegratorblock executes first and sends its output to theScopeblock, which executes second.

The nonvirtual Discrete Cruise Controller subsystem has a single execution order (5), which indicates that the subsystem and the blocks within it are the fifth to execute relative to the blocks at the same level.

Note

Depending on your model configuration, Simulink can insert hidden, nonvirtual subsystems in your model. As a result, the visible blocks inside the hiddenSubsystemblock can have a system index that is different from the current system index. For example, if you select theConditional input branch executionconfiguration parameter, Simulink may create hidden, nonvirtual subsystems for optimization, which can affect the sorted execution order.

Algebraic Loops

Blocks within an algebraic loop are moved into a hidden nonvirtual subsystem. Simulink first determines the execution order of the hidden subsystem within the context of the other blocks, then determines the execution order of the blocks within the hidden subsystem. SeeAlgebraic Loop Concepts.

Function-Call and Action Subsystems

For function-call and action subsystems, the execution of the subsystem is controlled by the execution of its initiator. The subsystem and its initiator therefore share an execution order.

Simulink ignores any block priority set onFunction-Call Subsystem,If Action Subsystem, orSwitch Case Action Subsystemblocks, but you can set the block priority on the blocks that initiate these subsystems.

At the root-level of export-function models, function-call execution orders have anFprefix.

For more information, seeExport-Function Models Overview.

Buses and Multiple Initiators

A block has multiple execution orders when the block executes multiple times based on different execution paths to that block. For example:

一块连接到总线的执行顺序corresponding to each signal that the bus contains.
A function-call or action subsystem with multiple initiators has an execution order corresponding to each initiator.

How金宝appDetermines Execution Order

Simulink uses task-based sorting to set the execution order of blocks and ports based on their derived sample time information. Task-based sorting provides an efficient and simpler process for determining the execution order of blocks.

With task-based sorting:

Tasks are sorted individually based on sample time.
Multiple sorted lists are generated instead of one flattened, sorted list of blocks across all tasks.
Rate transition handling is simplified.
False data dependency violations involving blocks in different tasks are avoided.
Code generation results are in efficient rate groupings.
One subsystem can belong to different sorted lists in multiple tasks.

Direct-Feedthrough Input Impact on Execution Order

To ensure that the execution order reflects data dependencies among blocks, Simulink categorizes block input ports according to the dependency of the block outputs on the block input ports. An input port whose current value determines the current value of one of the block outputs is adirect-feedthroughinput. SeeAlgebraic Loop Concepts. Examples of blocks that have direct-feedthrough inputs include:

Examples of blocks without direct-feedthrough inputs include:

Rules for Determining Block Execution Order

To sort blocks, Simulink uses these rules:

If a block drives the direct-feedthrough input of another block, the driving block must appear in the execution order ahead of the block that it drives.
This rule ensures that the direct-feedthrough inputs to blocks are valid when Simulink invokes block output methods that require current inputs.
If a block drives the input of another block that is not a direct-feedthrough input, there is no data dependency between the two blocks, so their relative execution order does not matter.

This model illustrates this result.

TheIntegratorblock1/sin the Car Dynamics virtual subsystem has no direct-feedthrough input. Therefore, even though its input is connected to theGainblock1/m, theIntegratorblock is sorted before theGainblock1/m. The output of theIntegratorblock drives the input of theGainblockb, so theIntegratorblock is sorted before thatGainblock.
In the root-level model, theStepblockstep responsedrives aSumblock, so theStepblock is sorted before theSumblock. TheSumblock drives the direct-feedthrough input of the Discrete Cruise Controller nonvirtual subsystem, so the subsystem is sorted after theSumblock.

The Discrete Cruise Controller nonvirtual subsystem is treated as a block with a direct-feedthrough input because its output depends on the current value of the input via the branch with theKpGainblock. Inside the subsystem, all theGainblocks, which have direct-feedthrough inputs, run before theSumblock that they drive.

Rules for Determining Block Execution Order in Models Containing Asynchronous Tasks

In simulation, asynchronous function call initiators have the highest priority when determining block sorting order within a task. For more information, seeAsynchronous Sample TimeandRate Transitions and Asynchronous Blocks(Simulink Coder).

To determine the block execution order in models containing asynchronous sample times, Simulink uses these rules:

If an asynchronous function call initiator is triggered by a discrete rate shared by the corresponding rate transition block, then in the task of the common discrete rate, the asynchronous function call initiator will be sorted first.
For example, in the below model, there is one asynchronous function call initiator that is triggered by the discrete rateD1. Within the discrete task, the asynchronous function call initiator is sorted first. TheRate Transitionblocks convert between the asynchronous rate,A1, and the discrete rate,D1.
If aRate Transitionblock is reduced toNoOp, theRate Transitionblock does not execute, and its position in the sorted order within the discrete task is transferred to the upstream or downstream discrete block to which it is connected.
For example, in the above model,RTB2is reduced toNoOp, so its position in the sorted order is transferred to the downstreamGainblock.
If two asynchronous function call initiators share a common discrete rate task, then asynchronous function call initiator with higher priority executes first within the discrete rate task.
For example, in the below model, two asynchronous function call initiators are triggered by the same discrete rate,D1. The one with higher task priority is sorted first.
The union of asynchronous sample times is not supported by task-based sorting. Models containing the union of multiple asynchronous sample times default to a global execution order, in which all blocks are sorted within a single task.

Checks for Execution Order Changes Involving Data Store Memory Blocks

Model Upgrades

Using task-based sorting instead of legacy (block) sorting can change the relative execution order involvingData Store Memoryblocks. An Upgrade Advisor check detects the changes and provides an option to keep the original execution order when upgrading your model from earlier versions of Simulink.

Open the Upgrade Advisor. On theModelingtab, selectModel Advisor>Upgrade Advisor.
Select the check box forCheck relative execution orders for Data Store Read and Data Store Write blocks.
ClickRun This Check.
Review any changes in theResulttable. If you want to keep the original execution order, clickModify.

Code Generation

When a model is compiled for code generation, the relative execution order ofData Store ReadandData Store Writeblocks can differ in the generated code from the order in normal simulation mode. A Model Advisor check detects these differences and provides an option to change the execution order in normal simulation mode to match the order in the generated code.

Open the Model Advisor. On theModelingtab, selectModel Advisor>By Product>Simulink Coder.
Select the check box forCheck for relative execution order change for Data Store Read and Data Store Write blocks.
ClickRun This Check.
Review any changes in theResulttable. If there are discrepancies listed and you want to change the execution order in normal simulation to conform with the execution order in generated code, clickModify block priorities.