Triggered Subsystems :: Creating a Model (Using Simulink)

Using Simulink

Triggered Subsystems

Triggered subsystems are subsystems that execute each time a trigger event occurs.

A triggered subsystem has a single control input, called the trigger input, that determines whether the subsystem executes. You can choose from three types of trigger events to force a triggered subsystem to begin execution:

rising triggers execution of the subsystem when the control signal rises from a negative or zero value to a positive value (or zero if the initial value is negative).
falling triggers execution of the subsystem when the control signal falls from a positive or a zero value to a negative value (or zero if the initial value is positive).
either triggers execution of the subsystem when the signal is either rising or falling.

Note In the case of discrete systems, a signal's rising or falling from zero is considered a trigger event only if the signal has remained at zero for more than one time step preceding the rise or fall. This eliminates false triggers caused by control signal sampling.

For example, in the following timing diagram for a discrete system, a rising trigger (R) does not occur at time step 3 because the signal has remained at zero for only one time step when the rise occurs.

A simple example of a triggered subsystem is illustrated.

In this example, the subsystem is triggered on the rising edge of the square wave trigger control signal.

Creating a Triggered Subsystem

You create a triggered subsystem by copying the Trigger block from the Signals & Systems library into a subsystem. Simulink adds a trigger symbol and a trigger control input port to the Subsystem block.

To select the trigger type, open the Trigger block dialog box and select one of the choices for the Trigger type parameter, as shown in the following dialog box:

Simulink uses different symbols on the Trigger and Subsystem blocks to indicate rising and falling triggers (or either). This figure shows the trigger symbols on Subsystem blocks.

Outputs and States Between Trigger Events. Unlike enabled subsystems, triggered subsystems always hold their outputs at the last value between triggering events. Also, triggered subsystems cannot reset their states when triggered; states of any discrete blocks are held between trigger events.

Outputting the Trigger Control Signal. An option on the Trigger block dialog box lets you output the trigger control signal. To output the control signal, select the Show output port check box.

The Output data type field allows you to specify the data type of the output signal as auto, int8, or double. The auto option causes the data type of the output signal to be set to the data type (either int8 or double) of the port to which the signal is connected.

Function-Call Subsystems

You can use a Trigger block to create a subsystem whose execution is determined by logic internal to an S-function instead of by the value of a signal. These subsystems are called function-call subsystems. For more information about function-call subsystems, see Function-Call Subsystems in the Writing S-Functions documentation.

Blocks That a Triggered Subsystem Can Contain

All blocks in a triggered systems must have either inherited (-1) or constant (inf) sample time. This is to indicate that the blocks in the triggered subsystem run only when the triggered subsystem itself runs, i.e., when it is triggered. This requirement means that a triggered subsystem cannot contain continuous blocks, such as the Integrator block.

Enabled Subsystems Triggered and Enabled Subsystems