To move the contents of a subsystem into the containing system, you can expand the subsystem.
For example, the
sldemo_enginewc model includes the Combustion subsystem.
After you expand the Combustion subsystem, the top level of the
sldemo_enginewc model includes the blocks and signals of the Combustion
subsystem. The expansion removes the Subsystem block and the
Inport and Outport blocks.
Expand a subsystem if you want to flatten a model hierarchy by bringing the contents of a subsystem up one level.
Expanding a subsystem is useful when refactoring a model. Flattening a model hierarchy can be the end result, or just one step in refactoring. For example, you could pull a set of blocks up to the parent system by expanding the subsystem, deselect the blocks that you want to leave in the parent, and then create a subsystem from the remaining selected blocks.
You can expand virtual subsystems that are not masked, linked, or commented. If you try to expand a masked, linked, or commented subsystem using the Simulink® Editor, a message gives you the option of having Simulink modify the subsystem so that you can then expand it.
|Kind of Subsystem||Modification|
Removes all masking information
Breaks the link
Uncomments the subsystem
You cannot expand these subsystems:
Subsystems with the Read/Write permissions parameter set to
Subsystems with an
Subsystems with linked requirements (using Simulink Requirements™ software)
To interactively expand a subsystem, right-click a Subsystem block and, from the context menu, select Subsystem & Model Reference > Expand Subsystem.
To programmatically expand a subsystem, use the
Subsystem expansion applies to the currently selected subsystem level. Simulink does not expand other subsystems in a nested subsystem hierarchy.
To improve readability when you expand nested subsystems, start by expanding the highest-level subsystem that you want to expand, and then work your way down the hierarchy as far as you want to expand.
When you expand a subsystem, Simulink:
Removes the Subsystem block
Removes the root Inport, root Outport, and Simscape™ Connection Port blocks that were in the subsystem
Connects the signal lines that went to the input and output ports of the subsystem directly to the ports of the blocks in the model that connected to the subsystem
Distributes blocks and routes signals for readability.
The paths for blocks that were in the subsystem that you expanded change. After expansion, update scripts and test harnesses that rely on the hierarchical paths to blocks that were in the subsystem that you expanded.
If you expand a subsystem with a missing connection on the outside or inside of the subsystem, Simulink keeps the line labels, but uses the signal name and properties from just one of the lines. For lines corresponding to:
A subsystem input port, Simulink uses the signal name and properties from the signal in the system in which the subsystem exists
A subsystem output port, Simulink uses the signal name and properties from the subsystem
The display layers of blocks (in other words, which blocks appear in front or in back for overlapping blocks) does not change after expansion. Blocks in front of the Subsystem block remain above the expanded contents, and blocks below the Subsystem block remain under the expanded contents.
When you compile a model, Simulink sorts the blocks in terms of the order of block execution. Expanding a subsystem can change block path names, which, in rare cases, can impact the block execution order.
If you explicitly set block execution order by setting block priorities within a subsystem, Simulink removes those block priority settings when you expand that subsystem.
Expanding a subsystem that contains a Data Store Memory block that other subsystems read from or write to can change the required data store write and read sequence. You may need to restructure your model. For details, see Order Data Store Access.