Explore Types of Model Components
Useful model components have a well-defined scope, perform functionality defined by requirements, and form part of a larger system.
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 Merge Simulink Models from the 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.
The different types of Simulink® components serve a variety of modeling requirements.
|Type of Component||Definition||Source of Contents||Implementation in Model||More Information|
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
|Group Blocks into Subsystems|
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
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
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 Reference Basics|
Simulink models can use any 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
Each of the types of model components has an ideal use case:
Subsystem — Ideal for simplifying the block diagrams of other components
Linked subsystem — Ideal for utilities and blocksets
Subsystem reference — Ideal for reducing file contention and merge issues
Model reference — Ideal for code reuse, unit testing, parallel builds, and large components
The ideal use cases are a subset of the possible use cases for each type of component. For example, you can also reduce file contention and merge issues with a model reference, and you can also unit test a subsystem.
If you expect a subsystem to grow, make it atomic so that it 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.
For an overview of when to use different componentization techniques, see Component-Based Modeling in Simulink (4 min, 28 sec).
This flow chart provides a starting point for choosing a component type.
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.
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.