| Simulink® | ![]() |
Ports & Subsystems
A Subsystem block represents a subsystem of the system that contains it. The Subsystem block can represent a virtual subsystem or a true (atomic) subsystem, depending on the value of its Treat as atomic unit parameter. An Atomic Subsystem block is a Subsystem block that has its Treat as atomic unit parameter selected by default.
You create a subsystem in these ways:
Copy the Subsystem (or Atomic Subsystem) block from the Ports & Subsystems library into your model. You can then add blocks to the subsystem by opening the Subsystem block and copying blocks into its window.
Select the blocks and lines that are to make up the subsystem using a bounding box, then choose Create Subsystem from the Edit menu. Simulink® software replaces the blocks with a Subsystem block. When you open the block, the window displays the blocks you selected, adding Inport and Outport blocks to reflect signals entering and leaving the subsystem.
The number of input ports drawn on the Subsystem block's icon corresponds to the number of Inport blocks in the subsystem. Similarly, the number of output ports drawn on the block corresponds to the number of Outport blocks in the subsystem.
See Creating Subsystems for more information about subsystems.
For a discussion on the data types supported by Simulink software, see Data Types Supported by Simulink® in the Simulink documentation.
See Inport for information on the data types accepted by a subsystem's input ports. See Outport for information on the data types output by a subsystem's output ports.

Causes Simulink software to display labels for the subsystem's ports on the subsystem's icon. Options include:
| Option | Description |
|---|---|
| none | Do not display port labels on the subsystem block. |
| FromPortIcon | If the corresponding port icon displays a signal name, display the signal name on the subsystem block. Otherwise, display the port block's name. |
| FromPortBlockName | Display the name of the corresponding port block on the subsystem block. |
| Signal Name | Display the name of the signal connected to the port on the subsystem block, if a name exists, otherwise, the name of the corresponding port block. |
Controls user access to the contents of the subsystem. You can select any of the following values.
| Permissions | Description |
|---|---|
ReadWrite | User can open and modify the contents of the subsystem. |
ReadOnly | User can open but not modify the subsystem. If the subsystem resides in a block library, a user can create and open links to the subsystem and can make and modify local copies of the subsystem but cannot change the permissions or modify the contents of the original library instance. |
NoReadOrWrite | User cannot open or modify the subsystem. If the subsystem resides in a library, a user can create links to the subsystem in a model but cannot open, modify, change permissions, or create local copies of the subsystem. |
Name of a function to be called if an error occurs while Simulink software is executing the subsystem. Simulink software passes two arguments to the function: the handle of the subsystem and a string that specifies the error type. If no function is specified, Simulink software displays a generic error message if executing the subsystem causes an error.
Specifies whether to resolve names of workspace variables referenced by this subsystem. The options are
All
Resolve all names of workspace variables used by this subsystem, including those used to specify block parameter values and Simulink data objects (for example, Simulink.Signal objects).
ExplicitOnly
Resolve only names of workspace variables used to specify block parameter values, data store memory (where no block exists), signals, and states marked as "must resolve".
None
Do not resolve any workspace variable names.
See Resolving Symbols and Hierarchical Symbol Resolution for more information.
Causes Simulink software to treat the subsystem as a unit when determining the execution order of block methods. For example, when it needs to compute the output of the subsystem, Simulink software invokes the output methods of all the blocks in the subsystem before invoking the output methods of other blocks at the same level as the subsystem block. If this option is not selected, Simulink software treats all blocks in the subsystem as being at the same level in the model hierarchy as the subsystem when determining block method execution order. This can cause execution of methods of blocks in the subsystem to be interleaved with execution of methods of blocks outside the subsystem.
This option appears only if the subsystem is atomic. If selected, this option tries to eliminate any algebraic loops that include the subsystem (see Eliminating Algebraic Loops in the online Simulink documentation for more information).
This option appears only if the subsystem is conditionally executed.

If selected, this option enables execution context propagation across this subsystem's boundary (see Propagating Execution Contexts in the online Simulink documentation). Simulink software disables this option by default.
This option appears only if the subsystem is a function-call subsystem.

The option is effective only if the Context-dependent inputs diagnostic on the Configuration Parameters > Connectivity dialog box is set to Use local settings. In this case, if this option is checked, Simulink software displays a warning if it has to compute any of this function-call subsystem's inputs directly or indirectly during execution of a function-call (see the "Function-call systems" examples in the Simulink "Subsystem Semantics" library for examples of such function-call subsystems.
Specifies the sample time of this subsystem if it is atomic, i.e., its Treat as atomic unit option is selected. The sample time that you specify must be one of the following:
Inherited Sample Time (-1), the default
Constant Sample Time (inf)
Periodic ([Ts 0])
Use this parameter to specify whether all blocks in this subsystem must run at the same rate or can run at different rates. If the blocks in the subsystem can run at different rates, specify the subsystem's sample time as inherited (-1). If all blocks must run at the same rate, specify the sample time corresponding to this rate as the value of the subsystem's Sample time parameter. If any of the blocks in the subsystem specify a different sample time (other than -1 or inf), Simulink software displays an error message when you update or simulate the model. For example, suppose all the blocks in the subsystem must run 5 times a second. To ensure this, specify the sample time of the subsystem as 0.2. In this example, if any of the blocks in the subsystem specify a sample time other than 0.2, -1, or inf, Simulink software displays an error when you update or simulate the model.
Specifies the code format to be generated for an atomic (nonvirtual) subsystem.
| If You Want Real-Time Workshop Software to... | Select... |
|---|---|
| Choose the optimal format for you based on the type and number of instances of the subsystem that exist in the model | Auto |
| Inline the subsystem unconditionally | Inline |
| Generate a separate, non-reentrant function with no arguments, and optionally place the subsystem code in a separate file | Function |
| Generates a function with arguments that allows the subsystem's code to be shared by other instances of it in the model | Reusable function |
When this option is set to Function or Reusable function, two additional options appear — Real-Time Workshop function name options and Real-Time Workshop file name options.
For more information on using these options, see Nonvirtual Subsystem Code Generation Options in the Real-Time Workshop documentation.
Specifies how Real-Time Workshop software is to name the function it generates for the subsystem.
| If You Want Real-Time Workshop Software to... | Select... |
|---|---|
| Assign a unique function name using the default naming convention, model, _subsystem(), where model is the name of the model and subsystem is the name of the subsystem (or that of an identical one when code is being reused) | Auto |
| Use the subsystem name as the function name | Use subsystem name |
| Assign a unique, valid C or C++ function name that you specify | User specified |
If you specify Use subsystem name and the subsystem is a library block, Real-Time Workshop software names the function (and filename) with the name of the library block, regardless of the names used for that subsystem in the model.
If you select User specified, a Real-Time Workshop function name option appears.
Specifies a unique, valid C or C++ function name for subsystem code.
Specifies how Real-Time Workshop software is to name the separate file for the function it generates for the subsystem.
| If You Want Real-Time Workshop Software to... | Select... |
|---|---|
| Generate the function code within the module generated from the subsystem's parent system, or, if the subsystem's parent is the model itself, within the file model.c or model.cpp | Auto |
| Generate a separate file and name it with the name of the subsystem or library block | Use subsystem name |
| Generate a separate file and name it with the function name you specify for Real-Time Workshop function name options | Use function name |
| Assign a unique, valid C or C++ function name that you specify | User specified |
If you specify Use subsystem name, the subsystem filename is mangled if the model contains Model blocks, or if a model reference target is being generated for the model. In these situations, the filename for the subsystem consists of the subsystem name prefixed by the model name.
If you select User specified, the option Real-Time Workshop filename (no extension) option appears.
Specifies how Real-Time Workshop software is to name the file for the function it generates for the subsystem. The filename that you specify does not have to be unique. However, avoid giving non-unique names that result in cyclic dependencies (for example, sys_a.h includes sys_b.h, sys_b.h includes sys_c.h, and sys_c.h includes sys_a.h).
Appears if you select Function for the Real-Time Workshop system code option. If checked, Real-Time Workshop Embedded Coder software generates subsystem function code in which the internal data for an atomic subsystem is separated from its parent model and is owned by the subsystem. As a result, the generated code for the atomic subsystem is easier to trace and test. The data separation also tends to reduce the size of data structures throughout the model.
When you select this option, three memory section options for data appear: Memory section for constants, Memory section for internal data, and Memory section for parameters.
For details on how to generate modular function code for an atomic subsystem, see Nonvirtual Subsystem Modular Function Code Generation in the Real-Time Workshop Embedded Coder documentation.
For details on how to apply memory sections to atomic subsystems, see Applying Memory Sections to Atomic Subsystems in the Real-Time Workshop Embedded Coder documentation.
Appear if you select Function for the Real-Time Workshop system code option. The value you specify for each of these options indicates how the Real-Time Workshop Embedded Coder software is to apply memory sections to the subsystem's initialization, termination, and execution functions. These options can be useful for overriding the model's memory section settings for the given subsystem.
The possible values vary depending on what (if any) package of memory sections you have set for the model's configuration. See Memory Sections, Configuring Memory Sections, and Real-Time Workshop Pane: Memory Sections in the Real-Time Workshop Embedded Coder documentation.
If you have not configured the model with a package, Inherit from model is the only value that appears. Otherwise, the list includes Default and all memory sections the model's package contains.
| If You Want Real-Time Workshop Embedded Coder Software to... | Select... |
|---|---|
| Apply the root model's memory sections to the subsystem's function code | Inherit from model |
| Not apply memory sections to the subsystem's system code, overriding any model-level specification | Default |
| Apply one of the model's memory sections to the subsystem | The memory section of interest |
For details on how to apply memory sections to atomic subsystems, see Applying Memory Sections to Atomic Subsystems in the Real-Time Workshop Embedded Coder documentation.
Appear if you select Function for the Real-Time Workshop system code option. The value you specify for each of these options indicates how the Real-Time Workshop Embedded Coder software is to apply memory sections to the subsystem's data. These options can be useful for overriding the model's memory section settings for the given subsystem.
The list of possible values varies depending on if and what package of memory sections you have set for the model's configuration (see Configuring Memory Sections in the Real-Time Workshop Embedded Coder documentation). If you have not configured the model with a package, Inherit from model is the only value that appears. Otherwise, the list includes Default and all memory sections the model's package contains.
| If You Want Real-Time Workshop Embedded Coder Software to... | Select... |
|---|---|
| Apply the root model's memory sections to the subsystem's data | Inherit from model |
| Not apply memory sections to the subsystem's data, overriding any model-level specification | Default |
| Apply one of the model's memory sections to the subsystem | The memory section of interest |
For details on how to apply memory sections to atomic subsystems, see Applying Memory Sections to Atomic Subsystems in the Real-Time Workshop Embedded Coder documentation.
Sample Time | Depends on the blocks in the subsystem |
Dimensionalized | Depends on the blocks in the subsystem |
Multidimensionalized | Depends on the blocks in the subsystem |
Zero Crossing | Yes, for enable and trigger ports if present |
![]() | Stop Simulation | Sum, Add, Subtract, Sum of Elements | ![]() |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |