Explore Types of Model Components
Simulink® provides multiple ways for you to organize your model into components. The different types of components target different requirements.
As you define a component, consider these potential requirements.
File contention — You can have larger components if only one person is working on each. If you must share components between several people, you should divide the design into smaller logical pieces. If multiple people must edit the same file, see Port or Restore Model Changes in Comparison Report.
Reusability — If you expect to use a group of blocks multiple times in a model, define the group of blocks in a reusable component. By avoiding duplication, you make maintaining the model easier. To refactor an existing model with duplication, see Refactor Models to Improve Component Reuse (Simulink Check).
Code generation — If you must generate standalone code for a physical component, such as a digital controller, you should have one component that represents the physical component and has a well-defined interface.
Verification cost — If part of a model changes frequently and has high testing costs, you should manage this part of the model as a component in a separate file. When components are defined in separate files, you can control and trace changes using project source control. For more information on source control, see Configuration Management.
Simulation speed — Using different solvers for components with different numerical properties can increase simulation speed. Similarly, grouping blocks based on their sample rate can increase simulation speed. For more information, see Solver Profiler and Improve Simulation Performance Using Performance Advisor.
Modeling requirements can influence the size of your components. For example, models with fewer than 500 blocks are easier to test than larger models. However, simulation can be faster for model hierarchies when referenced models contain more than 500 blocks.
Simulink Components
The different types of Simulink components serve a variety of modeling requirements.
| Modeling Requirement | Type of Component | Source of Contents | Implementation in Model | More Information |
|---|---|---|---|---|
| Simplifying the block diagrams of other components | Subsystem A subsystem is a unique group of blocks with a dynamic interface that can inherit the properties of its inputs and outputs. | None — Contents must be manually added to each subsystem | Subsystem block
| Group Blocks into Subsystems |
| Storing utilities and blocksets | Linked subsystem A linked subsystem is a linked instance of a Subsystem block that is stored in a library. If you disable the library link, each instance of a linked block can be unique. | Library file ( | Subsystem block with a library link
| Linked Blocks |
| Reducing file contention and merge issues | Subsystem reference A subsystem reference is a reference to a reusable group of blocks with a dynamic interface that can inherit the properties of its inputs and outputs. | Subsystem file ( | Subsystem Reference block
| Create and Use Referenced Subsystems in Models |
| Code reuse, unit testing, parallel builds, and large components | Model reference A model reference is a reference to a model with a defined interface that specifies the properties of its inputs and outputs. | Model file ( | Model block
| Model Reference Behavior and Capabilities |
Multiple types of components can address the same requirement. For example, you can reduce file contention and merge issues with a model reference, and you can unit test a subsystem.
Simulink models can use a combination of these components. For example, to minimize file contention for a large model, you can convert subsystems to referenced subsystems and models, both of which are saved in separate files.
When you drag a subsystem reference or model reference from a library into a model, it directly references the subsystem file or model file that defines its contents. It has a library link only when the parent library block has a mask applied directly to it. Typically, you should use model masks, which are saved in the referenced file and do not require a library link.
High-Level Component Selection Guidelines
This flow chart provides a starting point for choosing a component type.
Tip
If you expect a subsystem to grow, make the subsystem atomic so that the subsystem functionally groups the blocks. An atomic subsystem behaves like a single block, or atomic unit, when the parent model executes. Atomic behavior is necessary for you to convert a subsystem to a model reference.
This table provides the information from the flow chart and elaborates on how your choice of component type can improve performance for components that are reused multiple times in a hierarchy and contain many blocks.
| Component Use | Type of Component |
|---|---|
The component will require a defined interface or standalone behavior. | Consider a model reference. |
The component will contain enough blocks and be reused enough to benefit from accelerator mode simulation of referenced models. Whether a model
hierarchy benefits from accelerator mode simulation of referenced models depends
on many factors. For each referenced model that simulates in accelerator mode,
Simulink must build and compile a simulation target. These targets are reused
for additional instances of the referenced model, which accelerates simulation
when the model hierarchy contains many instances of the referenced model. If the
referenced model is unchanged, you can reuse its simulation target, which is
stored in a Simulink cache file ( | Consider a model reference. |
The component will be a published utility, which rarely changes. | Consider a linked subsystem. |
| The component will be reused or managed in a source control system and will not require a defined interface, benefit from model reference simulation targets, or be a published utility. | Consider a subsystem reference. |
The component will not be reused or managed in a source control system. | Consider a subsystem. |
For an overview of when to use different componentization techniques, see Component-Based Modeling in Simulink (4 min, 28 sec).
Modeling Requirement Considerations
Before implementing a component based on the high-level guidelines, consider additional modeling requirements. For example, if you require physical connections at the component interface, you must use a subsystem, linked subsystem, or referenced subsystem. If you require intellectual property protection, you must create a protected model, which can be referenced.
To determine whether a component meets your modeling requirements, see Compare Capabilities of Model Components.
