Performance benefits that scale — Reduce memory usage and the time
required to load and simulate models.

Component variants — Choose among multiple implementations of a
component.

Intellectual property protection — Limit functionality and content
visibility for components that you share with third parties.

Should You Create Model Components?

Considering the work required to define and manage components, you should use
component-based modeling only when the benefits outweigh the cost.

Separating an existing Simulink model into components is analogous to taking a large piece of code (C,
Java, or MATLAB® code) and breaking it down into multiple functions. The conversion can
require significant effort and extensive modifications if the design is not modular
from the beginning.

Poor component definition — The scope of subsystems that are grown
over time can fail to meet component requirements. For example, they
might contain too much or too little functionality to be reused, to
generate code that integrates with legacy functionality, or to support
hardware-in-the-loop tests.

Merge conflicts — If additional engineers begin to work on a model
that was originally designed for development by a single engineer, they
can encounter time-consuming and error-prone merges.

Algebraic loops — If a single engineer develops a model from the
bottom up, they are likely to group blocks into subsystems as model
complexity increases. The subsystems within the model are likely visual
groupings that do not affect model execution. When you make these
subsystems atomic, or convert them to referenced models, you can
introduce unwanted algebraic loops that are difficult to diagnose and
fix.

Components are also useful when a design becomes too complicated for one person to
manage all of the details. For example, a complicated model can be a model that has: