Choose Among Types of Model Components

Step 1 of 3 in Component-Based Modeling Guidelines

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.

Simulink Components

The different types of Simulink^® components serve a variety of modeling requirements.

Type of Component	Definition	Source of Contents	Implementation in Model
Subsystem	Unique group of blocks with a dynamic interface, which can be visual or functional.	None — Contents must be manually added to each subsystem	Subsystem block
Subsystem reference	Reference to a reusable group of blocks with a dynamic interface, which can be visual or functional.	Subsystem file (`.slx`) that contains the referenced subsystem	Subsystem Reference block
Model reference	Reference to a model with a well-defined interface, which is functional and independent of the parent model.	Model file (`.slx`) that contains the referenced model	Model block
Variant system	Multiple implementations of a component with only one active implementation. Variant systems allow you to address different sets of requirements within a single model. Variant choices can be any other component type, including a combination of component types.	None — Variant choices must be manually added to each variant system	Variant Subsystem block
Linked block, which can be linked to any component that is stored in a library	Linked instance of block that is stored in a library. If you disable the library link, each instance of a linked block can be unique. 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.	Library file (`.slx`) that contains the parent library block, or prototype block	Block with a library link

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.

High-Level Component Selection Guidelines

This flow chart provides a starting point for choosing a component type.

Before implementing a component based on the result from this flow chart, consider additional modeling requirements. For information on component compatibility with modeling requirements, see Compare Capabilities of Model Components.

If you expect a subsystem to grow, make it atomic so that it functionally groups the blocks and executes them together. Functionally grouping the blocks makes it easier to convert the subsystem to a referenced model.

Documentation