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.
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 of the context of the Model block, including:
Inclusion by reference
Incremental code generation
Independent configuration sets
|Analyze and visualize model referencing dependencies with or without library dependencies|
|Find referenced models and Model blocks in model hierarchy|
|Fully specified Simulink block path|
|Specify root folders for files generated by diagram updates and model builds|
|Update Model blocks to reflect changes to referenced models|
|Convert subsystem to model reference|
|Build standalone executable file or model reference target for model|
|Query contents of Simulink cache files|
|Unpack simulation and code generation targets from Simulink cache file|
|Create harness model that provides isolated environment for testing protected model|
|Return information about publisher that signed the protected model|
|Verify digital signature on protected model|
|Suppress digital signature verification of protected models|
Create a model hierarchy by referencing one model in another model. A referenced model contains blocks that execute together as a unit.
Consider componentization for large models and multiuser development teams.
Model references have requirements and limitations relating to features such as reusability, simulation modes, masking, and debugging.
Include a model in another model.
Use a protected model that you received from a third party.
Prepare a subsystem for conversion, convert the subsystem to a model, and compare simulation results before and after conversion.
Ports in the referenced model correspond with ports at the model reference. Signals that cross the model boundary must meet certain requirements.
Examine the contents, structure, model versions, and logged signals in a model hierarchy.
Configuration parameter values can be different in top models and referenced models. Some configuration parameter values have special requirements or behavior with model referencing.
Execute referenced models conditionally, similar to conditionally executed subsystems.
A referenced model can inherit sample times from the model that references it.
When you model a reusable component as a referenced model, to configure each instance of the component to use different values for block parameters, create model arguments.
This example shows how to programmatically configure multiple instances of a referenced model to use different values for the same block parameter.
This example shows how to programmatically configure multiple instances of a referenced model to use different values for the same block parameter by using structures.
When you use
Simulink.LookupTable objects to store and configure lookup table data for ASAP2 or AUTOSAR code generation (for example, STD_AXIS or CURVE), you can configure the objects as model arguments.
Select the simulation mode for models in a model hierarchy.
A simulation target, or SIM target, is a MEX-file that implements a referenced model that executes in accelerator mode.
Use Simulink cache files to share build artifacts that let you avoid the cost of a first-time build.
Reduce diagram update time for large model reference hierarchies by using parallel builds.
Run a standalone simulation of a conditionally executed referenced model.
Simulate a model that contains multiple instances of a referenced model.