Explore Types of Model Components

Step 1 of 3 in Component-Based Modeling Guidelines

• 1
• 2
• 3

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 (.slx or .mdl) that contains the parent library block, or prototype block	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 (.slx or .mdl) that contains the referenced subsystem	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 (.slx, .mdl, or .slxp) that contains the referenced model, which may be a protected model	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 (.slxc). For more information, see Share Simulink Cache Files for Faster Simulation.	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.