This is machine translation

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

Note: This page has been translated by MathWorks. Please click here
To view all translated materals including this page, select Japan from the country navigator on the bottom of this page.

Simulink Model Referencing Requirements

About Model Referencing Requirements

A model reference hierarchy must satisfy various Simulink® requirements, as described in this section. Some limitations also apply, as described in Model Referencing Limitations.

Name Length Requirement

The name of a referenced model must contain fewer than 60 characters, exclusive of the .slx or .mdl suffix. An error occurs if the name of a referenced model is too long.

Configuration Parameter Requirements

A referenced model uses a configuration set in the same way that any other model does, as described in Manage a Configuration Set. By default, every model in a hierarchy has its own configuration set. Each model uses its configuration set the same way that it would if the model executed independently.

Because each model can have its own configuration set, configuration parameter values can be different in different models. Furthermore, some parameter values are intrinsically incompatible with model referencing. The Simulink response to an inconsistent or unusable configuration parameter depends on the parameter:

  • Where an inconsistency has no significance, or a trivial resolution exists that carries no risk, Simulink ignores or resolves the inconsistency without posting a warning.

  • Where a nontrivial and possibly acceptable solution exists, Simulink resolves the conflict silently, resolves it with a warning, or generates an error. See Diagnostic Configuration Parameter Changesfor details.

  • Where no acceptable resolution is possible, Simulink generates an error. Change some or all parameter values to eliminate the problem.

Manually eliminating all configuration parameter incompatibilities can be tedious when:

  • A model reference hierarchy contains many referenced models that have incompatible parameter values

  • A changed parameter value must propagate to many referenced models

You can control or eliminate such overhead by using configuration references to assign an externally stored configuration set to multiple models. See Manage a Configuration Reference for details.

    Note:   Configuration parameters on the Code Generation pane of the Configuration Parameters dialog box do not affect simulation in either normal or accelerator mode. Code Generation parameters affect only code generation by Simulink Coder™ itself. Accelerated mode simulation requires code generation to create a simulation target. Simulink uses default values for all Code Generation parameters when generating the target, and restores the original parameter values after code generation is complete.

The tables in the following sections list Configuration parameter options that can cause problems if set:

  • In certain ways, as indicated in the table

  • Differently in a referenced model than in a parent model

Where possible, Simulink resolves violations of these requirements automatically, but most cases require changes to the parameters in some or all models.

Configuration Parameters Changed During Accelerated Simulation and Code Generation

During model referencing simulation in accelerator and rapid accelerator mode, Simulink temporarily sets several Configuration Parameters > Diagnostics > Data Validity parameter settings to None, if they are set to Warning or Error. You can use the Model Advisor to check for parameters that change. For details, see Certain Diagnostic Configuration Parameters Ignored for Models Referenced in Accelerator Mode.

If the Configuration Parameters > Code Generation > Symbols parameters hold identifier information about the name of a referenced model and do not use a$R token, code generation prepends the $R token to the name of the model. You can use the Model Advisor to check for changed model names. See Configuration Parameters Changed During Code Generation.

Configuration Requirements for All Referenced Model Simulation

Dialog Box PaneOptionRequirement
SolverStart timeThe start time of the top model and all referenced models must be the same, but need not be zero.
Stop timeSimulink uses Stop time of the top model for simulation, overriding any differing Stop time in a referenced model.
The Type and Solver of the top model apply throughout the hierarchy. See Solver Requirements.
Data Import/ExportInitial stateCan be on for the top model, but must be off for a referenced model.


Default parameter behaviorIf the parent model has this set to Inlined, then the referenced model cannot have this set to Tunable.

Application lifespan (days)

For code generation, must be the same for parent and referenced models. For simulation, the setting can be different for the parent and referenced models.

Model ReferencingTotal number of instances allowed per top modelMust not be Zero in a referenced model. Specifying One rather than Multiple is preferable or required in some cases. See Model Instance Requirements.

Solver Requirements.  Model referencing works with both fixed-step and variable-step solvers. All models in a model reference hierarchy use the same solver, which is always the solver specified by the top model. An error occurs if the solver type specified by the top model is incompatible with the solver type specified by any referenced model.

Top Model Solver Typereferenced model Solver TypeCompatibility
Fixed StepFixed StepAllowed
Variable StepVariable StepAllowed
Variable StepFixed-stepAllowed unless the referenced model is multi-rate and specifies both a discrete sample time and a continuous sample time
Fixed StepVariable StepError

If an incompatibility exists between the top model solver and any referenced model solver, one or both models must change to use compatible solvers. For information about solvers, see Solvers and About Solvers.

Model Instance Requirements.  A referenced model must specify that it is available to be referenced, and whether it can be referenced at most once or can have multiple instances. The Configuration Parameters > Model Referencing > Total number of instances allowed per top model parameter provides this specification. See Total number of instances allowed per top model for more information. The possible values for this parameter are:

  • Zero — A model cannot reference this model. An error occurs if a reference to the model occurs in another model.

  • One — A model reference hierarchy can reference the model at most once. An error occurs if more than one instance of the model exists. This value is sometimes preferable or required.

  • Multiple — A model hierarchy can reference the model more than once, if it contains no constructs that preclude multiple reference. An error occurs if the model cannot be multiply referenced, even if only one reference exists.

Setting Total number of instances allowed per top model to Multiple for a model that is referenced only once can reduce execution efficiency slightly. However, this setting does not affect data values that result from simulation or from executing code Simulink Coder generates. Specifying Multiple when only one model instance exists avoids having to change or rebuild the model when reusing the model:

  • In the same hierarchy

  • Multiple times in a different hierarchy

Some model properties and constructs require setting Total number of instances allowed per top model to One. For details, see General Reusability Limitations and Accelerator Mode Reusability Limitations.

Model Structure Requirements

The following requirements relate to the structure of a model reference hierarchy.

Signal Propagation Requirements

The signal name must explicitly appear on any signal line connected to an Outport block of a referenced model. A signal connected to an unlabeled line of an Outport block of a referenced model cannot propagate out of the Model block to the parent model.

Bus Usage Requirements

For bus signals that cross model reference boundaries, use the same bus object to specify the properties of the bus in both the parent and the referenced model. For details, see Bus Data Crossing Model Reference Boundaries.

Sample Time Requirements

The first nonvirtual block connected to a root-level Inport or Outport block of a referenced model must have the same sample time as the port to which it connects. Use Rate Transition blocks to match input and output sample times, as illustrated in the following diagram.

Related Examples

More About

Was this topic helpful?