A model reference is a reference to another model using a Model block. These references create model hierarchy. Each referenced model has a defined interface that specifies the properties of its inputs and outputs. The defined interface makes the behavior of the referenced model independent of its context in the model hierarchy. Model references are ideal for code reuse, unit testing, parallel builds, and large components. They can also reduce file contention and merge issues.
To determine whether referenced models meet your modeling requirements, see Component-Based Modeling Guidelines.
To learn about code generation for model reference hierarchies, see Referenced Models (Simulink Coder).
To create a protected model, see Model Protection (Simulink Coder).
To perform SIL/PIL testing for a model reference hierarchy, see SIL and PIL Simulations (Embedded Coder).
|Analyze and visualize model referencing dependencies with or without library dependencies
|Find referenced models and Model blocks in model hierarchy
|Model hierarchy path composed of referenced models and Model blocks (Since R2023b)
|Update variants, linked blocks, and model references to reflect changes (Since R2023a)
|Fully specified Simulink block path
|Specify root folders for files generated by diagram updates and model builds
|Force update to Model block to reflect changes to referenced model (Since R2020a)
|Convert subsystem to model reference
|Build standalone executable file or model reference target for model
|Query contents of Simulink cache files (Since R2020b)
|Unpack simulation and code generation targets from Simulink cache file (Since R2020b)
|Create harness model that provides isolated environment for testing protected model (Since R2020b)
|Return information about publisher that signed the protected model (Since R2020a)
|Verify digital signature on protected model (Since R2020a)
|Suppress digital signature verification of protected models (Since R2020b)
|Option to conditionally, always, or never rebuild model reference targets
|Never rebuild diagnostic
|Diagnostic action to take when model reference target must be rebuilt
|Enable parallel model reference builds
|Option to build a model reference hierarchy in parallel whenever possible
|MATLAB worker initialization for builds
|Options for how to initialize MATLAB workers for parallel builds
|Enable strict scheduling checks for referenced models
|Option to check consistency of scheduling and sample time in referenced models
|Total number of instances allowed per top model
|Number of references to this model that can occur in another model
|Propagate sizes of variable-size signals
|Option to specify how variable-size signals propagate through referenced models
|Minimize algebraic loop occurrences
|Option to try to eliminate artificial algebraic loops related to referenced model
|Propagate all signal labels out of the model
|Option to pass propagated signal names out of referenced model
|Use local solver when referencing model
|Option to use local solver for referenced model (Since R2022a)
|User-created files and data that potentially impact simulation results
|Perform consistency check on parallel pool
|Option to perform checks on parallel pool before starting parallel build (Since R2021a)
|Include custom code for referenced models
|Option to use custom code in model reference simulation target
|Pass fixed-size scalar root inputs by value for code generation
|Option to pass scalar input to model by reference or value
Model Referencing Diagnostics
|Model block version mismatch
|Diagnostic action to take when Model block does not represent current version of referenced model
|Port and parameter mismatch
|Diagnostic action to take when port or parameter does not match between Model block and referenced model
|Unsupported data logging
|Diagnostic action to take when data logging is unsupported
|No explicit final value for model arguments
|Diagnostic action to take for model argument with default value at top-level model reference (Since R2020b)
Determine When to Reference Models
- Component-Based Modeling Guidelines
Consider componentization for large models and multiuser development teams.
- Model Reference Basics
Create a model hierarchy by referencing one model in another model. A referenced model contains blocks that execute together as a unit.
- Model Reference Requirements and Limitations
Model references have requirements and limitations relating to features such as reusability, simulation modes, masking, and debugging.
Create Model References
- Reference Existing Models
Include a model in another model.
- Reference Protected Models from Third Parties
Use a protected model that you received from a third party.
- Convert Subsystems to Referenced Models
Prepare a subsystem for conversion, convert the subsystem to a model, and compare simulation results before and after conversion.
- Define Model Reference Interfaces
Ports in the referenced model correspond with ports at the model reference. Signals that cross the model boundary must meet certain requirements.
- Inspect Model Hierarchies
Examine the contents, structure, model versions, and logged signals in a model hierarchy.
Configure Model References
- Set Configuration Parameters for Model Hierarchies
Configuration parameter values can be different in top models and referenced models. Some configuration parameter values have special requirements or behavior with model referencing.
- Conditionally Execute Referenced Models
Execute referenced models conditionally, similar to conditionally executed subsystems.
- Referenced Model Sample Times
A referenced model can inherit sample times from the model that references it.
- Parameterize Instances of a Reusable Referenced Model
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.
- Parameterize a Referenced Model Programmatically
This example shows how to programmatically configure multiple instances of a referenced model to use different values for the same block parameter.
- Group Multiple Model Arguments into a Single Structure
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.
- Configure Instance-Specific Data for Lookup Tables Programmatically
When you use
Simulink.LookupTableobjects 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.
Simulate Model Hierarchies
- Choose Simulation Modes for Model Hierarchies
Select the simulation mode for models in a model hierarchy.
- Manage Simulation Targets for Referenced Models
A simulation target, or SIM target, is a MEX-file that implements a referenced model that executes in accelerator mode.
- Share Simulink Cache Files for Faster Simulation
Use Simulink cache files to share build artifacts that let you avoid the cost of a first-time build.
- Override Model Reference Simulation Modes
When a top model simulates in normal mode, you can override the simulation mode used for model references without dirtying their parent models.
- Reduce Update Time for Referenced Models by Using Parallel Builds
Reduce diagram update time for large model reference hierarchies by using parallel builds.
- Simulate Conditionally Executed Referenced Models
Run a standalone simulation of a conditionally executed referenced model.
- Simulate Multiple Referenced Model Instances in Normal Mode
Simulate a model that contains multiple instances of a referenced model.