This is machine translation

Translated by Microsoft
Mouseover text to see original. Click the button below to return to the English version of the page.

Note: This page has been translated by MathWorks. Click here to see
To view all translated materials including this page, select Country from the country navigator on the bottom of this page.

Model

Include multiple model implementations as block in another model through model reference

  • Library:
  • Simulink / 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 (using the Model block) is called the parent model.

The Model block displays input 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 References for more information.

By default, the contents of a referenced model are user-visible by double-clicking the Model block. However, you can hide the contents of a referenced model by making the model a protected model.

To set the referenced model and simulation parameters, open the Block Parameters dialog box and use the Main tab. To specify values for model arguments, use the Arguments tab.

Ports

Input

expand all

The Model block has an input port for each root-level Inport, Enable, or Trigger block in the referenced model. The name of the Model block port matches the name of the corresponding referenced model input block. The Model block input signals must be valid for the corresponding referenced model input blocks. See Model Reference Interface.

Input signals can have real or complex values of any data type supported by Simulink, including bus objects, arrays of buses, fixed-point, and enumerated data types. For details about data types, see Data Types Supported by Simulink.

Output

expand all

The Model block has an output port for each root-level Outport block in the referenced model. The name of the Model block port matches the name of the corresponding Outport block. The Model block output signals are the signals from the corresponding referenced model Outport blocks. See Model Reference Interface.

Output signals can have real or complex values of any data type supported by Simulink, including bus objects, arrays of buses, fixed-point, and enumerated data types. For details about data types, see Data Types Supported by Simulink.

Parameters

expand all

Main Tab

Path to the referenced model. The file name must be a valid MATLAB® identifier. The extension, for example, .slx, is optional. The file name must contain fewer than 60 characters, exclusive of the .slx or .mdl suffix.

To navigate to the model that you want to reference, click Browse.

To view the model that you specified, click Open Model.

Programmatic Use

Parameter: ModelFile
Type: character vector
Value: '' | '<file name>'
Default: ''

Specify the simulation mode for the Model block. The simulation mode for the Model block can be different than the simulation mode of its referenced model and of other models in the model hierarchy.

  • Accelerator — Create a MEX-file for the referenced model and then executes the referenced model by running the S-function.

  • Normal — Execute the referenced model interpretively, as if the referenced model is an atomic subsystem implemented directly within the parent model.

  • Software-in-the-loop (SIL) — This option requires the Embedded Coder® software. Generate production code based on the Code Interface parameter setting. The 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 based on the Code Interface parameter setting. 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.

The corners of the Model block reflect the simulation mode of the Model block. For normal mode, the corners have empty triangles. For accelerator mode, the corner triangles are filled in. For SIL and PIL modes, the corners are filled in and the word (SIL) or (PIL) appears on the block icon.

While you can set a referenced model to rapid accelerator mode, simulation ignores the referenced model simulation mode. For information about simulation mode precedence in a model hierarchy, see Simulate Model Hierarchies.

Programmatic Use

Parameter: SimulationMode
Type: character vector
Value: 'Normal' | 'Accelerator' | 'Software-in-the-loop' | 'Processor-in-the-loop'
Default: 'Normal'

Specify whether to generate the code from the top model or the referenced model for SIL and PIL simulation modes. To deploy the generated code as part of a larger application that uses the referenced model, specify Model reference. To deploy the generated code as a standalone application, specify Top model.

Model reference

Code generated from referenced model as part of a model 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.

Dependencies

To display and enable this parameter, select either Software-in-the-loop (SIL) or Processor-in-the-loop (SIL) from the Simulation mode drop-down list.

Programmatic Use

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

Control display of initialize event port on the Model block.

off

Remove port.

on

Display model initialize event port.

Programmatic Use

Block parameter: ShowModelInitializePort
Type: character vector
Value: 'off' | 'on'
Default: 'off'

Control display of reset event ports on the Model block.

off

Remove port.

on

Display model reset event ports.

Programmatic Use

Block parameter: ShowModelResetPorts
Type: character vector
Value: 'off' | 'on'
Default: 'off'

Control display of terminate event port on Model block.

off

Remove port.

on

Display model block port.

Programmatic Use

Block parameter: ShowModelTerminatePort
Type: character vector
Value: 'off' | 'on'
Default: 'off'

Control display of periodic event ports on Model block.

off

Hide ports.

on

Display ports for rate-based models. A rate-based model is a model with the Sample time for a connected Inport block specified.

If you want to manually specify the port rates, set the parameter AutoFillPortDiscreteRates to 'off', and then add the port rates to the parameter PortDiscreteRates.

Programmatic Use

Block parameter: ShowModelPeriodicEventPorts
Type: character vector
Value: 'off' | 'on'
Default: 'off'

Arguments Tab

Display model arguments and specify model argument values. Model arguments enable the referenced model to use a different value for a variable used by a referenced model. To specify model argument values, use the Value column in the table. For more information about configuring model arguments in a referenced model and specifying argument values, see Parameterize Instances of a Reusable Referenced Model.

When changing argument values, you can use a partial structure, which has fields that correspond to only the arguments whose values you want to change. Arguments not included in the partial structure retain their values. In the structure, include the model argument names and values, represented as character vectors.

Programmatic Use

Block parameter: ParameterArgumentNames
Type: character vector
Value: character vector in the form of 'argument1,argument2'
Default: none

Programmatic Use

Block parameter: ParameterArgumentValues
Type: structure
Value: structure
Default: structure with no fields

Block Characteristics

Data Types

double[a] | single[a] | Boolean[a] | base integer[a] | fixed point[a] | enumerated[a] | bus[a] | string[a]

Direct Feedthrough

No

Multidimensional Signals

Yes[a]

Variable-Size Signals

Yes[a]

Zero-Crossing Detection

No

[a] 

Actual data type or capability support depends on block implementation.

Compatibility Considerations

expand all

Warns starting in R2017b

Extended Capabilities

Introduced before R2006a