Documentation

Model, Model Variants

Include multiple model implementations 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 Referencing 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:

An InitFcn callback in a top model cannot change parameters used by referenced models.

Data Type Support

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

Parameters

Code interface

Specify whether the generated code is from top model or referenced model.

Settings

Default: Model reference

Model reference

Code generated from referenced model as part of a model reference hierarchy. Code generation uses the slbuild('model', 'ModelReferenceRTWTarget') command.

Top model

Code generated from top model with the standalone code interface. Code generation uses the slbuild('model') command.

Dependency

Setting the Simulation mode parameter to Software-in-the-loop (SIL) or Processor-in-the-loop (PIL) enables this parameter.

Command-Line Information

Parameter: CodeInterface
Type: character vector
Value: 'Model reference' | 'Top model'
Default: 'Model reference'

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_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 (character vector) — 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 (character vector) — The name of the referenced model associated with the specified variant control in the Model block.

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

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

  • variant.SimulationMode (character vector) — 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: character vector
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: ''

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 Browse.

  • To confirm your selection, click Open Model.

Dependency

Enable variants enables this parameter.

Command-Line Information

Structure field: represented by the variant.ModelName field in the Variants parameter structure
Type: character vector
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 box, 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 Specify Different Value for Each Instance of Reusable Model.

Dependency

Enable variants enables this parameter.

Command-Line Information

Structure field: Represented by the variant.ParameterArgumentNames field in the Variants parameter structureOneArgName
Type: character vector
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 list in the same order as the corresponding argument names in the Model arguments field. To separate the items in the list, use commas, spaces, or semicolons.

Dependency

Enable variants enables this parameter.

Command-Line Information

Structure field: Represented by the variant.ParameterArgumentValues field in the Variants parameter structureOneArgName
Type: character vector
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: character vector
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: character vector
Value: '' if no overriding variant control is specified.
Default: ''

See Also

Create Variant Controls Programmatically

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: character vector (read-only)
Value: Variant control

See Also

Variant control

Enter the variant activation condition or the variant control that contains the expression for variant activation.

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, define control variables as Simulink.Parameter objects.

Settings

Default: Variant

Dependency

Adding a Model block inside a Variant Subsystem block enables this parameter

Command-Line Information

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

See Also

Generate preprocessor conditionals

When generating code for an ERT target, this parameter determines whether variant choices are enclosed within C preprocessor conditional statements (#if).

When you select this option, Simulink analyzes all variant choices during an update diagram or simulation. This analysis provides early validation of the code generation readiness of all variant choices.

Settings

Default: Disabled

Dependencies

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

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

Command-Line Information

Parameter: GeneratePreprocessorConditionals
Type: character vector
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: character vector
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. See:

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

Generic Real Time (grt ) and Embedded Real Time (ert ) based targets provide the option Model Configuration Parameters > All Parameters > 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

Data Types

Double | Single | Boolean | Base Integer | Fixed-Point | Enumerated | Bus

Direct Feedthrough

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.

Multidimensional Signals

Yes

Variable-Size Signals

Yes

Code Generation

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.

Introduced before R2006a

Was this topic helpful?