You can include one model in another by using a Model block. Each instance of a Model block is a model reference. For simulation and code generation, blocks within a referenced model execute together as a unit. The model that contains a referenced model is a parent model. A collection of parent and referenced models constitutes a model hierarchy.
A model can function as both a standalone model and a referenced model, without changing the model or any entities derived from it. To use a referenced model as a standalone model, the referenced model cannot depend on data that is available only from a higher-level model.
Like subsystems, model references allow you to organize large models hierarchically. Like libraries, model references allow you to define a set of blocks once and use it repeatedly. Model references provide several advantages that are unavailable with subsystems and libraries. Several of these advantages result from referenced models compiling independent from the context of the Model block, including:
You can develop a referenced model independently from the models that use it.
With a Simulink® Coder™license, you can obscure the contents of a referenced model, allowing you to distribute the model without revealing its intellectual property.
With a Simulink license, you can reference a protected model provided by a third party. Depending on the granted protected-model permissions, you can view, simulate, and generate code for the protected model.
Inclusion by reference
You can reference a model multiple times without making redundant copies, and multiple models can reference the same model.
Simulink software loads a referenced model when it is needed, which speeds up model loading.
Simulink software can convert a referenced model to code and simulate the model by running the code, which is faster than interactive simulation.
Incremental code generation
Accelerated simulation generates code only if the model has changed since the code was previously generated.
Independent configuration sets
The configuration set used by a referenced model can differ from the configuration set of its parent or other referenced models.
For a video summarizing model reference advantages, see Modular Design Using Model Referencing.
To compare model references, subsystems, and libraries, see Capabilities of Model Components. You can use multiple componentization techniques in the same model.
Referenced models can contain Model blocks that reference lower-level models. The top model is the topmost model in a hierarchy of referenced models. Where only one level of model reference exists, the parent model and top model are the same. To prevent cyclic inheritance, a Model block cannot refer directly or indirectly to a model that is superior to it in the model hierarchy. This figure shows cyclic inheritance.
A parent model can contain multiple Model blocks that reference the
same referenced model, as long as the referenced model does not define global data. For
sldemo_mdlref_basic model includes Model blocks
that reference three instances of the same referenced model,
The referenced model can also appear in other parent models at any level.
A Model block displays input, output, and control ports that correspond to root-level input, output, and control ports of the model it references. To connect the referenced model to other elements of the parent model, use these Model block ports. Connecting a signal to a Model block port connects the signal to the corresponding port in the referenced model.
sldemo_mdlref_basic, each Model block has
three inputs: two Constant blocks and a Pulse Generator
block. Each Model block has one output signal logged to a scope. Because
the input signal from each Pulse Generator block uses a different sample
time, the output signal from each Model block differs for each model
To connect to the parent model, referenced model
includes three Inport blocks (upper,
lower, and input) and one
Outport block (output). If you change the ports in
the referenced model, refresh the Model block to reflect these
Signal attributes in the referenced model are independent from the context of the Model block. For example, signal dimensions and data types do not propagate across the Model block boundary. To define signal attributes in the referenced model, define block parameters for root-level Inport and In Bus Element blocks.
For more information, see Model Reference Interface.
Each model has its own workspace for storing variable values. In a model hierarchy, each model workspace acts as a unique namespace. Therefore, you can use the same variable name in multiple model workspaces. To share data among models, you can use a data dictionary.
Duplicate data definitions can exist in a model reference hierarchy under these conditions:
Each model in the hierarchy can see only one definition.
Definitions must be the same across models in the hierarchy.
For more information on where you can store variables and objects, see Determine Where to Store Variables and Objects for Simulink Models.
To use an external signal to control whether a Model block executes during simulation, see Modify Referenced Models for Conditional Execution.
Variant Subsystem blocks can contain Model blocks as variant systems. For information on variant systems, see What Are Variants and When to Use Them.
By default, a block parameter has the same value in each Model block
instance of a reusable referenced model. To specify a different block parameter value
for each instance of a reusable referenced model, create model arguments. For example,
if you add a Gain block to model
sldemo_mdlref_counter, model arguments allow each of the three
instances of this model to use different gain values. See Parameterize Instances of a Reusable Referenced Model.
With a model mask, you can control the appearance of Model blocks and customize the way the blocks display model arguments. For model mask requirements, see Model Masks.
You can simulate a referenced model either interpretively (in normal mode) or by compiling the referenced model to code and executing the code (in accelerator mode). For details, see Simulate Model Hierarchies.
The first time that you simulate or update the diagram for a model that builds a model reference simulation (SIM) target, the build process creates a Simulink cache file. The cache file stores build artifacts and speeds up successive model builds. For additional benefits and an example workflow, see Share Simulation Builds for Faster Simulations.
To learn about considerations when generating code for a referenced model, see Code Generation of Referenced Models (Simulink Coder).