A model becomes a referenced model when a Model block in some other model references it. Any model can function as a referenced model, and can continue to function as a separate model.
For a video explaining how to create model references, see Getting Started with Model Referencing.
If the Simulink® block references a model that contains Assignment blocks that are not in an iterator subsystem, you cannot place a Model block in an iterator subsystem.
In a configurable subsystem with a Model block, during model update, do not change the subsystem that the configurable subsystem selects.
To create a reference to a model (referenced model) in another model (parent model):
If the folder containing the referenced model you want to reference is not on the MATLAB® path, add the folder to the MATLAB path.
In the referenced model:
Set Configuration Parameters Model Referencing Total number of instances allowed per top model to:
One, if the hierarchy uses the model at most
Multiple, to use the model more than once per top
model. To reduce overhead, specify
Multiple only when
Zero, which precludes referencing the model.
Create an instance of the Model block in the parent model by dragging a Model block instance from the Ports & Subsystems library to the parent model. The new block is initially unresolved (specifies no referenced model).
Double-click the Model block to open the parameter dialog box
Enter the name of the referenced model in the Model
name field. This name must contain fewer than 60 characters, exclusive
For information about Model Arguments, see Specify Different Value for Each Instance of Reusable Model.
For information about the Simulation mode, see Simulate Model Reference Hierarchies.
Click OK or Apply.
If the referenced model contains any root-level inputs or outputs, Simulink displays corresponding input and output ports on the Model block instance that you have created. Use these ports to connect the referenced model to other ports in the parent model.
A signal that connects to a Model block is functionally the same signal
outside and inside the block. Therefore, that signal is subject to the restriction that a
given signal can have at most one associated signal object. See
Simulink.Signal for more information. For information about connecting a bus
signal to a referenced model, see Bus Usage Requirements.
To reuse an algorithm (a set of connected blocks that perform a repeatable function), instead of copying and pasting the blocks, you can encapsulate the algorithm in a referenced model and refer to that model with multiple Model blocks. Each Model block is an instance of the algorithm.
Encapsulating a reusable algorithm in a referenced model:
Decreases the effort of maintance—to change the algorithm, you make the modifications only once.
Makes models easier to understand at a glance—the Model blocks indicate that they refer to the same algorithm (the same referenced model).
Helps prepare your model for efficient code generation (Simulink Coder™)—the generated code calls a reentrant function instead of repeating the algorithm operations line by line.
To enable reuse of a referenced model, set Configuration Parameters > Model Referencing > Total number of instances allowed per top model to
Multiple (the default setting).
Alternatively, to reuse an algorithm, you can create a custom library subsystem. To decide which technique to use, see Componentization Guidelines. To iteratively repeat an algorithm over multiple similar signals in the same model, consider using a For Each subsystem. See Repeat an Algorithm Using a For Each Subsystem.
By default, each instance (each Model block) reads from and writes to a separate copy of the signals and block states in the model. Therefore, the instances do not interact with each other through shared signal or state data.
To share a piece of data between all of the instances (for example, an accumulator or a fault indicator), model the data as a data store.
To restrict access to the data so that only the blocks in the referenced model can read from and write to it, use a Data Store Memory block in the model and select the Share across model instances parameter. For an example, see Share Data Between Instances of a Reusable Algorithm.
To allow access to the data outside the referenced model (for example, in
the parent model or in other sibling referenced models), use a global data
store, which is a
Simulink.Signal object in the base
workspace or a data dictionary.
For more information about data stores, see Model Global Data by Creating Data Stores.
For some applications, you can reuse an algorithm only if you can configure each instance to use a different value for a block parameter (such as the setpoint of a controller or a filter coefficient). The instances differ only in the value of the parameter.
By default, a block parameter has the same value in each instance (each Model block) of a reusable referenced model. To specify a different value for each instance, define a model argument. For more information, see Parameterize Instances of a Reusable Referenced Model.
If a referenced model has any of these characteristics, the model must specify
Total number of instances allowed per top model as
One. No other instances of the model can exist in the
The model contains any To File blocks.
The model references another model that is set to single instance.
The model contains a state or signal with a non-auto storage class.
The model uses one of these Stateflow® constructs:
Stateflow graphical functions
The referenced model executes in accelerator mode and has any of these characteristics:
A subsystem that is marked as a function
An S-function that is either not inlined or is inlined but does not
set the option
A function-call subsystem that Simulinkforces to be a function and is called by a wide signal
An error occurs in either of these cases:
You do not set the parameter correctly.
Another instance of the model is in the hierarchy, in either normal mode or accelerator mode.
You can mask a model and reference the masked model from a Model block. With a model mask, you can control the appearance of corresponding Model blocks and customize the way the blocks display model arguments. For more information about block masks, see Introduction to Model Mask.