Quantcast

Documentation Center

  • Trial Software
  • Product Updates

Model, Model Variants

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 top-level input and output ports of the referenced model. Using these ports allow you to connect the referenced model to other blocks in the parent model. See Model Reference for more information.

A Model block can specify the referenced model:

  • Statically, as a Model block parameter value, which must name the model literally

  • Dynamically, depending on base workspace values

A Model Variants block is a Model block with variants enabled. The Model block parameter dialog box contains the Enable Variants button by default. If you click the Enable Variants button, the Model Variants block parameter dialog opens. The Model Variants block parameter dialog contains the Disable Variants button by default. Therefore, you can use either the Model block or the Model Variants block for implementing model variants. For more information about how to specify a referenced model for multiple specifications, see Set Up Model Variants.

By default, the contents of a referenced model are user-visible, but you can hide the contents as described in Protected Model.

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. For more information, see Simulink.Signal.

The Model block supports signal label propagation. For details specific to model referencing and model variants, see:

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 this block references.

Settings

Default: <Enter Model Name>

The value must be a valid MATLAB® identifier.

The extension, for example, .SLX, is optional.

Tips

  • To navigate to the model that you want to reference from this block, use the Browse button to the right of the Model name parameter.

  • To confirm that the model you specify is the one you intended, you can use the Open Model button to the right of the Model name parameter.

Command-Line Information

Parameter: ModelNameDialog
Type: string
Value: Any valid value
Default: The name of the referenced model exactly as you typed it in, with any surrounding white space removed. When you set ModelNameDialog programmatically or from the dialog, Simulink® automatically sets the values of ModelName and ModelFile based on the value of ModelNameDialog.

Model arguments

Display model arguments accepted by the model referenced by this block.

Declaring a variable to be a model argument allows each instance of the model to use a different value for that variable.

Settings

Default: ''

This is a read-only parameter that displays model arguments for the model referenced by this block. To create model arguments, refer to Using Model Arguments.

Model argument values (for this instance)

Specify values to be passed as model arguments to the model referenced by this block each time the simulation invokes the model.

You can enter the values as literal values, variable names, MATLAB expressions, and Simulink parameter objects. Any symbols used resolve to values as described in Symbol Resolution Process. All values must be numeric (including objects with numeric values).

Settings

Enter the values in this parameter as a comma-separated list in the same order as the corresponding argument names in the Model arguments field.

Command-Line Information

Parameter: ParameterArgumentValues
Type: string
Value: Any valid value
Default: ''

Simulation mode

Set the simulation mode for the model referenced by this block. This setting specifies whether to simulate the model by generating and executing code or by interpreting the model in Simulink.

Settings

Default: Accelerator

Accelerator

Creates a MEX-file for the sub model, then executes the sub model by running the S-function.

Normal

Executes the sub model interpretively, as if the sub model were an atomic subsystem implemented directly within the parent model.

Software-in-the-loop (SIL)

This option requires the Embedded Coder software. Generates production code using model reference target for the sub model. This code is compiled for, and executed on, the host platform.

Processor-in-the-loop (PIL)

This option requires the Embedded Coder software. Generates production code using model reference target for the sub model. This code is compiled for, and executed on, the target platform. A documented target connectivity API supports exchange of data between the host and target at each time step during the PIL simulation.

Command-Line Information

Parameter: SimulationMode
Type: string
Value: 'Accelerator' | 'Normal' | 'Software-in-the-loop (SIL)' | 'Processor-in-the-loop (PIL)'
Default: 'Accelerator'

See Also

Enable variants

Enables variants and opens the Model Variants block parameter dialog box, which is hidden by default. The Model Variants block parameter dialog is the default block parameter dialog for the Model Variants block.

Settings

Default: Disabled

Dependencies

This button enables the Model Variants Sections, which include: Variant choices table, Model parameters for the chosen variant in table section, parameters to override variants, and a Code generation section.

The following example shows the Model variants options from the example model sldemo_mdlref_variantssldemo_mdlref_variants.

See Also

Set Up Model Variants

Variant choices

Displays a table of variant choices, associated model names, variant controls, and conditions. The variant control can be a boolean condition expression, or a Simulink.Variant object representing a boolean condition expression. If you want to generate code for your model, you must define the control variables as Simulink.Parameter objects.

Settings

Default: The table has a row for each variant object in the base workspace. The Variant choices table includes the Model name, its associated Variant control, and Condition (read-only) columns.

Use the Add a new variant button to add a new row to the table. See the description of the Model name, Variant control, and Condition (read-only) table columns for information about how to set values for table rows.

Tips

You can use buttons to the left of the Variant choices table to modify the table.

FunctionButton
Add a new variant: Add a new, empty row below the currently selected row
Delete selected variant: Delete the currently selected row. (Models and objects are not affected.)
Create/Edit selected variant object: Creates a Simulink.Variant object in the base workspace and opens the Simulink.Variant object parameter dialog in order to specify the variant Condition . This button will only be enabled for valid Simulink.Variant objects.
Move variant up: Move the currently selected row up one slot in the table
Move variant down: Move the currently selected row down one slot in the table

Dependency

Enable variants enables this parameter.

Command-Line Information

Parameter: Variants
Type: array
Value: array of variant structures where each element specifies one variant. The structure fields are:
  • variant.Name (string) — The variant control can be a boolean condition expression, or a Simulink.Variant object representing a boolean condition expression. If you want to generate code for your model, you must define the control variables as Simulink.Parameter objects.

  • variant.ModelName (string) — The name of the referenced model associated with the specified variant control in the Model block.

  • variant.ParameterArgumentNames (string) — Read-only string containing the names of the model arguments for which the Model block must supply values.

  • variant.ParameterArgumentValues (string) — The values to supply for the model arguments when this variant is the active variant.

  • variant.SimulationMode (string) — The execution mode to use when this variant is the active variant.

    • Possible values are 'Accelerator' | 'Normal' | 'Software-in-the-loop (SIL)' | 'Processor-in-the-loop (PIL)'

See Also

Configure the Model Variants Block

Variant control

Displays the variant controls in the base workspace. The variant control can be a boolean condition expression, or a Simulink.Variant object representing a boolean condition expression. If you want to generate code for your model, you must define the control variables as Simulink.Parameter objects.

Settings

Default: Variant1

To enter a variant control name, double-click Variant control column in a new row and enter the variant control expression.

Dependency

Enable variants enables this parameter.

Command-Line Information

Structure field: Represented by the variant.Name field in the Variants parameter structure
Type: string
Value: Variant control associated with the variant.
Default: ''

See Also

Condition (read only)

Display the condition for the Simulink.Variant object.

Settings

This read-only field displays the condition for the associated model variant in the base workspace. Click the Edit selected variant object button to specify the condition for the selected variant object.

Tips

The variant condition must be a Boolean expression that references at least one base workspace variable or parameter. For example, FUEL== 2 && EMIS == 1. Do not surround the condition with parentheses or single quotes. The expression can include:

  • MATLAB variables defined in the base workspace

  • Simulink parameter objects defined in the base workspace

  • Scalar variables

  • Enumerated values

  • Operators ==, ~=, &&, ||, ~

  • Parentheses for grouping

Dependency

Enable variants enables this parameter.

See Also

Configure the Model Variants Block

Model name

Display or enter the name of the model associated with the variant control in the Variant choices table.

Settings

Default: ''

Double-click the table cell to enter a model name. The name must be a valid MATLAB identifier.

The extension, for example, .SLX, is optional.

Tips

You can type the model name into the table, or you can use the Model parameters for chosen variant in table controls to find and open models:

  • To navigate to the model that you want to reference for the selected variant in the table, click the Browse button to the right of the Model name edit box.

  • To confirm that the model you specify is the one you intended, click the Open Model button to the right of the Model name edit box.

Dependency

Enable variants enables this parameter.

Command-Line Information

Structure field: represented by the variant.ModelName field in the Variants parameter structure
Type: string
Value: any valid value
Default: name of the referenced model exactly as you typed it, with any surrounding white space removed. When you set the model name programmatically or using the GUI, Simulink automatically sets the values of ModelName and ModelFile based on the value of ModelNameDialog.

See Also

Set Up Model Variants

Model name

Display or enter the name of the model associated with the selected variant object in the Variant choices table.

Settings

Default: ''

Must be a valid MATLAB identifier.

The extension, for example, .SLX, is optional.

Tips

You can type the model name in either the table cell or the Model name edit box for the selected variant in the table. Use the controls to find and open models as follows:

  • To navigate to the model that you want to reference from this block, use the Browse button to the right of the Model name parameter.

  • To confirm that the model you specify is the one you intended, you can use the Open Model button to the right of the Model name parameter.

Dependency

Enable variants enables this parameter.

Command-Line Information

Structure field: represented by the variant.ModelName field in the Variants parameter structure
Type: string
Value: any valid value
Default: name of the referenced model exactly as you typed it, with any surrounding white space removed. When you set the model name programmatically or using the dialog, Simulink automatically sets the values of ModelName and ModelFile based on the value of ModelNameDialog.

See Also

Set Up Model Variants

Model arguments

Display model arguments for the variant control highlighted in the Variant choices table.

Declaring a variable to be a model argument allows each instance of the model to use a different value for that variable.

Settings

Default: ''

This is a read-only parameter that displays model arguments for the variant control highlighted in the Variant choices table. To create model arguments, refer to Using Model Arguments.

Dependency

Enable variants enables this parameter.

Command-Line Information

Structure field: Represented by the variant.ParameterArgumentNames field in the Variants parameter structureOneArgName
Type: string
Value: Enter model arguments as a comma separated list
Default: ''

See Also

Model argument values (for this instance)

Specify values to be passed as model arguments for the model variant control highlighted in the Variant choices table, each time the simulation invokes the model.

Settings

Enter the values in this parameter as a comma-separated list in the same order as the corresponding argument names in the Model arguments field.

Dependency

Enable variants enables this parameter.

Command-Line Information

Structure field: Represented by the variant.ParameterArgumentValues field in the Variants parameter structureOneArgName
Type: string
Value: Any valid value
Default: ''

See Also

Simulation mode

Set the simulation mode for the model variant control highlighted in the Variant choices table. This setting specifies whether to simulate the model by generating and executing code or by interpreting the model in Simulink.

Settings

Default: Accelerator

Accelerator

Creates a MEX-file for the sub model and then executes the sub model by running the S-function.

Normal

Executes the sub model interpretively, as if the sub model were an atomic subsystem implemented directly within the parent model.

Software-in-the-loop (SIL)

This option requires the Embedded Coder software. Generates production code using model reference target for the sub model. This code is compiled for, and executed on, the host platform.

Processor-in-the-loop (PIL)

This option requires the Embedded Coder software. Generate production code using model reference target for the sub model. This code is compiled for, and executed on, the target platform. A documented target connectivity API supports exchange of data between the host and target at each time step during the PIL simulation.

Dependency

Enable variants enables this parameter.

Command-Line Information

Structure field: Represented by the variant.SimulationMode field in the Variants parameter structure
Type: string
Value: 'Accelerator' | 'Normal'| 'Software-in-the-loop (SIL)' | 'Processor-in-the-loop (PIL)'
Default: 'Accelerator'

See Also

Override variant conditions and use following variant

Specify whether to override the variant conditions and make the specified Variant parameter the active variant.

Settings

Default: Off

On

Override the variant conditions and set the active variant to the value of the Variant .

Off

Determine the active variant by the value of the variant conditions.

Tip

Both this GUI parameter and the Variant GUI parameter (following) use the same API parameter, OverrideUsingVariant.

Dependencies

Enable variants enables this parameter.

This parameter enables variants.

Command-Line Information

Parameter: OverrideUsingVariant
Type: string
Value: '' if no overriding variant control is specified.
Default: ''

See Also

Create, Export, and Reuse Variant Controls

Variant

Specify the variant control associated with the model to use if you select Override variant conditions and use the following variant.

Settings

Default: ''

Must be a valid non empty or non commented name.

Tips

  • You can use the Variant drop down to view a list of all variant controls currently available and their associated models.

  • Both this GUI parameter and the Override variant conditions and use following variant GUI parameter (above) use the same API parameter, OverrideUsingVariant.

Dependencies

Enable variants and Override variant conditions and use the following variant enable this parameter.

Command-Line Information

Parameter: OverrideUsingVariant
Type: string (read-only)
Value: Variant control

See Also

Generate preprocessor conditionals

Control preprocessor conditionals. This check box is relevant only to code generation, and has no effect on the behavior of a model in Simulink. See Generate Preprocessor Conditionals for Variant Systems for more information.

Settings

Default: Disabled

Dependencies

  • The check box is available for generating only ERT targets.

  • Override variant conditions and use following variant is cleared ('off')

  • Model Configuration Parameters > Optimization > Inline parameters is selected ('on' )

  • Model Configuration Parameters > Code Generation > Interface > Generate preprocessor conditionals is set to Use local settings.

Command-Line Information

Parameter: GeneratePreprocessorConditionals
Type: string
Value: 'off' | 'on'
Default: 'off'

See Also

Variant Systems

Disable variants

Disable model reference variants and hide the Model Variants Section. The block retains any information you have entered and approved by clicking Apply or OK.

Command-Line Information

Parameter: Variant
Type: string
Value: 'off' | 'on'
Default: 'off'

Navigating a Model Block

  • 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 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 Feed through

When a Model block is part of a cycle, and the block is a direct feed through 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.

Direct Model Block Feed through Caused by Sub model Structure

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

Direct Model Block Feed through Caused by Model Configuration

Embedded Real Time (ert ) based targets provide the option Model Configuration Parameters > Code Generation > Interface > Single output/update function. This option controls whether generated code has separate output and update functions, or a combined output/update function. See:

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

Characteristics

Direct Feed through

If Single output/update function is enabled (default), a Model block is a direct feed through 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 feed through block, depending on the structure of the referenced model.

Scalar Expansion

Depends on model referenced by this block.

Multi dimensional

Yes

Requirements, Limitations, and Tips for Model Variants

A Model Variants block and its referenced models must satisfy the requirements in Simulink Model Referencing Requirements and Model Referencing Limitations. You can nest Model Variants blocks to any level.

Tips

  • A Model Variants block can log only those signals that the referenced model specifies as logged. If a model is a variant model, or contains a variant model, then you can either log all logged signals or log no logged signals. The Signal Logging Selector configuration for the model must be in one of these states:

    • The Logging Mode is set to Log all signals as specified in model.

    • The Logging Mode is set to Override signals and the check box for the model block is either checked ( ) or empty ( ). The check box cannot be filled ( ).

      For more information about logging referenced models, see Models with Model Referencing: Overriding Signal Logging Settings.

    To enable logging programmatically, use the DefaultDataLogging parameter.

    • You can enable or suppress warning messages about mismatches between a Model Variants block and its referenced model by setting diagnostics on the Diagnostics Pane: Model Referencing.

    • During model compilation, Simulink evaluates variant objects before calling the InitFcn callback. Therefore, do not modify the condition of the variant object in the InitFcn callback.

    • Each variant must have an associated variant control specified in the Variant control column. The variant control can be a boolean condition expression, or a Simulink.Variant object representing a boolean condition expression. If you want to generate code for your model, you must define the variant controls asSimulink.Parameter objects.

Was this topic helpful?