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	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
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
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
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

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.

Tip

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.

Consider a subsystem if the component meets all of these conditions:

• The component will not require a defined interface or standalone behavior.

• The component will not be managed in a source control system.

• The component will not be reused.

Consider a linked subsystem if the component meets all of these conditions:

• The component will not require a defined interface or standalone behavior.

• The component will either be managed in a source control system or be reused.

• The component will not contain enough blocks and be reused enough to benefit from accelerator mode simulation of referenced models.

• The component will be a published utility, which rarely changes.

Consider a subsystem reference if the component meets all of these conditions:

• The component will not require a defined interface or standalone behavior.

• The component will either be managed in a source control system or be reused.

• The component will not contain enough blocks and be reused enough to benefit from accelerator mode simulation of referenced models.

• The component will not be a published utility, which rarely changes.

Consider a model reference if the component meets either of these conditions:

• The component will require a defined interface or standalone behavior.

• 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.

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.