|On this page…|
You can include one model in another by using Model blocks. Each instance of a Model block represents a reference to another model, called a referenced model or submodel. For simulation and code generation, the referenced model effectively replaces the Model block that references it. The model that contains a referenced model is its parent model. A collection of parent and referenced models constitute a model reference hierarchy. A parent model and all models subordinate to it comprise a branch of the reference hierarchy.
The interface of a referenced model consists of its input and output ports (and control ports, in the case of a conditional referenced model) and its parameter arguments. A Model block displays inputs and outputs corresponding to the root-level inputs and outputs of the model it references. These ports enable you to incorporate the referenced model into the block diagram of the parent model.
Use the ports on a Model block to connect the submodel to other elements of the parent model. Connecting a signal to a Model block port has the same effect as connecting the signal to the corresponding port in the submodel. For example, the Model block CounterA has three inputs: two Constant blocks and a Pulse Generator block with a sample time of .1. The Model block CounterB also has three inputs: the same two Constant blocks, and a Pulse Generator block with a sample time of .5. Each Model block has an output to a separate Scope block.
The referenced model includes Inport and Outport blocks (and possibly Trigger or Enable blocks) to connect to the parent model. The sldemo_mdlref_countersldemo_mdlref_counter model has three Inport blocks (upper, input, and lower) and one Outport block (output).
A referenced model can itself contain Model blocks and thus reference lower-level models, to any depth. 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 reference hierarchy. This figure shows cyclic inheritance.
A parent model can contain multiple Model blocks that reference the same submodel as long as the submodel does not define global data. The submodel can also appear in other parent models at any level. You can parameterize a referenced model to provide tunability for all instances of the model. Also, you can parameterize a referenced model to let different Model blocks specify different values for variables that define the behavior of the submodel. See Parameterize Model References for details.
By default, the Simulink® software executes a top model interpretively, just as it would if the model did not include submodels. Simulink can execute a referenced model interpretively, as if it were an atomic subsystem, or by compiling the submodel to code and executing the code. See Referenced Model Simulation Modes for details.
You can use a referenced model as a standalone model, if it does not depend on data that is available only from a higher-level model. An appropriately configured model can function as both a standalone model and a referenced model, without changing the model or any entities derived from it.
Like subsystems, referenced models allow you to organize large models hierarchically; Model blocks can represent major subsystems. Like libraries, referenced models allow you to use the same capability repeatedly without having to redefine it. However, referenced models provide several advantages that are unavailable with subsystems and/or library blocks:
You can develop a referenced model independently from the models that use it.
You can obscure the contents of a referenced model, allowing you to distribute it without revealing the intellectual property that it embodies.
Inclusion by reference
You can reference a model multiple times without having to make redundant copies, and multiple models can reference the same model.
Simulink loads a referenced model at the point it needs to use the model, which speeds up model loading.
Simulink 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 requires code generation 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 additional information about how model referencing compares to other Simulink componentization techniques, see Componentization Guidelines. For a video summarizing advantages of model referencing, see Modular Design Using Model Referencing
You can use the masking facility to create custom dialog boxes and icons for Model blocks. Masked dialog boxes can make it easier to specify additional parameters for Model blocks. For information about block masks, see Masking.
Simulink includes several models that illustrate model referencing.
The Introduction to Managing Data with Model Reference Introduction to Managing Data with Model Reference example introduces the basic concepts and workflow related to managing data with model referencing. To explore these topics in more detail, select the Detailed Workflow for Managing Data with Model Reference example.
The following are the most commonly needed resources for working with model referencing:
The Model block, which represents a model that another model references. See the Model block parameters in the "Ports & Subsystems Library Block Parameters" section of the Block-Specific Parameters table for information about accessing a Model block programmatically.
The Configuration Parameters > Diagnostics > Model Referencing pane, which controls the diagnosis of problems encountered in model referencing. See Diagnostics Pane: Model Referencing for details.
The Configuration Parameters > Model Referencing pane, which provides options that control model referencing and list files on which referenced models depend. See Model Referencing Pane for details.