| Simulink® | |
| On this page… |
|---|
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 Simulink® Model Referencing Limitations.
The name of a referenced model must contain fewer than 60 characters, exclusive of the .mdl suffix. An error occurs if the name of a referenced model is too long.
A referenced model uses a configuration set in the same way that any other model does, as described in Configuration Sets. By default, every model in a hierarchy has its own configuration set, which it uses in 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. Simulink's 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 Model configuration mismatch for details.
Where no acceptable resolution is possible, Simulink generates an error. You must then change some or all parameter values to eliminate the problem.
When a model reference hierarchy contains many submodels that have incompatible parameter values, or a changed parameter value must propagate to many submodels, manually eliminating all configuration parameter incompatibilities can be tedious. You can control or eliminate such overhead by using configuration references to assign an externally-stored configuration set to multiple models. See Referencing Configuration Sets for details.
Note Configuration parameters on the Real-Time Workshop® pane of the Configuration Parameters dialog have no effect on simulation in either Normal or Accelerated mode. Real-Time Workshop parameters affect only code generation by Real-Time Workshop itself. Although Accelerated mode simulation requires code generation to create a simulation target, Simulink uses default values for all Real-Time Workshop 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, or if set 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.
| Dialog Box Pane | Option | Requirement |
|---|---|---|
| Solver | Start time | The start time of the top model and all referenced models must be the same, but need not be zero. |
| Stop time | Simulink uses the top model's Stop time for simulation, overriding any differing Stop time in a submodel. | |
| Type Solver | The top model's Type and Solver apply throughout the hierarchy. See Solver Requirements. | |
| Data Import/Export | Initial state | Can be on for the top model, but must be off for a referenced model. |
Optimization | Inline parameters | Can be on or off for a top model, but must be on for a referenced model. See Inline Parameter Requirements. |
Application lifespan (days) | Must be the same for top and referenced models. | |
| Model Referencing | Total number of instances allowed per top model | Must not be Zero in a referenced model. Specifying One rather than Multiple is preferable or required in some cases. See Model Instance Requirements. |
Hardware Implementation | Embedded hardware options | All values must be the same for top and referenced models. |
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 submodel, as shown in the following table:
| Top Model Solver Type | Submodel Solver Type | Compatibility |
|---|---|---|
| Fixed Step | Fixed Step | Allowed |
| Variable Step | Variable Step | Allowed |
| Variable Step | Fixed-step | Allowed unless the submodel is multi-rate and specifies both a discrete sample time and a continuous sample time |
| Fixed Step | Variable Step | Error |
If an incompatibility exists between the top model solver and any submodel solver, one or both models must change as needed to use compatible solvers. For information about solvers, see Solvers and Choosing a Solver.
Inline Parameter Requirements. Simulink requires Configuration Parameters > Optimization > Inline parameters (see Inline parameters) to be enabled for all referenced models in a reference hierarchy. The top model can enable or disable inline parameters. If a referenced model disables inlined parameters, and you try to build the parent model:
For a Normal mode submodel, Simulink generates an error and cancels the build. All models and compiled files remain unchanged after the failed build.
For an Accelerator mode submodel, Simulink temporarily enables inline parameters, posts no warning, and builds the model. Inline parameters remain disabled after the build completes.
Simulink ignores tunable parameter specifications in the Model Parameter Configuration Dialog Box for both the top model and referenced models. Consequently, you cannot use this dialog box to override the inline parameters optimization for selected parameters and thereby permit them to be tuned. Parameterizing Model References describes alternate techniques.
Model Instance Requirements. A referenced model must specify that it is available for such use, and whether it can be used at most once or can have multiple instances. Configuration Parameters > Model Referencing > Total number of instances allowed per top model provides this specification. See Total number of instances allowed per top model for more information. The possible values for this parameter are:
Zero — The model cannot be referenced. An error occurs if a reference to the model occurs in another model.
One — The model can be referenced at most once in a model reference hierarchy. An error occurs if more than one instance exists. This value may be preferable or required.
Multiple — The model can be referenced more than once in a hierarchy, provided that 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, but does not affect data values that result from simulation or from executing code generated by Real-Time Workshop . Specifying Multiple when only one model instance exists facilitates later reusing the model in the same hierarchy, or multiple times in a different hierarchy, without having to change or rebuild the model.
Some model properties and constructs require Total number of instances allowed per top model to be set to One, limiting the model to being used only once in a hierarchy. For details, see General Reusability Limitations and Accelerator Mode Reusability Limitations.
The following requirements relate to the structure of a model reference hierarchy independently of configuration parameter requirements.
The signal name must explicitly appear on any signal line connected to an Outport of a referenced model. A signal that is connected by an unlabeled line to an Outport of a referenced model cannot propagate out of the Model block to the parent model.
A bus that propagates between a parent model and a referenced model must be nonvirtual, and the same bus object must specify the properties of the bus in both the parent and the referenced model. This object must be defined in the MATLAB® workspace. See Using Buses for more information.
The first nonvirtual block connected to a root-level Inport or Outport of a referenced model must have the same sample time as the port to which it connects. You can use Rate Transition blocks to match input and output sample times as illustrated in the following diagram.
| Simulation Targets | Parameterizing Model References | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |