Subsystems are the means by which you can group blocks together in your model to manage model complexity. Simulink consists of two classes of subsystems:
Treat as atomic
unit
option on a virtual subsystem.States when enabling
parameter in the enable
port block. Each output port of an enabled subsystem can be configured to
hold or reset its output via the Output when disabled
parameter
in the outport block. You create an enabled subsystem by placing an enable
port block within a subsystem. Trigger type
parameter on the trigger port block. Simulink
limits the type of blocks placed in a triggered subsystem to blocks that do
not have explicit sample times (i.e., blocks within the subsystem must have a
sample time of -1) because the contents of a triggered subsystem
execute in an aperiodic fashion. You create a triggered subsystem by placing
a trigger port block within a subsystem. A Stateflow chart can also have a
trigger port which is defined by using the Stateflow editor. From Simulink's
perspective there is no difference between a triggered subsystem and a
triggered chart.Trigger type
parameter set to function-call within a subsystem. A Stateflow chart can
also have a function-call port, which is defined by using the Stateflow
editor.Trigger type
parameter on the
trigger port block. Simulink limits the types of blocks placed in an
enabled with triggered subsystem to blocks that do not have explicit sample
times (i.e., blocks within the subsystem must have a sample time of -1)
because the contents of a triggered subsystem execute in an aperiodic
fashion. You create an enabled with triggered subsystem by placing a
trigger port block and a enable port block within a subsystem.
Action subsystems can be executed at most once by the action subsystem
initiator. Action subsystems give you control over when the states reset via
the States when execution is resumed
parameter on the action
port block. Action subsystems also give you control over whether or not to
hold the outport values via the Output when disabled
parameter
on the outport block. This is analogous to enabled subsystems.
Action subsystems behave very similarly to function-call subsystems because they must be executed by an initiator block. Function-call subsystems can be executed more than once on any given time step whereas action subsystems can be executed at most once. This restriction means that a larger set of blocks (e.g., periodic blocks) can be placed in action subsystems when compared with function-call subsystems. This restriction also means that you can have control over how the states and outputs behave.
A while-subsystem is very similar to a function-call subsystem in that it can
run for any number of iterations on a given time step. The while-subsystem
differs from a function-call subsystem in that there is no separate initiator
(e.g., a Stateflow Chart). In addition, a while-subsystem has access to the
current iteration number optionally produced by the while-iterator block. A
while-subsystem also gives you control over whether or not to reset states
when starting via the States when starting
parameter on the
while-iterator block.
A for-subsystem has access to the current iteration number that is
optionally produced by the for-iterator block. A for-subsystem also gives you
control over whether or not to reset states when starting via the
States when starting
parameter on the for-iterator block. A
for-subsystem is very similar to a while-subsystem with the restriction that
the number of iterations on any given time step is fixed.