Main Content

Model Reference Interface and Boundary

A Model block has input, output, and control ports that correspond to root-level input, output, and control ports of the model it references. A referenced model can include Inport, Outport, In Bus Element, Out Bus Element, Trigger, and Enable blocks to get input from the parent model and to provide output to the parent model. The input signals for the Model block must be valid for the corresponding input blocks of the referenced model. The output signals for the Model block are the referenced model root-level output block signals.

In sldemo_mdlref_basic, each Model block has three inputs: two Constant blocks and a Pulse Generator block. Each Model block has one output signal logged to a scope. Because the input signal from each Pulse Generator block uses a different sample time, the output signal from each Model block differs for each model instance.

Each Model block has input ports named upper, input, and lower and one output port named output.

To connect to the parent model, referenced model sldemo_mdlref_counter includes three Inport blocks (upper, lower, and input) and one Outport block (output).

Blocks that represent model input and output are part of the block diagram for the model.

To view how the output signal for each Model block differs, you can use the Simulation Data Inspector.

Simulation Data Inspector plot of the output signal for each model instance

Refresh Model Blocks

Refreshing a Model block updates its internal representation to reflect changes to the interface of the referenced model. For example, when the referenced model gains or loses a port, refreshing the Model block updates its ports.

By default, when a referenced model is loaded, the Model blocks that reference it automatically refresh. When a referenced model is not loaded, the corresponding Model blocks refresh when you perform actions such as:

  • Opening the parent model

  • Selecting a Model block

  • Simulating the model hierarchy

  • Generating code for the model hierarchy

To be notified when Simulink® detects Model blocks that might not match their referenced models, change the default setting for these diagnostic configuration parameters:

When these configuration parameters are set to error for a model, the Model blocks in that model do not automatically refresh. To refresh a Model block when these configuration parameters are set to error, perform either of these actions:

When these configuration parameters are set to warning or none for a model, you can manually refresh all Model blocks in the model hierarchy. To do so, perform either of these actions:

Signal Propagation

Signal attributes in a referenced model are independent from the context of the Model block. For example, signal dimensions and data types do not propagate across the Model block boundary. To define signal attributes in a referenced model, define block parameters for root-level Inport and In Bus Element blocks.

For signals that connect to Outport blocks to propagate out of a referenced model to the parent model, the signal names must explicitly appear on the signal lines.

For buses at interfaces, use In Bus Element and Out Bus Element blocks instead of Inport and Bus Selector blocks for inputs and Outport and Bus Creator blocks for outputs. In Bus Element and Out Bus Element blocks support multirate virtual buses and do not require Simulink.Bus objects at model interfaces, unlike Inport and Outport blocks. They also provide cleaner bus interfaces. For more information, see Simplify Subsystem and Model Interfaces with Bus Element Ports.

For an example of a model hierarchy that uses buses with Inport blocks, see Interface Specification Using Bus Objects.

A referenced model can only provide input or get output for user-defined data types that are fixed point or that Simulink.DataType or Simulink.Bus objects define.

Signal Logging in Referenced Models

In a referenced model, you can log any signal configured for signal logging. Use the Signal Logging Selector to select a subset or all the signals configured for signal logging in a model hierarchy. For details, see Override Signal Logging Settings.

You can use the Simulation Data Inspector to view and analyze signals logged in referenced models. You can view signals on multiple plots, zoom, and use data cursors to understand and evaluate the data. Also, you can compare signal data from multiple simulations. For an example of viewing signals with referenced models, see Viewing Signals in Model Reference Instances.

Sample Time Requirements

The first nonvirtual block that connects to a referenced model root-level input or output block must have the same sample time as the related port. If the sample times are different, use Rate Transition blocks to match input and output sample times, as shown in this diagram.

Simple block diagram with one Rate Transition block after the Inport block and another Rate Transition block before the Outport block

Share Data Among Referenced Model Instances

By default, each Model block instance 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 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 Store Between Instances of a Reusable Algorithm.

  • To allow access to data outside the referenced model, use a global data store, which is a Simulink.Signal object in the base workspace or a data dictionary. Data outside the referenced model can be in the parent model or in other referenced models.

For more information about data stores, see Model Global Data by Creating Data Stores.

See Also

| | | |

Related Topics