Learn more about Simulink

Model - Include model as block in another model

Library

Ports & Subsystems

Description

The Model block allows you to include a model as a block in another model. The included model is called a referenced model, and the model containing it (via the Model block) is called the parent model.

The Model block displays input ports and output ports corresponding to the referenced model's top-level input and output ports. These ports allow you to connect the referenced model to other blocks in the parent model. See Referencing a Model for more information.

A Model block can specify the referenced model statically as a Model block parameter value, which must name the model literally, or dynamically depending on base workspace values, as described in Using Model Reference Variants. By default, the contents of a referenced model are user-visible, but you can hide the contents as described in Protecting Referenced Models.

A signal that connects to a Model block is functionally the same signal outside and inside the block. A given signal can have at most one associated signal object, so the signal connected to the Model block cannot have a signal object in both the parent and the referenced models. See Simulink.Signal and Multiple Signal Objects for more information.

Data Type Support

Determined by the root-level inputs and outputs of the model referenced by the Model block.

Parameters and Dialog Box

Model Name

Name of the model referenced by this block. This name must be a valid MATLAB identifier. The extension is optional, and if provided can be .mdl or .mdlp. See Creating a Model Reference and Protecting Referenced Models for details.

Model arguments

Names of model arguments accepted by the model referenced by this block. See Using Model Arguments for details.

Model argument values

Values to be passed as model arguments to the model referenced by this block each time the model is invoked during a simulation. Enter the values in this field as a comma-separated list in the same order as the corresponding argument names appear in the Model arguments field. See Using Model Arguments for details.

Simulation mode

The simulation mode for the model referenced by this block. See Referenced Model Simulation Modes for details.

Accelerator: Simulink software creates a MEX-file for the submodel, then executes the submodel by running the S-function. See Accelerator Mode.
Normal: Simulink software executes the submodel interpretively, as if the submodel were an atomic subsystem implemented directly within the parent model. See Normal Mode and Systems and Subsystems.
Processor-in-the-loop (PIL): This feature requires Real-Time Workshop Embedded Coder software. Simulink creates both a MEX-file and a model reference target for the submodel. The MEX-file executes the cross-compiled object code on the target processor (or equivalent instruction set simulator). See Processor-in-the-loop (PIL) mode and Verifying Compiled Object Code with Processor-in-the-Loop Simulation.

Enable Variants

Enables model reference variants and opens the Model Variants Section, which is hidden by default. See Model Variants Section and Enabling Model Variants.

Model Variants Section

When you click Enable Variants, the Model block dialog box expands to show the Model variants Section. The dialog then looks like this:

The standard Model block capabilities remain available on the right, and have the same capabilities, although some labels have changed slightly to accommodate model variants. See Using Model Reference Variants for information about using the Model Reference Variants section. The parameters specific to model reference variants are:

Disable Variants: Disables model reference variants and hides the Model Variants Section. The block retains any information you have entered and approved by clicking Apply or OK. See Disabling Model Variants.
Variant objects: A list (shown as a table) of Simulink.Variant objects whose Boolean expressions determine which is the active variant. See Example Variant Objects and Implementing Variant Objects.
Override variant conditions and use the following variant: Whether to override the variant conditions and make a specified variant the active variant. See Overriding Variant Conditions.
Variant: The name of the variant to use if Override variant conditions and use the following variant is selected. See Overriding Variant Conditions.
Generate preprocessor conditionals: Controls whether generated code contains preprocessor conditionals. This checkbox is relevant only to code generation, and has no effect on the behavior of a model in Simulink. The checkbox is available only for ERT targets when Inline parameters is 'on'. See Generating Code Variants for Variant Models for more information.

Navigating a Model Block

Model blocks behave differently from other blocks when double-clicked. This customized behavior provides the results most likely to be useful given the current status of the Model block, as follows:

Double-clicking the prototype Model block in the Ports & Subsystems library opens its Block Parameters dialog box for inspection, but does not allow you to specify parameter values.
Double-clicking an unresolved Model block opens its Block Parameters dialog box. You can then resolve the block by specifying a Model name.
Double-clicking a resolved Model block opens the model that the block references. You can also open the model by choosing Open Model from the Context or Edit menu.

To display the Block Parameters dialog box for a resolved Model block, choose Model Reference Parameters from the Context or Edit menu.

Model Blocks and Direct Feedthrough

When a Model block is part of a cycle, and the block is a direct feedthrough block, an algebraic loop can result. An algebraic loop in a model is not necessarily an error, but it may not give the expected results. See:

Algebraic Loops for information about direct feedthrough and algebraic loops.
Highlighting Algebraic Loops for information about seeing algebraic loops graphically
Displaying Algebraic Loop Information for information about tracing algebraic loops in the debugger.
The Diagnostics Pane: Solver pane Algebraic loop option for information about detecting algebraic loops automatically.

Direct Model Block Feedthrough Caused by Submodel Structure

A Model block may be a direct feedthrough block due to the structure of the referenced model. Where direct feedthrough results from submodel structure, and causes an unwanted algebraic loop, you can:

Automatically eliminate the algebraic loop using techniques described in:
Manually insert one or more Unit Delay blocks as needed to break the algebraic loop.

Direct Model Block Feedthrough Caused by Model Configuration

ERT-based targets provide the option Configuration Parameters > Real-Time Workshop Pane > Interface > Single output/update function. This option controls whether generated code has separate output and update functions, or a combined output/update function. See:

Embedded Model Functions for information about separate and combined output and update functions.
Single output/update function for information about specifying whether code has separate or combined functions.

When Single output/update function is enabled (the default) a Model block has a combined output/update function, which makes the block a direct feedthrough block for all inports regardless of the structure of the referenced model. Where an unwanted algebraic loop results, you can:

Disable Single output/update function. The code for the Model block then has separate output and update functions, eliminating the direct feedthrough and hence the algebraic loop.
Automatically eliminate the algebraic loop using techniques described in:
Manually insert one or more Unit Delay blocks as needed to break the algebraic loop.

Characteristics

Direct Feedthrough

If Single output/update function is enabled (the default), a Model block is a direct feedthrough block regardless of the structure of the referenced model.

If Single output/update function is disabled, a Model block may or may not be a direct feedthrough block, depending on the structure of the referenced model.

Scalar Expansion

Depends on model referenced by this block.

Multidimensionalized

Yes